Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Risk Factory: How to Implement an Effective Incident Response Programme


Published on

  • Be the first to comment

  • Be the first to like this

Risk Factory: How to Implement an Effective Incident Response Programme

  1. 1. Effective Incident
  2. 2. A simple, easy to use, online, B2B procurement portal for purchasing products and services to identify, minimise and manage the security threat to business data.
  3. 3. Overview • Who cares? • Why care? • Success definition • Policy & preparation work • Procedures & forms • Tools & training • Incident database • Reviews & measurements
  4. 4. Who Cares?• Specifically? Name these stakeholders now• Eliminate finger pointing potential after• Establish Incident Response Team – List stakeholders roles & responsibilities – Contact details – Team mission statement – Post / Publish / Preach!
  5. 5. Why Care?• Because incidents = lost cash £• Iceberg tip theory• Timely response = minimized loss• Determine exactly who, what, when, why & how• Inform other departments of findings• Prevention & preparation for future• Mitigate risk & liability• Apprehend & prosecute
  6. 6. Define SuccessLimit damage caused by incidentMinimize and/ or recover financial lossesMinimize downtimeTechnological recoveryMinimize image damageMinimize personal lossesEnable resolution of incidentExpunge virus/intruderImprove securityDisciplinary action (solid evidence is key)Prosecution
  7. 7. Response TeamRequire wide range of technical skillsDedicated response staffTeam makeup = skilled in applicable technologyAd hoc team of existing sys adminsMultisite teams?Additional duties = additional pay…
  8. 8. Policy & PreparationPolicy: “What do you do”?Definition = critical.Must be comprehensiveDefine do’s and don’tDeviations are incidentsDefine level of incidentsDefine incident responseKeep it simpleWrite it downManagement sign off
  9. 9. Ramifications of GoingSoloIf you don’t define an incident = it never happensInsufficient skills = FailureInsufficient staff = FailureInsufficient tools = FailureInsufficient prep = FailureScapegoat….
  10. 10. Elements a Plan • Incident definition (Major vs. Minor) • Outline response for each type of incident • Reporting Process (Response Team Notification) • Containment Process • Eradication Process • Restoration • Follow-up Process • Reporting
  11. 11. Preparation:Do you know where your data is?WorkstationsServers (e-mail, databases)Log files (there are many of them)Network traffic (be careful about privacy)Backups (can you find what you need?)Are you prepared to preserve evidence?Hard drives, software, spare hardware
  12. 12. Incident Response Process• Initial observation, report, or question• Assessment of severity and worth• Physical assessment• Preserve data on target systems• Network assessment• Preserve related evidence on network• Develop response/investigative strategy• Crime analysis• Conclusions and reports
  13. 13. Procedures and FormsIncident numbering systemCERT# 2003032201Communication procedureWho to notify under what circumstancesEncrypted e-mail versus phone/pagerProcedures for each incident typeVirus, DoS, intrusion, telephone systemSexual harassment, threatsForms to ensure consistencyDocument incident detailsEvidence collection and documentation
  14. 14. Procedures: EvidenceDo you have authorization?Employee consentSearch warrantInvolve human resources & attorneysAdmissibilityDocument all actions (chain of custody)Evidence originated from its purported sourceEvidence was not altered during/after collectionAssociated information is accurate (e.g. dates)To shutdown or not to shutdown?
  15. 15. Sample Procedure OutlineWhen incident initially reported: Remote information gathering Preserve evidence on networkCollecting volatile data Step by step with tools and examplesImage hard drives Step by step with tools and examplesRestore and secure systems Backup data, reformat drive, rebuild, etc.Communicate to community
  16. 16. Documentation: FormsExpense and time logs:dates and times working on incidents, including time to recover systems, helps calculate cost of damageIncident response actions taken and when: telephone conversations helps explain incident response years laterEmployees questioned and involved: everyone involved may be required to testifyEvidence inventory: helps locate evidence later
  17. 17. Forms: Evidence Collection• Memory aide, not just extra paperwork• Incident number (#2003032201)• Authorization• Who collected evidence & when• Where the evidence was located• Details of computer systems involved• How the evidence was collected• File names, sizes, hash values• Additional notes
  18. 18. TrainingUnderstand the technology • Hardware components • System operation and security • Network trafficTrain personal in evidence handling • Do you really care about this?Train personnel to use tools • Media analysis • Log analysis • Network exploration (nmap, Nessus, scripts) • Traffic analysis
  19. 19. Response & Measurement• Deploy incident response team (procedures!)• Decide whether or not to collect volatile data• Take systems offline for forensic analysis• Probe and monitor network• Interview individuals• Document everything• Correlate data from multiple sources• Communicate with legal counsel and police
  20. 20. 26 Dover Street London United Kingdom +44 (0)20 3170 8955+44 (0)20 3008 6011 (fax)