return
Software for incident response simulation exercises is not so common in the market. Not so much because of its complexity with respect to other types of software, but because it is useful for something very specific, which is usually provided by large consulting services companies worldwide. However, a smaller scale project could allow the realization of dashboard exercises in a practical way and without having to do without the functionalities raised by commercial or private tools, considering that modern interaction platforms are only accessible for use in large corporations and government agencies.
In order to be able to create a platform, one must first understand the main functionalities to be expected:
A simple approach is to perform the interaction on a commonly used platform, such as Slack or Discord, similar in many aspects. A thorough analysis of features, functions, and licensing modes, oriented to a prototype, leads to lean towards Discord given its granular role assignment functions, text chat, voice and video rooms, categories and channels, and a freely available API with a large community of developers and existing examples.
Another design decision is the scenario storage format, which supports remote queries, and a programming language suitable for fulfilling the aforementioned functions, which in this case was Python. Regarding scenario storage, a spreadsheet format (Excel type) was selected, which can be easily transformed to other formats oriented to data queries. This decision is due to the fact that the design of scenarios is typically reflected in a spreadsheet known as MSEL (Master Scenario Events List) where all the elements that constitute the basis of the events that will be injected as pieces of information during the course of the exercise (injects) are detailed and organized in chronological order. Thus, each column represents an element that is defined in the design stage of the exercise.
As for the mechanism that allows taking the information from each event and assigning it to each team (channel), a script (bot) was developed and to facilitate the interaction, the MSEL spreadsheet in xlsx format was converted to a JSON format file, which simplifies the queries. The bot was prepared to be executed in a cloud system that has the latest version of Python, and that can connect and access the Discord server in question to perform event injections (injects). Once the bot is activated, its control is performed from the Discord platform by the users enabled to manage it (facilitators) through the commands programmed for this: ping, to check connection; start, to start the flow of events; and resume, to resume or start from a certain point. To resolve the defined chronology, the bot calculates the time between events instead of observing the time in real time. Before running, the bot is preconfigured with channel nomenclature according to the requirements of each use.
This project was named BORIS (Bot for Security Incident Response Orchestration) and was made publicly available for download from an online repository on the collaborative development and version control platform GitHub.
Although exercises of this type are typical of large corporations, there is nothing to prevent the development of versions that can be taken to the classroom, with the corresponding adaptations. For this reason, BORIS was proposed for the development of simulations adapted to university undergraduate or professional training courses in programs that include information security management, resilience and business continuity, and incident response, in such a way that techniques and good practices can be exercised, and allow students to experience situations similar to those they would encounter in the real world. Surveys after the exercises were conducted over a period of one year showed very positive results in relation to the capacity of the learning mode enabled by this type of practice.
It was then decided to extend the limits of the typical applications of BORIS to this type of exercise, in order to propose it to organizations and medium-sized companies that, given the size of their operations, are not the ones that would typically have services of this type, and probably would not have all the personnel with the internal knowledge to develop it. As already noted, desktop simulations were traditionally associated with large companies and government agencies, due to their size, number of areas, personnel, and economic capacity to contract a service or in-house knowledge to produce it. The exercises with different medium-sized companies gave very good results, and the subsequent surveys showed very positive data regarding the experience of the scenario simulation, in relation to the real cases.
The expected performance of BORIS both at the educational and commercial level resulted in the need for a growth that could not have been realized with just a Python script. We then took feedback from former students, colleagues, professionals and business customers, regarding possible features for the tool, and found that the most requested was the possibility of interaction with other platforms, i.e. to include the possibility of the bot to interact with different communication platforms such as Slack, Telegram, Whatsapp, Microsoft Teams.
Since the APIs of each communications platform are different, we started programming a different bot to interact with each one, which turned the project into a set of bots rather than a tool that could solve interactions with various systems. This problem led to the design of a framework that could provide a general architecture to interact with each platform in a modular way, with the possibility of including as many additional modules as there are communication platforms. The structure of the framework is shown below.
Thus, a modular structure was created with the orchestration of events stored in a master database (MSEL) as its core, together with a series of rules defined for each exercise (optional) and a configuration that allows defining the technical parameters of the platform used, such as access tokens. This MSEL is built for each exercise based on a history, which in turn is based on the sector or industry definitions and the type of base incident chosen. The orchestrator communicates with the specific module of the platform and this allows the events to be presented in the corresponding input channels according to the configuration of its module. The project then went from being a single Python bot to a framework, which is why it was redefined as T3SF (Technical TableTop Exercise Simulation Framework). For the documentation of the project, the free open source software documentation hosting platform Read the Docs was used, which produces documentation written with the Sphinx generator. Similarly, the source code of the framework is published for free and open use under GPLv3 license in a repository on the GitHub platform. https://github.com/Base4Security/T3SF.
The framework as described, and with all its functional characteristics, was used in different subsequent exercises in companies and organizations, with satisfactory results, and is constantly being improved with the correction of faults and the addition of functionalities such as pre-established decisions in the face of certain events, or the variable flow of the exercise according to the actions and responses of the participants.
Cybersecurity incident response simulation exercises proved to be an experiential tool to help improve reaction capabilities to adverse events, through specially designed rehearsals to stress specific desired points, based on an organization's processes and procedures. The application in educational environments proved useful by exposing students to fictitious situations without the need to have previously experienced them in operational or work environments, thus enriching the participants' experience.
The inclusion of software platforms for conducting this type of tests gives greater realism to the simulated environments, while allowing the fictitious scenarios to be expanded and the exercises themselves to be scaled up. By developing a free and open tool for this purpose, this possibility is open to all environments, whether educational or professional, so that the limitations of commercial software, whose costs are prohibitive for most environments, can be avoided. Thus, the result of the innovation process applied to cybersecurity resulted in a free and open solution that any organization can use to exercise its incident response capabilities.
