12.3 Manage Security Operations (Domain 5.6)
Key Takeaways
- Domain 5.6 covers the SOC, intelligent monitoring of security controls, log capture and analysis (SIEM, log management, threat intelligence), incident response, vulnerability assessments, and penetration testing.
- Cloud monitoring must cover firewalls, IDS/IPS, honeypots, network security groups, and increasingly AI-assisted detection—scoped to customer-visible telemetry under shared responsibility.
- SIEM and log pipelines only work if sources are complete, time-synchronized, protected from tampering, and enriched with threat intelligence and asset context.
- Vulnerability assessment and penetration testing in cloud require provider authorization rules, tenancy limits, and safe scoping so tests do not violate AUP or harm co-tenants.
- On CCSP items, pick controls and tests that fit the service model and legal/contract boundaries—not on-premises habits that ignore multi-tenant constraints.
Manage Security Operations
Domain 5.6 requires you to manage security operations for cloud environments. The outline clusters six operational pillars:
- Security Operations Center (SOC)
- Intelligent monitoring of security controls (firewalls, IDS/IPS, honeypots, network security groups, AI)
- Log capture and analysis (SIEM, log management, threat intelligence)
- Incident Response (IR)
- Vulnerability assessments
- Penetration testing
Earlier Domain 5 topics build infrastructure and operational standards; 5.6 is where detection, investigation, and continuous assurance run as a service. Cloud does not remove the SOC—it changes telemetry sources, automation opportunities, and testing rules of engagement.
Security Operations Center (SOC)
A SOC is the people, process, and technology function that monitors, detects, analyzes, responds to, and reports security events. It may be in-house, outsourced (MSSP), hybrid, or “virtual” with follow-the-sun tiers—but the capabilities remain exam-relevant even if the org chart differs.
| SOC function | Description |
|---|---|
| Monitoring | 24/7 or risk-based coverage of alerts and health of security controls |
| Triage | Noise reduction; severity assignment; false-positive handling |
| Investigation | Correlate logs, endpoints, identities, and cloud audit trails |
| Response coordination | Containment steps, IR playbooks, escalations |
| Threat hunting | Proactive search using hypotheses and intelligence |
| Reporting | Metrics for leadership; regulatory evidence support |
| Continuous improvement | Tune detections; feed lessons into engineering |
Cloud SOC Design Considerations
| Consideration | Practice |
|---|---|
| Multi-account / multi-subscription | Centralize security telemetry into a security account or dedicated project |
| Identity-first attacks | Prioritize IdP, federation, and privileged API monitoring |
| Ephemeral assets | Detect based on images, roles, and behaviors—not only long-lived hostnames |
| Shared responsibility | Know which alerts are customer-actionable vs provider status |
| Automation | SOAR-style runbooks for isolation, key rotation, ticket creation |
| Skills | Analysts need cloud IAM, container, and API literacy—not only traditional firewalls |
| Metrics | MTTD, MTTR, alert fidelity, coverage of critical assets, not raw ticket count alone |
SOC models: Internal SOC offers control and context; MSSP offers scale; hybrid is common for cloud (provider-native detections + MSSP tier-1 + internal IR). Exam stems care about capability completeness, not brand of SOC product.
Integration points: SOC consumes outputs from Domain 5.4 forensics readiness and produces inputs for Domain 5.5 stakeholder communication. IR without a SOC-like monitoring function is reactive only; a SOC without IR authority is a spectator.
Intelligent Monitoring of Security Controls
Monitoring means continuously verifying that protective and detective controls work and generating actionable signals when they fail or are attacked. The outline explicitly lists firewalls, IDS/IPS, honeypots, network security groups, and Artificial Intelligence (AI) as examples—intelligent monitoring implies tuning, correlation, and adaptive detection, not merely “device powered on.”
Control Monitoring Catalog
| Control | What to monitor | Cloud expression |
|---|---|---|
| Firewalls | Policy changes, deny/allow anomalies, bypass attempts, rule shadowing | Cloud firewalls, host firewalls, WAF events, edge ACLs |
| IDS | Signature/anomaly alerts, sensor health, coverage gaps | Network IDS appliances, host IDS, cloud threat detection services |
| IPS | Block events, false positives impacting availability, fail-open/fail-closed mode | Inline virtual appliances, provider IPS features |
| Honeypots / deception | Interaction events (high-fidelity intent signals) | Decoy credentials, fake API endpoints, honeytokens in object stores |
| Network Security Groups (NSGs) / security groups | Overly permissive rules, sudden exposure of admin ports, drift from baseline | Per-ENI/VM/subnet filters; flow logs correlation |
| AI-assisted monitoring | Model-driven anomaly scores, automated clustering of rare events | UEBA-like identity analytics, anomaly detection on API usage |
Intelligent vs Naïve Monitoring
| Naïve | Intelligent |
|---|---|
| Alert on every deny | Baseline normal deny rates; alert on change in patterns or high-value destinations |
| Ignore control-plane API calls | Treat IAM and logging configuration changes as tier-0 signals |
| Static signatures only | Combine signatures, anomalies, threat intel, and asset criticality |
| No ownership of alert quality | Feedback loops to tune rules; suppress known benign automation |
| Tools in isolation | Correlate firewall + identity + endpoint + CSP audit in one case |
AI in Security Operations (Exam-Balanced View)
AI/ML can accelerate detection of rare API sequences, impossible travel on federated logins, or malware-like process trees. Domain 1 also flags AI for threat detection and SOAR. Operational caveats:
- Data quality drives model value—garbage logs yield garbage anomalies.
- Explainability matters for IR and audit: analysts must understand why an alert fired.
- Adversarial risk and privacy: training data may include sensitive content; protect model pipelines.
- Automation bounds: auto-containment is powerful; mis-aimed AI actions can cause self-inflicted outages—prefer human-in-the-loop for high-impact responses until playbooks are proven.
- Regulatory/ethical use of monitoring AI should align with organizational policy.
Honeypots and Deception in Cloud
Deception is high-signal because legitimate users rarely access decoy resources.
| Technique | Example |
|---|---|
| Honeytoken credentials | Fake access keys that alert on any use |
| Decoy storage | Attractive bucket names with canary objects |
| Fake admin endpoints | Internal URLs that only attackers scanning would hit |
| Decoy identities | Unused privileged-looking accounts monitored tightly |
Place deception where attackers look after initial access; ensure canaries never sit on production critical paths in ways that break business functions.
NSGs and Micro-Perimeter Reality
In cloud, network security groups are often the primary distributed firewall. Monitoring must detect:
0.0.0.0/0exposure on SSH/RDP/database ports- Rules opened “temporarily” and never closed
- Shadow admin paths through peerings and shared services
- Drift from infrastructure-as-code baselines
Pair NSG monitoring with flow logs and configuration change events; a quiet NSG that suddenly allows the world is an incident precursor.
Log Capture and Analysis: SIEM, Log Management, and Threat Intelligence
Without logs, the SOC is blind. Domain 5.6 highlights Security Information and Event Management (SIEM), log management, and threat intelligence as the analytic backbone.
Log Management Fundamentals
| Concern | Practice |
|---|---|
| Collection | Agents, platform APIs, syslog, cloud-native export pipelines |
| Coverage | Control plane, data plane (where needed), identity, network, endpoint, application |
| Normalization | Consistent fields (identity, IP, resource ID, geo, result) for correlation |
| Time sync | UTC, reliable NTP; clock skew breaks timelines |
| Retention | Hot tier for investigation speed; cold tier for compliance; legal hold overrides |
| Integrity | Append-only / immutable options; separate admin plane from producers |
| Privacy | Minimize PII in logs; control analyst access; retention justified by purpose |
| Cost | Filter noise early; sample low-value debug; never “save money” by dropping auth and API audit logs |
SIEM Role
A SIEM aggregates events, correlates rules and analytics, supports investigations, and often drives alerting and case management.
| SIEM capability | Cloud operations use |
|---|---|
| Correlation rules | Link failed logins → successful login → privilege escalation → logging disabled |
| Dashboards | Control health, top talkers, privileged activity |
| Use cases / content packs | Mapped to MITRE-like techniques and cloud audit events |
| UEBA / anomaly | Peer-group deviations for users and service principals |
| Case workflow | Assign, enrich, escalate, close with evidence links |
| SOAR integration | Automated enrichment and containment actions |
Cloud SIEM pitfalls: incomplete data-plane logging; multi-cloud field inconsistency; alert floods from mis-tuned rules; storing SIEM data in the same breached account without immutability; ignoring SaaS admin logs because “we only watch the VPC.”
Threat Intelligence
Threat intelligence (TI) is contextual knowledge about threats—actors, campaigns, IOCs, TTPs—used to prioritize detection and response.
| TI type | Operational use |
|---|---|
| Strategic | Leadership risk decisions, sector threat reports |
| Tactical / TTP | Hunt hypotheses, detection engineering |
| Operational / IOC | Blocklists, SIEM matches on hashes, IPs, domains |
| Internal intel | Recurring adversary behaviors against your estate |
Intelligence lifecycle: direction → collection → processing → analysis → dissemination → feedback. Feed TI into SIEM match lists, WAF/DNS controls, and IR playbooks—but validate IOCs (false positives from shared cloud IPs are common).
Reference Architecture (Logical)
- Sources emit logs (cloud audit, NSG/flow, IdP, EDR, WAF, application).
- Transport is authenticated and encrypted into a central log management tier.
- SIEM correlates with threat intel and asset inventory/criticality tags.
- Alerts route to SOC with runbooks; high severity triggers IR.
- Lessons update detections (closed loop).
That pipeline is the operational expression of Domain 3.4 audit mechanisms at scale.
Incident Response (IR)
Incident Response is the structured handling of security incidents to reduce impact and restore secure operations. Domain 5.3 lists incident management among operational standards; Domain 5.6 expects IR as a live security operations capability tightly coupled to the SOC.
IR Phases (Practical Cloud View)
| Phase | Activities |
|---|---|
| Preparation | Playbooks, roles, tools, forensics readiness, contracts, comms templates, tabletop exercises |
| Detection & analysis | Alert triage, scoping, severity, confirm true positive |
| Containment | Short-term (isolate instance, disable key) and long-term (account segmentation) |
| Eradication | Remove malware, rotate credentials, patch exploited flaws, rebuild from clean images |
| Recovery | Restore services, heightened monitoring, validate integrity |
| Lessons learned | Blameless review, detection gaps, architecture fixes, stakeholder report |
Cloud-Specific IR Constraints and Opportunities
| Topic | Implication |
|---|---|
| Snapshot isolation | Quarantine by security group / account move rather than only pulling network cables |
| Identity compromise | Revoke sessions, rotate keys, disable federated app, review privilege grants—often more important than disk wipe |
| Immutable rebuild | Prefer redeploy from known-good IaC/images over “cleaning” untrusted hosts |
| Provider dependency | Escalate for platform events; use status and support bridges |
| Multi-tenancy | Contain within your tenancy; do not attempt actions against co-tenants |
| Serverless / containers | Revoke roles, replace tasks/pods, invalidate layers; limited traditional host IR |
| Evidence | Preserve per Domain 5.4 before aggressive rebuild when investigation matters |
| Automation | Pre-approved SOAR actions (disable user, snapshot, block IOC) cut MTTR |
Playbooks Worth Having
- Compromised cloud admin / root account
- Public storage exposure with sensitive data
- Ransomware on IaaS and identity
- Suspected cryptomining on compute
- OAuth app or SaaS token abuse
- Supply-chain malicious package in CI
- CSP region impairment (BC-linked)
Each playbook should list entry criteria, data sources, containment steps, evidence steps, comms triggers (Domain 5.5), and exit criteria.
Coordination with Forensics and Communications
IR is the orchestrator: SOC detects → IR contains and investigates → forensics preserves evidence → communications notifies stakeholders → recovery returns service → improvements harden the estate. Exam answers that only “restore from backup” without containment and credential rotation often miss active persistence.
Vulnerability Assessments and Penetration Testing
Continuous assurance finds weaknesses before attackers do. Domain 5.6 pairs vulnerability assessments with penetration testing—related but not identical.
Vulnerability Assessments
A vulnerability assessment systematically identifies and prioritizes known weaknesses (missing patches, misconfigurations, vulnerable libraries, weak TLS, open management ports).
| Attribute | Practice |
|---|---|
| Breadth | Inventories of VMs, containers, functions, images, SaaS configs |
| Methods | Authenticated scanning, agent-based, API/config auditors, SCA for dependencies, CSPM-style misconfiguration checks |
| Frequency | Continuous or frequent for cloud change velocity; gate images in CI |
| Prioritization | Exploitability, asset criticality, internet exposure, threat intel—not CVSS alone |
| Remediation SLA | Timeboxes by severity; exceptions risk-accepted with expiry |
| Validation | Rescan to confirm closure |
Cloud nuances: Ephemeral instances may disappear before scan completion—shift left to image and pipeline scanning. Misconfiguration (public buckets, open security groups, excessive IAM) often outranks unpatched OS CVEs in real cloud breaches. Include identity and control-plane posture, not only guest CVE lists.
Penetration Testing
Penetration testing simulates attacker techniques to validate exploitability and business impact beyond a scanner’s CVE list. It is scoped, authorized, time-bounded, and reported with proof of concepts and remediation guidance.
| Assessment | Penetration test |
|---|---|
| Width over depth | Depth on critical paths |
| Often automated + analyst review | Manual tradecraft + tooling |
| Finds known issues and misconfigs | Demonstrates chaining and impact |
| Continuous-friendly | Periodic or event-driven (major release, annual) |
Cloud-Specific Constraints (Critical for CCSP)
| Constraint | Why it matters |
|---|---|
| Provider authorization / AUP | Many CSPs require pre-approval or restrict test types (for example, certain DoS, flooding, or tests against infrastructure outside your tenancy) |
| Scope boundaries | Only test resources you own or have written permission to test; never “pivot” into co-tenant systems |
| Shared services | Avoid techniques that could impact platform stability or other customers |
| Data sensitivity | Prod tests may expose real PII—prefer non-prod or tightly controlled prod windows |
| Legal agreements | Written rules of engagement, success criteria, contacts, safe word to halt |
| SaaS limits | You may be limited to application-layer tests allowed by the vendor; no backend host tests |
| Rate limits & WAF | Coordinate so security controls do not simply ban the tester’s IPs without analytical value—or intentionally validate those controls |
Exam trap: “Run an unrestricted network flood against the CSP core routers to test resilience” is wrong. “Conduct an authorized application and IaaS tenant penetration test following provider policies, with scoped targets and emergency contacts” is right.
Integrating VA/PT into Security Operations
- Continuous vulnerability management feeds the backlog and patch/config pipelines.
- Periodic penetration tests validate SOC detections (did monitoring see the test?) and IR readiness.
- Purple-team exercises blend attack simulation with detection engineering.
- Findings without remediation ownership are theater—track to closure.
- Retest critical findings; report residual risk to leadership.
Unified Operations Picture
A mature Domain 5.6 program looks like this:
- SOC watches intelligent signals from firewalls, IDS/IPS, NSGs, deception, and AI analytics.
- Log/SIEM/TI pipelines turn raw cloud telemetry into cases.
- IR executes playbooks with forensic preservation and stakeholder communication.
- VA/PT continuously and periodically prove that controls and detections work under cloud rules of engagement.
Exam Approach for Domain 5.6
- Map the stem to SOC, monitoring, logging/SIEM/TI, IR, VA, or PT.
- Apply shared responsibility and provider policy limits.
- Prefer detection + response + improvement loops over single point tools.
- For testing items, demand authorization, scope, and non-impact to co-tenants.
- For monitoring items, require coverage, integrity, and actionable correlation, not mere log existence.
Which SIEM-oriented design best supports cloud security operations?
A team wants to prove exploitability of internet-facing cloud apps and IaaS assets. What is the most appropriate penetration-testing approach?
Which example best illustrates intelligent monitoring rather than naïve device uptime checks?
During IR for a suspected stolen workload identity in a container platform, which action set best reflects cloud-appropriate response?