Pre-incident Preparation: Part 1
Results 1 to 3 of 3

Thread: Pre-incident Preparation: Part 1

  1. #1
    Senior Member
    Join Date
    Aug 2003

    Pre-incident Preparation: Part 1


    This tutorial is compiled from several different internet sources, and also the book "Incident Response & Computer Forensics, 2nd edition" by Kevin Mandia, Chris Prosise, and Matt Pepe. Some of this information is provided verbatim, and where possible, sources are cited. It is not intended to be all inclusive, but rather to present an overview of pre-incident preparation.

    You come into work and discover that your servers have been compromised, and valuable personal data has been stolen. No problem, you call your computer security incident response team (CSIRT), and everything will be great, right?

    Not necessarily. One of the most important, and most overlooked, steps of intrusion detection (in my short experience) is the PRE-INCIDENT PREPARATION. What follows is a summary from "Incident Response & Computer Forensics, 2nd edition" (IR&CF,2ND)

    - Identify your corporate risk
    - prepare your hosts for incident response
    - prepare your network by implementing network security measures
    - establish policies and procedures that allow you to meet your response objectives
    - create a response toolkit for use by the CSIRT
    - create a CSIRT that can assemble to handle incidents.

    This is fairly self explanatory. Basically it just means asking a few questions. What are our assets? How are those assets threatened? How can someone get to those assets?

    For my example, we will pretend to be in charge of security for a commercial property management company. In this case, field offices are spread throughout the country. At each office a database containing sensitive client information is maintained, and it is required that the database is sent to the "Home Office" once a week.

    Our assets would then be the database, and the information contained could be addresses, social security numbers, tax id's, etc. The threat could come from competitors vying for our clients or identity thieves. The vulnerabilities lie in several areas. Untrained users, sniffers, keyloggers, database 'miners', and unpatched servers.


    Again, borrowing from IR&CF, 2ND:

    -record checksums of critical files
    -increase and enable secure audit loging
    -build up defenses
    -back up data and store media securely
    -educate users about security

    A checksum, also known as a fingerprint, is a digital signature unique to that file. These are used to compare a system in a known "Good State" vs a system that may have been compromised. One of the most commonly used methods to create checksums is the MD5 algorithm. The algorithm was created by R. Rivest, and is detailed in RFC 1321.

    An explanation of how it works, along with both a windows version and *nix version can be found here:

    There are also programs to automate the process such as Tripwire (no longer supported).


    Windows and Unix both have extensive logging policies, but may need to be tweaked. Not trying to start a flame war, but my limited research indicates Unix has better, and more logging capabilities than Windows. Regardless of what OS you use, review your manuals to learn how to configure your logs properly. Many are not configured by default.

    SET UP REMOTE LOGGING. Unix has features already built in (in most cases), Windows NT requires a 3rd party application such as NTsyslog, found here:

    By transferring your log files to a remote secure server, you minimize the danger of log files being removed or altered.


    Patches, firewall, IDS, etc. Disable unnesessary servicec.


    Back up often...


    Probably one of the most difficult aspects, and beyond the scope of this tutorial.


    In summary (again from IR&CF, 2nd)
    -install firewalls and IDS
    -use access control on routers
    -create a network topology conducive to monitoring
    -encrypt network traffic
    -require authentication

    This will be covered in a later tutorial.


    Instronics' tutorial does (imho) an excellent job covering this, and I recommend everyone take time to read it.

    A couple legal issues that I don't recall seeing in there concern privacy issues.(And if I missed it, my apologies) Basically, unless you have a specific policy that states you may monitor traffic, you can't. Unless you have a policy stating that you may monitor emails, you can't. Of course, laws vary from stae to state.

    Policies need to include provisions for performing trap and trace traffic, full content monitoring, and searching an individuals machine. With policies in place, a system admin is able to legally cut through some of the obstacles thrown up by law enforcement.

    A complete explanation of the Electronic Communications Privacy Act can be found here:

    More on this will (hopefully) be covered in a future tutorial.

    PART 2: The CSIRT toolkit, assembling the CSIRT team.

  2. #2
    Junior Member
    Join Date
    Nov 2003
    Nice tutorial!
    There are sports cars. Then there\'s the Z.
    240Z 260Z 280Z 280ZX 300ZX 350Z

  3. #3
    AOs Resident Troll
    Join Date
    Nov 2003
    educate users about security
    This is by far is the hardest...but most important thing.

    I use teaching by ossmosis.......repeat the same thing over and over and over and over........
    If I say it day they will get it ???

    How people treat you is their karma- how you react is yours-Wayne Dyer

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts