Just as no two security incidents are identical, no two incident responses are identical – even if the same malware causes both events. That is because security incidents might start out from a basic attack but once inside the corporate network, they move laterally and vertically through the network using the path of least resistance based on the compromised credentials.
That said, there are industry best practices of actions you must take in order to prepare for a breach, identify the path it has taken through the network, then contain and mitigate the damage and test the network to ensure the breach has been secured.
Planning for the Inevitable
One of the CISO’s useful tools in minimizing the impact against the unavoidable breach is a written and tested incident response plan. It might sound obvious but sadly, too many companies take the first step of writing a plan but then fail to test it. Without going through the testing stage, one can easily overlook basic protections, such as having a list of first responders with up-to-date contact information or lists of exactly where critical resources and data are located.
The plan should be regularly improved based on the current threat landscape. The development and testing of the incident response plan should be a collaborative effort within the IT team, human resources, legal, public relation, risk, compliance and security team, and outside trusted advisors who can assist in responding and investigating the breach. Once you know who will be part of the plan, each member can then create a list of actions they will take once a breach is identified.
The plan also should outline when law enforcement is called, who makes that call, and who will be the central point of contact and key stakeholder for all crucial decisions. A key stakeholder is a person who understands the legal, business operations, and data security ramifications of their decisions and often seeks advice from the incident commander or breach coach.
Testing the Plan
Once a plan is developed, it must be tested. Testing should be a realistic exercise and must be done at least annually, as well as if there are any major changes in the network architecture or organization, like business acquisitions.
Next week we’ll look at what you should do and what not to do when a breach is identified.