Course 3: Incident Response

Stage 2 – Identification
Incident response

1
Section 1: Incident
Identification
Course 3: Incident Response Stage 2 – Identification

2
What defines an incident?
• Event that requires a response
• Should already be defined in policy
• Usually adverse with negative impact
– The real question is, how do we identify when they happen?

3
Sources of incident notification
End users
Most common source, but not always reliable. I.e., some events are just events and not incidents

Log sources
SIEM solutions, IDS, firewalls, HIPS. Volume can be overwhelming
– Machine learning, deep learning and AI will help

• Notification from outside entities, such as law enforcement

4
Things to look out for
• Make sure the identification process is sufficient
– Too loose and everything is an incident
– Too tight and you miss critical events

5
Allow room for identifying new incidents
• Just because it’s not defined doesn’t mean it’s not an incident
• Some of the more devastating incidents are “new” ones

6
Maintain scope and focus
• Identify the incident and move on to classification
– Don’t try to do containment at this stage!

7
How incidents are detected
• Law enforcement
• Internal detection/DLP
• Third-party consultants/vendors
• Exfiltrated data disclosed (internet or dark web)
– Worst-case scenario?

8
Section 2:
IR classification levels
Course 3: Incident Response Stage 2 – Identification

9
Not all incidents are equal
• Severity
• Priority
• Organizational culture

10
Severity levels
• Often difficult to measure completely
• May be frequently adjusted and IT landscape changes (cloud, etc.)
• Must include input from upper management and other parts of the organization

11
Things to look out for
• Make sure the identification process is sufficient
– Too loose and everything is an incident
– Too tight and you miss critical events
– Things that are not identified properly are rarely classified properly

12
Allow room for identifying new incidents
• Just because it’s not defined doesn’t mean it’s not an incident
• Some of the more devastating incidents are “new” ones

13
Maintain scope and focus
• Identify the incident and move on to classification
– Don’t try to do containment at this stage!

14
United States DHS CISA

Source: www.us-cert.gov/CISA-Cyber-Incident-Scoring-System

15
Common methodology
Urgency
How quickly will the damage continue to grow while the incident is still ongoing?

Impact
How widely is the impact felt, how many users or customers are affected and what will be
the cost of the impact?

16
Common methodology
• Each urgency and impact have their own ratings, which are sometimes combined to calculate priority

IMPACT

High Medium Low

High
URGENCY
Medium
Low

17
Include other data in criteria
• Risk assessments already performed by IT risk group
• Business Impact Analysis data
• Disaster recovery
• Business continuity

18
Section 3: Communication and
notification of an incident
Course 3: Incident Response Stage 2 – Identification

19
Where are the tools?
• On the internal network
• On each endpoint (i.e., memory forensics agents)
• Internet service provider
• In the cloud
– Sometimes with your cloud service provider, e.g., Amazon, Google, Microsoft Azure, etc.

20
Things that shape communication plan for IR
• Legal requirements
• Compliance
• Media and public disclosure
• Internal communications

21
Legalities
• Regulations are different for some industry groups
• Different countries have different requirements
• Privacy may be of concern

22
Compliance
• HIPAA
• SOX — Sarbanes-Oxley
• PCI
• Others

23
Communications with media
• Should be filtered through legal team and PR team
• Who should receive reports (daily updates, etc.)?

24
Internal communications
• Who has the need to know?
• Use standard normal communications?
• Set up separate communication paths
• Dedicated internet connections
• Out-of-band file storage and digital communications between the team

25
Internal communications
• Do we continue to use internal messaging email if that system is compromised?
• If the network is compromised, does that potentially include mail servers?
– Bad guys might be monitoring our IR process!

26
Out-of-band communications
• Set up separate email and messaging and file storage system outside the network (e.g., Google,
Amazon, Azure, etc.)
• Used exclusively for these type of incidents
• Consider backup/alternate devices for connectivity to these messaging and storage systems

27
Reporting
• Reports should be treated as highly confidential, distributed as need-to-know only
• Daily status report to be shared among incident handlers
• Weekly status report for upper management at a minimum
– Sometimes management will request daily reports, usually depending on the severity of the incident

28
Section 4: Identification
tools and techniques
Course 3: Incident Response Stage 2 – Identification

29
Tool types
• Network
• Host
• Cloud
• General IT operations tools

30
Network tools
• Network IDS (NIDS)
• Network IPS
• Firewalls
• SIEM solutions
• Sniffers
• Packet brokers and aggregators

31
Host-based tools
• Host-based intrusion detection
• Host-based firewalls
• Host event logs

32
Allow room for identifying new incidents
• Just because it’s not defined doesn’t mean it’s not an incident
• Some of the more devastating incidents are “new” ones

33
Maintain scope and focus
• Identify the incident and move on to classification
– Don’t try to do containment at this stage!

34
United States DHS CISA

Source: www.us-cert.gov/CISA-Cyber-Incident-Scoring-System

35
Common methodology
Urgency
How quickly will the damage continue to grow while the incident is still ongoing?

Impact
How widespread is the impact felt, how many users or customers are affected and what will be the cost
of the impact?

36
Common methodology
• Each urgency and impact have their own ratings, which are sometimes combined to calculate priority

IMPACT

High Medium Low

High
URGENCY
Medium
Low

37
Include other data in criteria
• Risk assessments already performed by IT risk group
• Business Impact Analysis data
• Disaster recovery
• Business continuity

38