Developing a Response Plan for Computer Forensics

By Oliver Rist | Feb 22, 2002 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/979231/Developing-a-Response-Plan-for-Computer-Forensics.htm

Similar to a disaster recovery plan, a criminal response plan simply documents general procedures in case of a criminal incident involving corporate IT resources. In fact, many cyber-crime response plans are actually a part of an overall company disaster recovery plan. The primary objective here is to instigate a set of procedures that will effectively:

  1. Determine the nature of the crime
  2. be
  3. Determine the number and location of affected resources
  4. Determine the extent of damage to corporate resources, customers and partners
  5. Isolate affected resources from the production network
  6. Identify and isolate affected users from the network
  7. Document all processes and evidence for law enforcement officials.

Determining the nature of a crime, even if it is IT-related, cannot always be the sole responsibility of the network and systems admin staff. An electronic embezzling scheme, for instance, will probably need to be identified by the financial staff. As such, while network admins may write most of a cyber-crime response plan, they will need to involve other department heads in this process as well. Further, systems and processes will need to be in place to help pinpoint a criminal determination.

Again using a Windows 2000 network scenario, this could mean using a central file viewer (see next page), intrusion detection software, central encryption authority, and detailed knowledge of the Windows Registry. But these are just the tools. What will determine whether a criminal act has taken place can be summed up in a single word: "Documentation." Network administrators now more than ever need to effectively document the fair use and state of their networks. What should be running, where, how long, accessed by whom and why?

Such a benchmark is critical in determining criminal behavior, especially when an internal criminal is making illicit use of corporate resources or accessing data he or she shouldn't. All the investigative tools and procedures in the world are useless unless network administrators are fully aware of what should and should not be going on within the network environment. And if you think not knowing this information down to the last detail is embarrassing when a senior manager is looking over your shoulder, just wait until it's an FBI investigator or, worse, a defense attorney during cross examination.

With such information, however, it should be relatively simple not only to figure out whether a crime has been committed but also what resources have been affected and possibly even who was responsible. This is great news for both network admins as well as law enforcement officials, but here is where the two begin to diverge. Law enforcement is aimed strictly at catching the criminal and prosecuting the case. If that means impounding evidence immediately, so be it. Network administrators need to be concerned with keeping the network up and running. Losing a workstation is no big deal, but losing an important server, sensitive or essential corporate data or similar resources, however, is a big deal.

Once you've determined steps 1, 2 and 3, steps 4 and 5 must revolve not only around law enforcement's requirements but also corporate requirements. Network administrators will need to sit down with corporate counsel and senior management to determine the best procedures for tracking cyber-criminals; determining corporate damage and exposure; informing customers, clients and partners; and maintaining network up-time while still isolating damaged or criminally affected resources and users for investigative purposes.

The exact steps will differ for every company, but the goal will always be to give law enforcement all the tools they need to properly handle an investigation, while simultaneously protecting your network, your company and your customers or partners. Often this means additional back-up resources. On the software side, this can mean additional data stores and backup application resources. On the hardware side, it means even more uses for mirrored hardware resources even if they're just sitting in a store room waiting for a rainy day.

Evidence Handling & Documentation
Once your evidence has been identified and isolated, network managers are usually the first line of defense in an evidence-handling chain, which is when you arrive at step 6. Sure, law enforcement officials should manage this process, but in reality it will most often fall onto network and systems administrators simply because their priority is to first protect and stabilize the network and then involve law enforcement.

Indeed, this is best from the network manager's point of view as law enforcement will often impound compromised machines and data for analysis off-site; you don't want to be scrambling to initiate a back-up system as investigators are yanking important resources off the network. Those resources should already be running when investigators arrive, so that removal of any evidence has no further adverse affect on network performance or productivity.

Proper documentation should be exhaustive. Always err on the side of too much, and use as much automated documentation as possible. By that, we mean documentation that already exists including asset management data, for example. Affected resources will require brand names, model numbers, serial numbers, MAC addresses and similar data. Accessing an asset management database can pull up this information in seconds. Proper network documentation will provide IP addresses, domain names, resource permissions, drive paths and more. Use these resources, append this information to your investigative documentation and make sure to authenticate the material with signatures and, if possible and relevant, digital time stamps.

The rest of your documentation must include all your investigative actions, the reasons for those actions, the methods used for investigation and always when and where everything took place. Make sure to use only legal means for investigating a situation (another good thing to discuss with an attorney during the response planning phase) and document this as well. This should cover not only when and why you accessed certain corporate or user resources, but also the tools you used in the process.

Forensic Tools & Intrusion Detection
What should be in an electronic forensic tool kit? Again, this will vary from network to network, but some general suggestions include:

  • Hard drive partitioning tools. PartitionMagic, for example, will allow not only the booting of practically any PC off its base floppy, but will also be able to identify and picture almost any OS file partition.
  • File viewers. These are faster and more efficient than tracking down the appropriate file application. A single image viewer can cross not only application but OS boundaries, and they offer the added benefit that they don't tamper with the data in any way. Opening a Word file in a viewer usually changes nothing, for instance, but opening it in Word can change the modification date and other Properties-style information.
  • CD-R and ZIP disc utilities. Creating these disks is often the task of specialized software, which must be in your tool kit for full access to such discs.
  • Unerase and System Recovery utilities. Norton is the most popular vendor of such tools for Windows environments, but more tools exist for other operating systems. Hard drive imaging tools are another goody in this category.
  • Resource snapshot utilities. Fcheck is a file integrity checker usually reserved for intrusion detection systems on Unix hosts. Using it standalone, however, can allow administrators to take snapshots of directories or file systems and then use those snapshots as benchmarks for later comparisons of proper use and tampering.
  • Text searching utilities. There are a number of these applications, such as dtSearch, that are designed to search large gobs of text data (documents, presentations, data stores, email stores, etc.) for key words and phrases.

Again, these are just base guidelines of front-line investigative tools, and they will vary significantly with your specific network type and operating environment. Those companies who feel they are at high risk may want their network managers to look at specialized forensic investigative tool kits. These can include special investigative applications, such as those sold by NTI, or be focused more on proper investigation, evidence handling and case documentation such as those sold by EnCase.

Obviously, the material presented here can be used only as the most general guideline towards specific forensic procedures. Your company, its business, your network environment and operating platform will all determine not only your specific forensic response but also tools and procedures.

The best tip here is maintaining depth. Network administrators need to become expert not only in the operational details of their networks, but in the features, quirks and traps of their chosen operating platforms as well. Keeping the number of operating systems and product platforms on your network limited is one of the best ways of allowing your staff to concentrate on learning the intricacies of only a few platforms rather than attempting to become expert at everything under the sun. Limiting your environment means limiting your perimeter, and that always makes for an easier defense.

Being an expert on your own systems will also enable you to interact more effectively with law enforcement authorities. When they have questions, you'll have answers. When they need to modify the environment, you'll be able to respond. And when a defense attorney attempts to discredit your organization, you'll be armed. For computer forensics especially, knowledge is the ultimate power.

--
Oliver Rist is a technology journalist and vice president of technology at AIC Inc. A former technology editor of CMP's InternetWeek and expert in the Microsoft Windows and BackOffice product family.