Incident Response Playbook

Back to list of all Outcomes

Original Working Session content: Incident Response Playbook


Outcomes

  • Incident response playbook

Synopsis and Takeaways

Goals

  • IR from a developer’s perspective
  • Don’t cover entire IR field, just the developer’s roles and responsibilities
  • Reinforce how other best practices, such as threat models, support the IR process

Preparation

  • Conduct fire drill – consider tabletop exercises
  • Assign points of contact (e.g., Security Champions)
  • Rapid deployment plan
  • Logging

Questions that will be asked

  • Is it our data?
  • Is it a breach?
  • What app/service provides the data?
  • Where did the data come from?
  • Can the data be time stamped?
  • What does it mean?
  • Does it have value?
  • Can we roll back to last known ‘good’ state?

Response to incident

  • Rapid deployment, owners have to know their roles
  • Communication – keep people updated with minimal publicity
  • Log what happens, and when, so people coming in as the crisis develops can be brought up to speed quickly
  • Stagger engineering team so that 24/7 coverage is possible (people need to rest, eat, etc.)
  • The benefit of a situation dealt with quickly and efficiently outweighs the cost of the remedy and the cost to the business

Post Mortem

  • Did the threat model cover this?
  • Bug Bounty the target?
  • Why did it happen?
  • How did we react?
  • Was best practice followed?
    • If not, why not?
  • Tuning web application firewalls

Lessons learnt / next steps

  • How many pre-requisites were satisfied?
  • Was Playbook appropriate?
  • Variables will cause gaps in PB
  • What adjustments need to be made?

Overall outcome

  • We feel that a Preparation Guide could satisfy needs in this area, perhaps building on Tom Brennan’s OWASP Incident Response Project

References


Back to list of all Outcomes

Edit this page here