TL;DR
- Treat ADD/SDD documents as a structured log-source discovery instrument, not background reading: systematically extract components, data flows, trust boundaries, integrations, and auth mechanisms, map each to its log-generating capability, then cross-reference against CMDB/asset inventory and network telemetry to close the gap between “designed” and “actually emitting.” No single source is complete — ADD/SDD tells you what should exist, CMDB/scanning tells you what does.
- Prioritize with an explicit, weighted, risk-driven model built from real frameworks — MITRE Crown Jewels Analysis (criticality), MITRE ATT&CK v18 Detection Strategies/Analytics (threat/detection value), the Five Eyes “Priority Logs for SIEM Ingestion” guidance (categorical starting order), and the MaGMa Use Case Framework (business/threat/implementation traceability and coverage scoring). Ingest the smallest set of logs that earns its place; the “ingest everything, find a use case later” pattern creates a costly “data graveyard.”
- Onboarding is a full discipline, not an ingestion event: validate schema, normalize to CIM/OCSF/CEF, estimate volume/EPS, tier for cost, wire each source to at least one detection use case and response action, and validate coverage against ATT&CK — then treat parser drift and format changes as standing operational risk.
Key Findings
1. ADD/SDD documents are rich, underused log-source catalogs. Architecture Design Documents and Solution/System Design Documents contain, in predictable sections, nearly everything a detection engineer needs to enumerate candidate log sources: component decomposition, deployment topology, technology stack (with versions), integration/interface tables, data flow diagrams, security architecture (authN/authZ flows), and data architecture (stores, schemas, authoritative data sources). Standard templates (e.g., the C4 model’s Context/Container/Component views, the HUD Agile Architecture/System Design template, and common SAD templates) expose these as named sections you can mine directly.
2. The strongest discovery method is triangulation. ADD/SDD gives you the intended design; a CMDB/asset inventory gives you managed reality; active/passive network discovery finds shadow assets. First-time discovery scans routinely find asset counts far above manual inventories, so design docs alone will always undercount. Overlaying all three, then mapping to MITRE ATT&CK data components, produces a defensible “visibility gap analysis.”
3. Prioritization frameworks exist and should be cited, not invented. The most authoritative, recent, and directly-on-point publication is the Five Eyes agencies’ Priority Logs for SIEM Ingestion: Practitioner Guidance, published 27 May 2025 as one of three joint cybersecurity information sheets led by NSA with ASD’s ACSC and partner agencies. It gives an explicit categorical prioritization order and per-source event detail. This complements MITRE Crown Jewels Analysis, MITRE ATT&CK (v18, released Oct 28 2025), NIST SP 800-92, the MaGMa UCF, DeTT&CT, and vendor guidance from Splunk and Microsoft.
4. MITRE ATT&CK changed materially in October 2025. ATT&CK v18 retired the old “Data Sources” detection model and replaced it with Detection Strategies (DETxxxx) and Analytics (ANxxxx), while keeping and refining Data Components and adding Log Sources references to analytics. Per MITRE’s official “Updates – October 2025,” Enterprise v18 now contains 216 Techniques, 475 Sub-Techniques, 691 Detection Strategies, 1,739 Analytics, and 106 Data Components (with Data Sources deprecated), and adds 12 new techniques. Coverage/gap analysis workflows built on the old data-source mapping still work conceptually, but new work should map log sources → data components → analytics → techniques.
5. Onboarding maturity models are published and usable off the shelf. Splunk’s Security Data Journey / S2M2 and its Lantern “onboarding useable and purposeful security data” 5-step workflow, plus the MaGMa capability/maturity model (mapped to CMMI’s five levels), give ready-made maturity ladders and workflow checklists.
Details
Part A — What to extract from ADD and SDD documents
An ADD typically operates at the enterprise/solution architecture level (how systems, zones, and platforms fit together); an SDD (also called Solution/System Design or Software Architecture Document, SAD) operates at the build level (components, interfaces, schemas, deployment). For log-source discovery, mine these sections in order of yield:
- Component decomposition / logical & physical views (C4 Container and Component diagrams). Each container is annotated with its technology and communication protocol (e.g., “Go binary,” “PostgreSQL 15,” “Redis 7,” ports/protocols). Every named container is a candidate log producer: application logs, access logs, audit logs.
- Deployment / infrastructure architecture. Per-environment topology (dev/test/staging/prod) tells you where logs originate, whether a source is internet-facing, and how many instances exist (critical for volume estimation). Note environment because production internet-facing tiers get priority.
- Technology stack table (layer → technology → version). Maps directly to which log format/parser you’ll need and whether a vendor add-on/TA exists.
- Integration architecture / external systems table. Systems, protocols, purpose, SLA; integration patterns (REST/gRPC API, event-driven, legacy). Each integration point is both a log source (API gateway, message bus) and a trust boundary worth monitoring.
- API surface tables (REST/gRPC/SDK/MCP/CLI). API gateways, WAFs, and app-tier logs sit here.
- Security architecture. Authentication flow (often a sequence diagram), authorization/RBAC model, secrets management, data protection (at-rest/in-transit, PII). This tells you the identity providers (Entra ID, Okta), the auth events to capture (SAML/OAuth success/failure), and where privileged actions occur.
- Data architecture / Data Flow Diagrams (DFDs). DFDs show external entities, processes, data stores, data flows, and trust boundaries — the canonical threat-modeling artifact. They reveal databases (→ DB audit logs), object stores (→ access logs), authoritative data sources, and where sensitive/regulated data (PCI/PII/PHI) crosses boundaries, which drives compliance-based prioritization.
- Network detail / communications architecture. Network zones/segments, VLANs, firewalls, load balancers, proxies, VPN concentrators — all high-value network log sources.
- Architecture Decision Records (ADRs). Explain why choices were made; useful for understanding compensating controls and where logging may be weak.
A practical extraction tip: DFDs and threat-model diagrams are the single richest artifact because they encode both the components and the trust boundaries where adversary activity crosses — the same boundaries you want telemetry on.
Part B — Step-by-step methodology to derive candidate log sources
Step 1 — Inventory components into a working register. From each ADD/SDD, extract every component/container/external system into a spreadsheet or CMDB-linked register with columns: component name, type (app/DB/network device/identity provider/cloud service/SaaS/container platform/OT), environment, internet-facing (Y/N), data sensitivity (PII/PCI/PHI/none), owning team, and source document/section reference (for two-way traceability).
Step 2 — Map each component to its log-generating capability. For each component, enumerate what telemetry it can emit. Use category templates so this is repeatable:
- Applications → application logs, access logs, audit logs, error logs.
- Databases → authentication (success/failure), privileged access, DDL/schema changes, query/execution logs, permission changes (per Five Eyes “Database Logs” category).
- Network devices → firewall allow/deny (ingress/egress), NetFlow, IDS/IPS alerts, proxy/web query logs, VPN connect/disconnect/auth, config changes.
- Identity providers → sign-in logs (interactive, non-interactive, service principal, managed identity), audit logs, conditional access, MFA, directory changes.
- Cloud services → control-plane audit (CloudTrail / Azure Activity & Entra / GCP Admin Activity), data-plane access (S3/Storage/bucket), network flow logs, key/secret access.
- Endpoints/servers → EDR telemetry, process creation, PowerShell/script block, security event logs.
- Containers/orchestration → API server audit, RBAC changes, admission, runtime.
- SaaS/WAF/SASE (Cloudflare, Zscaler) → HTTP request logs, WAF blocks, SSL inspection, DLP, access policy.
Step 3 — Enrich each candidate with onboarding facts. For each source capture: log format (syslog/JSON/CEF/API), transport/collection method (agent, syslog to Cribl/SC4S, API pull, cloud-native connector), whether a supported parser/TA/connector exists, estimated volume (GB/day and peak EPS), retention/compliance requirement, and normalization target (CIM data model / OCSF class). This is the “data source evaluation” step in Splunk’s workflow (their worked example: “80 GB/day; ~12,000 EPS at peak; Syslog; forward via SC4S; needs CIM Network Traffic data model”).
Step 4 — Reconcile against reality (see Part C). Mark each candidate as designed-only, in-CMDB, or observed-emitting.
Step 5 — Score and prioritize (see Part D).
Step 6 — Produce the roadmap. Group prioritized sources into onboarding waves (e.g., Wave 1 crown-jewel + identity + EDR; Wave 2 network/cloud control plane; Wave 3 supporting/high-volume-low-value to cheaper tiers).
Part C — How ADD/SDD discovery complements other methods (visibility gap analysis)
ADD/SDD extraction is a top-down, design-driven discovery method. It is necessary but not sufficient, and should be layered with:
- CMDB / asset inventory cross-referencing. The CMDB is the intended “single source of truth” for managed assets, configurations, ownership, and interdependencies, and underpins SOX/HIPAA/PCI-DSS/ISO 27001 audit evidence. But CMDBs drift: manually maintained inventories are routinely far smaller than reality (Gartner-cited discovery exercises commonly find asset counts 30–80% higher than existing manual inventories). Cross-referencing ADD/SDD components against CMDB CIs finds documented-but-untracked systems.
- Active/passive network discovery & Attack Surface Management (ASM). Discovery scans and ASM find shadow IT, decommissioned-but-live hosts, and cloud resources provisioned outside change control — assets that will never appear in a design doc. Some SIEMs (e.g., FortiSIEM) ship a built-in CMDB that auto-discovers assets and applications.
- MITRE ATT&CK data-source/component mapping. This flips discovery from “what assets exist” to “what telemetry do I need to detect adversary behavior.” In ATT&CK’s model, a data source (e.g., Process) contains data components (Process Creation, Process Termination…), and each component detects one or more techniques. Reverse-mapping known log sources to techniques shows rough visibility coverage; mapping desired techniques back to required components shows what’s missing.
- DeTT&CT (rabobank-cdc). A free blue-team framework (maintained by Marcus Bakker and Ruben Bouman) that scores data-source quality across five dimensions — device completeness, data field completeness, timeliness, consistency, retention — and produces ATT&CK Navigator layers for visibility and detection coverage. It’s the most concrete open tool for turning a log-source inventory into a visibility heatmap.
Visibility gap analysis is the synthesis: overlay (designed sources ∪ CMDB ∪ observed) against (techniques you care about → required data components). The gaps are (a) assets with no telemetry, (b) telemetry with poor quality/coverage, and (c) techniques with no supporting data. A key discipline: a spreadsheet marking a technique “covered” is not coverage until you’ve proven the sensor, log, and detection actually fire — validate, don’t assume.
Part D — Prioritization frameworks and a concrete scoring model
Real, citable frameworks:
- Five Eyes / ASD Priority Logs for SIEM Ingestion: Practitioner Guidance (27 May 2025). The most directly applicable publication, released as one of three joint CSIs led by NSA with ASD’s ACSC. It states logging is a two-stage process (creation/collection/centralization, then SIEM ingestion), explicitly discourages using the SIEM as a repository for all logs, and recommends gradually building up sources rather than all at once. It gives a loose prioritization order by category: (1) EDR, (2) network device, (3) domain controllers, (4) AD/Domain Service security, (5) Windows endpoint, (6) virtualization, (7) OT, (8) cloud, (9) container, (10) database, (11) MDM, (12) DNS, (13) Linux auditing, (14) macOS — with per-source event IDs. It also lists four assessment criteria per source: purpose/use case, prioritization, volume, and analytical value, stating plainly that “the authoring agencies discourage logging for the sake of logging.”
- MITRE Crown Jewels Analysis (CJA). A structured method to identify the cyber assets most critical to the organization’s mission; MITRE describes it as providing “a rigorous, mission-decomposition approach to uncover vital mission dependencies — even those that are too subtle for less rigorous methods to detect,” and characterizes it as “rigorous, repeatable, self-documenting.” It is the canonical way to establish the “criticality/crown-jewel” dimension of prioritization. Dragos adapts it as a consequence-driven six-layer model for OT/ICS.
- MITRE ATT&CK v18 (Oct 28 2025). Now expresses detection as Detection Strategies (high-level approaches) and Analytics (platform-specific logic) — 691 and 1,739 respectively for Enterprise — each pointing at Log Sources and Data Components (106 for Enterprise). Use it to score a source’s threat-model relevance and detection value (how many relevant analytics/techniques it enables). Note the deprecation of the old Data Sources page.
- NIST SP 800-92 (Guide to Computer Security Log Management, 2006; draft revision 800-92r1, 2023). Establishes the log-management lifecycle (collection, normalization, analysis, retention/disposal) and explicitly covers prioritizing log files and building centralized infrastructure. Pair with CIS Controls v8.1 Control 8 (Audit Log Management).
- MaGMa Use Case Framework (FI-ISAC NL, v1.0, 15 Nov 2017; lead author Rob van Os, based on ABN AMRO’s framework developed by Floris Ladan and Tony Tromp). A business-centric use-case management framework whose name stands for Management, Growth, and Metrics & assessment. It structures every use case in three layers — Business (strategic: purpose, drivers including compliance, stakeholders, output), Threat (tactical: threats, actors/TTPs, IR, analysis), and Implementation (operational: log sources, scope, detection mechanisms, monitoring rules) — and three detail levels (L1 high-level threat aligned to the 7 cyber-kill-chain steps, L2 concrete threat [62 shipped], L3 actual monitoring rule mapped to the MITRE ATT&CK Matrix for Enterprise). Note the important nuance: L1 and L2 sit in the Threat layer; only L3 sits in the Implementation layer. It scores L3 rules on effectiveness, implementation, and coverage (manually set, effectively 0–100%), computes weight (their product) and potential (improvement headroom), and explicitly states prioritization “should be risk-driven … high-risk use cases should be implemented first,” covering “the most critical systems first (i.e. the crown jewels).” Its two-way traceability is exactly what an ADD/SDD-driven roadmap needs to show auditors how business drivers connect to specific monitoring rules.
- Use-case structuring alternatives: the SPEED SIEM Use Case Framework (vendor-neutral directory structure with a dedicated location for log-source monitoring use cases) and MITRE’s Cyber Analytics Repository (CAR).
A practical weighted scoring model (synthesize the above into a repeatable 0–5 scale per factor; multiply by weight; sum; rank):
| Factor | What it measures | Suggested weight | Source basis |
|---|---|---|---|
| Asset criticality | Crown-jewel / mission dependency | 25% | MITRE CJA |
| Threat-model relevance | Maps to top threats / ATT&CK techniques you prioritize | 20% | ATT&CK v18, MaGMa threat layer |
| Detection value | # of use cases / analytics the source enables | 15% | ADS, MaGMa weight/potential |
| Coverage-gap closure | Fills a current visibility/detection blind spot | 15% | DeTT&CT, gap analysis |
| Compliance driver | Required by PCI-DSS/HIPAA/SOX/NIST 800-53/ISO 27001 | 10% | MaGMa compliance drivers, CMDB audit |
| Exposure | Internet-facing / remote-access reachable | 10% | Five Eyes cloud guidance |
| Cost/volume (inverse) | GB/day & EPS vs. detection payoff | 5% (penalty) | Splunk EPS, Sentinel tiering |
Sources scoring high on criticality + threat relevance + exposure but low on cost go to Wave 1. High-volume/low-value sources (verbose firewall, DNS, VPC flow) that score low on detection value are candidates for cheaper storage tiers rather than exclusion.
Part E — The onboarding workflow once a source is prioritized
Combining Splunk’s Lantern 5-step workflow, the NCSC-style threat-model step, and general detection-engineering practice:
- Intake & justification. Capture business justification, requester, owner, and the one event that must be actioned immediately (“what would do the most damage if compromised?”). Prioritize the request; don’t assume requester priority equals platform priority.
- Onboarding questionnaire / interview. Ask for service decompositions, HLDs, and network diagrams (i.e., the ADD/SDD); existing monitoring; scale/volume (GB/day, EPS, device count); planned growth; and how data will be sent. A call beats a form.
- Threat modeling → use cases. Decompose the service to generate detections and responses. Splunk’s default fallback (“Standard Monitoring”) when in doubt: Authentication, Network Traffic, Change, and Endpoint Protection. Every source must connect to a use case and a response action.
- Data source evaluation. Confirm technology/format, collection method, whether a TA/connector exists, and normalization effort (CIM data model / OCSF class). Estimate volume: verify raw log sizes, compute daily/peak/retained/future volume across all hosts. For Splunk sizing, EPS = total events ÷ seconds; rule of thumb ~15% of raw for compressed rawdata + ~35% for index files (~50% of original for syslog). Don’t size on averages — actual volume exceeds the median ~50% of the time.
- Normalization / field mapping. Map to a common schema. CIM (Splunk) via props/transforms for field extraction, aliasing, tagging, and data-model acceleration; OCSF as the vendor-neutral schema (e.g.,
src_ip/source_ip_address/client_ip→src_endpoint.ip); CEF/LEEF for syslog-framed vendor logs. Aim for “CIM-compliant enough” — 100% is unachievable, but enough to fire out-of-the-box content. Do format handling upstream (in Cribl Stream, SC4S, Edge/Ingest Processor, or the collector) so parsing, timestamping (UTC), and field mapping happen before the SIEM; preserve unknown fields; version parsers so changes can be tested and rolled back. - Test ingestion (pre-prod). Validate against representative production telemetry, not clean sample logs — clean samples hide parsing, timestamp, and noise problems. Confirm key fields survive normalization (user, host, src IP, outcome), detections fire when logs arrive late/out-of-order/with missing fields, and benign event noise doesn’t drown signal. Verify RBAC and compliance handling (mask/route PCI data).
- Retention & cost tiering. Route by value: Splunk — analytics index vs. Federated Search/S3 for cold; drop unneeded data with Edge/Ingest Processor. Microsoft Sentinel — three tiers plus archive: Analytics (indicatively ~$2.06–4.30/GB, US East; full KQL, real-time rules), Basic (~$1/GB; limited KQL, 30-day interactive retention), Auxiliary (GA 1 April 2025 at ~$0.15/GB; batch query only, 30-day interactive retention), and long-term/Archive retention (~$0.02/GB/month, up to 12 years). Classify each source by whether it’s in an active detection rule (→ Analytics), occasionally searched (→ Basic), or compliance-only (→ Auxiliary/Archive), and use Data Collection Rules to drop low-value fields at ingest. Commitment tiers cut analytics cost meaningfully. The buyer-side principle: design ingestion before turning the taps on — “detection value comes from the right logs, not all logs.”
- Create detection use cases. Author detections using a documented framework — Palantir’s Alerting and Detection Strategies (ADS) template (Goal, Categorization, Strategy Abstract, Technical Context, Blind Spots & Assumptions, False Positives, Validation, Priority, Response) is the community standard; store as version-controlled detection-as-code. Use a grace/tuning period before going live.
- Validate ATT&CK coverage. Map the new detections to ATT&CK techniques (v18 Detection Strategies/Analytics), update your Navigator/DeTT&CT layer, and confirm the source actually closed the intended gap. Sigma + Uncoder and MITRE CAR help port content.
- Promote to live & lifecycle. Analyst walkthrough (what use cases, what baselines), add to lifecycle review, and treat parser/format drift as ongoing onboarding — a vendor payload change silently breaks detections.
Maturity ladder to anchor the program: Splunk’s Security Data Onboarding model — L1 Ingested & searchable (correct index/sourcetype/_time, access, basic docs); L2 Compliance & coverage (CIM-compliant enough, mapped to use cases, known physical coverage — “if you can’t map it to a security use case, don’t onboard it”); L3 Assured & enriched; L4 unified detection & response. This aligns to CMMI’s five levels (Initial→Optimizing) used by MaGMa and Splunk’s S2M2.
Part F — Common pitfalls and lessons learned
- “Ingest everything, find a use case later.” Creates a “data graveyard”: paying to store unused data, onboarding fatigue, endless maintenance. Start with why (the use case), then onboard.
- Using the SIEM as the central repository for all logs. Five Eyes explicitly discourages this; centralize broadly to cheap storage, ingest selectively to the SIEM.
- Sizing on averages. Actual volume exceeds the median ~50% of the time; size on peak.
- Validating on clean sample logs. Demos pass; production fails on malformed records, mixed timestamps, rotated fields, and bursty ingest.
- Treating parsing/normalization as one-time. Log quality drifts as cloud services, SaaS, and apps change; unversioned, in-SIEM hand-built transforms make every upstream change an outage risk for detections.
- Wrong-field / wrong-timezone parsing. The classic silent failure: a perfect credential-stuffing rule never fires because src IP landed in the wrong field, timestamps are local not UTC, and the username is buried in free text.
- Marking ATT&CK coverage from a spreadsheet. “Covered” is meaningless until the sensor, log, and detection are proven to fire.
- No response tied to the data. Every source should link to a use case and a clear action; alerts nobody acts on breed alert apathy (the problem the ADS framework was built to solve).
- Ignoring OT/ICS constraints. OT logging can impact safety-critical, deterministic systems; take a conservative approach, use ICS-aware monitoring, data diodes/unidirectional gateways, and test thoroughly.
- CMDB blind trust. Manual CMDBs undercount dramatically; always reconcile with discovery.
Recommendations
Stage 0 — Set up (week 1). Stand up a log-source register (columns per Part B). Adopt three named frameworks up front so the program is defensible: Five Eyes Priority Logs (categorical order), MITRE CJA (criticality), and MaGMa or ADS (use-case traceability). Decide your normalization target (CIM for Splunk ES; OCSF if feeding a multi-tool lake via Cribl).
Stage 1 — Discover (weeks 1–3). Extract components from every ADD/SDD into the register with document/section traceability. Reconcile against CMDB and a discovery/ASM scan. Flag internet-facing and regulated-data components. Deliverable: a candidate log-source inventory tagged designed-only / in-CMDB / observed-emitting.
Stage 2 — Map & gap (weeks 2–4). Map each candidate to ATT&CK data components → analytics/techniques (v18). Build a DeTT&CT/Navigator visibility layer. Deliverable: a visibility gap heatmap.
Stage 3 — Prioritize (week 4). Apply the weighted scoring model (Part D). Deliverable: ranked sources grouped into 3 onboarding waves. Benchmark: Wave 1 = crown-jewel + identity (Entra ID) + EDR (CrowdStrike) + internet-facing WAF/proxy (Cloudflare/Zscaler) + cloud control plane.
Stage 4 — Onboard iteratively (ongoing). Run the 10-step workflow per source; use Cribl Stream/SC4S for upstream parsing, timestamping, normalization, and tiered routing; onboard in waves, checking source health after each. Never onboard a source without a linked use case and response.
Stage 5 — Measure & mature. Track MaGMa-style metrics (weight, potential, coverage per threat; false-positive ratio) and progress up the Splunk L1→L4 maturity ladder. Deliverable: quarterly coverage report tying business drivers → threats → detections.
Thresholds that change the plan:
- If a Wave-1 source exceeds its detection payoff on cost (very high GB/day, few detections), downgrade its tier (Sentinel Auxiliary / Splunk S3) rather than drop it.
- If a source scores high on compliance but low on detection value, route to cheap retention to satisfy audit, not to Analytics.
- If discovery finds >20–30% assets not in CMDB, pause onboarding and fix asset inventory first — you can’t prioritize what you can’t see.
- If parser drift causes a detection miss, escalate parsing upstream and add schema-drift monitoring before adding new sources.
Caveats
- ATT&CK v18 is recent (Oct 28 2025). Tooling, Navigator layers, and vendor mappings that reference the old “Data Sources” model are mid-migration; expect a transition period where both models coexist. Map to Data Components/Analytics for future-proofing.
- The weighted scoring model in Part D is a synthesis, not a single published standard — the factors are drawn from real frameworks (CJA, ATT&CK, Five Eyes, MaGMa), but the specific weights are a defensible starting point to be tuned to your risk appetite, not an industry-certified formula.
- MaGMa’s exact numeric scoring scale lives in its companion Excel tool; the published documentation specifies effectiveness/implementation/coverage as manually-set values on an effective 0–100% basis (with a qualitative none/low/medium/high/full fallback mapping to 0/25/50/…/100%) and weight as their product. Treat any “0–3 integer scale” claim as unverified against the tool. Note also the layer-vs-level distinction: MaGMa has three layers (Business/Threat/Implementation) and three detail levels (L1/L2/L3) — they are not the same thing.
- Sentinel and Splunk pricing figures are indicative (region-, contract-, and date-dependent; the figures cited are US East). The tier architecture (Analytics/Basic/Auxiliary/Archive; index vs. federated S3) is stable, the per-GB numbers are not — confirm current pricing before committing.
- NIST SP 800-92 is old (2006) and high-level; a draft revision (800-92r1, 2023) reframes it as a planning “playbook.” Use it for lifecycle vocabulary and the prioritization principle, not for modern cloud/EDR specifics — the Five Eyes 2025 guidance is far more current and operational.
- Design documents are frequently stale. ADD/SDD reflects intent at authoring time; always reconcile against live discovery, and prefer the DFD/threat-model artifacts, which change less often than deployment detail.