“Failing to plan is like planning to fail.” – Alan Lakein
As part of our 5-part series about Incident Response Planning (IRP), this article dives deeper into several best practices to keep in mind when building an Incident Response Plan. Incident Response Planning has proven to be an effective strategy for organizations to:
Part 1/5: The 5 Benefits of an Incident Response Plan
Part 3/5: Incident Response Team: Roles and Responsibilities
Past 4/5: Data Breach Notification Laws: Canada, U.S. & Europe
Part 5/5: Lessons Learned: The Unsung Hero of the Incident Response Planning Process
Note: This 5-part blog series was developed to help organizations understand what IRP is, what they should consider when implementing IRP, and how they can leverage IRP to secure themselves against cyberthreats.
While it is important that organizations talk about how to prepare for, handle and recover from a potential security incident, best practices recommend developing an IRP in writing.
According to the SANS Institute, documenting the Incident Response Plan is especially necessary as it can be a “substantial lifesaver when it comes to incident response”, both for evidence retention purposes in case of legal action as well as for lessons learned exercises to improve incident response capabilities going forward.
Some legislations impose retention time even for expired policies, so make sure to find out about what’s required in your industry and legislation prior to implementing an IRP.
The security rule of the Health Insurance Portability and Accountability Act (HIPAA) of 1996, for example, requires that entities maintain written security policies and procedures and written records of required actions, activities and assessments until six years after the later of the date of their creation or last effective date, see 45 C.F.R. § 164.316.
According to the Best Practices for Victim Response and Reporting of Cyber Incidents issued by the U.S. Department of Justice, regular exercises must be conducted to guarantee the suitability of the IRP, the accessibility of necessary lines of communication as well as the understanding of assigned individuals of their respective roles and responsibilities.
Battle-testing an IRP means assessing the sufficiency of the dedicated technical and human resources to address the latest cyber threats. It should verify whether the organization has acquired or has access to the necessary technology and services, even if it requires outsourcing some or most of the IRP.
Note that testing may be required by law.
The American Federal Information Security Management Act of 2002 [FISMA], for instance, requires that all federal agencies conduct “periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices, to be performed with a frequency depending on risk, but no less than annually”.
Federal agencies must have an annual independent evaluation of their programs and practices – a standard that large corporations may seek to endorse as well.
Given that IRPs are battle-tested and reviewed frequently, they should be modified in a consequent manner as to reflect the conclusions of these exercises or changes in the threat landscapes.
As a general rule, IRPs need to be robust enough to withstand frequent organizational changes as a company grows and flexible enough to be applicable to a variety of different scenarios.
NIST Special Publication 800-61 (‘Computer Security Incident Handling Guide’) and the Payment Card Industry Data Security Standard [PCI-DSS] recommend reviewing the plan annually.
Applicable standards depend on compliance, jurisdiction and sectoral activity. The Information & Privacy Commissioner of British Columbia, for example, recommended that a University should review their privacy and security policies at least every three years.
To ensure accountability and adherence to regular review schedules, the IRP should also identify the person responsible for annual or periodic reviews.
IRPs need to be synchronized with other business functions, practices and policies that are relevant, such as those regarding insider threats or human resources.
When it comes to corporate policy management, organizations that develop their plans and policies as standalone documents in informational silos run the risk of disrupting alignments, create conflict and sacrifice the organization’s effectiveness, efficiency, and agility.
In the same way, the depth and complexity of an Incident Response Plan will largely depend on the size of the organization.
In the words of Pablo Picasso, “action is the foundational key to all success”.
The same principle applies to Incident Response Plans, which need to be actionable to be effective and relevant to an organization’s success. This implies two underlying assumptions:
There is no doubt that security incidents against organizations are here to stay. And sooner than later, we’ll all need to live up to the fact that careful incident planning and preparation is one of the best strategies to respond to security incidents.
For Incident Response Plans to be effective, they must be written and documented, tested in battle, flexible enough to evolve over time, in alignment with the organization’s context and business practices and actionable. If your organization is planning to implement an IRP or review an IRP that’s currently in place, make sure to keep these best practices in mind.
Now that we’ve learned about the best practices of Incident Response Planning, what roles and responsibilities should be established within an IRP?
