Develop two critical response protocols. The first of these is a process to assess new threats, determine the vulnerability of your environment, and then develop countermeasures to provide protection until appropriate patches can be applied. If you are vulnerable, consider the following:
- Can the attack be stopped at the perimeter? Can the protocol be disabled? Can the ports be blocked by firewalls/routers?
- If the particular service is critical and cannot be shut down, blocked, or disabled then can the service be moved to another, non-vulnerable system? This is a good argument for diversity. If possible, move from a vulnerable platform to one that is not vulnerable to Linux). True, this requires more overhead for maintenance and administration, but diversity means flexibility.
- Can the compromise be identified by monitoring traffic patterns?
- What about bandwidth utilization?
- Does the attack open up a backdoor that can readily be identified?
- Once a compromised system has been identified, what's next?
- Will you take the system offline?
- Will you cordon off that network segment to prevent the infection from spreading?
- How will you contact external support of the network is down?
- Do you have out-of-band management capabilities?
- If the infection is spread via email, can you quickly block attachments at your mail gateway?
- Will you shut down your mail gateway?
There is no single security countermeasure, or silver bullet, that can protect our networks completely. Over time the threats have grown in both number and complexity, while the timeframe for response has been shortened dramatically. Previous successful attacks have shown that even those who are well protected and have large budgets and resources can be compromised. We need to be constantly alert, tracking the latest vulnerabilities, and monitoring the health and performance of our networks. Finally, we must have a plan of action in place, with a well trained staff ready to respond at the drop of a hat.
Don't Panic... Prepare!