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
- September 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- CERT Advisory (www.cert.org)
on the Buffer Overflow in IIS mentioned above. Nothing
new here, so I delete it.
- 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).
- Return to tabled reports to determine if any action
is currently necessary.
- Recheck e-mail for new reports.
- Lather, rinse, repeat.
About the Author
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.