A security breach patch checklist

Following this security breach patch checklist 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 in this security breach patch checklist.

 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

  • Tip: Teach users how to patch their own systems
  • Tip: Stay on top of automated patching
  • Ask the Experts: Ask Jason Chan your patch management questions


  • This was first published in July 2005
    This Content Component encountered an error

    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:

    -ADS BY GOOGLE

    SearchVirtualDesktop

    SearchWindowsServer

    SearchExchange

    Close