The first step in incident response: Prepare 1 June 2012 – BSides Detroit James Foster

The first step in incident response: Prepare

http://xkcd.com

1 June 2012 – BSides DetroitJames Foster

Intended audience

Non-security IT folks IT security folks who are busy with other things

IR plan?Tomorrow...

Why this presentation?

A typical incident finds the victim ill prepared I want to help you help your incident responders

(in-house or outsiders)

Who am I?

James (Jim) Foster Based in the Detroit area Part of CDW Advanced Technology Services -

Security Assessment team

Disclaimer: These words are mine, not sanctioned or vetted by my employer or anyone else. I represent only myself here today. Also, I could be wrong about everything.

Who am I?

I do: Security assessments / penetration tests Incident response Whatever other security related stuff comes up

I have: ~17 years of experience in various IT roles; the last

~8 in IT security, doing lots of different stuff BSCS, CISSP, GCIH

A warning about me

I prefer looking at an incident from the network rather than from the compromised host itself

Compromised hosts lie Taking / inspecting people's computers freaks

them out In a business, many hosts might be involved

Which ones? Traditional forensics can be icky

Who cares?

When an incident happens: You $ Your boss $$ Your boss's boss (etc.) $$$

Efficiently proving that an event is NOT an incident is just as important as proving that an event is an incident

Show of hands

And now, the stuff

Logs

Logs – common problems

Logging not turned on Logging broke, and nobody noticed

Logs are being sent to a server that's been turned off for 6 months

Logs do not contain sufficient detail to be useful

Logs – more common problems

Logs don't go back far enough Absent other requirements, shoot for 90 days

Logs – more common problems

Logs are turned into useless pie charts Dashboards are pretty, but they aren't logs

Logs != 10.1.1.1

10.2.2.2

10.3.3.3

10.4.4.4

Logs – more common problems

Nobody knows how to access or interpret the logs they have

Logs overwhelm the tools Logs in unusable formats Don't forget about source NAT or load

balancers!

Logs – what to log

Firewall SMTP Security devices (IPS, DLP, AV, HTTP filter) AD/Windows (servers and clients) Web servers Network infrastructure

Logs – what to log

Applications DNS DHCP MOAR LOGS!

The holy grail

Wouldn't it be nice to just log all conversations on your network?

Crazy?

Netflow!

(IPFIX, Jflow, etc.)

Enough about logs already!

Time sync What time zone is it?

Legalities (IANAL)

Authority to monitor Authority to ask questions of users Authority to inspect or seize Have an AUP!

Michigan PI Law

DENIEDDENIEDAPPROVEDAPPROVED

Michigan PI Law

Starting in 2008 in Michigan, a Professional Investigator (PI) license is required to perform “...computer forensics to be used as evidence before a court, board, officer or investigating committee...”

“"Computer forensics" means the collection, investigation, analysis, and scientific examination of data held on, or retrieved from, computers, computer networks, computer storage media, electronic devices, electronic storage media, or electronic networks, or any combination thereof.”

http://www.michigan.gov/lara/0,4601,7-154-35299_61343_35414_60647_35469---,00.html

http://www.legislature.mi.gov/%28S%28yq3rz145rpg4ut45rav3zsj4%29%29/mileg.aspx?page=GetObject&objectname=mcl-act-285-of-1965

https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-moulton-2.pdf

http://www.youtube.com/watch?v=-WEKAqI4O50

Michigan PI Law

Many exemptions, including: Employees doing internal-only work

“A person employed exclusively and regularly by an employer in connection with the affairs of the employer only, if there exists a bona fide employer-employee relationship for which the employee is reimbursed on a salary basis.”

Law enforcement, attorneys, CPAs, etc.

IR policy / process

Who makes what decisions Who needs to be involved When and how to involve law enforcement What scenarios have legal implications /

requirements

BREACH!

Documentation

Current documentation (network diagrams, system profiles, configs, etc.)

Reasonable inventory of systems (how many and where are they?)

Credentials are important Assume at least one key IT person will be

unavailable when your incident happens

Documentation

External contact lists (service providers, etc.) Internal contact lists (various IT groups, legal,

HR, PR, corporate security, etc.) Contacts at remote sites for hands-on

Sufficient DHCP pools

Subnets with enough addresses Longer lease times

Practice!

User reports to the helpdesk that over the last few days, some of their email is showing up as read before they've actually read it

Practice!

User suspects their PC was being remote controlled because they saw their mouse moving around and clicking things on its own

Practice!

User reports random-ish words are being typed into whatever application they are in

OMG!I been hax0r3d!

IR advice

Have someone in charge Don't freak out

Don't let your management freak out Don't go too fast Be flexible Small cache of hardware Prefer simple answers over complicated Prefer mistakes over malice

The End