Unit 5: Incident Response, Monitoring, Malicious Activity, and Security Governance

Security operations convert visibility into action: detecting adverse events, responding in a structured way, preserving evidence, and governing the whole process through written policy. This unit maps the lifecycle from a raw log entry to a documented, authorised remediation.

• Confidentiality, Integrity, Availability (CIA): the properties every control defends; an incident is any event that threatens one of them.
• Event vs. incident: an event is any observable occurrence (a login, a packet); an incident is an event that violates policy or security — only incidents trigger response.
• Indicator of Compromise (IoC): a forensic artefact (file hash, IP, registry key) showing a breach has already occurred; distinct from an indicator of attack (IoA), which shows intent in progress.
• Chain of custody: the documented, unbroken record of who handled evidence and when, required for admissibility.
• Governance: the layered framework — policy → standard → procedure — that authorises and constrains all of the above.

II. Incident Response and Forensics

From detecting an incident to proving what happened in court.

A. Incident Response

Incident response (IR) is the disciplined process of preparing for, containing, and recovering from security incidents to limit damage and restore service.

• Lifecycle phases: the canonical NIST SP 800-61 sequence:
  1. Preparation: build the capability — IR plan, trained team, tooling, and communication tree — before an incident.
  2. Detection and Analysis / Containment, Eradication, Recovery / Post-incident Activity: the active phases.
• Containment strategies:
  • Short-term: isolate the host (pull the network cable, disable the switch port) to stop spread.
  • Long-term: apply patches and rebuild clean systems.
• Eradication and recovery: remove the root cause (malware, backdoor account) then restore from known-good backups and monitor for recurrence.
• Lessons learned: a post-incident review within a set window (commonly ~2 weeks) produces concrete process changes; the deliverable is a report, not blame.
• Key roles: the CSIRT (Computer Security Incident Response Team) coordinates; legal, HR, PR, and management are stakeholders invoked per the plan.

B. Digital Forensics

Digital forensics is the structured acquisition and analysis of digital evidence such that findings are repeatable and defensible.

• Order of volatility: collect most-perishable data first — CPU registers/cache → RAM → network state → disk → archival media — because volatile data vanishes on power loss.
• Acquisition integrity:
  • Hashing: compute a hash (e.g. SHA-256) of the image at capture and again later; matching digests prove the copy is unaltered.
  • Write blocker: hardware/software that permits reads but blocks writes to the original drive.
• Chain of custody: a signed log recording every transfer of the evidence item; a single gap can render it inadmissible.
• Legal hold and e-discovery: on notice of litigation, routine data deletion must be suspended for relevant records.

III. Monitoring Infrastructure

Where the data comes from and the tools that read it.

A. Data Sources

Data sources are the raw telemetry streams from which indicators and alerts are derived; coverage gaps here create blind spots everywhere downstream.

• Log files: the primary source — each records a specific layer:
  • System/OS logs: process starts, authentication (/var/log/auth.log, Windows Security Event ID 4624/4625 for logon success/failure).
  • Application logs: events emitted by the app itself (database errors, failed transactions).
  • Firewall/network logs: allowed and denied connections with source/destination IP and port.
• Metadata: data about data — email headers (sender IP, routing path), file timestamps (MAC: Modified, Accessed, Created), EXIF in images.
• NetFlow/sFlow: flow records summarising conversations (src/dst, bytes, duration) without full packet capture — compact, good for volume analysis.
• Packet captures: full payload via tools like tcpdump; highest fidelity, highest storage cost.
• Vulnerability scans: output listing missing patches and misconfigurations, feeding risk prioritisation.

B. Alerting and Monitoring Tools

These tools aggregate the data sources and raise notifications when conditions match a rule.

• SIEM (Security Information and Event Management): central platform that collects, correlates, and alerts on logs from many sources; correlation rules link separate events (e.g. a failed-login spike then a success) into one alert.
• SNMP: polls or receives traps from network devices for availability and performance monitoring.
• Antivirus/EDR: endpoint agents raising alerts on signature or behaviour matches.
• NetFlow collectors / packet analysers: surface anomalous volume or protocols.
• Tuning concepts:
  • False positive: a benign event flagged as malicious — wastes analyst time.
  • False negative: a real attack missed — the dangerous failure.
  • Alert fatigue: excessive alerts desensitise analysts; mitigated by tuning thresholds and aggregation.

IV. Malicious Activity: Attack Indicators

Recognising the signatures that each attack class leaves behind.

A. Malware Attack Indicators

Signs that malicious software is present or executing on a host.

• Account lockouts / concurrent logins: credentials stolen and reused from impossible locations.
• Resource consumption / inaccessibility: unexplained CPU, disk, or network spikes — cryptominers or exfiltration.
• Out-of-cycle logging and missing logs: logs appearing at odd times, or being cleared, signal tampering.
• Published/documented IoCs: known-bad file hashes, C2 (command-and-control) domain names, or mutex strings matching threat-intel feeds.
• Specific types: ransomware (encrypted files + ransom note), trojan (unexpected outbound beaconing), rootkit (hidden processes invisible to the OS tools).

B. Physical and Network Attack Indicators

Indicators arising from the physical environment and from traffic on the wire.

1. Physical indicators:
   • Access anomalies: badge used at an unusual door or hour; tailgating captured on CCTV.
   • Hardware tampering: rogue USB devices, skimmers, or an unknown device on a switch port.
   • Environmental sensors: door-open, temperature, or motion alerts outside policy.
2. Network indicators:
   • Scanning: sequential connection attempts across ports/hosts (reconnaissance).
   • Denial of Service (DoS): traffic volume far above baseline from many sources (DDoS); service becomes unavailable.
   • Beaconing: regular, small outbound connections to one external host — classic C2.
   • On-path (MITM): duplicate ARP replies or unexpected certificate changes.

C. Application Attack Indicators

Signs that an application's logic or input handling is being abused.

• Injection: input containing SQL fragments (' OR 1=1--) or shell metacharacters in logs; database errors returned to users.
• Cross-Site Scripting (XSS): <script> tags surviving into stored or reflected output.
• Privilege escalation: a low-rights account suddenly performing admin actions.
• Replay / forgery: repeated identical requests or session tokens reused from new IPs.
• Abnormal HTTP status patterns: a surge of 401/403 (auth probing) or 500 errors (fuzzing crashing the app).

V. Security Governance

The written authority that directs and constrains operations.

A. Policies Standards and Procedures

Governance documents form a hierarchy from high-level intent to step-by-step action.

• Policy: a high-level, mandatory statement of management intent — what and why (e.g. an Acceptable Use Policy). Broad and slow to change.
• Standard: a mandatory, specific requirement supporting a policy — e.g. "all disks encrypted with AES-256."
• Procedure: a detailed, ordered set of steps — how to carry out a task (e.g. the onboarding checklist).
• Guideline: recommended, non-mandatory best practice.
• Common policy types: Acceptable Use (AUP), access control, data classification, incident response, and Business Continuity / Disaster Recovery policies.

B. Change Management

Change management is the formal process ensuring modifications to systems are assessed, approved, and reversible, so that changes do not themselves become incidents.

• Request and approval: a Request for Change (RFC) is reviewed by a Change Advisory Board (CAB) before authorisation.
• Impact and risk analysis: identify affected systems, dependencies, and the blast radius of failure.
• Backout (rollback) plan: a tested path to restore the prior state if the change fails.
• Maintenance window: a scheduled, communicated period minimising user impact.
• Technical implications: updating allow/deny lists, restarting services or applications, and documenting the change for audit and version control.

VI. Automation and Orchestration

Scaling repetitive security work beyond human speed.

A. Automation and Orchestration

Automation executes a single task without human action; orchestration chains automated tasks across multiple systems into a coherent workflow.

1. Automation: scripting one repeatable action — e.g. a cron job that quarantines a file when EDR flags its hash.
2. Orchestration: coordinating many such actions end-to-end — e.g. a SOAR (Security Orchestration, Automation and Response) playbook that, on a phishing alert, extracts the IoC, blocks it at the firewall, searches mailboxes, and opens a ticket.

• Common use cases: user provisioning/deprovisioning, guard-rail enforcement on cloud config, ticket enrichment, and continuous integration/continuous deployment (CI/CD) security gates.
• Benefits: speed and consistent reaction, enforced baselines, reduced analyst workload, and a reliable audit trail.
• Considerations and limitations:
  • Complexity and cost: playbooks require skilled maintenance; a wrong rule automates a mistake at scale.
  • Single point of failure: if the orchestration platform fails, dependent processes stall.
  • Technical debt: scripts written against one API break when that system changes, demanding ongoing upkeep.