System Design Description (SyDD) — ISO/IEC/IEEE 15289 — Description | IEEE 29148 §6.5
Generated 2026-03-27 — UHT Journal / universalhex.org
flowchart TB n0["system<br>Cybersecurity Operations Centre"] n1["subsystem<br>SIEM Engine"] n2["subsystem<br>Network Security Monitoring"] n3["subsystem<br>Endpoint Detection and Response"] n4["subsystem<br>Threat Intelligence Platform"] n5["subsystem<br>Vulnerability Management"] n6["subsystem<br>SOAR Platform"] n7["subsystem<br>Identity and Access Monitoring"] n8["subsystem<br>SOC Facility Infrastructure"] n9["subsystem<br>Communications and Reporting"] n1 -->|Correlated alerts| n6 n2 -->|Network alerts, metadata| n1 n3 -->|Endpoint telemetry, alerts| n1 n4 -->|IOC enrichment data| n1 n6 -->|Containment commands| n3 n5 -->|Vulnerability context| n1 n7 -->|Identity alerts| n1 n6 -->|Notifications, reports| n9 n4 -->|Threat context for playbooks| n6 n3 -->|Endpoint telemetry CEF/ECS| n1 n2 -->|IDS alerts, DNS, NetFlow| n1 n4 -->|IoC watchlists STIX 2.1| n1 n7 -->|Auth events, UEBA alerts| n1 n5 -->|Vuln scan results, risk scores| n1 n1 -->|Correlated alert packages| n6 n6 -->|Incident data, reports| n9 n1 -->|Operational metrics| n9
Cybersecurity Operations Centre — Decomposition
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SUB-SUB-SIEM-001 | The SIEM Engine SHALL provide an ad-hoc threat hunting query interface supporting structured and unstructured searches across all ingested telemetry types, with query response time not exceeding 30 seconds for searches spanning the full 90-day hot storage window, and SHALL support saved hunt hypotheses linked to MITRE ATT&CK technique identifiers. Rationale: Derives from SYS-SYS-DETECT-013 threat hunting requirement. 30-second query latency matches the parent requirement and is driven by analyst workflow studies showing that interactive threat hunting degrades when query round-trip exceeds 30 seconds. Saved hypothesis linkage to ATT&CK enables systematic coverage tracking across hunt campaigns. | Test | session-298 |
| SUB-SUB-SIEM-002 | The SIEM Engine SHALL implement alert suppression, deduplication, and correlation grouping to reduce raw alert volume by at least 80% before analyst presentation, maintaining a per-analyst actionable alert queue not exceeding 25 active alerts per 8-hour shift, with suppression rules configurable per detection rule and auditable for false negative review. Rationale: Derives from SYS-SYS-DETECT-014. The 25-alert-per-analyst threshold is based on cognitive load research showing SOC analyst effectiveness drops sharply above 3-4 alerts per hour. 80% reduction target reflects industry benchmarks for mature SIEM tuning. Auditability of suppression rules is critical to prevent false negatives from hiding in suppression logic. | Analysis | session-298 |
| SUB-SUB-SIEM-003 | When the SIEM Engine is unavailable or operating at degraded capacity, the SOAR Platform SHALL activate direct alert ingestion channels from the EDR, NSM, and IAM subsystems, maintaining detection capability for at least the top 50 MITRE ATT&CK techniques at a minimum 60% detection rate relative to nominal SIEM-mediated operation, with analyst notification within 2 minutes of SIEM degradation onset. Rationale: Derives from SYS-REQS-017 degraded-mode detection requirement. The 60% detection floor and top-50 ATT&CK technique scope match the parent requirement. Placing this capability in the SOAR subsystem reflects the SOAR's role as the operational workflow engine — it must be able to receive alerts even when the SIEM correlation backbone is down. The 2-minute notification threshold ensures analysts know they are operating in degraded mode. | Test | session-298 |
| SUB-SUB-SIEM-004 | The SOC Facility Infrastructure SHALL maintain a documented disaster recovery capability including a secondary SOC site or cloud-hosted failover environment, achieving a recovery time objective of 4 hours and recovery point objective of 1 hour for all SIEM correlation data, SOAR case state, and detection rule configurations, with DR procedures tested semi-annually. Rationale: Derives from SYS-SYS-INFRA-016 disaster recovery requirement. The 4-hour RTO and 1-hour RPO match the parent requirement. Recovery must preserve SIEM correlation data, SOAR case state, and detection rules because loss of any one of these renders the SOC operationally blind (data), uncoordinated (cases), or undefended (rules). Semi-annual testing is the minimum cadence for DR validation in security-critical infrastructure. | Test | session-298 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| IFC-IFC-INTERNAL-001 | The SIEM Engine SHALL transmit correlated alert packages to the SOAR Platform via a message queue interface, with each package containing the triggering events, matched rule identifiers, affected asset inventory records, and threat intelligence enrichment data, delivered within 10 seconds of correlation completion. Rationale: The SIEM-to-SOAR alert handoff is the critical transition from detection to response. The 10-second delivery SLA ensures automated playbooks can execute within the 60-second response target (SYS-SYS-RESPOND-004). Including matched rule identifiers and threat intelligence enrichment in the package eliminates SOAR round-trip queries that would add latency and coupling. | Test | |
| IFC-IFC-INTERNAL-002 | The Endpoint Detection and Response Subsystem SHALL stream endpoint telemetry to the SIEM Engine in Common Event Format (CEF) or Elastic Common Schema (ECS), including process creation, file modification, registry changes, and network connection events, at a sustained rate matching the endpoint fleet size without event loss. Rationale: Endpoint telemetry is the primary data source for host-based threat detection. CEF/ECS format standardisation enables correlation with network-layer events in the SIEM without per-vendor normalisation logic. Zero-loss streaming is required because adversary dwell-time indicators (process trees, registry modifications) are ephemeral and unrecoverable if dropped. | Test | |
| IFC-IFC-INTERNAL-003 | The Threat Intelligence Platform SHALL push updated indicator-of-compromise watchlists to the SIEM Engine within 5 minutes of indicator ingestion, using STIX 2.1 bundle format, including indicator type, confidence score, TLP marking, and associated threat actor attribution where available. Rationale: IoC freshness directly determines detection effectiveness against active campaigns. The 5-minute push interval balances operational urgency with TIP processing overhead for deduplication, confidence scoring, and TLP compliance. STIX 2.1 is mandated by NIS2 information-sharing requirements and interoperability with government CERTs. | Test | |
| IFC-IFC-INTERNAL-004 | The SOAR Platform SHALL issue containment commands to the Endpoint Detection and Response Subsystem via an authenticated REST API, supporting network isolation, process termination, and file quarantine actions, with command acknowledgement returned within 5 seconds and execution confirmation within the 30-second containment SLA. Rationale: Automated containment via SOAR-to-EDR API is the mechanism that achieves the 30-second containment SLA (SYS-SYS-RESPOND-003). The 5-second acknowledgement confirms the EDR agent received the command, distinguishing command delivery failures from execution failures. Network isolation, process termination, and file quarantine are the three containment primitives that cover 95% of MITRE ATT&CK response actions. | Test | |
| IFC-IFC-INTERNAL-005 | The Network Security Monitoring Subsystem SHALL forward IDS alerts, DNS query logs, and NetFlow metadata to the SIEM Engine in near-real-time with end-to-end latency not exceeding 30 seconds, tagging each event with the originating network segment identifier and sensor location. Rationale: Network-layer visibility provides detection coverage for threats invisible to endpoint agents (lateral movement, C2 beaconing, DNS exfiltration). The 30-second latency ceiling ensures IDS alerts reach the SIEM before automated response windows expire. Segment tagging is essential for correlating network events to asset inventory and establishing blast radius during incidents. | Test | |
| IFC-IFC-INTERNAL-006 | The Identity and Access Monitoring Subsystem SHALL stream authentication events, privilege escalation attempts, and UEBA anomaly alerts to the SIEM Engine in Elastic Common Schema format, with event delivery latency not exceeding 15 seconds from event occurrence and including user principal name, source IP, authentication method, and risk score for each event. Rationale: Identity-based attacks (credential stuffing, privilege escalation, lateral movement via stolen tokens) account for over 60% of enterprise breaches. The 15-second delivery SLA ensures UEBA anomaly alerts reach the SIEM fast enough to correlate with concurrent network and endpoint indicators. ECS format ensures consistent schema with EDR telemetry for cross-domain correlation. | Test | interface, validation, session-293 |
| IFC-IFC-INTERNAL-007 | The Vulnerability Management System SHALL export vulnerability scan results and asset risk scores to the SIEM Engine via a scheduled API integration at intervals not exceeding 1 hour, with each record including CVE identifiers, CVSS base and environmental scores, affected asset identifiers, and remediation status. Rationale: Vulnerability context enriches SIEM correlation by linking observed exploit attempts to known vulnerable assets, enabling prioritised alerting. The 1-hour integration interval balances scan result freshness with API rate limits on vulnerability scanners. CVSS environmental scores (not just base) are required for risk-adjusted prioritisation against the organisation's specific attack surface. | Test | interface, validation, session-293 |
| IFC-IFC-INTERNAL-008 | The SOAR Platform SHALL create and update incident tickets in the IT Service Management system via a bidirectional REST API integration, with ticket creation occurring within 60 seconds of incident declaration, including severity, affected assets, containment actions taken, and remediation tasks, and SHALL receive ticket status updates to maintain incident timeline synchronisation. Rationale: ITSM integration is the boundary between SOC incident response and organisational IT remediation workflows. The 60-second ticket creation SLA ensures affected asset owners are notified before containment actions cause service disruptions. Bidirectional synchronisation prevents timeline divergence between the SOAR case record and the ITSM ticket, which undermines post-incident review accuracy. | Test | external, validation, session-293 |
| IFC-IFC-INTERNAL-009 | The Threat Intelligence Platform SHALL expose a synchronous enrichment API to the SOAR Platform, accepting indicator queries (IP, domain, hash, URL) and returning confidence score, associated threat actor, TLP marking, and related indicators within 2 seconds per query, supporting a sustained query rate of at least 100 queries per minute during active incident response. Rationale: During incident response, SOAR playbooks need real-time indicator enrichment to make automated triage and containment decisions. Without a direct TIP-to-SOAR query interface, analysts must manually pivot to the TIP, adding minutes to response time. The 2-second SLA ensures playbook execution stays within the 60-second automated response target. The 100 qpm rate supports large-scale incidents. | Test | interface, validation, session-297 |
| IFC-IFC-INTERNAL-010 | The SOAR Platform SHALL issue network-level containment commands to the Network Security Monitoring Subsystem via an authenticated API, supporting IP address blocking, VLAN isolation, and DNS sinkhole actions, with command acknowledgement within 5 seconds and enforcement at the network perimeter within 30 seconds of command issuance. Rationale: Endpoint containment alone (IFC-INTERNAL-004) is insufficient for threats from unmanaged devices, IoT, or OT assets without EDR agents. Network-level containment through firewall rule insertion, VLAN isolation, or DNS sinkholing provides a complementary containment vector. The 30-second enforcement SLA matches EDR containment for consistent response timing. Cross-domain analog: naval CMS uses both close-in and area-defence engagement layers. | Test | interface, validation, session-297 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| ARC-ARC-RAT-001 | The Cybersecurity Operations Centre SHALL employ a SIEM-centric hub-and-spoke architecture where the SIEM Engine acts as the central correlation point, receiving telemetry from all detection subsystems (NSM, EDR, IAM, VMS) and forwarding correlated alerts to the SOAR Platform for automated and analyst-driven response. Rationale: Hub-and-spoke with SIEM as the central correlator was selected over a fully-meshed subsystem topology because it reduces integration complexity from O(n^2) to O(n) interfaces, concentrates log retention and forensic search in one store, and provides a single correlation context across all detection domains. The alternative — distributed correlation at each subsystem — was rejected due to increased latency for cross-domain detections and duplicated storage costs. | Analysis |
| Entity | Hex Code | Description |
|---|---|---|
| Communications and Reporting Subsystem | 40A57B58 | Secure communications and reporting subsystem providing internal SOC collaboration, external stakeholder notification, and regulatory reporting capabilities. Internal channels include encrypted instant messaging, voice/video conferencing for distributed analyst teams, and a shared evidence repository with role-based access. External communications include automated alert notifications to IT asset owners, executive summary dashboards for CISO and board reporting, and pre-formatted regulatory notifications (GDPR Article 33, NIS2 Directive, sector-specific). Integrates with ITSM ticketing systems (ServiceNow, Jira) for incident-to-change tracking. Provides shift handover documentation, daily/weekly/monthly reporting templates, and KPI dashboards tracking MTTD, MTTR, alert volume, false positive rate, and analyst workload. |
| Cybersecurity Operations Centre | 40A57AD9 | Enterprise-grade Security Operations Centre (SOC) providing 24/7 cyber defence for a large organisation's IT and OT infrastructure. Integrates Security Information and Event Management (SIEM), Network Security Monitoring (NSM), Endpoint Detection and Response (EDR), threat intelligence platform, vulnerability management, and Security Orchestration Automation and Response (SOAR). Ingests telemetry from 50,000+ endpoints, 200+ network segments, and cloud workloads across multiple regions. Staffed by tiered analyst teams (L1 triage, L2 investigation, L3 hunt/forensics) operating in a purpose-built facility with redundant power, communications, and physical security. Must comply with NIST CSF, ISO 27001, and sector-specific regulations. Designed to detect advanced persistent threats (APT) with mean time to detect (MTTD) under 15 minutes and mean time to respond (MTTR) under 60 minutes for critical incidents. |
| Endpoint Detection and Response Subsystem | 51F77B19 | Agent-based endpoint detection and response (EDR) subsystem deployed across 50,000+ Windows, Linux, and macOS endpoints including servers, workstations, and virtual machines. Agents collect process telemetry, file system events, registry modifications, network connections, and memory indicators at kernel level. Cloud-hosted analysis engine performs behavioral detection using ML models trained on enterprise-specific baselines, with detection latency under 5 seconds for known IOCs and under 30 seconds for behavioral anomalies. Supports remote containment actions (network isolation, process termination, file quarantine) executable from the SOAR or analyst console. Provides forensic timeline reconstruction capability for incident investigation. |
| Identity and Access Monitoring Subsystem | 41B77319 | Specialised monitoring subsystem focused on identity-based threats across the enterprise identity fabric. Integrates with Active Directory, Azure AD/Entra ID, LDAP directories, and Privileged Access Management (PAM) vaults to monitor authentication events, privilege escalations, service account usage, and lateral movement indicators. Performs User and Entity Behaviour Analytics (UEBA) using statistical models of normal login patterns (time, location, device, resource) to detect credential compromise, insider threats, and account takeover. Monitors Kerberos ticket operations for Golden/Silver ticket attacks, DCSync, and Pass-the-Hash. Feeds high-confidence identity alerts to SOAR for automated account lockout or MFA step-up enforcement. |
| Network Security Monitoring Subsystem | 40A53219 | Passive and active network security monitoring subsystem covering 200+ network segments across enterprise LAN, WAN, DMZ, and OT networks. Deploys network TAPs and SPAN ports feeding full-packet-capture appliances retaining 72 hours of PCAP at 10Gbps aggregate throughput. Runs signature-based IDS (Suricata rule sets updated every 4 hours), protocol anomaly detection, and encrypted traffic analysis using JA3/JA4 fingerprinting. Integrates NetFlow/IPFIX collectors for traffic baselining and lateral movement detection. Feeds alerts and metadata to the SIEM for correlation and provides raw packet data to forensics analysts on demand. |
| SIEM Engine | 51F77B19 | Security Information and Event Management engine serving as the central data processing backbone of the SOC. Ingests structured and unstructured log data from 50,000+ endpoints, network devices, firewalls, proxies, cloud services (AWS CloudTrail, Azure AD, GCP audit logs), and application servers at sustained rates exceeding 100,000 events per second. Performs real-time correlation using 500+ detection rules mapped to MITRE ATT&CK techniques, statistical baselining for anomaly detection, and multi-stage alert triage with configurable severity thresholds. Stores 90 days of hot data and 1 year of warm data in a distributed search cluster. Outputs correlated alerts to SOAR for automated response and to analyst dashboards for manual investigation. |
| SOAR Platform | 51B77B19 | Security Orchestration, Automation and Response (SOAR) platform serving as the operational workflow engine of the SOC. Executes 150+ automated playbooks for common alert types (phishing, malware detection, brute force, data exfiltration) with human-in-the-loop approval gates for high-impact actions (endpoint isolation, firewall rule deployment, account disablement). Manages the full incident lifecycle from alert triage through containment, eradication, recovery, and lessons learned. Integrates bidirectionally with SIEM, EDR, TIP, firewalls, email gateways, DNS, Active Directory, and ticketing systems via REST APIs. Provides case management with evidence chain-of-custody tracking, analyst assignment, SLA monitoring, and regulatory reporting templates (GDPR 72h breach notification, sector-specific reporting). |
| SOC Facility Infrastructure | DE851018 | Purpose-built physical facility housing the Security Operations Centre, designed to Tier III data centre standards for the server room and secure operations area. Includes redundant UPS and diesel generator backup providing 72-hour autonomous operation, N+1 HVAC for equipment cooling, and TEMPEST-grade electromagnetic shielding for classified operations. Physical security includes mantrap entry, biometric access control (iris + badge), CCTV with 90-day retention, and 24/7 guard presence. Operations floor features a video wall (12-panel array) displaying real-time threat maps, alert dashboards, and incident status. Analyst workstations are dual-screened with secure KVM switches for accessing multiple security enclaves. Includes a dedicated war room for major incident coordination. |
| Threat Intelligence Platform | 40F77319 | Cyber threat intelligence (CTI) aggregation and management platform that ingests, normalises, and correlates intelligence from 20+ commercial and open-source feeds (STIX/TAXII 2.1, CSV, JSON). Maintains a structured IOC database of IP addresses, domains, file hashes, URLs, and YARA rules with automated scoring based on source reliability, age, and corroboration. Provides enrichment APIs consumed by the SIEM correlation engine and SOAR playbooks to contextualise alerts with threat actor attribution, campaign tracking, and TTP mapping to MITRE ATT&CK. Supports bidirectional sharing with sector ISACs and national CERT. Retains 2 years of historical intelligence for trend analysis. |
| Vulnerability Management System | 41F77B19 | Continuous vulnerability management subsystem maintaining a real-time asset inventory of all IT and OT assets (servers, endpoints, network devices, cloud instances, containers, IoT). Performs authenticated and unauthenticated vulnerability scans on a rolling 7-day cycle for IT assets and 30-day cycle for OT assets (to avoid operational disruption). Correlates scan results with threat intelligence to produce risk-prioritised vulnerability scores (CVSS base + temporal + environmental). Integrates with IT service management for remediation ticket generation and tracks patch compliance against SLA targets (critical: 72h, high: 14d, medium: 30d). Provides attack surface mapping and exposure analysis. |
| Component | Belongs To |
|---|---|
| SIEM Engine | Cybersecurity Operations Centre |
| Network Security Monitoring Subsystem | Cybersecurity Operations Centre |
| Endpoint Detection and Response Subsystem | Cybersecurity Operations Centre |
| Threat Intelligence Platform | Cybersecurity Operations Centre |
| Vulnerability Management System | Cybersecurity Operations Centre |
| SOAR Platform | Cybersecurity Operations Centre |
| Identity and Access Monitoring Subsystem | Cybersecurity Operations Centre |
| SOC Facility Infrastructure | Cybersecurity Operations Centre |
| Communications and Reporting Subsystem | Cybersecurity Operations Centre |
| From | To |
|---|---|
| Network Security Monitoring Subsystem | SIEM Engine |
| Endpoint Detection and Response Subsystem | SIEM Engine |
| Threat Intelligence Platform | SOAR Platform |
| SIEM Engine | Communications and Reporting Subsystem |
| SOAR Platform | Network Security Monitoring Subsystem |
| Vulnerability Management System | SIEM Engine |
| Identity and Access Monitoring Subsystem | SIEM Engine |