Pre-incident Preparation: Part 1
PREPARATION FOR PRE-INCIDENT RESPONSE: PART 1 of 2
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.
IDENTIFY YOUR CORPORATE RISK
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.
PREPARING HOSTS FOR INCIDENT RESPONSE
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. http://www.faqs.org/rfcs/rfc1321.html
An explanation of how it works, along with both a windows version and *nix version can be found here:http://www.fourmilab.ch/md5/
There are also programs to automate the process such as Tripwire (no longer supported).
ENABLE SECURE AUDIT LOGGING
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: http://sourceforge.net/projects/ntsyslog/
By transferring your log files to a remote secure server, you minimize the danger of log files being removed or altered.
BUILD UP DEFENSES
Patches, firewall, IDS, etc. Disable unnesessary servicec.
BACK UP DATA
Back up often...
EDUCATE USERS
Probably one of the most difficult aspects, and beyond the scope of this tutorial.
PREPARING A NETWORK
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.
ESTABLISHING POLICIES AND PROCEDURES
Instronics' tutorial does (imho) an excellent job covering this, and I recommend everyone take time to read it. http://www.antionline.com/showthread...hreadid=239576
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:
http://floridalawfirm.com/privacy.html
More on this will (hopefully) be covered in a future tutorial.
PART 2: The CSIRT toolkit, assembling the CSIRT team.
