The Seven Deadly Sins of Incident Response

© 2015 Lancope, Inc. All rights reserved.

The Seven Deadly Sins of Incident Response

Brandon TanseySecurity Researcher

Javvad MalikSenior Analyst, Enterprise Security Practice

© 2015 Lancope, Inc. All rights reserved. 2

The origin of [incident response] sin…

© 2015 Lancope, Inc. All rights reserved. © 2015 Lancope, Inc. All rights reserved.

1. Not understanding your environment due to a lack of visibility

3




Developer PCs

Other PCs

Domain Controllers

DNS Servers

Mail Servers

Code Repositories

FTP Servers

Web Servers

Internet Hosts

Developer PCs

Other PCs

Domain Controllers

DNS Servers

Mail Servers

Code Repositories

FTP Servers

Web Servers

Internet Hosts


Developer PCs

Other PCs

Domain Controllers

DNS Servers

Mail Servers

Code Repositories

FTP Servers

Web Servers

Internet Hosts

Developer PCs

Other PCs

Domain Controllers

DNS Servers

Mail Servers

Code Repositories

FTP Servers

Web Servers

Internet Hosts


Developer PCs

Other PCs

Domain Controllers

DNS Servers

Mail Servers

Code Repositories

FTP Servers

Web Servers

Internet Hosts

Developer PCs

Other PCs

Domain Controllers

DNS Servers

Mail Servers

Code Repositories

FTP Servers

Web Servers

Internet Hosts


Network

Services

Hosts


Regardless of the type of information…

• Are you just logging information or are you also collecting it?

• Are you saving only ‘special’ log lines, or everything?

• Do you have a standard retention period in policy?• Does the budget control the period, or the period the budget?

• If you have end-user managed hosts, are they subject to the same logging policies?

10



• 2. Not having the right staff

12


12%

16%

44%

23%

5%

0% 10% 20% 30% 40% 50%

None

One

2 to 5

6 to 10

More than 10

Number of team members in

CSIRT

45%

28%

14%

11%

2%

0% 10% 20% 30% 40% 50%

None

One

2 to 5

6 to 10

More than 10

Number of team members

fully dedicated to CSIRT

Or any staff…

Source: Lancope / Ponemon Institute Source: Lancope / Ponemon Institute


Collection

Analysis

Action / Realizing Value


Not having the right staff

• Technical skills

• Knowledge transfer

• Appropriate to type of company

15


79%

14%

10%

36%

45%

47%

43%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

IT Management

Executive Management

Board of Directors

Risk management

Legal

Compliance

HR

What functions or departments are

involved in the incident response

process?

Source: Lancope / Ponemon Institute


3. Lack of budget(a.k.a. Not being able to speak the

language of the business)

17


Lack of budget

• Communicating technical issues in technical terms to the business

• Not helping to sell more ‘widgets’

• Ineffective allocation of budget

18

Source: 451 Research


Source: 451 Research


How much of your security budget goes towards an incident response program?

20

50%

31%

11%

5% 2% 1%

Less than 10% 10% to 20% 21% to 30% 31% to 40% 41% to 50% More than 50%



46%

50%

4%

Yes No Unsure

Does your organization have meaningful operational metrics to measure the overall effectiveness of incident response activities?

42%

55%

3%

Yes No Unsure

Does your organization have meaningful operational metrics to measure the speed at which incidents are being detected and contained?

Source: Lancope / Ponemon InstituteSource: Lancope / Ponemon Institute


91%

64%

51%

50%

49%

24%

20%

12%

0% 20% 40% 60% 80% 100%

IT Management

Compliance / Audit

Legal

HR

Risk Management

Broadly throughout org.

Executive Management

Board of Directors

Frequency of cyber threat briefings to

various functions within the organization(Very frequently and frequently responses combined)



4. Becoming a headless

chicken when IT hits the fan

(a.k.a. not having a plan)

23


Becoming a headless chicken when IT hits the fan

• Undefined roles and reporting lines

• Knee-jerk reactions and decisions

• Lack of change management

24


Vince Lombardi, sort of

“When you get into [an incident investigation], act like you've been

there before.”

25


Things to ask ahead of time

• Who can approve what actions?• Does the type of incident affect the answer?

• If an appropriate person cannot be reached, can the incident responder act on their own after a given amount of time?

(and get in writing)

26



• What are end-users’ responsibilities in the incident response process?• Are they required to turn over machines to the CSIRT?

• In the event of a compromise resulting in a wipe, do users get access to their files? Which ones?

• What happens when a user needs something that the CSIRT has blocked?

• Who handles exceptions?


27



• What are your external (legal, compliance, contractual) obligations?• At what point has there been a “breach”?

• Is this the point when other teams (legal, etc) are notified?

• If any, what are your external notification requirements?


28



• Can your CSIRT participate in information and indicator sharing groups?

• Can your CSIRT run malware live on the internet?• What are safe handling requirements?

• Can your CSIRT interact with malicious hosts for the purpose of intelligence gathering?• From the corporate LAN? An unattributed network?


29


5. Using generic response processes

that aren’t specific to your organization

30


Using generic response processes that aren’t specific to your organization

• ‘Monkeys in a cage’ mentality

• Not tailoring processes to your company

• Lack of risk assessment and measurement

31


Note: All of the ‘questions’ in the last section

were just that, questions.


You need to know (or figure out) what is best for

your own organization, and that’s not just a

technical decision.


Should your CSIRT make decisions or

recommendations?


6. Improper threat modelling

(a.k.a missing the big picture)

35


Improper threat modelling

• Missing the big picture

• Emotion-based decisions making

• Defending against all possible threats all the time

36



The safest network is one with nothing

connected. Go ahead and make that your

policy.*

* Don’t do this.


7. Not considering your environment and

capabilities when tuning devices

39


Not considering your environment and capabilities when tuning devices

• Unable to separate the news from the noise

• Settings defaults and forgetting

• Monitoring quality of alerts vs. counting stats

• Shelfware

40



Things to ask think about when tuning

• Tuning is an iterative process

Dealing with quantity and sensitivity

42




• What type of setup are you working to?• A bat-signal to summon the part-time CSIRT employee?

• A set of ‘suspicious’ things for analysts to investigate?


43






• Using detection tools to supplement your knowledge• Context

• Someone on the Internet port scans hosts in your DMZ? Meh.

• A host on your LAN begins scanning internal ranges? Hrm…


44






• Using detection tools to supplement your knowledge• Context

• Someone on the Internet port scans hosts in your DMZ? Meh.

• A host on your LAN begins scanning internal ranges? Hrm…

• Familiarize yourself with the rules/events/alarms you turn on• The best rule/event/alarm is one that you wrote yourself

• Know how it works, when it doesn’t, what it means, and what to do…

• Learn which events are your ‘money’ events, figure out why the others aren’t in that bucket


45


Recap!

• 1. Not understanding your environment due to a lack of visibility


• 3. Lack of budget

• 4. Becoming a headless chicken when IT hits the fan

• 5. Using generic response processes that aren’t specific to your organization

• 6. Improper threat modelling

• 7. Not considering your environment and capabilities when tuning devices

46

© 2015 Lancope, Inc. All rights reserved. © 2015 Lancope, Inc. All rights reserved. 47

8. Not taking advantage of the fruits of an incident

investigation


80%

76%

67%

65%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

NetFlow / Pcap

SIEM

IDS / IPS

Threat Feeds

What type of tools are most effective in

helping to detect breaches?



43%

54%

3%

0% 10% 20% 30% 40% 50% 60%

Yes

No

Unsure

Do your organization's incident

investigations result in threat indicators

which are used to defend the

organization from future attacks?



Recap!

• 1. Not understanding your environment due to a lack of visibility


• 3. Lack of budget

• 4. Becoming a headless chicken when IT hits the fan

• 5. Using generic response processes that aren’t specific to your organization

• 6. Improper threat modelling

• 7. Not considering your environment and capabilities when tuning devices

• 8. Not taking advantage of the fruits of an incident investigation

50


Thank you!

51

@Lancope

https://www.facebook.com/Lancope

http://www.linkedin.com/groups/NetFlow-Ninjas-2261596/about

https://plus.google.com/u/0/103996520487697388791/posts

http://feeds.feedblitz.com/netflowninjas

https://www.facebook.com/Lancope

http://www.linkedin.com/groups/NetFlow-Ninjas-2261596/about

https://plus.google.com/u/0/103996520487697388791/posts

http://feeds.feedblitz.com/netflowninjas

Date post:	17-Jul-2015
Category:	Technology
Upload:	lancope-inc
View:	188 times
Download:	1 times

The Seven Deadly Sins of Incident Response

Technology