Ever wonder if your incident response plan would actually work when sh*t hits the fan? You're not alone! Smart organizations put their plans to the test, making tweaks and improvements along the way. It's like a fire drill, but for cyber attacks.
Where did this come from?
This sage advice comes straight from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix of 100+ controls here: https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4
The matrix provides a baseline of security controls tailored for cloud computing. Think of it as a checklist of best practices to keep your cloud environment locked down tight.
Who should care?
- Security managers responsible for keeping incidents under control
- IT leaders who need to keep the lights on no matter what
- Auditors checking that security plans aren't just wishful thinking
- Execs and board members who prefer not to end up in the headlines
What is the risk?
Imagine a major security incident strikes and everyone starts running around like headless chickens. Without practicing your response ahead of time:
- Containment and recovery efforts will be sloooow
- Miscommunication and confusion will reign supreme
- Key steps will be missed, making the situation even worse
- Customers, regulators, and the media will ask tough questions you can't answer
On the flip side, battle-tested plans help you spring into smooth, coordinated action to detect, respond, and recover from incidents with minimal damage. You'll sleep better at night.
What's the care factor?
For critical systems and data (which is most of them in the cloud), incident response testing should be a top priority. The reputation and survival of the entire organization may depend on it.
Even for less critical assets, it's still important to have a solid, proven plan. Winging it is not a strategy.
When is it relevant?
Incident response plans should be tested at least annually for critical operations. They should also be stress tested after:
- Major org changes (reorgs, M&A, layoffs, etc.)
- Disruptions to vendors and suppliers
- Natural disasters that could impact systems
- Security breaches or near misses that reveal gaps
Testing is less critical in very stable, lower risk environments. But be careful - change is constant in the cloud.
What are the trade offs?
Testing incident response is not free. It takes time and resources to:
- Develop realistic scenarios
- Coordinate participants
- Simulate attacks and outages
- Document and discuss results
- Implement improvements
Done right, testing causes some disruption. But it pales in comparison to the disruption of a real incident you're not prepared for. You have to invest to avoid much greater pain.
How to make it happen?
- Assign an incident response testing coordinator
- Determine frequency based on critically
- Develop a range of realistic technical and non-technical scenarios
- Write a test plan with objectives, scenarios, participants, and schedule
- Get sign off from leadership on the plan
- Schedule and conduct the test
- Have an impartial observer document the test
- Conduct a post-mortem to discuss what worked and what didn't
- Develop an action plan to implement improvements
- Update incident response plans and playbooks
- Brief management on the results and action plan
- Ensure regular re-testing to verify improvements and updates
What are some gotchas?
- Ensure key participants are available and committed (IT, security, PR, legal, etc.)
- Avoid scheduling during freezes, holidays, big deadlines
- Have an "all stop" signal in case real incidents happen during the test
- Don't cause actual damage or outages just to make the test "realistic"
- Make sure you have permission to conduct tests (yes, really)
What are the alternatives?
- Tabletop exercises where participants talk through scenarios vs actual simulation
- Spontaneous tests vs scheduled (but these are very disruptive)
- Narrowly focused tests (e.g. only the SOC's detection and analysis) vs end-to-end
- Testing selected parts of the plan vs the entire plan at once
Mix and match these options, but the closer you get to reality, the better.
Explore further
- My post on Crafting an Incident Response Plan That Actually Works (coming soon)
- CSA Cloud Controls Matrix v4.0.10: "Ensure Information Security Continuity" control (SEF-03) for business continuity testing
- NIST SP 800-61 Computer Security Incident Handling Guide: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
- FIRST's Computer Security Incident Response Team (CSIRT) Services Framework: https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1
- ENISA's Good Practice Guide on Incident Response: https://www.enisa.europa.eu/publications/incident-response
