Section 24 – Incident Response

Section 24 Incident Response

incident: act of violating a security policy

eg password cracking or installing malware – breaks security policy

NIST standard is commonly used: US Nat Inst of Standards and Technology

 

IR procedures for handling Incidents

many procedures

 

7 phase model is used:

preparation – strengthening systems to resist attacks

training, testing, trial exercises

detection

id’s security incidents

analysis

examination of the incident

informing stakeholders

containment

securing data and protecting biz operations

prevent malware spreading further eg disconnecting server/wkstn from network

eradication

once contained we can begin eradication

 

recovery

restoring systems to known good state – eg via backup, security backups, config updates

 

lessons learned

after all the above

how can we improve for the future

what do we need to change re our procedures

 

root cause analyss

uses a 4 stage process:

1. define cause

eg a user plugging in a usb stick

ie determine causal relationship which led to the incident

 

2. id effective solution

 

3. implement and track solution

 

4. lessons learned/ after action report

 

large orgs often have ft incident response teams, small ones form temporary teams or may be a function of the sys admin role

 

THREAT HUNTING

finding hidden threats not caught by our regular security monitoring – instead of waiting for them to appear by themselves – a more proactive approach

who might want to harm us

what might they try to do,

and how might they try to do it

that TTPs might they use

what kind of threat actor are they eg criminal, hackivist, competitor, hostile nation state, etc

analyse logs and process/file data

how does TH differ from usual security monitoring – we start with idea that our usual procedures have failed.

looks for NEW threats – undetected issue, thinks that have somehow bypassed the checks

Indicators of Comprimise IoCs

We refer to threat intel sources, eg advisories and bulletins, from vendors and security researchers

Intel Fusion and Threat Data, use SIEM platform data

eg outbound traffic – where is it going?

what progs are running on our servers?

what connections are there

 

threat hunting is costly, a lot of overhead, but can be worthwhile to improve security

integrate the TH with threat intelligence

 

 

ROOT CAUSE ANALYSIS

is a 4 stage process:

1. define scope of the incident

2. what was the initial source of the incident

3.. determine the causal relationship

which led to the incident

eg someone clicking a link in an email

4. id a solution

tell users not to click on links, antivirus scanning, email scanning

 

very important: a no-blame culture!

A NO BLAME approach can help a lot – helps with investigation and transparancy and honesty, to get the true facts.

primary purpose of root cause analysis is not to assign blame but to figure out what caused the incident, nothing more.

 

TRAINING and TESTING

differ!

training: ensure staff understand incident response tasks and procedures