Plan for Anything that Could Cause Loss or Damage
The first step in properly responding to a security incident is to prepare. By the time an incident occurs, it is too late to get organized. The preparation step includes building the CSIRT and developing a response plan. Preparing also includes assembling any supplies, software, and hardware your team will need to respond to an incident.
Your organization should invest the resources to develop checklists and complete plans to address the results of each likely incident. It will require substantial effort to plan for every likely incident, but focusing on those that could cause loss or damage will be worthwhile. Many CSIRTs discover existing vulnerabilities while developing response plans. You may find problems you can address just by planning for incidents. The greatest reason for preparing for incident response is that your team can decide on the best course of action for each incident when there is time to really think through the alternatives. You probably won’t have much time to consider alternatives during an incident. A plan increases the possibility your team can contain the damage and prevent further problems.
When developing your plan, consider every type of incident that can cause unacceptable damage. One way to develop a complete incident response plan is to think of as many potential incidents as possible and rank them by probability of occurrence and severity of impact if that incident does occur. However, you shouldn’t have to start from scratch. You should develop a comprehensive incident response plan only after developing a risk management plan. The risk management process includes a risk analysis phase, which provides the list of identified risks, ranked by probability of occurrence and severity. The process of developing a risk management plan better prepares any organization to handle risks that are realized, including computer security incidents. The most important incidents are those that are most likely to occur and would have the greatest impact on your organization. Those are the incidents to prioritize if your budget doesn’t allow developing a plan for all identified incidents.
Build the CSIRT
The first step is to identify and assemble the CSIRT members. A good plan includes input from all team members. Have your initial team in place before you begin developing the plan. The CSIRT is the group that mobilizes to respond when incidents occur. The team should contain all of the members who will authorize, conduct, and communicate every incident response activity. A good way to ensure you have the right team members is to define the roles your CSIRT must fulfill. TABLE 13-2 lists the CSIRT roles.
TABLE 13-2 CSIRT Roles |
|
|---|---|
| ROLE | DESCRIPTION |
| Team lead | Leader of the CSIRT and the primary point of contact for all CSIRT issues. |
| Incident lead | Member of the CSIRT assigned to lead activities for a specific incident. Medium and large organizations may routinely need to respond to multiple incidents simultaneously. |
| IT liaison | Point of contact for communicating with the IT department. Even though there will likely be IT department members on the CSIRT, having a single point of contact makes communicating easier. Primary responsibilities include communicating CSIRT activities to IT and keeping everyone aware of how incident response actions might impact IT operations. The IT liaison also helps identify the IT expertise and resources needed to respond to incidents. |
| Legal representative | Generally an attorney who specializes in law related to security incidents. The legal representative advises the CSIRT on incident-handling methods that minimize the organization’s legal liabilities. The legal representative will also communicate with law enforcement as needed and address evidence-handling procedures to maintain admissibility. |
| Public relations representative | Person responsible for communicating with the media and customers regarding incident-related events. The main goal for this role is to protect the organization’s reputation. |
| Management | Person with ability to authorize team activities. Without solid support from management, the CSIRT will not have the authority or resources to be successful. |
| Subject matter experts (SMEs) | As the name implies, SMEs are experts in at least one area. For example, your team may need a network security SME, a malware SME, and an application security SME. One person may fill multiple roles. SMEs may be full team members or you may just consult with them as needed, especially during the planning phases. |
© Jones & Bartlett Learning. |
|
The first team members to assign to your CSIRT are the management representative and the CSIRT leader. These assignments originate with the team’s sponsor. The sponsor is a member of your organization’s management who has the authority to create and fund a CSIRT. The management representative can be the team’s sponsor or another member of management. Once the team has management support and a lead, you can start to fill the other roles on the team.
After the initial team is in place, begin planning. Depending on the team’s existing knowledge of security incident response, you may need to provide some training on the subject. The idea is to give team members enough of a foundation in incident response that they are prepared to develop your initial plan.
Plan for Communication
Before you start to develop checklists for each specific type of incident, take the time to plan the framework. Your CSIRT should handle all incidents in the same way. The severity of incidents will change some of the team’s responses. However, the overall manner in which the team responds should be consistent across incidents. You achieve consistent behavior by developing a response framework. One crucial part of your response framework is your plan for communication. A simple plan for communicating CSIRT actions can reduce overall tension during an incident and may contribute to a successful incident resolution.
Your plan for CSIRT communication should include sections for each of the following topics:
Contacts and hierarchy—Include a list of every internal and external stakeholder in your information system environment. Identify areas of interest for each one. This list should also include media contacts. Store this information in a database or spreadsheet to make it easy to query and sort. Storing areas of interest can cut down on the number of people in the communication chain when efficient communication is important. For example, assume the CSIRT is responding to a Microsoft update that causes remote client computers to crash. Remote users are very interested in this incident but database administrators are not as interested. On the other hand, an incident resulting from corrupted data in the central application database would be of interest to database administrators and remote users. Also include in this section any hierarchy of indirect communication if you use multiple points of contact to distribute information.
Responsibilities—Descriptions of CSIRT communication responsibilities include press releases, incident notifications, updates, and resolution notification. This section assigns the responsibility for each type of communication to avoid finger pointing.
Frequency expectations—This section states the expected frequency of communication based on incident severity and type. Critical incidents require updates at least every 15–30 minutes while minor incidents may only warrant daily updates. The incident’s severity in the initial notification lets stakeholders know when to expect an update. Consider your audience as well when determining update frequency. You’ll likely keep management more up to date than the press.
Methods—This section informs stakeholders of how the CSIRT will communicate with them. Avoid frustration by ensuring everyone knows where to find messages that relate to incidents. Options include email, website status pages, social media methods, and physical signs or banners. This section also includes plans for secondary communications in the case of severe incidents. A fully prepared CSIRT would likely have radios to communicate when all other methods fail.
Plan Security
When an incident occurs, the CSIRT responds to it in the manner prescribed in the incident response plan. In other words, the team follows the plan. Make sure your team has access to the plan. Ensure the team can retrieve the most current version of the plan regardless of the circumstances. Have multiple copies available in different formats stored in different locations. An incident that corrupts the document management system could make life difficult for your CSIRT if the response plan is stored in the corrupt system. Part of your plan should ensure that the plan is available when needed.
A comprehensive plan will likely contain proprietary information. This information should only be available to authorized users. Likewise, only authorized users should be able to make changes to the plan. Unauthorized changes to the response plan could result in incorrect steps, making an incident worse. The best way to guarantee your response plan is available, confidential, and trustworthy is to consider the plan private and essential data. Then, pursue controls to ensure the confidentiality, integrity, and availability (C-I-A) properties of data security that you’ve learned about.
Revision Procedures
Regardless of the effort invested to create your initial plan, you’ll encounter situations that require changes to it. You may have left some incidents or procedures out of the initial plan. You may also have discovered better methods for handling incidents. In any case, include a formal procedure to change the plan. In general, the whole team or an appointed group of team members should review any changes. They should then either approve or deny them. As long as you review all change requests and fully document any changes approved for the plan, you can continually make your plan better.
Also include formal periodic reviews in the plan. The entire team should review the response strategy at least annually. This periodic checkup ensures changes to the plan, or changes to your environment haven’t weakened the team’s ability to respond to an incident.
Plan Testing
The final step in the recurring cycle of incident response planning is to test the plan. Regardless of how good your plan looks on paper, you won’t know how well it works until you try it out.
Simulated incidents test the plan and train your team. These simulations can be informal walk-throughs where team members talk through plan steps or more realistic simulations where the team responds with realistic actions. The more realistic simulations better train team members and reveal any plan weaknesses. Test your response as often as you can to ensure you’re ready when a real incident occurs.