RU2747099C1 - Automated cybersecurity event testing system - Google Patents

Abstract

FIELD: cybersecurity.SUBSTANCE: invention relates to automated cybersecurity event testing system. The system contains a query orchestration module connected to all the system modules and the database, which provides redirection of user requests to the system modules containing parameters for forming testing algorithms; an infrastructure autoconfiguration module in a virtual environment that interacts with the API of external tools and provides automatic deployment of the infrastructure in a virtual environment from the user's configuration file using external tools.; a testing module that provides automatic testing of cybersecurity events in the deployed infrastructure based on the information of testing algorithms contained in the user's configuration file; a module for monitoring events in the deployed infrastructure that provides automatic addition of monitoring mechanisms within the created infrastructure based on the data in the configuration file and processing events that occur as a result of the activity of objects in the created infrastructure; a database containing user configuration files with specified algorithm parameters for testing cybersecurity events.EFFECT: automation of cybersecurity event testing.6 cl, 5 dwg

Description

FIELD OF TECHNOLOGY

[0001] The present technical solution, in General, relates to the field of computational data processing, and in particular, to automated systems for testing cybersecurity events.

LEVEL OF TECHNOLOGY

[0002] The main task of cybersecurity is to maintain and increase the level of protection of objects of protection commensurate with the emerging risks associated with cyber threats to these objects of protection. At the same time, identifying the actual direction of change (increasing or decreasing) the level of security when applying any actions aimed at this (for example, changing the settings of the domain group policy, introducing a new information security system or adding a second authentication factor) is, in fact, also a hypothesis. At the moment, this hypothesis is often confirmed or refuted either by expert opinion or by testing with low accuracy (on industrial infrastructures where there is no possibility of using really malicious activity). Neither one nor the other is sufficient evidence to make a decision to take any action, especially in an industrial environment.

[0003] Thus, in the framework of research activities, that in the framework of operational activities, in the field of cybersecurity, there is a constant need for experiments (testing). At the same time, the main feature of conducting such tests in "exact" execution is the use of real malicious actions, programs, loads, which, in turn, can destroy the entire testing infrastructure, which will lead to additional labor costs or the impossibility of testing.

[0004] In addition, hypotheses formulated in research laboratories and within an organization are often of a different nature and require different test environments for testing (in a laboratory it can be a stand with general infrastructure settings, while inside an organization it should be a stand reflecting real infrastructure with a certain precision).

[0005] Moreover, static test environments are also not always suitable for testing in the field of cybersecurity, since a number of currently existing attacks use dynamic data generated by users and applications (for example, user network traffic or the memory area in which the program runs) ...

[0006] In view of this, the presence of a system that allows you to automate the deployment of the test environment, to conduct a given test scenario with prepared dynamic activity inside the test environment and isolating this environment from external interactions is a priority task for conducting research activities.

[0007] Such systems are widely known in the art, for example, CybExer Range Platform (see https://cybexer.com), Cyber Exercise & Research Platform (see https://www.kypo.cz/en). A common disadvantage of existing solutions in this area is the low speed of testing and the lack of automation of the testing process.

ESSENCE OF THE TECHNICAL SOLUTION

[0008] The claimed technical solution proposes a new approach in the field of testing cybersecurity events.

[0009] The technical problem or technical problem to be solved is the creation of a new automated system for testing events in the field of cybersecurity, with a high speed and accuracy of testing.

[0010] The main technical result achieved when solving the above technical problem is the automation of the testing process in the field of cybersecurity events.

[0011] An additional technical result achieved by solving the above technical problem is to increase the speed of testing in the field of cybersecurity events.

[0012] The claimed results are achieved through an automated cybersecurity event testing system comprising:

• a query orchestration module capable of redirecting user requests to system modules, and the user request contains parameters for generating testing algorithms;

• module for auto-configuration of infrastructure in a virtual environment, made with the ability to automatically deploy infrastructure in a virtual environment from the user's configuration file and interact with external tools;

• a testing module capable of automatic testing of cybersecurity events based on the information of testing algorithms contained in the user's configuration file;

• an infrastructure monitoring module capable of automatically adding monitoring mechanisms within the created infrastructure and processing events arising from monitoring the activity of infrastructure objects;

• at least one database containing user configuration files with specified algorithm parameters for testing cybersecurity events.

[0013] In one particular embodiment, the system comprises a proxy server that executes secure connection algorithms.

[0014] In another particular embodiment, the test execution module executes a test script processing algorithm.

[0015] In another particular embodiment, the testing module executes an algorithm for preparing a queue of tasks to be implemented prior to testing.

[0016] In another particular embodiment, the test module performs an algorithm for generating feedback with the infrastructure during testing.

[0017] In another particular embodiment, the test module executes an infrastructure optimization algorithm in a virtual environment.

DESCRIPTION OF DRAWINGS

[0018] Features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings, in which:

[0019] FIG. 1 illustrates a general diagram of a claimed automated cybersecurity event testing system.

[0020] FIG. 2 illustrates a general scheme for real-time monitoring.

[0021] FIG. 3 illustrates a general framework for monitoring the results of activity in the infrastructure.

[0022] FIG. 4 illustrates a general framework for monitoring a virtualization platform hypervisor.

[0023] FIG. 5 illustrates a general view of a computing device for implementing a system.

CARRYING OUT THE INVENTION

[0024] The automated cybersecurity event testing system is intended for: automatic deployment of infrastructure in a virtual environment from a configuration file created by a user, automatic preparation and adding various dynamic activities to the created infrastructure, development of a test script in the field of cybersecurity, optimization of the infrastructure involved in testing during its conduct, testing according to a previously created scenario, storage and provision of previously created (by other users) configuration files to system users.

[0025] As part of the automatic deployment of infrastructure in a virtual environment, the system layer by layer (for example, first virtual machines, then the network between them, then setting the domain, etc.) reproduces the infrastructure described in the configuration file created by the user. To do this, the system, using its own auto-configuration algorithms, analyzes the configuration file and translates it into specific directives, which are arranged in an order that will not lead to errors during automatic deployment. These directives represent calls to external subsystems. The system orchestrates directives, redirecting them in the correct order to external subsystems, processing the result of directive execution and adjusting the next directive in accordance with the result. Thus, the gradual execution of all directives ultimately allows you to get a complete infrastructure corresponding to the one specified in the user's configuration file.

[0026] The system uses external subsystems as a tool to execute directives and allows, but is not limited to, the following directives to be implemented:

• create virtual machines (from pre-prepared templates or by creating a new virtual machine with specified characteristics),

• create a network topology for the created virtual machines (with emulation of real network equipment),

• create basic integrations between virtual machines (deployment and configuration of a domain, mail service, dynamic distribution of IP addresses, etc.),

• deploy the software on the created virtual machines,

• deploy a system for monitoring and collecting data obtained during testing for the created cyberspace,

• isolate the created cyberspace from the external influences of the virtual environment.

At the same time, the system allows adding external subsystems to implement new directives.

[0027] As part of the automatic preparation and addition of various dynamic activities to the created infrastructure, the system allows you to connect various tools to simulate one or another activity in the created virtual infrastructure. The system uses third-party tools (for example, intelligent agents) to implement dynamic activities and allows, but is not limited to, the following activities:

• simulation of malicious activity (both the actions of intruders and the delivery and launch of malicious software),

• simulation of user actions (on workstations),

• simulation of network traffic,

• simulation of the public segment of the Internet,

• simulation of network services.

At the same time, the system allows you to add external subsystems to implement new activities.

[0028] As part of developing a cybersecurity test scenario, the user indicates to the system the infrastructure and activity to be carried out on the selected infrastructure. In addition, the user can set the initial conditions for activity, conditions for the end of activity and triggers for the implementation of certain events that the user specifies separately (for example, changing the firewall table if a certain event is detected), the number of repetitions, dynamic variables (for example, several values the same setting, so that within the same testing it changes and you can see the difference), etc.

[0029] As part of the optimization of the infrastructure involved in testing during testing, the system assumes varying degrees of "accuracy" ("accuracy" means closeness to the original, for example: a real computer can be virtualized - a virtual machine with a real OS; emulate - running the OS inside a real OS installed, for example, on a virtual machine; simulate - launch a program that will be able to receive calls and return responses, simulate OS behavior) reproduction of an object (host, service, network topology, network equipment, user in the OS, traffic on a network, etc.) in a virtual environment, by choosing its representation: object simulation, emulation, virtualization, containerization, or using a full-fledged original (in hardware). Moreover, the system can both supplement the basic infrastructure of the configuration file with objects with less "accuracy" (for example, around real virtual machines that implement one network segment, simulation of other network segments will be deployed or another network segment that implements workstations using containerization), which makes it possible to expand testing area, without increasing the load on system performance, and to reproduce part of the infrastructure from the configuration file in a less "accurate" version with a subsequent increase in "accuracy" in real time - is used to reduce the required system capacity as part of testing in a step-by-step mode.

[0030] As part of testing according to a previously created scenario, the system, using information about testing, optimization of the testing infrastructure (if necessary), dynamic testing variables, the number of repetitions (if specified at the stage of creating a test scenario) generates a testing plan, within which:

• the required capacity to maintain the testing infrastructure is determined, the maximum possible number of parallel testing threads is calculated, taking into account dynamic variables and the number of repetitions,

• a queue of tasks for testing is formed.

[0031] After the formation of the test plan, the system starts its automatic execution. In this case, a pre-calculated number of parallel threads is formed, each of which receives a task from a queue, which (task) consists of the following stages:

• deployment of infrastructure in a virtual environment,

• adding dynamic activity,

• start of testing,

• event handling according to test triggers,

• detection of the end of testing event,

• collection of the received data,

• saving data,

• destruction of the deployed infrastructure.

[0032] In addition, there is a step-by-step testing mode, in which the user generates activity steps in advance, and the system automatically prepares the necessary part of the infrastructure in a given “accuracy.

[0033] As part of storing and providing previously created configuration files to users, the system provides a single database in which previously created test scripts and infrastructure configuration files are stored. Also, if the script and / or infrastructure has already been used, then the system can store technical information that allows, if reused, to skip a number of steps that the system takes to start testing or deploying the infrastructure. The system also controls versions of the specified files and provides an interface for searching, viewing, editing these files. In addition, the system provides a programming interface (API) for exchanging and synchronizing content (taking into account access rights) with databases of the same systems.

[0034] The main input data for the system is provided in a configuration file, which can represent one of the following formats: YAML, XML, JSON - but not limited to them.

[0035] The task of the system is to process the configuration file and implement the instructions that it contains for the purpose of testing in the field of cybersecurity.

[0036] The objectives of this testing are, but are not limited to:

• obtaining a set of data corresponding to a particular activity in a specific infrastructure,

• assessment of security measures (or changes in security measures) of a particular infrastructure against various types of computer attacks,

• search for protection measures against various types of computer attacks,

• analysis and identification of techniques and tactics of malicious software,

• training of artificial intelligence algorithms for carrying out computer attacks on certain infrastructures,

• training of artificial intelligence algorithms to detect computer attacks, training of artificial intelligence algorithms in the application of protection measures when detecting certain computer attacks.

[0037] In addition to conducting cybersecurity testing, the system is capable of performing the following tasks:

• testing and evaluating the effectiveness of protection against various types of computer attacks,

• training of the organization's personnel responsible for ensuring cybersecurity, prototyping solutions, both to determine the level of their security, and to determine their impact on the security of the infrastructure as a whole,

• demonstration of new technologies.

[0038] To start working with the system, the user must pass authentication, which can be any well-known authentication method: using a separate account and secret, using a single account and secret (Single-Sign-ON), using the user's personal certificate , biometric authentication, two-factor authentication, etc.

[0039] If the user does not have an account, he can pre-register a new user - in this case, the minimum privileges in the system will be assigned, which the user can increase by providing identifying information (for example, a personal certificate or biometric data, etc.) ).

[0040] After being authenticated, the user is assigned rights according to his role in the system, however, the proxy server can evaluate each user request separately from the rights assigned to him by dynamically generating the user's score according to his actions and methods of authentication and access. And in case of a significant rejection of this scoring, block the execution of requests that are provided for by the user's role (the principle of zero trust).

[0041] The proxy server implements classical security algorithms: user registration, user authentication, request authorization, request routing for load balancing purposes, and differentiation of user access rights. In addition, the presence of a proxy server makes it possible to implement the principle of zero trust in terms of incoming network connections and / or external requests to the server side of the system.

[0042] An authenticated user (adjusted for his own role) has the ability to perform standard operations, such as: searching the database; viewing ready-made configurations of infrastructures, settings and templates (for example, looking at the content of a specific virtual machine template or atomic actions of an attacker as part of a particular attack), adjusting the settings for accessing own resources, etc.

[0043] FIG. 1 shows a general diagram of the claimed system (100).

System (100) receives streams of information that are generated by users. The information entering the system (100) is distributed among the appropriate modules responsible for its processing in an automated mode. System (100) contains a set of interconnected data processing modules.

[0044] The request orchestration module (101) is designed to redirect user requests to other modules in the system, as well as to redirect requests between modules in the system.

[0045] As input, the module (101) expects a network message that consists of a header and a body (<header> <body>). The message header should contain all technical information: request category; request command; arguments and flags of the request command; data of the user or module that made the request; additional information, if necessary - (<category> <command> <flags> <user_data> <payload>).

[0046] The request orchestration module (101) processes at least the following requests from the user:

• display of configuration files / file contained in the database,

• displaying data of specific entities contained in databases or storage of external systems (for example, data about a saved attack in an attack database or data about virtual machine templates from a virtualization platform),

• search by configuration files and their contents,

• receiving (downloading) a configuration file,

• launch of auto-deployment of infrastructure,

• destruction of the deployed infrastructure,

• launch of testing.

[0047] Also, the request orchestration module (101) processes at least the following requests from the testing module (103):

• launch of auto-deployment of infrastructure,

• destruction of the deployed infrastructure,

• getting an item from the database (for example, a network topology configuration).

[0048] Also, the request orchestration module (101) processes at least the next request from the auto-configuration module (102) to retrieve an item from the database (104) (eg, a network topology configuration).

[0049] The Query Orchestration Module (101) implements the following algorithms. Algorithm for processing the request of the user and other modules of the system. Upon receipt of input data (a network message containing at least the following information: <category><command><flags><user_data> <payload> - request category; request command; request command arguments and flags; data of the user or module that made the request ; additional information, if necessary) the request orchestration module (101) analyzes the received technical information contained in the message header. The information in the <category> field determines the direction of message transmission. For the found direction, the correctness of the command is determined, which is contained in the <command> field. If the command is incorrect, a response is generated that contains a request execution error. If the command is correct, then the command itself is analyzed. If the command refers to interaction with databases, then the algorithm for interaction with databases is started. If the command refers to the launch of testing or the launch of auto-deployment of the infrastructure, then the algorithm for the initial check of the user's configuration file is launched. After successful verification of the configuration file and if the command does not belong to those listed above, the message is sent towards the required system module (100).

[0050] Algorithm for interacting with databases. If the command relates to interaction with databases, the query orchestration module (101) independently accesses the required database. For this, there is a mechanism for connecting databases, which can be implemented using: an additional program script that implements interaction with the database API (104) (for example, when integrating with MongoDB); an additional program script that implements SQL-like queries to the database (104) (for example, when integrating with MySQL); as well as any other known methods of database integration. Upon receiving a message of the category of interaction with the database (104), the query orchestration module (101) parses the message and determines the database (104) to which it is necessary to execute the query. Having received this information, the request orchestration module (101) refers to the specified method of communication with the database (104), where it transmits the connection information and the request contained in the message.

[0051] Next, a connection to the database (104) is formed, and the request from the message is converted into an API call to the connected database (104) or into an SQL-like query that is sent to the database (104). Based on the results of the command execution in the database (104), the query orchestration module (101) generates a response and returns it to the user or the module from which the incoming message came.

[0052] Algorithm for the initial check of the user's configuration file. Upon receipt of an incoming message with the task of starting testing or starting auto-deployment of the infrastructure, the request orchestration module (101) conducts an initial analysis of the correctness of the configuration file. Within the framework of this analysis, the following checks are carried out: the presence or absence of a configuration file in the incoming message, the completeness of the configuration file (correctly and completely read from the network message), checking the format of the configuration file (whether it corresponds to the format that the autoconfiguration module processes (102)), the presence of such the same configuration file in the database (104) with configuration files.

[0053] If the check is successful or if a configuration file is found in the database (104), the request orchestration module (101) sends the message further to the system modules (as well as technical information on the implementation directives, if it is in the database). If an error is detected, the request orchestration module (101) generates a response indicating the error.

[0054] An infrastructure autoconfiguration module in a virtual environment (102) is designed for automatic infrastructure deployments in a virtual environment from a user's configuration file, as well as for interacting with external tools at the user's request or other system modules outside the task of automatically creating an infrastructure in a virtual environment.

[0055] As input, the module (102) expects a user configuration file that describes the necessary infrastructure parameters. The configuration file is a data structure (yaml, json, xml), pre-formed for understanding by the system (100), in which certain keys (corresponding to the system data model and being immutable) correspond to any values (specified by the user and are the main configuration parameters infrastructure). In this case, the file consists of sections, each of which corresponds to the main key, which corresponds to the name of the third-party tool that should be processed.

[0056] The request autoconfiguration module (102) can process at least the following requests:

• requests to create infrastructure from a configuration file,

• requests for additional information in the framework of the creation of infrastructure,

• requests for additional information from databases of third-party tools,

• requests for information on the created infrastructure,

• requests for action for a number of third-party tools.

[0057] The infrastructure auto-configuration module in the virtual environment (102) implements the following algorithms.

[0058] Algorithm for connecting third-party tools. Connecting third-party tools to the system (100) implies the integration of the system (100) with the API of the plug-in tool. Integration consists in developing a script that implements the interaction of the system (100) with the API of the plug-in tool. To connect a new third-party tool, it is necessary to add information about this tool to the configuration: <tool_name>: {<tool_call_directory> <order_id>} - as well as an integration script that contains: an algorithm for checking the sufficiency of the configuration file in the part of the connected system that implements the verification of a part file, for the implementation of which this external tool is responsible for the possibility of implementing these actions and the sufficiency of information for the implementation of these actions, by comparing the structure of the configuration file (in its area of responsibility) with the template structure expected by this integration script, as well as checking the keywords with the expected , an algorithm for generating requests with the requirements for additional information about the deployed infrastructure, directives for providing additional information about the work performed, directives for translating information in the configuration file into specific API calls of an external installer umenta.

[0059] In the absence of information for the implementation of certain actions specified in the configuration file, the algorithm for generating requests with the requirements for additional information about the deployed infrastructure generates a request to the autoconfiguration module (102) to provide additional data from one of the previously used external tools (or to pass a request to the query orchestration module in order to get data from one of the databases).

[0060] Algorithm for sequencing the process of deploying infrastructure and adding dynamic activity. Upon receipt of the configuration file, the autoconfiguration module (102) analyzes the main sections of the configuration file to collect information on the required layers of the deployment. The information obtained is compared with information about the available integration scripts. Information about the main sections is assigned the value <order_id> corresponding to the value from the system settings (100) generated when adding integration scripts. After that, the main sections with the assigned <order_id> are ranked in order from lowest to highest. The resulting data array is an ordered list of launching integration scripts for deploying infrastructure in a virtual environment.

[0061] Algorithm for generating directives from a user configuration file. After the algorithm for ordering the infrastructure deployment process and adding dynamic activity, the auto-configuration module (102) transfers the configuration file to the integration script. The integration script checks the transferred integration file and, if successful, calls the directives corresponding to the API calls of the external tool. The correspondence between the configuration file, directive and API call is determined at the stage of development of the integration script and is expressed in the format of the description of the created part of the infrastructure in the configuration file. At the same time, when the directive is launched and the API call is launched, they are written to a separate file, where the launch order, name and arguments passed to the external system (100) are specified, which allows, as a result, to generate a file containing all the technical information about the infrastructure deployment (including information, which is additionally requested by the integration scripts as part of its work).

[0062] A directive orchestration algorithm to deploy infrastructure and add dynamic activity. After the algorithm for ordering the infrastructure deployment process and adding dynamic activity, the autoconfiguration module (102) transfers the configuration file to the integration script, starting from the minimum sequence number. The integration script implements the algorithm for checking the sufficiency of the configuration file in the part of the connected system (100).

[0063] If the data is sufficient, the integration script converts the configuration file into directives and API calls to an external tool. In case of insufficient data, it generates a request for additional information using the algorithm for generating requests with the requirements for additional information about the deployed infrastructure and sends it to the autoconfiguration module (102).

[0064] The autoconfiguration module (102), upon receiving a request for additional information, redirects it to the desired integration script. The integration script, having received a request for additional information, implements the directives for providing additional information about the work performed and returns the result to the autoconfiguration module (102). The autoconfiguration module (102) returns the result to the requesting integration script. The integration script analyzes the received information and either generates a new request to provide information (for example, to another module), or generates an error, or converts the configuration file into directives and API calls of an external tool, and then returns a response to the autoconfiguration module (102), which generates the answer for the worked out part of the integration scripts and sends it to the request orchestration module (101). After that, the auto-configuration module (102) proceeds to the next sequence number and transfers the configuration file to the next integration script.

[0065] Algorithm for isolating the created infrastructure. This algorithm is launched after infrastructure deployment in a virtual environment and infrastructure monitoring mechanisms in a virtual environment, if the need to isolate the infrastructure is specified in the user's configuration file. In order to deploy the infrastructure and add dynamic activity between the system with external tools and the virtual environment where the infrastructure is deployed, a network connection is created through which all tools implement their tasks on virtual machines in the created infrastructure. This network connection is created using the directives specified in the integration scripts. At the same time, scripts can also not use a direct network connection, but work through the available calls to the hypervisor. After all tasks are completed, the created connection is blocked for any use (inbound / outbound traffic) and the created environment becomes isolated from any outside network access. In this case, the environment is accessed only through the hypervisor. If there is a need to make changes after creating an isolated environment, the auto-configuration module (102) can deploy a pre-prepared virtual machine with all the data inside the created environment for making changes in automatic mode.

[0066] The testing module (103) is designed for automatic testing of cybersecurity events based on the information of the testing algorithms contained in the user's configuration file. The module (103) interacts with the query orchestration module (101) and with the created infrastructure in the virtual environment.

[0067] As input, the module (103) expects a user configuration file, which consists of three sections: a testing algorithm, a description of the infrastructure in which testing will be carried out, and a description of the mechanism for monitoring the created infrastructure. The configuration file is a data structure (yaml, json, xml), pre-formed for understanding by the system (100), in which certain values correspond to certain keys.

[0068] Description of the infrastructure, in which testing will be carried out similarly to a configuration file for the task of automated deployment of infrastructure in a virtual environment and may, among other things, be only a pointer to a saved (ready) configuration file in the system database (100).

[0069] Description of the infrastructure monitoring mechanism, in which testing will be carried out similarly to the configuration file for the task of organizing monitoring within the created infrastructure in a virtual environment and may, inter alia, be only a pointer to the saved (ready) configuration file in the system database (100)

[0070] The testing algorithm may include, but is not limited to, the following data:

• data on the impact on the infrastructure - this is information about the action that must be performed in the infrastructure for testing (launching a malicious file, launching an attack that consists of several steps, launching a particular traffic, performing an action of a workstation user, installing programs, etc.); can be a pointer to a stored (ready) action in the system database or a key-value set for creating a new one (depends on an external tool that is used to implement the action),

• data on the number of testing repetitions - the number of starts from scratch of the same testing (starting with the deployment of infrastructure in a virtual environment and ending with its destruction),

• dynamic test variables - values in the infrastructure description file in which testing will be carried out, which are subject to change during testing (can be in the format of an array of values for the key, if there are several of them); together with the number of repetitions, testing is meant with a change in certain parameters of the infrastructure in the amount indicated,

• data about the start of testing - can be one of the stages of the system operation (100) (for example, the end of the autoconfiguration module (102)),

• data on the end of testing - can be one of the stages of the system operation (for example, the end of the auto-configuration module (102)) or an event in the monitoring system from the deployed infrastructure,

• triggers for additional testing events - can be one of the stages of the system operation (for example, the end of the autoconfiguration module (102)),

• additional data about a testing event - it is analogous to "impact on infrastructure", but triggered by a trigger,

• data on the type of testing - automation or step by step,

• and any other data for testing in the field of cybersecurity, but not limited to.

[0071] The testing module (103) implements the following algorithms.

[0072] Algorithm for processing a test script. Upon receipt of the configuration file for testing, the testing module (103) generates requests to the request orchestration module (101) to check the received configuration file and obtain additional data. If the configuration file for testing contains links to the saved configuration files, then the request is generated in order to find and load these files from the databases. If the configuration file contains values for launching using external tools, then the request is formed in order to determine the correctness and sufficiency of the data for execution (the request is sent to the request orchestration module (101), which redirects it to the database or to the infrastructure autoconfiguration module in the virtual environment (102), from where it enters the integration module of the external system and is checked using the algorithm for checking the sufficiency of the configuration file in the part of the connected system).

[0073] If these checks are successful, the module (103) analyzes the contents of the test script, the infrastructure description file and the infrastructure monitoring mechanisms description file. If necessary, the testing module (103) enriches the infrastructure description with additional data (for example, the need to deploy a specific monitoring mechanism). If necessary (the presence of the infrastructure isolation property), the testing module (103) adds a pre-prepared virtual machine to the infrastructure description, which will implement the functionality of the module (103) in an isolated environment. After a successful check, the testing module (103) starts the task queue preparation algorithm.

[0074] Algorithm for preparing a task queue. As part of preparing a test plan, module (103) prepares a queue of tasks that must be implemented before testing begins. The configuration file generated by the user and the system (100) (at the previous stage) is divided into a test scenario and a description of the infrastructure. In accordance with event triggers (start, end, end), rules for monitoring these events are formed, and the configuration for their implementation is added to the infrastructure description.

[0075] The resulting infrastructure description file is processed in accordance with the infrastructure optimization algorithm (if specified in the test script). In accordance with dynamic variables, several copies of the infrastructure description are created (each of which contains its own value of a dynamic variable). After that, for each pair, a task is formed, which consists of the following subtasks: deploy the infrastructure, waiting for triggers for triggering an impact, triggering additional actions, ending testing, reacting to triggers, destroying the infrastructure, transferring data (results) to a centralized storage. Each task is replicated in the amount specified in the test script and added to the task queue. Then the testing algorithm starts.

[0076] Algorithm for testing. The testing module (103) transfers the infrastructure description and the testing script for processing to the infrastructure optimization algorithm in terms of determining the possibility of parallelism of testing launch. If such a possibility is determined, the module (103) creates the required number of threads and at one time receives an equal number of tasks (in the order of the queue) from the task pool. If parallelism is impossible, module (103) takes one task at a time from the task pool. After receiving the task, the module (103) generates a request for infrastructure deployment in a virtual environment for the infrastructure autoconfiguration module (102).

[0077] The autoconfiguration module (102) deploys the infrastructure and reports this to the testing module (103). The testing module (103) registers the events of the end of infrastructure deployment and, in the presence of isolation, generates a request to the configuration module (102) to deploy an additional control segment with an instance of the testing module (103).

[0078] The autoconfiguration module (102) expands the control segment and reports this to the testing module (103). The testing module (103) registers the events of the end of the deployment of the management segment and generates a request to add mechanisms for monitoring the deployed infrastructure for the infrastructure monitoring module (105).

[0079] The infrastructure monitoring module (105) organizes infrastructure monitoring mechanisms (taking into account the isolation or non-isolation of the infrastructure) and reports this to the testing module (103).

[0080] The testing module (103) registers the events of the completion of the deployment of infrastructure monitoring mechanisms and generates a request to the auto-configuration module (102) to isolate the created infrastructure, if it is provided by the testing scenario.

[0081] The testing module (103), if it is necessary to isolate the infrastructure, waits for the completion of this task from the autoconfiguration module (102) and goes into the waiting mode for event triggers. When the trigger is triggered, module (103) implements an event processing algorithm within the framework of testing. When a test completion event is detected, the module (103) generates a request to collect the received data (if the data was not output to the centralized database earlier). After collecting the data, the module (103) generates a request to the autoconfiguration module (102) to destroy the created infrastructure.

[0082] After destroying the created infrastructure, the testing module (103) proceeds to the next task from the test task queue. Then, after completing the last task, the module (103) generates a response about the testing (including by collecting and analyzing the received data in a report format) and sends the response to the user.

[0083] An algorithm for generating feedback with the infrastructure during testing. The testing module (103), at the stage of processing the test script, analyzes the adequacy of the description of the infrastructure monitoring mechanism. If necessary, the module (103) converts the triggers described in the test script into rules for filtering monitoring events and actions based on the result of filtering monitoring events, which are added to the configuration file for the infrastructure monitoring module (105), which implements the specified parameters during the execution of its task. In the absence of isolation of the created infrastructure, the testing module (SW) generates a configuration file for the infrastructure monitoring module (105) in such a way that the action on the result of filtering monitoring events will be to send a message to the testing module (103) via standard communication channels using such network attributes like IP address, port, etc. If the created infrastructure is isolated, the testing module (103) generates a configuration file and a request for the autoconfiguration module (102), within which (using the algorithms described in the autoconfiguration module (102)) the creation of a control environment integrated with the isolated infrastructure takes place and with a monitoring environment created using the infrastructure monitoring module (105). The configuration file for the infrastructure monitoring module (105) is generated in such a way that the action on the result of filtering monitoring events will be to send a message to the testing module (103) via communication channels created within the isolated infrastructure using such attributes of network interaction as IP address , port, etc.

[0084] The message from the monitoring engine received by the testing module (103) inside the isolated infrastructure will correspond to a specific trigger in the description of the test scenario.

[0085] If a trigger is detected, the testing module (103) determines which event (described in the testing scenario: start, end, launch of malicious activity, launch of a specific user action, etc.) this trigger belongs to and implements this event in the deployed infrastructure. If a test completion event is detected, the testing module (103) sends a request to the virtualization platform to destroy all virtual machines within this infrastructure.

[0086] An infrastructure optimization algorithm. This algorithm carries out two activities: optimization of the parallel launch of tasks from the queue and optimization of the built infrastructure.

[0087] Optimization of parallel execution of tasks from the queue.

The algorithm receives a description of the infrastructure and a test scenario. From the test scenario, the algorithm, by multiplying the number of values of dynamic variables by the number of test repetitions, obtains the total number of test runs (the length of the task queue). From the description of the infrastructure, the requirements for the capacity of the created infrastructure are formed (maximum values of RAM and CPU). If these values are not specified explicitly, then a query is made to the database in order to determine the settings of the virtual machine templates from which the infrastructure will be created. After that, the free resources of the virtualization platform are divided by 2 and then by the capacity requirements of one infrastructure. The result, rounded down, is the number of concurrent infrastructure creation threads.

[0088] Optimization of building infrastructure.

The algorithm receives a description of the infrastructure and a test scenario. The algorithm determines the availability of free resources after the infrastructure is deployed. If there are free resources, an action is added to the configuration file to deploy the simulation of additional network segments (the number is determined depending on the availability of free resources and indicated in the optimization section in the test script). The routing and location of the segments is chosen randomly, but with an optimal distribution relative to all other network segments of the deployed infrastructure.

[0089] The database (104) or databases are used at least for: storing user configuration files that describe infrastructure in a virtual environment and / or testing, version control of user configuration files, storing information related to user credentials, role models, user access rights, as well as information on the basis of which dynamic authorization of user requests can be carried out (inventory data about user devices, secrets for the interaction of system modules, certificates, history of user behavior and system modules, etc.), information storage required for the operation of the infrastructure autoconfiguration module (102), storage of files intended for the implementation of activity as part of the infrastructure deployment or impact in the framework of testing (for example, intelligent agents that simulate user behavior on virtual machines in a deployed infrastructure), storage of information related to the field of cybersecurity: data on vulnerabilities, security patches, malicious files, attacks, etc., storage of configuration information for the operation of the system.

[0090] The infrastructure monitoring module (105) is designed to organize a full cycle of processing events occurring in infrastructure objects created using the autoconfiguration module (102). The module (105) interacts with the query orchestration module (101), with the created infrastructure in the virtual environment and the testing module (103).

[0091] As input, the module (105) expects a user configuration file with a description of the required infrastructure monitoring mechanism. The configuration file is a data structure (yaml, json, xml), pre-formed for understanding by the system (100), in which certain values correspond to certain keys.

[0092] The description of the infrastructure monitoring mechanism is similar to a configuration file for the task of automated deployment of infrastructure in a virtual environment and may, among other things, be only a pointer to a saved (ready) configuration file in the system database (100).

[0093] The algorithm for organizing monitoring within the created infrastructure may include the following data (but not limited to):

• data on the type of monitoring mechanism - it is information about the monitoring mechanism that needs to be used: real-time monitoring - using standard tools (Splunk, Qradar, ELK, Zabbix, etc.), which is carried out directly in the deployed infrastructure, monitoring based on the results of activity in the infrastructure - collecting data for their subsequent analysis in an external system (PCAP, logs, etc.), monitoring using the virtualization platform hypervisor - monitoring at the hypervisor level in real time in order to increase the level of isolation and raise awareness,

• data about infrastructure objects that need to be monitored - represents information about the objects of the deployed infrastructure (an object means any created entity: virtual machine, data network, operating system, application, etc.), as well as specific event logs of these objects (for example, for the Windows operating system, these can be the Application, Security, System logs; for the data transmission network - metadata about network flows, changes in the configuration of network equipment, the "payload" of a network request, for example, during data transfer via the HTTP protocol etc.),

• Algorithm for processing monitoring events may include the following data (but not limited to):

• data on filtering rules for monitoring events - this is information about the selection of individual events that came from the monitoring object, for example, the event of a successful user logon to Windows OS, which came from the OS object from the Security log. Filtering rules can use any context available from the infrastructure description, for example, in addition to specifying objects of a specific type, you can also specify a specific object: "virtual machine with identification number X", "user Y", etc.

• data on actions based on the result of filtering monitoring events - this is information about the action that must be performed as a result of detecting an event that falls under one or another filter. Such actions can be: generating a new event, sending a signal in a given direction, saving to a database, discarding an event (destroying), etc.,

[0094] The infrastructure monitoring module (105) implements the following algorithms.

[0095] Algorithm for organizing monitoring within the created infrastructure. This algorithm is launched after infrastructure deployment in a virtual environment if the need for monitoring is indicated in the user's configuration file or upon request from the testing module (103) if an infrastructure monitoring mechanism is required for its correct operation. The user can specify one of three types of monitoring mechanisms within the created infrastructure.

[0096] In case real-time monitoring is specified (Fig. 2), the infrastructure monitoring module (105) makes a request to the auto-configuration module (102) to add a new virtual machine inside the deployed infrastructure and rebuild the network topology. The added virtual machine is placed in the deployed network topology as a separate network segment, routing to which is strictly limited for all participants in the network exchange: incoming connection is allowed on a narrow list of ports, outgoing connection is prohibited.

[0097] Similar actions are performed with network equipment to collect network traffic. Data is collected and stored in the same infrastructure where testing or any other user generated activity takes place. With this type of monitoring, the user can independently select or add a monitoring system.

[0098] If monitoring is indicated based on the results of activity in the infrastructure (Fig. 3), the infrastructure monitoring module (105) generates a request to the autoconfiguration module (102) to create a separate monitoring environment in which virtual machines with a monitoring system and base are deployed data (this separate environment may not be created every time from scratch, but a ready-made environment with deployed systems can be used, which provides storage of various datasets centrally in a single database). A pre-prepared virtual machine is created between the deployed infrastructure, according to the configuration file and the monitoring infrastructure, which is a gateway between the two environments - a "relay", specialized software is deployed on this virtual machine, which is a filter of passing data and implements the functionality of antivirus software, intrusion prevention tools etc. - any data transmitted between the two media passes through this filter, and if a threat is detected, the transmission is blocked.

[0099] The added virtual machine is placed as a separate network segment for two environments, routing in which is strictly limited to all participants in the network exchange: incoming connection is allowed on a narrow list of ports, outgoing connection is prohibited for the environment deployed from the user's configuration file; outgoing connection is allowed on a narrow list of ports, incoming connection is prohibited for the monitoring environment. A pre-provisioned virtual machine with database software is also added to the environment deployed from a user config file to act as a temporary database to reduce the impact on performance.

[0100] The added virtual machine is placed in the network topology deployed from the user's configuration file as a separate network segment, routing to which is strictly limited for all participants in the network exchange: incoming connection is allowed on a narrow list of ports, outgoing connection is prohibited. All virtual machines in the infrastructure are supplemented with specialized software and / or settings for collecting and sending event logs to the monitoring system.

[0101] Similar actions are performed with network equipment to collect network traffic. Data is collected and stored in the same infrastructure in a temporary database, from where it is transferred by “sets” to a “transfer unit”, which analyzes the safety of the set and transfers it to the monitoring environment in a centralized database, from where the monitoring system receives them for further processing and analysis. With this type of monitoring, the user can independently select or add a monitoring system (by adding a third-party tool using the algorithm for adding a third-party tool), as well as a system for collecting and sending event logs.

[0102] In the event that monitoring using the virtualization platform hypervisor (Fig. 4) is specified, the infrastructure monitoring module (105) makes a request to the autoconfiguration module (102) to create a separate monitoring environment in which virtual machines with a monitoring system are deployed and database (this separate environment may not be created every time from scratch, but a ready-made environment with deployed systems can be used, which provides storage of various datasets centrally in a single database). Data collection is carried out at the hypervisor level. Since all network interactions, as well as operations with the file system of a virtual machine, are carried out through the hypervisor, this data can be collected while passing through it and transferred to another virtual machine, which is located in the deployed monitoring environment. Also, at the hypervisor level, data is filtered for malware and, if suspicious data is found, it is blocked. After transferring the data to the monitoring environment, they are stored in a centralized database, from where they enter the monitoring system for further processing and analysis.

[0103] Algorithm for processing monitoring events. This algorithm is launched after the organization of the infrastructure monitoring mechanism and is designed to set filtering of events and actions obtained as a result of monitoring the filter results. All actions are performed according to the configuration file created by the user or by the testing module (103).

[0104] Module (105) analyzes the configuration file and translates its configuration (in terms of filtering) into specific directives within the previously specified monitoring mechanism. Directives in this case can be: YARA-description of filtering monitoring events; regular expressions; boolean logic and matching in key-value pairs; boolean logic and search for values in tags of such data structuring formats as YAML, JSON, XML, etc.

[0105] The module (105) analyzes the configuration file and translates its configuration (in terms of actions based on the filtering results) into specific directives within the framework of the previously specified monitoring mechanism. Directives in this case can be: sending a syslog message of a specific format to a specific address; launching an external pre-prepared script; sending a message over the data network in YAML, JSON, XML, etc.

[0106] The main process of the system (100) can be divided into two independent areas: automated deployment of infrastructure in a virtual environment and testing.

[0107] The task of automated deployment of infrastructure in a virtual environment implies the creation of infrastructure from scratch according to the configuration file and allowing the user to work in the created infrastructure as if he had done it himself in manual mode. The user creates a configuration file in YAML, XML or JSON format and sends a command to create the infrastructure from this file in the virtual environment. The file is downloaded via the web interface or via the command line interface. The client side forms a request, in which it adds a configuration file and sends it to the proxy server. The proxy server authorizes the request in accordance with its own internal settings. If successful, it redirects the request to the request orchestration module (101) of the server side, in case of unsuccessful authorization, the request is rejected.

[0108] The request orchestration module (101) performs the initial check of the configuration file using the algorithm for the initial check of the user's configuration file. If the check is successful, the request is sent to the infrastructure autoconfiguration module (102); if an error is found in the configuration file, the request is returned to the client indicating the error.

[0109] The autoconfiguration module (102), having received the configuration file, using the algorithm for ordering the infrastructure deployment process and adding dynamic activity, forms the order of using certain third-party tools for error-free building of infrastructure layers, in the order of the formed queue, the section of the configuration file is converted into specific directives for an external tool.

[0110] The directives formed at the previous stage are sent for execution to an external tool responsible for the implementation of these directives. An external tool implements the received directives directly in the virtual environment, or on deployed virtual machines and prepares the result of operations, which includes some (any) additional data generated as a result of the directives execution.

[0111] The result of the executions is returned to the auto-configuration module (102), where the processing cycle is repeated again with the next element of the generated queue, while using the directive orchestration algorithm in order to deploy the infrastructure and add dynamic activity, each external tool can generate a request for additional data from the tools, which have already completed their work (necessary for cases when the data for the operation of the tool can only be obtained as a result of the work of another tool - for example, installing software by IP address with dynamic assignment of IP addresses during the creation of virtual machines).

[0112] The auto-configuration module (102), after processing all external tools, generates and sends the result of the work to the query orchestration module (101). The query orchestration module (101), using the database interaction algorithm, saves the configuration file and all technical data generated by the result of the task execution into the database.

[0113] The request orchestration module (101) analyzes the execution of the user's configuration file, if it detects the need to organize infrastructure monitoring mechanisms, the module (101) sends a request to the infrastructure monitoring module (105).

[0114] The infrastructure monitoring module (105) analyzes the configuration file and, by means of generating requests to the auto-configuration module (102), adds the required monitoring mechanism to the created infrastructure.

[0115] The infrastructure monitoring module (105), after completing all its tasks, generates and sends the result of the work to the request orchestration module (101). The query orchestration module (101), using the database interaction algorithm, saves the configuration file and all technical data generated by the result of the task execution into the database.

[0116] The task of testing includes the task of automated deployment of infrastructure in a virtual environment, as well as a number of other tasks related to testing: impact on the infrastructure according to the test scenario (for example, automated launch of an attack), additional events that occur during impact on the infrastructure (for example, changing the network connection blocking table in response to the detection of suspicious traffic), repeating the test as planned (for example, performing the same test 10 times and comparing the results or collecting data sets), repeating the test with minor changes to the virtual infrastructure (for example , launching the same attack on the infrastructure 10 times, but each time the settings of one of the domain policies in the infrastructure will change).

[0117] The process of the system (100) during testing occurs in stages. The user creates a configuration file in YAML, XML or JSON format and sends a command for testing from this file in a virtual environment. The file is downloaded via the web interface or via the command line interface. The client side forms a request, in which it adds a configuration file and sends it to the proxy server. The proxy server authorizes the request in accordance with its own internal settings. If successful, it redirects the request to the request orchestration module (101) of the server side, in case of unsuccessful authorization, the request is rejected.

[0118] Next, the request orchestration module (101) transmits the configuration file to the testing module (103). The testing module (103) prepares the necessary data and conducts testing, for this it can access the request orchestration module (101), which in turn redirects the request to the infrastructure autoconfiguration module (102), the infrastructure monitoring module (105) or to the database (104), as well as directly into the created virtual infrastructure.

[0119] The test execution configuration file is evaluated for feasibility using the test script processing algorithm. After that, using the algorithm for preparing a test plan, a test plan is formed: what infrastructure will be used, what options for changing the infrastructure, if there are dynamic variables, how the impact will be triggered (remotely without isolation, or it is necessary to deploy a copy that triggers the impact inside the infrastructure), events reactions to triggers (similarly remotely or internally), the number of repetitions, the end of testing event, etc.

[0120] After the plan is formed, the test execution module (103) calculates the best test case using the infrastructure optimization algorithm and the simultaneous launch of several test cases (for example, when the number of runs or dynamic variables is specified) of the test.

[0121] After that, the module (103) begins to implement the test plan, for this, the following actions are performed in several threads (if possible): creating an infrastructure in a virtual environment, launching an action using the autoconfiguration module (102), creating infrastructure monitoring mechanisms using the infrastructure monitoring module (103), isolating the infrastructure, if necessary, using the autoconfiguration module (102), monitoring event triggers, triggering events using the autoconfiguring module (102) or directly, waiting for test end events, collecting data using the monitoring mechanism, destroying virtual infrastructure, repeated with the creation of a new virtual infrastructure (if multiple starts or dynamic variables are expected).

[0122] At the end of testing, the data is provided to the user in a similar way to the workflow for automated infrastructure deployment in a virtual environment.

[0123] FIG. 5 shows an example of a general view of a computing device (300) for implementing the system (100).

[0124] In the General case, the computing device (300) contains one or more processors (301) united by a common bus of information exchange, memory means such as RAM (302) and ROM (303), input / output interfaces (304), devices input / output (1105), and a device for networking (306).

[0125] The processor (301) (or multiple processors, multi-core processor, etc.) can be selected from a range of devices currently widely used, for example, such manufacturers as: Intel ™, AMD ™, Apple ™, Samsung Exynos ™, MediaTEK ™, Qualcomm Snapdragon ™, etc. Under the processor or one of the processors used in the device (300), it is also necessary to take into account a graphics processor, for example, NVIDIA GPU or Graphcore, the type of which is also suitable for full or partial execution of the system (100), and can also be used for training and applying models machine learning in various information systems.

[0126] The RAM (302) is a random access memory and is intended for storing machine-readable instructions executed by the processor (301) for performing the necessary operations for logical data processing. RAM (302), as a rule, contains executable instructions of the operating system and corresponding software components (applications, software modules, etc.). In this case, the available memory of the graphics card or graphics processor can act as RAM (302).

[0127] ROM (303) is one or more persistent storage devices, such as a hard disk drive (HDD), solid state data storage device (SSD), flash memory (EEPROM, NAND, etc.), optical storage media ( CD-R / RW, DVD-R7RW, BlueRay Disc, MD), etc.

[0128] Various types of I / O interfaces (304) are used to organize the operation of the components of the computing device (300) and to organize the operation of external connected devices. The choice of the appropriate interfaces depends on the specific version of the computing device, which can be, but are not limited to: PCI, AGP, PS / 2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0129] To ensure user interaction with the computing device (300), various I / O means (305) are used, for example, a keyboard, display (monitor), touch display, touch pad, joystick, mouse manipulator, light pen, stylus, touch panel, trackball, speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification (retina scanner, fingerprint scanner, voice recognition module), etc.

[0130] The networking tool (306) provides data transmission via an internal or external computer network, for example, Intranet, Internet, LAN, and the like. One or more means (306) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and / or BLE module, Wi-Fi module and dr.

[0131] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be construed as limiting other, particular examples of its implementation that do not go beyond the scope of the claimed legal protection, which are obvious to specialists in the relevant field of technology.

Claims (11)

1. An automated system for testing cybersecurity events, containing: • a query orchestration module associated with all system modules and a database, configured to redirect user requests to system modules, and the user request contains parameters for generating testing algorithms; • an infrastructure autoconfiguration module in a virtual environment that interacts with the API of external tools and is configured to automatically deploy infrastructure in a virtual environment from a user's configuration file using external tools; • a testing module capable of automatically testing cybersecurity events in the deployed infrastructure based on the information of the testing algorithms contained in the user's configuration file; • a module for monitoring events in the deployed infrastructure, capable of automatically adding monitoring mechanisms within the created infrastructure based on the data in the configuration file and processing events resulting from the activity of objects in the created infrastructure; • a database containing configuration files of users with specified parameters of algorithms for testing cybersecurity events. 2. The system according to claim 1, characterized in that it contains a proxy server that executes secure connection algorithms. 3. The system according to claim 1, characterized in that the testing module performs the testing scenario processing algorithm. 4. The system according to claim 1, characterized in that the testing module performs an algorithm for preparing a queue of tasks that must be implemented before testing. 5. The system according to claim 1, characterized in that the testing module performs an algorithm for generating feedback with the infrastructure during testing. 6. The system according to claim 1, characterized in that the testing module performs an infrastructure optimization algorithm in a virtual environment.

Images