Incident Response Question

Incident Response

A s a security professional, you will be versed in a number of different technologies and techniques, each designed to prevent an attack and secure the organization. Each of the techniques you will learn is meant to prevent

an attack or limit its scope, but the reality is that attacks can and will happen, and the techniques you have learned in this course cannot ever be guaranteed to stop an attack from penetrating your organization. As a security professional, this is a reality that you will have to accept.

Once you have accepted that an attack will inevitably penetrate your organization at some point, your job now becomes knowing how to respond to these situations. This is the role of incident response. Incident response, as the name implies, is the process of how you and your organization will respond to a security incident when it occurs. Although security incidents are bound to occur, you shouldn’t sit by and let them happen. You have to know, in some detail, how you will respond.

Incident response includes those details. If you respond incorrectly to an incident, you could make a bad situation worse. For example, not knowing what to do, whom to call, or what the chain of command is in these situations would potentially do further damage.

Finally, incident response may have a legal aspect. Security incidents are often crimes, and so you must take special care when responding. When you decide to pursue criminal charges, you move from the realm of just responding to performing a formal investigation. The formal investigation will include special techniques for gathering and processing evidence for the purpose of potentially prosecuting the criminal later.

This chapter investigates and examines the various aspects of incident response and ways to plan and design a process for responding to that breach in your organization.

336

14 CHAPTER

Chapter 14 Topics

This chapter covers the following topics and concepts:

• What a security incident is

• What the process of incident response is

• What incident response plans (IRPs) are

• What planning for disaster and recovery is

• What evidence handling and administration is

• What requirements of regulated industries are

Chapter 14 Goals

When you complete this chapter, you will be able to:

• List the components of incident response

• List the goals of incident response

What Is a Security Incident?

A security incident in an organization is a serious event that can occur at any point from the desktop level to the servers and infrastructure that make the network work. A security incident can be anything including accidental actions that result in a problem up to and including the downright malicious. Regardless of why a security incident occurred, the organization must respond appropriately.

A security incident can cover a lot of different events, but to clarify what constitutes a security incident, the following guidelines tend to apply:

• The result is the theft or misuse of confidential information of any type, such as customer information, patient information, or financial information.

• The event substantially affects the network infrastructure and services, such as performance or security.

• The event provides unauthorized access to any resource. • The event provides a platform for launching attacks against a third party.

Other events can and will be included on this list, depending on the organization and the environment in which it functions. For example, a company in the health care field would include additional events that pertain to patient information and unauthorized access to this information. A security incident can be simply thought of as an event or situation that adversely affects the security stance of the organization.

14

Incid ent R

esp o

nse

337

The Incident Response Process

As a security professional, you are responsible for reducing the chance of a security breach or incident to the lowest possible level. However, no matter how hard you try, the reality is that you are only reducing the chance of a security incident, not eliminating it, which is nearly impossible. So as a well-prepared professional, you must plan how you will react when a security incident occurs. This planning will reap benefits, as it will give you an edge when determining what to do after an incident and how to do it. Proper security incident response will determine whether an incident is dealt with swiftly and completely or if it gets worse and out of control.

One of the first things to keep in mind when thinking about incident response is the fact that you are very likely dealing with something that falls under the realm of crime, so it will require special care. Responding to an incident of computer crime can be particu- larly challenging, as the evidence that needs to be collected is intangible.

The concept of investigating a crime versus investigating an incident can be confusing. In reality, there are a couple of points to consider when deciding the best course of action:

• Unless it is a serious crime with effects outside your organization (for example, murder, or the theft of credit card information), you have no legal obligation to involve the police or press charges. Many businesses may opt not to report computer crimes because the fact that they were victimized may lead to bad publicity.

• In case of an incident in which you do want to involve law enforcement, you will follow the rules of evidence. If you think things are moving toward this end, you should not try to handle things internally; instead, opt to let law enforcement professionals deal with the incident.

Computer crime is defined and covered in the legal codes of the United States and other countries with varying degrees of scope and penalties. In the United States, computer crime is covered primarily under U.S. Code Title 18, 1030, titled “Fraud and related activity in connection with computers.” This code is part of the Computer Fraud and Abuse of Act of 1986 and has been amended three times since then: in 1994, 1996, and 2001.

When computer crime involves attacks or activities that cross state or even national borders, the rules can change substantially. The very definition of computer crime can vary widely depending on the jurisdiction involved. Therefore, a computer crime involving more than one jurisdiction will require much more care.

338 PART 3 | Incident Response and Defensive Technologies

Computer crime is defined as a criminal act in which a computer or similar device is involved as either the source or target of an attack. Computer crime can involve any act that affects national security or involves fraud, identity theft, or the distribution of malware. Computer crime does not discriminate against activities that are initiated via the Internet or launched from a private network.

Incident Response Policies, Procedures, and Guidelines The next point that is important when considering incident response is to have a policy in place that defines the procedures and guidelines for responding to a security incident. The policy will define the course of action that a company or organization will take in the time following a security incident. The policy is quite commonly supplemented by proce- dures and guidelines that specify additional details, but the following are usually included:

• The individuals who will take responsibility for determining when and if a security incident has occurred

• The individuals and/or departments that are to be part of the initial notification that a security incident has occurred

• The means through which they will be notified: e-mail, phone, or face to face

• The responsible person or parties that will take the lead in responding to the incident

• Appropriate response guidelines for the given security incident

So, who will be involved in the incident response process? This depends on the organi- zation, the assets involved, and the overall severity of the situation. Several departments within an organization can work together—human resources, public relations, infor- mation technology, corporate security, and others. The idea is to get the appropriate personnel and departments involved in order to properly deal with the situation at hand. These key people can also determine which information can be released and to whom. For example, employees may not be privy to all the details of the security incident and may in fact be informed only on a need-to-know basis.

No less important in this process is the control of information, or “need to know.” The knowledge of an incident in the wrong hands can be catastrophic. Information about a security breach can rattle the confidence of the public, shareholders, employees, and customers, and as such should be tightly controlled wherever possible. The parties that are part of the first response effort will typically be the only ones with definite need to know, with others being added to the list later on.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 339

Phases of an Incident and Response There are several phases in the incident response process. Each incident will traverse these phases as it occurs, evolves, and moves to its final resolution. Every phase has distinct actions that take place within it, which you will learn more about as you move on, but let’s take a high-level look at the incident response process itself. Table 14-1 defines the phases of incident response and what happens at each step.

Incident Response Team As organizations grow in size and importance, it is likely that they will assemble a group known as an incident response team. These teams will be composed of individuals who have the training and experience to properly collect and preserve evidence of a crime and the associated components of the response process. Incident response teams must have both the proper training and the requisite experience to respond to and investigate a security incident. As a security profes- sional, it is very likely that you will take part in this team in some capacity, as a key member or otherwise.

One of the components of incident response is the first responder or responders who answer the call when an incident is first reported. In the broadest sense, these can be the individuals appropriate for the security incident concerned, including the following:

• IT personnel • Legal representation • Leaders from affected departments • Human resources • Public relations • Security officers • Chief security officer

The goal of your security response team is to have in place key people who are well versed in how to deal with security incidents. These members will know what to do and have been drilled on how to do it in the event an incident occurs.

NOTE

Some organizations may add or remove steps in this process based on need or their unique situation, but generally will follow similar steps. The idea is to have a process clearly defined and to know responsibilities ahead of time so when a security incident happens, you know the process to deal with it.

340 PART 3 | Incident Response and Defensive Technologies

TAblE 14-1 Phases of incident response.

Phase DescriPtion

Incident identification

It is important for you to establish early on just what has actually occurred. Is the incident an actual security incident or is it something else? The incident response team will be responsible for making this determination as well as making the determination or discovery as to what was affected.

Triage The next step after the determination that a security incident has occurred is to determine how seriously the incident has affected critical systems or data. Remember that not all systems or services will be affected the same way, and some will require more attention than others. Also remember that some systems are mission-critical and will require more attention as well. In a computer crime scenario, once the incident response team has evaluated the situation and determined the extent of the damage, a triage approach will be implemented, and the situation will be responded to according to criticality. If multiple events have occurred, the most serious event will be addressed first, and remaining events will be investigated based on risk level.

Containment It is necessary early on in the incident response to contain and control the crime scene as much as possible. It is important that no alterations of the crime scene or tampering of any sort occur to avoid damaging evidence. Disconnecting any devices, wires, or peripherals, or even shutting down the system would constitute tampering. It is important to let trained professionals do their job at the crime scene.

Investigation As the response team discovers the cause of the problem, the investigative process can start. The investigation is designed to methodically collect evidence without destroying or altering it in any way. This process can be performed by internal personnel or optionally by an external team where appropriate. It is essential in either case is that the team involved in the investigation understand how to collect the evidence properly, as the result of the process may be to take this collected information to court.

So who may investigate a security incident? This may vary depending on the extent and type of security breach. In some cases, internal teams or consultants may be all that are needed to investigate and analyze a crime scene; however, in other cases that may not be enough. It is possible under certain conditions to get local law enforcement involved in the investigation of a crime.

Of course, this option will vary depending on the skills of local law enforcement. Some police departments are very adept at dealing with computer crime, but this is not always the case.

Investigations should never be taken lightly and once local law enforcement is involved, other issues arise. Police departments may not be able to respond in a timely fashion, as corporate security problems are not part of the police mission and therefore are low priority.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 341

TAblE 14-1 continued

Phase DescriPtion

Analysis and tracking

Evidence that has been gathered is useless unless it is examined and dissected to determine what has occurred. At this point you will either be involving external professionals to examine the evidence or employing your own internal teams. These teams will be responsible for determining which evidence is relevant to the investigation and which is not.

Recovery and repair

During the recovery and repair phase, it is assumed that all relevant evidence has been collected and the scene has been cleaned. At this point the investigation of the security incident has been completed and the affected systems can be restored and returned to service. This process will include restoring and rebuilding operating systems with their applications and data from backups or drive images.

In the event that a system has experienced substantial damage in the course of an attack, it becomes necessary to repair the system. The recovery process is designed to deal with rebuilding a system after evidence has been collected, but it does not account for potential damages done that may need to be repaired. Additionally, the repair process may be needed as the collected evidence may have required the removal of components (that will need to be replaced) for preservation of evidence.

Debriefing and feedback

When it is all said and done, you will need to debrief and obtain feedback from all involved. The incident happened for a reason and presumably at this point you have determined what this reason is. The goal of this phase is to determine what you did right, what you did wrong, and how to improve. The lessons learned during this debriefing can then be used to determine the changes that will be made to improve the incident response process for the next time it is put into effect. Additionally, depending on the incident, it may be necessary to start the process of informing clients and other agencies and regulatory bodies of the breach. This last point may in fact be the most important one, because failure to inform the appropriate regulatory bodies can mean you or your company is guilty of a crime.

342 PART 3 | Incident Response and Defensive Technologies

Incident Response Plans

The composition of the response team is important, but so is the process team members must follow to respond to an incident. Once a security incident has been recognized and declared, it is vital that the team have a plan to follow. This incident response plan (IRP) will include all the steps and details required to inves- tigate the crime as necessary.

The Role of Business Continuity Plans A plan that will become an important part of security in your organization is an item known as a business continuity plan (BCP). This policy defines how the organization will maintain what is accepted as normal day-to-day business in the event of a security incident or other events disruptive to the business. The importance of the BCP cannot be overstated, as it is a necessary item in ensuring that the business continues to perform and can survive a disaster. A BCP ensures protection for vital systems, services, and documents, informing key stakeholders and recovering assets as necessary. The BCP will include issues relating to infrastructure and maintaining the services needed to keep the business running using techniques such as fault tolerance and high availability. Furthermore, because the business requirements change periodically, the BCP will need to be reviewed on a regular basis to ensure it is still relevant.

NOTE

Remember that a security IRP will include all the steps needed to address a security incident and legally protect the company. A security incident that is investigated improperly can result in substantial legal problems for the company.

It is not unheard of for an organization to have no IRP or one that is grossly out of date. In some cases, organizations had a sound security response plan at one point, but it was never updated, resulting in a plan that cannot effectively deal with current situations. In other cases, this plan was overlooked, meaning that no one ever got around to or even thought of creating one in the first place.

A BCP does not dictate how the entire business will be brought back to an operational state; it addresses how to maintain some semblance of business operations. A BCP is designed to ensure that your company continues to deliver on its mission in the event of either a human or natural disaster. Cleaning up and restoring the business in the event of a disaster is the responsibility of a disaster recovery plan (DRP).

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 343

Next to a BCP, and closely intertwined with it, is the DRP. This document or plan states a policy that defines how personnel and assets will be safeguarded in the event of a disaster and how those assets will be restored and brought back to an operating state after the disaster passes. The DRP typically will include a list of responsible individuals who will be involved in the recovery process, hardware and software inventory, steps to respond to and address the outage, and ways to rebuild affected systems.

Techniques That Support Business Continuity and Disaster Recovery There are several techniques that can be used to keep the organization running and diminish the impact of a disaster when it occurs. Several of these techniques are discussed in this section.

Fault tolerance, or the capacity of a system to keep functioning in the face of hardware or software failure, is a valuable tool in your arsenal, as it will give you the ability to weather potential failures while still providing some measure of service. While this level of service may not be optimal, it should be enough to maintain some level of business operations even if not at the normal level of performance. Fault-tolerant mechanisms include service and infrastructure duplication designed to handle a component failure when it occurs.

Common examples of fault-tolerant devices include the following:

• Redundant array of independent disks (RAID)—Provides an array of disks that are configured so that if one disk fails, access to data or applications is not affected

• Server clustering—A technique used to group servers together in such a way that if one server fails, access to an application is not lost

• Redundant power—Can be provided by using systems such as backup generators and uninterrupted power supplies

Another tool in your toolbox is something known as high availability. This technique is simply a gauge of how well the system is providing its service, specifically how available the system actually is. Ideally, a system should be available 100 percent of the time, but in practice this is not possible. High availability simply states, as a percentage, how available a system is, so the closer a system’s availability is to 100 percent, the less time it has spent offline. High availability can be attained by having redundant and reliable backup systems.

Fault tolerance can be applied to just about any service and system available, with the limiting factors being cost and requirements. You will use fault-tolerant mechanisms on those systems and services that are deemed of a higher importance and would adversely affect the business if they were taken offline. In cases where the cost of the fault tolerance systems is higher than the cost of actually losing the service, the use of such systems would be unnecessary.

344 PART 3 | Incident Response and Defensive Technologies

In addition to high availability and fault tolerance is something known as a service level agreement (SLA). This is a document that spells out the obligations of the service provider to the client. Specifically, an SLA is a legal contract that lays out what the service provider will provide, at what performance level, and steps that will be taken in the event of an outage. This document can be very detailed and include specific performance and avail- ability levels that are expected and the associated penalties for not meeting these performance levels. Additionally, it will spell out the parties responsible and the extent of their responsibilities. In the event of a disaster, the individuals listed on the SLA will take care of the problems related to the disaster.

Alternate sites are also used in the event of a system failure or disaster. The idea is to have another location from which to conduct business operations in the event of a disaster. Under ideal conditions, an alternate site is where all operations will be moved if the primary or normal site is no longer able to provide said services.

There are three types of alternate sites that can be utilized by an organization:

• Cold site—This type of site is the most basic type of alternate site and the most inexpensive to maintain. A cold site, by normal definition, does not include backed-up copies of data and configuration data from the primary location. This type of site also does not include any sort of hardware set up and in place. However, a cold site does include basic facilities and power. The cold site is the cheapest option, but it will mean greater outage times as the infrastructure will need to be built and restored prior to going back online.

• Warm site—A warm site is the middle-of-the-road option offering a balance between expense and outage time. A warm site typically has some, if not all, necessary hardware in place with other items such as power and Internet connectivity already established, though not to the degree that the primary site has in place. These types of sites also have some backups on hand, though they may be out of date by several days or even weeks.

• Hot site—A hot site represents the top of the line here. It means little to no downtime but also the greatest expense. These types of sites typically have a high degree of synchro- nization with the primary site up to the point of completely duplicating it. This type of setup requires a high degree of complexity in the form of complex network links and other systems and services designed to keep the sites in sync. This level of complexity adds to the expense of the site, but also has the advantage of substantially reduced (or eliminated) downtime.

NOTE

SLAs are legal contracts and as such can have penalties for being broken. An SLA typically has provisions that penalize the service provider in the event that it does not meet its service obligations. Penalties can include financial penalties or even termination of service for repeated or flagrant violation.

NOTE

Alternate sites played a huge role for companies that were hit by Hurricane Katrina. Some companies that were hit by Katrina suffered huge losses because they did not have alternate sites as part of their disaster planning. Of course, an event like Katrina is rare, but there still exists a potential for such an event; therefore, appropriate steps should be evaluated and implemented.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 345

Before an alternate site can work, however, you need to have a backup. This backup must be kept secure, because it contains information about your company, clients, and infrastructure. Backups should be stored safely and securely, with copies being kept both onsite and offsite to give optimal protection. Additionally, backups should always be stored on their own media and ideally stored in a locked location offsite. Other safeguards should be taken to protect the backups from fire, floods, and earthquakes.

Suitable backup storage locations will depend on the organization’s own requirements and other situations. Recent backups can usually be stored onsite, with older archival copies stored someplace offsite. The offsite location is used in the event that the primary site suffers a major event that renders systems and data residing there either unusable or inaccessible.

Recovering Systems Your BCP and DRP will spell out the process for recovering data, systems, and other sensitive information. Secure recovery requires a number of items to be in place, primary among which is the requirement to have an administrator designated to guide the recovery process. As with any backup and recovery process, steps should be taken to review the details and relevance of the process, and to update it where necessary.

Recovering From a Security Incident When security incidents happen, and they will happen, you have to have a plan to restore business operations as quickly and effectively as possible. This requires that you and your team correctly assess the damage, complete the investigation, and then initiate the recovery process. During the time from the initial security incident onward, the organi- zation presumably has been operating at some reduced capacity; you need to recover the systems and environment as quickly as possible to restore normal business operations. Other key details are the definite need to generate a report on what has happened and the ability to communicate with appropriate team members.

Loss Control and Damage Assessment Early on, an assessment needs to be performed in order to determine the extent of damages and expected outage or downtime. During this phase, efforts are moving toward damage control.

Some steps you can expect to follow during the damage assessment are:

• The first responder may assess the area of damage to determine the next course of action.

• You should determine the amount of damage to the facility, hardware, systems, and networks.

• If your company has suffered virtual—rather than physical—damage, you may need to examine log files, identify which accounts have been compromised, or identify which files have been modified during the attack.

346 PART 3 | Incident Response and Defensive Technologies

• If your company has suffered physical—and not virtual—damage, you may need to take a physical inventory to determine which devices have been stolen or damaged, which areas the intruder(s) had access to, and how many devices may have been damaged or stolen.

• One of the most important and overlooked components of damage assessment is to determine whether the attack is over. Attempting to react to an attack that is still in progress could do more harm than good.

Inside the organization, it is important to determine to whom to report security incidents. This should be someone who has accountability and responsibility for safeguarding the organization’s assets. These individuals can be different depending on the organization, but each of them will ultimately have accountability for security within the organization. The following is a list of potential reporting points in the organization:

• Chief information security officer (CISO) • Information security officer (ISO) • Chief security officer (CSO) • Chief executive officer (CEO) • Chief information officer (CIO) • Chief operating officer (COO)

Business Impact Analysis When working with incident recovery and analysis, an important part of the process is the business impact analysis (BIA). This term covers the process of analyzing existing risk and using various strategies to minimize said risk. The outcome of this process is a BIA report that covers all the potential risks uncovered and their potential impact on the organization. The BIA should go a long way toward illustrating the impact of any loss to the organization in which systems are integrated and rely on each other in increasing amounts.

In the context of the overall disaster recovery and planning, the BIA is used to illustrate the costs of a failure. For example, a BIA will demonstrate costs such as:

• Work backlogs • Profit/loss • Overtime • System repair and replacement • Legal fees • Public relations • Insurance costs

A BIA report emphasizes the importance of each of the various business components and proposes fund allocation strategies to protect them.

NOTE

The ultimate goal of having an individual who is charged with the overall responsibility for security in the organization is to have leadership and legal accountability.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 347

Planning for Disaster and Recovery

In order to properly plan for disaster recovery, you will need to know where you stand (specifically where the company stands). You need to completely assess the state of preparedness of the organization and then you can understand what to do in order to be properly prepared.

In order to properly plan for disaster recovery, the following guidelines and best practices should be observed:

• Always consider and evaluate the proper redundancy measures for all critical resources. Look for adequate protection for systems such as servers, routers, and other devices in case they are needed for emergency usage.

• Check with all critical service providers to ensure that adequate protection has been taken to guarantee that the services provided will be available.

• Check for the existence of or the ability to obtain spare hardware wherever necessary. Ensure that the devices not only are appropriate for use but also can be obtained in an emergency.

• Evaluate any existing SLAs that are currently in place so that you know what constitutes acceptable downtime.

• Establish mechanisms for communication that do not require company resources (as they may be unavailable). Such communication channels should also take into account that power may be unavailable.

• Ensure that the organization’s designated alternate site can be accessed immediately.

• Identify and document any and all points of failure, as well as any up-to-date redundancy measures that have been put in place to safeguard these points.

• Ensure that the company’s redundant storage is secure.

Testing and Evaluation A plan can be well thought out and account for seemingly everything, but the reality is that unless it is periodically tested and retested, you can never tell just how effective or relevant it may be. Testing is the process through which a plan has its effectiveness measured and evaluated. When a plan is tested, care should be taken to ensure that the processes involved work as designed and intended.

Even if a plan is properly evaluated and tested, it must be reviewed regularly, as times change and the plan must adapt. Some of events that can affect or diminish the overall strength of a plan include:

• Situational and environmental changes that are introduced as an organization evolves to take on new roles and challenges

• Change of equipment due to upgrades and replacements • Ignorance about or lack of interest in updating the plan • New personnel who have no interest in or knowledge of the plan

348 PART 3 | Incident Response and Defensive Technologies

These points plus others necessitate the regular testing and evaluation of a plan in order to prevent its obsolescence. When a plan is tested, special attention should be placed on the plan’s strengths and weaknesses, including:

• Is the plan feasible and is it a viable recovery and repair process? • Are backup facilities adequate for the environment? • Are adequate human resources allocated to the process, and are these teams

properly trained? • Where are the perceived or real weaknesses in the current process? • Are teams properly trained to deal with the recovery process? • Can the process, as designed, carry out the tasks assigned to it?

Because incident response and the plans that go with it sometimes require special skills, training may be required for all parties and teams involved. The range of special skills is large, with extra training required for tasks that involve:

• System recovery and repair • Fire suppression • Evacuation of personnel • Backup procedures • Power restoration

For the test to verify the effectiveness of a plan, it is necessary to simulate as closely as possible the real conditions under which the plan will operate. In order to do this, consider the following factors:

• The actual size of the installation • Data processing services and their sensitivity to failure • The service level expected by users and the organization • Acceptable downtime and recovery • The type and number of locations involved • The cost of and budget for performing the test

Preparation and Staging of Testing Procedures Performing the right test on your plan will ensure accurate and appropriate results that are the most useful to you. Testing suites that can be performed on a plan include:

• Walkthrough • Checklist • Simulation • Parallel • Full interruption

Each test offers unique benefits that give it the ability to reveal different and sometimes more accurate results.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 349

Structured Walkthrough In this type of test, members of the disaster recovery team get together around a table and read through the plan together. The goal is to read through the steps and note how each department gets responsibilities handed off to it and how it interacts. This type of test will uncover potential gaps and bottlenecks in the response.

Checklist This type of test will assist in verifying that sufficient supplies are stored and available at the backup site, contact information is current, and the recovery plan is accessible and available to all who need it in an emergency. The recovery team should review and identify weak areas but also resources that are available.

Simulations In this type of test, a disaster is simulated in such a way that normal business opera- tions are not adversely affected. The test will seek to simulate a disaster as accurately as practical given the budget and situation. Features of this test include practicing backup and restore operations, incident response, communication and coordination of efforts, alternative site usage, and other similar details. Tasks or processes that cannot be economically or practically completed should be omitted where necessary, including travel requirements, taking down key systems, and involvement of certain teams.

Full Interruption In this type of test, the complete disaster recovery plan is enacted under simulated conditions. This test will very closely simulate a disaster, including the simulation of damage to systems such as communications and other services.

Due to the fact that this type of test interrupts services and the organization itself, extreme caution should be exercised to avoid a major impact on the organization. Ideally, this type of test should be scheduled during slow periods, at the end of the month, after business hours, or at any point when critical business operations are such that they will not be affected.

Frequency of Tests Testing must be run in order to ensure that the plan is effective, but this testing is not a one-time thing. It should be run on a regular basis to ensure that the plan remains effective. Tests should be considered and run as often as is practical—for example, quarterly, semiannually, or annually.

Analysis of Test Results The purpose of all this testing is to provide data on how well a plan is working. Personnel should log events during the test that will help evaluate the results. The testing process should provide feedback to the disaster recovery team to ensure that the plan is adequate.

350 PART 3 | Incident Response and Defensive Technologies

The recovery team, which normally consists of key management personnel, should assess test results and analyze recommendations from various team leaders regarding improvements or modifications to the plan. It is essential to quantitatively measure the test results, including:

• Elapsed time to perform various activities • Accuracy of each activity • Amount of work completed

The results of the tests will most likely lead to changes in the plan. These changes should enhance the plan and provide a more workable recovery process. Testing the disaster recovery plan should be efficient and cost effective. It provides a means of continually increasing the level of performance and quality of the plan and of the people who execute it. A carefully tested plan provides the organization with the confidence and experience necessary to respond to a real emergency. Disaster recovery plan testing should involve scheduled and unscheduled tests for both partial and total disasters.

Evidence Handling and Administration

Once the incident response process has been defined at a high level, it is time to turn your attention toward the collection of evidence from a crime scene. Although you may be involved in this process, it is possible that it will also involve special teams or external consultants.

Evidence Collection Techniques Proper collection of evidence is essential and is something that is best left to professionals whenever the need arises. When a crime is suspected, it may become necessary to expand the incident response to include trained professionals in the process. The process here is really one of forensics, or the methodical and defensible process of collecting information from a crime scene. This is a process best left to those professionals trained to do it, because novices can inadvertently damage evidence in such a way that makes the investigation impossible or the case indefensible in court. Trained personnel will know how to avoid these blunders and properly collect everything relevant.

Evidence Types Not all evidence is created equal and should not be treated as such because evidence is what ultimately proves your case. Collecting the wrong evidence or treating evidence incorrectly can have an untold impact on your case, which should not be underestimated.

Table 14-2 lists some of the different types of evidence that can be collected and what makes each unique.

NOTE

Involvement of those not trained to handle evidence properly can result in evidence that is not adequate to prosecute a crime or that is indefensible in court. Typically, those who collect evidence from crime scenes are specially trained to do so and have the required experience to ensure that evidence is true and correct and is collected in a way that can be used in court.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 351

TAblE 14-2 Types of evidence.

eviDence DescriPtion

Best Best evidence is a category of evidence that is admissible by requirement in any court of law. In the case of documents, best evidence is the original document. The existence of best evidence eliminates your ability to use any copies of the same evidence in court.

Secondary Secondary evidence is any evidence that is a copy of the original evidence. This could be items such as backups and drive images. This type of evidence may not always be admissible in a court of law and is not admissible if best evidence of the item exists.

Direct Direct evidence is evidence that is received as the result of testimony or interview of an individual regarding something he or she directly experienced. This individual could have obtained the evidence as a result of observation. Evidence in this category can prove a case.

Conclusive Conclusive evidence is evidence that is above dispute. Conclusive evidence is considered so strong that it directly overrides all other evidence types by its existence.

Opinion Evidence that of this type is derived from an individual’s background and experience. Opinion evidence is divided into the following types:

• Expert—Any evidence that is based upon known facts, experience, and an expert’s own knowledge.

• Non-expert—The opinion evidence of non-experts is limited to that based upon the witness’s perception of a series of events where that perception is relevant to the case.

Corroborative Evidence in this category is evidence that is obtained from multiple sources and is supportive in nature. This type of evidence cannot stand on its own and is used to bolster the strength of other evidence.

Circumstantial Circumstantial evidence is any evidence that indirectly proves a fact through the use of deduction.

352 PART 3 | Incident Response and Defensive Technologies

Chain of Custody When collecting evidence for use in court, the chain of custody must be maintained at all times. The chain of custody is simple in theory, as it documents the whereabouts of the evidence from the point of collection to the time it is presented in court and after, when it is returned to its owner or destroyed. The chain is essential as any breaks or question about the status of evidence at any point can result in a case being thrown out. A chain of custody will need to include every detail about the evidence such as how it was collected up to how it was processed.

A chain of custody can be thought of as enforcing or maintaining six key points at any point. These points will ensure that you focus on how information is handled at every step.

Chain of custody should always maintain these six points by asking the following questions:

• What evidence has been collected? • How was the evidence obtained? • When was the evidence collected? • Who are the individuals who handled the evidence? • What reason did each person have for handling the evidence? • Where has the evidence traveled and where was this evidence ultimately stored?

Also remember to keep the chain of custody information up to date at all times. Every time any evidence is handled by an investigator, a record must be kept and updated to reflect this. This information should explain every detail such as what the evidence actually consists of, where it originated, and where it was delivered. It is important that no gaps exist at any point.

Additionally, for added legal protection, evidence can be validated through the use of hashing to prove that it has not been altered. Ideally, the evidence you collected at the crime scene is the same evidence you present in court.

Remember, lack of a verifiable chain of custody is enough to lose a case.

Computer Removal When any sort of computer crime is logged and reported, it becomes necessary to examine the system and in some cases remove the computer from the crime scene. Of course, such a seizure of a computer means that the chain-of-custody requirements come into play and the system must be tagged and tracked up until it is presented in court.

Also, do not forget that collecting computer evidence, like many different types of evidence, may require specific legal authorization. Requirements will vary depending on the company and situation in question, but it is another item to consider.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 353

Rules of Evidence No evidence, no matter the type, is necessarily admissible in court. Evidence cannot be presented in court unless certain rules are followed. These rules should be reviewed ahead of time. The rules of evidence presented here are general guidelines and are not consistent across jurisdictions.

The following list includes the five commonly accepted rules of evidence:

• Reliable—This is consistent and leads to a common conclusion.

• Preserved—Chain of custody comes into play, and the records help identify and prove the preservation of the evidence in question.

• Relevant—This is evidence that directly relates to the case being tried.

• Properly identified—This is evidence in which records can provide proper preservation and identification proof.

• legally permissible—Evidence that is deemed by the judge to fit the rules of evidence for the court and case at hand.

Chain of Custody Key in Bonds Case

While not related to computer crime, this article demonstrates the concept of chain of custody and how it can call a case into question:

Before the federal government attempts to convince a jury that Barry Bonds lied under oath when he denied he knowingly used steroids, prosecutors face another challenge: proving the drug tests which were positive for steroids belong to baseball’s home run king and that the test results are reliable and relevant to the perjury trial set to begin March 2.

Bonds’ defense team is expected to press the issue and ask Judge Susan Illston to throw out the evidence in pretrial motions due Thursday. Illston will have to weigh evidence the government seized in its 2003 raid of BALCO against the following facts:

• No one saw Bonds urinate into a container when he provided samples that allegedly tested positive for steroids.

• Bonds never signed anything that authenticated the urine samples that tested positive for steroids were his.

In this case, not having definite proof of where the evidence came from or a way to authen- ticate the evidence could have an impact on the case as the chain of custody is broken.

Source: Yahoo! Sports

NOTE

Evidence laws and types will vary based on the jurisdiction and case involved. The rules presented here are appropriate for the United States, but you can expect variations of the rules when other countries are involved in investigating and prosecuting potential computer crimes.

354 PART 3 | Incident Response and Defensive Technologies

Security Reporting Options and Guidelines When considering the reporting of a security incident, it is important to be aware of the structure and hierarchy of a company. The overall structure of reporting can have a huge impact on how things operate in the event of a security incident. Additionally, making individuals aware of this structure ahead of time is of the utmost importance so there is no confusion when the time comes to report an incident.

Reporting a Security Incident Once an incident has been responded to and a team has gotten involved to assess the damage and start the cleanup, the required parties will need to be informed. These parties will be responsible for getting the ball rolling whether it is legal action, investigative processes, or other actions as necessary.

When considering how to report a security incident, the following guidelines are worth keeping in mind and can prove helpful at the time of crisis:

• Wherever feasible, refer to previously established guidelines as documented and described in the company IRP. The IRP should include guidelines on how to create a report and whom to report to. Furthermore, the IRP should define the formats and guidelines on how to put the report together in order to ensure that the information is actually usable by its intended audience.

• Consider the situations in which it is necessary to report the incident to local law enforcement in addition to company officials.

• Consider the situations and conditions in which the security incident must be reported to regulatory bodies as required by law.

• Security incidents reported outside the organization can and should be noted in the company incident report.

During the preparation of a security incident report, include all the relevant information to detail and describe the incident. At a minimum, the following items should be included:

• A timeline of the events of the security incident that includes any and all actions taken during the process.

• A risk assessment that includes extensive details of the state of the system before and after the security incident occurred.

When generating a report, avoid the temptation to use flowery or overly technical language because the individuals who will eventually read the report may not be technically savvy. While technical information and jargon are helpful to some, you won’t always know what the skill and knowledge level of the audience will be. Language that is overly technical or filled with jargon can be included, but relegated to an appendix in the report.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 355

• A detailed list of any and all participants who took part in the discovery, assessment, and final resolution (if this has occurred) of the security incident. It is important to include all those who took part in this process regardless of how important or unimportant their roles may be perceived to be.

• A detailed list of the reasons behind the decisions that were made during the process. Document these actions in a format that states what each action was and what factors led to the decision to take the action.

• A recommendation as to what could be done to prevent a repeat of the incident and what could be done to reduce any damage that may result.

• Two sections to ensure that the report is usable by all parties: first, a long- format report that includes specific details and actions that occurred during the incident, and second, an executive summary that provides a high-level, short-format description of what occurred.

Affected Party Legal Considerations One of the biggest concerns you will have to face is inappropriate use of resources such as e-mail and Internet access. Employees have been known to use company resources for all sorts of activities, both work related and otherwise, some of which can result in problems for someone. The question is who. When an individual uses company resources inappropriately, the question becomes who is held liable: the company or the employee or both. It also brings up the question of what each party’s rights are.

Protecting information is also important when considering the individuals involved. Not every issue will be one of employee versus company; other variations exist and their requirements will vary.

The scenario of liability has been played out numerous times in companies over the years, with organizations becoming the victim of legal actions because of the actions of an employee. For example, some companies have been the subject of legal action due to an employee using a company account to post hate speech or other comments. Other examples have seen companies become the subject of legal action due to an individual browsing pornographic content at work and offending a coworker who promptly files a harassment lawsuit.

Stating what is and is not appropriate use of resources can provide the company some measure of protection against these scenarios.

356 PART 3 | Incident Response and Defensive Technologies

Customers With respect to customers, the issues are as follows:

• What data is considered private, what is considered public, and how does each need to be protected?

• What does a company need to do to protect customer information both professionally and legally?

Business Partners With regard to business partners, the following should be considered:

• Who is responsible for the liability of data that is stored in one location and processed in another?

• Who is responsible for the necessary security and privacy of data transmitted to and from an organization and a business partner?

Requirements of Regulated Industries

Depending on the industry or business an organization is in, additional legal requirements may need to be considered when protecting information. A business that is part of the utility, financial, or health care industry should expect regulations to come into play that dictate data protection needs and other requirements. The security professional should exercise appro- priate care when deploying a security solution in a regulated industry and, if necessary, seek legal support to ensure the proper regulations are being followed.

Payment Card Industry Data Security Standard For the payment card industry, a set of rules exists for incident response. The Payment Card Industry Data Security Standard (PCI DSS) has certain specific requirements for organizations’ incident response plans.

Organizations must verify that their IRP describes the following:

• Roles, responsibilities, and communication strategies in the event of a compromise

• Coverage and responses capabilities for critical systems and their components

• Notification requirements for credit card associations and acquirers

• Business continuity planning

• Reference or inclusion of incident response procedures from card associations

• Analysis of legal requirements for reporting compromises (for example, California Bill 1386)

There are several terms you should remember that will ensure that you are doing what is necessary to protect yourself. “Due care” is a policy that describes and dictates how assets

NOTE

You will need to become familiar with regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes- Oxley Act to make sure that you are meeting legal obligations. For example, HIPAA is a set of guidelines that will directly affect you if your company is in the health care industry.

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 357

As a security professional, you are expected to be versed in a variety of different technologies and techniques, each designed to prevent an attack and secure the organization. However, you must accept the fact that attacks are going to happen, and some may be successful despite your best efforts. As a security professional, breaches of your security perimeter and defenses are a reality that you will have to accept.

After you have accepted that an attack will penetrate your defenses at some point, your job becomes knowing how to respond to these situations. Incident response is the process of responding to a security breach. Security incidents are going to happen, but you are not powerless—you just have to know, in some detail, how you will respond.

Responding incorrectly to an incident could result in making a bad situation worse (for example, not knowing what to do, whom to call, or what the chain of command is in these situations).

Finally, something that will have substantial impact on incident response is the potential legal aspect. Exercising due care, due diligence, and due process is absolutely essential. When a security incident happens, it typically falls under the banner of computer crimes and requires additional care in the response given. The deployment of special teams trained in techniques such as forensics will be absolutely essential to get right. When you respond to a security incident that has gone to this level, you are moving from the realm of just responding to performing a formal investigation. The formal investigation will include special techniques for gathering and processing evidence for the purpose of potentially prosecuting the crime later.

CHAPTER SUMMARY

need to be maintained and used during company operations. Under the banner of due care are guidelines on how to use equipment safely in line with approved company guidelines.

Next is the concept of due diligence, which is the process of investigating any and all security incidents and related issues pertaining to a particular situation. An organi- zation must exercise due diligence to make sure its policies are effective and stay effective. An organization also needs to exercise due diligence to make sure that no violations of laws or regulations are occurring.

Finally, due process references a key idea that when a policy or rule is broken, disci- plinary measures are followed uniformly and employees are not considered guilty until they have been given proper process. Due process ensures that policies are applied uniformly to all employees regardless of who they are or other factors so as to respect their civil rights and to protect the company from potential lawsuits later.

358 PART 3 | Incident Response and Defensive Technologies

1. ________ is the capacity of a system to keep functioning in the face of hardware or software failure.

2. List at least three potential reporting points in an organization. These are people to whom a security incident should be reported.

3. A(n) ________ is a plan that defines the proce- dures for responding to a security incident.

A. IRP B. DCP C. DRP D. None of the above

4. BCP is used to define the process and procedures used to clean up after a disaster.

A. True B. False

5. ________ must be gathered by trained professionals.

6. What type of evidence gives the most solid proof of a crime?

A. Corroborative B. Circumstantial C. Best D. Opinion

7. ________ ________ is used when best evidence cannot be acquired.

8. Another location from which to conduct business in the event of a disaster is called a(n) ________.

CHAPTER 14 ASSESSMENT

Chain of custody Computer crime Evidence

Forensics Incident Incident response plan (IRP)

KEY CONCEPTS AND TERMS

14

Incid ent R

esp o

nse

CHAPTER 14 | Incident Response 359