In many cases, organisations determine their course of action prior to an attack. But in an equal number of cases, organisations must make this their first order of business after an attack. In addition to determining your specific goals after an attack, you should consider executing a disaster recovery plan, if one exists for your organisation. Depending on the severity of the situation, it may make sense to treat the situation as if the data centre had been destroyed. The one unique complication to activating a disaster recovery plan for an organisation is that it is typically centred on a known event with a known time. But with an intrusion into your network, you may not know exactly when the system was first compromised. This can complicate the recovery process because it may not be clear what set of backups should be restored for each system. Further complicating matters is the fact that some systems may have been compromised before others, so it may be necessary to repeat the restoration process several times while trying to determine when the first intrusion occurred and on which system. Communicate
Once you have decided on your approach, you need to communicate to upper management what is happening -- or what you suspect is happening. This is perhaps the most difficult step and, because of that, it is one that is often skipped or delayed. But despite the potential for internal political problems, it is important to let business leadership understand what is happening so that everyone can plan for the steps required to resolve the problem. It will also give business leadership an opportunity to reaffirm the goal for problem resolution, whether that goal is to go after the intruder, target the vulnerability, or simply solve the problem as quickly as possible. You should also communicate with your IT peers about the problem. You need everyone on the team to look for suspicious activity to ensure that the network is not further compromised. To that end, the more professionals involved who are aware of the problem, the more likely it is that nothing will slip through the cracks and be missed. Conversely, you should not communicate with your users that you have detected an intrusion. An employee may have caused the breach, either by providing a password to a friend with the intention of allowing a breach or through something more innocent. It is a good idea to hold off on notifying employees until the HR department can communicate the company policy along with the message. Finally, if you have a security infrastructure partner, communicate with it immediately that you have a potential situation. Even if you have only engaged the organisation in the past to perform a security audit, you should call it to indicate that you suspect that you have a problem. The intent here is not at this point to ask for help but rather to inform the partner so that it can be prepared to assist if necessary. Disconnect
If you are not planning on attempting to identify the intruder or the vulnerability, you should disconnect the system or the entire internal network from the Internet as soon as possible. This prevents the intruder from working against you as you try to clean up the mess and also prevents further infections or data loss while you work on the systems. One of the downsides of disconnecting is that people who want to use the system internally and externally will be unable to do so until the problem is resolved. This can exert substantial internal pressure to take shortcuts to get the systems back up again. But the natural desire to reconnect systems before a thorough evaluation of their status has been conducted is ill advised and typically leads to repeated intrusions while the problems with each of the servers are identified and resolved one-by-one. The decision to disconnect the entire organisation from the Internet or to disconnect just one system or a few systems is a difficult call, particularly in the first five minutes. You will not have had time to evaluate which, if any, other systems have been compromised, so it is possible that removing a single system from the Internet may not resolve the problem. On the other hand, you may want the organisation to continue to function with as little disruption as possible. Ultimately, the decision comes down to one of risk tolerance. How much risk is the organisation willing to accept to avoid some downtime? In most organisations, the risk of potential intruders greatly outweighs the desire to maintain availability of all systems. In other words, most organisations agree that it is important to disconnect from the Internet immediately so that the systems can be checked for signs of intrusion without the possibility of intruders attempting to cover their tracks. Conclusion
The first few minutes after you discover an attack are likely to be stressful and confused, so it's important to have a plan of action in place before it happens. When you realise you've been attacked, make sure you identify your objectives in resolving the situation, communicate the situation promptly to business leadership and peers, and determine whether the problem requires you to disconnect one or more systems from the Internet. Deciding how to react to an attack is tricky, at best. The actions you take (or don't take) can have a huge impact on your organisation -- and on your reputation. However, following a plan for controlling the situation can make things less chaotic and start you down the right path to get things back on track.
More enterprise IT news in ZDNet UK's Tech Update Channel.
For a weekly round-up of the enterprise IT news, sign up for the Tech Update newsletter. Let the editors know what you think in the Mailroom.
