The operational shape of cybersecurity in an organisation is critical to its success and legal health. In light of recent developments such as the SEC charges of SolarWinds, the forthcoming implementation of its new reporting rules, the increasing strength of the GDPR enforcement regime in Europe, the need to maintain resilience in the insurance sector and countless related developments, it is obvious that the shape of security will be a key focus of regulators, litigators, court and, of course, business partners in a supply chain. An elemental concern will be the shape of incident response.
So here is a thought piece for you. If you were asked to draw a simple diagram to represent security, would you draw a line or a circle? Then, for your diagram, what labels would you add to it? Would your choice change if you started with the labels?
If you approach the topic of security in this way – as a thought piece – you will draw a circle, even if you begin with a line. The labels force you there.
Cyber Security Ransomware Email Phishing Encrypted Technology, Digital Information Protected Secured
There are clear taxonomies available for security labelling. You have choices about which to use and the level of granularity to apply. A useful label is “prevent”, in the sense that you would want to prevent a security breach occurring. Another is “detect”, because you want to know when a breach, or an event that might cause a breach, has occurred. Another is “respond”, because you cannot ignore a breach. You have to deal with them.
When we set it out this way, you have a logical flow of requirements and that gives us a line. But thinking about it some more, we would not want to suffer a recurrence of the breach, or a similar incident. We want to prevent recurrences, which helps us realise that the line folds back on itself, giving us a circle.
We can try another thought piece. What came first, the chicken or the egg? The answer is that it does not matter and we can we bypass the question by rephrasing the dilemma: what do we need? The answer is we need both, chickens and eggs. We need that circle, a circle of life.
Now, these thought pieces are not idle conjectures, because they take us to two operational focal points. The first focal point is that we actually will find a circular formulation in standards for best practice for the quality assurance of processes. Sometimes this is referred as the Deming Cycle, or Plan Do Check Act. The second focal point is the operational reality of incident response itself.
The key question is whether our operational reality is delivering a circle, or just a line. If it is delivering a line for incident response, then two consequences will flow. First, the incident response will not conform to best practice. Second, due to the twinning of operational security and security law, the incident response will not deliver legal compliance either, if the circumstances and context of the incident are subject to legal duties (bearing in mind the vastness of the scope of security law, the most appropriate starting point is to assume that is the case).
Do not get me wrong; some organisations are excellent at delivering incident response. It is important to say this, because if excellence can be achieved, there must be compelling reasons for not doing so. However, my experience is that it is very rare for incident response to deliver an operational circle, or even an approximation of one. Mostly, it delivers a flat line, or if there is some looping back from respond to prevent, the diagram looks more like a ski, or a show shoe, or a u-turn, but not a circle.
There are many reasons for this phenomenon. One relates to silos, which cause a failure to deliver a holistic response. Silos in incident response exist for many reasons. One reason is that the response is uni-dimensional, utilising a single skill set, so it does not address all the other issues beyond the skill set. Another cause is different levels of understanding, skills, resources and priorities in a multi-dimensional response. The mixed priority problem in a multi-dimensional response arises from the fact that the response is not “core business” for all members of the incident response team.
Let me break this down a little. If you have plans in place for incident response that conform to international best practice, per the ISO/IEC 27035 family of international standards, for example, you will have constituted an “incident management team”, with functions underneath consisting of an “incident coordinator” and a variety of different experts that form the incident response team itself. You will also have process connectivity to other business functions, such as change management and business continuity. You will create similar structures if you use NIST, albeit you will use different labels.
Collectively, this means that there will be an array of actors involved in incident response, from people with a full time role in cybersecurity, through to those who only get involved when things go wrong. So, incident response is core business for some people, but not for others.
This drives a race to the end of the line, rather than the completion of the circle, because people with an ad hoc role in cybersecurity want the problem over and done with and put to bed as soon as possible, so that they can return to their core business. Thus, when the short term and immediate goals of the response are completed, the incident responders start to leave the scene. The circle is not completed.
This will be most obvious to people who have been involved in a serious incident. If you have had that misfortune, what was your experience like? Was it “full on”, high octane intensity for a short while, followed by a gradual petering out of intensity and engagement? Do you have a sense or suspicion of possible loose ends, or unfinished business?
You see, the reality of incident response in most cases is that aside from the technical roles, usually there is insufficient activity undertaken to properly learn the lessons and act upon them, so as to turn the response into prevention.
A good example relates to supply chains, which encapsulates everything from the use of third party technology providers to MSPs. In a supply chain incident, the root cause might be weak security controls around a server. However, the preventative work needed to avoid recurrences might relate to institutional processes for procurement of third party support, or the assurance of that support. If the response fixes the controls around the server only and not the underlying procurement or assurance processes, then you have operationalised a line, not a circle. Your work may seem complete, but in fact it is not.
What we have to address, therefore, is the need for thorough post incident reviews (PIRs), so that all the lessons of incident response are learned and acted on. This is required for operational security and for security law.
In practical terms, how can you tell if the lessons have been learned and acted upon? Well let the PIR be your atlas. It should provide a clear topography of all of the issues that need to be addressed by reference to the context of your organisation and the incident itself. Some of the big continents and domains in the atlas include root cause analysis, re-running the risk assessment process and the adjustment of controls frameworks based on the results. You should be able to hold the plans for these kinds of things and records of the outputs in your hands. If you find that you cannot do that, then your incident response has likely failed, both operationally and legally, albeit you might have patched the server.
So, if you were to draw a simple diagram to represent security in your organisation, would you draw a line or a circle?

source