Checklist: Patching after a security breach -- special considerations

The patching approach you take immediately following a security breach may mean the difference between preventing future attacks and leaving your system exposed to new threats.

The typical cure for an external security breach is to undo the damage and patch to prevent that type of attack

from happening again, whether it was a worm or an exploit that takes advantage of a specific buffer overflow condition. However, the approach you take directly following a security breach may be the difference between preventing a future occurrence or leaving your systems open to attack once more. Here are some special considerations to keep in mind.

 Checklist: Patching after a security breach -- special considerations
1. Find out exactly what happened
Perform an analysis of the attacks on your systems, and compare them to those suffered by others in your organization, or by other organizations entirely. The CERT group has detailed
information about the symptoms, causes and resolutions of the most notorious in-the-wild attacks. For instance, if you suspect you were hit with a buffer-overflow worm that
attacks via Internet Information Services (IIS), check the IIS service logs around the time symptoms started appearing to see if the telltale patterns of a buffer overflow are present.
2. Don't rule out of the possibility of multiple attacks at once
If you only patch for one type of attack after you've been hit, you may still be vulnerable to another program that entered your network at the same time. For instance,
being hit by a buffer overflow attack is bad enough, but it might allow someone to arbitrarily inject code that installs a keystroke logger and harvest your system passwords.
3. Do forensics before you patch
Make sure any forensic work -- log analysis, copying out kernel dumps, etc. -- is done before you patch anything. If there was real loss involved and you had to call the police
or FBI, don't touch anything.
4. Determine if the patch is really what you need
An outside attack might lead you to discover that something else was at fault here. For instance, was the attack actually an internal breach? If so, patching may not stop it if
someone has local console access. Take time to determine if the security breach was caused by something unrelated to the patchable problem.
5. Test and test again
Don't assume a patch means the end of the problem. Get a white hat tester if you can to make sure the patch does indeed fix the described issue. Also see if any other behaviors
appear or are affected by this patch. For instance, if you're patching firmware in a router, make sure existing routing rules or packet-length structures aren't affected -- things which
can cause bizarre behaviors in some e-mail systems.

Windows Security Checklists offer you step-by-step advice for planning, setting up and hardening your Windows security infrastructure. E-mail the editor to suggest additional checklist topics.


ABOUT THE AUTHOR:   Go back to Checklist
Serdar Yegulalp is the editor of the Windows 2000 Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!

This tip originally appeared on SearchWindowsSecurity.com

This was first published in August 2005

Dig deeper on Network Administration

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close