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 in this security breach patch checklist.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
|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!|
More information from SearchWindowsSecurity.com