The first thing an IT security executive should do after the corporate network has been breached is fall back on the incident response plan that was put in place well before attackers got through the carefully constructed defenses.
That's what should have happened, but even if it wasn't there are certain steps that anyone running an incident response team should follow in order to accomplish the main goal of any such cleanup: getting the network back to supporting business as usual as quickly as possible.
There are seven key things breach-repair leaders should do, according to Wade Woolwine, the manager of strategic services for Rapid7, who outlined the steps last week at his company's United customer conference. "It's all about recovering the business back to normal operations," Woolwine says.
Here are the seven steps:
Each incident may call for a different set of players. For example, if the first notification of a breach comes from the FBI calling to say it's found out the corporate network was breached, one of the first people to call is the company legal officer.
Or if the breach involves loss of critical corporate data the trade secrets that represent the value of the company the executive board has to be called in. In the case of personally identifiable customer information being compromised, compliance teams need to be tapped to coordinate notification of those affected in accordance with laws and regulations.
This is a changing cast of characters based on the circumstances of each breach.
The critical time in any breach investigation is the first 24 to 48 hours, and gathering hard data about what machines were breached, how they were hacked and what information might have been stolen is essential. It will determine what specific actions to take to secure the network from the immediate threat. "You will make decisions as evidence materializes," Woolwine says.
This is the time to rely on the response team, which is a different group from "the right people" mentioned above. This is the team that will respond to any incident in order to determine what happened, when and how.
During this phase it is important to communicate effectively with the team to hear what they've found out and to hear from the response leader what others know so far so they can better determine what they should do next. "Rely on your team," he says, but challenge their assumptions about what happened in order to ensure that ongoing decisions and analysis are based on fact not speculation.
This is different from the overall incident response plan referred to above that was made before the breach. This plan is specific to the current incident and lays out the details of how to respond to its particular damage.
Sign up for CIO Asia eNewsletters.