Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Computer Security Incident Response Team
Even the best information security infrastructure cannot guarantee that intrusions or other malicious acts will not happen, be successfully detected, or prevented every time. However, the speed with which an organization can recognize, analyze, deter, and respond to an incident will limit the damage and lower the cost of recovery.
A computer security incident response team (CSIRT) is a service organization that receives, reviews, and responds to computer security incident reports and activity and helps in recovery. Its services are usually performed for a defined constituency that could be a parent entity such as a corporation, governmental or educational organization, a region or country, a research network, or a paid client.
Why would some organizations want to form an incident response team? The following list contains a few of the advantages:
Ability to effectively coordinate a response
Ability to bring together a team of experts to analyze and solve complex incident issues
Ability to improve overall efficiency of an organization's response processes
Ability to work proactively
Ability to create a liaison to deal with institutional barriers, because generally the teams are able to exert more authority than an individual
While the benefits of CSIRTs are obvious, the task of forming and operating a CSIRT is fraught with pitfalls that can result in the demise of a team. Thus, it must be emphasized that to ensure an infrastructure of a competent and respected CSIRT, supporting information and guidance are extremely important. Successful metrics must be established to indicate the degree of success in the actions taken to deal with incidents. A number of possible metrics for incident response exist:
How many incidents has the response team dealt with in a given time period?
How many incidents resulted in an estimated financial loss that is below a certain value?
What were the average time and resources needed to resolve each incident, plotted against the apparent complexity of an incident?
Self-evaluation measures, such as questionnaires, can be used; however, none of the metrics, or even a combination of them, can be adequate to measure the success of a CSIRT. A CSIRT should view such metrics as a start, and ultimately, develop its own metrics that satisfy and suit the organization and the constituency it serves.
Is a team really necessary? It is not always advantageous to create a CSIRT. An alternative is to use individuals who are not part of the incident response team, but who are available (usually based on prior agreements, such as service-level agreements, between organizations) when incidents occur. There are some possible advantages of adopting such an alternative. Smaller organizations generally do not need a team; the overhead costs can outweigh the advantages. In addition, due to the lack of resources, forming and deploying a team could become a difficult goal to achieve. This is because personnel with computer security expertise are hard to find. The following is a list of recommended steps to form a team in an organization. These steps do not have to be followed in the sequence shown:
Obtain management support and buy-in for human resources and costs.
Determine the CSIRT strategic plan for the team's goals and operations, and gather pertinent information to help in understanding past and current issues.
Design the CSIRT vision by defining the charter and goals and identifying the constituencies.
Communicate the vision and operational plan to management, constituencies, and others who need to know and understand the teams' operations.
Start the CSIRT implementation by hiring the appropriate staff and acquiring the needed equipment, as well as defining the required policies. (See "Computer Security Incident Response Policy" on page 17.)
Announce the operational CSIRT to the constituencies and the parent organization that provided the resources.
Evaluate the CSIRT effectiveness periodically with the appropriate metrics. The metrics could need to be fine tuned.
This should involve informing executives such as the chief information officer or the chief security officer.
There is another angle to pursue and evaluate when an organization is initially considering to form a team to respond to security incidents. Should it have its own incident response team, or should it outsource the effort to provide incident response support? One of the many advantages of contracting with a commercial CSIRT is that the overall cost of dealing with incidents is likely to be lower because incident response personnel (contractors or consultants) need to deal only with incidents that occur. Unless there is a plethora of incidents, there is no need to keep a full-time staff waiting for incidents to occur. This can be a viable alternative not only for small companies but even for large ones when there is no trained staff available or when recruiting for a proposed CSIRT.
A CSIRT can be a formal or an informal team. A formal team performs incident response work as its major job function. In this article, we do not define the membership of a formal CSIRT. An informal team is called together to respond to an incident when the need arises. In this article, the informal team is referred to as a virtual CSIRT (or VCSIRT), and its membership is defined in "VCSIRT Team Members on page 8. Although initiated by an organization's security team (referred to as the worldwide security team) to resolve a particular incident or a set of related incidents, a VCSIRT can span several organizations within an enterprise, as shown in the following figure.
)
FIGURE 1 CSIRT
and VCSIRT Within an Enterprise
The following list contains the typical functions of a CSIRT:
Announcements regarding current or potential threats
Vulnerability announcements and responses
Artifact analysis and response (artifact typically applies to potentially malicious software left by an intruder on the compromised system or network)
Education
Incident tracing
Intrusion detection
Security consulting (serving as a clearinghouse for security information)
Risk analysis
Technology watch
Security process development
Collaboration
Cooperation with other internal or external related entities
These functions are usually performed in varying degrees by an enterprise's CSIRT. However, collaboration and cooperation activities are significant with any kind of CSIRT. An organization's VCSIRT usually focuses on the mandatory services pertaining to a particular security incident response. It is expected that an enterprise CSIRT and one or more VCSIRTs will communicate with each other and that the information flow between them will be well-defined.
VCSIRT Team Members
This section includes descriptions of key individuals who can form the wider VCSIRT community.
NOTE
Depending on the geographic area, the size and type of the organization and the enterprise membership can differ; however, the underlying representation requirements are important. A VCSIRT team could consist of any combination of the individuals listed below, or others, but at least one person with security responsibilities is required to be in the team.
Enterprise service engineer
Technical support person
Enterprise's security coordinator
Geo-based customer account manager
Enterprise's CSIRT assigned contact
Organization's geo-based security officer
Organization's worldwide security manager
Personnel relations (PR) officer
Enterprise's legal counsel
This person is responsible for covering the customer site's installation, maintenance, and/or support.
This person is typically in the enterprise's customer service center and gets involved when contacted by an enterprise customer, a partner, or an enterprise field engineer.
This person coordinates security fixes to the enterprise's products and services by planning for and acquiring internal enterprise resources. Usually, it is also the responsibility of this individual to monitor security vulnerabilities reported to the industry or to the enterprise, set priorities for the issues rising from the vulnerabilities, and take appropriate steps to protect the enterprise's, customer's, and business partner's interests by coordinating necessary actions within the enterprise. If an incident is reported by customers using the security@company.com alias, this person assists in the coordination of the response.
This person is responsible for the customer account for the site in question.
This person gets involved in cases in which the enterprise's equipment (such as their WAN) is affected.
This person is responsible for the security of all of the organization's customer installations in that geographic area. Every geographic area is expected to have a security officer.
This person is responsible for the overall security policy and manages all of the geo-based security officers for the organization, in addition to other staff members, such as security administrators and policy developers.
This person could be needed depending on the situation (for example, to avoid media coverage). Usually, the PR officer is a corporate-level PR employee in the enterprise.
This person is required when prosecutions, lawsuits, or possible regulatory violations are involved, but can also provide guidance when sensitive verbal or written communications with external parties are prepared and delivered.
User Community
Discretion should be used when notifying users. Users can be of the following types:
Enterprise's employees (that is, customer service engineers, organizational administrators, and other enterprise employees)
Enterprise's business partners
Enterprise's customers
Because users could also be customers, an extremely careful analysis of information and wording of the notice is necessary.
Public Relations
The enterprise's PR office must be consulted when any incident needs to be reported externally through the organization's worldwide security manager. However, the organization's geo-based customer account manager or the geo-based security officer, in the account manager's absence, should maintain the focus over the incident. In addition, the geo-based security officer should closely monitor the incident and the geo-based customer account manager's actions to maintain the necessary rapport with the site in question.
Involvement of the Organization's Teams
FIGURE 2 on page 11 shows the involvement of the organization's teams for one or more incidents. For a particular geographic area, there is a one-to-one relationship between the customer, the geo-based VCSIRT, and the geo-based security officer. However, a single geo-based security officer could be involved in overseeing more than one incident and, hence, more than one VCSIRT and customer.
)
FIGURE 2 Organization's
Security Teams
Worldwide Security Team
This team consists of the worldwide security manager of the organization and the geo-based security officers, along with other security-related staff such as policy developers and security engineers. The scope of their work covers all of the organization's customers, partners, and vendors.
Geo-Based Security Team
This team includes the geo-based security officer and all of the organization's customer account managers within that geographic area. Local security experts of the organization could also be part of this team. The scope of this team could be limited to a part of a country or one or more countries within a geographic area. Each geo-based customer account manager has security monitoring jurisdiction over his or her region, along with the geo-based security officer.
Virtual Computer Security Incident Response Team
The virtual computer security incident response team (VCSIRT) is formed by the geo-based security officer to make quick progress on a specific security incident. This team should consist of at least the security officer, the geo-based customer account manager of the region where the incident took place, and the organization's or enterprise's technical persons (for example, field engineers, technical support engineers, or computer forensics experts) involved directly in reporting, following, or mitigating the impact of and/or recovery from an incident.
Security Advisory Group
The security advisory group (SAG) is an enterprise-wide entity and is independent of any specific organization within an enterprise. Its primary functions include advising on tactical and long-term strategies, reviewing the organization's policies, and providing recommendations. SAGs can be initiated and formed by organizations for indefinite periods of times, or for long as they are deemed necessary. SAGs use resources from the entire enterprise. By the advisory nature of its function, a SAG should include highly experienced security experts, ideally covering different aspects of security.
Security Team Interactions
FIGURE 3 on page 13 shows the scope of operations and interactions among an enterprise's security teams that are involved in its customer's security incident response. This is just an example for best practice. The communications framework differs according to the size and type of an enterprise. There are two organizations shown within an enterprise. Each has its own SAG and worldwide security team for assisting customers on security and incident response with respect to their products, services, and operations at the customer sites. The SAG can be outside of the organization, with members from the organization's worldwide security team. A VCSIRT can be formed per incident by an organization, depending on the need, with members from inside or outside the organization (as shown with its coverage outside of the organization). The corporate security team is usually involved with all organizations, as the need arises, in resolving major security issues and communicating with the SAGs. However, an organization's worldwide security team can also choose to communicate with the corporate security team, which for a medium to large enterprise, is usually a central team in the enterprise. The internal CSIRT of an enterprise is a resource to the VCSIRTs and is formed by organizations. They can become a focal point for incident processing, particularly when the enterprise is at risk.
In a relatively large enterprise, all of these teams could co-exist in varying combinations; while, in a small company with minimal resources, only a single security team could handle every incident. In such a case, it is recommended that functional responsibilities be assigned to one or more members who are represented in the diagram by the teams' major functions.
)
FIGURE 3 An
Example of the Enterprise and Organizational Security Teams
By exchanging information, cooperating teams usually benefit, and in turn, their customer constituencies benefit as well. Information is exchanged not only between the teams in an enterprise, but also between an enterprise's internal CSIRT and external CSIRT. Exchanging information across country borders requires special attention to the laws of the countries involved. Also, it is more appropriate to service an incident local to its occurrence where local needs, language, time zone, and other requirements can be met. For example, there have been instances in which a CSIRT in a European country has contacted CERT in the U.S.A., without realizing that a national-level CSIRT exists. In this case, CERT diligently responded to the request for immediate assistance, then referred the CSIRT to the appropriate national-level CSIRT for further help.
As summarized in the following table, formal agreements between teams clarify solutions to issues regarding the use and exchange of information.
|
Information Issue |
Description |
|
Confidentiality and/or secrecy |
As the information could be valuable to other parties, its confidentiality and/or secrecy must be maintained. This is true for the transfer, storage, and actual usage of the information. |
|
Appropriate use |
While the information belongs to one team, it must be clear to other teams that they must adhere to guidelines of appropriate use, as outlined by the originating team. In this context, it is assumed that appropriate use includes information creation and destruction, and classification and declassification. |
|
Disclosure |
As the information could be distributed to the public in the future, disclosure restrictions must be stated. |
|
Proper acknowledgements |
Because the information was collected, analyzed, and made available by other teams, the team using it should consider a fair and proper acknowledgement of the source. |
Definition and Relationships of Constituency
A constituency is the specific community that a CSIRT is established to serve. It is also the most important party among a wide range of parties the CSIRT needs to interact with during the course of its operation. Most commonly, CSIRTs have bounded constituencies that tend to reflect the CSIRT funding. Human resources, costs (which differ depending on the size, type, and needs of a constituency), and risks must be taken into account. Defining a constituency is not a trivial task, as it first seems. Constituencies of customers or customer sites can be defined by a number of constraints, such as:
Geographical boundaries
Network provider
Organizational dependencies
The nature of the relationship between a CSIRT, or CSIRT-related teams, and its constituency directly impacts the nature of the services that the CSIRT offers. In general, for accomplishing best practices in cooperation and collaboration, there are four categories of authority for the teams that must be considered: full, shared, none, and indirect, as summarized in the following table.
|
Level of Authority |
Team Examples |
Constituency Relationship |
|
Full |
VCSIRT, plus worldwide security team or geo-based security team |
The members of these teams have the authority to undertake any necessary actions or decisions on behalf of their constituency. |
|
Shared |
VCSIRT |
The members provide direct support to their constituents (per incident basis) and share in the decision making process with the worldwide security team. In other words, they can influence constituency decisions, but they are unable to dictate them. |
|
None |
SAG |
The members of the SAG have no authority over their constituency and can act only in the role of an advocate or in an advisory capacity. |
|
Indirect |
Enterprise's CSIRT |
The team members of the enterprise's internal CSIRT can exert pressure on its constituency (which is the enterprise itself, including all of the organizations and their VCSIRTs) to enforce certain rules when dealing with customer issues that may affect, for example, the enterprise's WAN. |
Functions of the Security Incident Response Service
For each service, among a range of services provided, a CSIRT must provide its constituency with service descriptions (or formal Service Level Agreements) in as much detail as possible. These descriptions are helpful to the team when defining, implementing, and operating the service. In particular, the descriptions should include an explanation of the items, such as:
Objective of the service
Scope and depth
Functions
Availability (to whom, when, and how)
Quality assurance parameters (to set limitations on constituency expectations)
Interactions and information disclosure
Interfaces with other services
Priorities of the services, with respect to other services, and of functions, with respect to other functions in a service
The security incident response service, reflected in the establishment of a Security Incident Response Policy and provided by a security team such as an organization's worldwide security team, usually consists of the following four functions:
Triage
Incident management
Announcement
Feedback and proactive measures
)
FIGURE 4 Organization's
Worldwide Security Team's SIR Service Functions
In the context of this article, the triage function provides a single-point-of-contact for accepting, collecting, sorting, and passing on incoming information from the affected customers for the SIR service. The incident management function provides support and guidance related to suspected or confirmed computer security incidents at customer sites. This function primarily includes the notification, evaluation, containment, and eradication of an incident. In addition, legal and investigative resources could be involved, as appropriate, and post-incident procedures could be developed. The feedback and proactive measures function consists of feedback on issues not related to specific incidents, but it can involve answering frequently asked questions relating to SIR, and developing and maintaining proactive measures for reducing the risks of future harm. Lastly, the announcement function generates information tailored for the specific customer constituency. (Part of the incident management function and the feedback and proactive measures function are described in a follow-up article.)