6 Security Operations and Incident Response

Monitoring and logging

Security operations turn security data into timely decisions: teams detect suspicious activity, determine its significance, reduce risk, investigate incidents, and restore services safely. Effective operations rely on accurate asset inventories, useful monitoring, reliable logs, practiced response plans, and tested recovery capabilities.

Monitoring sources and tools

Continuous monitoring gathers and assesses information about assets, threats, vulnerabilities, and security-control effectiveness. It requires defined coverage, review procedures, escalation paths, and follow-up; merely watching alerts is not enough.

Common information sources include:

• Network devices: firewalls, routers, DNS, VPN, proxy, and network flow records.

• Endpoints and servers: operating-system events, antivirus or endpoint detection and response (EDR), process activity, and system changes.

• Identity systems: authentication, account changes, privilege use, and failed logins.

• Applications and databases: access, errors, administrative activity, and data changes.

• Cloud and security tools: cloud audit trails, email security, data-loss-prevention tools, intrusion detection and prevention systems, and vulnerability scanners.

An IDS detects and alerts on suspicious activity; an intrusion prevention system (IPS) can also block or disrupt it. Host-based systems monitor individual devices, while network-based systems observe traffic across network segments. An EDR collects endpoint telemetry and supports investigation and response. A security information and event management system (SIEM) centralizes and correlates events from multiple sources, often generating alerts using rules, thresholds, and analytics. Security orchestration, automation, and response (SOAR) can coordinate approved steps, such as enriching an alert or disabling a confirmed malicious account. Automation should have safeguards, authorization, and audit records.

Log management and alert review

A security log records events. Good log management defines what to collect, how to transmit and protect it, who may access it, how long to retain it, and how to dispose of it. Centralized logs can help investigators even if a compromised device’s local logs are altered or deleted. Synchronized clocks and consistent timestamps, including a time zone or UTC, help place events in sequence. Restrict and monitor log access, protect logs from tampering, and retain them according to business, legal, and regulatory needs. Log management covers generating, transmitting, storing, accessing, and disposing of log data.

An event is an observed occurrence; an alert is a condition needing review; an incident is an event or group of events requiring a coordinated response under organizational policy. A useful alert identifies the affected asset or identity, time, event, severity, relevant context, and recommended next action. Tune detections to reduce both missed threats and excessive false positives.

For example, a SIEM may correlate a successful VPN login from an unusual location with repeated failed logins and a later privilege change. Each event may have a benign explanation on its own, but their sequence warrants triage: verify the user and device, examine related authentication and endpoint records, and escalate if evidence indicates account compromise.

Measure outcomes such as time to detect, time to respond, alert volume, and the proportion of alerts that prove actionable. Speed alone does not measure success.

Vulnerability management

A vulnerability is a weakness that could be exploited. Vulnerability management is a continuing process, not a one-time scan: discover assets, identify weaknesses, assess risk, treat findings, and verify the result. Enterprise patch management includes identifying, prioritizing, acquiring, installing, and verifying patches and updates.

A practical workflow is:

1. Maintain asset and software inventories. Include internet-facing services, cloud resources, endpoints, firmware, and unsupported or unmanaged systems. Unknown assets create blind spots.

2. Scan and assess. Use authorized vulnerability scanners, configuration checks, and vendor advisories. Authenticated scans can inspect more system details; unauthenticated scans show what an outside observer may see. Scanning can disrupt fragile systems, so define scope, timing, and permissions in advance.

3. Validate and prioritize. Confirm whether a finding applies. Consider exploitability, known exploitation, exposure, asset importance, compensating controls, and potential business impact. A CVSS score communicates vulnerability severity characteristics, but it is not by itself a complete organizational risk decision.

4. Treat the risk. Patch or upgrade where feasible. Otherwise use a supported workaround, configuration change, isolation, or another compensating control. Document accepted risk, its owner, rationale, and review date. Prioritize vulnerabilities known to be exploited and those on important exposed systems.

5. Verify and document. Rescan or otherwise confirm remediation, record exceptions, and track unresolved issues to closure. A patch deployment report alone does not prove the vulnerability is fixed.

A scanner may report a false positive, where the weakness is not actually present, or a false negative, where a weakness was missed. Validate consequential findings against asset configuration, software versions, and other evidence. A zero-day is a vulnerability exploited or disclosed before an effective patch is available; temporary mitigations may be needed while watching for exploitation. If evidence indicates that a vulnerability was used to compromise a system, treat it as an incident as well as a remediation task.

Prioritization combines technical severity with threat context and business impact. For example, a severe vulnerability on an isolated test machine may pose less immediate risk than a moderately scored, actively exploited flaw on an internet-facing identity server.

Incident response

Incident response depends on people, roles, communications, tools, procedures, and relationships with legal, privacy, leadership, IT, vendors, and external responders. Plans should specify who can declare an incident, authorize containment, preserve evidence, communicate externally, and approve recovery actions.

Current guidance integrates incident response into broader cybersecurity risk management and the Cybersecurity Framework 2.0 rather than treating it as an isolated activity. A useful operational sequence is prepare; detect and analyze; contain; eradicate; recover; and learn. These activities can overlap and repeat.

Response activities

• Prepare: Define roles, escalation criteria, contact lists, playbooks, backup plans, and evidence-handling procedures. Exercise scenarios before an incident.

• Detect and analyze: Validate alerts; identify affected systems, accounts, data, and likely scope; preserve relevant records; and assess severity and business impact. Record facts separately from hypotheses.

• Contain: Limit damage and prevent spread. Options include isolating a host, disabling a compromised account, blocking malicious traffic, or segmenting a network. Choose actions according to risk: powering down a device may stop activity but can destroy volatile evidence.

• Eradicate: Remove the cause, such as malware, unauthorized accounts, persistence mechanisms, or exploited weaknesses. Determine whether rebuilding from a known-good image is safer than cleaning a compromised system.

• Recover: Restore trusted systems and services in a controlled order. Monitor closely for reinfection or renewed attacker access, and verify security controls before returning systems to normal operation.

• Learn: Document the timeline, decisions, impact, and control gaps; update detections, procedures, training, and recovery plans.

Maintain an incident record with timestamps, actions, decision-makers, evidence references, and communications. Communicate through approved channels, especially if normal email or collaboration systems may be compromised. Follow applicable organizational policy and legal requirements for notification and evidence handling.

Digital forensics

Digital forensics is the systematic identification, preservation, collection, examination, analysis, and reporting of digital evidence. It can support incident investigation, recovery decisions, internal inquiries, or legal processes. Follow organizational policy and consult appropriate legal or privacy specialists when required; forensic handling is not a substitute for legal advice.

Preserve and acquire evidence

Record who collected evidence, when, where, how, and why. Maintain a chain of custody: a documented history of evidence possession and handling. Where practical, use a write blocker when imaging storage media, create a forensic copy, and calculate cryptographic hashes to help demonstrate that the copy has not changed. Hashes support integrity checks, but do not prove who created a file or that its contents are truthful.

Prioritize volatile evidence when appropriate. Information in memory, running processes, network connections, and temporary state may disappear when a system is shut down. Collection order depends on investigative goals and risk; coordinate with incident leadership before actions that change or destroy evidence.

Preserve originals and analyze verified forensic copies when feasible. Record tools, settings, steps, and results so another analyst can understand or reproduce the examination. Correlate endpoint artifacts, file systems, application records, authentication logs, network captures, and cloud audit trails to build a timeline, accounting for clock differences and gaps in logging.

Evidence collection must be authorized and scoped. Avoid unnecessary access to personal or unrelated data, and preserve confidentiality. A defensible investigation depends on reliable methods, clear documentation, and careful interpretation—not merely possession of forensic tools.

Disaster recovery and resilience

A disaster recovery plan (DRP) describes how to restore systems and technology services after a major disruption. Business continuity focuses more broadly on sustaining important business functions; incident response addresses security events; and system contingency procedures guide recovery of a particular system. These plans should coordinate but serve different purposes. Contingency planning includes impact analysis, recovery strategies, documented plans, exercises, and maintenance.

A business impact analysis identifies critical services, dependencies, and acceptable downtime or data loss. The recovery time objective (RTO) is the target maximum time to restore a service after disruption. The recovery point objective (RPO) is the target maximum amount of data loss measured in time. For example, an RPO of four hours means recovery should use data no older than the agreed four-hour point.

Recovery design should match these targets and business priorities. A hot site is equipped for rapid activation but typically costs more. A warm site has some infrastructure ready but requires additional setup. A cold site provides space and basic facilities but needs substantial equipment and configuration before operation. Actual recovery time depends on more than site type: contracts, staffing, connectivity, data restoration, and testing also matter.

Backups and recovery testing

Backups may be full, incremental, or differential. An incremental backup contains changes since the last backup of any type; a differential backup contains changes since the last full backup. Protect backups with access controls and encryption where appropriate, and maintain offline or immutable copies to reduce ransomware risk. The 3-2-1 guideline is to keep three copies of important data, on two types of storage, with one copy off-site. A backup success message does not establish recoverability; restore tests do.

Test plans with progressively realistic methods: review procedures, conduct tabletop exercises, test individual recovery steps, and perform coordinated failover or restoration exercises when safe. After recovery, validate data integrity, application functionality, access controls, monitoring, and business-owner acceptance. Update plans when systems, suppliers, dependencies, or recovery objectives change.