In-Depth

Incoming Wounded

The work of risk analysis—evaluating security threats, alerts and all-out panic attacks—is vital to keeping your network safe and sound and you sane.

• By Roberta Bragg
• 09/01/2001

Like most of you, I'm not always in the office ready and waiting to respond to security threats and announced bugs. So just how do I perform triage using security reports and the background of risk analysis? Better still, what's my strategy when I'm away from those I'm charged to protect?

Like medical personnel at the site of an emergency, I'm prepared at all times to deal with incoming wounded—in my case, reports of vulnerabilities, bugs, viruses and Trojans. Like paramedics, I have a routine that allows for quick response, if necessary. But rather than taking pulse and checking for spurting blood and missing appendages, I look for how much destruction the problem might cause, whether I use that product, and how well my current protection will mitigate the risk. Oh, and I rely very heavily on my evaluation of the source of the bug report.

Here's the process:

First, I do a quick reading, looking for critical info.

• Is that product in use? If not, delete the report. Life is too short.
• Who sent it? Reliable and trusted gets more attention than unknown, known but unreliable, Chicken Little pretenders and so on.
• Where did it come from? Was it a Microsoft security bulletin? Then you'd better pay attention. CERT advisory is a good bet. BUGTRAQ? It depends on the author. Many people may send things to this list, but some of them are worthless. Fortunately most of the useless ones are dropped or quickly countered by those in the know. Media reports are bound to be hyped. Use it as a general indicator, but search for truth elsewhere.
• How bad is it? Allows attacker to take over OS? That's bad. Must be administrator to utilize? Well, how well do I trust my admins and how hard is it to crack their passwords? Does the attack give an administrator something more than he or she already has? (In most cases, this isn't likely to be true.)
• Can I quickly mitigate the effect? Shut down the system? Remove Internet access until controls can be modified?
• Do my current controls prevent the attack or reduce its likelihood of being effective?

Next, perform triage. Determine whether the report requires an immediate response, whether it should be tabled for later reading, or whether the message should be deleted. My approach is iterative; I shuffle less-risky problems temporarily out of my way and come back to them after all current reports have been evaluated or after more critical reports have been processed.

To give you an example of how I do this, I'll detail my responses to several reports that reached me while I was in Atlanta recently. Reports came via e-mail. Additional alerts came as a result of conversations with others. Conversations aren't detailed, as they add nothing new and, for once, no one thought the sky was falling. I often have to debunk reports of dubious credibility. There are usually a lot of them that ignore how Windows 2000 works (something like the old, "Did you know the administrator has complete control over the system?"). Many of these come in as a result of media hype or some overeager presenter or other alarmist who blows things out of proportion.

I caution you against using my responses as representative of the action you should take to these or other alerts. Remember, I'm responding to my known circumstances and to conditions directly under my control. Your actions may be different, but your approach to the triage may be similar.

1. The first report is an e-mail from some organization with the word "security" in it. It's about multiple vulnerabilities in AMLServer, which is a paging gateway server for Windows. I'm not using the product, so I delete the message.
2. More on MS01-023 (sadminD/IIS Worm—a previous issue) from NTBUGTRAQ (www.ntbugtraq.com). The source is good, with notes to prior IIS vulnerability and possible re-application of hotfix after service pack update. I've already dealt with this, so I table it for reading later.
3. Security Bulletin from Microsoft--(MS01-033), "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise." Because IIS is installed by default, this could be bad. A quick read details the potential. However, it also reveals that it can be prevented by removing script mappings for .idq and .ida—which is standard practice for securing IIS and is already implemented on my site. Further reading, however, indicates that these mappings are replaced when Add/Remove Software | Add/Remove Windows Components is run. I haven't run that recently on the Web server. Seems like I'm OK, but I need to add the patch when I return to the office. I table it and note to check www.microsoft.com/technet/security for more details later.
4. NTBUGTRAQ notice on the above bulletin, with some more caution to remove additional mappings. It's the same information as Microsoft's recommendation for securing a Web server. I delete the message.
5. eEye Digital Security's posting to NTBUGTRAQ detailing how to use the vulnerability in an attack. This company is the one that found the flaw and worked with Microsoft. Note it didn't advertise the vulnerability until Microsoft had issued a bulletin and a patch. Kudos to eEye Digital, and another feather goes in its cap. It has done good work before, and this reinforces its standing with me. I'll note any alerts it issues, for sure. A quick scan of the post tells me that no scripting novice will use this exploit. However, that doesn't mean someone with skills won't create a script to run. I'm always aware of that, but at least the lack of a current, easily obtainable script will allow admins to patch servers.
6. Notice from win2ksecadvise list. Someone I've never heard of is complaining about McAfee VirusScan Online. It does indicate it's not an alert—just his experience with the product. He claims it left him without virus protection. I'm not using this product. I'll table it for some interesting reading later, perhaps, but it goes to the bottom of the stack.
7. InfoWorld (www.infoworld.com) security alert—a Sun Solaris bug report. It appears that a bug in the printer software provided with the OS might allow an attacker to compromise the network. Amusing, but there are no Solaris boxes on my network now. I delete the notice.
8. MS Security Bulletin—(MS01-34), "Malformed Word Document Could Enable Macro to Run Automatically." Even though macros can't run by default, apparently someone has figured out how to avoid security scans. A quick read of the bulletin seems to indicate that an attacker would have to alter a real Word document by editing it at a low level (i.e. not in Word). It's not something that can happen as the result of a known virus infection. While I use Word a lot, the risk seems low. There are few Word documents I open that come from someone else, and none that I open should they come from someone unknown. So to be affected, someone would have to grab a document of mine or a trusted third party's, do the dirty deed and get it to me. I table this for later action.
9. MS Security Bulletin—(MS-00-77), "Patch Available for NetMeeting Desktop Sharing Vulnerability." This is a revision to a bulletin announcing another variant of the DDOS attack and the availability of a new fix. Sharing the desktop through NetMeeting—in fact, sharing any desktop across the Internet—is risky business. Because I'm not currently using NetMeeting, make it a rule not to enable remote desktop sharing when I do, and block port 1720 (the NetMeeting listening port) on my firewall, this one can go to the bottom of the pile, too.
10. MS Security Bulletin—(MS01-035), "FrontPage Server Extension Sub-Component Contains Unchecked Buffer." I'm not using FrontPage, so I table it for reading later.
11. CERT Advisory (www.cert.org) on the Buffer Overflow in IIS mentioned above. Nothing new here, so I delete it.
12. W2Knews Newsletter (www.w2knews.com) with subject line, "This is a Serious Hole," which refers to IIS Buffer Overflow discussed above. It's nothing new. I table for reading later along with other newsletter pages (none of them appears to be a security issue).
13. Return to tabled reports to determine if any action is currently necessary.
14. Recheck e-mail for new reports.
15. Lather, rinse, repeat.