Over the more than 8 years of Solar JSOC’s existence, an incredible number of documents from completely different customers (from banks to large energy holdings) have passed through us. And, regardless of the scale, almost everywhere it was the same: a bunch of inoperable outdated internal documentation that no one uses, because it is difficult, unreadable, and in general – Nibiru. This, of course, did not suit us, but nothing could be done, because the documents were not ours. But the work of an external SOC is highly dependent on how “mature” staff on the customer’s side is responsible for cybersecurity. This is not a game with only one goal, when we give a notification, but it is “swallowed” by the Black Hole. As a result, an instruction in pictures in clear BPMN notation was born. She is a comic for adult uncles, she is a playbook
she is Goga, she is Zhora…
What’s in the playbook
As written above, a playbook is a graphical diagram displayed in a visually understandable BPMN notation, where the roles of the participants, their actions (activities), gateways, data flows and everything that the authors of the notation have come up with are spelled out. In order for all consumers to understand the scheme in general, we sign each graphic display with the most understandable and capacious term (yes, we have a huge internal glossary of this, just 47 sheets).
Conventionally, playbooks can be divided into two types: technical and business. The first describes the process flow when working with an incident and is directed to the customer’s response team. The second is a description of the chain of departments involved in the incident, and its consumer is rather line management. But, as Buzz Lightyear said, “infinity is not the limit.” We began to combine both of these options in playbooks with an indication of the execution time of each of the operations, making the process a little more transparent for business units.
We were forced to come to an indication of an internal SLA when economic security divisions appeared in our life as information consumers. We have launched a pool of scripts aimed at controlling international phone calls for VoIP. And yet they represent SEB employees in the same way? Feedback is not for these great guys. What got there is gone. In addition, they often do not know what exactly needs to be done from the point of view of information security. Hence, a more detailed detailing of actions for each of the participants in the process appears: where to go, what to do at one stage or another and how quickly. Everything is transparent: here is the information for entry, here is a list of actions, here is the time for which they must be performed, here is the way out. The result is practically a charter, which describes all the nuances of interaction between departments. But it is necessary to make a reservation that this will work exactly in the case when the ESS and the information security service have a single management (and this, as a rule, is the case).
What could go wrong
But there are “a few” pitfalls here. A playbook in our understanding is a description process information security incident response. And processes should always have an owner. And here it is, the first stone: which process to choose – large-block or consisting of many blocks?
In the first case, many actions are concentrated in the hands of one employee at once. There are usually not very many such blocks in a company, and it is always easier to find the owner of a process. But this approach, alas, does not provide a sufficient level of decomposition.
From this point of view, splitting processes into small blocks is more convenient – you can determine a specific action for a specific person. But then how to find this person? But what if one of the many owners doesn’t want to change the process for the sake of cybersecurity? Or will he not want to work in the imposed SLA?
Here’s another example from our practice. One of the customers had a large number of branches throughout the vast Motherland. And in one of the branches, a virus attack on the infrastructure was detected. Onsite, an IT staff member was responsible for responding to the incident, who worked from call to call. When colleagues from IB asked him to respond to the incident, he said that his working day was over and he was going home. And left. Naturally, an unplanned “run on the ceiling” began, calls between high bosses, as a result of which the obstinate was returned back and forced to work, but time was lost and a bunch of unnecessary gestures were made.
Moral: it is necessary for all participants in the process to fix the areas of responsibility, time frames and carry out further control (as you like: in the form of reports, in IRP or SD systems).
The second pitfall is the specifics of a specific infrastructure. Making a “spherical horse in a vacuum” is not difficult, but it won’t work. It is imperative to audit and interview process owners before modeling them. You cannot take a ready-made approach that has worked somewhere and thoughtlessly apply it to another infrastructure.
If a contractor already has experience working with different customers, if he has gone through the path of trial and error, then he most likely knows who and what to ask about in such a way that it turns out as efficiently and painlessly as possible for the customer. As a result, it becomes clear which information security processes (and related to them) already exist in the company, who is their owner and how it all gets along in the customer’s infrastructure at the moment.
There is one more pitfall. It is quite obvious that the inputs and outputs of the processes will be the same, but the internal content will be very different. Absolutely everything affects here: the level of automation in terms of response, the number of units involved (including contractors), areas of responsibility of specific participants, and much more. And at this stage, the methodologist begins to “jump”: everything and everyone must be taken into account and the process must be made working. Simplification of the task was suggested by one of the customers: you just need to make a catalog of atomic actions, from which you can then put together a puzzle on the spot for each specific company. An obvious solution that lay on the surface, and which we had not thought of. But now everything has become faster and easier, and at the same time it became possible to introduce automation in IRP systems,
To be honest, we never met the customer’s expectations the first time. The reasons were different, but they were more and more related to working moments and were always correctable.
How to check the effectiveness of the instruction
When the playbook is ready, all that remains is to test it. This, as a rule, we give to the customers, because he will continue to “live” on these processes. Someone goes through all the stages with a stopwatch, someone cuts (literally – with scissors) the printout along the borders of the tracks and pools and distributes it to their employees with the words: “Do you understand what is drawn here?” And then it goes along the entire chain of the process, after which it comes back to us with comments on the test results and then we go to the second round. Another testing option is to try to implement the playbook in the IRP. But this is a separate rather complex task that requires a different approach to the formation of actions: they must be understandable for the logic of the IRP, and not for a person.
Instead of a resume
In short, instructions are necessary and important. But they must be readable and understandable and not contain clerical statements; the instructions must be tailored to the specific user who uses them. In short, they should be in pictures.
Roman Semenov, Head of Methodology and Consulting Department Solar JSOC, Rostelecom-Solar