Unit 1: SOC Fundamentals and Incident Response

INT244 — Securing Computing Systems 11 min read

I. Orientation — Security Operations as a Defensive Function

Security operations combine people, processes, and technology to continuously protect an organization’s information systems. A Security Operations Center (SOC) performs this function by monitoring telemetry, identifying threats, coordinating incident response, and improving controls. Its governing principle is risk reduction: prevent incidents where possible, detect them quickly, limit their impact, and restore normal operations securely.

Security objectives: Preserve confidentiality, integrity, and availability—the CIA triad—while supporting authenticity, accountability, privacy, and business continuity.
Risk basis: Risk arises when a threat exploits a vulnerability and causes business impact; controls reduce its likelihood or consequences.
Operational cycle: Collect telemetry → detect suspicious activity → investigate → contain → eradicate → recover → improve.
Evidence-driven decisions: Analysts rely on timestamps, logs, alerts, packet captures, endpoint artifacts, identities, and threat intelligence.
Defence in depth: Preventive, detective, and corrective controls operate across endpoints, networks, applications, identities, and cloud services.
Governance requirement: Policies, legal duties, service-level agreements, escalation criteria, and documented playbooks define acceptable action.

II. Introduction to SOC — Centralized Security Operations

A. Introduction to SOC: overview of SOC

A SOC is a centralized or coordinated capability that continuously monitors, detects, investigates, and responds to cybersecurity events.

Inputs: Telemetry includes firewall logs, DNS queries, authentication events, endpoint detection and response (EDR) alerts, cloud audit logs, and application records.
Core technology: A Security Information and Event Management (SIEM) platform centralizes logs and correlates events; Security Orchestration, Automation and Response (SOAR) executes approved workflows.
Outputs: The SOC produces validated incidents, containment actions, threat reports, metrics, and recommendations for control improvement.
Scope: Monitoring may cover on-premises systems, remote devices, operational technology, software-as-a-service platforms, and infrastructure-as-a-service workloads.

B. Introduction to SOC: importance of SOC

A SOC provides continuous visibility and coordinated action, reducing the time attackers remain undetected and the damage they can cause.

Early detection: Correlating an impossible-travel login with a new mailbox rule can reveal account compromise before data exfiltration.
Reduced impact: Rapidly isolating an infected endpoint can prevent ransomware from reaching shared storage.
Compliance support: Retained logs, incident records, and access trails provide evidence for legal, regulatory, and contractual obligations.
Business continuity: Prioritizing critical services—such as identity, payment, or clinical systems—aligns security response with operational needs.

C. Introduction to SOC: challenges in SOC

SOC effectiveness is constrained by excessive data, evolving threats, limited context, and shortages of skilled personnel.

Alert fatigue: Thousands of low-quality alerts can obscure a genuine attack; tuning must reduce false positives without creating false negatives.
Visibility gaps: Unmanaged devices, encrypted traffic, missing cloud logs, and inconsistent timestamps weaken investigations.
Threat evolution: Attackers change indicators, use legitimate administration tools, and exploit zero-day vulnerabilities.
Resource pressure: Continuous shifts, repetitive triage, and high-severity incidents contribute to analyst burnout.
Integration problems: Different products may use incompatible schemas, identifiers, retention periods, and severity scales.

D. Introduction to SOC: roles and responsibilities

SOC responsibilities are divided by specialization and escalation level so that incidents receive appropriate expertise and authority.

Tier 1 analyst: Monitors queues, validates alerts, gathers initial evidence, and follows triage playbooks.
Tier 2 analyst: Performs deeper investigation, correlates artifacts, determines scope, and recommends containment.
Tier 3 analyst or threat hunter: Investigates advanced threats, develops detections, analyzes malware, and conducts hypothesis-led hunting.
Incident responder: Coordinates containment, eradication, recovery, evidence handling, and technical documentation.
SOC manager: Manages staffing, risk escalation, service metrics, stakeholder reporting, and continuous improvement.
Supporting roles: Forensics, legal, privacy, human resources, communications, system owners, and executives contribute when required.

E. Introduction to SOC: models

A SOC model defines where analysts, technologies, and operational responsibilities are located.

Internal SOC: Organization-owned staff and tools provide strong context and control but require substantial investment and round-the-clock staffing.
Outsourced SOC or managed security service: A provider supplies monitoring expertise and scale, but contracts must define data access, escalation, and response authority.
Hybrid SOC: External teams handle routine monitoring while internal teams retain incident command and business-sensitive decisions.
Virtual or distributed SOC: Personnel collaborate remotely through shared SIEM, ticketing, communication, and case-management systems.
Follow-the-sun SOC: Teams in different time zones transfer active cases through formal shift handovers.

III. SOC Pillars — Capabilities Supporting Effective Operations

A. SOC Pillars: introduction

SOC pillars are the interdependent capabilities required to turn raw security data into reliable detection, response, and improvement.

Operational relationship: People interpret evidence, processes standardize decisions, and technology collects or acts on data.
Continuous loop: Intelligence informs detection; detection triggers analysis; analysis guides response; lessons learned improve controls.
Failure dependency: Advanced tools cannot compensate for untrained analysts, undocumented escalation, or missing telemetry.

B. SOC Pillars: definition of SOC pillars

The principal SOC pillars are people, process, technology, governance, and actionable intelligence.

People: Analysts, responders, engineers, managers, and business stakeholders provide expertise and decision-making.
Process: Playbooks define steps for phishing, malware, unauthorized access, data leakage, and denial-of-service incidents.
Technology: SIEM, EDR, network detection and response, vulnerability scanners, ticketing systems, and SOAR enable operations.
Governance: Policies establish ownership, risk tolerance, evidence retention, authorization, and reporting obligations.
Intelligence: Context about adversaries, vulnerabilities, tactics, and indicators improves detection and prioritization.

C. SOC Pillars: importance of SOC pillars

Balanced pillars make security operations repeatable, measurable, and resilient rather than dependent on individual judgment.

Consistency: A phishing playbook ensures analysts preserve the email, inspect headers, analyze URLs, identify recipients, and block confirmed indicators.
Accountability: A RACI matrix identifies who is responsible, accountable, consulted, and informed during an incident.
Scalability: Automation enriches alerts with asset ownership or reputation data while humans retain authority over disruptive actions.
Resilience: Cross-training and documented procedures preserve operations during absences, surges, and staff turnover.

D. SOC Pillars: levels of SOC analysis

SOC analysis progresses from basic alert validation to advanced, proactive investigation.

Level 1—Triage: Confirm whether an alert is genuine, identify affected assets and users, assign severity, and close obvious false positives.
Level 2—Investigation: Build a timeline, correlate endpoint, identity, network, and cloud evidence, and determine scope and impact.
Level 3—Advanced analysis: Examine malware behavior, memory artifacts, persistence mechanisms, lateral movement, and command-and-control activity.
Proactive hunting: Search for behaviors not already detected—for example, unusual PowerShell execution followed by outbound connections.

E. SOC Pillars: prioritization and analysis

Prioritization directs limited SOC resources toward incidents presenting the greatest organizational risk.

Risk factors: Consider alert confidence, asset criticality, data sensitivity, exploitability, exposure, attack stage, and potential impact.
Severity distinction: A high-confidence alert on a test device may rank below a moderate-confidence alert involving a domain administrator.
Analytical method: Establish facts, form hypotheses, test them against independent evidence, document assumptions, and reassess conclusions.
Framework mapping: Mapping behavior to MITRE ATT&CK techniques, such as credential dumping or remote services, helps identify likely next actions.

F. SOC Pillars: remediation and recovery

Remediation removes the weakness or malicious presence, while recovery restores systems safely and verifies normal operation.

Remediation: Remove malware, disable compromised accounts, revoke tokens, patch vulnerabilities, rotate credentials, and correct insecure configurations.
Recovery: Restore clean backups, reconnect isolated assets in stages, monitor for recurrence, and validate service integrity with system owners.
- Change control: Emergency actions must be recorded because unplanned blocking, deletion, or shutdown can disrupt evidence and business services.
- Exit criteria: Recovery is complete only when required functions operate, monitoring is restored, and no continuing compromise is detected.

G. SOC Pillars: assessment and audit

Assessment and audit determine whether SOC controls are designed correctly, operating effectively, and producing defensible records.

Operational metrics: Mean time to detect, acknowledge, contain, and recover reveal delays, but must be interpreted alongside incident severity.
Control testing: Tabletop exercises, phishing simulations, purple-team tests, and log-source validation expose practical gaps.
Audit evidence: Tickets, timestamps, approvals, chain-of-custody records, retention settings, and playbook versions demonstrate compliance.
Maturity assessment: Review coverage, automation, staffing, documentation, intelligence use, and lessons-learned implementation.

H. SOC Pillars: threat intelligence

Threat intelligence is analyzed information about threats that supports timely and risk-based security decisions.

Strategic intelligence: Describes long-term threat trends for executives and risk planners.
Operational intelligence: Explains campaigns, targeted sectors, adversary objectives, and likely attack paths.
Tactical intelligence: Describes tactics, techniques, and procedures, such as credential phishing followed by cloud persistence.
Technical intelligence: Includes IP addresses, domains, file hashes, URLs, and certificates; these indicators require context because they can expire or be shared.
Intelligence cycle: Direction → collection → processing → analysis → dissemination → feedback.

IV. Security Incident Response — Coordinated Control of Incidents

A. Security Incident Response: incident response lifecycle

The incident response lifecycle organizes activities from readiness through organizational learning.

Preparation: Establish policy, contacts, access, logging, secure communications, backups, playbooks, and response tools.
Detection and analysis: Validate indicators, classify the incident, estimate scope and impact, preserve evidence, and assign priority.
Containment, eradication, and recovery: Limit spread, remove causes and persistence, restore trusted systems, and intensify monitoring.
Post-incident activity: Document lessons, identify control failures, update detections, and assign corrective actions with owners and deadlines.
Lifecycle principle: Phases may overlap; urgent containment can begin while investigation continues.

B. Security Incident Response: handling and investigation technique

Incident handling combines controlled decision-making with evidence-based reconstruction of what happened.

Initial handling: Record reporter, time, systems, symptoms, alert source, and actions already taken in a uniquely numbered case.
Evidence preservation: Collect volatile data where appropriate, secure logs and disk images, calculate cryptographic hashes, and maintain chain of custody.
Timeline analysis: Normalize timestamps and correlate logins, process creation, file changes, DNS requests, and network connections.
Scoping: Search enterprise telemetry for the same user, host, hash, domain, technique, or persistence mechanism.
Containment choice: Balance immediate isolation against monitoring the attacker to learn scope; safety and business impact govern the decision.

C. Security Incident Response: post-incident analysis

Post-incident analysis converts experience into measurable improvements and must avoid assigning personal blame.

Root-cause analysis: Distinguish the entry point, enabling control failure, attacker actions, and resulting business impact.
Review questions: Determine what occurred, when detection happened, which actions worked, where delays arose, and whether escalation was timely.
Corrective actions: Patch systems, improve logging, revise access controls, update playbooks, and create new detection rules.
Tracking: Each action needs an owner, target date, priority, and closure evidence; otherwise lessons remain only documented observations.

D. Security Incident Response: information sharing in incident response

Controlled information sharing improves collective defence while protecting confidentiality, privacy, and investigations.

Internal sharing: Provide system owners, leadership, legal, privacy, and communications teams only the details needed for their roles.
External sharing: Coordinate with vendors, insurers, sector information-sharing groups, regulators, law enforcement, or affected partners.
Structured exchange: STIX represents threat information, while TAXII supports automated transport between participating systems.
Handling controls: Traffic Light Protocol markings communicate sharing restrictions; sensitive personal data, credentials, and investigative details require minimization.
Quality requirement: Shared indicators should include timestamps, confidence, context, source, and observed behavior.

E. Security Incident Response: communication strategies

Incident communication must be timely, accurate, role-appropriate, and coordinated through an established command structure.

Communication plan: Define authorized speakers, secure channels, contact trees, update intervals, approval paths, and fallback methods.
Audience tailoring: Analysts need indicators and timelines; executives need impact, decisions, risk, and estimated restoration status.
Situation reports: State confirmed facts, uncertain points, completed actions, current risks, next steps, and required decisions.
Channel security: If corporate email is compromised, use an approved out-of-band platform rather than exposing response activity.
Public communication: Legal and communications teams should coordinate notifications to prevent speculation, contradiction, or disclosure of sensitive evidence.

F. Security Incident Response: incident response in IT environment

IT incident response must account for interconnected endpoints, networks, identities, applications, virtualization, and cloud platforms.

Endpoint response: Isolate hosts through EDR, capture relevant artifacts, remove persistence, reimage when trust cannot be restored, and verify patches.
Identity response: Disable accounts, revoke sessions and tokens, reset credentials, review multifactor-authentication changes, and inspect privilege escalation.
Network response: Block malicious destinations, segment affected systems, inspect traffic, and preserve firewall, proxy, DNS, and VPN logs.
Cloud response: Review control-plane audit logs, access keys, security groups, storage permissions, snapshots, and cross-account activity.
Operational coordination: System owners approve service-affecting actions, continuity teams manage outages, and responders preserve evidence throughout restoration.