02 Nov GUARD: Security pipeline – a successful approach to threat identification and attack detection
The user dashboard has the objective to present all the services and features available in the GUARD framework to the user. The security pipeline is responsible for making the overall process as straightforward as possible and allows the user to deploy, start, stop, configure and delete services such as agents and algorithms in different environments within GUARD. The security pipeline approach centrally manages the individual security policies, agent and algorithm instances deployed to a certain environment.
The security pipeline workflow is a part of the GUARD security dashboard and aims to centralise the management of cybersecurity and threat management services and tools. Often, threat monitoring and detection services and tools are offered as stand-alone solutions and do not allow to be centrally managed along with other tools. This makes the monitoring and reacting job much harder as many steps need to be taken in order to confirm threats, data leaks or any other cyberattack. Thus, the process allows the user to centrally create pipelines for selected services that oversee the configuration and the state of such services in the environment it is deployed on. Once any unusual activity is detected and confirmed, the services trigger the central reaction and mitigation process that informs the user of such activities. The pipeline consists of four main components: security policies, execution environment, agents and algorithms.
The security policies are a set of constraints on system functions, data access and information flow of the systems and services in the GUARD environment. Such policies allow the user to specify rules to the services, namely agents and algorithms, that will be deployed in a certain domain. As can be seen in the figure below, the user is able to easily add any constraints and rules to the security pipeline in the text area “Security Policy”.
As the agents and algorithms already follow instructions and rules on what to monitor and how to react to security breaches, the security policies can be seen as additional instructions that the user wants to give to certain services. Such instructions might be related to rules on what to monitor, but can also describe what to do once security breaches have been identified. While creating or editing a security pipeline, the user has the possibility to add new security policies in the appropriate security policies text area.
The execution environment is the place where the security pipeline and its services are to be deployed. The environment can be a physical or cloud server, virtual machine, virtual network, device or another type of information system that hosts applications and services.
In the security pipeline, the user will need to select the execution environment. To do so, first of all, the agent and algorithm that are to be deployed are chosen, then the environment in which the agents and algorithms can be deployed on will be presented to the user. Note that, if an environment already uses the chosen agent or algorithm deployed in it, the selection of that environment is disabled. In this case, the user can edit the currently existing pipeline that manages the wished agent or algorithm in the environment.
The agent is the service performing the desired action by the user inside the environment, such as attack detection, threat identification, data tracking and trust and risk assessment. Once the agent is deployed on a server, it is seen as an instance of the agent by the security pipeline. A pipeline is able to manage one or more agent instances, as long as they are deployed in different environments.
While creating the pipeline, the user has the possibility to add a configuration to the chosen agent instances. By default, the instances use the configuration of the agent. However, the user can change this configuration by individually changing the configuration parameters of the agent instances, as well as by uploading a new configuration file to the instance. This can be seen in the exemplary figure below.
The algorithm works similarly to the agents. Both are deployed to a certain environment in order to detect attacks, identify threats, track data and assess risks. Once deployed in the environment, an instance of the algorithm is created. Such instances can be centrally managed and configured by the security pipeline. The configuration can be updated by changing the configurable parameters or uploading a new configuration file at any time. An example of the configurable parameters can be seen in the figure below.
Security Pipeline Actions
After applying the security policies, selecting the environment, agent and algorithm as well as configuring the agent and algorithm instances, the user is able to start the pipeline. This action centrally starts the pipeline which sends requests to the individual agents and algorithms to be started in the environment they were deployed on. Additionally, the security pipeline gives the user the option to stop and restart the pipeline, and reload the default configuration of the agent and algorithm to the deployed agent and algorithm instances.
Therefore, the user is able to easily create a pipeline with the desired services in a certain environment, set specific rules and configurations to these services as well as centrally start and manage the pipeline via the security dashboard.