Response scenarios, or how IS/IT processes are like theatre

Ruslan Rakhmetov, Security Vision

Fig. 1 - A working script - order automation

In the current article we are going to understand such concepts as script, playbook and script, as well as the ways of their implementation from the point of view of tasks of IT and information/economic security specialists. To begin with, let's define the terminology and what we will further describe. Despite the same translation*, let's agree that in this article we will call a script a sequence of operations in some programming language (e.g. python), a script and a playbook - a sequence of actions described in human language (including on paper or visualised in the form of flowcharts). In the differences between the terms we put the peculiarities of perception: while an engineer and programmer may find it easy to work with programme code (script), an ordinary user may find it easy to work with flowcharts, plain text and memos (script/playbook). It is due to the desire to make instructions simpler and clearer that comics, originally conceived as step-by-step instructions, gained their popularity. In this article we will apply this term - ‘instruction’, which unites our concepts and has met every reader.

*Script is a word of Italian-Greek origin with a meaning close to ‘scaffolding’. Playbook and script have English roots and in their native language mean ‘playbook’ and ‘script’ respectively. All three terms come from theatre, but have taken root in the information security field along with the term ‘orchestration’.

Fig. 2 - An example of the process of taking a request to work in the form of a flowchart

Instructions work where there is an algorithm, i.e. if it is clear what to do in a particular case. It is impossible to write an instruction for cases when it is not clear what to do and when to do it. Thus, instructions (scripts, scripts, playbooks) are related to automation tasks. But this tool can have different forms and areas of application: to describe the functions of a new refrigerator, the rules of travelling in the underground, the peculiarities of the company's routine or even violations punishable under the criminal code. Any instruction consists of a reason (or goal), an action and a result. For example, in order to take a bus correctly, you need to validate your bus pass, and to check your computer for possible infection, you need to run anti-virus software. The more complex the object, the more complex the structure of the instruction: this is how different conditions are added to it. If the ‘on air’ light on a radio station is on, it's recording and it's better not to make noise, and if a corporate laptop asks for an update, it's better to do it at the allotted time to ensure security.

The easiest thing to automate in the first stages of implementing any IT system is sending out notifications. The notification itself is a mini-process that has a trigger (the reason for the notification, such as exceeding the limit of free cloud space), the text of the notification and the procedure for sending it to the end user. Often standard notifications can be edited by adding your own text or deleting entire blocks, but sometimes there is a need to use more flexible constructors. Good examples would be BPM (Business Process Management) engines in CRM systems and solutions like SOAR.

The reverse of notification sending - the process of parsing an incoming message - works in a similar way. For example, processing a request from an employee for paid leave, analysing an email sent to an IS specialist for suspected phishing, checking the availability of seats in an office meeting room when booking via Exchange, etc. Such processes are not about sending emails, but about triggering processes because a certain email has been received.

There are also more complex processes that involve multiple users and automatic actions of different information systems. The picture above is an example of a vulnerability remediation request process that may involve L1-L2 response level users, their management and involved IT specialists.

In general, there can be a lot of scenarios, and to work with them with a high level of automation can be any employee in the office or an ordinary person at home. In the case of the office, these are of course IS/IT specialists whose work is organised in overlapping systems, and the processes themselves often involve specialists from a related department. Automated scripts can be used by HR specialists (for launching 360 assessments, sending notifications about overdue holiday pay), accountants (sending payslips, electronic signing of applications from employees by their managers), managers (receiving statistics on staff load, semi-annual performance evaluation and bonuses) and other employees.

But scenarios also exist at home, and can be realised not only in ‘smart’ appliances. Even a delayed start of a washing machine is also a scenario with a simple condition to start the process after the timer has been triggered. Exactly the same conditions are applied in IT, when to protect against server overload, a timeout is set for processing a command for no more than X seconds. A sensor signal can be used as a trigger to start the script (switching on a lamp when motion is detected, notifying an ES employee about a possible leak of confidential information from the DLP system). An additional trigger can be a schedule that is executed periodically (opening the curtains at dawn, starting the kettle 5 minutes before the alarm clock, clearing outdated emails once every six months or backing up a large database at night).

Fig. 3 - An example of a process in the form of a script

The second type of instructions are machine-readable scripts. To automate anything, you need to program the computer to solve this task, for example, move a file from folder A to folder B or find duplicate files (by name, size and/or hash sums). If it is possible to use in-house development for solving tasks, it would be logical to write such scripts, because a lot of things can be automated in this way. For example, this is how scripts work in Ansible Automation Platform (script sets there are written in YAML) and other solutions with a convenient interface (the source code of the programme consists of machine-readable instructions). If the solution interface does not allow you to build algorithms in the form of flowcharts, then most likely you will have to operate with such ‘robots’ and ‘scripts’. Scripts, of course, help to create ‘magic’, but for different tasks you need to know different programming languages: Go, Python for working with files, SQL for databases, SSH for processes on Linux workstations and PowerShell scripts for working out scripts on MS Windows APMs and servers.

Thus, any task that has an algorithm can be automated. If you perform the same action hundreds of times and imagine under what conditions you will have to repeat it again, it is time to think about time saving and automation. You can use different tools: write your own mini-program (or not necessarily mini) or use visually convenient flowcharts and BPM-engines. But the most convenient way of automation will be the one that allows you to combine the flexibility of scripts and the convenience of working with playbooks in the form of graphical diagrams.