AS 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 one of 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 happen, you shouldn't sit by and let them happen. You have to know how you will respond and the details to this response.
Incident response is not only the act of how you respond to a security incident but also the details involved in that response. 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, something that will have substantial impact on incident response is its potential legal aspect. When a security incident happens, it may frequently fall under the banner of computer or related crimes, so it might require that additional care be taken when responding. When you decide that you wish 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 how you can plan and design a process for responding to that breach in your organization.
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.
It substantially affects the network infrastructure and services, such as performance or security.
It inadvertently provides unauthorized access to any resource.
It 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 impacts the security stance of the organization.
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 the 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 that special care. Responding to an incident of computer crime can be particularly challenging, as the evidence that needs to be collected is intangible.
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.
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 procedures 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 lead for 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 organization, the assets involved, and the overall severity of the situation. Several departments within an organization can work together—human resources, public relations, information 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 security incident and may in fact be informed on only a need-to-know basis.
There are several phases in the incident response process. Each incident will traverse these phases as the incident 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.
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.
As organizations grow in size and importance, it is likely that they will build or already have a group known as an incident response team. These teams will be composed of individuals that 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 professional, 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 will be the initial individuals to respond to an incident when one is 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 and aware of 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.
Table 14-1. Phases of incident response.
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 incident scenario, once the incident response team has evaluated the situation and determined the extent of the incidents, 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 process of 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, 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. The key detail in either case is that the team involved in the investigative process understand how to collect the evidence properly, as the end 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 some 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. In some cases 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. |
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 what 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. |
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 investigate the crime as necessary.
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.
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 through 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.
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 that will be involved in the recovery process, hardware and software inventory, steps to respond and address the outage, and ways to rebuild affected systems.
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 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:
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.
An item that is generally not found too far from 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 availability 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.
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.
Alternate sites are another technique that is 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 in a situation 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 this 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 synchronization 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
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 considered and evaluated.
Before an alternate site can work, however, you need to have a backup that 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 environmental concerns such as 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.
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 steps and relevance of the process, and update it where necessary.
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 organization presumably has been operating at some reduced capacity and 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.
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 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.
If your company has suffered physical—and not conceptual—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 is 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)
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.
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.
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.
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
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
Service level expected by users and the organization
Acceptable downtime and recovery
Type and number of locations involved
Cost of and budget for performing the test
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.
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.
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.
In this type of test, a disaster is simulated in such a way that normal business operations 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.
In this type of test, the complete disaster recovery plan is enacted under simulated conditions. This test will very closely simulate the event of 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 where critical business operations are such that they will not be affected.
Testing must be run in order to ensure that the plan is still effective, but this testing is not a one-time thing and 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.
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.
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 for 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 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 consider scheduled and unscheduled tests for both partial and total disasters.
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 you will also involve special teams or external consultants.
Note
Involvement of those not trained to handle evidence properly can result in evidence that is not adequate to prosecute a crime or is indefensible in court. Typically those who collect evidence from crime scenes are specially trained to do so and have the required experience to do so to ensure that evidence is true and correct and is collected in a way that can be used in court.
Proper collection of evidence is essential and is something that is best left to professionals whenever the need arises. When a crime has been 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 indefensible in court. Trained personnel will know how to avoid these blunders and properly collect everything relevant.
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.
Table 14-2. Types of evidence.
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.
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 computer evidence, like many different types of evidence, may require specific legal authorization to be taken. Requirements will vary depending on the company and situation in question, but it is another item to consider.
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—When presented 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—Evidence that directly relates to the case being tried
Properly identified—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
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 involving other countries in investigating and prosecuting potential computer crimes.
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.
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 requirements 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 where it is necessary to report the incident to local law enforcement in addition to the company officials.
Consider the situations and conditions about when and if 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:
Timeline of the events of the security incident that includes any and all actions taken during the process
Risk assessment that includes extensive details of the state of the system before and after the security incident occurred
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.
Detailed listing of the motivations of 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 designated action.
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 it is usable by all parties. First, a long format report should be prepared that includes specific details and actions that occurred during the security incident. Second, the report should include an executive summary that provides a high-level, short-format description of what occurred.
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 for inappropriate reasons, 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.
Depending on the industry or business an organization works 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 appropriate care when deploying a security solution in a regulated industry and, if necessary, seek legal support to ensure the proper regulations are being followed.
Note
You will need to become familiar with regulations such as the Healthcare Information Portability and Accounting Act (HIPAA) and Sarbanes-Oxley 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.
For the payment card industry, a set of rules exists for incident response. Its Data Security Standard has certain specific requirements for its 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 need to be maintained and used during company operations. Under the banner of due care are guidelines on how to safely use equipment 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 organization needs to ensure that it is always exercising 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, disciplinary 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.
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. Each of the techniques you have learned is intended to prevent or limit the scope of an attack; 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 now becomes one of how to respond to these situations. Incident response is the process of how a security breach will be responded to. Even though security incidents are going to happen, it does not mean that you are powerless—you just have to know how you will respond and the details of that response.
Incident response is not only the act of how you respond to a security incident, but also the details involved in that response. How you respond to an incident is an important detail to have in mind because 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 the concepts of 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 as such will require additional care to be taken when responding. 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 now 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.
Chain of custody
Computer crime
Evidence
Forensics
Incident
Incident response plan (IRP)
_______ used to define mechanisms to keep the business running consistently.
List at least three potential reporting points in an organization. These are people to whom a security incident should be reported.
_______ is a plan that defines the procedures for responding to a security incident.
IRP
DCP
DRP
None of the above
BCP is used to define the process and procedures used to clean up a disaster.
True
False
_______ must be gathered by trained professionals.
What type of evidence gives the most solid proof of a crime?
Corroborative
Circumstantial
Best
Opinion
_______ _______ is used when best evidence cannot be acquired.
Another location from which to conduct business in the event of a disaster is called a(n) _______.