- Focus and Scope
- Working with Law Enforcement
- Operational Strategy
- Services Offered
- The Importance of Credibility
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Operational Strategy
At this point, we have addressed some basic factors in identifying the focus and scope of the team. The next major section of the puzzle to consider is the team's operational strategy. Specifically, will the team be strictly reactive or both proactive and reactive in nature? If it is reactive only, the team would strictly respond to computer incidents as they are detected or reported from the constituency. Tools such as intrusion detection systems (IDSs) may be used to monitor for and detect unauthorized activity as it happens. (Some IDSs can also be configured to help stop an attack in progress.)
It is very difficult, and sometimes ineffective, for a team to remain completely reactive. For example, if an incident affects a number of systems, it may be a prudent measure to proactively examine other systems that do not appear to have been affected. This activity ensures that no damage was inflicted and confirms that proper safeguards are in place to prevent the systems from being affected in the future. Although prevention programs are difficult to justify because it is nearly impossible to quantify the number of incidents prevented, it stands to reason that an incident that is prevented consumes fewer resources than one that must be investigated.2
If the team is to be both proactive and reactive in nature, then services such as risk assessments, vulnerability analysis, and training may be included in the capabilities offered by the team. The number of tasks assigned to the team will have a direct impact on the number of personnel and tools required for the team to be completely operational. Keep in mind that some of these services may be outsourced or scaled appropriately for the organization, depending on the projected return on the investment for the services that are offered. More detail on the types of services that the team may consider offering is provided later in this chapter.
Defining an Incident
Regardless of the strategy taken, the type of activity that is considered to be an incident should be clearly decided up front. It is strongly recommended that a clear, concise definition be developed for the “incidents” a team will address. Generic or vague definitions such as “unauthorized activity” leave too much room for interpretation and may negatively affect operations. For example, the number of personnel assigned to the team may prove insufficient for the volume of “unauthorized activity” reported and problems may be encountered in trying to enter and track the incident data in a database or trouble ticket system.
This question leads into a discussion on the very important topic of terminology. As this topic can be quite expansive, a separate chapter has been dedicated to this one piece of the puzzle. Refer to Chapter 3 for this discussion.
Tracking an Incident
Although this is still very early in the book, you should consider your incident tracking strategy to be a part of the foundation of the incident response team. The ability to track incidents is important for several reasons:
-
Management Reporting. The incident tracking system may be used as a tool to justify and report on the performance of the investment that has been made in the team and security tools. Reporting the type and severity of incidents encountered also helps upper management to gain a clear picture of the threats being realized in their environment. This information can then be used to focus efforts on specific areas, such as user awareness, antivirus software, and increased levels of defense, so as to improve the overall security posture of the organization.
-
Incident Triage. A mechanism for grouping incidents can lead to streamlining incident investigation activities, setting priorities for incidents, and correlating incident data.
-
Customer Service. The incident response team's reputation among its constituency is critical to its success. A team that permits incidents to “fall through the cracks” will lose favor with its constituency, and eventually management support. Management will naturally expect the team to handle incident information and evidence in a responsible, prudent manner. In addition to incident accountability, a team must have a well-planned method of keeping the affected constituency abreast of the status of the incident.
A dedicated database for tracking incidents, correlating activity data, and reporting statistics to upper management can be the most valuable tool that an incident response organization has at its disposal. Tracking processes and mechanisms must be established to follow the incident from the time it is reported to the time it is considered closed. Otherwise, if the team is very busy (as most are in today's environment), the chance for an incident to “fall through the cracks” is too great. Two or more tools may actually be required for this function, such as a triage tool that feeds data into a central database. The triage tool may be used for tracking open tickets, while the database is used for reviewing specific details about the activity.
Once the team is operational, the sources for reporting a computer incident to the team will typically have multiple origins. A team may accept incident reports via the telephone, e-mail, IDS, paging systems, law enforcement, or other sources. Not all information that is reported to a team as an “incident” will, in fact, turn out to be a real incident, just as a call to the emergency 911 telephone system may not be an emergency. (Note: 911 is the code used within the United States for emergency calls to police, fire, and medical officials. Other codes are used in different countries, such as 0, 411, and 119.)
As activity is reported from various sites or systems, mechanisms for correlating various aspects of it need to be available. For example, how often does a specific IP address show up? Have any other attacks on a specific target been reported? How many scans of a particular port number have been detected?
Finally, statistics can be a wonderful tool for any team. A database can help to quickly identify useful data, such as the number of reports received, number of open incidents, number of false reports processed, number of times that a particular Internet service provider's (ISP) addresses have attacked systems in the team's constituency, and much more. These statistics can, in turn, help to identify specific threats to the systems that the team is trying to protect as well as justify the need for the team or additional resources moving forward. (Granted, statistics can be manipulated in many ways, but it is very difficult to dispute facts that are very well defined with a good deal of granularity.)
Counting Incidents
A similar issue that must be addressed is how incidents will be counted. It is not uncommon for an attacker to gain unauthorized access to multiple sites within the same time frame or deny services to more than one system at once. A good example was the distributed denial-of-service attacks launched in February 2000. Over the course of three days, computer systems at Yahoo!, buy.com, eBay, CNN.com, amazon.com, ZDNet.com, E*Trade, Datek online, and Excite were all affected by the attack.3 Depending on the accounting procedures implemented by an incident response team, these attacks could have been combined into one incident or tracked separately as nine incidents with similar patterns.
Combining the activity that appears to be attributable to the same person or group of persons can help with the correlation of the activity. Conversely, by grouping the activity together, important statistics may be lost. Most teams will combine the activity that appears to come from the same source. In that case, it is recommended that the database or means of tracking statistics have enough granularity built in to depict the number of targets affected by the attack.