Chapter 2: Design Methods

2.1 Design Principles & References

Effective cybersecurity monitoring system design is grounded in a set of executable engineering principles that have been validated through operational experience across diverse enterprise environments. These principles are not abstract ideals but actionable constraints that shape every architectural decision, from telemetry source selection to SOAR playbook design. Each principle is accompanied by a reference type indicating its primary justification — whether SOC best practice, engineering necessity, compliance requirement, or operational scaling concern.

1. Use-case first, not data-hoarding: Onboard telemetry by prioritized scenarios and assets. Collecting everything without classification creates unsustainable costs and noise that defeats the purpose of monitoring. Reference: SOC best practice + cost control.
2. Time is a security control: Enforce NTP/PTP across all sources, collectors, and SIEM components; monitor drift continuously. Correlation accuracy depends entirely on synchronized timestamps. Reference: Engineering necessity for correlation.
3. Common schema or consistent mapping: Adopt ECS-like field normalization; version-control parsers as code. Inconsistent field naming prevents cross-source correlation. Reference: Interoperability.
4. Asset and identity binding is mandatory: Every event must map to asset_id and user_id when possible. Without this binding, triage requires manual lookup and MTTR increases dramatically. Reference: Operational triage.
5. Tiered retention by criticality: Hot/warm/archive storage tiers plus WORM for key logs. Flat retention is either too expensive or too short for compliance. Reference: Compliance + cost.
6. Least privilege and separation of duties: Collectors, SIEM admins, and SOC analysts must have separate roles; break-glass access must be audited. Reference: Insider risk.
7. Defense-in-depth observation points: Deploy visibility at edge, east-west, management network, and cloud simultaneously. Modern lateral movement bypasses perimeter-only monitoring. Reference: Modern threat landscape.
8. Severity = Impact × Confidence × Exposure: Standardize severity scoring to reduce noise and prioritize analyst attention. Reference: SOC scaling.
9. Automation with guardrails: All automated response actions must have approval gates, rollback capability, and dry-run modes. Automation without guardrails causes outages. Reference: Availability protection.
10. Closed-loop governance: Every incident must yield tuning and hardening tasks; track closure rates. Reference: Continuous improvement.
11. Immutable evidence: Log integrity and chain-of-custody are prerequisites for investigations and legal proceedings. Reference: Audit/legal.

2.2 Failure Causes & Recommendations

Monitoring system failures rarely result from a single catastrophic event. More commonly, they arise from a cascade of design oversights that individually seem minor but collectively create significant blind spots or operational failures. The following table maps the most common failure causes to their underlying mechanisms, operational results, and actionable recommendations.

2.3 Core Design & Selection Logic

The design selection process follows a structured decision framework that begins with business objectives and works through environment characteristics, scale requirements, and automation needs to arrive at an appropriate architecture pattern. This decision tree prevents the common mistake of selecting a SIEM product before understanding the deployment context and operational model.

Figure 2.1: Architecture Selection Decision Tree — From Business Objectives through Compliance-Heavy vs. Threat-Driven orientation, Environment type, Scale sizing, and Response Automation level, leading to four architecture patterns: Central SIEM, Regional Hubs, Cloud-Native SIEM, or Managed SOC.

Decision Steps

1. Identify top 12–20 detection use-cases mapped to MITRE ATT&CK techniques and business risk. This scope definition prevents scope creep and focuses telemetry onboarding.
2. Define asset tiers and "crown jewels." Identify the 5–15% of assets that, if compromised, would cause the most significant business impact. These drive observation point placement and retention requirements.
3. Choose observation points and minimum telemetry per tier. Map each detection use-case to the telemetry sources required to detect it. Avoid collecting sources that don't contribute to any use-case.
4. Size ingestion/storage and define retention tiers. Use the calculators in Chapter 9 to derive EPS, GB/day, and storage requirements for each tier.
5. Choose SIEM/SOAR integration pattern and approval model. Select from the four architecture patterns based on the decision tree, then define the approval workflow for automated actions.
6. Define acceptance tests using simulated attack paths. For each detection use-case, define a test scenario that validates end-to-end detection and response capability.

2.4 Key Design Dimensions

Every monitoring system design must be evaluated across seven key dimensions that collectively determine whether the system will be effective, sustainable, and compliant over its operational lifetime. Optimizing for only one or two dimensions while ignoring others leads to systems that are technically impressive but operationally unviable.