SYSTEM FORENSICS HELPS REDUCE THE OCCURRENCE of security incidents. It also helps minimize the impact of incidents that do occur. A forensic analyst examines how an attack is perpetrated and then develops controls to prevent or mitigate that form of attack. For example, the early Secure Sockets Layer (SSL) protocol safeguarded Internet sessions. However, it was vulnerable to man-in-the-middle attacks. Forensic analyses led to changes in SSL to eliminate this vulnerability.
To prevent and mitigate security incidents, an organization must establish formal incident prevention and intrusion response plans. You write these formal plans using an analytical framework. They should include incident response protocols. They should also assign responsibility for incident prevention and response. This chapter discusses these important forensic investigation processes.
Many organizations learn about incident response only after experiencing an attack. This approach has some benefits but is costly and disruptive to the organization. For maximum impact, incident prevention and response should be a planned part of an overall risk mitigation strategy.
Successful incident response has two components:
Prevention—An organization must have procedures to minimize the potential for incidents to occur.
Incident response—An organization must be able to react to an incident in a manner that reduces its impact and restores normal operations as quickly as possible.
Of the two components, prevention is the most cost-effective and provides the highest return on investment (ROI). Incident response, however, gets more coverage both within and outside an organization. For example, for years, oil tankers brought oil from Alaska for transfer to the "lower 48". The tankers delivered their cargo without recognition or notice, following controls and safety protocols to navigate the narrow channels without incident. One tanker failure eliminated the years of hard work and dedication by people who had made so many successful oil deliveries routine. That tanker failure also resulted in billions of dollars in cleanup costs and disruption to the lives of individuals affected by the oil spill.
Relating a computer failure to an oil tanker spill might seem like overkill. The reality, however, is that in today's digital world, a computer incident might result in damage and disruption that far exceeds the cost of an oil spill. A successful attack on the electric grid, for example, could cost billions in lost business and disruption, including loss of life. A successful attack on a bank could result in billions of dollars in losses. A successful attack on a navigation system could put more than one tanker "on the rocks."
A basic rule of incident prevention and response is to plan for the worst, test the plan fully, and react to the incident. This rule is based on the assumption that if you plan and test your plan for the worst situation, you will be better prepared to block an attack and mitigate its potential effects when it does occur.
It is impossible to prevent all security incidents. In most cases, it's not even cost-effective to implement all possible security measures. Some incidents result from intentional attacks. Others result from unintentional actions of system users and maintainers. Thus, the goal should be zero incidents. However, although an organization might minimize the number of incidents, the probability of a disruptive event will never be zero.
Given that the potential for a disruptive security event will never be zero, an organization should strive to minimize the potential impact of a security event. Take the following measures to help minimize the number and impact of security incidents in your organization:
Establish and enforce security policies and procedures—Many security incidents are accidents. They may result from information technology (IT) personnel not following or not understanding system operating procedures and controls. IT personnel may make mistakes with change management procedures, system security configurations, or user authentication and privilege assignment. Your policies and procedures should be practical and clear. They should also provide the appropriate level of security. In addition, put metrics in place to determine whether personnel are complying with your security policies.
Gain management support for security policies and incident handling—Senior management should demonstrate this support with approval of reasonable budget requests. Managers should also be vocal in supporting compliance enforcement procedures.
Routinely assess vulnerabilities in the environment—A security specialist with the appropriate clearance and access to sensitive data should perform these assessments. The security specialist should also have no direct responsibility for correcting the deficiencies identified. Individuals who must both identify and correct deficiencies may not identify all deficiencies. They may make tradeoffs based on their assessment of whether management will approve the resources needed for correction. Specialists who are not responsible for remediation tend to identify more risks.
Keep systems up to date and routinely check all computer systems and network devices—Regularly audit systems to ensure that they have all the latest patches. In some situations a patch has the potential to cause more damage than the risk of the patched vulnerability. In this case, organizations use waivers to document why they haven't deployed a patch.
Train IT personnel—Security threats are constantly changing. The only way to ensure that IT staff can stay protected against newer threats is to train them on what they are. Additionally, IT staff need training on how to use recently purchased controls and countermeasures. A brand new sophisticated intrusion protection system isn't useful if it stays in the box.
Train end users—Social engineering is a common tactic in which attackers trick users into giving up valuable information, such as their username and password. The primary reason social engineering succeeds is due to a lack of security awareness by end users. A little training can go a long way.
Implement and enforce a password policy—A password policy will ensure that personnel use strong passwords, and that they change them regularly. You can easily enforce password policies with tools, such as Microsoft Group Policy or third-party tools.
Monitor network traffic—Significant changes in network traffic may indicate a problem. For example, if a worm infects your network, network traffic may increase resulting in decreased performance. If you catch this before it's serious, you may be able to contain the threat. An anomaly-based intrusion detection system (IDS) can automate this process. You start by creating a baseline of normal activity. The IDS then monitors for any changes and sends an alert if the change exceeds a certain threshold.
Review logs—Logs are regularly recording activity that can let you know of a potential issue before it's a serious problem. However, they must be reviewed. Operating systems have logs. Additionally, services and applications, such as firewalls and IDS, all have logs that you can readily review. Either manually review the logs or purchase a third-party tool to automate the review. Most automated tools are preconfigured to look for specific events, and you can modify them to look for other events. They then send an alert to notify administrators of the potential issue.
Implement and test a backup policy—A backup policy identifies what data to back up, how often, and how long to keep the backups. Conduct backups regularly but base the actual frequency on how often the data changes, and how important it is. A test restore attempts to restore the backups to verify that backup and restore procedures are sound.
An event is any observable occurrence within a system or network. This includes any activity on the network, such as when a user accesses files on a server or when a firewall blocks network traffic. Adverse events are events with a negative result or negative consequences. Attacks on systems are adverse events. Adverse events in this book are events that are computer-security related. They are not events caused by sources, such as natural disasters and power failures.
A computer security incident is any event that violates an organization's security policies. This includes computer security policies, acceptable use policies, or standard security practices. The following are examples of computer security incidents:
Denial of service (DoS) attacks—A DoS attack could result from an attacker sending specially crafted packets to a Web server that cause it to crash. It could also result from an attacker directing hundreds of external compromised workstations to send many Internet Control Message Protocol (ICMP) requests to an organization's network. When the attack is from multiple sources, you refer to it as a distributed DoS (DDoS) attack.
Malicious code—Malicious software, or malware, is any malicious code, such as viruses, worms, and Trojans. For example, a worm uses open file shares to quickly infect hundreds of systems in an organization. Employees may innocently introduce viruses into a network from their home computer on USB thumb drives. When they plug the USB drive into the work computer, the virus infects it.
Unauthorized access—This includes any time someone accesses files they shouldn't be able to access. The access can be from someone within the organization, such as an employee, or from an external attacker. If you don't lock down shared files with appropriate permissions, users may stumble upon data they shouldn't see. If you don't secure databases used by Web servers, attackers may be able to access sensitive customer data, such as credit card information, from anywhere on the Internet.
Inappropriate usage—Inappropriate usage could take a number of forms. For example, a user might provide illegal copies of software to others through peer-to-peer (P2P) file-sharing services. This same P2P software could cause data leakage resulting in private data from the user's computer being shared on the Internet to anyone else using the same P2P software. Or a person might threaten another person through e-mail.
An incident response team (IRT) is a group of people who respond to incidents. You can form an IRT as needed in response to an incident. You can also designate one in advance. For example, a small organization may not have a formal IRT. Instead, when an incident occurs, IT professionals respond to the incident as an informal IRT. However, a large organization may have a group of security professionals designated as the IRT.
When an organization sets up an IRT in advance, it ensures the team has the necessary knowledge and skills to respond to incidents. This helps minimize the impact of incidents. Additionally, when a team forms in advance, some team members can be full-time security professionals and work proactively to minimize the occurrence of incidents.
For example, these security professionals can regularly monitor the network for anomalies, since changes in network behavior may indicate a security breach. They can keep up to date with emerging threats, and regularly perform vulnerability assessment and penetration testing.
An incident response team must be equipped to handle incidents. Team preparation includes the following:
Training on the proper use and location of security tools—An organization should preconfigure portable computers with all the tools a team will need during an incident. The IRT should be familiar with the systems and tools before an incident occurs. Properly protect these systems and associated tools when not in use.
Assembling relevant communication information—An organization should have the names and phone numbers of people in the organization who should be notified of an incident. This includes members of the incident response team and those in charge of media relations. The organization also needs details about its Internet service provider (ISP), backup storage provider, and any support contractors. The organization should also know how to contact local and national law enforcement agencies. The organization's legal counsel must be informed of any contacts with law enforcement.
Placing all appropriate system information in an accessible location—When a serious incident occurs, the IRT needs access to system information. This includes administrative passwords, network layout diagrams, and router and firewall configuration information. If the team has to search for this information, the incident can cause more damage during the search. The longer the team has to search for this information, the longer the incident has to cause damage. The team needs to secure this very valuable information as well. If the information is in a physical form, such as a binder, keep it in a secure place such as a safe. If it's in an electronic format, such as on a portable computer, safeguard it with permissions and encryption. Additionally, make it clear who is authorized to access this information. For example, the organization may decide that only the incident response team leader, the chief information officer (CIO), chief information security officer (CISO), and chief technology officer (CTO) can access the information.
The incident response team membership and structure depends on the type of organization and its risk management strategy. The incident response team should generally form part or all of an organization's security team. The team's members should include security professionals, network specialists, application maintainers, representatives of the user community, and senior managers. The incident response team should also be responsible for coordinating a response to any incident.
Note
The number of members on the incident response team typically depends on the organization's size and complexity. Scale the team to individual incidents.
A successful incident response team has several key members:
Team leader—The team leader is generally responsible for the activities of the incident response team. The team leader coordinates reviews of the team's actions. If needed, he or she implements changes in policies and procedures for dealing with future incidents.
Incident lead—The incident lead is responsible for a particular incident or set of related security incidents. This could be the team leader or someone else who may have expertise more relevant to an incident. The incident lead is the focal point for all communications related to the incident. Team members report to the incident lead and the incident lead speaks for the team.
IT team members—Team members assist the team leader and/or incident lead in responding to incidents. Team members have expertise in specific IT areas and not all team members will necessarily respond to all incidents.
Specialists—In addition to the primary team members, a team identifies specialists who respond to particular incidents or provide input to the team. These specialists may come from different departments in the organization. Table 13-1 lists some specialist team members and their responsibilities.
In the event of an incident, the incident response team should coordinate a response and communicate with the associate members of the incident response team. Table 13-2 shows the responsibilities of these individuals during the incident response process.
Table 13-1. Incident response team specialists.
TEAM MEMBER | RESPONSIBILITIES |
|---|---|
Many incidents have legal ramifications and need the expertise of a lawyer who understands established incident response policies. The lawyer provides advice on an organization's legal liabilities. He or she provides advice on steps to take before, during, and after an incident if attackers will be prosecuted. | |
Communicating effectively to the media is extremely important during a crisis. An organization may be doing all the right things internally, but if the wrong message is communicated externally, then this affects the organization's image and reputation. This can translate to loss of a company's stock value and reduced sales to customers. The public relations officer crafts the message to the media based on management objectives. | |
When internal employees are the cause of an incident, the HR representative can advise the team on proper methods for communicating and dealing with the employees. HR reps are experts on HR policies, disciplinary procedures, and employee counseling. | |
Management | Department managers may be a part of the team if the incident directly affects their department. These managers can ensure that the team has adequate resources to respond to the incident. |
Table 13-2. Responsibilities of incident response team members during the incident response process.
ACTIVITY | INCIDENT LEAD | IT TEAM MEMBER | LEGAL REPRESENTATIVE | PR REPRESENTATIVE | MANAGEMENT |
|---|---|---|---|---|---|
Assess | Advise | None | None | None | |
Initial response | Respond | Implement | Update | Update | Update |
Collect forensic evidence | Implement | Advise | Owner | None | None |
Implement temporary fix | Implement | Implement | Update | Update | Advise |
Advise | Advise | Advise | Implement | Implement | |
Check with local law enforcement | Update | Update | Implement | Update | Implement |
Implement permanent fix | Implement | Implement | Update | Update | Update |
Determine financial impact on business | Update | Update | Advise | Update | Advise |
An incident response plan outlines specific procedures to follow in the event of a security incident. It identifies the responsibilities of all members of the team. It also identifies the specific reporting requirements for an incident. Although the team members should be intimately aware of the details of the incident response plan, it's important that all IT staff know the procedures for reporting incidents. For example, if members of the IT staff discover an incident, they should know exactly what to do to raise the alarm.
The incident response plan also identifies the steps to take when an incident occurs. A plan could include the following steps:
Assessment—Not all events are incidents, and some incidents are more serious than others. The initial assessment verifies the event is an incident and assesses the severity. An IT staff member can carry this out.
Communication—The incident is reported to the incident response team. The plan identifies whom to notify based on the initial assessment.
Containment—The team contains the incident to minimize the damage and risk to other systems. For example, if malware has infected a system, the team can remove the network cable to contain the damage to this system alone. It's important to ensure that the team protects evidence for use in court later if necessary.
Evaluation—The team investigates the incident to determine the type and severity. It may take additional steps, depending on the business and the incident. For example, if the incident resulted in the loss of customer data, the company may be legally responsible to report it to the affected customers.
Recovery—The incident response team recovers and restores systems. This may be as simple as rebooting the system or may require an extensive rebuild.
Document and review—Every incident has lessons that the team can learn by evaluating what happened and how the response progressed. Documentation records the details. Later, a review can identify areas to improve. For example, the team could update security policies or modify the response plan.
Although these steps are numbered, the team doesn't necessarily have to perform them in the order presented, and there is some overlap between the steps. For example, communication and documentation both occur throughout the incident. Additionally, protecting evidence is important throughout the incident to ensure the evidence is not modified and a chain of custody is maintained.
Tip
Test your incident response plan before an incident. A common way to do so is a tabletop exercise in which key team members sit in a conference room and talk through the steps they'll take. The team leader presents the scenario, and team members logically walk through their response. This method tests the plan without impacting systems and also helps identify areas that the team can improve.
However, having these steps helps the organization respond to incidents quickly and decisively. It can save time, money, and protect the organization's reputation. The following sections describe these steps in more detail.
Every reported event isn't an incident. One of the first steps to take is to assess the event and determine if it is an actual incident. Many events can occur naturally on a network but be falsely reported as an incident by an automated tool. You don't want to gather the entire IRT for a false alarm.
For example, a common attack is a transmission control protocol (TCP) synchronize (SYN) flood attack. A TCP session is initiated with a three-way handshake using three packets sent back and forth between two systems. The three steps are:
The first system sends a SYN packet.
The second system responds with an acknowledge (ACK) packet.
The first system then responds with a SYN/ACK packet. This guarantees a connection between the two systems.
Note
The TCP packets have specific bits set known as flags. The SYN bit is short for synchronize. The ACK bit is short for acknowledge.
However, in a TCP SYN flood attack, the attacker sends the first packet and then withholds the third packet. It's like a practical joker who sticks his hand out to shake hands, and then pulls his hand away as soon as the other person extends her hand to shake. The second person is left hanging. Similarly, the second system is left hanging with resources allocated to complete the TCP handshake.
When a failed TCP handshake happens once or twice, it's not a problem. It sometimes occurs due to network problems. However, if an attacker initiates hundreds of these incomplete sessions, it can cause a system to crash. A network typically has an IDS that detects SYN flood attacks. Depending on the threshold set for the IDS, it might trigger an alarm on normal activity indicating that a SYN flood attack is in progress.
At this point, the incident response team needs to investigate the alarm. Is it an actual attack or is it a false alarm? If an attack is in progress, the team identifies it as an actual incident. However, if it's just a false alarm, the IRT won't take any additional steps.
An initial assessment includes the following actions:
Determine whether the data indicates an actual incident or a false positive.
Get a general idea of the type and severity of the attack. Collect enough information to begin detailed research and to contain potential damage.
Record actions taken. Later use these records to document the incident—whether it was an actual incident or a false positive.
Tip
Investigate all events that are possible incidents. The goal is to complete the initial assessment as quickly as possible. Additionally, responders should err on the side of caution. It's better to act on a false alarm rather than ignore an actual attack.
As soon as someone on your team has verified an incident, he or she should let others know about it. This may be a call to the help desk, or a call to the incident response team leader, depending on what the plan dictates. The team leader determines who else to contact. The goal is to ensure that the right team members get on the scene as quickly as possible.
Communication will occur throughout the incident. For example, the initial assessment may have either under assessed or over assessed the incident's impact. As more details come out, they are reported. Once the incident team has responded, the team reports to either the incident response team leader or an incident lead. These leads have the responsibility to ensure that the required details are reported to senior management as necessary.
For example, if an attacker defaced the company's Web site and posted valuable company secrets on the site, the team leader should ensure the information is reported to the CEO. The CEO and other senior management personnel will need to decide how to respond. On the other hand, a simple virus infection of a single system doesn't require notification to the highest levels of management.
Restrict communication of the incident to team personnel. You don't want to tip off an attacker that you're aware of the attack. The attacker could be an unknown internal employee that you'll want to catch in the act if the perpetrator repeats the attack. It could also be an external attacker who may try to attack again. If the attacker thinks no one has detected his or her actions, the attacker is likely to use the same tactics during the next attack.
If the incident requires communication outside the organization, involve the public relations specialist. This ensures the message is properly created to present the company in a positive light, even if a major attack has occurred.
It's important to contain an incident as quickly as possible. This minimizes the damage. The solution can be as simple as removing the network cable from the affected system to disconnect the system from the network.
Tip
Containment is also known as isolation. You isolate the affected system or network from other systems to contain the incident to the original affected systems.
A computer worm is an example of a threat you must contain. Many viruses have a worm component. Sometime after a virus activates, it can launch a worm that spreads through a network. If you detect the virus and isolate the system quickly enough, the worm won't spread. Similarly, you can reconfigure routers to prevent a worm from traveling from one subnet to another.
Some incidents are more serious than others. When responding to serious incidents, consider the following:
Always protect human life and safety first—Human lives can't be replaced but things can.
Protect data—Determine the level of protection for data by its value to the company. Some data may be proprietary and deserve the highest level of protection to prevent unauthorized disclosure. Other data may be public and only need protection against unauthorized modification.
Protect hardware and software—This includes protecting systems against unauthorized modification of the system configuration, and against theft of the hardware.
Protect service integrity—Many services require multiple systems to function. If a criminal launches an attack against a database server, it may seem simple to disconnect the database server from the network to isolate it. However, if this server is providing data for multiple servers, isolating it will affect multiple services on the network. Instead, isolate it by modifying the firewall to limit network traffic.
While containing an incident, consider some other issues. These include:
Protect evidence—If it's possible that your organization may prosecute the attacker, protect your evidence. Because you rarely know in advance if an incident will go to court, strive to protect all evidence. This includes ensuring that your team doesn't modify the original data and that you use a chain of custody to control the evidence. For example, you may decide to remove the hard drives as evidence. You would copy these with a bit copy tool, and you would only examine the copies. This requires you to rebuild the affected system with new hard drives.
Avoid alerting attackers—If possible, avoid letting the attacker know you're aware of the attack. You may want to continue collecting evidence about the attack to use for prosecution, or you may want to learn more about the attacker's methodologies. If the attacker realizes he or she's been discovered, the criminal may disappear without a trace, and then come back another time with better tactics.
Consider costs versus risks—Containment isn't always an easy choice. For example, consider a Web server that generates $10,000 in revenue per hour. If this server is attacked and you isolate it from the attacker, you may also isolate it from customers and your revenue stream will stop. In the face of a DoS attack from a single attacker, you can modify the firewall to block this attacker. However, if it's a DDoS attack from multiple attackers, it isn't as easy to modify the firewall to block all the attackers, but it may still be a better choice than removing the server from all access.
Once you've contained an attack, and even while you're trying to contain it, you will be evaluating it. Identify the type of attack, how serious it is, and how many systems it is affecting. This is similar to the initial assessment but more detailed. The primary goal of the initial assessment is to verify that the event is actually an incident. However, later evaluation allows you to look deeper to determine the extent of the incident.
For example, the initial assessment may have indicated the attack was from a single source. However, deeper evaluation may indicate that the attack is from multiple sources. Similarly, you may have originally thought the attack was against a single server but later learn that multiple servers are under attack. Each of these scenarios indicates the attack is more serious than initially thought and may require a different response. For example, you may need to notify additional people in the company, such as upper-level management.
It's common for an incident response plan to include classifications to help the IRT determine severity. For example, an organization could use the following severity levels:
Severity level 1—A successful attack that caused significant disruption of operations. This attack has impacted a significant number of systems, or a system important enough that its failure could impact the mission of the business.
Severity level 2—A successful attack that caused limited disruption of operations. This attack affected one or more systems and requires manual intervention.
Severity level 3—An isolated event that was resolved through automated controls, such as antivirus software automatically quarantining a virus, or an intrusion prevention system detecting an attack and thwarting it by modifying the environment.
Tip
Organizations determine severity levels within an incident response plan. The security levels may differ between two organizations.
These classifications can also help identify who should be notified. For example, the CEO may want to be notified of any level 1 incidents, and departmental managers may want to know about any level 2 incidents.
You evaluate an attack by examining all the information you have available to you. You normally have quite a bit of information in various logs. These include:
System logs—Look for any suspicious activity, such as the system or individual processes stopping or restarting. Gaps in the logs, or deleted logs, may indicate that the attacker was covering his or her tracks.
Security or audit logs—Look for any unusual audit failures. A series of failures by the same source followed by a success may give you insight into where the attacker was able to access your resources.
Application logs—Logs for applications, such as Web applications or database applications, will give you specific information on what the attacker may have accessed. You'll often need the assistance of the IT personnel who manage the application to identify which logs are relevant.
IDS logs—The IDS logs will often have more details than the router and firewall logs. They are able to analyze these other logs and identify potential attacks. Chapter 11 discusses intrusion detection in more detail.
Router and firewall logs—These logs show what traffic is passing into your network, and what traffic has been blocked. For example, a simple port scan will be logged with the same source and destination IP addresses, but will show different destination ports. Rudimentary port scanners check the ports in sequential order, such as portl and then port2. Advanced port scanners will randomize the port order. No matter what type of scanning tool is used, the source and destination IP addresses will be the same, and the destination port is different which clearly indicates a port scan.
Tip
Attackers frequently use port scans in reconnaissance attacks to determine what services are running on a system. For example, if port 80 is open, the server is probably a Web server running HTTP. The attacker can then use other methods to determine what type of Web server is running. It could be Apache running a Linux system, or Microsoft Internet Information Services (IIS) running on a Microsoft system.
Additionally, many companies use more advanced tools, such as Microsoft System Center Operations Manager (SCOM), to automate the collection of data from these logs. These tools allow you to view a significant amount of data on a single server. You can also configure them to alert you when they detect abnormal activity so you can quickly respond to an attack.
In addition to searching this log data, you can look for other symptoms. These include:
Administrator group membership—Check to see if an attack has modified group membership. For example, the Nimda worm enabled the guest account and placed it into the administrators group on each system it infected. In Microsoft domains, check membership in the Domain Admins and Enterprise Admins groups as well.
Unauthorized hardware—If a criminal has breached your physical security, an attacker may have added hardware that could be a threat. For example, a wireless access point attached to a router can capture and transmit valuable data to an attacker using a wireless laptop in a neighboring parking lot.
Unauthorized software—Attackers may have remotely installed, or tricked a user into installing, rogue software. This could include vulnerability assessment software that can identify the vulnerabilities within your organization. The attacker can use this information to launch new attacks.
Changes in performance—Compare the current performance of systems against the baseline performance. If the performance is significantly different, it could indicate additional rogue processes are running.
This data can help you determine an attack's source. For example, an attacker's IP address will quickly tell you if it is from an internal system, or from the Internet. Internal IP addresses are in one of the private IP ranges and will be much easier to track down to the actual source of an attack. A public IP address lets you know the attack is coming from the Internet, but not necessarily from where on the Internet.
It's important to realize that the attacking IP address may not be the actual source. It's common for attackers to take control of remote systems and use them as zombies to attack when they're commanded to do so. For example, a public IP address may indicate that the source is from a system in the United States, but the actual attacker may be in a foreign country.
This data can also help you determine the goal of the attack. Some attacks are against targets of opportunity. In other words, the attack isn't a personal attack against your organization, but instead you have a vulnerability that the attacker can exploit. On the other hand, it may be a specific attack against your organization for a specific purpose. Some attacks are trying to gather information for monetary gain and will likely be attempted against any similar organization. Other attacks are malicious in nature and attempt to cause damage to a specific organization.
By evaluating what was attacked, what systems were probed, and what files were accessed, you can gain insight into the attacker's motives. For example, the attacker may be focused only on locating and accessing databases. In such a case, you'll want to determine if the attacker accessed any sensitive data.
After collecting the data, you may decide that you need to take other steps. The incident response plan may give specific instructions to follow based on certain attacks. For example, if you detect a DoS attack from a source on the Internet, the plan may direct you to modify the firewall to block all traffic from this IP address.
You also may need to contact other team members, or additional people in the organization. As mentioned previously, team members share new information with the team leader or incident lead. The lead has the responsibility to notify others as needed. This includes ensuring that all personnel on the incident response team have current information.
In many situations, the organization may decide to prosecute the attacker. However, successful prosecution is dependent on successfully collecting and protecting the evidence. If it is possible that the evidence is tainted, the U.S. justice system protects the accused. Make sure the evidence is verifiable and protected from modification so your organization can use it as legal evidence.
Because you really never know if your organization will pursue prosecution, protect all evidence. This includes ensuring that you don't modify it during collection. Think about a police show on TV. You may see an inept rookie cop walk through a pool of blood at a crime scene, but you'll never see a seasoned professional do the same thing. Similarly, seasoned IT professionals know that by simply accessing a file on a system, it changes the file. Instead of showing when an attacker accessed the file, it now shows when the IT person accessed it.
In addition to saving the data for prosecution, you'll also save it for later forensic analysis. It's not always possible to do the necessary forensic analysis during the incident. Instead, capture the data and later analyze it in a controlled environment.
If there's a chance that you'll need the data, back it up using a bit copy tool. Many of these tools are available and they are often included in forensic tool kits. A bit copy tool copies the data at the bit level ensuring that it isn't modified.
At least one backup should be on a write-once, read-many media, such as a CD-R or DVD-R. Use this backup only for prosecution of the offender. Create and use another backup for data recovery and forensic analysis. Ensure that no one accesses these backups except for legal or investigative purposes. Also, create detailed documentation about the backups. Include information regarding who backed up the systems, when, how you secured the systems, and who had access to them.
Note
In some cases, the benefit of preserving data might not be worth the cost of delaying the response and recovery of the system. Compare the costs and benefits of preserving data against those of faster recovery for each event.
After you make the backups, remove the original hard disks and store them in a physically secure location. Use these disks as forensic evidence in the event of prosecution. Also, use new hard disks to restore the systems.
In addition to creating copies of the data, it's also important to maintain a chain of custody. This shows who handled the data and when. It provides proof to a court that the evidence presented is the same as the evidence collected.
Some laws dictate that you must notify external entities if specific breaches occur. Some external agencies may be able to provide assistance in responding to an attack. They may be able to help you recover your systems quicker, or help you identify, thwart, and possibly prosecute the attacker.
Additionally, many state and federal laws require you to notify customers if their private data has been compromised. Personally identifiable information (PII) is protected by many laws. PII includes credit card data, health-related data, and other types of information. If you don't notify the customers of the compromise, your organization may be subject to legal action.
Note
Chapter 2 discusses the local, state, and federal law enforcement agencies involved in system forensics. See that chapter for more information on the types of crimes to report to each type of agency.
System recovery depends on the extent of an attack. A simple virus scan may detect and remove any malware and the system recovers. Other times, all you need to do is reboot the system, since rebooting a system solves many ills.
However, attacks that require you to save the original disks and make copies require work that is much more extensive to recover a system. For example, you'll need to reinstall the operating system and applications. Many organizations use imaging techniques to speed up this process. The image includes the operating system, the applications, and all the required configuration settings.
Next, you'll restore all the relevant data from a backup. This requires you to have a thorough backup plan with reliable backups. For databases that are frequently modified, you can usually restore the data up to the moment of failure, or up to the moment of the attack.
Before bringing a system back online, make sure as well that it has all current updates and patches. Even if you're using images, updates have probably been applied to the system since the image was first captured. This includes updates to the operating system and any installed applications.
As the old saying goes, the job isn't complete until the documentation is done. This is as true with security incidents as it is with other jobs. The documentation and review process actually starts as soon as you declare an incident is authentic. During the incident, you are collecting information to contain and resolve the incident. Once you have resolved it and the systems have recovered, you finalize the documentation.
One of the things you'll want to do is document all the information necessary to reconstruct the events. This includes:
What led up to the event
What happened during the event
How effective the response was
When you're determining the damage your organization has sustained, consider both direct and indirect costs. Incident damage and costs are critical evidence if your organization decides to pursue legal action. These costs could include the following:
Direct costs related to the loss of business sales
Costs to restore the organization's reputation and bring back customers
Costs for time the IRT devoted to responding to, recovering from, investigating, and reviewing the incident
Costs to recover the systems, including lost productivity, and replacement of any hardware or software
Legal costs associated with prosecution
Legal costs in response to lawsuits from customers or employees whose data was compromised
The review process also allows you to determine if you need to make changes to the response plan. If the response wasn't effective, you'll want to know why. It could be because team members weren't familiar enough with your plan's steps. For example, a legal chain of custody might not have been established because the team members didn't know how to establish and maintain one.
After the review process, you may have specific recommendations for change. This could be changes to the plan, changes in team membership, changes in training, or some other change. Without the review process, you won't uncover or address problems, and the same mistakes could happen during the next incident.
Organizations must reasonably minimize their chances of attack. They should also plan what they will do when they're attacked. This chapter discusses measures that help minimize incidents, including assembling a core computer security incident response team and defining an incident response plan.
Adverse event
Chief information officer (CIO)
Chief technology officer (CTO)
Computer security incident
Event
Incident response plan
Incident response team (IRT)
U.S. Computer Emergency Readiness Team (US-CERT)
The ideal time for an organization to learn how to respond to security incidents is after suffering an attack.
True
False
It is impossible to prevent all security incidents. Therefore, when a security incident does occur, an organization must _______ its impact.
Which of the following is a violation of computer security policies, acceptable use policies, or standard security practices?
Event
Adverse event
Computer security incident
US-CERT
The ideal incident response team membership and structure depends on the type of organization and its risk management strategy.
True
False
An incident response team should place all emergency system information in a central, offline location. Which of the following is not a type of information that falls into this category?
Malicious code
Administrative passwords
Network layout diagrams
Router configuration information
Firewall configuration information
Which member of an incident response team is responsible for a particular incident or set of related security incidents?
Team leader
Incident lead
Associate member
Chief information officer
The incident response team performs most actions in response to an incident. However, all levels of IT staff should be aware of how to report incidents internally.
True
False
An organization's ________ outlines specific procedures to follow in the event of a security incident.
An organization should try to let attackers know that the organization is aware of their activities.
True
False
_________ assists federal civilian agencies in their incident-handling efforts. It analyzes the information provided by all agencies to identify trends and precursors of attacks.
When an organization is determining the damage it has sustained, it should consider both ______ and _______ costs.