1 / 56

Incident Handling

Incident Handling. Considerations in Approach. Presented by Chris Budge and Nick von Dadelszen. 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

benson
Télécharger la présentation

Incident Handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  27. Preparation Lets deal with that later….

  28. Identification

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

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

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

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

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

  34. Containment

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

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

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

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

  39. Eradication

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

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

  42. Recovery

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

  44. Preparation Ostrich Risk Management

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

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

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

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

More Related