ISO 27001 A.8.16: Monitoring Activities

Quick Reference: A.8.16 in 60 Seconds

The 30-Second Architecture

┌─────────────────────────────────────────────────────────────┐
│  LAYER 4: RESPONSE (SOAR, Incident Response, Automation)    │
│  "Act on what you detect"                                   │
├─────────────────────────────────────────────────────────────┤
│  LAYER 3: ANALYSIS (SIEM, UEBA, Detection Engineering)      │
│  "Correlate, detect, and investigate"                       │
├─────────────────────────────────────────────────────────────┤
│  LAYER 2: AGGREGATION (Log Collection, Parsing, Normalization)│
│  "Collect everything in one place"                          │
├─────────────────────────────────────────────────────────────┤
│  LAYER 1: SOURCES (Endpoints, Network, Cloud, Apps, DBs)  │
│  "Generate logs from every asset"                           │
└─────────────────────────────────────────────────────────────┘

What the Standard Actually Requires

Figure · Process

What A.8.16 asks you to do

ISO 27001:2022 A.8.16 Text

ISO 27001:2022 Annex A 8.16 asks organizations to monitor networks, systems, and applications for anomalous behavior and act on potential security incidents.

ISO 27002:2022 Implementation Guidance (Section 8.16)

ISO 27002 provides 6 implementation guidelines for 8.16:

1. Monitoring strategy, Define what to monitor, how often, and with what tools. The strategy should cover networks, systems, and applications.
2. Monitoring tools, Deploy tools to collect and analyze event data. Tools should support real-time alerting and historical investigation.
3. Anomaly detection, Establish baselines and detect deviations from normal behavior. This includes both signature-based and behavioral detection.
4. Event logging, Ensure that security-relevant events are logged. Logs should be protected from tampering and unauthorized access.
5. Log review, Regularly review logs for signs of security incidents. Reviews should be documented and follow a defined procedure.
6. Response to anomalies, Define how anomalies are evaluated and escalated. This links directly to A.5.24 (Incident Response) and A.5.25 (Assessment and Decision).

What Changed from ISO 27001:2013

Key implication: The 2022 version is more focused on active monitoring and response rather than passive log collection. The control now explicitly requires organizations to monitor networks, systems, and applications for anomalous behavior and act on potential security incidents. This means monitoring without response is non-compliant.

What Auditors Actually Check

The Monitoring Policy Minimum Requirements

Every auditor will ask for your monitoring policy. It must contain:

💡 Tip from Singahi: In our audits, we see that 45% of 8.16 non-conformities stem from a missing or inadequate monitoring policy. Organizations deploy Splunk or Sentinel but never document the process around it. The tool is not the control. The documented, repeatable process is the control.

The Monitoring Scope

Most guides stop at "networks, systems, and applications." That's incomplete. Here is the complete monitoring scope for a modern organization.

The 12 Monitoring Domains

The Cloud-Native Expansion

Modern infrastructure has expanded the monitoring scope dramatically:

Edge Monitoring

Edge devices, IoT, retail POS, manufacturing sensors, remote offices, are often blind spots.

💡 Tip from Singahi: During ISO 27001 Stage 2 audits, we see auditors specifically probe for cloud and container monitoring. If you run workloads in AWS or Azure but your monitoring policy only mentions "servers," expect a non-conformity. The scope must match your actual infrastructure.

The Monitoring Architecture

Design Principles

Defense in Depth for Monitoring

Don't rely on a single layer. Build monitoring depth:

┌─────────────────────────────────────────────────────────────┐
│  TIER 4: STRATEGIC (Threat Intelligence, Risk Dashboards) │
│  "What threats are coming? What's our exposure?"            │
├─────────────────────────────────────────────────────────────┤
│  TIER 3: OPERATIONAL (SOC, SIEM, Alerting, Response)      │
│  "What's happening right now? Should we respond?"           │
├─────────────────────────────────────────────────────────────┤
│  TIER 2: TACTICAL (Log Aggregation, Parsing, Storage)     │
│  "Collect, normalize, and store everything"                 │
├─────────────────────────────────────────────────────────────┤
│  TIER 1: TECHNICAL (Endpoint, Network, Cloud, App Logs)   │
│  "Generate telemetry from every asset"                      │
├─────────────────────────────────────────────────────────────┤
│  TIER 0: FOUNDATIONAL (Time Sync, Log Integrity, Policy)  │
│  "Without accurate time and integrity, monitoring is useless"│
└─────────────────────────────────────────────────────────────┘

Centralized vs. Distributed Monitoring

Singahi recommendation: Start centralized. Most organizations under 1,000 employees should have one primary SIEM. Above that, consider federated with regional collectors. Above 10,000 employees or multi-national with data residency requirements, go hierarchical.

Real-Time vs. Batch Processing

Critical insight: Not everything needs to be real-time. Alerting should be real-time. Threat hunting can be near-real-time. Compliance reporting can be batch. Misjudging this creates alert fatigue and wastes infrastructure budget.

Agent-Based vs. Agentless Collection

On-Premises vs. Cloud vs. Hybrid Monitoring

The Hybrid Reality: Most organizations are hybrid. They have on-prem Active Directory, AWS workloads, Azure SaaS, and GCP BigQuery. Your monitoring architecture must accommodate all three without creating blind spots.

Singahi's recommended hybrid architecture:

┌────────────────────────────────────────────────────────────────────┐
│                        CLOUD SIEM (Sentinel / Splunk Cloud)         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌──────────┐ │
│  │ Analytics   │  │ Threat Intel│  │ SOAR        │  │ Reporting│ │
│  └─────────────┘  └─────────────┘  └─────────────┘  └──────────┘ │
└────────────────────────────────────────────────────────────────────┘
                              ▲
                              │ Encrypted TLS / VPN
┌────────────────────────────────────────────────────────────────────┐
│                    LOG AGGREGATION LAYER                            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌──────────┐ │
│  │ Syslog NG   │  │ Kafka       │  │ Logstash    │  │ Fluentd  │ │
│  └─────────────┘  └─────────────┘  └─────────────┘  └──────────┘ │
└────────────────────────────────────────────────────────────────────┘
                              ▲
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
┌───────┴───────┐   ┌─────────┴─────────┐   ┌───────┴───────┐
│   ON-PREM     │   │      AWS           │   │    AZURE      │
│  AD, VMware   │   │  CloudTrail, VPC   │   │  Monitor, AD  │
│  Firewalls    │   │  GuardDuty, EKS    │   │  Sentinel,    │
│  Endpoints    │   │  CloudWatch, ALB   │   │  Defender     │
└───────────────┘   └───────────────────┘   └───────────────┘

💡 Tip from Singahi: The #1 architectural mistake we see is organizations buying Splunk Cloud and then discovering they cannot forward their on-prem firewall logs without a heavy forwarder or syslog gateway. Plan the data flow before you buy the license.

Log Sources & Collection

Operating System Logs

Windows Event IDs Every Monitor Must Track:

Linux Audit Rules Every Organization Should Deploy:

## Monitor user/group modifications
-w /etc/passwd -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes

## Monitor sudoers
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d -p wa -k sudoers_changes

## Monitor SSH configuration
-w /etc/ssh/sshd_config -p wa -k ssh_config_changes

## Monitor privilege escalation
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation

## Monitor file integrity critical paths
-w /etc/cron.d -p wa -k cron_changes
-w /etc/cron.daily -p wa -k cron_changes
-w /var/spool/cron -p wa -k cron_changes

## Monitor suspicious command execution
-a always,exit -F arch=b64 -S execve -C uid!=euid -k privilege_escalation

Application Logs

Application Logging Best Practices (The 5-Field Rule):

Every application log entry should contain at minimum:

1. Timestamp (ISO 8601, UTC, millisecond precision)
2. Severity (DEBUG, INFO, WARN, ERROR, CRITICAL)
3. Event type (auth.success, auth.failure, data.access, config.change)
4. Actor (user ID, service account, IP address, session ID)
5. Outcome (success, failure, blocked, allowed, with detail)

Example:

{
  "timestamp": "2026-06-15T05:19:50.173Z",
  "severity": "WARN",
  "event_type": "auth.failure",
  "actor": {
    "user_id": "user@company.com",
    "ip_address": "203.0.113.45",
    "session_id": "sess_abc123"
  },
  "outcome": "failure",
  "detail": {
    "reason": "invalid_password",
    "mfa_required": true,
    "attempt_count": 3
  }
}

Network Logs

Authentication & Identity Logs

Database Audit Logs

Cloud Audit Logs

Kubernetes & Container Logs

Physical Access Logs

API Gateway Logs

💡 Tip from Singahi: The most common log source gap is DNS. Organizations monitor firewalls and endpoints but ignore DNS. 80% of malware uses DNS for C2 communication. If you're not logging DNS queries, you're blind to the majority of modern malware traffic. Enable DNS logging today, it's often free with your existing DNS infrastructure.

Log Management & Centralization

Syslog, Syslog-NG, and Rsyslog

The syslog protocol (RFC 5424) is the backbone of log collection. Understand the differences:

Sample rsyslog Configuration for Centralized Collection:

## /etc/rsyslog.conf
## Enable TCP reception
module(load="imtcp")
input(type="imtcp" port="514")

## Enable UDP reception (fallback only)
module(load="imudp")
input(type="imudp" port="514")

## Template for structured storage
*.* ?RemoteLogs
& stop

## Forward everything to central SIEM over TLS
*.* @@central-siem.company.com:6514;RSYSLOG_SyslogProtocol23Format

Sample syslog-ng Configuration with Parsing:

## /etc/syslog-ng/syslog-ng.conf
source s_network {
    network(
        transport("tcp")
        port(514)
    );
};

destination d_central {
    syslog("central-siem.company.com"
        transport("tls")
        port(6514)
        tls(
            ca_dir("/etc/syslog-ng/ca.d")
            key_file("/etc/syslog-ng/client.key")
            cert_file("/etc/syslog-ng/client.crt")
        )
    );
};

## Parse and route Apache logs
filter f_apache {
    program("apache");
};

destination d_apache_parsed {
    file("/var/log/apache/structured.log"
    );
};

log {
    source(s_network);
    filter(f_apache);
    destination(d_apache_parsed);
    destination(d_central);
};

Windows Event Forwarding (WEF)

WEF is the native, agentless way to collect Windows events. It uses WinRM and is built into Windows Server.

Architecture:

Domain Controllers / Workstations (Source)
           ↓ (WinRM, HTTPS or HTTP with Kerberos)
    Windows Event Collector (WEC) Server
           ↓ (rsyslog, Splunk UF, or direct to SIEM)
           SIEM

Why WEF matters:

• No agent installation on endpoints (agentless)
• Uses Active Directory for authentication
• Supports both push (source-initiated) and pull (collector-initiated) subscriptions
• Can filter events at the source, reducing bandwidth

WEF Subscription Types:

WEF Limitations:

• Only works for Windows events (not Sysmon, not custom application logs)
• Requires Active Directory
• No native encryption without HTTPS configuration
• Limited parsing capability (events are XML)

Best practice: Use WEF for baseline Windows Security events. Use an agent (Winlogbeat, Splunk UF, CrowdStrike) for rich endpoint telemetry including Sysmon, PowerShell, and custom application logs.

Log Shippers: Fluentd, Fluent Bit, Logstash, Vector

Modern log architecture uses lightweight log shippers at the edge.

Fluent Bit Configuration Example (Kubernetes + CloudWatch + SIEM):

## fluent-bit-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush         1
        Log_Level     info
        Daemon        off
        Parsers_File  parsers.conf
    [INPUT]
        Name              tail
        Tag               kube.*
        Path              /var/log/containers/*.log
        Parser            docker
        DB                /var/log/flb_kube.db
        Mem_Buf_Limit     50MB
    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
    [OUTPUT]
        Name            cloudwatch_logs
        Match           kube.*
        region          us-east-1
        log_group_name  /eks/application-logs
    [OUTPUT]
        Name            syslog
        Match           kube.*
        Host            siem.company.com
        Port            514
        Mode            tcp
        Syslog_Format   rfc5424

Log Parsing and Normalization

Raw logs are useless without parsing. The goal is to convert unstructured or semi-structured logs into a common schema.

Common Log Schemas:

Parsing Example: Apache Combined Log to ECS:

Raw: 192.168.1.1 - - [15/Jun/2026:05:19:50 +0000] "GET /api/users HTTP/1.1" 200 1234 "https://app.company.com" "Mozilla/5.0"

ECS Parsed:
- source.ip: 192.168.1.1
- http.request.method: GET
- url.path: /api/users
- http.response.status_code: 200
- http.response.body.bytes: 1234
- http.request.referrer: https://app.company.com
- user_agent.original: Mozilla/5.0
- event.category: web
- event.dataset: apache.access

Normalization Pipeline:

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Raw Log    │ →  │   Parse     │ →  │  Enrich     │ →  │  Normalize  │
│  (Apache,   │    │  (Regex,    │    │  (GeoIP,    │    │  (ECS, CIM,│
│  Windows,   │    │  Grok,      │    │  Threat     │    │  ASIM)      │
│  JSON)      │    │  Dissect)   │    │  Intel, AD) │    │             │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

Log Aggregation Architecture Patterns

Pattern 1: Direct to SIEM (Small Orgs)

Endpoints → Splunk UF / Filebeat → Splunk / Elastic

• Simple, low latency
• No intermediate buffering
• Risk: SIEM outage = data loss

Pattern 2: Message Queue Buffering (Mid-Size)

Endpoints → Fluent Bit → Kafka → Logstash → Elastic

• Kafka provides buffering and replay
• Decouples collection from analysis
• Better for high-volume or bursty environments

Pattern 3: Cloud-Native Pipeline (Cloud-First)

CloudWatch / Azure Monitor / GCP Logging → Data Firehose / Event Hub → S3 / Data Lake → Athena / Spark → SIEM

• efficient for high volume
• Enables long-term storage and batch analytics
• Higher latency for real-time alerting

Pattern 4: Multi-Cloud Federation (Enterprise)

AWS CloudTrail → Kinesis → Lambda (normalize) → Kafka
Azure Activity Logs → Event Hub → Function (normalize) → Kafka
On-Prem syslog → syslog-ng → Kafka
Kafka → Splunk / Sentinel / Elastic (central SIEM)

• Unified schema across all sources
• Complex to build and maintain
• Requires dedicated data engineering team

💡 Tip from Singahi: We recommend Pattern 2 for organizations with 100–5,000 employees and Pattern 4 for organizations above 5,000 employees or with multi-cloud requirements. Pattern 1 is acceptable for under 100 employees but will create pain as you scale.

SIEM Deep Dive

A SIEM is the brain of your monitoring operation. Choosing the wrong one is a multi-year mistake. This section covers the major platforms in forensic detail.

Splunk Enterprise / Splunk Cloud

Splunk Enterprise Security (ES):

• Pre-built correlation searches for common use cases
• Risk scoring framework
• Notable event management
• Threat intelligence framework (STIX/TAXII)
• Incident Review dashboard
• overhead: Additional license on top of Splunk base

Splunk SOAR:

• Playbook automation
• 300+ integrations
• Case management
• overhead: Additional license, but essential for SOC efficiency

Splunk for ISO 27001:

• Pre-built compliance dashboard for ISO 27001
• Data models for Authentication, Change, Endpoint, Network
• Ability to map events to Annex A controls

IBM QRadar

QRadar Differentiators:

• QRadar Network Insights: Deep packet inspection without decryption
• QRadar User Behavior Analytics (UBA): Free add-on for user anomaly detection
• QRadar Vulnerability Manager: Integration with vulnerability data for risk-based prioritization
• QRadar Advisor with Watson: AI-assisted threat investigation (limited value in practice)

Microsoft Sentinel

Sentinel Key Features:

• Microsoft 365 Defender Integration: Automatic ingestion of Defender for Endpoint, Identity, Cloud Apps, and Office 365 alerts
• Built-in SOAR: Azure Logic Apps playbooks for automation
• Microsoft Threat Intelligence: Free integration with Microsoft TI feeds
• Hunting Queries: Community-driven KQL queries (GitHub: Azure/Azure-Sentinel)
• Fusion ML: Multi-stage attack detection across signals
• UEBA: Built-in (requires Azure AD P2)

Sentinel licensing Reality:

• A 500-person company with Microsoft 365 E5 gets significant data ingestion included

Google Chronicle

Chronicle Unique Value:

• Unlimited Retention: All data retained at no extra overhead. This is a paradigm shift for forensic investigations.
• Asset-Entity Graph: Automatic entity extraction (users, devices, IPs) and relationship mapping
• Curated Detections: Google/Mandiant-authored YARA-L rules
• VirusTotal Enterprise: Included for file/hash investigation

Elastic Security (Elastic Stack)

Elastic Security Components:

• Elastic Agent: Unified agent replacing Beats
• Fleet: Centralized agent management
• Detection Engine: Rule-based detection with KQL + EQL (Event Query Language)
• Cases: Built-in case management
• Osquery Manager: Live endpoint querying
• Threat Intelligence: STIX/TAXII integration, custom IOC lists
• ML Jobs: Anomaly detection for rare events, unusual traffic, beaconing

Elastic licensing (Self-Managed):

• Open source (free): Core SIEM functionality
• Key advantage: You pay for infrastructure, not per GB. High-volume environments can be dramatically cheaper.

LogRhythm

Sumo Logic

Datadog Security Monitoring

Datadog Security Products:

• Security Monitoring: SIEM capability (log analysis, detection rules)
• Cloud SIEM: Full SIEM with dashboards, case management
• Cloud Security Posture Management (CSPM): Misconfiguration detection
• Cloud Workload Security (CWS): Runtime threat detection (Falco-like)
• Application Security Management (ASM): In-app threat detection (RASP-like)

New Relic Security

Wazuh (Open Source)

Wazuh Capabilities:

• Log Analysis: Collects and analyzes logs from endpoints, network devices, applications
• File Integrity Monitoring (FIM): Detects file changes in real-time
• Malware Detection: Rootkit detection, anomaly detection
• Active Response: Automated blocking of IPs, disabling accounts
• Vulnerability Detection: Scans endpoints for CVEs
• CSPM: Cloud security posture for AWS, Azure, GCP
• Container Security: Docker and Kubernetes monitoring

Graylog (Open Source)

SIEM Comparison by Organization Size

SIEM licensing Models Explained

overhead Optimization Strategies:

1. Filter before ingest: Drop debug logs, health checks, and duplicate events at the collector
2. Use hot/warm/cold tiers: Only keep recent data in premium-tier hot storage
3. Selective parsing: Not every field needs to be indexed
4. Sample high-volume logs: Application performance metrics can be sampled 1:100
5. Dedicated ingestion windows: Batch non-critical logs during off-peak hours
6. Negotiate commit tiers: Sentinel and Splunk offer significant discounts for volume commitments

Security Monitoring Use Cases

This is where most guides stay generic. Here are specific, actionable detection use cases with exact detection logic.

Use Case 1: Account Compromise

Scenario: Attacker obtains credentials via phishing or credential stuffing and logs into a corporate account.

Detection Logic:

Example Splunk SPL:

| tstats `summariesonly` count from datamodel=Authentication by _time, src_user, src_ip, action
| where action="failure"
| stats count by src_user, src_ip
| where count > 5
| lookup geo_ip src_ip as src_ip
| where distance(src_lat, src_lon, user_home_lat, user_home_lon) > 500 AND time_window < 2h
| eval severity="high"

Use Case 2: Privilege Escalation

Scenario: Attacker or insider elevates privileges to gain unauthorized access.

Detection Logic:

Example Sigma Rule (Privilege Escalation, Local Admin):

title: User Added to Local Administrators
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4732
    TargetUserName: Administrators
  condition: selection
level: high

Use Case 3: Lateral Movement

Scenario: Attacker moves from compromised endpoint to other systems within the network.

Detection Logic:

Use Case 4: Data Exfiltration

Scenario: Sensitive data is transferred out of the organization.

Detection Logic:

Example KQL (Sentinel, Data Exfiltration via Email):

OfficeActivity
| where Operation == "Send" and RecipientScope == "External"
| where Attachments has_any ("pdf", "docx", "xlsx", "csv", "zip")
| extend AttachmentSize = toint(AttachmentsSize)
| where AttachmentSize > 52428800  // 50MB
| summarize TotalSize=sum(AttachmentSize), Count=count() by UserId, bin(TimeGenerated, 1h)
| where Count > 10 or TotalSize > 500000000  // 500MB
| project TimeGenerated, UserId, TotalSize, Count

Use Case 5: Malware and Ransomware

Detection Logic:

Use Case 6: DDoS Attack

Detection Logic:

Use Case 7: Insider Threat

Detection Logic:

Use Case 8: Brute Force and Credential Stuffing

Detection Logic:

Use Case 9: API Abuse

Detection Logic:

Use Case 10: Cloud Misconfiguration Exploitation

Detection Logic:

Detection Engineering

Detection engineering is the discipline of building, testing, and maintaining detection logic. It is the core technical function of a modern security monitoring program.

The Detection Engineering Lifecycle

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  RESEARCH    │ →  │  DEVELOP     │ →  │  TEST        │ →  │  DEPLOY      │ →  │  MAINTAIN    │
│  (Threat     │    │  (Write rule,│    │  (Unit test, │    │  (CI/CD,     │    │  (Tune, update│
│  intel,      │    │  query,      │    │  integration │    │  version     │    │  for new     │
│  incident    │    │  playbook)   │    │  test,       │    │  control,    │    │  variants,   │
│  post-mortem)│    │              │    │  red team)   │    │  rollback)   │    │  deprecate)  │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

Rule Writing Frameworks

Sigma

Sigma is the generic signature format for SIEM rules. It allows you to write one rule and convert it to Splunk SPL, KQL, Elastic DSL, QRadar AQL, and others.

Why Sigma matters:

• Vendor-agnostic rule format
• Large community repository (github.com/SigmaHQ/sigma)
• Enables rule portability between SIEMs
• Supports CI/CD for detection engineering

Example Sigma Rule (Suspicious PowerShell Download):

title: Suspicious PowerShell Download
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'IEX(New-Object Net.WebClient)'
      - 'Invoke-Expression'
      - 'bitsadmin'
      - 'certutil -urlcache'
  condition: selection
falsepositives:
  - Legitimate administrative scripts
level: high

Sigma Rule Conversion:

## Convert to Splunk SPL
sigmac -t splunk rule.yml

## Convert to Microsoft Sentinel KQL
sigmac -t azure Sentinel rule.yml

## Convert to Elastic DSL
sigmac -t es-qs rule.yml

## Convert to QRadar AQL
sigmac -t qradar rule.yml

YARA

YARA is the pattern matching tool for malware identification and classification. While primarily for files, YARA-L is used in Chronicle for log-based detection.

YARA for File Detection:

rule APT_MALWARE_Example {
    meta:
        description = "Detects known APT malware family"
        author = "Security Team"
        date = "2026-06-15"
    strings:
    condition:
}

YARA-L for Log Detection (Chronicle):

rule suspicious_dns_tunneling {
  meta:
    author = "Security Team"
    description = "Detects potential DNS tunneling"
  events:
    
    
    condition:
}

Snort / Suricata Rules (Network Detection)

For organizations running IDS/IPS or network detection:

alert tcp any any -> any 443 (msg:"SUSPICIOUS TLS SNI - DGA Pattern"; 
    tls.sni; pcre:"/[a-z]{20,30}\.(com|net|org)/"; 
    sid:1000001; rev:1;)

Detection-as-Code

Detection-as-Code is the practice of managing detection rules with the same rigor as application code.

Principles:

1. Version control: All rules in Git
2. Peer review: Pull requests for rule changes
3. Automated testing: Unit tests for every rule
4. CI/CD deployment: Rules deployed via pipeline, not manual UI configuration
5. Documentation: Every rule has a README explaining logic, false positives, and response
6. Metrics: Track rule performance, false positive rate, and detection latency

Sample Detection-as-Code Repository Structure:

detections/
├── windows/
│   ├── privilege_escalation/
│   │   ├── local_admin_addition.yml
│   │   ├── local_admin_addition_test.py
│   │   └── README.md
│   ├── lateral_movement/
│   │   ├── psexec_execution.yml
│   │   └── wmi_lateral_movement.yml
│   └── malware/
│       ├── ransomware_behavior.yml
│       └── cobalt_strike_beacon.yml
├── linux/
│   ├── privilege_escalation/
│   ├── persistence/
│   └── lateral_movement/
├── cloud/
│   ├── aws/
│   ├── azure/
│   └── gcp/
├── network/
│   ├── dns_tunneling.yml
│   └── c2_beaconing.yml
└── tests/
    ├── data/
    │   ├── windows_security.log
    │   ├── cloudtrail.json
    │   └── sysmon.json
    └── test_runner.py

CI/CD Pipeline for Detection Rules:

## .github/workflows/detection-deploy.yml
name: Detection Deployment
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Sigma CLI
        run: pip install sigmatools
      - name: Validate Sigma Rules
        run: sigma check detections/
      - name: Convert and Test Rules
        run: |
          python tests/test_runner.py --target-splunk
          python tests/test_runner.py --target-sentinel
  
  deploy-splunk:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Splunk
        run: |
          python scripts/deploy_splunk.py --env production
        env:

  deploy-sentinel:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Sentinel
        run: |
          python scripts/deploy_sentinel.py --env production
        env:

Testing Detections

Every detection rule must be tested before deployment. Testing methods:

Red Team Test Example (Account Compromise):

## Step 1: Create test account
create_test_user "detection_test_user"

## Step 2: Simulate impossible travel
login_from "detection_test_user" "New York"    # 9:00 AM EST
login_from "detection_test_user" "Tokyo"     # 9:30 AM EST (impossible)

## Step 3: Verify detection fires within 15 minutes
assert_detection_fired "impossible_travel" "detection_test_user" within 15m

## Step 4: Cleanup
delete_test_user "detection_test_user"

False Positive Tuning

False positives destroy SOC credibility. The tuning process:

1. Measure baseline: Run rule in "monitoring mode" for 2 weeks. Count alerts per day.
2. Categorize: Tag each alert as true positive, false positive, or benign true positive.
3. Identify patterns: Are false positives from specific systems, users, or time windows?
4. Add exclusions: Add filter conditions to exclude known benign patterns.
5. Re-test: Run for another 2 weeks. Target < 5% false positive rate.
6. Document: Maintain exclusion documentation with business justification and expiry date.

Example Tuning Evolution:

## Version 1: Initial rule (too broad)
title: Off-Hours Login
detection:
  selection:
    EventID: 4624
    Hour: [0,1,2,3,4,5,22,23]
  condition: selection
## Result: 50 alerts/day. 90% false positive (night shift DBAs, offshore teams)

## Version 2: Add baseline exclusion
title: Off-Hours Login
detection:
  selection:
    EventID: 4624
    Hour: [0,1,2,3,4,5,22,23]
  filter:
    UserName|endswith: '_batch'  # Exclude service accounts
    UserName|startswith: 'dba_'   # Exclude known DBA accounts
  condition: selection and not filter
## Result: 10 alerts/day. 60% false positive (still catching offshore dev team)

## Version 3: Add geolocation and learning
title: Off-Hours Login
detection:
  selection:
    EventID: 4624
    Hour: [0,1,2,3,4,5,22,23]
  filter_known_users:
    UserName|endswith: '_batch'
  filter_baseline:
    UserName in known_offhours_users  # Dynamic lookup from UEBA baseline
  condition: selection and not filter_known_users and not filter_baseline
## Result: 3 alerts/day. 10% false positive. Actionable.

Coverage Mapping to MITRE ATT&CK

Map your detection rules to MITRE ATT&CK to identify gaps.

Gap Analysis Action:

• If > 20% of techniques in a tactic are red, prioritize building rules for that tactic
• Focus on techniques with high prevalence in your threat intelligence
• Update coverage map quarterly

UEBA & Behavioral Analytics

User and Entity Behavior Analytics (UEBA) detects anomalies by establishing baselines of normal behavior and flagging deviations. It is essential for detecting insider threats, compromised credentials, and slow-and-low attacks that signature-based rules miss.

What UEBA Actually Does

UEBA vs. Signature-Based Detection

Key UEBA Capabilities by Tool

Baseline Establishment Process

Phase 1: Data Collection (Week 1–2)

• Collect 30 days of activity data: logins, file access, email, web, application usage
• Ensure data quality: deduplicated, timestamped, actor-identified
• Include metadata: time, location, device, application, data sensitivity

Phase 2: Baseline Learning (Week 3–4)

• Calculate per-user baselines:
  • Login times (hours, days of week)
  • Geographic locations (cities, countries)
  • Devices used (laptop, mobile, VDI)
  • Applications accessed
  • File access volume and patterns
  • Data sensitivity levels accessed
  • Email volume and external recipients
  • Web categories visited
• Calculate peer group baselines (department, role, geography)
• Identify system-wide baselines (server traffic patterns, API baseline)

Phase 3: Threshold Setting (Week 5)

• Set anomaly thresholds:
  • Statistical: 3-sigma deviation from mean
  • Peer-based: Deviation from peer group median
  • Temporal: Off-hours defined by individual work pattern
  • Contextual: Unusual combination of activities
• Tune for false positives: Adjust thresholds until < 5% FP rate

Phase 4: Continuous Learning (Ongoing)

• Re-baseline quarterly
• Incorporate feedback from analyst investigations
• Adjust for role changes, seasonal patterns (quarter-end for finance)
• Retire old baselines for departed users

Risk Scoring Models

A practical risk scoring model combines multiple factors:

Risk Score = (Anomaly Score × Weight) + (Threat Intel Score × Weight) + (Asset Value × Weight)

Where:
- Anomaly Score (0–100): Deviation from baseline (login time, location, volume, peer group)
- Threat Intel Score (0–100): IOC match, known malicious IP, suspicious domain
- Asset Value (0–100): Sensitivity of data accessed (Public=0, Internal=20, Confidential=60, Highly Confidential=100)
- Weights: Typically 0.4, 0.3, 0.3

Example Risk Score Calculation:

Risk Score Thresholds:

Insider Threat Detection with UEBA

Insider threats are the hardest to detect because the actor has legitimate access. UEBA excels here.

Privacy Considerations:

• UEBA monitoring must be documented in privacy policy and employee agreements
• In EU, works councils may need to be consulted
• Avoid keystroke logging or screen recording without explicit legal basis
• Focus on data access patterns, not content (e.g., "accessed 500 files" not "read confidential merger document")
• Implement data minimization: only collect data needed for security
• Set retention limits: behavioral baselines should be deleted when user departs

💡 Tip from Singahi: UEBA is not a "set and forget" tool. It requires 2–4 weeks of learning, then continuous tuning. Organizations that buy Exabeam or Splunk UBA and never tune it end up with 200 daily alerts and an ignored queue. Assign a dedicated analyst for the first 90 days to provide feedback and tune thresholds.

Cloud Monitoring

Cloud monitoring is no longer optional. For most organizations, cloud infrastructure is the primary, or only, infrastructure. Monitoring cloud-native services requires cloud-native tools and techniques.

AWS CloudTrail

CloudTrail is the audit log of AWS. Every API call is recorded.

Critical CloudTrail Configurations:

CloudTrail Events to Alert On Immediately:

CloudTrail Log Analysis Example (Athena):

SELECT 
    eventTime,
    eventName,
    userIdentity.arn,
    sourceIPAddress,
    requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('DeleteTrail', 'StopLogging', 'PutBucketPolicy')
    AND eventTime > current_timestamp - interval '7' day
ORDER BY eventTime DESC;

AWS GuardDuty

GuardDuty is AWS's managed threat detection service. It uses ML and threat intelligence.

GuardDuty Integration:

• Forward findings to SIEM via EventBridge → Kinesis → Lambda → SIEM
• Use Security Hub for centralized AWS security findings
• Integrate with SOAR for automated response (e.g., isolate EC2 on GuardDuty finding)

Azure Monitor & Sentinel

Azure's monitoring stack is deeply integrated. Azure Monitor collects logs and metrics. Sentinel analyzes them.

Azure Monitor Data Sources:

Azure Sentinel Key Tables:

GCP Security Command Center

GCP's security monitoring is centered around Security Command Center (SCC).

GCP Cloud Audit Logs (Critical for Monitoring):

GCP Log Analysis Example (BigQuery):

SELECT
  timestamp,
  protoPayload.authenticationInfo.principalEmail,
  protoPayload.methodName,
  protoPayload.resourceLabels.project_id,
  protoPayload.serviceData.policyDelta.auditConfigDeltas
FROM `project-id.audit_logs.cloudaudit_googleapis_com_data_access`
WHERE protoPayload.methodName LIKE 'setIamPolicy'
  AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY timestamp DESC;

Multi-Cloud Monitoring Strategy

Most mid-to-large organizations use multiple clouds. A unified monitoring approach is essential.

Architecture Pattern: Centralized Cloud SIEM with Cloud-Native Feeds

┌────────────────────────────────────────────────────────────────────┐
│                    CENTRAL SIEM (Splunk / Sentinel / Elastic)       │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌──────────┐ │
│  │ Correlation │  │ Detection   │  │ Cases       │  │ Reporting│ │
│  │ Engine      │  │ Rules       │  │             │  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘  └──────────┘ │
└────────────────────────────────────────────────────────────────────┘
                              ▲
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
┌───────┴───────┐   ┌─────────┴─────────┐   ┌───────┴───────┐
│   AWS LANDING │   │   AZURE LANDING   │   │   GCP LANDING │
│   ZONE        │   │   ZONE            │   │   ZONE        │
│               │   │                   │   │               │
│ CloudTrail →  │   │ Activity Log →    │   │ Cloud Audit → │
│ Kinesis →    │   │ Event Hub →        │   │ Pub/Sub →     │
│ Lambda →     │   │ Function →          │   │ Function →    │
│ SIEM         │   │ SIEM                │   │ SIEM          │
│               │   │                   │   │               │
│ GuardDuty →  │   │ Defender for →      │   │ SCC →         │
│ SecurityHub →│   │ Cloud → SIEM        │   │ SIEM          │
│ SIEM         │   │                   │   │               │
└───────────────┘   └───────────────────┘   └───────────────┘

Multi-Cloud Monitoring Challenges:

CSPM Integration with Monitoring

Cloud Security Posture Management (CSPM) finds misconfigurations. Monitoring detects exploitation. They must work together.

Example CSPM → Monitoring Workflow:

1. CSPM detects S3 bucket is public (prisma:public-s3-bucket)
2. SIEM receives CSPM alert, creates low-priority ticket
3. CloudTrail shows GetObject operations on that bucket from unknown IP
4. SIEM correlates CSPM alert + CloudTrail anomaly → Critical alert
5. SOAR automatically blocks IP and restricts bucket policy

💡 Tip from Singahi: The biggest cloud monitoring gap we see is organizations enabling CloudTrail but never reviewing it. CloudTrail without alerting is just premium-tier storage. At minimum, set up alerts for ConsoleLogin, DeleteTrail, PutBucketPolicy, and AuthorizeSecurityGroupIngress. These 4 events cover 80% of critical cloud security incidents.

Kubernetes & Container Monitoring

Containers and Kubernetes have unique monitoring challenges: ephemeral infrastructure, shared kernels, and complex networking. Standard host-based monitoring is insufficient.

Kubernetes Audit Logs

K8s audit logs record every request to the API server. They are the CloudTrail of Kubernetes.

Enabling K8s Audit Logs:

For managed K8s (EKS, AKS, GKE), audit logs are partially enabled. For self-managed K8s, you must configure the API server.

## /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log all requests at the Metadata level
  - level: Metadata
    omitStages:
      - RequestReceived
  
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods", "pods/status", "pods/log"]
    omitStages:
      - RequestReceived
  
  # Log secret access at RequestResponse
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    omitStages:
      - RequestReceived
  
  # Log RBAC changes at RequestResponse
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
    omitStages:
      - RequestReceived
  
  # Log exec and attach at RequestResponse
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
    omitStages:
      - RequestReceived
  
  # Don't log health checks
  - level: None
    nonResourceURLs:
      - /healthz
      - /livez
      - /readyz

Critical K8s Audit Events to Monitor:

Example K8s Audit Alert (Falco + Fluent Bit):

## falco rule
- rule: Unauthorized K8s Secret Access
  desc: Detect reading secrets by non-service-account users
  condition: >
    k8s.audit.user != "system:serviceaccount:*" and
    k8s.audit.verb in ("get", "list") and
    k8s.audit.objectref.resource = "secrets"
  output: "Unauthorized secret access by user=%k8s.audit.user resource=%k8s.audit.objectref.name"
  priority: HIGH

Falco, Runtime Security

Falco is the open-source runtime security engine for containers. It detects unexpected behavior using system calls.

Falco Deployment Options:

Critical Falco Rules for Production:

## falco_rules.local.yaml
- rule: Privileged Container Started
  desc: Detect privileged container creation
  condition: >
    spawned_process and
    container.privileged = true
  output: "Privileged container started: %container.name"
  priority: CRITICAL

- rule: Sensitive File Access in Container
  desc: Detect access to /etc/shadow, /etc/passwd
  condition: >
    spawned_process and
    (proc.name in ("cat", "less", "more", "vim")) and
    (fd.name contains "/etc/shadow" or fd.name contains "/etc/passwd")
  output: "Sensitive file access: %proc.name %fd.name %container.name"
  priority: HIGH

- rule: Outbound Connection from Sensitive Container
  desc: Database containers should not make outbound connections
  condition: >
    outbound and
    container.name contains "database" and
    fd.type = "ipv4"
  output: "Outbound connection from database container: %container.name %fd.name"
  priority: HIGH

- rule: Shell Spawned in Container
  desc: Detect interactive shell in container
  condition: >
    spawned_process and
    shell_procs and
    container.id != "host"
  output: "Shell spawned in container: %proc.name %container.name"
  priority: MEDIUM

Admission Controllers

Admission controllers intercept requests to the K8s API server before persistence. They enforce policy.

Kyverno Policy Example (Block Privileged Containers):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged
spec:
  validationFailureAction: enforce
  rules:
  - name: validate-privileged
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Privileged containers are forbidden"
      pattern:
        spec:
          containers:
          - securityContext:
              =(privileged): "false"

Container Runtime Security

Beyond Falco, additional runtime security layers:

Service Mesh Monitoring

Service meshes (Istio, Linkerd) provide mTLS, traffic management, and observability.

Istio Security Monitoring:

## Monitor for mTLS policy violations
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
## Any connection without mTLS will be rejected and logged

Network Policies

K8s NetworkPolicies are firewall rules for pods. Monitoring them is essential.

Monitoring Network Policy Violations:

• Calico: calico-policy-controller logs denied packets
• Cilium: cilium monitor shows policy drops
• Weave: weave-npc logs denied connections
• Log these to SIEM and alert on denied connection attempts from sensitive namespaces

💡 Tip from Singahi: Most organizations deploying Kubernetes monitor pod CPU and memory but not K8s audit logs. The K8s API server is the control plane, every attack on K8s goes through it. Enable K8s audit logs, forward them to your SIEM, and alert on pods/exec, secrets/get, and clusterrolebindings/create. These 3 events catch 80% of K8s attacks.

Database Monitoring

Databases contain the crown jewels. Monitoring database activity is non-negotiable for ISO 27001 compliance.

Database Audit Log Categories

Database Activity Monitoring (DAM) Tools

DAM tools sit between the database and the application, monitoring all traffic without modifying the database.

Native Database Audit Configuration

PostgreSQL (pgaudit):

-- Install pgaudit extension
CREATE EXTENSION pgaudit;

-- Configure pgaudit in postgresql.conf
pgaudit.log = 'write, ddl, role'
pgaudit.log_catalog = off
pgaudit.log_parameter = on
pgaudit.log_statement_once = off
pgaudit.log_level = log

-- Audit specific tables
CREATE TABLE sensitive_customers (...);
ALTER TABLE sensitive_customers SET (pgaudit.log = 'all');

Microsoft SQL Server (SQL Server Audit):

-- Create server audit
USE master;
CREATE SERVER AUDIT ComplianceAudit
TO FILE (FILEPATH = 'D:\SQLAudit\', MAXSIZE = 100 MB, MAX_ROLLOVER_FILES = 10)
WITH (ON_FAILURE = CONTINUE);
ALTER SERVER AUDIT ComplianceAudit WITH (STATE = ON);

-- Create database audit specification
USE ProductionDB;
CREATE DATABASE AUDIT SPECIFICATION SensitiveDataAudit
FOR SERVER AUDIT ComplianceAudit
ADD (SELECT, INSERT, UPDATE, DELETE ON dbo.Customers BY public)
WITH (STATE = ON);

Oracle (Unified Audit Policy):

-- Create unified audit policy
CREATE AUDIT POLICY monitor_sensitive_data
ACTIONS SELECT, INSERT, UPDATE, DELETE ON hr.employees,
        SELECT, INSERT, UPDATE, DELETE ON hr.salary_data
WHEN 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') != ''HR_APP'''
EVALUATE PER STATEMENT;

-- Enable policy
AUDIT POLICY monitor_sensitive_data;

Query Analysis for Security

Monitor query patterns for signs of abuse:

Database Access Pattern Monitoring

Establish baselines for database access:

DLP for Databases

Database DLP prevents sensitive data from leaving the database environment.

💡 Tip from Singahi: Database monitoring is the most commonly neglected area in ISO 27001 implementations. Organizations monitor firewalls and endpoints but treat databases as "internal" and safe. The majority of data breaches involve database compromise. At minimum, enable native database audit logs, forward them to your SIEM, and alert on failed logins, privilege changes, and off-hours access. Native audit is free, use it.

Network Monitoring

Network monitoring is the foundation of security visibility. Even in a zero-trust world, network telemetry reveals attacker movement, data exfiltration, and command-and-control communication.

NetFlow, sFlow, and IPFIX

Flow protocols summarize network traffic metadata without capturing full packets.

Flow Analysis for Security:

Packet Capture (Full PCAP)

Full packet capture provides the deepest visibility but at the highest overhead.

Arkime (Open-Source PCAP Analysis):

• High-performance full packet capture and indexing
• Web-based search and session reconstruction
• Supports 10Gbps+ capture rates
• Integrates with YARA for file extraction
• overhead: free (open source), requires significant storage infrastructure

Storage Calculation for PCAP:

1 Gbps network = 125 MB/s = 450 GB/hour = 10.8 TB/day = 324 TB/month
At 10 Gbps: 108 TB/day = 3.2 PB/month

Solution: Capture only on critical segments, use flow for everything else, trigger PCAP on alert.

IDS / IPS

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) inspect traffic for known attack signatures.

Suricata Rule Example (C2 Beaconing):

    msg:"SUSPICIOUS TLS SNI - DGA Pattern";
    classtype:trojan-activity; sid:1000001; rev:1;
)

Zeek Script Example (Detect RDP over Non-Standard Port):

## rdp_anomaly.zeek
event RDP::client_connect(c: connection)
    {
        {
        }
    }

Network Detection and Response (NDR)

NDR tools use AI/ML to detect network anomalies without signatures or decryption.

NDR vs. IDS/IPS:

Best practice: Run both. IDS/IPS for known threats and blocking. NDR for unknown threats and behavioral detection.

Encrypted Traffic Analysis

With 90%+ of web traffic encrypted, traditional deep packet inspection is increasingly ineffective.

JA3 Fingerprinting Example:

## JA3 is a TLS fingerprint based on Client Hello
## Normal Chrome: ja3=769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0
## Metasploit: ja3=769,53-47-5-10-49161-49162-49171-49172-50-56-19-4,65281-0-11-35-5-16,23-24-25,0
## Alert when JA3 matches known malware fingerprint

DNS Monitoring

DNS is the most underutilized monitoring source. 80% of malware uses DNS for C2.

DNS Logging Configuration (Windows DNS):

## Enable debug logging (not for production scale, use analytic logs for scale)
dnscmd /Config /LogLevel 0x8100F331
## Or use Windows DNS Analytical Logs (Event ID 1000+)
## Enable in DNS Manager → Properties → Event Logging → Analytical

DNS Monitoring Alert Example (KQL):

// Detect potential DGA activity
DNS_Logs
| where TimeGenerated > ago(1h)
| summarize QueryCount=count(), UniqueDomains=dcount(QueryName) by ClientIP
| where QueryCount > 100 and UniqueDomains > 50
| extend DGAScore = QueryCount * UniqueDomains
| where DGAScore > 5000
| project ClientIP, QueryCount, UniqueDomains, DGAScore
| sort by DGAScore desc

💡 Tip from Singahi: If you do one thing for network monitoring this quarter, enable DNS query logging and forward it to your SIEM. DNS is free telemetry that catches malware C2, data exfiltration, and phishing. Most organizations already have DNS infrastructure, they just don't log it. BIND, Windows DNS, and Infoblox all support query logging. Turn it on.

Endpoint Monitoring

Endpoints are where attacks begin and where data resides. EDR/XDR provides the granular visibility needed to detect and respond to endpoint threats.

EDR / XDR Landscape

EDR Data Sources

Modern EDRs collect extensive telemetry:

Sysmon, The Essential Windows Telemetry

Sysmon is a free Microsoft tool that provides deep Windows telemetry. Every EDR uses Sysmon-like data. Even with a commercial EDR, Sysmon provides independent visibility.

Critical Sysmon Event IDs:

Sysmon Configuration (Best Practice, SwiftOnSecurity):

<!-- sysmonconfig-export.xml by SwiftOnSecurity -->
<Sysmon schemaversion="4.90">
  <HashAlgorithms>sha256,IMPHASH</HashAlgorithms>
  <EventFiltering>
    <!-- Process creation -->
    <RuleGroup name="Process Creation" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Image condition="begin with">C:\Windows\</Image>
        <Image condition="begin with">C:\Users\</Image>
        <CommandLine condition="contains">powershell</CommandLine>
        <CommandLine condition="contains">certutil</CommandLine>
        <CommandLine condition="contains">bitsadmin</CommandLine>
      </ProcessCreate>
    </RuleGroup>
    
    <!-- Network connections -->
    <RuleGroup name="Network Connections" groupRelation="or">
      <NetworkConnect onmatch="include">
        <DestinationPort condition="is">443</DestinationPort>
        <DestinationPort condition="is">80</DestinationPort>
        <DestinationPort condition="is">53</DestinationPort>
      </NetworkConnect>
    </RuleGroup>
    
    <!-- Registry events -->
    <RuleGroup name="Registry Events" groupRelation="or">
      <RegistryEvent onmatch="include">
        <TargetObject condition="contains">Run</TargetObject>
        <TargetObject condition="contains">RunOnce</TargetObject>
        <TargetObject condition="contains">Shell</TargetObject>
      </RegistryEvent>
    </RuleGroup>
    
    <!-- File creation -->
    <RuleGroup name="File Creation" groupRelation="or">
      <FileCreate onmatch="include">
        <TargetFilename condition="end with">.exe</TargetFilename>
        <TargetFilename condition="end with">.dll</TargetFilename>
        <TargetFilename condition="end with">.ps1</TargetFilename>
      </FileCreate>
    </RuleGroup>
    
    <!-- Process access (credential dumping) -->
    <RuleGroup name="Process Access" groupRelation="or">
      <ProcessAccess onmatch="include">
        <TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
        <GrantedAccess condition="contains">0x1010</GrantedAccess>
      </ProcessAccess>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

EDR + SIEM + NDR Correlation

The power of modern security monitoring comes from correlating endpoint, network, and cloud data.

Correlation Example: Detecting Ransomware

Correlation Query (Splunk):

| tstats `summariesonly` count from datamodel=Endpoint.Processes where Processes.process_name=vssadmin.exe by _time, host, user
| join host [
    | tstats `summariesonly` count from datamodel=Endpoint.Filesystem where Filesystem.file_name=*.locked by _time, host
]
| join host [
    | tstats `summariesonly` count from datamodel=Network_Resolution.DNS where DNS.query=*.onion.to by _time, host
]
| stats count by host, user
| where count > 3
| eval alert_type="ransomware_correlation"

XDR: Extended Detection and Response

XDR extends EDR by integrating data from multiple sources into a unified detection and response platform.

XDR vs. SIEM + EDR:

💡 Tip from Singahi: For Microsoft-heavy organizations (Azure, M365, Windows), Microsoft Defender XDR + Sentinel is the most efficient and integrated option. For heterogeneous environments (Linux, AWS, GCP, diverse endpoints), a best-of-breed approach (CrowdStrike + Splunk/Elastic) provides more flexibility. The key is correlation, if your EDR and SIEM don't talk to each other, you're doing detection in silos.

Alert Management

A SIEM without alert management is a noise generator. Alert management is the discipline of turning raw alerts into actionable incidents.

Alert Triage Process

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   ALERT     │ →  │  ENRICHMENT │ →  │  PRIORITIZE │ →  │  DECISION   │
│  (Raw SIEM  │    │  (Add context│    │  (Score risk,│    │  (Investigate│
│   detection) │    │  : user, asset│    │  check SLA) │    │  , escalate,│
│              │    │  , threat intel│    │             │    │  or dismiss)│
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

Alert Enrichment (Automated):

Alert Prioritization Framework

Not all alerts are equal. Use a risk-based prioritization matrix:

Alert Fatigue Reduction

Alert fatigue is the #1 reason SOC analysts miss real threats. The average SOC receives 10,000+ alerts per day. 90% are false positives.

Alert Fatigue Reduction Strategies:

Alert Correlation Example:

Before correlation:
- 10:00: Failed login from 192.168.1.1 (Alert #1)
- 10:01: Failed login from 192.168.1.1 (Alert #2)
- 10:02: Failed login from 192.168.1.1 (Alert #3)
... (50 alerts)
- 10:15: Successful login from 192.168.1.1 (Alert #51)
- 10:16: Privileged command executed (Alert #52)

After correlation:
- Incident #1: Brute force attack followed by successful compromise (1 incident, 52 correlated alerts)

SOAR, Security Orchestration, Automation, and Response

SOAR automates repetitive SOC tasks.

Common SOAR Playbooks:

💡 Tip from Singahi: Alert fatigue is the silent killer of security monitoring programs. We've seen SOC teams with 50,000 daily alerts where analysts spend 100% of their time on false positives and 0% on real threats. If your SOC has more than 100 actionable alerts per analyst per day, you have an alert fatigue problem. The fix is not hiring more analysts, it's tuning your rules. We typically reduce alert volume by 60–80% in the first 30 days of engagement through systematic tuning.

The SOC Operating Model

A Security Operations Center (SOC) is the organizational engine that executes monitoring. Without a defined operating model, even the best tools fail.

SOC Tiers

SOC Shift Schedules

Shift Handoff Protocol:

Every shift change must include:

1. Active incident status (open incidents, severity, current owner)
2. Alerts requiring follow-up (triage incomplete, awaiting enrichment)
3. System health issues (SIEM lag, agent failures, tool outages)
4. Threat intelligence updates (new IOCs, active campaigns)
5. Scheduled maintenance or changes (planned downtime, rule deployments)

SOC Runbooks

A runbook is a step-by-step procedure for handling specific alert types.

Runbook Structure:

Escalation Matrix

SOC Metrics & Staffing Model

Staffing Formula:

Analysts needed = (Alerts per day × Avg time per alert) / (Hours per day × Analyst efficiency)

Example:
- 2,000 alerts/day
- 10 minutes average triage time
- 8 hours/day effective work (accounting for breaks, meetings)
- 70% efficiency (30% of time spent on non-alert work: training, tuning, projects)

Analysts needed = (2,000 × 10) / (480 × 0.70) = 20,000 / 336 = 59 analyst-hours/day = 7.4 → 8 analysts

For 24/7 coverage with 8 analysts: Use hybrid MDR model or accept 8×5 coverage with on-call escalation.

Metrics & KPIs

What gets measured gets managed. Security monitoring metrics must be precise, actionable, and benchmarked.

The Essential Metrics Dashboard

Benchmarking Your SOC

SIEM Performance Metrics

Tool Comparison

Complete SIEM / Security Monitoring Matrix

Open Source Stack for Budget-Conscious Organizations

If budget is constrained, this open-source stack provides 80% of enterprise capability at 10% of the overhead:

Trade-offs:

• No vendor support (community support only)
• Requires internal expertise
• Higher time-to-value
• Less polished UX
• Integration between tools requires manual work

Implementation Roadmap: 8 Weeks

Week 1: Assessment & Planning

Week 2: Core Infrastructure

Week 3: Detection Rules

Week 4: Cloud & Advanced Sources

Week 5: Alert Management & Triage

Week 6: UEBA & Behavioral Analytics

Week 7: Detection Engineering & Tuning

Week 8: Metrics, Audit Readiness & Handoff

Week 8 Milestone: ISO 27001 A.8.16 Audit Ready

Common Audit Failures & Fixes

After guiding 50+ companies through ISO 27001 audits, we've seen the same A.8.16 non-conformities repeatedly. Here's how to avoid them.

Failure 1: No Centralized Log Collection

Auditor finding: "Logs are stored only on local systems. There is no evidence of centralized collection or review."

Why it happens: Organizations enable logging on each server but never configure forwarding. They think "we have logs" means "we are compliant."

The fix:

1. Deploy a syslog collector (rsyslog, syslog-ng, or Splunk UF) within 2 weeks
2. Forward all critical Windows events via WEF or Winlogbeat
3. Forward all Linux auth logs via rsyslog
4. Verify collection daily: create a dashboard showing log source health
5. Document the architecture in the monitoring policy

Evidence for audit: SIEM dashboard showing active log sources, network diagram of log flow, policy section on collection.

Failure 2: Logs Are Not Reviewed

Auditor finding: "Logs are collected but there is no evidence of regular review or analysis for security events."

Why it happens: The SIEM is a "set and forget" tool. Alerts fire into email but no one has time to review them.

The fix:

1. Define review frequency: real-time alerts for critical events, daily triage for high/medium, weekly trend analysis
2. Assign specific people to review (named in policy, not "the IT team")
3. Document every review: date, reviewer, scope, findings, actions taken
4. Start with just 30 minutes per day. Review yesterday's authentication failures and privilege changes.
5. Use SOAR to auto-dismiss obvious false positives, reducing review burden

Evidence for audit: Log review logs, daily triage tickets, weekly summary reports, incident records created from log reviews.

Failure 3: No Alerting on Critical Events

Auditor finding: "The organization collects logs but has no automated alerting configured for anomalous behavior."

Why it happens: Organizations confuse log collection with monitoring. Monitoring requires detection and response.

The fix:

1. Define 10 critical events that must generate alerts (see Section 8)
2. Configure these alerts in your SIEM within 1 week
3. Ensure alerts go to someone who is accountable (not a group mailbox that no one owns)
4. Test each alert monthly: simulate the event, verify the alert fires
5. Document alert configuration and response procedures

Evidence for audit: Screenshot of alert configuration, test records, incident tickets created from alerts.

Failure 4: Insufficient Log Retention

Auditor finding: "Logs are retained for 30 days, but the policy requires 90 days, and regulatory requirements mandate 1 year."

Why it happens: Default settings are accepted. Disk space is premium-tier. No one checks retention against policy.

The fix:

1. Define retention periods by log type and regulation:
   • Authentication logs: 1 year
   • Firewall logs: 90 days hot, 1 year warm
   • Application logs: 90 days
   • Cloud audit logs: 1 year (AWS CloudTrail default)
2. Implement hot/warm/cold tiering: recent data in fast storage, old data in cheap archive
3. Automate archival: S3 Glacier, Azure Archive, or tape backup
4. Verify retention quarterly: restore a random archive log and confirm readability
5. Document retention policy and technical implementation

Evidence for audit: Retention policy, storage configuration, sample archived log, quarterly verification records.

Failure 5: Clock Synchronization Issues

Auditor finding: "System clocks are not synchronized. Log timestamps vary by more than 5 minutes across systems, making correlation impossible."

Why it happens: NTP is not configured on all devices, or devices are using different NTP servers with drift.

The fix:

1. Deploy central NTP servers (pool.ntp.org or internal Stratum 2)
2. Configure all Windows systems to sync with domain controllers (which sync to NTP)
3. Configure all Linux systems with chronyd or ntpd pointing to central NTP
4. Configure network devices, firewalls, and appliances to sync to NTP
5. Verify daily: run a script that checks time drift across all systems
6. Set alarm if drift > 1 second

Evidence for audit: NTP configuration files, time drift check results, SIEM query showing consistent timestamps.

Failure 6: No Monitoring of Cloud Infrastructure

Auditor finding: "The organization operates workloads in AWS but the monitoring policy and SIEM do not cover cloud events."

Why it happens: Cloud monitoring requires different tools and expertise. On-prem teams don't extend their scope to cloud.

The fix:

1. Enable CloudTrail (AWS), Activity Log (Azure), or Cloud Audit Logs (GCP) in all regions
2. Forward cloud audit logs to your SIEM using native connectors or Event Hub/Kinesis
3. Configure alerts for cloud-specific events: IAM changes, public resource creation, root account use
4. Include cloud in monitoring policy scope
5. Assign cloud security monitoring responsibility to a named person

Evidence for audit: CloudTrail configuration screenshot, SIEM showing cloud events, policy section on cloud monitoring.

Failure 7: Privileged User Activity Not Monitored

Auditor finding: "There is no specific monitoring or alerting for administrator and privileged user activities."

Why it happens: Administrators are trusted, so their activity is not scrutinized. Or, admins object to being monitored.

The fix:

1. Log all privileged actions: sudo usage, admin group membership changes, IAM policy changes
2. Alert on privileged actions: create a dedicated alert channel for admin activity
3. Review admin activity weekly: separate review from standard user activity
4. Implement break-glass procedures: emergency admin access requires manager approval and is fully logged
5. No admin should be able to clear or modify their own logs

Evidence for audit: Privileged user monitoring dashboard, weekly admin review records, break-glass procedure.

Failure 8: Monitoring Policy Does Not Exist

Auditor finding: "There is no documented policy or procedure for monitoring activities."

Why it happens: Organizations focus on tools and forget governance. "We have Splunk" is not a policy.

The fix:

1. Write a monitoring policy (see Section 2 for minimum requirements)
2. Get it approved by management (CISO or CEO depending on org size)
3. Publish it on the intranet or document management system
4. Communicate it to all relevant personnel (IT, security, operations)
5. Review annually and after significant changes

Evidence for audit: Signed policy document, communication records, acknowledgment tracking, review records.

Failure 9: No Response Procedure for Anomalies

Auditor finding: "Anomalies are detected but there is no defined procedure for evaluating or escalating potential incidents."

Why it happens: Alerts fire but no one knows what to do. The link between monitoring and incident response is broken.

The fix:

1. Define anomaly severity levels (Critical, High, Medium, Low)
2. Map each severity to a response action:
   • Critical: Immediate SOC investigation, potential incident escalation
   • High: SOC investigation within 1 hour
   • Medium: Daily batch review
   • Low: Weekly trend review
3. Document escalation to incident response (A.5.24)
4. Create runbooks for top 5 anomaly types (see Section 17)
5. Test the escalation path quarterly: simulate an anomaly, verify IR is engaged

Evidence for audit: Anomaly response procedure, runbooks, escalation test records, incident tickets created from anomalies.

Failure 10: Third-Party Access Not Monitored

Auditor finding: "Vendor and contractor access to systems is not subject to the same monitoring as employee access."

Why it happens: Third-party accounts are created but not included in monitoring scope. Vendor VPNs are separate from corporate VPN.

The fix:

1. Include all third-party accounts in identity monitoring (same as employees)
2. Log and alert on all vendor access: VPN, RDP, cloud console, application access
3. Review vendor access weekly or monthly
4. Implement time-bound access: vendor accounts expire automatically
5. Require vendors to provide their own audit logs for critical systems

Evidence for audit: Vendor access logs, vendor monitoring dashboard, third-party access review records.

Illustrative Scenarios: Breaches That Monitoring Could Have Prevented

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

What happened:

• Attackers compromised an HVAC vendor's credentials (Fazio Mechanical)
• Used vendor access to enter Target's network
• Moved laterally to the POS system
• Installed malware on POS terminals
• Exfiltrated 40 million credit card numbers and 70 million customer records

Monitoring failures:

• Target had a SIEM (FireEye) but did not monitor vendor access adequately
• The SIEM generated alerts for the malware installation, but alerts were not reviewed or acted upon
• Lateral movement (HVAC network → POS network) was not segmented or monitored
• Data exfiltration over weeks went undetected

What proper monitoring would have caught:

1. Vendor access alert: "Vendor account logged in at 2 AM, accessed file server, then POS network"
2. Malware detection: FireEye alert (which did fire) escalated to immediate response
3. Lateral movement: "Connection from HVAC VLAN to POS VLAN detected"
4. Data exfiltration: "Unusual outbound FTP connection from POS server"

Lesson: A SIEM without alert review and response is just premium-tier storage. The FireEye alert fired. No one acted.

Illustrative Scenario 2: Equifax (2017), The 147 Million Record Breach

What happened:

• Apache Struts vulnerability (CVE-2017-5638) was exploited
• Attackers gained access to Equifax's dispute portal
• Moved laterally through the network
• Accessed databases containing personal data
• Exfiltrated data over 76 days

Monitoring failures:

• Vulnerability scanning (A.8.8) failed to identify the Apache Struts vulnerability promptly
• Network monitoring did not detect the initial exploitation or lateral movement
• Database monitoring did not detect unauthorized database queries
• Data exfiltration went unnoticed for 76 days
• SSL certificate monitoring failed: Equifax discovered the breach only when they renewed an SSL certificate and noticed anomalous traffic

What proper monitoring would have caught:

1. Web application monitoring: "Apache Struts exploitation attempt detected by WAF"
2. Network monitoring: "Unusual connection from web server to database server"
3. Database monitoring: "Database queries from web server IP returning 147M records"
4. Data exfiltration: "76-day sustained outbound transfer of 30GB+ to unknown IP"
5. Certificate monitoring: This should not have been the detection mechanism

Lesson: Monitoring must be layered. Relying on a single point of failure (SSL certificate renewal) for breach detection is negligence. Network + application + database monitoring would have caught this at multiple stages.

Illustrative Scenario 3: SolarWinds / Sunburst (2020), The Supply Chain Breach

What happened:

• Attackers compromised SolarWinds' build system
• Inserted malicious code into Orion software updates
• 18,000 organizations downloaded the backdoored update
• Attackers used the backdoor to access select high-value targets (including government agencies)
• Activity went undetected for months

Monitoring failures:

• Organizations that did not monitor outbound DNS from their Orion servers missed the C2 beaconing
• UEBA was missing: The Orion server making outbound HTTPS to unknown domains was anomalous
• Supply chain monitoring: No one monitored the integrity of the software update itself
• Cloud monitoring: Attackers accessed Azure AD and Office 365, which was not monitored for anomalous application access

What proper monitoring would have caught:

1. DNS monitoring: "Orion server querying avsvmcloud.com [DGA-like domain] every 60 seconds"
2. UEBA: "SolarWinds server making HTTPS to unknown domain, never seen before"
3. Cloud monitoring: "Application 'SolarWinds Orion' accessing Azure AD with unusual permissions"
4. Network monitoring: "Beaconing pattern detected: 60-second intervals to same external IP"

Lesson: Supply chain attacks require monitoring the vendor's behavior within your environment. The software was trusted, but its behavior was anomalous. DNS and behavioral monitoring catch supply chain compromises when signature-based tools cannot.

Illustrative Scenario 4: Colonial Pipeline (2021), Ransomware and Operational Shutdown

What happened:

• Attackers compromised Colonial Pipeline via a leaked VPN password
• Used the VPN to access the business network
• Deployed DarkSide ransomware
• Colonial shut down the pipeline (operational network) as a precaution
• Caused fuel shortages across the US East Coast

Monitoring failures:

• VPN monitoring: No alert for VPN login from unusual location or with old password
• Credential monitoring: The VPN password was discovered in a breach database (no credential monitoring)
• OT/ICS monitoring: Separation between IT and OT was assumed but not monitored
• Ransomware indicators: No detection of ransomware precursor activities (AD reconnaissance, lateral movement, backup deletion)

What proper monitoring would have caught:

1. VPN monitoring: "VPN login from unexpected geography using old password"
2. Credential monitoring: "Password for VPN account found in Have I Been Pwned breach database"
3. Network monitoring: "Connection from IT network to OT network detected"
4. Endpoint monitoring: "DarkSide ransomware behavior: vssadmin delete shadows, mass file encryption"

Lesson: OT/ICS monitoring is critical. The pipeline was shut down not because ransomware hit the OT network, but because Colonial could not confirm that the OT network was safe. Monitoring the IT/OT boundary would have provided that confidence.

Illustrative Scenario 5: Uber (2016), The Cover-Up

What happened:

• Attackers accessed Uber's GitHub repository and found AWS access keys
• Used keys to access Uber's AWS S3 buckets
• Downloaded 57 million user and driver records
• Disclosure was delayed for over a year

Monitoring failures:

• Cloud monitoring: No alert for AWS access key usage from unknown IP or for bulk S3 downloads
• Code repository monitoring: No monitoring of GitHub for exposed credentials (secrets scanning)
• Data access monitoring: No alert for 57 million record download from S3
• Third-party monitoring: GitHub is a third-party SaaS; Uber did not monitor it for security

What proper monitoring would have caught:

1. Cloud monitoring: "AWS access key used from unknown IP address"
2. Cloud monitoring: "S3 bulk download: 57M objects accessed from single session"
3. Secrets monitoring: "AWS access key committed to GitHub repository"
4. Data monitoring: "Unusual data access pattern: entire user database downloaded"

Lesson: Cloud-native monitoring is essential. AWS CloudTrail would have recorded every API call. The data was there, Uber was not watching it. Additionally, secrets scanning in CI/CD (A.8.30) is a prerequisite to monitoring, don't commit credentials to repositories.

Multi-Framework Mapping

A.8.16 is not an island. Mapping it to other frameworks ensures compliance efficiency and audit readiness.

Annex A 8.16 Across Major Frameworks

Mapping: ISO 27001 A.8.16 → SOC 2 CC7.2

Mapping: ISO 27001 A.8.16 → PCI DSS v4.0

Mapping: ISO 27001 A.8.16 → NIST SP 800-53 Rev 5

Mapping: ISO 27001 A.8.16 → DORA (EU Digital Operational Resilience Act)

FAQ

Q1: Do I need a SIEM to pass an ISO 27001 audit for A.8.16?

No, but you need centralized monitoring and anomaly detection. A SIEM is the most common and effective way to achieve this. For small organizations, a centralized syslog server with daily manual review and basic alerting may be sufficient. However, as you scale, a SIEM becomes essential. The auditor will check: Are you monitoring? Are you detecting anomalies? Are you responding? A SIEM makes this easier but is not strictly mandatory.

Q2: What's the minimum budget for A.8.16 compliance?

For a small organization (under 50 employees), the minimum budget is:

For mid-market (50–500 employees):

For enterprise (500+ employees):

Q3: How do I monitor cloud-native services (serverless, managed databases)?

Cloud-native services are monitored via the cloud provider's APIs:

• Serverless (Lambda, Azure Functions, Cloud Functions): Enable function-level logging (CloudWatch Logs, Azure Monitor, Cloud Logging). Log every invocation, error, and cold start. Forward to SIEM.
• Managed databases (RDS, Azure SQL, Cloud Spanner): Enable native audit logs (RDS audit, Azure SQL Auditing, Cloud Audit Logs). These are API-accessible and forwardable to SIEM.
• Managed Kubernetes (EKS, AKS, GKE): Enable control plane logging (API server, audit, authenticator). Forward via Fluent Bit or cloud-native export.
• API Gateways: Enable access logging and execution logging. Forward to SIEM or cloud monitoring.

The key is to not treat cloud services as "black boxes." Every cloud service has logs. You just need to enable them and forward them.

Q4: What retention period is required for logs?

ISO 27001 does not specify a fixed retention period. It depends on:

• Your monitoring policy (which you define)
• Regulatory requirements (PCI DSS: 1 year, GDPR: as long as necessary for security)
• Legal requirements (litigation hold may require longer retention)
• Industry standards (financial services often require 3–7 years)

Singahi recommendation:

• Authentication logs: 1 year
• Security event logs: 1 year
• Application logs: 90 days
• Network flow logs: 90 days
• Full packet capture: 7–30 days (unless incident-related)
• Cloud audit logs: 1 year (or as required by cloud provider)
• Archive logs: 3–7 years in cold storage

Q5: How do I handle privacy concerns with user monitoring?

Monitoring user activity must balance security with privacy:

• Document monitoring in your acceptable use policy and privacy policy
• In EU, consult works council if applicable
• Monitor access patterns, not content where possible (e.g., "accessed 500 files" not "read confidential merger memo")
• Avoid keystroke logging or screen recording without explicit consent
• Implement data minimization: only collect what is necessary for security
• Set retention limits: delete user activity baselines when the user departs
• Allow access to one's own logs for transparency (where legally required)

Q6: What's the difference between A.8.15 (Logging) and A.8.16 (Monitoring)?

• A.8.15, Logging: The generation and protection of logs. Ensures logs exist, are accurate, and are protected from tampering. Technical control.
• A.8.16, Monitoring: The analysis of logs and systems for anomalous behavior. Requires detection, review, and response. Operational control.

You need both. A.8.15 without A.8.16 means you have logs but no one looks at them. A.8.16 without A.8.15 means you want to monitor but have no logs to analyze.

Q7: How do I detect zero-day attacks?

Zero-day attacks cannot be detected by signatures (no one knows the signature yet). Detection relies on:

• Behavioral monitoring: Anomalous process execution, unusual network connections, unexpected file changes (EDR, UEBA)
• Network anomaly detection: Beaconing, unusual data flows, DGA domains (NDR, network monitoring)
• Threat hunting: Proactive searches for indicators of unknown threats (e.g., "show me all processes that made outbound connections and were not seen in the last 30 days")
• ML-based anomaly detection: UEBA and network behavior analytics that detect deviations from baseline
• Honeypots / deception: Fake assets that attract attackers; any interaction is anomalous

Q8: Should I build an in-house SOC or use an MDR?

Singahi recommendation:

• Under 250 employees: MDR (fully managed)
• 250–1,000 employees: Hybrid (in-house business hours + MDR for nights/weekends)
• 1,000+ employees: In-house SOC with MDR for overflow or specific functions (e.g., threat hunting)

Q9: How do I measure the effectiveness of my monitoring program?

Use the metrics from Section 18. The top 5 metrics are:

1. MTTD (Mean Time to Detect): Are you finding threats faster? Target < 24 hours.
2. MTTR (Mean Time to Respond): Are you responding faster? Target < 1 hour for critical.
3. False positive rate: Are you wasting analyst time? Target < 5%.
4. Detection coverage: Are you covered against the threats you care about? Target > 70% of ATT&CK techniques in scope.
5. Alert volume per analyst: Is your SOC sustainable? Target < 100 actionable alerts per analyst per day.

Q10: What should I do if my SIEM is too premium-tier?

Options:

1. Reduce ingestion: Filter noise, sample high-volume logs, drop debug logs
2. Optimize storage: Use hot/warm/cold tiers; move old data to cheap archive
3. Switch to open source: Elastic (self-managed) or Wazuh for core SIEM capability
4. Use cloud-native SIEM: Sentinel or Chronicle can be efficient for cloud-first orgs
5. Hybrid approach: Use cloud SIEM for real-time alerting and data lake (S3, BigQuery) for long-term storage and batch analysis
6. Renegotiate: Many vendors offer significant discounts if you commit to volume tiers or multi-year contracts

Q11: How do I monitor third-party SaaS applications (Slack, Salesforce, GitHub)?

Most SaaS applications provide audit logs via API:

• Slack: Audit logs (Enterprise Grid) via API
• Salesforce: Event Monitoring, Setup Audit Trail
• GitHub: Audit log, Security tab, Dependabot alerts
• Google Workspace: Admin console audit, Google Cloud Identity logs
• Office 365: Unified Audit Log (via Compliance Center or Sentinel connector)
• Jira/Confluence: Audit log (Data Center/Cloud)
• Zoom: Account activity, operation log

Collect these via API connectors (Splunk Add-on, Sentinel Data Connector, Elastic Agent) or custom scripts. Include SaaS in your monitoring policy scope.

Q12: Can I use my existing observability tool (Datadog, New Relic) for security monitoring?

Yes, with caveats:

• Pros: Unified platform, existing infrastructure, overhead efficiency, cloud-native
• Cons: Security features are newer and less mature than dedicated SIEMs; limited SOAR, limited detection rule libraries, less strong case management

Best approach:

• Use observability for application security (API abuse, injection, performance-based anomalies)
• Use dedicated SIEM for enterprise security monitoring (correlation, threat hunting, compliance)
• Integrate both: forward observability security findings to SIEM for unified incident management

Q13: What is the most common mistake in A.8.16 implementation?

The most common mistake is deploying tools without process. Organizations buy Splunk, deploy agents, and consider the job done. They don't have:

• A monitoring policy
• Defined review procedures
• Alert tuning and false positive management
• Escalation to incident response
• Metrics and KPIs

The tool is not the control. The process is the control.

Q14: How often should detection rules be updated?

Q15: Do I need to monitor OT/ICS environments for ISO 27001?

If your scope includes OT/ICS (manufacturing, energy, critical infrastructure), then yes. However, OT monitoring requires specialized tools and approaches:

• Passive monitoring (no active scanning that could disrupt operations)
• Protocol-aware (Modbus, DNP3, IEC 61850)
• Air-gap considerations (data diode for log export)
• Tools: Nozomi Networks, Claroty, Dragos, Fortinet OT Security

If your scope is purely IT, OT may be excluded with explicit scope definition and risk acceptance.

Indian Regulatory Context and Illustrative Scenario for A.8.16

Indian regulators expect security monitoring to be continuous, actionable and aligned with sectoral reporting obligations. RBI's Cyber Security Framework requires banks to deploy SIEM, correlate logs centrally, and report serious incidents within 6 hours. SEBI's cybersecurity circulars for market infrastructure institutions mandate 24x7 security operations, log retention for at least one year and regular vulnerability scanning. CERT-In directions require reporting of specified cyber incidents within 6 hours and maintenance of logs for 180 days. The DPDP Act 2023 makes monitoring evidence critical for demonstrating reasonable security safeguards (Section 8(5)) and for detecting personal data breaches that must be intimated under Section 8(6).

Illustrative Scenario, Indian E-commerce Fraud Detection (2024): A Gurugram-based e-commerce platform noticed anomalous order refunds totaling over a two-week period. Initial investigations by the finance team assumed vendor error. The security operations team, using a SIEM with UEBA rules, identified that refunds were initiated from an admin account outside business hours, from an unrecognized IP address and with altered browser user-agent strings. The account had been compromised through credential stuffing. Because monitoring detected the anomaly within 72 hours, the company reversed most refunds, revoked the account, notified affected customers and filed a CERT-In report. Post-incident, the platform implemented MFA for all admin accounts, geo-velocity alerts, and automated deactivation of accounts with impossible-travel signals.

Lessons:

• Centralize logs from all critical systems and retain them for at least 180 days.
• Build detection rules for India-specific fraud patterns (UPI, wallet refunds, coupon abuse).
• Test alerting paths quarterly and measure mean time to detect (MTTD).
• Document monitoring coverage as evidence for RBI/SEBI and ISO 27001 auditors.

💡 Need help implementing this? Contact Singahi for a 20-minute readiness call. We build monitoring programs in 8 weeks.