October 7, 2004
(Computerworld)
You've just learned that a new worm from a former Soviet country is spreading fast because it doesn't rely on e-mail – it automatically exploits a vulnerability in Microsoft's Internet Information Server. Now what? Do you cancel your evening plans and stay late testing patches, or can you safely ignore this worm?
Network administrators face similar questions hundreds of times each year. With your company's electronic treasures at stake, you need a consistent paradigm to help evaluate whether each new threat deserves a yawn, a fire drill or something in between.
What follows is a checklist of nine questions to help you weigh the significance of any new threat.
1. Does the new threat affect software we use? No? Then you're in the clear. But don't answer too hastily. Your policy might forbid, say, AOL Instant Messenger, but that doesn't mean it's not on your network. Read up on some of the applications that users like to sneak onto their machines – most commonly peer-to-peer file sharing, instant messaging applications, media players and IRC. Find out which port numbers they use, then check your firewall logs for outbound traffic on those ports.
Also, don't fall for this one: "If I haven't heard of it, it's probably not on my network." Read security bulletins thoroughly before deciding that the vulnerable software isn't on your network.
2. Is this exploit an insider threat or from the outside? Attackers from within are usually easier to track because they use a range of IP addresses and MAC addresses you know. Plus, insiders know they could lose their jobs for attacking you.
Attackers from outside your network have the entire Internet in which to hide, and they know you can't touch them. Therefore, threats from the outside are more worrisome than threats that can be exploited only locally. When you read about a new vulnerability, watch for red-flag terms like "executed remotely," "remote root" and "external."
The rule of thumb: If it's a threat that can be exploited externally, treat it with more urgency.
3. How difficult is this exploit? Some widely reported vulnerabilities are so tricky to exploit that they're more theoretical than real. Other attacks are as simple as logging on without entering a password.
Any additional complexity in the attack, whether on the attacker's part or the victim's, reduces the number of hackers who will try the attack and lessens the chances of it succeeding.
The most aggressive attackers are barely knowledgeable script kiddies who don't truly know programming. So the rule of thumb is, if it requires a genius (or a ton of labor) to launch the attack, chances are, it won't come your way. If executing the attack is simple, take it very seriously.
4. What is the impact of a successful attack? Suppose the attacker succeeds completely in compromising your network. What does he win? The answer tells you how urgently you should respond. The rule of thumb, in broad brush strokes:
| If a successful exploit does this: | You should generally do this: |
| Creates a denial-of-service condition (such as causing your server to hang and reboot) | Patch on your next routine maintenance cycle, as long as the server isn't mission critical and will recover on its own |
| Lets the attacker read local files | Implement the fix as soon as it is feasible |
| Enables attacker to read and modify local files | Apply countermeasures this week |
| Lets attacker write to disk and send scripted code with a reasonable chance it will execute, but he wins only local privileges | Act today |
| Lets attacker execute code of his choice, with root or system-level control | Patch immediately |
5. When was my last backup? If you know that a week of your company's work will be lost forever if an attack succeeds, take the threat more seriously than you would if you knew you had backed up your system the night before.
6. Have we prepared a response to this kind of threat? Most external attacks are variations on the same few themes. But occasionally, someone develops a new attack vector. If your policies (security, acceptable use) don't include a scripted response to this new threat, take it seriously. If it hits your company, the entire institution will be caught off guard and your response could worsen, not lessen, damage.
7. What's the state of my network today? Like that of a living organism, your network's health varies. When your network hits one of its shaky phases (servers are hanging frequently, you have unusual bandwidth demands because of a large project, or access to certain segments seems unstable), the impact of an exploit could be far worse than when the network is stable. However, that also means that patching could destabilize your environment. Approach with caution and thoughtfulness when the network turns quirky.
8. Is this threat personal? Attacks fall into one of two categories: impersonal and personal. Impersonal attacks are carried out to feed attacker vanity, to provide the attackers with extra bandwidth or processing power or to provide them with relay points to hide their identities during the real attack. Personal attacks occur because of who you are. If early reports of a threat indicate that it's attacking your sector or a related sector, treat the threat more seriously.
9. Is the cure worse than the disease? Life equals risk. Achieving 100% security is impossible. The goal is to provide security so your institution can pursue its mission. Often, common sense and bottom-line business requirements will drive your security response. For some threats, the appropriate response is to note the possibilities and stay vigilant, but do nothing. Develop your sense of proportion. The eight questions before this one – and more months of experience – will help you respond appropriately.
Mark Stevens is chief strategy officer at WatchGuard Technologies Inc., a network security company based in Seattle.