Domain-Specific Relationship Extraction Prompt for Cybersecurity

This prompt is built for security operations center (SOC) analysts, threat intelligence teams, and detection engineers who need to convert unstructured threat reports, blog posts, and advisories into structured, machine-readable relationship objects. The core job-to-be-done is ingesting narrative threat data—such as a vendor report describing a new malware variant targeting a specific vulnerability—and producing STIX 2.1-compatible relationship records that can be directly loaded into a SIEM, threat intelligence platform (TIP), or graph database. The ideal user understands cybersecurity entities (threat actors, malware families, CVEs, indicators of compromise) and needs consistent, auditable extraction rather than ad-hoc parsing.

Use this prompt when the input text contains identifiable cybersecurity entities and explicit or strongly implied relationships between them. For example, a sentence like 'APT29 exploited CVE-2023-23397 to deploy GooseEgg malware' contains a clear actor-target-technique chain that the prompt is designed to capture with confidence scores and source attribution. The prompt also handles Traffic Light Protocol (TLP) markings, ensuring that extracted relationships carry the appropriate sharing boundaries. However, do not use this prompt for general entity extraction without relationship context, or for reports where threat context is absent—such as generic IT documentation or policy papers. It is also unsuitable for extracting relationships from highly fragmented data like raw netflow or DNS logs, where the relationship signal requires statistical inference rather than natural language understanding.

Before deploying this prompt, ensure your pipeline validates the output against a STIX 2.1 schema, checks for hallucinated relationship types, and routes low-confidence extractions to human review. The prompt assumes the input text is in English and contains sufficient context to disambiguate entity references. For multi-document or cross-report relationship extraction, pair this prompt with an entity resolution step to normalize threat actor names and malware aliases before linking. If your use case involves regulated data or operational alerting, always require human approval before extracted relationships are committed to production knowledge graphs or automated blocking rules.

This prompt template is designed to extract structured relationship objects from cybersecurity threat reports, intelligence bulletins, and incident write-ups. It produces STIX-compatible relationship objects that link threat actors, malware, vulnerabilities, and infrastructure, with explicit TLP markings and calibrated confidence scores. The template includes domain-specific false positive patterns—such as coincidental IP co-occurrence or vendor marketing associations—that security analysts must account for when automating extraction pipelines.

textCopy
You are a cybersecurity relationship extraction system. Your task is to read the provided threat report text and extract all meaningful relationships between cybersecurity entities. Produce a JSON array of relationship objects following the schema defined below.

## INPUT
[THREAT_REPORT_TEXT]

## ENTITY TYPES TO EXTRACT RELATIONSHIPS BETWEEN
- threat-actor (APT groups, criminal groups, hacktivist collectives)
- malware (strains, families, variants, tools)
- vulnerability (CVE identifiers, exploit techniques, weakness classes)
- infrastructure (IP addresses, domains, URLs, ASNs, hosting providers)
- campaign (named intrusion sets, attack campaigns)
- sector (targeted industry verticals)

## RELATIONSHIP TYPES TO EXTRACT
- uses (actor uses malware, actor uses infrastructure)
- targets (actor targets sector, campaign targets sector)
- exploits (malware exploits vulnerability, actor exploits vulnerability)
- attributed-to (campaign attributed-to actor)
- communicates-with (malware communicates-with infrastructure)
- mitigates (patch mitigates vulnerability)
- indicates (infrastructure indicates malware, infrastructure indicates campaign)
- associated-with (actor associated-with actor, malware associated-with malware)

## OUTPUT SCHEMA
Return a JSON array of relationship objects. Each object must have these fields:
{
  "source_entity": {
    "type": "string (one of the entity types above)",
    "value": "string (the extracted entity name or identifier)",
    "source_span": "string (exact text from the report that mentions this entity)"
  },
  "target_entity": {
    "type": "string",
    "value": "string",
    "source_span": "string"
  },
  "relationship_type": "string (one of the relationship types above)",
  "confidence": "string (one of: high, medium, low)",
  "confidence_rationale": "string (brief explanation of why this confidence level was assigned)",
  "tlp": "string (one of: RED, AMBER, GREEN, WHITE, derived from the report's TLP marking or inferred from content sensitivity)",
  "evidence_snippet": "string (the exact sentence or paragraph that supports this relationship)",
  "is_historical": "boolean (true if the relationship describes past activity no longer active, false if current or ongoing)",
  "first_seen": "string or null (ISO 8601 date if mentioned, otherwise null)",
  "last_seen": "string or null (ISO 8601 date if mentioned, otherwise null)"
}

## CONFIDENCE GUIDELINES
- high: The relationship is explicitly stated in the text with clear attribution (e.g., 'APT29 used CozyBear malware')
- medium: The relationship is implied or inferred from strong contextual evidence (e.g., infrastructure patterns, tool overlap)
- low: The relationship is speculative, based on weak indicators, or mentioned with hedging language (e.g., 'possibly linked', 'may be associated')

## DOMAIN-SPECIFIC FALSE POSITIVE PATTERNS TO AVOID
Do NOT extract relationships in these cases:
1. Coincidental IP co-occurrence: Two threat actors mentioned in the same paragraph without explicit connection language.
2. Vendor marketing associations: Statements like 'Our product protects against X and Y' do not imply X is related to Y.
3. Hypothetical scenarios: Descriptions of what an actor 'could' or 'might' do without evidence they have done it.
4. Generic sector references: 'Targets the energy sector' without naming a specific campaign or actor is not a relationship.
5. Shared tooling without attribution: Multiple actors using the same open-source tool does not imply actor-to-actor association unless explicitly stated.
6. Temporal coincidence: Two events occurring in the same timeframe without causal or operational linkage.

## CONSTRAINTS
- Extract only relationships that are supported by explicit evidence in the text.
- If no relationships are found, return an empty array [].
- Do not invent entity names, CVE identifiers, or infrastructure values not present in the text.
- Preserve the original text in source_span and evidence_snippet fields exactly as written.
- If the report has a TLP marking, use it. If not, infer TLP from content sensitivity: detailed IoCs with active exploitation = AMBER, general threat descriptions = GREEN, public summaries = WHITE.
- For each relationship, include at least one evidence_snippet that directly supports the connection.
- Return ONLY the JSON array. No markdown fences, no explanatory text.

## EXAMPLES

Example 1:
Input: 'APT29 has been observed deploying WellMess malware against COVID-19 vaccine research organizations since 2020.'
Output:
[
  {
    "source_entity": {
      "type": "threat-actor",
      "value": "APT29",
      "source_span": "APT29"
    },
    "target_entity": {
      "type": "malware",
      "value": "WellMess",
      "source_span": "WellMess malware"
    },
    "relationship_type": "uses",
    "confidence": "high",
    "confidence_rationale": "Explicitly stated with direct attribution and observed activity.",
    "tlp": "AMBER",
    "evidence_snippet": "APT29 has been observed deploying WellMess malware against COVID-19 vaccine research organizations since 2020.",
    "is_historical": false,
    "first_seen": "2020-01-01",
    "last_seen": null
  },
  {
    "source_entity": {
      "type": "threat-actor",
      "value": "APT29",
      "source_span": "APT29"
    },
    "target_entity": {
      "type": "sector",
      "value": "COVID-19 vaccine research",
      "source_span": "COVID-19 vaccine research organizations"
    },
    "relationship_type": "targets",
    "confidence": "high",
    "confidence_rationale": "Explicitly stated targeting with observed deployment activity.",
    "tlp": "AMBER",
    "evidence_snippet": "APT29 has been observed deploying WellMess malware against COVID-19 vaccine research organizations since 2020.",
    "is_historical": false,
    "first_seen": "2020-01-01",
    "last_seen": null
  }
]

Example 2:
Input: 'Multiple threat groups including APT41 and Winnti Group have targeted the telecommunications sector. Our security suite protects against both.'
Output:
[
  {
    "source_entity": {
      "type": "threat-actor",
      "value": "APT41",
      "source_span": "APT41"
    },
    "target_entity": {
      "type": "sector",
      "value": "telecommunications",
      "source_span": "telecommunications sector"
    },
    "relationship_type": "targets",
    "confidence": "medium",
    "confidence_rationale": "Targeting stated but without specific campaign or incident details.",
    "tlp": "GREEN",
    "evidence_snippet": "Multiple threat groups including APT41 and Winnti Group have targeted the telecommunications sector.",
    "is_historical": false,
    "first_seen": null,
    "last_seen": null
  },
  {
    "source_entity": {
      "type": "threat-actor",
      "value": "Winnti Group",
      "source_span": "Winnti Group"
    },
    "target_entity": {
      "type": "sector",
      "value": "telecommunications",
      "source_span": "telecommunications sector"
    },
    "relationship_type": "targets",
    "confidence": "medium",
    "confidence_rationale": "Targeting stated but without specific campaign or incident details.",
    "tlp": "GREEN",
    "evidence_snippet": "Multiple threat groups including APT41 and Winnti Group have targeted the telecommunications sector.",
    "is_historical": false,
    "first_seen": null,
    "last_seen": null
  }
]
// Note: No actor-to-actor relationship extracted because the vendor marketing statement 'Our security suite protects against both' is a false positive pattern.

To adapt this template, replace [THREAT_REPORT_TEXT] with the actual report content. If your target graph database or SIEM requires a different schema, modify the OUTPUT SCHEMA fields while preserving the confidence rationale and evidence snippet requirements—these are critical for auditability. For production pipelines, add a post-extraction validation step that checks every relationship against the false positive patterns list using a secondary classifier or rule-based filter. When processing reports with mixed TLP markings, extract the highest applicable marking per relationship rather than applying a single document-wide TLP. Always log extraction failures and empty arrays separately so you can distinguish between reports with no relationships and extraction errors.

This prompt is designed to be called from an application layer, not used as a standalone chat. The typical integration pattern is: fetch a threat report or intelligence document, inject it into the [SOURCE_TEXT] placeholder along with the [TARGET_ONTOLOGY] and [TLP_MARKING] parameters, call the model, validate the output against the expected STIX-compatible relationship schema, and route low-confidence or malformed results to a human review queue. The application should own document chunking if the source exceeds the model's context window—split by section or paragraph, extract relationships per chunk, and deduplicate in post-processing using the source_span and relationship_id fields.

Validation and retry logic is critical because cybersecurity workflows cannot tolerate hallucinated threat actor associations or missing infrastructure links. After the model returns, validate that every relationship object contains required fields: source_ref, target_ref, relationship_type, confidence, source_span, and tlp. Check that relationship_type values match the allowed taxonomy from [TARGET_ONTOLOGY]—unexpected types should trigger a retry with the error message injected into [PREVIOUS_ERRORS]. Set a maximum of two retries before routing to human review. For confidence thresholds, route any relationship with confidence below 0.7 to a review queue, and flag any batch where more than 20% of relationships fall below threshold as a potential document quality or prompt mismatch issue. Log every extraction attempt with the model version, prompt hash, source document identifier, and validation outcome for auditability.

Model choice and tool integration depend on your deployment constraints. For classified or air-gapped environments, use an on-premises model with strong instruction-following and JSON mode support. For unclassified threat intelligence, GPT-4o or Claude 3.5 Sonnet with structured outputs enabled provide reliable schema adherence. If your pipeline ingests STIX bundles directly, wire the validated relationship objects into a STIX 2.1 bundle generator—do not ask the model to produce the full bundle wrapper, only the relationship objects. For graph database ingestion, transform the validated relationships into Cypher MERGE statements in the application layer, using the source_ref and target_ref as lookup keys against existing node identifiers. Never pass raw model output directly to a graph write operation without schema validation and duplicate detection.

Common failure modes to instrument for: the model may extract relationships from hypothetical or historical examples embedded in the threat report rather than from the report's primary narrative—watch for relationships where source_span points to a background or example section. The model may also over-extract by linking every mentioned entity pair, producing a dense graph with low-confidence noise edges. Mitigate this by including explicit negative examples in [FEW_SHOT_EXAMPLES] that show when NOT to extract a relationship. Finally, monitor for taxonomy drift where new threat actor aliases or malware families appear that don't map to your [TARGET_ONTOLOGY]—log unmapped values and feed them into your ontology update process rather than forcing the model to guess a mapping. The application should emit metrics on extraction volume, confidence distribution, validation failure rate, and review queue depth to detect degradation early.