Incident Readiness and Response
By Omar Santos
It is extremely important to have a good incident management strategy within your organization. All organizations are susceptible to security incidents that either impact or threaten to impact normal business operations. To achieve a successful enterprise-wide incident readiness and response strategy, it is first necessary to have a solid background in the operational, management, and support functions required by such an initiative. This article provides a high-level overview of incident readiness and response methodologies.
Note: The Cisco Press book "End-to-End Network Security: Defense-in-Depth" includes more detailed information on numerous best practices that can be implemented to achieve a good incident management process.
A six-step methodology on security incident handling has been adopted by many organizations, including service providers, enterprises, and government organizations. This methodology is composed of the following steps:
- Classification and Containment
- Reaction and Recovery
- Postmortem (Lessons Learned)
The preparation phase is the most important phase in incident management. On this phase you perform tasks such as risk analysis, threat modeling, and implement security configuration best practices in network devices to achieve infrastructure protection. Additionally, you put strong security policies and processes in place that will help you identify, classify, and mitigate security incidents.
Risk analysis is crucial. You need to know what you are protecting and how you are protecting it. What are your critical systems and assets? What constitutes your organization today? These are some initial questions you should ask yourself when starting any risk-analysis process. You must know the difference between threats and vulnerabilities. Threats are occurrences that can affect a system or an organization as a whole. Examples of threats include fraud, theft of information, and physical theft. Vulnerabilities are flaws that make a system, an individual, or an organization exposed and susceptible to a threat or an attack. On several occasions, when you ask security engineers, managers, architects, and executives to list or describe the critical systems of their organization, their answers are contradictory. One of the main goals that members of an organization should have is to understand their environment and what they are trying to protect and what risks are most imminentt.
The primary goal of any threat modeling technique is to develop a formal process while identifying, documenting, and mitigating security threats. This process has a huge impact on any organization because it is basically a methodology used to understand how attacks can take place and how they will impact the network, systems, and users.
Cisco has developed a methodology that goes beyond typical threat modeling techniques.This methodology or framework is called Security Assessment, Validation, and Execution (SAVE) framework, formerly known as the Cisco Operational Process Model (COPM). SAVE is a process model that was initially designed for service providers but has recently been adopted by many other organizations. This threat-mitigation practice goes beyond a single product or technology. The SAVE framework helps you to prepare and anticipate the lack of operational security expertise by minimizing threats that cannot be completely controlled while controlling those that can be. It focuses on both business and technology groups throughout an organization, while also focusing on the availability and reliability of the infrastructure and its systems. Total network visibility and complete control of elements is crucial to maintain services and business continuity. SAVE is designed to introduce flexibility while improving security without relying on a single technology or product. Multiple technologies and features are used throughout the network to obtain visibility into network behavior and to maintain control during abnormal behavior. SAVE defines network security in six major categories or "pillars." The following figure illustrates the different categories within the SAVE framework.
The six pillars in SAVE are as follows:
- Identity and Trust
- Instrumentation and Management
- Isolation and Virtualization
- Policy Enforcement
How good is your network if you cannot manage it when an outbreak or attack is underway? Visibility is twofold. Network administrators should always have complete visibility of networking devices and the traffic within their infrastructure. At the same time, intruders must not have visibility to unnecessary services or vulnerable systems that can be exploited within an organization. The following section describes how you can perform periodic security penetration tests and audits to assess and evaluate the visibility of vulnerable systems within the organization.
Note: The book "End-to-end Network Security: Defense-in-depth" describes several techniques that you can use to maintain the visibility of devices and systems within your infrastructure.
Always keep up-to-date by analyzing intelligence reports about current vulnerabilities and threats. In addition, try to educate yourself on advanced security topics to help you better protect your network and reduce organizational risks.
Note: You can obtain security intelligence reports and information about new threats from the Cisco Security Center.
A typical network infrastructure is built with routers, switches, and other equipment that provide indispensable services designed to increase the productivity of your organization. Each day results in new security threats, including DoS attacks, and worm and virus outbreaks deliberately created to directly or indirectly disrupt the services that your network infrastructure attempts to provide. That is why it is critical to understand how to protect your organizational infrastructure by using security tools and best practices to protect each system in your network. You need to know not only how to protect the infrastructure, but also how infrastructure components can help you identify, classify, and protect against these security threats. You need to understand the different router planes and their architecture to better protect your infrastructure devices.
RFC 3654 defines two planes:
- Control plane
- Forwarding plane
ITU X805 defines three planes:
- Control plane
- Management plane
- End-user plane
Finally, Cisco defines three planes:
- Control plane
- Management plane
- Data Plane
Infrastructure protection includes disabling unnecessary services and implementing security best-practice configurations on networking devices. The following white-paper describes currently available tools that you can use to protect Cisco IOS software-based infrastructure elements. Detailed step-by-step configuration examples are also included in the "End-to-end Network Security: Defense-in-depth" Cisco Press book.
Building Strong Security Policies and Processes
Always remember, what good does a firewall, IPS sensor, encryption device, and your favorite security product/tool do if you do not have guidelines, policies, and best practices on how to effectively configure and use them? Building strong security policies is crucial for any organization. These policies should be strong, yet realistically flexible to accommodate ever-changing requirements.
Policies communicate not only a standard but also an agreement on what should be the best practice for a specific situation (in this case, related to security). Policies must be detailed yet easy to understand and must also balance enforcement and productivity. A security policy is useless if it impedes productivity. During the security policy design stages, you should define the reasons why such a policy is needed. Also define the stakeholders, contacts, and their responsibilities. In addition, you should discuss how to handle violations to such a policy.
The following are some of the most common policies in every organization:
- Physical security policies
- Information protection
- Perimeter security
- Device security
- Acceptable use of specific applications and systems
- Remote access
- Wireless security policies
- Data center security policies
- Extranets and demilitarized zones (DMZ)
- Patch management
The following are examples of other elaborate policies:
- Lab security
- Acceptable encryption protocols
- Network admission control policies
- Identity management policies
Note: SANS has several security policy templates that you can download. Cisco has a Security Policy Builder tool here.
Some people think of security policies as long documents that merely define what level of access systems and people have. However, policies include all of the previously mentioned items and topics, such as:
- Baseline router configuration parameters
- Guidelines for forwarding e-mails to external addresses
- Configuration management procedures and change control
Configuration management procedures and change control is a hot topic when planning incident response procedures. Security changes are defined as changes to network equipment that might impact the overall security of the network. Remember that these policies have to be flexible enough to accommodate the changes that staff members make to respond to security incidents and outbreaks. All security teams such as Information Security (InfoSec) teams and Computer Incident Response Teams (CSIRTs), should review the list of business and technical requirements to identify specific network configuration or design issues to meet security needs. Patch management is also a hot topic today. Always ensure that the current software revision levels of network equipment, desktop machines, and servers are up-to-date with security patches and hotfixes. You should update security policies regularly, or as needed. At a minimum, schedule an annual review to ensure that security policies do not become obsolete because of technology changes and demands. Also, include a provision for ad-hoc updates when higher-priority changes are needed.
It is recommended that you engage subject matter experts (SMEs) when reviewing existing policies because you should consider several factors in addition to those included during the initial development. SMEs can provide valuable input into changes in technology and best practices that may need to be incorporated in the specific policy. Security violations, deviations, and relevant audit information should also be reviewed when considering an existing policy.
You can use various techniques when planning, developing, and updating security policies. Always take the following basic idea into consideration: the policy must primarily reflect what is good for the security of the organization as a whole without limiting productivity.
Lessons Learned and Postmortem
Always remember that "lessons learned" is knowledge or understanding gained by experience (in this case, by the experience during the security incident). The Lessons Learned section in your postmortem should focus on identifying incremental and innovative improvements that will measurably improve the following areas of the organization:
- Processes and policies
- Technology and configurations
The postmortem should include both negative and positive experiences. You should highlight the recurrence of successful outcomes while helping to prevent the recurrence of unsuccessful outcomes. The Lessons Learned section in the postmortem will also help you to improve your risk management processes. You can incorporate these lessons learned into several areas of risk management. One of the key inputs to risk identification is historical information. An input to both qualitative and quantitative risk analysis is identified risks, which can be obtained in your postmortem. Your team should evolve to reflect new threats, improved technology, and lessons learned.