# Introduction to Incidents — Definitions, Classification, and Fundamentals

A comprehensive foundation for understanding security incidents, their characteristics, severity, indicators, and impact.

**Tags:** #IncidentHandling #DFIR #BlueTeam #IOC #IOA #Severity

---

## Part 1: What is a Security Incident?

### Foundational Definitions

Before we can respond to an incident, we must first understand what qualifies as one. Three major frameworks define incidents slightly differently, but the concepts are consistent.

#### NIST SP 800-61 Definition

> A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

NIST's definition is deliberately broad to capture all potential threats, not just confirmed breaches. It includes:
- Unauthorised access to systems or data
- Disruption or denial of service
- Unauthorised modification of systems or data
- Suspicious or unusual activity that might indicate a threat

The key word is **violation** — actual or imminent. This means we respond to *potential* threats, not just confirmed ones.

#### ISO 27035 Definition

> An information security incident is a single or a series of unwanted or unexpected information security events that has a significant probability of compromising business operations and threatening information security.

ISO's definition emphasises **business impact** — the incident matters if it threatens operations or information security. A theoretical vulnerability on an unused system isn't an incident; a breach of customer data is.

#### SANS Definition (Operational)

> An incident is an occurrence that actually or potentially jeopardises the confidentiality, integrity, or availability (CIA) of an information system or the information the system processes, stores, or transmits.

SANS's definition uses the **CIA triad** — Confidentiality, Integrity, Availability. Any event that threatens any of these three is an incident. This operational definition is practical for SOC teams.

### The Incident Spectrum: Event → Alert → Incident → Breach

These terms are often confused. Here's the progression:

#### Event
A **change in state** of a system or network. Most events are benign.

**Examples:**
- A user logs in to a system
- A network packet is transmitted
- A file is opened or modified
- A process starts or stops
- An application crashes
- A scheduled backup runs
- A log file rotates
- A cron job executes

**Frequency:** Millions per day on any given network.
**Response:** None needed; events are captured by logging but mostly ignored.

#### Alert
An **automated notification** triggered when an event matches a detection rule.

**Examples:**
- Intrusion detection system (IDS) flags suspicious traffic
- Antivirus detects a malicious file hash
- SIEM correlation rule fires on suspicious behaviour
- Firewall blocks traffic from a blacklisted IP
- File integrity monitoring detects unauthorised file change
- DLP (Data Loss Prevention) blocks data exfiltration attempt
- EDR (Endpoint Detection and Response) detects suspicious process injection

**Frequency:** Hundreds to thousands per day on a large network.
**Response:** Triage by SOC analyst. Determine if alert is valid (true positive) or false positive.

**False positive rate matters:** If your detection system generates 1000 alerts per day but 95% are false positives, your team is overwhelmed. Tuning alerts to reduce false positives is a core SOC responsibility.

#### Incident
An **alert that has been triaged and confirmed** as a real security event requiring response.

**Examples:**
- A file flagged as malware is confirmed to be present on a production server
- Multiple failed login attempts escalate to a successful breach of a privileged account
- A data exfiltration alert reveals actual data has left the network
- Suspicious process injection is confirmed as active malware
- Insider is confirmed accessing files outside their role

**Frequency:** Tens to hundreds per month on a mature network (depends on maturity and size).
**Response:** Full incident response procedure initiated.

#### Breach (or Compromise)
An **incident where attackers have achieved their objective** and obtained access to or stolen confidential information.

**Examples:**
- Customer data has been confirmed exfiltrated and is known to be in attacker's hands
- Attacker maintains persistent access (backdoor, webshell, etc.)
- Encryption keys or secrets have been compromised
- Financial fraud or unauthorised transactions have occurred
- Intellectual property has been stolen

**Frequency:** Varies wildly; some organisations go years without a confirmed breach; others have multiple per year.
**Response:** Escalation to executive level. External notifications and legal involvement likely. Regulatory reporting required.

### Visual Progression

```
Events (Millions/day)
    ↓ [Detection rule matches]
Alerts (Hundreds/day)
    ↓ [Analyst confirms true positive]
Incidents (Tens/month)
    ↓ [Attackers achieve objective or data is confirmed compromised]
Breach (Rare but critical)
    ↓ [Regulatory reporting, customer notification, legal involvement]
```

### Key Distinctions

| Characteristic | Event | Alert | Incident | Breach |
|---|---|---|---|---|
| **Confirmation** | Automated logging | Automated detection | Human verified | Human + external verified |
| **Severity** | Unknown | Potential | Real | Critical |
| **Action** | Log and forget | Triage | Full response | Escalation + legal |
| **Frequency** | Millions/day | Hundreds/day | Tens/month | Varies |
| **Investigation** | None | Minutes | Hours–days | Days–weeks |

---

## Part 2: Categories of Security Incidents

Security incidents come in many forms. Understanding each category helps with detection, response, and recovery. We'll categorise by attack type, then discuss characteristics and response implications.

### 2.1 Malware Infections

**Malware** (malicious software) is code designed to harm systems or users. It's one of the most common incident categories.

#### Types of Malware

**Ransomware**
- **Definition:** Encrypts victim's files, demands payment for decryption key
- **Characteristics:**
  - File extensions change (.locked, .encrypted, .ransom, etc.)
  - Ransom note appears on screen or in text files
  - Network shares and backups also encrypted
  - May include data exfiltration threat
- **Impact:** Complete loss of access to data; operational shutdown
- **Examples:** WannaCry, NotPetya, REvil, Lockbit, LockBit 3.0
- **Response:** Immediate isolation, backup verification, law enforcement notification, no negotiation (generally advised)

**Spyware**
- **Definition:** Monitors user activity and exfiltrates sensitive information
- **Characteristics:**
  - Runs silently in background
  - Keylogging, screen capture, clipboard monitoring
  - Credential theft
  - May be deployed by insiders or attackers with access
- **Impact:** Privacy breach, credential compromise, potential espionage
- **Examples:** NetWire, Agent Tesla, Azorult, Emotet (information-stealing variant)
- **Response:** User education, credential reset, system rebuild, enhanced monitoring

**Trojans**
- **Definition:** Appears legitimate but performs malicious function
- **Characteristics:**
  - Delivered as legitimate-looking application or file
  - Once executed, opens backdoor for attacker access
  - May drop additional malware
  - Often requires user execution
- **Impact:** System compromise, lateral movement, data theft
- **Examples:** Emotet, Trickbot, Zeus, BlackEnergy
- **Response:** Isolation, evidence preservation, malware analysis, backdoor closure

**Worms**
- **Definition:** Self-replicating malware that spreads across networks without user action
- **Characteristics:**
  - Exploits network vulnerabilities to spread
  - No user interaction required
  - Can spread to thousands of systems rapidly
  - Often causes DoS or resource exhaustion
- **Impact:** Network-wide compromise, operational disruption
- **Examples:** WannaCry (also ransomware), Stuxnet (also worm/trojan), Nimda
- **Response:** Immediate network isolation, patch deployment, lateral movement investigation

**Rootkits**
- **Definition:** Provides attacker with privileged access while hiding its presence
- **Characteristics:**
  - Loads at OS kernel level (very difficult to detect)
  - Hides files, processes, and network connections
  - Persists across reboots
  - Standard antivirus may not detect
- **Impact:** Complete system compromise, persistence, forensic contamination
- **Examples:** ZeroAccess, TDSS, kernel-mode rookits
- **Response:** Full system rebuild (not just removal), memory forensics, boot sector analysis

#### Malware Incident Response Overview

1. **Detection:** Antivirus alert, EDR detection, user report, or network traffic analysis
2. **Isolation:** Disconnect infected system from network
3. **Evidence:** Capture memory image, disk image, volatile data
4. **Analysis:** Determine malware type, functionality, C2 infrastructure
5. **Containment:** Block C2 domains/IPs, prevent lateral movement
6. **Eradication:** Remove malware (if possible), patch vulnerabilities
7. **Recovery:** Rebuild system or restore from backup
8. **Monitoring:** Watch for re-infection or lateral movement

See [[Incident-Types/08a-Malware-Incidents|Malware Incidents]] for detailed procedures.

### 2.2 Phishing / Social Engineering

**Phishing** is a social engineering attack that tricks users into revealing information or executing malicious code.

#### Phishing Attack Types

**Email Phishing**
- **Definition:** Fraudulent email attempting to trick user into clicking link or opening attachment
- **Characteristics:**
  - Impersonates legitimate sender (bank, vendor, colleague, executive)
  - Urgency ("confirm your account immediately", "urgent security alert")
  - Asks user to click link, open attachment, or enter credentials
  - Link may lead to credential-harvesting site or drive-by malware download
- **Impact:** Credential compromise, malware infection, data theft
- **Examples:** Business Email Compromise (BEC), credential phishing, malware distribution
- **Response:** Email isolation, credential reset if compromised, user education, detection rule creation

**Spear Phishing**
- **Definition:** Targeted phishing attack against specific individual or organisation
- **Characteristics:**
  - Highly personalised (includes victim's name, company, recent events)
  - Often used by APT groups
  - Higher success rate than mass phishing
  - Reconnaissance phase (attacker researches target)
- **Impact:** Targeted credential compromise, APT foothold, espionage
- **Examples:** APT phishing campaigns, executive targeting
- **Response:** Investigation into attacker profiling, incident escalation, enhanced monitoring

**Whaling**
- **Definition:** Spear phishing targeting high-value victims (executives, finance staff)
- **Characteristics:**
  - Targets C-level executives or finance staff
  - High-value outcome (wire fraud, data theft, espionage)
  - Highly personalised and researched
- **Impact:** Wire fraud, data theft, ransomware foothold
- **Examples:** CEO fraud, CFO targeted wire transfer attack
- **Response:** Immediate executive notification, transaction freeze, credential reset, investigation

**Vishing** (Voice Phishing)
- **Definition:** Phishing attack over phone
- **Characteristics:**
  - Attacker calls pretending to be IT support, bank, vendor
  - Tricks user into revealing information or executing action
  - Often combined with email phishing
- **Impact:** Credential compromise, social engineering breach
- **Examples:** Tech support scams, bank impersonation
- **Response:** User education, internal call-back verification procedure

**Smishing** (SMS Phishing)
- **Definition:** Phishing attack via SMS text message
- **Characteristics:**
  - Text message with malicious link or credential-harvesting code
  - Often impersonates banking, delivery service, or common vendor
  - Mobile malware may result from link click
- **Impact:** Mobile compromise, credential theft, malware
- **Examples:** Bank phishing texts, delivery service scams
- **Response:** User education, SMS filtering, mobile device management

#### Phishing Incident Response Overview

1. **Detection:** User report, email gateway detection, or URL sandbox alert
2. **Triage:** Identify sender, recipients, timeline, link/attachment
3. **Isolation:** Remove email from user inboxes (if possible), block sender
4. **Evidence:** Preserve email headers, content, and links
5. **Analysis:** Analyse links and attachments (URL sandbox, static analysis)
6. **Containment:** Reset credentials if compromised, block email domain/IP
7. **Notification:** Notify affected users, provide guidance
8. **Prevention:** Create email rule, update URL filtering, user training

See [[Incident-Types/08b-Phishing-Incidents|Phishing Incidents]] for detailed procedures.

### 2.3 Unauthorised Access

**Unauthorised access** incidents involve attackers gaining access to systems or data they shouldn't have permission to access.

#### Access Compromise Scenarios

**Credential Theft**
- **Definition:** Attacker obtains valid username and password
- **Characteristics:**
  - Via phishing, malware, data breach, weak password, credential stuffing
  - Valid credentials used to gain access
  - Hard to detect without monitoring for unusual access patterns
  - May be used for lateral movement or privilege escalation
- **Impact:** Access to systems and data as compromised user
- **Examples:** Compromised AD account, stolen API credentials, vendor account takeover
- **Response:** Credential reset, force password change, review access logs, MFA enforcement

**Brute Force Attack**
- **Definition:** Attacker tries many password combinations to guess valid credentials
- **Characteristics:**
  - Many failed login attempts followed by success
  - May be distributed across multiple IPs to avoid rate limiting
  - Often targets weak passwords
  - May succeed against accounts with simple passwords
- **Impact:** Account compromise, potential privilege escalation
- **Examples:** RDP brute force, SSH brute force, web application login brute force
- **Response:** Rate limiting, account lockout policies, MFA, strong password requirements

**Insider Access**
- **Definition:** Legitimate employee or contractor uses their access for unauthorised purposes
- **Characteristics:**
  - Valid credentials with legitimate access
  - Accesses files/systems outside their normal duties
  - May copy, download, or exfiltrate data
  - Hard to detect without behavioural monitoring
- **Impact:** Data theft, espionage, sabotage
- **Examples:** Employee accessing HR files, contractor exfiltrating source code
- **Response:** Investigation, evidence preservation, account suspension, legal coordination

**Weak Authentication**
- **Definition:** Systems with inadequate authentication controls
- **Characteristics:**
  - Default credentials (admin/admin, root/root)
  - Hardcoded API keys or passwords
  - No MFA
  - Shared accounts
  - Legacy systems without modern authentication
- **Impact:** Trivial compromise of multiple systems
- **Examples:** Network device with default password, application with hardcoded credentials
- **Response:** Credential reset, MFA deployment, API key rotation, security hardening

#### Unauthorised Access Incident Response Overview

1. **Detection:** Failed login monitoring, access review, or behavioural analysis
2. **Verification:** Confirm access was unauthorised (check user location, time, etc.)
3. **Evidence:** Collect access logs, security logs, audit trails
4. **Scope:** Determine what systems/data were accessed
5. **Isolation:** If active, immediately revoke access
6. **Investigation:** Determine compromise vector (phishing, weak password, malware, insider, etc.)
7. **Remediation:** Reset credentials, patch vulnerabilities, close access vector
8. **Monitoring:** Enhanced logging on accessed systems for follow-up access

See [[Incident-Types/08e-Insider-Threat|Insider Threat]] for detailed procedures on insider-specific incidents.

### 2.4 Denial of Service (DoS) / Distributed Denial of Service (DDoS)

**DoS/DDoS attacks** disrupt service availability by overwhelming systems with traffic or requests.

#### DoS Attack Types

**Volumetric Attacks**
- **Definition:** Attacker floods network/service with massive traffic volume
- **Characteristics:**
  - Consumes all available bandwidth
  - May use botnet for amplification (DDoS)
  - Often uses UDP or ICMP
  - Difficult to mitigate without ISP support
- **Impact:** Service unavailability, customer impact, revenue loss
- **Examples:** UDP flood, DNS amplification, NTP reflection, SMURF attack
- **Response:** ISP-level mitigation, traffic filtering, rate limiting, DDoS service activation

**Protocol Attacks**
- **Definition:** Exploit weaknesses in network protocols
- **Characteristics:**
  - SYN floods (TCP handshake exhaustion)
  - Fragmented packet attacks
  - Malformed packets
  - Ping of death
- **Impact:** Service unavailability, resource exhaustion
- **Examples:** SYN flood, Ping of Death, Smurf attack
- **Response:** Firewall tuning, rate limiting, ISP filtering, DDoS mitigation

**Application-Layer Attacks**
- **Definition:** Target weaknesses in application logic
- **Characteristics:**
  - HTTP floods (legitimate-looking requests)
  - Slowloris attack (slow client exhaustion)
  - DNS query floods
  - Database query exhaustion
- **Impact:** Application unavailability, database exhaustion
- **Examples:** HTTP GET flood, Slowloris, DNS query flood
- **Response:** Application firewall (WAF), rate limiting, caching, code optimisation

#### DDoS Incident Response Overview

1. **Detection:** Sudden traffic spike, service unavailability, or DDoS alert
2. **Verification:** Confirm attack vs. legitimate traffic surge
3. **Isolation:** Activate DDoS mitigation (if service exists)
4. **Filtering:** Block obvious attack traffic, whitelist legitimate sources
5. **Escalation:** Notify ISP, activate DDoS protection service
6. **Analysis:** Identify attack type, traffic source, attack vector
7. **Remediation:** Apply targeted filters, rate limiting, application hardening
8. **Recovery:** Restore service, verify normal operations
9. **Post-Incident:** Analyse attack logs, strengthen resilience

See [[Incident-Types/08f-DDoS-Incidents|DDoS Incidents]] for detailed procedures.

### 2.5 Data Exfiltration / Data Breach

**Data breach** incidents involve unauthorised access to or theft of confidential information.

#### Data Breach Scenarios

**External Data Theft**
- **Definition:** Attacker breaks in and exfiltrates data
- **Characteristics:**
  - Breach followed by data exfiltration
  - Detected via network monitoring, data loss prevention, or ransom demand
  - May involve long dwell time (weeks/months before exfiltration)
  - Often involves APT group
- **Impact:** Loss of confidentiality, regulatory breach, customer trust loss
- **Examples:** APT exfiltrating trade secrets, competitor theft
- **Response:** Forensic investigation, scope determination, notification, ransom intelligence

**Insider Data Theft**
- **Definition:** Employee or contractor steals data
- **Characteristics:**
  - Legitimate user accessing authorised data
  - Copying to personal device, USB, cloud service
  - May be motivated by money (sale to competitor) or ideology
  - Hard to detect without DLP monitoring
- **Impact:** Loss of confidentiality, espionage, competitive harm
- **Examples:** Employee selling customer list, contractor exfiltrating source code
- **Response:** Investigation, forensic imaging, legal hold, law enforcement coordination

**Unsecured Data Exposure**
- **Definition:** Sensitive data exposed due to misconfiguration, not active attack
- **Characteristics:**
  - S3 bucket publicly accessible
  - Database without authentication
  - Backup exposed on network
  - Code repository with hardcoded credentials
  - Often discovered by security researcher or competitor
- **Impact:** Loss of confidentiality, regulatory violation, reputation damage
- **Examples:** AWS S3 misconfiguration, Elasticsearch without auth, exposed backups
- **Response:** Immediate access restriction, scope assessment, notification if required

**Loss or Theft of Physical Media**
- **Definition:** Laptop, hard drive, or USB device with sensitive data is lost or stolen
- **Characteristics:**
  - Physical security breach
  - May or may not have encryption
  - Unknown if data was accessed
  - Often detected much later
- **Impact:** Potential loss of confidentiality, regulatory risk
- **Examples:** Executive loses laptop at airport, USB drive left in taxi, hard drive disposal failure
- **Response:** Forensic verification (was data accessed?), notification if required, security hardening

#### Data Breach Incident Response Overview

1. **Detection:** DLP alert, network monitoring, ransom demand, or researcher notification
2. **Verification:** Confirm data breach has occurred
3. **Scope:** Determine what data was stolen, which systems compromised
4. **Evidence:** Preserve logs, timeline, exfiltration evidence
5. **Investigation:** Determine attack vector and attacker identity
6. **Containment:** Stop ongoing exfiltration, close breach vector
7. **Notification:** Determine regulatory requirements (GDPR 72 hours, etc.)
8. **Recovery:** Strengthen security, deploy additional controls
9. **Monitoring:** Track if stolen data is published, traded, or exploited

See [[Incident-Types/08d-Data-Breach-Incidents|Data Breach Incidents]] for detailed procedures.

### 2.6 Web Application Attacks

**Web application** attacks exploit vulnerabilities in web-based applications.

#### Common Web Attacks

**SQL Injection (SQLi)**
- **Definition:** Attacker injects malicious SQL code into application input
- **Characteristics:**
  - Vulnerable input field doesn't properly sanitise SQL code
  - Attacker can read, modify, or delete database records
  - Can lead to remote code execution on database server
- **Impact:** Data theft, data modification, database compromise
- **Examples:** Classic SQLi, blind SQLi, time-based SQLi, second-order SQLi
- **Response:** Application patching, WAF rule deployment, database audit

**Cross-Site Scripting (XSS)**
- **Definition:** Attacker injects malicious JavaScript into web page
- **Characteristics:**
  - Vulnerable application doesn't sanitise user input
  - JavaScript executes in victim's browser
  - Can steal cookies, session tokens, credentials
  - Can perform actions on behalf of victim
- **Impact:** Session hijacking, credential theft, malware distribution
- **Examples:** Reflected XSS, stored XSS, DOM-based XSS
- **Response:** Application patching, input validation, WAF rules, cookie security

**Remote Code Execution (RCE)**
- **Definition:** Attacker executes arbitrary code on web server
- **Characteristics:**
  - Vulnerability in application allows code execution
  - Attacker gains shell access to server
  - Can read files, modify application, install backdoor
  - Critical severity
- **Impact:** Complete system compromise, data theft, lateral movement
- **Examples:** CVE exploits, command injection, template injection, deserialization attacks
- **Response:** Immediate patching, forensic investigation, access review, backdoor removal

**Cross-Site Request Forgery (CSRF)**
- **Definition:** Attacker tricks authenticated user into making unintended request
- **Characteristics:**
  - User is already authenticated to vulnerable application
  - Attacker crafts request that application will execute
  - User doesn't realise malicious action occurred
- **Impact:** Unauthorised actions (password change, fund transfer, permission change)
- **Examples:** Malicious form submission, automatic redirect
- **Response:** Application patching, CSRF token implementation

#### Web Application Attack Incident Response Overview

1. **Detection:** WAF alert, application error log, vulnerability scanner, or user report
2. **Verification:** Confirm attack occurred (access logs, application logs)
3. **Evidence:** Preserve application logs, database logs, firewall logs
4. **Analysis:** Determine attack type, identify payload, understand impact
5. **Scope:** Determine what data/functions were affected
6. **Investigation:** Identify attacker (IP, origin), determine motivation
7. **Containment:** WAF rule to block attack, input validation fix
8. **Recovery:** Patch application, audit database changes
9. **Prevention:** Code review, security testing, WAF rule tuning

See [[Incident-Types/08g-Web-Application-Attacks|Web Application Attacks]] for detailed procedures.

### 2.7 Insider Threats

**Insider threats** involve people with legitimate access misusing that access for harmful purposes.

#### Insider Threat Types

**Malicious Insider**
- **Definition:** Employee or contractor intentionally misuses access for personal gain
- **Characteristics:**
  - Motivated by money (selling secrets), ideology, revenge, or competition
  - Often has legitimate access to sensitive information
  - Planned activity (not opportunistic)
  - May exfiltrate large volumes of data
  - Often discovered only after data appears on dark web or in competitor's product
- **Impact:** Trade secret theft, espionage, competitive harm, IP loss
- **Examples:** Engineer selling source code to competitor, finance analyst stealing customer data
- **Response:** Investigation, evidence preservation, law enforcement coordination, legal action

**Negligent Insider**
- **Definition:** Employee accidentally causes security issue through negligence or ignorance
- **Characteristics:**
  - No malicious intent
  - Lack of security awareness (sharing passwords, using weak passwords)
  - Misconfiguration of systems
  - Falls for social engineering
  - May expose sensitive information unintentionally
- **Impact:** Varies (credential compromise, data exposure, system misconfiguration)
- **Examples:** Leaving laptop unlocked, weak password, sharing password with colleague, falling for phishing
- **Response:** User education, access review, security hardening, monitoring

**Compromised Insider**
- **Definition:** Legitimate employee whose account is compromised by attacker
- **Characteristics:**
  - Not the employee's fault (stolen credentials, malware, etc.)
  - Attacker uses employee's access for attack
  - May include lateral movement or data theft
  - Can be difficult to distinguish from malicious insider initially
- **Impact:** System compromise, lateral movement, data theft
- **Examples:** Employee credential phished, employee system compromised by malware
- **Response:** Credential reset, account investigation, forensic analysis, lateral movement detection

#### Insider Threat Incident Response Overview

1. **Detection:** User behaviour analytics, DLP alert, access review, or suspicious activity report
2. **Investigation:** Interview user, review access logs, analyse file access patterns
3. **Evidence:** Preserve logs, forensic image of systems, email records
4. **Scope:** Determine what data was accessed, modified, or exfiltrated
5. **Containment:** If malicious, immediately suspend/revoke access
6. **Legal Coordination:** May involve HR, legal, and law enforcement
7. **Monitoring:** Enhanced monitoring of related accounts
8. **Recovery:** Credential reset, data remediation, policy review

See [[Incident-Types/08e-Insider-Threat|Insider Threat]] for detailed procedures.

### 2.8 Advanced Persistent Threats (APT)

**APT** groups are sophisticated attackers (typically nation-state or well-funded criminal groups) who conduct long-term, targeted campaigns.

#### APT Characteristics

- **Motivation:** Espionage, competitive advantage, sabotage, financial gain
- **Skills:** Advanced exploitation, custom tools, persistence techniques, evasion
- **Resources:** Well-funded, patient, long-term campaigns (months/years)
- **Tactics:** Spear phishing, supply chain attacks, zero-day exploits, C2 infrastructure
- **Persistence:** Multiple backdoors, persistence mechanisms, stealth
- **Dwell Time:** APT groups often remain undetected for months or years before discovery
- **Indicators:** Custom malware, sophisticated techniques, targeting of specific industries/entities

#### APT Response Considerations

- **Intelligence Value:** APT incidents provide valuable intelligence about attacker capabilities
- **Forensic Priority:** Full forensic investigation and evidence preservation critical
- **Network Isolation:** Long-term network monitoring to detect persistence and lateral movement
- **Supply Chain Check:** Determine if other customers/partners affected
- **Law Enforcement:** Often appropriate to involve FBI or national equivalent
- **Threat Intelligence Sharing:** Share indicators with industry peers

See incident type modules for APT-specific response guidance.

### 2.9 Supply Chain Attacks

**Supply chain** attacks target an organisation through third-party vendors or software.

#### Supply Chain Attack Scenarios

**Software Supply Chain**
- **Definition:** Attacker compromises software vendor, inserts malware into legitimate software
- **Characteristics:**
  - Legitimate software from trusted vendor contains malware
  - Distributed to thousands of customers
  - Difficult to detect (trusted source)
  - Often sophisticated attackers
- **Impact:** Widespread compromise across customer base
- **Examples:** SolarWinds Orion compromise, 3CX supply chain attack, CCleaner malware injection
- **Response:** Vendor communication, software version verification, malware detection, isolation

**Vendor/Third-Party Compromise**
- **Definition:** Attacker compromises vendor's systems to access customer data
- **Characteristics:**
  - Vendor has access to customer systems or data
  - Attacker uses vendor's access for lateral movement or data theft
  - May be part of APT campaign
  - Difficult to detect (legitimate vendor access)
- **Impact:** Customer system compromise, data theft, lateral movement
- **Examples:** APT targeting vendor to access downstream customers, managed service provider compromise
- **Response:** Vendor investigation, customer notification, enhanced monitoring

#### Supply Chain Incident Response Overview

1. **Detection:** Vendor notification, software hash verification, or malware alert
2. **Verification:** Confirm software version is compromised
3. **Scope:** Determine if your organisation was affected
4. **Isolation:** If affected, isolate affected systems
5. **Analysis:** Determine attacker identity, malware functionality, persistence
6. **Investigation:** Determine if systems were compromised through supply chain attack
7. **Recovery:** Patch or replace affected software
8. **Vendor Coordination:** Work with vendor on remediation and disclosure

### 2.10 Physical Security Incidents

**Physical security** incidents involve breach of physical security controls.

#### Physical Security Incident Types

**Unauthorised Physical Access**
- **Definition:** Attacker gains physical access to building or data centre
- **Characteristics:**
  - Tailgating (following authorised person through locked door)
  - Badge cloning or theft
  - Social engineering (impersonating employee or contractor)
  - Lock picking or bypass
- **Impact:** Direct access to systems, data theft, hardware theft, sabotage
- **Examples:** Attacker accessing data centre to install physical monitoring device, corporate office break-in
- **Response:** Building lock-down, inventory check, CCTV review, incident escalation

**USB Drop / Rogue Device**
- **Definition:** Attacker leaves malicious USB device or hardware in office area
- **Characteristics:**
  - USB device contains malware or implant
  - Employee plugs it in, causing infection
  - May have label to encourage connection ("Employee Salary Info")
  - Can bypass network controls
- **Impact:** Malware infection, credential theft, lateral movement
- **Examples:** USB with malware in parking lot, rogue keyboard with implant
- **Response:** User education, USB restrictions, malware analysis, infected system remediation

**Hardware Implant**
- **Definition:** Attacker installs hardware device (monitoring, persistence) on system
- **Characteristics:**
  - Installed inside computer, network device, or keyboard
  - Difficult to detect without physical inspection
  - May provide C2 access or monitoring
  - Often used by sophisticated attackers (APT, law enforcement)
- **Impact:** Persistent access, network monitoring, credentials interception
- **Examples:** Hacking Team implant, USB device in keyboard, network device compromise
- **Response:** Physical security review, device inventory, forensic analysis, network monitoring

---

## Part 3: Incident Severity Classification

Severity classification determines response urgency and resource allocation. Every organisation should have a defined severity matrix. Here's a comprehensive framework aligned with industry best practices.

### Severity Levels

#### Critical / Priority 1 (P1)

**Definition:** Active, system-wide security compromise with immediate business impact.

**Characteristics:**
- System-wide compromise (domain compromise, widespread malware, etc.)
- Active ransomware encryption occurring
- Data exfiltration happening now
- Multiple critical systems offline
- Executive systems compromised
- Active attacker on network

**Response SLA:** Immediate (< 15 minutes to initial response)
**Team Mobilisation:** Full incident response team + external escalation
**Examples:**
- Ransomware attack encrypting files across network
- Domain controller compromise
- Data exfiltration to external IP in progress
- DDoS attack causing service outage
- Confirmed APT persistence

**Response Actions:**
- Immediate network isolation
- Full team activation
- Executive notification
- External escalation (ISP, law enforcement)
- 24/7 monitoring activation

#### High / Priority 2 (P2)

**Definition:** Confirmed intrusion or significant compromise requiring immediate remediation.

**Characteristics:**
- Confirmed malware on production system
- Active C2 communication detected
- Privileged account compromise
- Significant unauthorised access
- Potential for lateral movement
- Regulatory breach potential

**Response SLA:** 1–2 hours to initial response
**Team Mobilisation:** Incident response team activation
**Examples:**
- Confirmed trojaned server with C2 connection
- Admin account password breached
- Unauthorised access to financial systems
- Insider stealing confidential data
- Vulnerability actively exploited

**Response Actions:**
- System isolation
- Evidence collection
- Forensic analysis
- Lateral movement investigation
- Stakeholder notification

#### Medium / Priority 3 (P3)

**Definition:** Suspicious activity or policy violation requiring investigation.

**Characteristics:**
- Suspicious but unconfirmed activity
- Isolated malware detection
- Failed attack attempt
- Policy violation
- Potential security weakness
- Requires investigation to confirm severity

**Response SLA:** 4–8 hours to investigation start
**Team Mobilisation:** SOC team investigation
**Examples:**
- Malware detected and quarantined on single system
- Multiple failed login attempts
- Suspicious network traffic (doesn't yet indicate compromise)
- Weak password detected
- USB device plugged into system (doesn't yet indicate infection)

**Response Actions:**
- Log analysis
- Malware testing
- User interview
- System checks
- Monitoring enhancement

#### Low / Priority 4 (P4)

**Definition:** Minor issue or false positive requiring verification.

**Characteristics:**
- Likely false positive
- Minor policy violation
- Low-risk security finding
- Informational alert
- No evidence of compromise

**Response SLA:** 1–3 days
**Team Mobilisation:** SOC analyst (normal shift)
**Examples:**
- Antivirus alert for known benign software
- Expired SSL certificate warning
- Failed update notification
- Minor security control failure (non-critical)
- Log message of low significance

**Response Actions:**
- Routine investigation
- Documentation
- Resolution
- No urgency

### Severity Scoring Matrix

A more granular approach uses multiple factors to calculate severity:

| Factor | Critical | High | Medium | Low |
|--------|----------|------|--------|-----|
| **Scope** | System/network wide | Multiple systems / single critical | Single system / limited scope | One system / minimal impact |
| **Confirmation** | Confirmed compromise | Confirmed threat/intrusion | Suspicious/unconfirmed | False positive likely |
| **Urgency** | Active/ongoing | Imminent threat | Potential threat | No immediate threat |
| **Data Impact** | Confidentiality OR Integrity OR Availability | Two of three compromised | One of three potentially compromised | No data impact |
| **User Impact** | Hundreds+ users | 10–100 users | 1–10 users | 0 users |
| **Business Impact** | Revenue loss / operational shutdown | Significant disruption | Moderate disruption | Minimal/none |
| **Attacker Activity** | Active/persistent | Active/exploratory | Unknown/suspected | Not applicable |

**Scoring:** 5+ critical factors = P1; 3+ high factors + critical factors = P2; etc.

### SLA (Service Level Agreement) Response Times

These should be defined by your organisation and communicated to stakeholders:

| Severity | Detection | Triage | Investigation Start | Status Update | Full Response |
|----------|-----------|--------|--------|---|---|
| **P1** | Immediate | 15 min | 15 min | Every 30 min | Ongoing |
| **P2** | 30 min | 1 hour | 2 hours | Every 4 hours | 8–24 hours |
| **P3** | 4 hours | 8 hours | 24 hours | Weekly | 5–7 days |
| **P4** | 24 hours | 48 hours | 72 hours | As needed | 30 days |

---

## Part 4: Common Attack Vectors

Attackers don't randomly compromise organisations — they use specific vectors. Understanding these helps with detection and prevention.

### External Attack Vectors

**Internet-Facing Systems**
- Web servers, email servers, VPN gateways, remote access portals
- Vulnerabilities exploited: unpatched software, misconfigurations, weak authentication
- Response: Patch management, WAF, network segmentation, monitoring

**Email**
- Phishing, spear phishing, malware distribution, compromise of email account
- Vulnerabilities exploited: user social engineering, weak passwords, email gateway bypass
- Response: Email filtering, user training, MFA, email authentication (DMARC, SPF, DKIM)

**Web-Based Applications**
- OWASP top 10 vulnerabilities (SQLi, XSS, RCE, etc.)
- Vulnerabilities exploited: insecure coding, insufficient input validation
- Response: Code review, security testing, WAF, patching

**Supply Chain**
- Third-party software, vendor compromise, supply chain attack
- Vulnerabilities exploited: trust in third parties
- Response: Vendor assessment, code signing verification, monitoring

### Internal Attack Vectors

**Lateral Movement**
- Once initial access obtained, attacker moves through network
- Methods: credential harvesting, exploit chaining, trust relationships
- Response: Network segmentation, monitoring, privilege restriction

**Privilege Escalation**
- Attacker escalates from user access to administrative access
- Methods: kernel exploit, privilege escalation vulnerability, credential theft
- Response: Patch management, privilege restriction, monitoring

**Data Exfiltration**
- Attacker moves stolen data out of network
- Methods: DNS tunnelling, HTTPS to attacker C2, email exfiltration
- Response: DLP, network monitoring, egress filtering

### Physical Attack Vectors

**Physical Access**
- Tailgating, social engineering, lock picking, badge cloning
- Response: Physical security controls, access logging, monitoring

**Removable Media**
- USB drives, external hard drives, mobile devices
- Response: Endpoint DLP, USB restrictions, mobile device management

---

## Part 5: Indicators of Compromise (IOCs) vs Indicators of Attack (IOAs)

Understanding the difference between IOCs and IOAs is critical to incident response. Both are valuable, but IOAs are more actionable.

### Indicators of Compromise (IOCs)

**Definition:** Observable artifacts left behind by an attacker.

IOCs are "footprints" of an attack — specific data points that indicate compromise has occurred.

#### IOC Types

**File-Based IOCs**
- File hash (MD5, SHA1, SHA256) of malware
- File path (C:\Windows\System32\malware.exe)
- Filename (ransomware creates .locked files)
- File creation/modification timestamps
- Example: `SHA256: 5d41402abc4b2a76b9719d911017c592`

**Network IOCs**
- Command and Control (C2) IP addresses
- Domain names used for C2 or data exfiltration
- Network port used for communication
- URL pattern used in exploit
- Example: `192.168.1.100:8080` or `malware-c2.evil.com`

**Registry IOCs** (Windows)
- Registry key modified by malware
- Registry value added by trojan (persistence mechanism)
- Example: `HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run`

**Log-Based IOCs**
- Event ID generated by attack (e.g., failed login spike)
- Specific log message indicating malware activity
- Unusual process creation
- Example: 4688 event (process creation) with suspicious arguments

**Behavioural IOCs**
- Process behaviour (process injection, memory modification)
- Network behaviour (C2 beacon pattern)
- File system behaviour (encrypted file creation pattern)
- Example: Process creating .encrypted files + sending DNS queries to C2 domain

#### IOC Limitations

IOCs have significant limitations:

- **Short lifespan:** Attackers change infrastructure (IP, domain) regularly
- **Attacker dependency:** Different attackers use different tools/infrastructure
- **Environment specific:** IOC in one environment may not appear in another
- **Reusable infrastructure:** Multiple attackers may use same public malware
- **Easy to evade:** Attackers constantly change tactics to avoid IOC detection

### Indicators of Attack (IOAs)

**Definition:** Observed patterns of behaviour that indicate an attack is occurring (or has occurred).

IOAs focus on *how* attackers behave, not *what* they use. They're more durable because they target fundamental attack patterns rather than specific tools.

#### IOA Examples

**Reconnaissance IOAs**
- Network scanning activity (port scanning, service discovery)
- User enumeration (username validation attempts)
- Vulnerability scanning (web application scanner activity)
- DNS reconnaissance (DNS query for all subdomains)

**Exploitation IOAs**
- Web server returning 5xx errors followed by shell access
- Unusual process spawning (system.exe creating cmd.exe)
- Network access from system process (svchost.exe making outbound connection)

**Persistence IOAs**
- New user creation on system
- Scheduled task creation with unusual executable
- Startup folder modification
- Registry run key addition
- Service installation with suspicious binary

**Privilege Escalation IOAs**
- Process requesting administrator token
- HKEY_LOCAL_MACHINE modification by unprivileged process
- Token impersonation
- SeImpersonate privilege exploitation

**Lateral Movement IOAs**
- Failed login attempts across multiple systems
- Administrative shares enumeration
- Remote service installation
- WMI/RPC activity to remote systems
- Pass-the-hash credential usage (same NTLM hash from multiple IPs)

**Exfiltration IOAs**
- Large data volume to external IP
- FTP/SCP activity to external location
- SFTP activity outside normal business hours
- Unusual DNS query volume (DNS tunnelling)
- Zip/rar file creation followed by external transfer

**Command and Control IOAs**
- Regular HTTP/HTTPS traffic to known C2 domain
- Beaconing pattern (regular connection at fixed interval)
- DNS TXT record queries (C2 command retrieval)
- HTTP POST to unusual path with unusual headers
- Traffic to multiple ports on same IP sequentially

#### IOA Advantages

- **Durable:** Fundamental attack patterns don't change as quickly as tools
- **Preventive:** IOAs can detect attacks before specific tools are used
- **Attacker-agnostic:** Same IOA detects multiple different attacks
- **Actionable:** IOAs directly inform detection and response

### The Pyramid of Pain (David Bianco)

The Pyramid of Pain illustrates the concept that some indicators are more "painful" for attackers to change:

```
                  ▲
               6. Tactics
              5. Tools
            4. TTPs (Techniques)
          3. Host Artefacts
        2. Network Indicators
      1. IOCs (Hash, IP, Domain)
    ───────────────────────────────
    Easy to Change    ←→    Hard to Change
    Low Value                High Value
```

**Level 1: IOCs (Hash, IP, Domain)** — Easiest for attackers to change
- Attacker simply changes domain, rotates IP, modifies malware (changing hash)
- Very low "pain" level for attacker

**Level 2: Network Indicators** — Moderate difficulty
- Email headers, user agents, Jitter values in C2 beacon
- Attacker must modify tooling/tactics

**Level 3: Host Artefacts** — More difficult
- File paths, registry keys, process names, scheduled task names
- Attacker must modify installation/persistence mechanisms

**Level 4: Tools** — Difficult to change
- Custom malware families, exploit kits, C2 frameworks
- Attacker must develop new tools or modify significantly

**Level 5: TTPs** — Highly painful
- Attack techniques (Pass-the-Hash, Kerberoasting, Living-off-the-Land binaries)
- Attacker must change fundamental approach

**Level 6: Tactics** — Most painful to change
- Reconnaissance, Weaponization, Delivery, etc. (Kill Chain)
- Attacker would need to completely change approach

**Implication:** Focus detection and hunting on higher levels of the pyramid (TTPs, Tools, Tactics) rather than low-level IOCs. IOCs are useful for quick detection, but TTPs are the foundation of robust defence.

---

## Part 6: The Cost of Incidents

Understanding the cost of security incidents helps justify incident response investment and highlights the importance of rapid response.

### IBM Cost of a Data Breach Report (2023 Edition)

IBM's annual "Cost of a Data Breach" report provides industry benchmark data:

**Global Average Cost:** USD 4.45 million per breach

**Cost Breakdown:**
- **Incident Response & Management:** 28% of total cost
- **Detection & Escalation:** 27%
- **Post-Breach Costs:** 25% (notifications, credit monitoring, etc.)
- **Lost Business:** 20% (customer loss, downtime, etc.)

**Per-Record Cost:** USD 165 per compromised record

**Cost Variables (can increase cost 1.5–2x):**
- Industry (healthcare highest ~USD 11 million average)
- Country/region (Germany, Canada, UAE among highest)
- Attack type (ransomware highest cost, phishing lowest)
- Severity (C-level compromise costs 2x more than employee)
- Time to identify (190 days average; over 200 days costs ~30% more)
- Time to contain (77 days average)

### Cost Reduction Through Fast Response

**Time to Identify Impact:**
- < 30 days: USD 3.89 million average
- 30–90 days: USD 4.41 million average
- > 90 days: USD 5.08 million average

**Conclusion:** Reducing detection time by 30 days saves approximately USD 1.2 million.

**Time to Contain Impact:**
- < 30 days containment: USD 4.06 million
- 30–90 days containment: USD 4.67 million
- > 90 days containment: USD 5.20 million

**Conclusion:** Faster containment directly reduces cost.

### Cost Categories

#### Direct Costs
- Forensic investigation (external firm: USD 500–2000/hour)
- Data recovery (varies widely; ransomware negotiation: USD 50k–millions)
- System rebuilds and patching
- Incident response team (overtime, external resources)

#### Indirect Costs
- Lost productivity (systems offline, staff time on incident)
- Regulatory fines (GDPR: up to EUR 20 million or 4% of revenue)
- Customer notification (postage, call centres, etc.)
- Credit monitoring (if PII exposed)
- Reputational damage (customer loss, partner relationships)
- Stock price impact (public companies often see drops)
- Insurance costs (cyber insurance renewal + increased premiums)
- Legal costs (litigation, settlements)

### Return on Investment (ROI) for Incident Response

Building incident response capability (team, tools, playbooks) has significant ROI:

- **Cost to build IR capability:** USD 100k–500k annually (depends on organisation size)
- **Cost saved per prevented incident:** USD 1–10 million
- **Cost reduced through faster response:** USD 500k–2 million per incident (time reduction)

Even one prevented or quickly-resolved incident pays for the entire IR programme.

---

## Part 7: Key Roles in Incident Response

Effective incident response requires clear role definitions. Here's the team structure:

### Executive & Strategic Roles

**Chief Information Security Officer (CISO)**
- **Responsibility:** Overall security programme, policy, budget, executive escalation
- **Decision:** Breach notification, regulatory coordination, major remediation decisions
- **Escalation point:** Board, executive management
- **Availability:** Called for P1 incidents, notified for P2+

**Incident Response Manager / Incident Commander**
- **Responsibility:** Coordinates IR team, makes tactical decisions, manages timeline
- **Decision:** Containment approach, when to call external responders, evidence handling decisions
- **Escalation point:** CISO for strategic decisions
- **Availability:** On-call for P1, responds within SLA for P2+

### Detection & Triage

**Security Operations Centre (SOC) Analyst — L1 (Tier 1)**
- **Responsibility:** Alert triage, initial investigation, false positive filtering
- **Decision:** Alert severity classification, escalation eligibility
- **Investigation depth:** Surface-level (check if alert is valid)
- **Escalation point:** SOC L2 for true positives
- **Availability:** Shift-based

**SOC Analyst — L2 (Tier 2)**
- **Responsibility:** Deeper investigation, log analysis, malware testing, initial scope determination
- **Decision:** Initial severity confirmation, evidence collection start
- **Investigation depth:** Medium (timeline construction, IOC identification, scope check)
- **Escalation point:** SOC L3 or IR Lead for P2+ incidents
- **Availability:** Shift-based with on-call rotation

**SOC Analyst — L3 (Tier 3)**
- **Responsibility:** Complex analysis, threat intelligence correlation, advanced forensics
- **Decision:** Scope determination, containment approach, external escalation needs
- **Investigation depth:** Deep (full timeline, attack chain, attacker identification)
- **Escalation point:** IR Lead for tactical decisions
- **Availability:** On-call for complex incidents

### Specialised Roles

**Forensic Investigator**
- **Responsibility:** Evidence preservation, forensic imaging, detailed system analysis, court-admissible reporting
- **Tools:** FTK Imager, Volatility, Autopsy, EnCase
- **Focus:** Chain of custody, evidence integrity, legal admissibility
- **Escalation:** Called for P1, P2, and any incident with legal implications
- **Availability:** On-call or external firm

**Threat Hunter**
- **Responsibility:** Proactive threat identification, IOC research, adversary profiling
- **Tools:** YARA rules, custom scripts, threat intelligence platforms
- **Focus:** Finding threats before automated detection
- **Availability:** Normal hours (proactive, not reactive)

**Network/Infrastructure Engineer**
- **Responsibility:** Network isolation, system access, account management, system recovery
- **Role in IR:** Executes containment orders, provides system access for investigation, coordinates recovery
- **Escalation:** Part of IR team for technical decisions
- **Availability:** On-call for P1, contacted for P2+

**Systems Administrator**
- **Responsibility:** System access, backup verification, system recovery, patch deployment
- **Role in IR:** Provides access to affected systems, coordinates recovery, validates patches
- **Availability:** On-call or shift-based

### Support Roles

**Legal Counsel**
- **Responsibility:** Regulatory compliance, breach notification requirements, evidence admissibility, attorney-client privilege
- **Decision:** When to notify law enforcement, how to handle evidence, what to communicate externally
- **Escalation:** Called for P1 and any incident involving potential legal action
- **Availability:** As needed

**Compliance Officer**
- **Responsibility:** Regulatory requirements (GDPR, HIPAA, PCI DSS, etc.), breach notification
- **Decision:** Who needs notification, what format, what timeline
- **Escalation:** Involved in P1 and P2 incidents, briefed on P3 incidents
- **Availability:** Normal hours or on-call for P1

**Communications / Public Relations**
- **Responsibility:** Internal communication, stakeholder updates, external statements, media management
- **Decision:** Communication timing, message content, external release approval
- **Escalation:** Involved in P1 and any incident with media implications
- **Availability:** On-call for P1

**Executive Stakeholder** (Finance, Operations, Business Unit Head)
- **Responsibility:** Business decision-making, approval for expensive remediation, stakeholder communication
- **Decision:** Accept risk vs. remediate, budget approval for incident response
- **Escalation:** Notified based on business impact; P1 incidents require executive approval
- **Availability:** As needed for P1

---

## Summary: Key Takeaways

1. **Incidents are broad:** An incident is any security event that violates policy or threatens CIA. Events → Alerts → Incidents → Breaches.

2. **Classification matters:** Severity (P1–P4) determines response urgency. Use SLAs to set expectations. Cost savings are significant for fast response (USD 1.2M+ per 30-day reduction in detection time).

3. **Attack categories are diverse:** Malware, phishing, unauthorised access, DDoS, data breach, web attacks, insider threats, APTs, supply chain, physical. Each requires tailored response.

4. **IOCs are useful but limited:** File hashes, IPs, domains are easy for attackers to change. Focus on IOAs (indicators of attack) and TTPs (tactics, techniques, procedures) for more durable detection.

5. **Cost of incidents is high:** Global average USD 4.45 million. Building IR capability pays for itself through prevention and speed.

6. **Roles are critical:** Clear role definitions ensure efficient response. CISO → IR Manager → SOC L1/L2/L3 → Forensic/Threat specialists.

---

#IncidentHandling #IOC #IOA #Severity #BlueTeam #DFIR