# SG/Sentinel: Learning From Standards, Open Source, And Threat-Intelligence Services

**version** v0.27.58
**date** 18 May 2026
**from** Human (project lead)
**to** Architect, Developer (lead), Security, AppSec, @Dev
**type** Research brief

---

## What This Is

The tenth brief in the SG/Sentinel series, and the one the voice memo explicitly asked to ground in research: **what can we learn from, reuse from, and become compatible with, so we do not reinvent the wheel?** The voice memo named the mission clearly: there is already a great deal of excellent standards, concepts, schemas, and platforms (MITRE ATT&CK, OWASP, and others), and the question is what to leverage, what to learn from, what to become compatible with, and eventually what to contribute back.

The brief covers three areas the voice memo named:

1. **What standards to become compatible with** (MITRE ATT&CK, OWASP CRS, SecLang, threat-intel formats)
2. **What to reuse and learn from open source** (Coraza, the OWASP Core Rule Set, existing detection code)
3. **What third-party threat-intelligence services to integrate** (IP reputation and context services, free and paid)

The voice memo also drew an important boundary: **malware and file-hash checking is not possible at the Sentinel layers**, because the zero-knowledge architecture means Sentinel never has access to file contents (it would need decryption keys it does not hold). So this brief excludes content-scanning approaches and focuses on what Sentinel can actually do: traffic-level, IP-level, and request-level intelligence.

This is research-grounded; the findings below come from current sources and are flagged where they bear on our design.

## The Guiding Principle: Compatibility Over Reinvention

The voice memo's framing is the right one: **the more compatible we are with established standards, the better the platform, because we inherit decades of community work rather than rebuilding it.** And the relationship can be reciprocal: **eventually we contribute back, showing the power of what these communities have built.**

This connects directly to the de-commoditising article from yesterday. The standards (MITRE ATT&CK, OWASP CRS) are the commodity layer: mature, community-maintained, free. SG/Sentinel is the custom shield on top. **We do not rebuild the commodity; we become compatible with it and build our differentiated value (the app-coupling, the LLM interpretation, the edge-everywhere, the developer-friendliness) on top.**

## Area 1: Standards To Become Compatible With

### MITRE ATT&CK

MITRE ATT&CK is the living knowledge base of adversary tactics, techniques, and procedures (TTPs), regularly updated from real-world observations. It is the cleanest mental model for how attackers operate, and it is the lingua franca of detection engineering.

For SG/Sentinel, the key technique is **T1190 (Exploit Public-Facing Application)**, which MITRE defines as exploiting a weakness in an internet-facing host to gain initial access. This is precisely the threat Sentinel sits in front of. The recommended approach from current practice: map exploitation to T1190, then map likely follow-on behaviour chains (execution, persistence, credential access, discovery, lateral movement, exfiltration, impact). This turns isolated detections into a durable detection plan.

How SG/Sentinel becomes compatible:

- **Tag rules with ATT&CK technique IDs.** Every Sentinel rule that detects an adversary behaviour should carry the relevant ATT&CK technique ID (e.g. T1190). This makes Sentinel's detections speak the standard language.
- **Map the evidence graph to ATT&CK.** The evidence graph (from the developer-friendliness brief) should map observed behaviours to ATT&CK techniques, so the evidence is expressed in the standard taxonomy.
- **Express detection coverage in ATT&CK terms.** We can describe what Sentinel detects as a coverage map over ATT&CK, which is how the whole industry describes detection coverage.

The important nuance from current sources: **OWASP describes what is vulnerable; MITRE ATT&CK describes how adversaries operate; the mapping is many-to-many, not one-to-one.** Sentinel benefits from both: OWASP for the vulnerability classes, ATT&CK for the adversary behaviours. They are two sides of the same coin (prevent what you can, detect what you cannot).

### OWASP Core Rule Set (CRS) And SecLang

The OWASP Core Rule Set is the enterprise-grade, community-maintained set of attack-detection rules, now at v4. It protects against the OWASP Top Ten and a wide range of attack categories: **SQL injection, cross-site scripting, PHP and Java code injection, HTTPoxy, Shellshock, and scanner/bot detection.** It uses paranoia levels to tune aggressiveness.

The rules are written in **SecLang** (the ModSecurity rule language), which is the de facto standard rule language for WAFs. This matters for SG/Sentinel because:

- **SecLang is a standard rule format.** If Sentinel can understand or import SecLang rules, it inherits the entire CRS rule library and the broader SecLang ecosystem.
- **CRS is the reference rule set.** Even if Sentinel's native rule format is different (our rules-are-everything model with strong schemas), being able to ingest or map CRS rules gives us a battle-tested baseline.
- **Paranoia levels are a proven tuning model.** The CRS paranoia-level concept (tune aggressiveness in steps) maps onto our progressive-lock-down model from the delegation brief.

Recommendation: **Sentinel should be able to consume CRS rules (via SecLang compatibility) as a baseline layer, while our native rules add the app-coupled, LLM-interpreted, edge-deployed differentiation on top.** The CRS handles the generic, well-understood attacks; our rules handle what only an app-coupled system can.

### Threat-Intelligence Formats: STIX/TAXII

For consuming threat intelligence, the standard is **STIX/TAXII** (the format MITRE ATT&CK and many feeds use). The MITRE ATT&CK data itself is available as a STIX/TAXII feed. Becoming STIX/TAXII-compatible means Sentinel can consume any threat-intel feed that speaks the standard, not just specific vendors.

### SBOM (Noted, With A Caveat)

The voice memo mentioned SBOM (Software Bill of Materials) and immediately noted it is probably not the best example here. That instinct is correct: SBOM is about software supply-chain composition, not runtime traffic security, so it is tangential to Sentinel's edge role. It matters for the broader platform's supply-chain security (and connects to MITRE's System of Trust supply-chain framework), but it is not a Sentinel-layer concern. Noted and set aside.

## Area 2: Open Source To Reuse And Learn From

### Coraza: The Reference Engine To Learn From

The most important open-source finding: **OWASP Coraza** is a next-generation WAF written in Go, fully ModSecurity-compatible, and 100% compatible with the OWASP Core Rule Set v4. It is the OWASP-blessed successor to ModSecurity (which moved under the OWASP umbrella in early 2024 and whose Trustwave-supported engine reached end-of-life in 2024). Coraza is a **library at its core, with many integrations**, and is explicitly extensible (custom audit loggers, persistence engines, operators, actions).

Why Coraza matters for SG/Sentinel:

- **It is the reference architecture for a modern, memory-safe, library-first WAF.** Even where we do not use Coraza directly, its design (library-at-core, extensible operators and actions, SecLang compatibility) is the model to learn from.
- **It is Go, memory-safe, high-performance.** This is directly relevant to the language question from the MVP and delegation briefs (Python preferred for same-code, but Go/Rust acceptable for performance). Coraza is proof that Go is a strong choice for the performance-critical layers.
- **It is a library, not a monolith.** This matches our rules-are-everything, tiny-core-engine model. Coraza's library-first design validates our architectural direction.
- **It is extensible by design.** The ability to add custom operators, actions, and persistence engines is exactly the extensibility our rules engine needs.

Recommendation: **study Coraza's architecture closely as the reference for a library-first, SecLang-compatible WAF engine.** Consider whether Sentinel's deterministic Layer 1/2 rules could use Coraza (or a Coraza-derived component) as the engine for CRS-compatible rules, with our native rules engine handling the app-coupled and LLM-interpreted layers on top. This would give us CRS compatibility almost for free while preserving our differentiation.

Note also **kubeWAF** (Kubernetes-native ModSecurity + CRS, stable release expected Q2 2026) as a reference for the deploy-as-sidecar, per-workload-protection pattern, which is relevant to our substrate-independence and isolated-deployment goals.

### The OWASP Core Rule Set As The Rule Reference

Beyond the engine, the CRS itself is the reference rule library. Even if we do not run it verbatim, it is the catalogue of what generic WAF protection looks like: the attack categories, the detection patterns, the paranoia-level tuning. **Our rule development (LLM-assisted, per the rules-engine brief) should start from the CRS as a reference for what attacks to cover, then add the app-coupled rules CRS cannot express because it does not know our application.**

### Existing Detection Code

The voice memo noted there are already models and code (Python and Node) that do specific detection. The research confirms this: there is a rich ecosystem of detection logic, much of it open source. The lift-and-shift principle from the MVP brief applies: **reuse existing detection code where it fits, rather than rewriting it.** The AppSec mini-tools direction (StrideGPT and similar) from earlier in the week is part of this ecosystem.

## Area 3: Third-Party Threat-Intelligence Services

The voice memo asked specifically what third-party services (free and paid) we can use to validate and contextualise traffic, naming IP data as one example. The research surfaces a clear landscape, and importantly, a critical caveat about IP reputation that shapes how we should use these.

### The Critical Caveat: IP Reputation Is No Longer Sufficient Alone

A significant finding from current research: **IP reputation as a primary defence is increasingly broken.** GreyNoise's April 2026 report (based on 4 billion malicious sessions) found that nearly 4 in 10 attacking IPs are now residential or compromised home connections, used as proxies. The industry assumption that you can determine intent from an IP address is, in their words, broken at scale.

This is important for SG/Sentinel's design: **IP reputation is useful context, not a verdict.** It feeds the evidence graph and informs decisions, but it cannot be the sole basis for blocking. This actually validates our architecture: because Sentinel knows what good traffic looks like (the coupling principle) and detects out-of-profile behaviour (the detect-before-damage principle), it does not rely on IP reputation as the primary signal. IP intelligence is one input to the evidence graph, weighted appropriately, not the decision itself.

### The Service Landscape

The current threat-intelligence service landscape, organised by what they offer:

| Service | What It Provides | Model | Fit For Sentinel |
|---------|------------------|-------|------------------|
| **AbuseIPDB** | Community-reported IP abuse with confidence scoring | Free (1,000/day), $5-150/mo | Cheap IP reputation context for the evidence graph |
| **GreyNoise** | Internet-wide scan classification; distinguishes mass-scanning from targeted | Paid | Filter internet background noise; identify scanners |
| **Shodan** | Internet-wide device/service discovery | Paid | Context on what an IP exposes |
| **VirusTotal** | Multi-source reputation (Google) | Free tier + paid | Broad reputation context |
| **AlienVault OTX** | Community threat pulses with MITRE ATT&CK mappings | Free | ATT&CK-mapped IOCs; aligns with our ATT&CK compatibility |
| **Spamhaus DROP/EDROP** | Networks controlled by threat actors | Free feeds | Block known-bad networks |
| **Cisco Talos** | Aggregated global attack patterns | Free checks | Cross-reference context |
| **Real-time risk scoring (IPQualityScore, MaxMind minFraud, IPinfo)** | Millisecond risk scores during live interactions (proxy detection, geo consistency) | Paid | Fast risk scoring for the near-real-time timeline |
| **Aggregators (isMalicious and similar)** | 500+ sources in one call, LLM-generated summaries, auto MITRE mapping | Paid | One-call enrichment; aligns with our LLM and ATT&CK direction |
| **abuse.ch (ThreatFox, URLhaus)** | IOC feeds for malware/abuse | Free | Feed input to the evidence graph |

### How These Fit The Timeline Model

Crucially, these services map onto the multiple-timelines model from the time brief. The key insight: **threat-intel lookups are mostly not inline.** They run on the near-real-time and analytical timelines (async, out-of-band), feeding the evidence graph, not blocking inline.

| Timeline | Threat-Intel Usage |
|----------|--------------------|
| Immediate (Layer 1) | Pre-loaded banned-IP lists only (embedded data; no live lookup) |
| Real-time-plus (Layer 2) | Fast cached reputation; millisecond risk scores if budget allows |
| Near-real-time (Layer 3 async) | Live lookups (AbuseIPDB, GreyNoise, etc.); feed the evidence graph |
| Analytical (Layer 3 LLM) | Aggregator enrichment with LLM summaries; ATT&CK mapping |

This fits detect-before-damage perfectly. The expensive threat-intel enrichment happens async, building the evidence graph over the detection window, not blocking the request inline. **Sentinel can afford rich threat intelligence precisely because it does not need it inline.**

### A Reference Implementation Pattern

Worth noting: the Anthropic Claude Cookbook includes a **threat-intelligence-enrichment-agent** example that demonstrates exactly this pattern: an agent that enriches IPs, domains, and indicators from reputation sources and maps them to MITRE ATT&CK. This is a direct reference for our Layer 3 LLM analysis: the agent enriches an indicator from threat-intel sources, maps it to ATT&CK, and produces structured evidence. **This is a near-exact template for our async evidence-building agents.**

The cookbook also confirms our exclusion: it separates IP reputation (AbuseIPDB, GreyNoise, Shodan) from file-hash lookup (VirusTotal, MalwareBazaar). The file-hash side is the part the voice memo correctly excluded for Sentinel: **we cannot do file-hash or malware checking because zero-knowledge means we never have the file contents.** We use the IP/domain/indicator side, not the file side.

## What We Can And Cannot Do (The Zero-Knowledge Boundary)

The voice memo drew the boundary explicitly and correctly. To restate it as a design constraint:

| Capability | Possible At Sentinel? | Why |
|------------|----------------------|-----|
| IP reputation and context | Yes | Sentinel sees the source IP |
| Request pattern analysis | Yes | Sentinel sees the request metadata |
| Behavioural / sequence analysis | Yes | Sentinel sees the traffic flow |
| ATT&CK technique mapping | Yes | Based on observed behaviour |
| Bot / scanner detection | Yes | Based on traffic patterns |
| Malware file scanning | No | Zero-knowledge; no file contents |
| File-hash reputation | No | Sentinel never has the file |
| Content inspection | No | Content is encrypted; no keys |

This boundary is not a limitation to apologise for; it is a consequence of the zero-knowledge architecture that is a core platform value. Sentinel does traffic, IP, and behavioural intelligence, which is exactly what an edge security layer should do. Content security is handled differently (by the application, with the keys), not at the edge.

## The Contribute-Back Opportunity

The voice memo named the reciprocal opportunity: **eventually contribute back to these communities, showing the power of what they have built.** This is worth holding as a direction:

- **CRS-compatible app-coupled rules.** If we develop a way to express app-coupled rules in a SecLang-compatible form, that could be a contribution.
- **The LLM-interpretation pattern.** Our approach to using LLMs out-of-band to generate and refine rules (never inline) is a pattern the WAF community is actively exploring; we could contribute our learnings.
- **The evidence-graph-to-ATT&CK mapping.** Our semantic evidence graph mapped to ATT&CK could be a useful open contribution.
- **The Coraza community needs contributors.** The research notes Coraza actively wants community contributors; if we build on it, contributing back is natural.

Contributing back is not just goodwill; it is the de-commoditising strategy in reverse. By contributing our differentiation patterns to the commodity layer where they are not our moat, we strengthen the ecosystem we depend on while keeping our actual moat (the integrated platform, the app-coupling, the developer experience) proprietary.

## What This Asks For

Concrete next steps:

1. **Adopt MITRE ATT&CK technique tagging** for all detection rules (starting with T1190 and its follow-on chains).
2. **Map the evidence graph to ATT&CK** techniques.
3. **Evaluate Coraza** as the engine (or reference architecture) for CRS-compatible deterministic rules.
4. **Assess SecLang compatibility** so Sentinel can ingest CRS rules as a baseline.
5. **Adopt STIX/TAXII** for consuming threat-intel feeds.
6. **Integrate threat-intel services on the async timelines** (AbuseIPDB and GreyNoise first; aggregator later), feeding the evidence graph, never inline.
7. **Treat IP reputation as context, not verdict** (per the GreyNoise residential-proxy finding).
8. **Use the Claude Cookbook threat-intel-enrichment-agent** as the template for the Layer 3 evidence-building agent.
9. **Hold the zero-knowledge boundary** (no file-hash or malware scanning; traffic/IP/behaviour only).
10. **Plan contribute-back** (CRS-compatible patterns, LLM-interpretation learnings, ATT&CK mappings, Coraza contributions).

Estimated effort: the research is done; the integration is incremental, layered onto the rules engine and evidence graph. ATT&CK tagging and the first threat-intel integration are near-term; Coraza/SecLang evaluation is a focused spike; contribute-back is ongoing.

## What This Does Not Try To Be

Deliberate scope limits:

- **Not a rebuild of CRS or Coraza.** We become compatible with and reuse them; we do not rebuild them.
- **Not IP-reputation-as-verdict.** IP intelligence is context for the evidence graph, not a blocking decision.
- **Not file/malware scanning.** Excluded by the zero-knowledge boundary.
- **Not inline threat-intel lookups.** Threat intel runs async, on the near-real-time and analytical timelines.
- **Not a commitment to specific paid services yet.** The landscape is mapped; specific choices follow evaluation.

## Honest Risks

Three risks:

**Risk 1: Standards compatibility could constrain our differentiation.** If we bend our design to fit CRS/SecLang, we might lose the app-coupling advantage. Mitigation: compatibility is a baseline layer, not the whole; our native rules (app-coupled, LLM-interpreted) sit on top and are not constrained by SecLang.

**Risk 2: Threat-intel services add cost and dependency.** Paid services and external dependencies have cost and reliability implications. Mitigation: async usage means failures degrade gracefully (no inline dependency); start with free tiers (AbuseIPDB, OTX, Spamhaus); add paid services only where the value is proven.

**Risk 3: Over-reliance on external threat intel could import their false positives.** The residential-proxy finding shows external reputation can be wrong. Mitigation: external intel is weighted context in the evidence graph, never the sole signal; our own knowledge of good traffic (the coupling) is the primary signal.

## Open Questions

| Question | Notes |
|----------|-------|
| Use Coraza directly, or learn from it and build our own? | Evaluate; possibly Coraza for CRS-compatible rules, native engine for the rest |
| Native rule format, SecLang, or both? | Probably native with SecLang ingestion for CRS baseline |
| Which threat-intel services first? | Free tiers first (AbuseIPDB, OTX, Spamhaus); GreyNoise for scanner filtering |
| How is external intel weighted in the evidence graph? | Context, not verdict; weight low; combine with our own signals |
| STIX/TAXII consumer: build or library? | Use an existing library if good ones exist |
| How much CRS to adopt as baseline? | The well-understood attack categories; paranoia-level tuning maps to progressive lock-down |
| When to start contributing back? | Once our patterns are proven; Coraza community is open now |
| ATT&CK coverage map: how to maintain? | Tag rules; generate the coverage map from the tags |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__arch-brief__sg-sentinel-developer-friendliness-and-evidence-graph.md` | The evidence graph that threat intel and ATT&CK mapping feed |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-time-as-first-class-dimension.md` | The timelines threat-intel lookups run on (async, not inline) |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-engine.md` | The rules that get ATT&CK tags and CRS-compatible baselines |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-delegation-and-choke-points.md` | Progressive lock-down maps to CRS paranoia levels |
| 18 May | `v0.27.58__dev-brief__edge-layer-mvp-visibility-blocking-deployment.md` | The lift-and-shift principle for reusing detection code |
| 18 May | `v0.27.58__arch-brief__edge-security-and-logging-layer-principles.md` | The de-commoditising frame: standards are commodity, our shield is custom |
| 17 May | `v0.27.55__article__de-commoditising-the-commodity.md` | The build-the-shield-on-the-commodity strategy applied to standards |
| 17 May | `v0.27.55__strategy-brief__myfeeds-b2b-research-briefings-as-evidence-packs.md` | The semantic-graph pattern the evidence graph and ATT&CK mapping use |
| 16 May | `v0.27.45__dev-brief__nova-and-agentcore-poc-fastapi.md` | Nova for the threat-intel enrichment agent |
| 16 May | `v0.27.45__strategy-brief__appsec-mini-tools-on-top-of-vaults.md` | StrideGPT and the AppSec tooling ecosystem to reuse |

---

## Acceptance Criteria

| # | Criterion | Verification |
|---|-----------|-------------|
| 1 | Detection rules carry MITRE ATT&CK technique tags | Rules tagged; coverage map exists |
| 2 | The evidence graph maps behaviours to ATT&CK | Mapping works |
| 3 | Coraza is evaluated as engine or reference | Decision documented |
| 4 | SecLang / CRS compatibility is assessed | CRS-baseline path defined |
| 5 | STIX/TAXII consumption is supported | Feeds consumable |
| 6 | At least two threat-intel services integrated on async timelines | AbuseIPDB + one more, feeding the graph |
| 7 | IP reputation is treated as context, not verdict | Weighted in the graph; not sole signal |
| 8 | The Claude Cookbook enrichment-agent pattern is adopted for Layer 3 | Agent enriches and maps to ATT&CK |
| 9 | The zero-knowledge boundary is held (no file/malware scanning) | Excluded by design |
| 10 | A contribute-back plan exists | Direction documented |

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).