Incident Handling

1. Incident Handling Considerations in Approach Presented by Chris Budge and Nick von Dadelszen

2. Introduction • Not legal advice • Not about computer forensic software • Is about considerations when responding to an ‘incident’ that may involve staff inappropriate computer activity, and • Is based on NZ experiences in both the Govt and private sector.

3. What We Have Seen • Staff ‘stealing’ IP (Client info etc) • Ex-Staff able to remotely connect • Overseas entry onto live systems • Automated intrusions due to AV / Pop-Up activity • Differences between desktop and laptop security (Static v Mobile)

4. What We Have Seen • IT Staff involved in incident as well as being appointed to ‘investigate’ • Badly worded policies for employee release • Incorrect terminology i.e. ‘objectionable’ (not in a legal sense) • Errors in 3rd party monitoring software

5. What We Have Seen • Considerable inappropriate material: • 25 to 38% of computers viewed held items of interest • 0.5 to 2.5% suspected ‘objectionable’ pictures • jpegs, gifs, HTML, mpg, avi etc • Excessive use of the Internet

6. Excuses / Defense # 1 It wasn’t me, never seen that ‘picture’ # 2 It was a virus # 3 It was a pop-up # 4 I left my computer on when I went to the toilet / lunch, it must have been someone else # 5 Someone else has my password

7. It Starts With Planning • Your preparedness: • Realisation it could happen • The team • Independent v Internal • The equipment • The readiness state • The ‘resource’ bin • When to call for help

8. Evidential Considerations • Review logging / reporting set ups regularly • Do not ignore potential threats as isolated incidents • Consider investigation early or at least securing of potential evidence • Never assume ‘this is going nowhere’ • Be prepared

9. Evidential Considerations • Identify and secure digital assets involved • If ‘live’ assets, secure on-line or secure off-line to removable media • Secured logs etc, if so: • Do before opening them • Make sure use original dates on CD/DVD burn • Original notes (even on a scrap of paper)

10. Digital Evidence • Is delicate. Is easily altered, damaged or destroyed by improper handling. • Any attempt to access data or run a computer program can jeopardise the integrity of the evidence. • Digital evidence, like all other evidence, must be handled carefully and in a manner that protects its evidential integrity.

11. Locating the Evidence

13. Evidential Considerations • DO NOT WRITE TO THE HDD (Exhibit) • Lots of notes • Who has access/used the computers • Confirm they (computers) are all there, if not, where are they ? • Ask about passwords, consider encryption

14. The Challenges • Investigative environment is changing rapidly • Technology poses old and new threats • Demanding stakeholders • Financial pressures • Covert activities • Privilege claims • Standards (What is inappropriate)

15. Job Difficulties • Not being told the ‘whole’ story (Trust your investigation/audit team) • Standard changes further ’up the chain’ • Disapproving Managers (After CEO direction) • IT Know-it-all’s • Financial – not all evidence reviewed

16. Forensic Case Study 1 of 4 • Civil Matter (Government) • 4 cities, total 25 locations • % of total computers, total 580 • 2 long weekends, 1 solid three week period • No offending at start, found as conducted • Media involvement-disgruntled employee

17. Forensic Case Study 2 of 4 • Civil Matter (Private) • 15 cities • Unauthorised release of information • No compulsion by visited entities • Timeframe decided by complainant • Difficult to prepare • Once entered on-site until completed • Weather and commercial activities delay

18. Forensic Case Study 3 of 4 • Civil Matters (Private/Government) • 2 entities, separate similar cases • Senior Management, Line Manager • Suspicious: activity, possible intrusion • Located by logs, not on computer • Dual logon capable, computer at home • Children (Teenagers) use • Security concerns

19. Case Study 4 of 4 • Civil Matter (Government) • 1 location, 1 user • Secure locality • External reports ‘proved’ employee • Computer, logs reviewed • Error by external entity, logs mixed • Employee proven ‘innocent’

20. Lessons Learned • Need Secure on-site work areas • Do not ‘trust’ anyone outside your team • Do not ‘believe’ all reports received • Forensic copying is better than previewing (Criminal/Employment proceedings) • Always have the ‘end state’ in mind

21. Locards Principle “For any two points of contact there is always a cross-transference of material from one to the other.” Edmond Locard 1877-1966 Every contact leaves a trace !

22. How To Survive an Incident (without losing the company or your mind)

23. Overview • What is an incident • Why it matters • The goals of incident management • The 6 steps • Preparation • Identification • Containment • Eradication • Recovery • Lessons Learned • What not to do • Conclusion

24. What is an Incident? • Computer Security Incident Response • Denial of Service • Malicious Code • Unauthorised Access • Inappropriate Use • How we get involved

25. Why You Should Care About Incidents • Because it is inevitable… • Direct financial loss • Loss of trust • Legal implications of privacy leaks • Negligence • The media cares about technology based crime • An incident is a PR nightmare

26. The Goals of Incident Management • Contain the issue • Find the extent of the issue • Find the source • Control publicity • Avoid legal implications • Prosecute • Avoid a repeat

27. Incident Response • 6 Steps • Preparation • Identification • Containment • Eradication • Recovery • Lessons Learned

28. Preparation Lets deal with that later….

29. Identification

30. Identification • How do I know I have an incident? • As a general rule, you don’t but… • Alerts from security systems • Your webpage has been redesigned by a 13 year old • “Funny” things happening on the network • Viruses from unknown sources • Strange network traffic • High volumes of network traffic • Complaints from other companies • Complaints from employees • The front page news

32. When An Incident Happens • Start logbook • Document all information to date on the event • Assign incident to a handler • Coordinate incident response team • Determine next steps • Is the incident on-going? • What is the impact on business continuity? • Is full forensic investigation required? • Is external assistance required? • What do legal/HR recommend?

33. The First 12 Hours – What to Expect • 1400 Admin can’t reboot server, strange messages • 1500 Security department contacted • 1600 Initial investigation can’t explain it, but it is highly suspicious • 1700 Security-Assessment gets a call • 1800 Arrive on site, create war room, gain understanding of situation • 1900 Live analysis of server • 1930 Start forensic imaging • 2000 Inform CIO, call emergency incident meeting • 2100 Start gathering logs

34. The First 12 Hours – What to Expect • 2200 First forensic image completes, start analysis • 2230 Initial analysis shows signs of an intruder with considerable access • 2300 Meeting to decide on action plan for next 24 hours • 0000 Seal and lock away evidence • 0030 Get some sleep… it’s going to be a long week

35. How to Handle Evidence • General Rule is • If the machine is off, leave it off • If the machine is on, leave it on, don’t reboot • Unplug the network cable • Make notes on who has accessed/used the computer • Ensure that whoever collects the data is qualified • If you want to prosecute your approach must very different.

36. Containment

37. Containment • What can be done to gain a quick understanding of the extent of the problem? • How far does the compromise go? • What devices does the compromised machine touch? • Example 1: Firewall stopped firewalling • Example 2: Hopping through the network

38. What Can I Turn Off? • Where is the “critical” data stored? Can it be secured? • Turn off the Internet • Disable services • Segregate the network • Send everyone home

39. Legal Implications • Could data concerning customers in California have been leaked? • Could customer credit card data have been involved? • Could financial records have been tampered with?

40. What is My Cover Story? • Don’t tell the world until you know what you’re dealing with • Incidents grow very fast, what seems small now could become massive. • When you start looking you will find things you didn’t expect • Example: Compromise on top of compromise

41. Eradication

42. Eradication • Perhaps the most difficult step… • Determine the Cause • Perform Vulnerability Analysis • Improve Defences • Remove the Cause

43. Eradication • Kernel level rootkits • Hardware rookits • Anti-virus is useless • You can’t ‘scan’ for an issue until you can reliably detect it • How many boxes do you rebuild from scratch? • When do you stop looking?

44. Recovery

45. Recovery • Rebuilding systems securely • Restore from backups • Validate systems • Monitoring

46. Preparation Ostrich Risk Management

47. Preparation • Incident Response Policy • Incident Response Team • Logging • Monitoring • Training • Incident response tests

48. Preparation – Incident Response Policy • An incident response policy should contain: • A list of threats the policy intends to cover • Who has authorisation for certain activities: • Conduct interviews • Review sensitive data • Conducting communications • What actions the responder is allowed to take • Taking a system offline • Denying access to intruder • Watch and monitor

49. Preparation – Incident Response Policy • An incident response policy should contain: • Who will be on the Incident Response Team • Who needs to be notified, in what manner and how often • Which is more important to the business: • System availability • Legal prosecution • Incident recovery

50. Preparation – Incident Team • Parties who may be included in the incident team: • Organisational security team • Executive management • Legal • Public relations • IS management • Human resources • CFO, financial auditor