Cybersecurity Readiness & Contingency Planning

By failing to prepare, you are preparing to fail.

• Contingency Planning

  • Covers Incident Response, Business Continuity, Disaster Recovery
  • Defined as preparing for future events that cannot be predicted with certainty
  • Cyber contingency = readiness for incidents that will eventually occur

• Why

  • Preventive controls reduce likelihood, but incidents are inevitable
  • Without planning, even small incidents can escalate into major losses
  • Required by NIST CSF & ISO/IEC 27001

Bow-Tie Diagram

Causes ➜ Incident ➜ Impacts Preventive (likelihood-reducing) controls Mitigating (impact-reducing) controls Does not show impact severity Commonly used for risk assessment (e.g. safety, civil protection, cybersecurity) Bow-tie analysis involves building one or more loop diagrams

Technical Concepts in Cyber Contingency Planning

RPO – Max acceptable data loss since last backup. Shorter RPO = less loss, higher cost. RTO – Time to restore functions after incident. Shorter RTO = faster recovery, higher cost. MTD – Max downtime before business suffers critical impact. Defines DRP/BCP strategy. DRP – Restore damaged systems to normal operation. BCP – Alternative procedures to keep business running during recovery. BIA – Identifies critical functions, dependencies, and sets RPO, RTO, MTD.

Example RTO and RPO for Critical Functions

Criticality	Colour	Crisis Event (RTO / RPO)	Disaster Event (RTO / RPO)
High	Red	RTO: Within 2h (full ops) RPO: 2h	RTO: Reduced ops ≤1 day, full ops ≤7 days RPO: 2h
Medium	Yellow	RTO: ≤8h (full ops) RPO: 24h	RTO: Full ops ≤7 days RPO: 24h
Low	Green	RTO: ≤1 week RPO: 1 week	RTO: Reduced ops ≤3 weeks, full ops ≤4 weeks RPO: 1 week

The Drill

Contingency Planning - Defines what must be protected and how quickly it must be restored (RPO, RTO, MTD). Incident Response - Provides the structured process to detect, contain, eradicate, and recover from incidents. Cybersecurity / Digital Forensics Triad - Brings together the teams and expertise needed to carry out the plan and response in practice.

Recognising an Incidents

• Event: an occurrence that takes place during a given time

  • suspicious email/software flagged by firewall
  • Positive or negative

• Incident: An event that has a negative outcome

  • Affects CIA
  • May or may not be malicious or deliberate
  • e.g., malware infects a server, encrypting critical business files.

Incident types

• Phishing: Deceptive attempts to steal sensitive information.
• Ransomware: Malware that locks data and demands a ransom.
• Insider Threats: Malicious or careless actions from within the organisation.
• Zero-Day Exploit: Attacks on unknown vulnerabilities before they're patched.
• Social Engineering (Next'Week): Manipulating people to disclose confidential info.

What's incident response (IR)?

• A process to prepare for and handle cybersecurity incidents
• Involves managing the consequences and fallout of incidents effectively.

Goals of an IR Program

1. Minimise Impact: Reduce damage to systems, data, and operations.
2. Efficient Recovery: Shorten recovery time and control costs.
3. Protect Reputation: Limit collateral damage to the organisation’s brand and trust.

Incident Response: Actions Depend on Key Factors

Reporting Requirement
-

1, 2, 3, 4, 5

Importance of an IR Plan

• Defines what constitutes an "incident" for the organisation.
• Provides clear, guided procedures for responding to incidents.
• Prepares organisations for Operational Technology (OT) and cybersecurity challenges.

Incident Response Processes

There are two distinct aspects to incident response:

1. Incident response preparation
2. Incident response handling

1. Incident response preparation:

• Occurs periodically, without any identified incident.
• Focus: Prepare teams to handle incidents efficiently and effectively.
  

1. Incident response preparation: Cont'

• Inputs:
  • OT security policies, processes, and procedures.
  • Asset inventory.
  • Completed incident response forms.
• Outputs:
  • Updated IR policy, processes, and procedures.
  • Recommendations summary document.

2. Incident Handling

• Provide a framework for systematic and efficient incident response.

• Minimise chaos by predefining roles and responsibilities.

• Inputs:

  • Blank incident response form, pre-prepared team, etc.

• Outputs:

  • Completed incident response form.
  • Restored system operations.
  • Communicated closed status.

Ideal Model

Incident response procedures: SANS

Others models:

1. Incident Response process

3. ISO/IEC Incident Response Standard: Not incident response model, but it includes guidance on incident management

1, 2, 3

SANS: Step 1 - Preparation

Objective:

• Ensure the organisation is ready to handle incidents effectively.

Key Actions:

1. Develop and maintain incident response policies and procedures.
2. Assemble and train the incident response team.
3. Gather tools and resources, such as monitoring systems and forensics tools.
4. Conduct regular incident response drills.

SANS: Step 2 - Identification

Objective:

• Detect and confirm the occurrence of an incident.

Key Actions:

1. Monitor systems for anomalies and suspicious activities.
2. Analyse logs, alerts, and other data sources.
3. Classify incidents based on type and severity.
4. Notify the incident response team of confirmed incidents.

SANS: Step 3 - Containment

Objective:

• Prevent further damage and limit the impact of the incident.

Key Actions:

1. Implement short-term containment measures (e.g., isolating affected systems).
2. Develop long-term containment strategies for ongoing incidents.
3. Preserve evidence for forensic analysis.

Goal:

• Stabilise the environment while maintaining the integrity of evidence.

SANS: Step 4 - Eradication

Objective:

• Eliminate the cause of the incident.

Key Actions:

1. Identify and remove malware, unauthorised access, or compromised accounts.
2. Patch vulnerabilities exploited during the incident.
3. Conduct thorough scans(e.g., pentest)to ensure the threat has been eradicated.

SANS: Step 5 - Recovery

Objective:

• Restore systems and operations to normal.

Key Actions:

1. Rebuild or restore affected systems from backups.
2. Verify systems are secure and fully operational.
3. Monitor for lingering threats or vulnerabilities.

Goal:

• Safely return to normal business operations.

SANS: Step 6 - Lessons Learned

Objective:

• Analyse the incident to improve future responses.

Key Actions:

1. Conduct a post-incident review with all stakeholders.
2. Identify gaps in the incident response process.
3. Update policies, procedures, and training based on findings.

Outcome:

• Build a more resilient incident response program.

Incident report form

You can download from here

Red, Blue, and Purple Teaming in Incident Response

• In cybersecurity, effective incident response requires a holistic approach that combines both offensive and defensive tactics.

• Red, Blue, and Purple Teaming are essential components in testing, defending, and enhancing an organisation's security posture.

1. Red Teaming

The Red Team acts as an adversary, simulating real-world cyberattacks to identify vulnerabilities in an organisation's security infrastructure.

1. Test vulnerabilities by simulating advanced persistent threats (APTs) or common attack vectors (e.g., phishing, exploitation).
2. Evaluate detection and response capabilities of the Blue Team during and after an attack.

How Red Teaming Supports Incident Response:

• Identifies weaknesses that could lead to security incidents.
• Improves the detection process by testing Blue Team’s ability to spot threats in real-time.
• Simulates actual cyberattacks to validate incident response plans.

2. Blue Teaming in Incident Response

The Blue Team is responsible for defending the organisation against cyberattacks, detecting intrusions, and ensuring a quick recovery from security incidents.

Goals:

1. Monitor systems for suspicious activities and anomalies.
2. Respond to and mitigate attacks to minimise damage and data loss.

How Blue Teaming Supports Incident Response:

• Ensures immediate containment and response during an incident.
• Protects critical assets and mitigates the effects of an ongoing attack.
• Tests response procedures through simulations and real-world attacks.

3. Purple Teaming in Incident Response

The Purple Team is a collaborative team that integrates Red and Blue Teams, enabling them to work together to enhance incident response capabilities.

Goals:

1. Facilitate collaboration between Red and Blue Teams.
2. Ensure that offensive tactics (Red Team) align with defensive strategies (Blue Team) to improve detection and response times.

How Purple Teaming Supports Incident Response:

• Shares knowledge between teams to identify attack patterns and improve defences.
• Helps the Blue Team better understand offensive tactics and improves their ability to detect real-world threats.
• Uses feedback loops from both Red and Blue Teams to develop more effective incident response plans.

Why we need to have them:

• Combining these teams enhances an organisation's ability to respond effectively to real-world cyber incidents.
• Regular simulations and collaboration ensure that both detection and response capabilities are constantly evolving.

Next Semester Modules in relation to IR

Security Testing - Liam

Digital Forensics - Ali

In-class Test in January

• The test will cover the weeks not included in Assessment 1:

  • Week 1, Week 2, Week 5, Week 7, Week 10, Week 11, and Week 12.
  • The test will include multiple choice questions, short reflections, and a small number of practical tasks.
  • Duration: 1 to 1.5 hours (to be confirmed).
  • Date: 15 January.

• Please monitor your email for the official announcement.

• This is a one-off exam with no extensions permitted. Non-attendance will result in no mark, and you will need to wait for the summer resit period to retake it.

Activities/Lab

• See you activities for IR from here