
This is a guest post from Infosec Institute.
Organizations create and deploy incident response plans while establishing procedures for handling various security incidents and breaches. Once an incident has been identified – while it is taking place or after the damage is done – organizations need to take measures to ensure it doesn’t happen again, and the corporation recovers from it, but a response plan is needed before this can happen.
According to a whitepaper by Bryan Cave’s Global Data Privacy and Security Team:
- Having an incident response plan lowers the cost of data breach incidents by $17 per record
- 50 percent of companies are not sure if their plans are effective
- 78 percent of companies with response plans have no scheduled review or have never reviewed their plans
- 22 percent of companies have no incident response plans in place
There are sections in industry regulations that state the requirements on incident response documentation. Examples include section 12.9 in PCI DSS and section 164.308(6)(i) in HIPAA. According to the Harvard Law School Forum on Corporate Government and Financial Regulation, incident response plans are needed for a variety of reasons, including these:
- Regulators will expect organizations in heavily regulated industries (financial, government, etc.) to have threat response plans.
- Incident response plans serve as evidence of security best practices if a company becomes a subject of regulatory proceedings.
- The plan will prevent existing and future incidents from becoming catastrophic events which could lead to an organization’s demise or death.
These plans are developed by security teams consisting of one or more individuals. In the case of one individual, the person acts as the coordinator of efforts made by a number of individuals. When response efforts have been conducted, others are released from their incident dealing duties while the coordinator continues the daily responsibilities of keeping a watch out for incidents.
Key Elements of an Incident Response Plan
These days, organizations are overwhelmed with the complexity and volume of incident response plans, particularly overlapping elements and policies offered by “me too” security advisors. More often than not, corporations base these plans on the day-to-day strategy, rather than adopting a comprehensive approach.
For a plan to be robust, durable and successful at delivering results, it should include the following key elements:
1) Policy and incident definition
Arguably a key aspect of an incident response documentation is the process of designing a policy to protect resources against intrusion and classifying what constitutes an incident. It may be an insider abuse or an external cyber attack. It may be highly sophisticated such as a social engineering attack or entirely technical in nature such as a web application hack. The IT committee needs to outline the breaches that should be included under the incident umbrella. The policy should promote information flow before, during, and after an event.
2) Roles and responsibilities
Details of key players and what will be their specific responsibilities are needed. Contact information should be disseminated to the security team and IT management. In general, incident handlers should be able to refer to the document to quickly identify who is going to analyze which aspect of the response, followed by validation of the response, while documenting all steps taken. Examples of important players include incident response manager (coordinator of the team), incident response officer (responsible for actions of the team) and incidence response custodian (handles technical response and application support). Redundancies can be looked into if key individuals are expected to take days off.
3) Performance objectives
Objectives should be laid out to contain and control the event to prevent further breach of information or unauthorized access. Performance objectives could include freezing, monitoring, or closing certain vulnerability gaps, while preserving any evidence pertaining to threat vectors. Performance training could include the use of prevention tools such as change management and patch testing. CSOs should frequently update performance objectives based on experience and key lessons learned.
4) External support
Effective event response documentation requires an organization to have pre-existing relationships with third parties such as forensic experts and law-enforcement organizations. External support could provide emergency services to minimize the possible impact on the corporation’s security architecture. Commercial partners are especially effective in handling evidence so as to serve a strong case in the court if lawsuits are filed. Finally, external support can provide greater scalability and flexibility to incident response plans. Guidelines that spell out the values of internal response teams will also guide the response from external response teams.
5) Incident assessment and response review
Continuous improvement of the plan is driven by the ongoing assessment of events – that is, the ways in which the incident could occur – and then making the necessary response appraisals. For each event type, the assessment outlines the team and response operating models. These models then document response rights, such as who’ll be responsible for notifying the law enforcement agency. The response outcomes should be reviewed to find out steps that could be performed better and harden the response to improve the overall plan. This should contain review of the communications, performance objectives, crisis management, and external forensic investigation.
The most critical element?
As is evident above, incident response plans have several key elements that define an organization’s response to an adverse event. However, the most critical aspect of the plan determines the depth of penetration of the event into the security infrastructure as well as the plan’s success.
And that most critical element is testing.
Incident response plan testing is needed to assess the response to an adverse event against the organization’s sensitive data, infrastructure and network. It is also used to fine-tune the documentation framework, responsibilities and the effectiveness of individuals undertaking responsibilities. The test will go beyond traditional evaluation exercises by testing real-time responses to live incidents against the company’s systems.
Testing can be conducted both remotely and on the site where the infrastructure was affected because of the incident. Industry regulation requirements also include testing for incident response documentation. For example, section 12.9 of PCI DSS asks organizations to conduct an annual test, but that may not be sufficient if you want to overcome deficiencies identified in monthly or quarterly audit cycles.
As a result, you can adopt a multi-faceted approach to frequently validate that technical controls and vulnerability response are updated properly to solidify the organization’s position against damaging events.
Response testing and capability analysis services provide an external testing option for organizations that lack internal capabilities to conduct tests. Such services provide simulations based on incident intelligence on tradecraft of adversaries to assess your response procedures during an event. Beyond tabletop exercises, you and your team are primed for real-time handling of security incidents through robust testing and best practices education.
Testing will also ensure what deviations from the plan frequently occur and how to put an end to those deviations. Advanced incidents will have different containment requirements and response testing methodologies than low-level incidents. Ideally, the test report will include:
- Testing methodology
- Assessment of response items
- Expected results
- Actual results
- Causes of deviation
- Recommendations to remove discrepancies
Having a tested incident response plan in place prior to an event will save you money, time and reputational hits when the unthinkable happens. It will also reduce the period of time in the lifecycle when an active response is required to successfully resolve issues raised by unwelcomed events.