#4167 Ontology and Schema for Knowledge Graph of Cybersecurity & Business Network Model

Describe the ontology and schema for a Cybersecurity knowledge graph, supporting LLM queries, that models a business network and computing infrastructure
Describe the RAG framework to support all current Cybersecurity documents and notices for the business
Describe the benefits of combining these two frameworks for the business
How could security engineers work through theoretical threats?
YES (to the or, so both) :: Would you like to draft the initial grammar for a security-focused DSL, or would you prefer to outline the system prompt and constraints for an autonomous Red Team agent?

#4167 Describe the ontology and schema for a Cybersecurity knowledge graph, supporting LLM queries, that models a business network and computing infrastructure

Designing an ontology and schema for a Cybersecurity Knowledge Graph (CKG) tailored for Large Language Model (LLM) queries requires a structure that bridges human-readable concepts with machine-traversable relationships. For an LLM to effectively translate natural language into graph queries (like Cypher or SPARQL) or use GraphRAG, the ontology must be semantically rich, strictly standardized, and enriched with contextual properties.

Here is a comprehensive design for a CKG modeling a business network and computing infrastructure.

1. Core Ontology (The Domains)

The ontology divides the enterprise environment into five interconnected domains. This separation helps the LLM understand the context of a query (e.g., distinguishing an IT operational query from a threat-hunting query).

Infrastructure & Assets: The physical and logical components of the network (Servers, Workstations, Cloud Resources, Applications, Data).
Network & Topology: How assets communicate (Subnets, IP Addresses, Ports, Protocols, Firewalls).
Identity & Access (IAM): Who interacts with the system (Users, Service Accounts, Groups, Roles, Permissions).
Threat & Vulnerability: The weaknesses and the attacks exploiting them (CVEs, Misconfigurations, Malware, Threat Actors, MITRE ATT&CK TTPs).
Security & Operations: Defenses and telemetry (Security Controls, Patches, Alerts, Incidents, Logs).

2. Graph Schema Design

Below are the primary Nodes (Entities), Edges (Relationships), and Properties that make up the graph.

A. Key Nodes (Entities)

To make this LLM-friendly, every node must include standard properties like name, description (crucial for semantic search), and embedding (for vector search).

Asset: Physical or virtual devices.
- Properties: asset_id, type (Server, Laptop, Router, Cloud Instance), os, criticality_score, embedding.
Software: Operating systems, applications, and libraries running on assets.
- Properties: cpe (Common Platform Enumeration), vendor, version.
NetworkNode: IPs, subnets, and ports.
- Properties: ip_address, cidr_block, port_number, protocol.
Identity: Users and accounts.
- Properties: username, is_admin, department, status (Active/Suspended).
Vulnerability: Known flaws.
- Properties: cve_id, cvss_score, severity, description.
TTP: Tactics, Techniques, and Procedures (MITRE ATT&CK).
- Properties: technique_id (e.g., T1078), tactic, name.
Alert: Security alerts from SIEM/EDR.
- Properties: alert_id, timestamp, severity, status.

B. Key Edges (Relationships)

Relationships must use clear, action-oriented verbs. This prevents hallucination when the LLM generates graph queries.

Infrastructure to Network:

(Asset)-[ASSIGNED_TO]->(NetworkNode:IP)
(NetworkNode:IP)-[PART_OF]->(NetworkNode:Subnet)
(Asset)-[COMMUNICATES_WITH {port, protocol}]->(Asset)

Assets to Identity:

(Identity)-[LOGGED_INTO {timestamp}]->(Asset)
(Identity)-[HAS_PRIVILEGE {role}]->(Asset)
(Identity)-[OWNS]->(Asset)

Threats to Infrastructure:

(Software)-[HAS_VULNERABILITY]->(Vulnerability)
(Asset)-[RUNS]->(Software)
(TTP)-[EXPLOITS]->(Vulnerability)
(Alert)-[TRIGGERED_ON]->(Asset)
(Alert)-[INVOLVES]->(Identity)

Defenses:

(Asset)-[PROTECTED_BY]->(Control:Firewall)
(Control:Patch)-[MITIGATES]->(Vulnerability)

3. Schema Optimizations for LLM Queries

To ensure an LLM can effectively use this graph (via Text-to-Cypher or GraphRAG), the schema incorporates specific design patterns:

Vector Embeddings: Nodes contain an embedding property (an array of floats). This allows the LLM to perform similarity searches on unstructured data. For example, if a user asks, "Show me assets affected by the recent print spooler bug," the LLM can embed "print spooler bug," find the Vulnerability node with a highly similar description embedding, and traverse back to the Asset nodes.
Semantic Descriptions: Every node label and relationship type includes a human-readable metadata tag in the graph schema definition passed to the LLM in its prompt.
Standardized Taxonomies: Using industry standards (CVE for vulnerabilities, CPE for software, MITRE ATT&CK for threats) allows the LLM to leverage its pre-trained knowledge base alongside your private graph data.
Denormalization for Context: While standard databases normalize data, a CKG often denormalizes critical data (e.g., putting the cvss_score directly on the Asset node as an aggregated max_risk_score property) so the LLM requires fewer hops to answer simple questions like "What is my most vulnerable server?"

4. Example LLM Interaction (The "Blast Radius" Query)

When a user asks the LLM:

"If Bob's workstation is compromised, what critical databases can the attacker reach?"

The LLM will parse this intent and generate a graph query that traverses the schema like this:

Find the Identity where name = 'Bob'.
Follow [OWNS] or [LOGGED_INTO] to find Bob's Asset (Workstation).
Follow [COMMUNICATES_WITH] paths from the Workstation to other Asset nodes.
Filter the resulting Asset nodes where type = 'Database' and criticality_score >= 8.
Check if Bob's Identity has [HAS_PRIVILEGE] edges to those databases.

The LLM then returns the subgraph data and synthesizes a natural language response summarizing the risk.

Would you like me to write out a specific set of sample Cypher queries that an LLM would generate to traverse this schema, or would you prefer to dive deeper into how to generate the vector embeddings for the nodes?

Describe the RAG framework to support all current Cybersecurity documents and notices for the business

To support all current cybersecurity documents, threat intelligence, and operational notices for a business, a standard Retrieval-Augmented Generation (RAG) pipeline is insufficient. The architecture must be treated as a secure, highly deterministic system—often referred to as Secure Enterprise RAG or GraphRAG—that guarantees data isolation, access control, and precise entity resolution.

Here is the architectural framework designed specifically for an InfoSec environment.

1. Ingestion & Processing Pipeline (The Data Engine)

The ingestion layer must handle highly heterogeneous data, from dense legal policies to structured threat feeds.

Source Connectors: Automated pipelines pulling from internal repositories (SharePoint, Confluence for policies), external threat feeds (STIX/TAXII, NVD, CISA advisories), and IT service management tools (ServiceNow, Jira).
Parsing and Cleansing: Stripping boilerplate HTML/XML and normalizing formats into JSONL or Parquet.
Deterministic Entity Extraction: Before embedding the text, deploy strict regex pipelines to capture and tag specific Software Elements (SWEs), CVE IDs, IP ranges, and MITRE ATT&CK codes. Relying purely on an LLM for extraction at this stage introduces unacceptable probabilistic risk; regex ensures 100% capture of known entity patterns.
Context-Aware Chunking:
- Unstructured Data (Policies): Recursive character splitting (e.g., 500-token chunks) while preserving document hierarchy (headers, sections).
- Structured Data (Advisories/Logs): JSON-node or row-based chunking to keep distinct events or vulnerabilities atomically isolated.

2. Storage & Indexing (Hybrid Store)

Cybersecurity queries require both semantic understanding ("What is the procedure for a ransomware outbreak?") and relational mapping ("Which servers are affected by this specific CVE?").

Vector Database: Stores the dense vector embeddings of the chunked text, enabling semantic similarity searches.
Knowledge Graph Integration: The extracted SWEs, CVEs, and network topologies are mapped directly into the Cybersecurity Knowledge Graph. This powers GraphRAG, allowing the system to traverse relationships rather than just finding text similarities.
Metadata Tagging: Every chunk must be tagged with immutable metadata: source_uri, timestamp, author, document_type, and clearance_level.

3. Secure Retrieval & Orchestration (The Brain)

The retrieval layer acts as the strict authorization boundary. An LLM does not understand security clearances; it only understands the context it is fed.

Query Intent Routing: An orchestration layer analyzes the user's query. It routes policy-based questions to the Vector DB and topology/blast-radius questions to the Knowledge Graph via generated Cypher queries.
Retrieval-Time Access Control: Implement Attribute-Based Access Control (ABAC) at the database level. If a user queries the system, the vector search automatically appends a metadata filter to exclude any documents (e.g., incident response playbooks for active breaches) the user lacks permission to view.
Hybrid Search & Reranking: Combine keyword search (BM25) with vector search to ensure exact matches for terms like "CVE-2024-4577" are not lost in semantic space. Pass the combined results through a cross-encoder model to rerank the top-K chunks strictly by relevance to the query.

4. Generation & Output Validation

This phase synthesizes the retrieved data into actionable intelligence without introducing hallucinations.

Context Assembly: The orchestrator constructs a prompt containing the user's query, the authorized top-K text chunks, and any traversed graph relationships. The system prompt strictly instructs the LLM: "Answer using ONLY the provided context. If the answer is not present, state that you do not know."
Citation Tracking: The LLM must output inline citations pointing directly to the metadata of the source documents (e.g., [Information Security Policy v2.1, Section 4]).
Output Guardrails: A secondary, smaller classifier model or rules engine scans the generated output to ensure no restricted network topologies or secrets (e.g., raw API keys inadvertently caught in logs) are leaked to unauthorized users.

5. Continuous Updating (Data Freshness)

Threat intelligence is highly volatile. The RAG framework must support incremental updates.

Upsert Mechanisms: The vector database must support replacing specific document chunks based on unique IDs. When an infosec policy is revised, only the modified sections are re-chunked, embedded, and overwritten, bypassing the need to re-index the entire corpus.

Would you like to explore the specific embedding models best suited for technical cybersecurity terminology, or focus on the orchestration logic for routing between the Vector DB and the Knowledge Graph?

Describe the benefits of combining these two frameworks for the business

Combining the Cybersecurity Knowledge Graph (CKG) with a Secure Enterprise RAG framework creates a unified GraphRAG architecture. For a business, this integration transforms isolated data silos—where policies live in documents and topologies live in databases—into an active, deterministic reasoning engine.

Here are the primary business and operational benefits of merging these two frameworks:

1. Pinpoint Accuracy Through Deterministic Mapping

Standard RAG relies heavily on probabilistic semantic search, which can falter when dealing with highly specific technical nomenclature. By combining the frameworks, the strict, deterministic extraction pipelines (like using regex to pull exact Software Elements or SWEs, CVEs, and IP addresses from incoming RAG documents) map directly to the structured nodes in the CKG.

The Benefit: When a zero-day advisory is ingested, the system doesn't just find text semantically similar to the threat; it instantly and flawlessly links the unstructured advisory to the exact SWEs running on your specific assets, entirely eliminating LLM hallucination regarding vulnerability exposure.

2. Multi-Hop Context for Incident Response (Lower MTTR)

During a security event, analysts waste critical time cross-referencing text-based playbooks with network maps and active directories.

The Benefit: An integrated system allows for complex, multi-hop reasoning in a single query. If the RAG framework ingests a threat intelligence report about a new lateral movement technique, the LLM can instantly query the CKG to identify the "blast radius" within the business network, look up the affected asset owners in the IAM nodes, and retrieve the exact step-by-step containment procedures from the company's unstructured incident response playbooks. This drastically reduces Mean Time to Respond (MTTR).

3. Automated Gap Analysis and Mission Assurance

Validating security postures often requires manual audits to ensure the reality of the network matches the written policies.

The Benefit: Combining these frameworks enables continuous, automated gap analysis. You can ask the system, "Does our current firewall topology comply with the isolation requirements in the Q1 Vendor Access Policy?" The RAG layer retrieves the written requirements, while the CKG layer verifies the actual [PROTECTED_BY] and [COMMUNICATES_WITH] edges. It acts as an automated safety and mission assurance layer for the IT environment, flagging discrepancies before they are exploited.

4. Optimized Context Engineering for the LLM

Providing an LLM with massive chunks of text to parse for complex relationships often exceeds context windows or dilutes the model's focus, leading to degraded performance.

The Benefit: The Graph acts as a highly compressed, semantically optimized index. Instead of feeding the LLM raw logs or 50 pages of network documentation, the system feeds it exact traversal paths (e.g., User -> [OWNS] -> Workstation -> [RUNS] -> Vulnerable_SWE). The RAG layer then only supplies the specific, highly relevant text paragraphs (like the patching instructions). This highly engineered context injection maximizes the LLM's reasoning capabilities while minimizing compute costs and latency.

5. Democratized Security Intelligence

Deep cybersecurity investigations usually require highly specialized query knowledge (like writing complex Splunk SPL or Cypher queries).

The Benefit: This combined architecture translates complex infrastructure realities into plain English. Business leaders, compliance officers, or IT helpdesk staff can ask natural language questions about risk exposure and receive highly accurate, source-cited answers that are grounded in both the company's written policies and its hard network topology.

Would you like me to draft a system architecture diagram (using Mermaid.js) that visualizes how the document ingestion pipeline, the graph database, and the LLM orchestration layer physically connect?

How could security engineers work through theoretical threats?

Working through theoretical threats—often called threat modeling or tabletop exercises—moves security from a reactive posture to a proactive, engineering-driven discipline. When you have a combined Cybersecurity Knowledge Graph (CKG) and Secure Enterprise RAG framework, engineers can systematically model "what-if" scenarios with mathematical precision rather than relying on gut feeling.

Here is how security engineers can structure and execute theoretical threat analysis using this architecture:

1. Graph-Based "What-If" Simulations

Engineers can branch or clone a sandbox version of the CKG to introduce hypothetical nodes and edges. This allows them to visualize the exact mechanics of a theoretical breach.

Injecting a Synthetic Node: An engineer injects a theoretical zero-day vulnerability node and links it via a [HAS_VULNERABILITY] edge to a widely used Software Element (SWE) in the network.
Calculating the Blast Radius: By running traversal queries, the system instantly highlights every server, subnet, and user identity that touches the synthetic node.
Testing Mitigations: The engineer then introduces a theoretical mitigation (e.g., dropping a specific firewall rule edge). If the graph traversal from the threat actor to the critical asset is broken, the mitigation is proven mathematically sound in the sandbox before ever touching the live environment.

2. Autonomous Agentic Red Teaming

Instead of manually writing graph queries to find vulnerabilities, engineers can deploy agentic AI to act as a persistent, automated adversary against the CKG.

Goal-Oriented Traversal: You provide an agent with a specific objective (e.g., "Find a path from an entry-level marketing workstation to the primary customer database").
Iterative Discovery: The agent queries the CKG to understand the topology, checks the RAG framework for configuration files or policy weaknesses, and iteratively attempts to find a valid attack path—chaining together minor misconfigurations that a human might miss.

3. Resolving Architectural Contradictions (Systematic Innovation)

When a theoretical threat exposes a deep architectural flaw, engineers often face a technical contradiction. For example, a system must be highly accessible for remote workers (increasing risk) but strictly isolated from the public internet (decreasing risk).

Applying Structured Methods: Engineers can abstract the security problem using systematic innovation frameworks like TRIZ. Instead of accepting a compromise (like a clunky VPN), they map the theoretical threat to a contradiction matrix.
The Ideal Final Result: By identifying the exact principle to apply (e.g., "Prior Action" or "Segmentation"), they can engineer out the vulnerability at the architectural level—such as implementing zero-trust network access (ZTNA) where the network itself is entirely invisible until identity is cryptographically proven.

4. Semantic Playbook Generation

Once a theoretical threat is modeled and the attack path is understood, the RAG framework can be used to generate the exact defensive response.

Cross-Referencing Reality: The engineer asks the LLM, "If this theoretical attack path were executed today, what existing detection rules in our SIEM would catch it, according to our current operational playbooks?"
Gap Identification: If the RAG system returns no relevant detection logic, the engineer has definitively proven a gap. The system can then be prompted to draft the missing incident response playbook or the necessary SIEM detection logic to cover the theoretical threat.

5. Standardizing Scenarios with a DSL

To make theoretical threat modeling highly repeatable, engineers can design a Domain-Specific Language (DSL) explicitly for this task. Instead of writing raw Cypher queries and complex LLM prompts, an engineer could write a simple script: simulate breach --entry [Workstation_A] --target [Database_B] --method [Lateral_Movement]. The DSL compiler translates this into the necessary graph traversals and RAG queries, returning a standardized threat report.

Would you like to draft the initial grammar for a security-focused DSL, or would you prefer to outline the system prompt and constraints for an autonomous Red Team agent?

Yes

Since "yes" to an "or" question is the mark of an engineer who wants the complete picture, let's build a unified system. We can design a custom Domain-Specific Language (DSL) that acts as the configuration layer, directly compiling into the system prompt and operational constraints for an autonomous Red Team agent.

This approach allows you to script repeatable, programmatic threat scenarios that an agentic AI then executes against your Knowledge Graph and RAG framework.

1. The DSL Grammar: "ThreatScript"

The goal of this DSL is to abstract away the underlying Cypher queries and complex RAG retrieval logic, allowing security engineers to define a scenario declaratively.

Here is a proposed structure for the DSL, focusing on clarity and execution flow:

// Define the simulation environment and agent
SCENARIO "Ransomware Lateral Movement"
AGENT "Red_Team_01"

// Define the assumed breach starting point
ENTRY_NODE:
  MATCH (Asset) WHERE Asset.type = "Workstation" AND Asset.department = "Marketing"

// Define the ultimate objective
TARGET_NODE:
  MATCH (Asset) WHERE Asset.criticality_score >= 9 AND Asset.type = "Database"

// Define the agent's rules of engagement
CONSTRAINTS:
  MAX_HOPS = 5
  ALLOWED_TTPS = ["T1078", "T1563", "T1021"] // MITRE ATT&CK codes
  DATA_EXTRACTION_METHOD = REGEX_ONLY // Force deterministic extraction for Software Elements (SWEs)

// Define success criteria and output
EXECUTE:
  OUTPUT = GRAPH_PATH, RAG_MITIGATION_REPORT

A simple parser (e.g., written in Python using a tool like textX or ANTLR) would read this script, extract the parameters, and dynamically generate the system prompt for the agent.

2. The Autonomous Red Team Agent: System Prompt

When the DSL is compiled, it initializes the LLM agent. The system prompt must tightly constrain the LLM, forcing it to act as a methodical reasoning engine rather than a creative text generator.

System Prompt:

Role: You are an autonomous Red Team security agent. Your objective is to find a valid, logical attack path through the provided enterprise infrastructure graph, starting from the ENTRY_NODE and terminating at the TARGET_NODE.
Environment: You have access to two primary tools:
query_graph(cypher_query): Executes read-only Cypher queries against the Cybersecurity Knowledge Graph (CKG).
query_rag(semantic_query): Searches the enterprise security document vector store.
Execution Directives:
Step 1: Reconnaissance: Query the CKG to identify the specific assets defined in your ENTRY_NODE constraints.
Step 2: Lateral Movement: Formulate Cypher queries to discover [COMMUNICATES_WITH], [LOGGED_INTO], or [RUNS] relationships branching from your current node. You are restricted to a maximum of 5 hops.
Step 3: Vulnerability Exploitation: When examining software running on a node, you must strictly use the provided regex tools to extract Software Elements (SWEs) and CVEs from the RAG threat intelligence feeds. Do not guess or probabilistically infer software versions.
Step 4: Verification: You may only claim a successful path if the TTPs required to traverse the nodes match your allowed list ["T1078", "T1563", "T1021"] and are not blocked by a [PROTECTED_BY] firewall edge.
Output: If a path is found, return the exact sequence of graph nodes and edges. Query the RAG tool to output the corporate mitigation policy for the specific vulnerabilities you exploited.

3. The Execution Loop (Agentic Workflow)

Once deployed, the agent operates in a continuous thought-action-observation loop (like ReAct):

Thought: "I am at a Marketing Workstation. I need to find its open ports and communicating neighbors."
Action: Calls query_graph("MATCH (n:Asset {dept: 'Marketing'})-[r:COMMUNICATES_WITH]->(m) RETURN m.ip, r.port").
Observation: The graph returns a list of IPs and ports.
Thought: "IP 10.0.5.50 is returning a response on port 22. Let me check the RAG for known vulnerabilities regarding the SSH daemon version running there."
Action: Uses regex to parse the SWE from the graph node, then calls query_rag("OpenSSH 8.9p1 vulnerabilities").

This combination turns theoretical threat modeling from a static, manual whiteboard exercise into a verifiable, executable, and automated software process.

Would you like to build out the Python parser logic to convert that DSL into the JSON configuration required to initialize the LLM agent, or map out the specific Cypher query generation tool the agent will use?

From <https://gemini.google.com/app/> Google Gemini 3.1 (Pro)

Search This Blog

Learning from ChatGPT