Data breaches and other IT security incidents are an inevitability for any organization. High-profile security breaches make headlines world-wide and often draw unwanted attention towards a company. The impact that a security breach can have both financially and reputationally is significant, while legal liabilities and regulatory exposure are also factors to be considered. Organizations must have adequate preparations in place to limit the possibility of an incident and also to limit the damage that will be caused in the event that an incident does occur.
A major security incident can be a career-damaging event for a CISO or IT Security Leader but it can also be used as an opportunity to learn from mistakes previously made. If an organization is well prepared, damage can be limited and detection and response strategies can be optimized to improve processes to deal with future incidents.
An effective response strategy, at the very least, decreases the risk of consequences stemming from a cyber security breach.
In some highly regulated industries, e.g. financial services, incident preparedness is part of the standard of due care and it is a documented requirement of applicable regulatory regimes, such as the U.S. Health Insurance Portability and Accountability Act, the U.K. Data Protection Act 1998, the Australian Prudential Practice Guide 234 and a number of generally accepted industry standards such as Payment Card Industry Data Security Standard (PCI DSS).
Because of this, both internal and external stakeholders would expect that processes for responding to a security incident and the minimization of its impact will be in place.
In general, details of security incidents cannot be predicted before they happen but there are some basic elements of an organization’s response to it that are very predictable:
In preparing for a security incident, and to ensure that an organization's incident response plans are clear, effectively targeted and aligned with organizational priorities, CISOs must make the following six critical decisions.
In order to develop a response strategy, CISOs must define those who will be involved or will be impacted by a security incident. In general, CISOs should work closely with these stakeholders and develop long-term relationships that will be important in the event of an incident.
These stakeholders may include:
Controllers — Controllers, such as regulators and external auditors, must be satisfied that the organization is meeting all applicable standards. This can mean meeting specific legal requirements and having an adequate incident response plan to preserve the organizations stability. While interaction with controllers generally comes after an incident, there needs to be a clear understanding of their expectations beforehand.
Support departments — Support departments, such as internal investigators, legal counsel and even external service providers, can provide specialized expertise in assisting with the response to an incident. It is important for the CISO to develop relationships with these supports prior to an incident happening and to know in advance who they are, what services they can assist with and when those services can be used.
The value chain — The CISO must be aware of the impact of an incident on business operations and lines of business must be involved in drills to test their response capabilities. This will determine the IT and information assets on which the organization’s critical business is dependent on and how these processes will be impacted by a potential interruption to services.
Adversaries — It is also important to understand why and how people may be working against the organization which can help identify the key focus of an attack and how future attacks might unfold. CISOs should develop good relationships with the media, industry professionals and even hackers themselves.
The CISO must have a comprehensive understanding of what the organization's priorities are before he or she can define an appropriate response to a security incident. These may vary greatly depending on the type of industry and company specific factors.
For example: If the systems that have been attacked deliver treatment that is necessary for cancer patients', system integrity is likely to be then the top priority.
If the system that is compromised is used by a law enforcement agency to store information about informants or operations, then the highest initial priority may be to identify either the person responsible or the extent of the unauthorized access and data that has been compromised.
If the system that has been attacked is used to deliver online retail banking, then restoring a reliable service for customers may be the top priority.
This will enable the CISO and other members of the response team to understand what the organization's priorities are and their own process.
The decision must be made by an organization on the individual or team that will have the primary responsibility for managing the response to an incident. This responsibility should, ideally, reside with a computer security incident response team (CSIRT), which may be either an actual team or a virtual one.
It is necessary to document what purpose the CSIRT serves so that a clear process is in place with an organization-wide understanding of what the CSIRT must achieve, what it will do in the event of an incident and what authority it has when an incident occurs. This will impact the administrative arrangements, resources and operating procedures of the CSIRT.
Responsible, accountable, consulted and informed (RACI) charts are very useful tools for ensuring that important activities are not overlooked or duplicated.
Organizations sometimes find it difficult to identify what is actually a serious incident and events that do not require an operational response.
CISOs should adopt a simple process for understanding which occurrences can be ignored (events), which ones require a normal operational response (incidents) and which ones require critical operational response (crises).
Events can range from relatively harmless port scans to more serious attempts to breach the organization’s security defenses and occur almost constantly. When these happen, the organization does not generally take action, relying upon already-in-place systems, such as anti-malware tools to deal with these events. Configuration and monitoring of these devices are relatively straightforward activities, and are managed by either the IT operations or by a managed detection and response service such as ActZero.
Most organizations experience incidents from time to time. These are events that require some form of active response and a failure to respond would have consequences for the organization in the future. A minor incident, such as an isolated malware outbreak that has no real impact on business operations, may still be managed entirely within IT or security operations. More serious incidents such as the compromise of personally identifiable information may have serious legal, business or financial implications. These incidents should be managed by the CSIRT with help from the legal counsel and compliances experts, if relevant to the particular incident.
An incident that is defined as very serious may escalate into a crisis that could affect the welfare of individuals or the future of the organization. Organizations most capable of surviving crises are those that have planned for them. They will have defined processes managed by a crisis management team and will likely involve senior management, including the CEO. One if the key defining factors is to know when an incident has become a crisis and where escalation boundaries lie in order to have an effective response strategy.
This can be achieved by defining an escalation framework based on a defined set of impact levels, with each level reflecting the extent of the potential impact across a range of criteria (for example, legal implications, brand reputation or financial impact).
A governance committee must have formal oversight of the CSIRT's activities as they are highly sensitive. A committee might already exist within an organization and a governance role may be an agenda item for this existing committee. The committee must, however, be made up of a wide range of member stakeholders, and not be made up solely of IT personnel. It should include business, operational risk and audit representation. It is also possible that several governance forums may have an interest in the incident response process.
This committee must be accountable for determining, prior to an incident, what levels of authority will be given to those in roles responding to an incident. This is important so that responders can act quickly in the event of an incident. The response team may also have to make necessary decisions that may have an impact on other service-level agreements (SLAs), depending on previously established priorities.
For example, in exceptional conditions, the engineering and security operations teams may be given authority to issue an emergency change management (ECM) request, for which the incident coordinator would be held accountable. This would be a pre-defined change process that may be executed during the course of normal business hours and with as little as 30-minutes' notice, depending on policy and circumstances. Authority such as this would be reflected in the RACI chart referred to earlier, which would be approved under the structure approved by the governance committee.
The operating model is the collection of documented procedures that define and outline how an incident is to be managed. It is driven by and includes the materials previously mentioned in this research, such as the RACI chart and the escalation framework.
Other related elements of the operating model are the identification of responsibilities between teams and the types of information or artifacts that must be kept or transferred, rules of engagement, service levels, and a description of each participant's purpose and success criteria. This becomes particularly important when in an outsourced or otherwise distributed environment, in which different cultures and organizational imperatives are involved, particularly in situations where the outsourced company is not aware of the organization’s priorities.
SLAs may include requirements that:
The key component is the procedure. The procedure could become extremely complex, and for this reason, more detailed procedures applicable to each individual team and the necessary hand-off points, such as the engineering, media relations, customer service and legal organizations, may be required.
The procedure reflects many of the decisions that have already been outlined in this document. For example, security operations can issue an ECM, but it must be approved by the incident coordinator — and only after liaising with senior management (to the extent possible under the circumstances).
An environment that is outsourced can make this far more difficult depending upon the nature of the outsourcing contract. This is why the foundational work is so important, because it ensures there is a clear understanding of responsibilities, deliverables and service expectations.
Materials to support a rapid response can be prepared in advance of an incident as when the speed of response is too slow, incidents can become worse. For example, a breach that affects members of the public’s personal information may be made worse if a company is slow to establish its media position after the news becomes public.
Likewise, poor responses to customer support lines can lead customer frustration, loss of customer confidence, and ultimately a greater financial impact. These outcomes can be mitigated by having prepared media positions and call center scripts already prepared in advance of an incident, so that they can be used as soon as required.
An important step in the incident management process that is often overlooked is the post-incident report (PIR). A PIR should be completed at or near the end of the process, so that root causes can be fixed and improvements can be made to processes. The report should contain a set of action items that address any root causes or flaws in the response process, and these should be tracked as part of the governance process.
To see how our MDR Service can help you prevent incidents, prepare for incidents, and detect and respond to them when they occur, get a demo today.