The first step in incident response: Prepare

1. http://xkcd.com 1 June 2012 – BSides Detroit James Foster The first step in incident response: Prepare

2. Intended audience • Non-security IT folks • IT security folks who are busy with other things IR plan? Tomorrow...

3. Why this presentation? • A typical incident finds the victim ill prepared • I want to help you help your incident responders (in-house or outsiders)

4. 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.

5. 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

6. 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

7. 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

8. Show of hands

9. And now, the stuff

10. Logs

11. 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

12. Logs – more common problems • Logs don't go back far enough • Absent other requirements, shoot for 90 days

13. Logs – more common problems • Logs are turned into useless pie charts • Dashboards are pretty, but they aren't logs Logs !=

14. 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!

15. Logs – what to log • Firewall • SMTP • Security devices (IPS, DLP, AV, HTTP filter) • AD/Windows (servers and clients) • Web servers • Network infrastructure

16. Logs – what to log • Applications • DNS • DHCP MOAR LOGS!

17. The holy grail • Wouldn't it be nice to just log all conversations on your network? • Crazy? Netflow! (IPFIX, Jflow, etc.)

18. Enough about logs already! • Time sync • What time zone is it?

19. Legalities (IANAL) • Authority to monitor • Authority to ask questions of users • Authority to inspect or seize • Have an AUP!

20. Michigan PI Law APPROVED DENIED

21. 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

22. 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.

23. 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!

24. 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

25. 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

26. Sufficient DHCP pools • Subnets with enough addresses • Longer lease times

27. 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

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

29. Practice! • User reports random-ish words are being typed into whatever application they are in OMG! I been hax0r3d!

30. 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

31. The End