The legal dangers of failing to protect your data are increasing daily, leading to a surge of interest in the field of forensic analysis. Administrators already possess some of the skills, tools, and knowledge needed for formal forensic analysis of a compromised system, but FA takes the usual problem-fixing routine to a whole new level—one you need to be aware of and plan for in advance if any of the data on your network is confidential or contains personal data of any sort.

The time is rapidly approaching when civil and criminal cases involving the compromise of personal information, corporate secrets, and even job-related disciplinary action will be commonplace. The best and perhaps only defense in a legal sense will be to have a solid incident response plan in place and follow it until you determine that a problem was not the result of a hacker or other criminal action. Failing to show good faith in protecting data could soon become a very expensive mistake in court. Just as important, without a formal forensic analysis/incident response plan, you can never be certain that you’ll actually discover who or what caused a problem or what data may have been compromised.

Forensic analysis of computer systems is as difficult and as necessary as the crime scene and medical forensics that are shown (albeit inaccurately) on popular TV shows. DNA analysis really doesn’t happen in a few minutes, nor does every small police lab have millions of dollars’ worth of equipment and unlimited resources to put on every case. Likewise, electronic forensic analysis of an intrusion will never be as easy or as painless as it is made out to be in some manuals, but it is vital, especially when the facts aren’t obvious from the outset.

Electronic forensic analysis
Some of the things that forensic analysis can show include:

  • Whether you were really hacked. This can often be surprisingly difficult to determine, and it must be determined at a very early point in the response process by someone on the scene.
  • If there are reasons to treat the incident as a legal issue rather than just fix the problem and move on.
  • If this was a targeted attack on your systems or just a random attack.
  • The origin of the attack; in particular, you need to determine if you have an internal threat, which is the most dangerous kind.
  • If any data has been copied, removed, or altered.

Answers to other questions may be of equal or greater importance for your company:

  • Exactly how did the penetration occur?
  • How can we prevent this in the future?
  • How can we assure the integrity of our data?
  • How quickly can we get the system and data restored and users back to being productive?
  • What system features are the most critical and need to be restored first?

How a business answers these questions will greatly depend on the kind of data being protected, whether the problem will be dealt with internally, or whether the company might eventually turn to law enforcement for help in prosecuting the perpetrators, but it will always involve forensic analysis of some sort.

The basis of all forensic analysis is just the normal troubleshooting you conduct whenever a network problem occurs. But if an actual attack has taken place, you need to follow some strict formal rules, and you need to begin thinking about them before an incident occurs. Merely being technically capable of analyzing a log to find an intrusion signature isn’t enough if a case ever needs to go to either civil or criminal court.

An understanding of basic forensic analysis is essential in producing an incident response plan so that you don’t lose vital data about the intrusion or destroy the chain of custody of the evidence before you realize you’ll need to preserve certain records in a specific legal fashion. This plan must be in writing because it must be available to any assistant or entry-level network administrator when he or she is alone in the office and is faced with a possible intrusion.

The importance of having a formal incident response plan and making certain everyone knows when and how to activate it can’t be overemphasized. Mistakes made by the third-shift assistant manager in the first five minutes can completely compromise an investigation to the point where you may never be able to determine if an attack even took place.

The case law on electronic evidence gathering is changing all the time and varies with jurisdiction, but some general rules apply. Even if you make a mistake, the courts can consider whether you made a good-faith effort to collect evidence in a proper manner. If you don’t have a written incident response plan, you could be in trouble if an intrusion has any legal ramifications.

Although it doesn’t apply directly to internal corporate situations, there is extensive information from the U.S. Department of Justice’s that may prove useful. A lot of this information covers rules involving seizure of evidence, which don’t apply to you. But there’s also information on search planning and evidence collection, with an emphasis on showing that records and programs haven’t been altered—these are essential for any incident response plan.

Forensic analysis basics are simple enough: Document everything, and I mean everything, from the time the incident was first reported, including who reported it, to whom it was reported, the precise network configuration, OS and application versions, and the location and timing of any existing backups. Federal judges have viewed claims that records have been altered with considerable skepticism unless some solid evidence of tampering exists, so you must be thorough in your documentation.

Planting malware, altering records, stealing personal information, interrupting services, and hijacking trade secrets are all likely actions that can result from a break-in. All of these actions have economic consequences and may end up in court at some later time. You need to approach every incident as if it will end up in court, at least to the point where you can determine that the cost was low, the damage was minimal, or the incident wasn’t the result of an attack—in other words, until you’re certain this won’t escalate into a legal matter.

Getting started
Here are a few basic elements to include in an incident response plan. You can adjust these to fit your particular environment.

  • Establish the chain of command. Indicate the first contact as well as alternatives if that person can’t be reached.
  • Describe, in detail, procedures used to determine if a reportable incident has occurred and when the incident response should be activated. Remember that this must be usable by anyone who may be left in charge of the network, and that person may need to contact someone in the chain of command to determine if the incident needs to be reported.
  • Record the precise hardware and software layout of the network at the time the incident is discovered and any potential entry points where an intruder is suspected to have compromised the network.
  • Describe the e-mail system in use and secure all e-mail messages.
  • Determine who has had recent legitimate access to the system.
  • Secure all formal backups and record all backup procedures.
  • Collect and secure any informal backups on removable media and, at a minimum, write-protect them; but more important, physically remove and secure them.
  • Secure all log files.
  • If the data is particularly sensitive or legal action is anticipated, make an image backup of any drives or removable media to tamper-proof media, such as a CD-R or DVD-R (but not a CD-RW or DVD-RW).
  • Image the drives in desktops, workstations, notebooks, file servers, and mainframes, and don’t forget to physically secure PDAs.
  • Be sure to run a virus check since malware can continue to alter data.

End sum
These are just a few of the bare essentials that any incident response plan must address, and they’re only the beginning steps to a formal forensic analysis of a network and its systems. In future articles, I’ll deal with forensic analysis in greater depth.