Custom Protective Threat Feed

Deliverable OSINT-054. Structure per cc02-standards/SYSTEM-STANDARD.md. Every component traces to a design basis (NEED/REQ) and to an acceptance criterion.

1. Purpose and Design Basis

1.1 Scope and Objective

The Custom Protective Threat Feed (v2) is a client-tailored real-time ingestion and threat alerting service. It consumes threat indicators and target parameters generated by OSINT-051 (Protective Intelligence Assessment) to monitor public and open-source data streams for indications of targeted activity, harassment, or physical compromise directed at a specific client or asset set.

1.2 Design Basis

This system replaces generic threat feeds with a client-specific parsing model. It ingests, parses, and scores threats deterministically using a localized client-lexicon and proximity rules, sending alert payloads off-hot-path.

1.3 Needs

  • NEED-OSINT-054-01: Team Leader (RF) requires client-tailored real-time alerting of direct threat indicators to trigger executive protective actions.
    • Source: RF (CEO/TL) operational warning concern.
    • Context: Standard generic threat streams do not capture specific client-targeted keywords or local residence proximity vectors, leading to false negatives.
  • NEED-OSINT-054-02: Systems Engineer (CS) requires strict isolation of client-specific monitoring profiles to prevent accidental disclosure of the client identity or home addresses.
    • Source: CS (Systems Engineer) security configuration plan.
    • Context: A centralized monitoring list that aggregates all clients is a high-value target for exfiltration.

1.4 Requirements

  • REQ-OSINT-054-01 (Traceability: NEED-OSINT-054-01): The threat feed shall ingest RSS and social media feeds, parsing matching client-targeted terms within 500 milliseconds [VR-OSINT-054-01].
    • Verification Method: Test (T)
  • REQ-OSINT-054-02 (Traceability: NEED-OSINT-054-01): The threat feed shall compute Likelihood and Impact scores based on the client-specific proximity model within 100 milliseconds [VR-OSINT-054-02].
    • Verification Method: Analysis (A)
  • REQ-OSINT-054-03 (Traceability: NEED-OSINT-054-02): The client-specific monitoring lexicon and coordinate profiles shall be stored in cryptographically sealed configurations decrypted only at runtime [VR-OSINT-054-03].
    • Verification Method: Inspection (I)

2. Architecture As Built

The Custom Protective Threat Feed is a client-confidential threat parsing service. It monitors open-source and proprietary feeds (RSS, emergency dispatch logs, local news) for threats directly targeting the client’s assets and locations, as specified by OSINT-051 profiles. All client identifiers and coordinates are stored in GPG-encrypted files on disk; the decryption wrapper decrypts these variables into memory at service start, and the regular expression term matcher performs the lexicon match and proximity scoring.

Data flow:

  1. The ingestion daemon polls the configured RSS and news feeds.
  2. At startup, the GPG decryption wrapper decrypts the client-specific lexicons and geofences into RAM only.
  3. The token matcher engine parses incoming feed text against the decrypted client threat keywords and venue coordinates.
  4. The scoring module calculates the Likelihood and Impact scores based on proximity and threat category.
  5. When the composite score triggers an alert, the feed produces a structured JSON alert payload.
+-------------------------------------------------------------------------+
| OSINT-054 Custom Protective Threat Feed                                 |
|                                                                         |
|  Feeds ---> Ingestion ---> GPG Decryptor ---> Lexicon Matcher ---> Out  |
|                               ^ (Lexicon)                               |
+-------------------------------------------------------------------------+

3. Components and Bill of Materials

ComponentSpecVendor / LinkPriceTierStatusTraceability
Ingestion DaemonPython 3.12 service with feedparser and requestsInternal$0.00-SELECTEDREQ-OSINT-054-01
Client GazetteerJSON-formatted location and client-lexicon matrixInternal$0.00-SELECTEDREQ-OSINT-054-02
Token Matcher EngineRegular expression string parsing engineOS$0.00-SELECTEDREQ-OSINT-054-01
Decryption WrapperGPG-based configuration decrypter moduleOS$0.00-SELECTEDREQ-OSINT-054-03

4. Build and Deployment

4.1 Daemon Setup

  1. Deploy the ingestion script on the secure C2 host.
  2. Establish configuration variable mappings in the /etc/default/client-threat-feed file.

4.2 Key Configuration

  1. Import the client’s GPG public key utilized for decrypter configuration validation.
  2. Verify that local geofence boundary files match the coordinates defined in OSINT-051.
  3. Encrypt the coordinate and lexicon mapping files using GPG: gpg --encrypt --recipient "sc-client-key" config/client_lexicon.json.
  4. Start the service using systemd: systemctl daemon-reload && systemctl enable --now client-threat-feed.

5. Hardening Baseline

  • User Restraints: Run the ingestion daemon under a dedicated, unprivileged system user sc-client-alerter.
  • Config Lockdown: Restrict coordinate configuration file permissions to read-only for the service owner (chmod 0400).
  • Memory Isolation: Store decrypted configuration lexicons in system memory variables, wiping them instantly on process exit [REQ-OSINT-054-03].

6. Integration Points

InterfaceTypeDirectionContract
Ingest ProfilesFile (Markdown)ConsumedPulls client target profiles and proximity coordinates from OSINT-051
Alert OutputAPI (JSON)ProducedPublishes structured JSON alerts containing the client bluf summary

7. Acceptance Tests

CriterionMethodExpected ResultReference
REQ-OSINT-054-01TestParse sample feed payload and identify client terms within 500 milliseconds.VR-OSINT-054-01
REQ-OSINT-054-02AnalysisVerify proximity tier scoring math yields correct risk values within 100 milliseconds.VR-OSINT-054-02
REQ-OSINT-054-03InspectionConfirm configuration file containing coordinates is encrypted on disk and decrypted only in RAM.VR-OSINT-054-03

8. Run and Maintenance Handover

  • Console Start: Start service via systemctl restart client-threat-feed.
  • Maintenance Schedule: Update GPG keys and client geofences monthly.
  • Ownership: Systems Engineer (CS).

Annex A: Severity Matrix Mapping

The Likelihood (1-5) and Impact (1-5) values are calculated using client geofences and threat categories:

  • Likelihood (1-5): Determined by proximity to client locations:
    • Inside client primary residence/workplace geofence 5
    • Within 500 meters of client venue 4
    • Within 2 kilometers of client venue 3
    • Inside client municipality or transit corridor 2
    • Outside client operational area 1
  • Impact (1-5): Determined by threat keyword severity:
    • Critical (Direct physical threat, active shooter, bombing) 5
    • High (Arson, localized protest, building fire) 3
    • Low (General civic disruption, road closure) 1

Annex B: Incident JSON Schema Contract

Alert schema sent by the feed processor:

{
  "client_id": "CLI-####",
  "incident_id": "INC-YYYYMMDD-###",
  "timestamp": "ISO-8601-TIMESTAMP",
  "matched_term": "string",
  "matched_location": "string",
  "likelihood": 1..5,
  "impact": 1..5,
  "composite_score": 1..25,
  "bluf_summary": "string"
}

END OF SYSTEM

Model wiring

Generated from cell frontmatter at publish time.