- : Executing a Policy
- Security Incident Response
- Computer Security Incident Response Teams
- Preparing for Incident Response
- Management of Security by Teams
- Execution of an Incident Response
- Evaluation of a Security Incident
- Containing the Incident
- Eradicating the Incident
- Recovering From an Incident
- Article Series
- About the Author
- Acknowledgements
- References
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Preparing for Incident Response
An organization and its constituents must be prepared to respond to an incident, just as it must be prepared to react to any other kind of emergency (for example, a fire). Also, ideally, constituents (that is, an organization's customers in the context of this article) and CSIRTs are expected to prepare for incidents before any incident actually happens. Although, in most cases, preparations happen in stages to reach a completed state. (Proactive teamwork in this area is addressed in detail in the last article in this series.)
The incident response process is summarized in the following diagram:
)
FIGURE 2
Computer Security Incident Response Process Diagram
As shown in Figure 2, there are six primary phases that the incident response policy must cover:
Discovery and reporting
Evaluation
Containment
Eradication
Recovery
Follow-up
All six phases are equally important to prepare for and to ensure that a security incident is quickly resolved with a minimum impact to the business operation. The follow-up phase includes a postmortem session that is extremely important for the VCSIRT and the worldwide security team to review areas that are overlooked during the process. A shortfall at any phase might impact the process in the next phase and might ultimately affect the entire process. Every incident is unique, and the experience gained from handling one incident can provide lessons that are helpful in different phases, as depicted in the feedback loop in the diagram.
Complexity of the incidents and their implications in terms of losses to businesses have made it an absolute necessity to prepare. The primary categories of tasks include:
Obtaining personnel who are skilled in security for incident servicing organizations to deal with incident issues as they occur
Setting up defense-in-depth within the infrastructures (defined in the next section) at the constituent site and at the VCSIRTs parent organization's site for communication between them
Establishing an infrastructure in the customer's enterprise to support incident response process and to mitigate risks that have adverse effects on the business
Creating the servicing enterprise organization's infrastructure processes and procedures to deal with incidents effectively
In the early stages of the formation of the organization's worldwide security team, there will be ad hoc approaches to incident response, but as the organization becomes more established and mature, policies, procedures, and standards must be developed. This topic will be discussed in detail in a future article on proactive teamwork.
Designing and Deploying Defense-in-Depth
Defense-in-depth is widely misunderstood. It is not just about technology, security experts, or policies and processes. It is multidimensional with time-honored improvements included, as discussed below. Having wide-open systems that are completely vulnerable to attack with a strong incident response policy and deployment is simply unreasonable. On the other hand, having strong defenses without having strong matching strength in response capability is naive. Thus, it is important to achieve a balance between these two extremes. The goal should be to allocate appropriate resources to achieve a baseline of security in systems, networks, devices, applications, middleware, operating systems, and databases. Therefore, incidents in which the risk is assessed to be very high are not likely to become commonplace.
People, Technology, and Continuous Process Reinforcement
First, the challenge here is to use security-trained personnel and multiple, independent, different, and mutually-reinforcing security technologies to safeguard the constituent's enterprise, the servicing organization's infrastructure, and their communications. The concept of defence-in-depth can be applied to an N-Tier architecture, which involves the grouping of systems that have similar services, security risks, and exposure. The premise is that no layer, device, or choke point should be a single-point-of-failure for the organization's customer site. By isolating the servers and services, an intruder who attempts to gain access to the site will have several layers of security to overcome before gaining access to the customer's sensitive information systems.
Second, irrespective of how tightly the security was designed and deployed, it is important to understand that security is an ongoing process. The process needs to be reviewed and upgraded periodically as weaknesses are discovered.
Risk Consideration
Secure, defense-in-depth design, with risk analysis in mind, impacts all of the components of an enterprise (for example, servers, hubs, switches, routers, firewalls, LANs, WANs, and wireless LANs—WLANs). In a future article in this series, risk analysis, with alternative ways to assess risk, will be discussed. However, in this section, we present two basic tenets of risk analysis that can guide personnel and organizations when designing and making changes to their computer-based infrastructures, to which the above components belong:
Principle of least privilege
Compartmentalization of information
Anything that is not expressly permitted is denied. This is well known in the security industry. For instance, this tenet is applied to firewall rules to allow only the absolutely necessary services to go across the firewall. It also applies to physical security (for example, in the distribution of keys and other access devices). Does Joe, who is a member of a VCSIRT, have a legitimate business need to have a key to the worldwide security team's lab? He certainly does. Does he have a need to access the chief security officer's office? Definitely not.
This tenet is actually a subset of the principle of least privilege. Information should be accessible and distributed on a need-to-know basis. There is a reason for a member of the VCSIRT or the enterprise's CSIRT to access the engineering information for an enterprise's security product from the parent of the organization to which the worldwide security team belongs; however, the team member does not have a reason to access human resource files for the worldwide security team members.