The number of IT security incidents in the enterprise is constantly increasing, and the security of the internal infrastructure is a permanent challenge for many companies, whether the company's Security Operation Center (SOC) maintains its own team for incident analysis – a Computer Emergency Response Team (CERT) or Computer Security Incidence Response Team (CSIRT) – or initially handles monitoring and incident response as a task itself.

In addition to already fairly extensive tasks (e.g., keeping a constant eye on the infrastructure, detecting attacks at an early stage, and containing the damage attackers potentially could cause), SOCs also have other responsibilities. Incident management, authoring and monitoring situation reports, and information protection with classic risk management and business continuity are all relevant to risk prevention. As an analyst, then, you are dependent on established reporting tools and techniques for the continuous analysis of data to conduct root cause research reliably and respond to the threat in the event of damage.

Threat intelligence analysis uses a variety of tools to help gather information and share insights. Various tools let you process security incidents. In addition to GRR Rapid Response [1] or MISP [2], the list of free incident response platforms includes The Hive [3], which is being further developed by analysts from SOCs and CERTs and already offers a successful environment for automation-capable analysis of large and small volumes of data with its basic feature set – above all, thanks to its flexible extensibility. To connect to other platforms and engage in an exchange with other analysts, the developers rely on MISP, an established sharing platform.

Cortex [4] is another tool that provides additional functionality for analysis with what are referred to as "neurons." The analyzers let you connect to external tools to check observables that serve as indicators of compromise (IoCs) of your analysis cases. The responders support immediate actions for matching analysis results, such as sending email for information or blocking DNS queries for certain malicious domains in your company.

Both tools support granular configuration and complex setups for daily use.

Setting Up The Hive and Cortex

Before I address the details of using The Hive, you will need a running instance of The Hive and Cortex with appropriate dependencies. At the time of writing, version 4.1 of The Hive was just released. The documentation [3] explains different ways to install, depending on which operating system you are using.

If you initially want to set up The Hive and Cortex for testing purposes only, Docker containers are particularly useful as a runtime environment. The project environment has its own Git repository [5], where you can pick up ready-made scripts for Docker Compose configuration files for different setups, which means you don't have to go into the details of configuring the components. To download the contents of the repository, use the command:

git clone https://github.com/TheHive-Project/Docker-Templates

In the remainder of this article, I use the containers of the Compose files available from the repository with version 4.1 of The Hive, version 3.1 of Cortex, and Nginx with HTTPS. These files can be found in the subfolder docker/thehive4-cortex31-nginx-https.

The Readme file included in the directory describes the steps needed to set up the environment. As the first step, create a certificate for the Nginx proxy and copy it to the correct location in the Nginx container volume:

openssl req -new -nodes > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req-signkey key.pem -days 365
cp cert.pem vol/ssl/nginx-selfsigned.crt
cp key.pem vol/ssl/nginx-selfsigned.key

Then, edit the Nginx configuration for The Hive in the ./vol/nginx/thehive.conf file and for Cortex in the ./vol/nginx/cortex.conf file to match your environment. In the simplest case, just update the value of the server_name directive. If you are running the containers locally, enter

server_name thehive.localhost www.thehive.localhost;
server_name cortex.localhost www.cortex.localhost;

and extend the entry for IP 127.0.0.1 in the /etc/hosts file to include these four names.

Before customizing the .env file with the API key for Cortex, manually create the network referenced in the Compose file and then start all the containers with the commands:

docker network create proxy
docker-compose up -d

After starting Cortex, open the web application by typing https://cortex.localhost/ , update the database when prompted by Cortex, and create an initial administrative user for your login. With this account, you will then log in directly to the user interface. To integrate with The Hive, you first need a new organization within Cortex. The automatically created organization, named cortex , cannot be used for this purpose, because you cannot create normal users in it. Therefore, create a new organization by clicking on Organizations | Add organization . Choose an arbitrary name and enter a short description of the organization. In the resulting list, click on the organization you just created and press Add user to create a new user. Fill out the name fields accordingly and keep the role setting of read, analyze .

After clicking on Create API Key in the line with the new user, press Reveal to display the generated API key, and copy the key into the .env file's variable definition. While you are currently in the user overview, you can create another user in this organization directly and assign the read, analyze, orgadmin role to this user as the organization's administrator. With this role, you then configure the analyzers and responders in the next step. For The Hive to now adopt the updated API key and connect to Cortex, stop and remove the corresponding container and restart it directly:

docker-compose stop thehive
docker-compose rm thehive
docker-compose up -d

If you do not start the containers as the root user, you will need to update the access rights to the files in the mounted folders by setting your current user as the owner of the files and restart all the containers,

chown -R `id -u`:`id -g` vol/*
docker-compose stop && docker-compose start

just to be on the safe side.

Analyzers

Cortex provides different analyzers for further analysis of the observables of an incident. The Hive comes with 16 different observable types. Among them are IP addresses; domain, host, and file names; and entries in the Windows registry. During incident handling, you will document these observables with a corresponding context, content, or date and time, which become IoCs.

The analyzers in Cortex now let you gather more information about observables. For example, you can discover the details of a domain name or the IP address of a connection or check for the existence of a host in email spam lists. Suspicious files can be uploaded to virus scanners, and the results can be used for further processing. Before you use these tools, however, you need to enable them for your organization and configure them accordingly.

Now when you log back into the Cortex interface, use the administrator role for your organization, which you just created for the login. Working with this account, you can now select the Organization | Analyzers tab and display all available analysis tools (Figure 1).

Figure 1: Overview of available analyzers in Cortex that search for specific tracks.

Scroll through the list and select the analyzers you want. Some of the analyzers use commercial services, so if you already use these in your company, you can enable them directly and enter your access data or API keys for use in the configuration pop-up. To demonstrate the usage, first enable three free services – GoogleDNS_resolve , Robtex_IP_Query , and SpamhausDBL – by pressing Enable .

You do not need to change anything in the specific settings of these three analyzers for the time being, so you can press Save in the lower area of the overlay. If you occasionally process confidential content during incident handling that you classify according to the Traffic Light Protocol (TLP) [6], you will want to set the TLP filter here to the maximum permitted level for the information sent to service providers. In addition to the TLP, you can also configure settings for the Permissible Actions Protocol (PAP) [7]. PAP specifies which activities you are allowed to perform with a resource that underlies an item of information – in particular, how invasive the performed activities are allowed to be. The Rate Limiting setting lets you configure an appropriate interval to regulate the number and frequency of requests.

Right now, you could try out the analyzers you just enabled by clicking on New Analysis from within the Cortex interface. To continue the integration of Cortex into The Hive, you should skip this step for now.

Responder Actions

After enabling the analyzers, now select the Responders tab. You will find a similar overview with small tools that help you respond to the incident findings. For example, if you use Cisco Secure Endpoint at your end, the Cortex AMPforEndpoints responder will isolate directly affected end systems for the duration of your investigation and then revoke this isolation when your work is complete.

The DNS_RPZ responder lets you add suspicious or dangerous domain names to a response policy zone on your DNS resolver and thus redirect or block access to these domains. You can also connect to a ticket system (e.g., Redmine is supported by default with the Redmine_Issue responder) and automatically post tickets for coworkers. On enabling, you have to enter credentials to access your Redmine instance and select the required project.

To avoid going beyond the scope of this article, only enable the Mailer responder at this point, which will dispatch email with information about your incident. Save an email account in the configuration that you can use for test purposes. Filters can also be configured for the responders to reflect the TLP and PAP levels. Because you are sending data from your incident with the mail responder, you should use these filters to prevent unintentional disclosure of confidential information.

To avoid inadvertently generating unnecessary traffic or spam, set a rate limit for each responder. Of course, all of these settings can be adjusted later if you suddenly find they no longer fit your company philosophy or the operational environment.