Drop, Stop and Roll: An Introduction to Computer Security Incident Response
•
0 likes•657 views
An introduction to computer security incident response and the incident response guideline in Minnesota State Colleges & Universities
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Drop, Stop and Roll: An Introduction to Computer Security Incident Response
Similar to Drop, Stop and Roll: An Introduction to Computer Security Incident Response (20)
Recently uploaded
Recently uploaded (20)
Drop, Stop and Roll: An Introduction to Computer Security Incident Response
- 1. Drop, Stop and Roll John Hoffoss and Scott St. Aubin Access more information security training for campus technical staff and earn CEUs: its.mnscu.edu/security/training/
- 2. An introduction to the Computer Security Incident Response System Guideline
- 3. Outline • Step Zero: Plan Your Escape Route • Smell Smoke? Detecting an Incident • Drop! • Stop! • Roll!
- 4. What is an incident? • A situation that presents a significant or imminent threat to the security of IT resources or data. • Unauthorized access or compromise of data or systems with perceived malicious intent • A significant threat or actual loss of nonpublic data via IT resources • A reasonable basis to believe that IT resources are being used for criminal activity
- 5. flickr//d-workx Before the Fire: Plan Your Escape Route
- 6. What is incident response? • Your set of [hopefully calm] actions taken as response to an incident. • heart-valve-surgery.com icanhascheezburger
- 7. About the Route Incident response is easier and goes better if you have a plan in place before you need it. • Management Support • Your incident response plan, tested! • Tools: hard drives, write blockers, analysis environment • Knowledge to perform this analysis
- 8. What goes in a plan? Good question...we made a guideline to answer that! (You can thank us later...)
- 9. The Guideline The Computer Security Incident Response System Guideline: • requires that you have a plan; • outlines the response process; • outlines the composition of your CSIRT; • requires that you test your plan.
- 10. mmm...phases 1. Detection and Reporting 2. Initial Classification and Notification 3. Containment 4. Eradication 5. Recovery 6. Closure
- 11. The Team
- 12. Anything else? • Your plan should tie in with other relevant processes • Continuity of Operations • Disaster Recovery • Breach Notification • Your plan must be tested! • Data gathered as part of incident response is nonpublic -- label it as such!
- 13. So I have write all that stuff? Are you joking? • You can if you want... • Some of you may have a plan already--it may only require tweaking to satisfy these. • But we have a template you can use! • www.its.mnscu.edu/security
- 14. Oooh, template! • Scott wrote all of it with my input. • Mostly-ready, but you’ll want to tweak a few areas: • Team Info - Table 1 • Constituencies - Table 3 • Reporting Process - Figure 2
- 15. Smell Smoke? Detecting an Incident flickr//lilcrabbygal
- 16. • errant mouse movement • missing system settings // system not in state an Detection employee left it // missing icons/folders/ programs • extreme performance issues
- 17. Now get out your log book Take notes! eaas.co.uk
- 18. Reporting • Houston, we have a problem. • Your users should know who to contact • Calling is always better than email
- 19. Classification & Notification • Yep, that computer is on fire. • Contact your response team
- 21. Containment • Actually unplug or cut the network cable • Mark the system as "borked - do not use" • Do not use or interact with the system yet • Log your actions in your logbook.
- 22. • Interview the user about what he/she saw. What data is stored or accessed from the suspect system? Is there nonpublic data stored? Online banking activity? • Confirm any new information pertaining to the incident with IDS, Firewall, AD logs, etc. • Log your actions in your logbook. • Sanity check: Do you think there's a fire? Or is it just smoke?
- 23. If you're certain there is no sensitive activity or data that could've been compromised, then move on to the eradication step. Log your actions in your logbook.
- 24. If you're not certain, or if you know there is sensitive activity or data, use your incident response tools to create an image of the system's memory in a forensically sound manner. Now pull the power plug (do not use the power button or hit Start->Shut Down).
- 25. • Depending on your classification, create two forensic copies of the suspect hard drive: • One to place back into the workstation (if necessary) for investigation or emergency return to operations • One to retain as an investigative copy of the original • Retain the original with that copy. • Chain of Custody
- 26. flickr//jeshuanace Stop!
- 27. Eradication Log your actions in your logbook. Keep the system air-gapped and off any network. Now you can interact with the system to see if there is persistent malware present (e.g. Mebroot, a boot-sector trojan) Log your actions in your logbook.
- 28. Analysis Tools • Sysinternals - netmon, • VirusTotal procmon, sysmon • Autopsy • Dumpevt • FTK • SilentRunners • EnCase • Malware Bytes Antimalware • Paraben Forensics • Antivirus software • Your Actions, Log Them.
- 29. Forensics! gizmodo
- 30. More Eradication Once you have some idea of how you got your nasty, figure out how to prevent it from returning. • User privileges • Network • Patches segmentation • Firewall and • IDS router ACLs
- 31. Roll! flickr//telstar
- 32. Recovery • Reimage • Log your actions • Restore data from known-good backups • Return to operation
- 33. Recovery Follow-up • Monitoring • Breach Notification
- 34. Closure • Schedule the Incident Recap meeting • Log your actions in your logbook. • Give the all-clear signal
- 35. Incident Follow-up • Incident Recap • Report or Brief
Editor's Notes
- John Hoffoss works in the Information Security Office, part of the Information Technology Services division of the Office of the Chancellor. He’s been with MnSCU for 3 years, likes carpentry and curls well. Scott St. Aubin is a consultant with NetSPI who has been working with MnSCU for about two years. He’s an active photographer, shoots an Olympus, and doesn’t own enough lenses.
- This talk will introduce the incident response guideline, the plan, the process, and share a war story or two.
- What is an incident? a situation that presents a significant or imminent threat to the security of system information technology resources or information resources; it includes, but is not limited to the following: •Unauthorized access or compromise of information resources or information technology resources with perceived malicious intent; •A significant threat or actual loss of not-public data via information technology resources; •A reasonable basis to believe that system information technology resources are being used for criminal activity.
- You need to be prepared. Have a process, toolbox, whatever. Running to buy a fire extinguisher while your house burns down won’t help.
- Incident response is your set of actions taken as response to an incident. You don’t want to be pulling your hair out or panicking when you discover a potential incident. Calm, cool and collected is always more effective. •Could mean you run like hell, or activate your incident response team, or pull out your response kit and start investigating on your own with the ultimate goal of returning to service-as-normal. •More often than not, it'll be a combination of the last two.
- The route: your management's support and your response team •They'll keep the heat off you while you work! Your plan, of course, distributed and tested so that your team members know what “we may have an incident” means. Your toolbox •Spare hard drive(s) larger than your most media-heavy user's drives •If you're getting too much "practice" at this, a write-blocker - Firefly, Ultrablock, or Tableau -- around $300 (for one) or $1500 (for complete Firewire/USB/SATA/PATA set) •Copy of BackTrack, Helix, or similar Knowledge and understanding of how to use these tools! - You wouldn't want to have to learn how to put on firefighter gear, learn how to drive a hook and ladder, and learn how the ladder works in the middle of a fire...
- The guideline is fairly straightforward. It lays out definitions and minimum requirements: •You must have a plan -- reasonable and appropriate methods to control and remediate information security incidents •Your response process should cover the process that we’ll go over •Your computer security incident response team should be multi-disciplinary That response process covers several phases...
- Six phases, to be exact: 1. Detection and Reporting. The method(s) of detecting and reporting an incident should be identified, as well as the path of information flows. Do your users know to call the help desk? Does your help desk know the signs of a potential incident? 2. Initial Classification and Notification. Each incident should be evaluated to ensure it is handled with the appropriate urgency, and the correct individuals are notified for the type of incident being investigated. External processes, like COOP, Breach Notification, Law Enforcement contact, etc. may be initiated when necessary. Breach notification and forensics will usually come later, though. 3. Containment. Initial steps to immediately stop the spread of the incident. This involves things like removing network connectivity from the system, creating forensically-sound copies of hard drives, performing a cursory examination of neighboring systems to identify additionally compromised systems, etc. 4. Eradication. Steps taken to remove the cause of the incident. This is where forensic analysis might be initiated, otherwise generally this is your workstation imaging process. 5. Recovery. Steps taken to return the computer systems to a full production mode. Restoring data, reconfiguring the workstation, and closing the hole that allowed the compromise in the first place. Then placing the system back in use with a period of elevated logging and monitoring to confirm the intruder is not still present. 6. Incident Closure. Complete all documentation and review the incident to determine how the systems, processes, or incident response plan could be improved to prevent recurrence in the future, or decrease recovery time. This is a lot to take on alone, which is why you have an incident response team...
- There are a lot of potential players in a CSIRT--you will hopefully never have to activate all of these groups, except for testing your plan, of course. Mostly, the team is you, your peers and your CIO. These lines don’t so much delineate control as they do communication paths. You as incident handler recommend action as it pertains to responding, but your CIO and campus leadership are the final authority--they decide if a system gets pulled, or if a system gets returned to operation, whether you think it premature or not. The ISO and OGC can help you coordinate Forensics and Law Enforcement activity.
- •Link your plan to existing processes--DR, COOP, Breach Notification--and vice versa •Your plan must be tested at least annually -- as in full-team training & exercise kind of test. 4 hours should be sufficient, and it doesn’t have to be fancy. This is as much a discussion and communication opportunity than anything else. •Data collected through this process is assumed nonpublic, classified as security data in MGDPA That, in a nutshell, is what the Guideline requires.
- This slide is fairly self-explanatory.
- •you'll need to customize your team information and introduce the plan and process to your local institution resources (Table 1) •Constituencies - Define the role and authority your institution's CSIRT will have over faculty, staff and student constituencies. (Table 3) •You'll also need to fill in details about your local process for reporting and responding to incidents, which you can model after the OOC information included in the template. (Figure 2) Enough about the guideline and template for now, let’s talk incident response in a little more depth.
- Detecting and Reporting isn’t a huge or difficult process, but it’s absolutely critical to effective incident response. •Your users are probably your first line of detection -- erratic behavior, sudden decline in performance, changed or missing icons/programs/etc, sudden decline in bank account balances, etc. Make sure your helpdesk is mindful of this. •Your IDS, firewalls, antivirus system, and other logs are additional sources for incident detection and confirmation, along with the network team, OET, REN-ISAC, law enforcement, and other randoms.
- When a suspicious event is detected or reported, get out your incident log book - paper, preferably hard-bound with numbered pages, written in ink. If it’s not numbered, number the pages by hand before you start using it. Keep this with you to document your steps through the entire response process. Never skip more than a page, and write "SKIPPED" on the skipped page. Never tear out a page of that book. Date and timestamp each page, if not each section of a page.
- So someone has detected an incident, and they want to report it. You need to make sure they know who to contact to do that! A phone call is better than an email--an intruder will have an easier time reading that user’s email than they will getting into your phone system to snoop the call. If you have an intruder and they get tipped off that they’ve been found, they’ll make a quick exit, potentially trashing your workstation. Your helpdesk should also know how to respond, asking that user to step away, come to IT to discuss what they’ve seen, something, anything, to get them away from the keyboard and preserve any evidence still left until someone can get to their workstation.
- Once you’ve received notification of a suspicious event, conduct some cursory analysis--preferably anywhere else BUT on the suspect system--to look for clues that your event should be escalated to an incident or not. This is where your plan gets activated. Your response will be different if this is inappropriate use, a virus, an insider, a drive-by browser malware issue, or an elite Russian hax0r pwning your datas. Your analysis should include examining Novell and ActiveDirectory logs, AV, firewalls & routers, and perhaps most importantly, an interview with the user reporting the event. Take notes in your log book throughout this process! You may need to recall why you decided to activate this plan two years later--I guarantee you will not remember if you don’t have it written down.
- Drop -- Initial Classification and Notification So after reporting and confirmation, you either found enough evidence that you think you have an incident, or you’re not comfortable saying you don’t have an incident. Congratulations! The first thing we need to do is drop network connectivity from a system under attack or suspected to be breached. This is like applying a tourniquet when you see blood. It may be overkill, but what if it’s necessary and you skip it?
- If this is your-institution-dot-e-d-u or some other high-impact system, you’ll need to communicate with some of your IR team members to get approval. This isn’t usually needed with workstations. So with permission attained, disconnect the network on the suspect device. And I mean really disconnect. Don’t just close a switch port--unplug or cut the cable. (The intruder may have access to your switches, too! Thankfully, most of you have fully isolated management VLANs, so this risk is much lower in MnSCU than elsewhere. Like banks or credit unions. *shudder*) Mark the system “dead” or “broken” or however you’d mark a system as not functioning so your users don’t touch. If it’s a sensitive system, do what you have to in order to guarantee the system doesn’t get modified. Log your actions!
- If you didn&#x2019;t do so already, talk with your user to learn what they did or didn&#x2019;t do, what they&#x2019;ve installed, where they were clicking, etc. It&#x2019;s worth confirming information the user gives you with log data. If they say they weren&#x2019;t on Facebook but you see in logs they were, talk to the user about it. You&#x2019;re not investigating them. (Yet.) Their cooperation and full honesty will help get their system back and running faster. Log your actions. (Is this getting repetitive yet? That&#x2019;s because none of you will want to do this in the midst of responding...) Sanity check -- you can always close out an incident early if you realize it&#x2019;s not actually an incident. <story of bank hacked by wireless mouse>
- If you&#x2019;re in doubt, continue in the containment phase to create forensically sound images of the system state and hard drive.
- Image the memory while the system is still in its current state This is not for the faint of heart, and you really, really, really need to have documented procedures and a thorough understanding of what you&#x2019;re doing.
- Create two forensic copies of the system hard disk and retain the original with one copy. Or at the very least pull the original altogether. Complete a chain of custody form for the hard disk, including information about the PC the disk came out of. If you don&#x2019;t already have procedures for this that you&#x2019;ve tested, call the ISO.
- Stop -- Eradication
- Remember, you&#x2019;re only doing this after determining there is no further need to preserve evidence due to data compromise, or you&#x2019;re working off of a copy of the original, still preserved. If you have no alternative, you can now interact with the system to continue investigating the incident. The ideal, though, is to use one of the copies you took to examine the system in a write-protected environment to investigate.
- There are many tools available to conduct this analysis. Some of these tools are expensive. You need to know what you&#x2019;re doing (perhaps some of you attended Dan Nash&#x2019;s malware investigation talk yesterday...) If you've determined what bits of malware you're dealing with, and they spread on their own, you'll want to look at other systems -- call the ISO, this is too incident-specific to give you a pithy slide (and potentially even a non-pithy slide) describing how to do this.
- Depending on what you've found, it may be time to ship your copy and your original off to a forensic specialist to continue the investigation. Some options are the state&#x2019;s enterprise security office or a third-party like NetSPI or Kroll OnTrack. Leave the forensics to the pros.
- Ideally, before moving on, you know exactly how the compromise occurred and you have taken steps to both prevent reinfection and detect a reinfection--eradicating that threat.
- Roll -- Recovery; Incident Closure; Breach notifications and other administrative follow-up
- Once you believe the incident has been contained and eradicated, and your investigation is complete, you may commence eradication with prejudice. Or just use Ghost or whatever your standard desktop imaging/deployment toolset involves. Don't ever think you can completely clean a Windows workstation. (You can, but it's prohibitively expensive.) Servers are another story, but talk to us in the ISO before you start down this path--we may still advise you to start fresh and restore data either from your copies or from data backups. You should now be ready to return the freshly reimaged suspect system back to production.
- Don't floor it -- monitoring is key at this point to ensure you eradicated the nasties. After an appropriate length of time, step down your monitoring. This completely depends on the nature of the event. Depending on the outcome of your investigation, this is where you would notify individuals of the breach of their nonpublic data, if appropriate and advised to do so by general counsel.
- At this time, once all steps and phases are complete, the incident is closed. Schedule a meeting with your incident response team and all other individuals involved--helpdesk, users, ISO, OGC, etc. to conduct a lessons-learned session.
- The incident recap exists to help you determine if there are changes that should be made to your IR process or procedures for future incidents. Should someone have been involved earlier? Should actions have been taken in a different order? etc.