Andrey Amirakh, Security Vision
Timur Galiulin, Infowatch
In this article we will tell you about the process of automating routine activities in one of the IS departments of a large company.
Initial data: the information security (hereinafter - IS) division of a large company with a branch structure processes a large number of information security events both in the head office and in subsidiary offices across the country. The team for whom the automation work was done deals mainly with events related to data breaches. The primary source for IS events is the InfoWatch Traffic Monitor DLP system, which collects and analyses IS events across all branches centrally. Because the information collected by the DLP system is confidential, a limited number of people have access to the console, and both employees with full access and employees without access to the DLP system can perform leak analysis, investigations, and additional activities. In order to pass information to employees without expanded access, in the DLP system console, privileged users view events, mark them as violations, and then manually create a task to ‘troubleshoot’ for the employee in the branch where the leak occurred. The DLP system collects a large evidence base and the task is also accompanied by a file with attachments containing sensitive information. For security, this file is encrypted using a personal certificate and KryptoPRO. All this was done manually before the solution was implemented.
Tasks that needed to be automated:
- creating a request in the task tracker
- assigning tasks to employees of the branch where the leak occurred
- encrypting attachment files from the DLP system
- Adding encrypted attachment files to the created task.
Additional tasks that arose in the process of implementation:
- monitoring the state of users' personal certificates
- generating warning messages about expired certificates
- sending instructions on how to update a user's certificate
- reporting on DLP-system events
To achieve these goals, first of all, it was necessary to obtain event data from the DLP-system. As it turned out, DLP InfoWatch Traffic Monitor has two APIs:
- Data Export API
- Push API
Data export is responsible for getting data from the DLP system to third-party systems, while Push API allows you to load data from third-party systems into Traffic Monitor. As you have probably already guessed, the Data Export API was used to solve the project tasks. A temporary licence was requested for the period of pilot testing, and the only thing left to do was to choose a suitable orchestrator to do everything quickly and without much ‘dancing with tambourine’. The choice fell on the Security Vision platform, because out of the box it had advanced functionality for writing integrations with third-party services and also the fact that the platform allowed us to build reporting using the built-in reporting mechanism.
The only thing left to do was to implement integrations and make friends with the following components:
- DLP system (source of data on IS events)
- SOAR system (the main mechanism of process automation)
- CryptoPRO (file encryption mechanism)
- Task Tracker (a tool for distributing tasks to branch offices)
Firstly, we needed to access the Traffic Monitor Data Export API from the Security Vision platform. To do this, we requested an API licence from the developer and activated it on our InfoWatch Traffic Monitor DLP server installation. Once the licence is activated, it is enough to simply specify the API version, company ID, importer name and token in the request headers (company ID and importer name need to be specified when requesting the licence).
Screenshot 1 - Request headers in Security Vision Connector Builder
After SOAR and DLP communication is established, the most interesting thing starts - receiving data about information security events. According to the integration implementation plan, we need to retrieve the following information:
- Event ID in DLP InfoWatch Traffic Monitor
- Event header
- Date of interception
- Breach level
- Name of the sender of the sensitive information
- Sender's email
- Security policies triggered
- Intercepted files containing sensitive information
- Name of the administrator who detected and marked the event as a violation
To solve this task, we had to make four independent types of requests to the InfoWatch Traffic Monitor server:
- Obtaining IS events with metadata
- Receiving event file descriptions
- Getting the files themselves
- Obtaining data from system audit
The first request generates a list of tasks that meet the sampling criteria for pilot operation:
Screenshot 2 - Request for obtaining IS events
URL/xapi/event?filter[date][from]=start_unix_time&filter[user_decision]=
Violation&filter[object_type_code]= D2B5132E27DA11E28444C2DB6088709B00000000
&with[senders]&with[policies]&with[recipients]
In response to the query, the InfoWatch Traffic Monitor server gives an array with the events that fall under the filter in the query. The query is executed with a cycle of two minutes. Further data normalisation is performed on the fly in the Security Vision handler:
Screenshot 3 - HTTP request result processing window in the Security Vision platform
In the second request, based on the received event identifier, data about the related files intercepted by the DLP system as part of the breach detection is generated. In this case, we need to get the names of files, including those in archives:
Screenshot 4 - Request to get a description of the linked files
URL/xapi/event/event_id?with[]=files
The response to the second request is JSON containing detailed information about the captured file, but the value of OBJECT_CONTENT_ID is the most valuable for us:
Screenshot 5 - Result of the request to retrieve the related file description
The third request downloads the captured IS event file from the DLP system:
Screenshot 6 - Request to download linked files
URL/xapi/event/file/file_id/raw?download=1
Here FILE_ID is the variable name, the Traffic Monitor OBJECT_CONTENT_ID parameter is passed to it in the request constructor. Finally, to get information about the DLP system administrator who flagged the event as a violation, we had to access the system audit data using the following query:
Screenshot 7 - Query to retrieve the last 200 audit events
URL/xapi/audit?filter[entity_type]=Object&sort[change_date]
=desc&start=0&limit=200
Here limit is the number of audit events between two synchronisations, you should adjust it locally. After a small transformation of the response we get normalised data for each audit event of the DLP system. The CHANGER_NAME field here is the name of the administrator who changed the status of the event to a violation event:
Screenshot 8 - Normalising audit event data in the Security Vision platform
That's all done with DLP, now we need to enrich the data, encrypt files, start tasks in the tracker and build analytics on all collected data.
Enrichment is done through integration with Active Directory. The Security Vision platform has an LDAP connector type as a standard feature, it allows you to write queries in the GUI. The connector looks as follows:
Screenshot 9 - LDAP query of users from AD with filtering by the mail field
As a result of executing the command, you can get advanced information about a specific user, even if the input parameter is only one ─ email.
Screenshot 10 - LDAP query result
Once the data is received and the attachment files are downloaded to the server, Security Vision needs to generate an encrypted copy of the file to send to the tracker. Here is an example of a connector that performs the download and encryption operation:
Screenshot 11 - Downloading a file directly from DLP to the encrypting server's file system
curl -k -s \
-H ‘X-API-Version: 1.1’ \
-H ‘X-API-CompanyId: SecurityVision.’ \
-H ‘X-API-ImporterName: SV5Platvorm.’ \
-H ‘X-API-Auth-Token: api_key’ \
-o ‘/distr/shared/dlp/dlp_event_id.eml.’ \
‘https://dlp_server_name/xapi/event/dlp_event_id/raw?download=1"
The above request is downloading to another server, then encrypting the file using digital signature and CryptoPro. Note that the download of the root content is similar to the request at the beginning of the article, but it takes place in a different container with CryptoPro installed.
Screenshot 12 - Encrypting a file by calling the command from a container with CryptoPro installed
docker exec cryptopro bash -c ‘yes Y | cryptcp -encr /shared/dlp/dlp_event_id.eml /shared/dlp/dlp_event_id.eml.p7m’
rm -f /distr/shared/dlp/dlp_event_id.eml
The result of the two connector commands is the execution of the curl command to download the attachment file from the DLP system, the docker exec command to perform encryption of the file using the CryptoPro container, and the subsequent deletion of the original file. Going into details, the encryption server has a CryptoPro container that uses the /shared/dlp folder shared with the host, so the container sees the downloaded files and can interact with them.
The last step of the automation process is to send the received information to the task tracker. This task was the easiest to cope with, as modern task trackers mostly have well-documented APIs. In this case, the Redmine tracker was used, and all the work of the Security Vision platform was reduced to two simple actions:
- upload an encrypted file to the Redmine server and get the file token
- using API create a task and link to the uploaded file.
Using the HTTP connector it is easy to perform POST requests and process responses from the remote server.
Screenshot 13 - File upload command in Redmine
URL/redmine/uploads.json?filename=event_id.eml.p7m
Screenshot 14 - Processing the result of the file upload and getting the token
Next, using the token, uploaded file and HTTP connector, you can make a request to the Redmine API to create a task and get the task ID directly in the Redmine task tracker.
Screenshot 15 - Request to create a task in Redmine
<?xml version=‘1.0’?
<issue>
<uploads type=‘array’>
<upload>
<token>file_token</token>
</upload>
</uploads>
<project_id>163</project_id>
<subject>subject</subject>
<description>description</description>
<category_id>org_unit_id</category_id>
<status_id>7</status_id>
<watcher_user_ids>manager_id</watcher_user_ids>
<watcher_user_ids>reporter_id</watcher_user_ids>
<custom_fields type=‘array’>
<custom_field name=‘Branch’ id=‘25’>
<value>normalisation of branch</value>
</custom_field>
</custom_fields>
</issue>.
Screenshot 16 - Processing a task creation request in the tracker and getting the task id
I would like to point out the fact that the task is assigned to a specific branch office, and the org_unit_id variable from the task creation request is generated by requesting data from AD via the offender's email. The user_api_key is also formed in an interesting way (see Screenshot 13), it is actually a unique user ID in Redmine. The Security Vision system stores in the form of a table a mapping between the full names of those responsible for the DLP system and these tokens. At the stage of requesting metadata from the DLP system (see Screenshot 8), the Security Vision platform automatically compares the result and converts the full name into a token. This is necessary for the task tracker to clearly show on whose behalf the task was started.
The project resulted in a significant increase in the speed of processing incidents related to information leaks. Previously, after a leak was detected, the administrator of the DLP system spent about 30 minutes to create a single task, as he had to manually enrich the task card, find the branch, correctly assign the responsible person and observers, and encrypt the file. After implementation of Security Vision solution these processes are performed in automated mode without distracting the specialist from other work. Setting tasks for a large number of branches is almost completely automated. The administrator of the DLP system now only needs to mark events as a violation, and the SOAR system takes care of all routine work.
Help
The InfoWatch API contains several ‘pass-holes’ that further improve the performance of highly loaded SOAR system queries. The InfoWatch Traffic Monitor DLP system allows you to creatively realise the task in different ways. For example, combine multiple queries of the same type, exclude events remembered in the previous iteration, and efficiently utilise processing threads. If you want to learn other solutions, welcome to InfoWatch Academy.
Link to the documentation used in the article (DataExport API): https://kb.infowatch.com/display/TMSDK
Security Vision SOAR provides automation of response to information security incidents using dynamic playbooks with NWI application, attack chain building and object-oriented approach. The solution reduces the influence of the human factor, increases the speed of incident response, and builds proactive defence in accordance with international information security standards.
Security Vision SOAR aggregates events and incidents, performs automatic execution of commands on various external systems for rapid containment and remediation of negative consequences according to NIST methodology, with expert recommendations at various stages of incident management.
Product details: https://www.securityvision.ru/products/soar/
