Chapter 13: Incident Response


Overview

There is no single indicator of computer crimes that has shown a decrease in the amount of computer incidents over the past ten years. In some cases, the number of reported computer crimes is increasing exponentially and one can only guess at the number of unreported crimes.

By using the information in this book and through the use of other resources, you will create a network that can be called "secure" by the current state of the technology. Remember, however, that this term is simply relative. Your network will never be "totally secure," no matter what vendor marketing may try to convince you in an effort to sell its products. Just the opposite is true; you will periodically experience "computer incidents" and at some point your network will be the target of a computer crime.

To react to this eventuality, you need a computer incident response team (CIRT). [1] Successfully responding to an incident will require a group in place with an established plan of action. There are several advantages to having a plan in place when an incident occurs. The primary objective of establishing an incident response plan is to prevent the loss of life or the loss of data because of the incident. It also ensures that resources are efficiently allocated. If two network administrators respond to a computer incident by performing the same actions, then that is a waste of time that could have been otherwise better spent. Having an established plan also allows the team to practice its response. It would not be a good idea, for example, to require a team to practice its evidence handling procedure during its first case of suspected computer crime. Finally, speaking of computer crime, if it does turn out that a computer incident is indeed the result of a crime, then having a trained team with a response plan that has been practiced and followed greatly increases the chance that the criminal will be successfully caught and, just as importantly, tried and convicted based on the evidence that your team has gathered.

By the end of this chapter, we will have covered the steps required to ensure the following:

  • Why an organized incident response plan is important

  • How to create your own company incident response team

  • How to craft your incident response policy

  • How to respond to an incident in a manner that minimizes network disruptions and provides consistent positive results for your network, its users, and the security of your information

While talking about incident response, we will also spend some time discussing the forensic process — due to the importance of the forensic process in a complete incident response plan.

Computer crimes have been growing at a phenomenal rate. While early numbers may have been somewhat lower due to companies' reluctance to speak about incidents on their networks, every major indicator of computer crime, from the FBI to global computer emergency response teams, has shown an incredible increase in the number of computer crimes over the past ten years.

Law enforcement often states that crime follows the money. Given the amount of money that is invested in and relies on our global information infrastructure, it is no surprise that computer crime trends have been rising so dramatically.

In the communications industry, we have spent enormous sums of money to protect our networks. We train our network administrators and end users in the art of information security. We establish security policies that lay out the expected behavior for network users, and we place our trust in fascinating technologies such as firewalls, virtual private networks, encryption, and intrusion detection.

Despite our best efforts, however, statistics tell us that it is just a matter of time before our companies will need to respond to a computer incident. How we react when this happens can often make the difference between a minor hiccup in network activity or considerable downtime and lost productivity. How we react when this happens can make the difference between the successful resolution of a computer crime and lost data, trade secrets, and trust on the part of our network users and investors.

The key to successful incident response is preparedness. Like any team, the best plays are executed when every member of the team knows his or her part and practices the execution of the play until it is perfect. When the big game comes, the best-prepared team is the one that wins. Inside the organization, the same analogy holds true. While creating an incident response team is going to cost some money and energy, having a team in place can offer a significant return on investment.

When an incident response team is called into action, its actions benefit the company in several tangible ways, including:

  • The incident response team that has practiced its response can most importantly prevent the loss of life or critical data. This is irrespective of whether data or lives are at risk due to software failure or a computer crime in progress.

  • Like every good team, each member knows the role that he or she plays in supporting the team. This allows rapid response and maximum utilization of company resources. This benefit pays big dividends when a team is allowed to practice its responses prior to an incident occurring.

  • Good incident response teams are good public relations teams as well. Whether individual investors or network users, people are happy to know that a crisis that might put the company at risk can be professionally managed.

  • Finally, but certainly not the least in importance, professional incident response may be the best countermeasure to criminal actions directed at the company. Digital data, like any type of evidence used in a crime needs to be handled in a specific and legally correct manner. When a company attempts to prosecute a computer crime, its chances of success are greatly reduced if it has not taken the proper steps in the acquisition of evidence. The best way to ensure success in the courtroom is to make sure that professionals trained in the science of evidence gather the evidence in the hectic first moments of a computer incident.

With that in mind, let us start thinking about incident response.

The discipline of incident response can be broken into nine major categories, each building on the previous one.

  1. Planning. This is where to spend the most time. A good planning process will ensure that the rest of the elements of incident response fall smoothly into place.

  2. Prevention. The best offense is a good defense. Special care should be taken to ensure that your network is secure and up-to-date with regard to a good security policy. When the network is secure, the detection and evaluation of real network threats are made much easier.

  3. Detection. Many computer crimes occur right under our noses, so to speak. Someone could be using your computer right now over the network without your knowledge. Without some way to see what is going on in the network, responding to an incident you do not know is occurring will be difficult.

  4. Evaluation. Not all incidents are crimes. A great deal of the time, suspicious behavior on your network can be accounted for by either software or hardware problems that have nothing to do with hackers in a small room thousands of miles away. Before sounding the alarm, we need to make sure that the behavior we are witnessing is indeed the result of a computer crime.

  5. Containment. In general, the first rule of incident response is to get a handle on the incident and ensure that neither your network users nor your information is at further risk.

  6. Investigation. Once the affected systems have been contained, it is time to examine the incident. During this time, any evidence that might be used in criminal proceedings is collected. At a bare minimum, the incident response team will seek to understand the cause of the incident so that a repeat event can be prevented in the future.

  7. Eradication. The cause of the incident is removed.

  8. Recovery. Finally, the updated, repaired, and safe system is brought back online. This might require a complete reinstallation of the software controlling the machine or it might require less drastic methods, depending on the number of steps taken during the planning and prevention stages. Once again, good planning pays off.

  9. Post-mortem. Every incident should be followed up with a meeting of the team to discuss what went right and what needs to be improved the next time around. Documentation produced during the incident should be reviewed and the incident response process should be refined to improve performance.

As previously mentioned, the most important step of incident response is the planning stage. There are several major objectives of this stage. Primarily, we are looking for buy-in from management that an incident response process is valuable to the company as a whole. This applies not to just the incident response team specifically, but to a corporate network security policy as a whole. Indeed, the incident response team is only a part of an overall security policy. Once approval for creating an incident response team has been granted, the next step is to assemble the team and develop the response plan.

Because an incident response team is part of an overall information security infrastructure, the same business benefits that can be made for selling security policy can also be made for the selling the incident response team. There are various ways to justify this expenditure, but they all hinge on the value of the assets that the security policy and the team are protecting. You would buy insurance to protect your house, right? This is an asset that you wish to protect. For the same reasons, you implement an incident response team — because your business depends on the network and the data that the network houses.

There are several ways to put an incident response team together. Many times, the team can be constructed from interested parties within an organization. Do not limit your search to just people who work on the IT staff. There are many roles to play on an incident response team. Your team will most likely include members of the IT staff, but it should also include members of human resources, the legal department, and administrative staff. It might also include some members who are not directly employed by your company if expertise in a given area is lacking from the in-house pool of talent. For example, in-house staff may not have the expertise to adequately investigate digital data. If company employees are trained in how to collect evidence and data correctly, an outside forensic expert with whom you have a professional relationship can do the actual forensic examination of the data.

There are several options to consider when choosing the composition of an emergency response team. Several years ago, it would have been acceptable to request the services of a public CIRT, such as the Carnegie Mellon Computer Emergency Response Team (CERT). When an incident was suspected, the concerned network administrator would contact the CERT and alert them of the incident and seek advice for resolving the issue. This arrangement was often advantageous not only because of the price, but also because the public teams responded to a great many incidents. This global perspective would mean that public CIRTs had an accurate view of overall incident activity and could maintain extensive databases of incidents and resolutions. The Internet as a whole, however, was a much smaller place and the number of incidents reported was nowhere near that of of today's numbers. While public CIRT teams are available, companies typically use them simply as places to record data. They are no longer a serious option for first responder roles.

Instead, a company can choose to use a commercial incident response vendor. These companies contract to monitor the network security of an organization and are empowered to respond to any incidents that might occur. Like the public CIRTs, these companies have a wealth of experience in forecasting and detecting incidents. While network administrators for a single organization may not have the perspective to recognize that problems on their network are occurring on a great deal of other networks at the same time, commercial CIRTs have just this ability.

A commercial CIRT may be advantageous to a company in that it allows the organization to better utilize its own resources. Most organizations cannot afford to keep someone on staff with the training and sole duty of responding to incidents. Many times, it is clear that outsourcing this function is good cost management.

Other organizations prefer to maintain their own incident response teams. While it is logical to presume that the team would be made up primarily of IT staff, this is not always a requirement. Many times, large organizations will split incident response teams so that they better mirror the business roles rather than strictly IT roles. The presumption is that each department knows its own needs best.

This intimate knowledge of the network and business needs of a company is the primary advantage to creating a CIRT utilizing your own resources. In large companies, where the incident response team and security groups might be independent entities, an in-house incident response team generally has an easier time than an outside vendor working with the security group to ensure that the incident does not re-occur.

The final option is not really an option, but necessity sometimes makes it so. An ad hoc incident response team is better than having no formal team in place at all. At a minimum, an ad hoc incident response team composed of whoever is available at the time would have a set of documented procedures to follow to assist in the timely response to an incident. This ad hoc team would also have documentation to and aid in the investigative and recovery portion of incident response.

When establishing the team, it is important to establish the chain of command and who has what responsibilities. This is a crucial element of incident response. While a democracy works well when there is time to deliberate actions, in a crisis, there needs to be a single person coordinating the actions of the other team members.

Some thought should also be given to whom the team as a whole reports to within the organization. This is where the understanding of the political climate of your organization will be important. There may be times when the team discovers inappropriate behavior on the part of individuals working within the company. Knowing that they can act upon such behavior without fear of backlash will be important for the proper operation of the team.

Once the team is established, it is time to work on response plans. These are the steps of who does what in a crisis. The major outline of the plan should follow the steps that we have already discussed. That is, there should be clear guidelines regarding how an incident might be detected, meaning what behavior should alert users to a possible computer incident; what the process of evaluation will be; and how an incident is distinguished from other network behavior. Once it is clear that there is a computer crime occurring on the network, how is the system contained? How is evidence collected? How is the system cleansed and protected from future attacks? Finally, how is the system brought back online?

The most difficult part of planning these steps is going to be the degree of subjectivity that most computer incidents have surrounding them. While it may be clear that a computer incident is in the works, it may not always be clear as to how the incident should be responded to. For example, consider the common event of someone scanning your firewall for vulnerabilities. This happens so often that a passing scan would be a waste of time and resources on everyone's part. What happens if one scan becomes ten from a single source or network? When does this nuisance activity become something to be concerned about?

One way to deal with such ambiguity is to create a threat list that categorizes potential incidents according to the degree of severity. For example, one such organization's list might look like this:

  • Critical. The Critical level might include only those threats that put human life and safety at risk. They might also involve threats that could potentially and irrevocably destroy critical data. Because every organization should have a comprehensive backup and recovery plan in addition to an incident response plan, it is hoped that the number of threats that could affect their data in this manner is quite minimal.

  • High. Threats in the High category might include attacks that have a very high potential for damage to critical network resources. Such threats might include attacks or vulnerabilities that allow an attacker root or administrative access to servers or the domain. Others might be attacks where system damage is imminent and classified or sensitive data is at risk. As a general rule of guidance, threats that affect the confidentiality or integrity of data should fall into this category. Our example of someone gaining root access to a system would allow this to occur.

  • Medium. Threats in the Medium category are those that are significant but do not directly threaten critical systems or data. Examples might include attempts at unauthorized access to user accounts, unusual user account activity, or the impairment of noncritical network resources. Many Web-site defacements might belong in this category as well. While the Web site has been attacked and this is a serious event, critical data has rarely been altered, lost to, or obtained by an attacker. Another generalization might be to include threats that affect the availability of resources but do not affect the confidentiality or the integrity of data. The Web-site defacement or a denial-of-service attack would qualify as threats to availability.

  • Low. A low threat is someone attempting to pass the Klez virus through your e-mail server when you know that your server is scanning for and removing these viruses. When you know that the system has been prepared for such an incident and that no harm will result from it, then the threat is low. Many "script kiddie" attacks, especially the older, well-established ones fall into this category as well.

  • Minimal. As a normal part of business, your network will be the target of a great deal of half-hearted "doorknob rattling." This group of minimal threats might include such things as PING scans, SYN scans, and the normal high-volume, low-threat activities that make the Internet such an interesting place.

These are, of course, just examples. Many companies like to use obtuse or important-sounding, threat-level categories like "alpha-orange-1" and "fire-left-down." Furthermore, what your company prioritizes may differ from the suggestions offered above. Whatever you like to use, the important element is that you have established that not all threats and incidents are created equal.

At the same time you are establishing threat levels, you should also examine your network resources. Prioritize them in terms of importance. There are surely some servers that are more important to the overall business than user end-stations, just as your customer relations management software is more important than a misbehaving e-mail client. The relative importance of your assets will also help your team make the right decisions during a crisis.

Once your team has established threat levels and defined critical network resources, it is time to define some response options. There are four major options that provide guidance on how to respond during an incident.

The first of these choices is: Do nothing! And that is right. You might decide that the most effective way to address some incidents is to do nothing at all. This is most often the case when the severity of the threat is low or minimal and the relative value of the target is also low.

One of the major reasons that incident response teams fail, in addition to lacking proper planning, is that they try to respond to too much. Properly following the eight steps of incident response requires a great deal of energy and time on the part of the incident response team. Throwing all these resources at every script-kiddie that comes your way will be a sure way to burn out your team members. Do not be afraid to "do nothing" when it is justified.

The second choice of incident response is to simply defend against the attack and future attacks. This may mean configuring the firewall to block such attacks or installing application or operating system patches that render the attack harmless. Not every organization is interested in investigating and pursuing computer criminals. Sometimes, the most effective use of time is to identify the threat, eradicate it, and prevent it from threatening your network in the future. This is a good choice for low to medium threats against most of your company assets.

In some specialized cases, one option may be to perform surveillance or gather additional data on the threat. This may mean confining the system to prevent the attacker from further damaging the network, but at the same time installing monitoring software or hardware to follow the attackers. Most of the time, this information is used to collect evidence in the eventual prosecution of the attacker, but it can also be used to educate the incident response team as to the attacker's methods and goals.

The final of the four response options is to defend the network against further attacks and at the same time seek the arrest of the perpetrator or otherwise demand satisfaction through the civil court system. This is the most costly and time-consuming of all options and should only be considered when the threat level and asset value are high. While there is a growing awareness of computer crimes, catching and successfully prosecuting a criminal for computer crimes can still be a long-shot proposition. Nevertheless, your incident response team members should be trained for this decision because the actions they take in the first few minutes of response can determine the eventual outcome of any legal action.

The final step of finishing the policy is to establish some guidelines as to the involvement of the incident response team members. For example, you do not necessarily need to involve the members of the team who are part of the legal department or those who are primarily concerned with the examination of forensic evidence for every incident. The level of threat, asset value of the target, and chosen response should dictate the involvement of team members on an as-needed basis.

Part of creating a CIRT is ensuring that the team has the resources it needs to accomplish its tasks. To further this end, a couple of "incident toolkits" should be prepared ahead of time so that during the response, when time is of the essence, all needed materials are at hand.

A single-incident toolkit typically includes a well-prepared laptop that has at a minimum the following features:

  • Sniffer software/protocol analyzers.

  • Network adapters for the various media on your network — typically Ethernet, fiber, and perhaps Token Ring if you are still fortunate enough to be employing this technology. Be aware that most Token Ring adapters do not work in promiscuous mode, thereby making them difficult to operate with sniffing software.

  • CD-RW drive. The laptop may be required to capture and store media. Ideally, these captures will be stored directly to a CD-RW to minimize the argument that someone had altered the data after collecting it.

  • Disk imaging software. There are a number of software products available for the direct copying of information from one disk to another. This is useful in the acquisition of data from active hard drives.

  • Forensic disk reading software. This specialized software allows a user to view the contents of a disk drive by viewing the surface of the drive itself. It is ideal for finding information that is otherwise hidden through the directory services of an operating system.

The above tools will, in combination, create a minimal forensics station capable of troubleshooting computer incidents and, if need be, collecting data to be used for further troubleshooting or an actual investigation. The laptop will not be as versatile as a dedicated forensics station, but will be adequate for a first response role. Companies that are serious about incident response and have the on-site expertise to be able to perform their own forensic investigations upon captured data should also invest in a dedicated forensics station. Introductory desktop forensic stations normally start around the price that you would pay for a decent laptop computer. Mobile stations start at about double that cost.

Impressive hardware with lots of bells and whistles, however, is only the start of a good incident toolkit. Other materials that assist in the troubleshooting and recording of data and actions are also helpful. Also consider including the following:

  • Removable media such as a JAZ or ZIP drive for quick removal of information from a system hard drive or volatile memory.

  • Spare, large-capacity drives, including IDE, SCSI, and tape drives. These are useful when a direct dump of all drive information is required. Retaining the same format as the original drive is especially important if you wish to boot the copied drive to recreate the environment on the original machine. Along with these drives, include a number of adaptor cables for each drive type, as well as spare power couplers. It is typical of Murphy's Law to be out of couplers from the internal power supply just when you need them for disk imaging.

  • Spare power strips. You can never have enough outlets.

  • 35mm flash camera or digital camera. Much of the documentation that must be performed in an investigation is greatly assisted through the use of a camera of some sort. The original environment can then be documented to film, along with the specific steps taken during any investigation.

  • A collection of bootable floppy disks. At a minimum, this should include boot disks for the operating systems that are used in your network. A number of single-disk Linux distributions are available that can provide a complete RAM disk-based operating system with network utilities if required.

  • A generous supply of write-once CDs, along with markers and labels for documentation.

  • Complete documentation for all operating systems, applications, and hardware likely to be found on the network. In general, this information is stored electronically on a number of CDs. Otherwise, your network response team is going to have to include weight training in its response planning.

  • Notebooks and pens. Documentation is crucial while investigating computer incidents.

  • Personal voice recorders. These can either be the cassette or MP3 variety. Ideally, CIRT members work in pairs, with one member taking notes and one recording events. A personal voice recorder, however, can allow one investigator to work while recording actions for later transcription if need be.

  • Evidence labels.

One item in the above list merits further explanation (i.e., the evidence label). Every piece of information gathered during an incident should be treated as if it would someday wind up in front of a judge. In the majority of cases, this will not be true; but for those times that it is true, collecting the evidence with a clear chain of custody will be preferable to trying to reverse-engineer the evidentiary chain of custody. The evidence labels we are referring to mean that, at a minimum, the following information is recorded on them: date and time the evidence was collected, a unique incident number, a unique item number within the incident, who the evidence belonged to before it was collected and where it came from, a complete description of the evidence, who collected the evidence, and who received the evidence from the person who collected it. Additionally, space should be included to record any information pertaining to use or movement of the evidence after it has been collected. This includes information as to where the evidence was moved from, where it was taken, and who removed the evidence, along with the date, time, and reason for moving it.

Once the team has been set up, it is time to drill. Ideally, there is time to drill, based on threats of various levels. Each team member should have the chance to practice his or her roles several times before there is an actual incident. Persons who are responsible for recognizing incidents should have full training with any logging software, intrusion detection devices, and troubleshooting tools that are available on their network. Persons responsible for the gathering of evidence or data should practice creating a clean copy of a hard drive several times before the outcome of an incident hinges upon it.

[1]CIRT is also used interchangeably with the other common acronym, CERT (computer emergency response team). Since every incident may not be an emergency or a crime, I prefer to use the term CIRT just for the sake of logical consistency.




Network Perimeter Security. Building Defense In-Depth
Network Perimeter Security: Building Defense In-Depth
ISBN: 0849316286
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Cliff Riggs

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net