Over the past few months during the post-hoc analysis of WannaCry-Petya, we have spoken in great lengths about what should have been done during the incident. This is quite a tricky thing to do in a balanced way because we are all clever in hindsight. What hasn’t been spoken about enough is understanding more generally what we need to do when things go wrong.
This question isn’t as simple as it appears, as there are a lot of aspects to consider during an incident, and only a brief window to identify, contain and mitigate a threat. Let’s look at just a few of these:
– Response times
This is often the greatest challenge but of utmost importance. The response is not only understanding the “how” and “why” of a threat but is also about putting the chain of events into action to make sure that the “what” doesn’t spiral out of control.
– Creating an effective playbook
A playbook should be a guide on how your incident response plan must be executed. Orchestration platforms contain these playbooks/runbooks. Also, note that these are not generic plug and forget policies. They need to be optimized and mapped to your business and regulatory requirements and are often unique to your organization. Otherwise, the incident will be controlled by an incorrect playbook.
– Skills and tool availability
Do you have the correct skills and tools available and are you able to leverage these. Do you understand where your security gaps are and do you know how to mitigate them?
On paper, incident response always works. Right until the moment of truth during a data breach that shows that it doesn’t. To avoid relying on theory only, it is best to run breach simulations and simulate some of the attacks that may affect your organization to find out if your processes and playbooks also work under more realistic conditions.
We’re always playing catch‒up for many reasons—new technologies, new vulnerabilities, and new threats. Software and hardware may possibly always be at the mercy of hackers, criminal actors and other threat actors, so prevention alone is futile. We have to become more resilient and better at dealing with the aftermath of an attack.
The key summary for me is this: How do you respond? Can the response be improved? Utilize the lessons learned in breach simulations to understand how you make the response better than before.
At DFLabs, we typically find our financial clients saddled by regulations which, although important, add layers of complexity to the already complicated process of incident response. We want our clients to be able to feed the compliance measures, not be eaten by them, and we support this end by providing a simple, clear and easy to use playbook editing functionality within the IncMan automation and orchestration platform.
I often point out how IncMan adaptable playbooks are of benefit to companies when determining incident response steps in consideration of regulation. IncMan offers a number of measures to enforce regulatory policy on playbook actions.
Let us take a look at some quick examples:
–Authorization levels: Effective use of the authorization chain means that personnel are engaged only for the tasks for which they have clearance.
–Timed response: Playbook action enforce the urgency when dealing with a particular notification, action or identification, i.e. 72 hours to alert a particular authority about a breach.
–Mandatory tasks: Prescribed tasks are essential for any organization to take the regulatory actions necessary whilst following corresponding incident response workflows.
This list is not exhaustive and IncMan offers lots of possible incident response workflows and points of use for regulatory compliance.
Beyond these measures, it is important to remember that the information gathered in the case record as part of the incident should be fully utilized. The post-mortem analysis of the incident and how it was managed, is as critical as the immediate response. This analysis will help you to define, restructure and organize the ongoing policy changes, and continually fine tune your incident response playbooks.
Our new correlation engine will give you the ability to not only see the entire picture, but also to learn how the picture was built over the course of a timeline of events. Correlation Engine 2.0 helps you to redefine your approach for incident trending and identifying relationships in incident data.
The Canadian Securities Administrators (CSA) continues to ramp up its efforts for improving cyber security for reporting issuers, which include companies with publicly traded securities. The latest step in this direction is the introduction of the Multilateral Staff Notice 51-347 – Disclosure of cyber security risks and incidents, as an update to the Staff Notice 11-322 – Cyber Security guide issued in September, 2016. Тhe CSA considers cyber security to be one of its top priorities, and these guidelines are meant to help regulated entities mitigate cyber security risks.
The main goal of these latest notices is to regulate the way certain organizations disclose cyber security risks and incidents. Issuers are expected to comply with the obligations prescribed in the Multilateral Staff Notice, which among other things, requires them to file detailed reports on each detected cyber security risk and incident.
Automation Platform for Efficient and Detailed Disclosure
Complying with the continuous disclosure obligations might be difficult for some reporting issuers, as it may require spending a significant amount of time and money, potentially affecting their bottom line. However, there are solutions that can help ease that additional strain. For instance, there are automated platforms that are capable of maintaining complete control over cybersecurity incidents and managing risks.
Using a platform that can predict, detect, and respond to cybersecurity breaches can help organizations contain the damage as results of incidents that have occurred, and reduce the risk of such incidents occurring in the future, while also complying with disclosure obligations.
One of the key capabilities of such platforms in relation to the disclosure obligations is the fact that they can create automated reports for each incident, and track every action that is taken by an organization’s computer security incident response team. These types of features are crucial for every organization’s efforts for complying with the above-mentioned requirements.
Multiple Customizable Report Types
The Multilateral Staff Notice requires reporting issuers to disclose specific and detailed reports on every detected material cyber security risk, while also disclosing what actions they take to mitigate and manage said risks. Furthermore, when disclosing cyber security incidents, issuers are required to notify authorities on the potential impact of an incident and the costs ensuing from it. This is where an automated cyber incident response platform can prove to be very useful to reporting issuers. These platforms are able to create different types of customizable reports, containing detailed information about a given cyber security risk or incident.
For example, they can generate encrypted PDF reports, along with DOC, IODEF, IOC and TXT reports, depending on an organization’s needs during a particular incident. These reports include information such as: incident kind, actions taken, evidence, and time of detection, to name a few.
Utilizing a platform of this type, reporting issuers can have peace of mind that all cybersecurity risks are detected in a timely manner and all incidents are resolved as quickly and effectively as possible, while complying with disclosure obligations in the process.