In search of a security incident response system for the masses, Part 2: A Minimal Deployment

Introduction

This article is the third instalment in the series presenting STIR (Security Telemetry and Incidence Response) project, the previous articles introducing STIR (In search of a security incident response system for the masses) and showing one of its potential applications (Detect and stop exfiltration attempts with F5 Distributed Cloud App Infrastructure Protection). The goal of the current article is to show how STIR can deployed and configured in a minimalist way.

You may recall that one goal of STIR is to allow for a very easy deployment of all its components. This is achieved using Terraform or Helm chart packaging and although the deployment of the containers requires one single command, configuring these components to communicate with each other and have a minimal setup is a slightly lengthier process.

Configuration

We should start with the internal diagram of STIR, showing the components that will be deployed via Terraform/Helm, some of them needing further configuration.

 In this article we will go over:

1. A sample Terraform file
2. A basic Helm chart configuration file
3. Initial setup up of Cortex
   • Creating an administrator account
   • Creating an organisation
   • Creating admin and analyst accounts for the new organisation
     
     
4. Initial setup of MISP
   • Changing the default administrator password
   • Editing the default organisation details
   • Creating a sync user
     
     
5. Initial setup of TheHive
   • Changing the default administrator password
   • Creating a new organisation
   • Creating admin and analyst accounts for the new organisation
   • Activating a webhook allowing TheHive to send event notifications to Node-Red
     
     
6. Applying the new configuration file
   • Editing the Helm chart configuration file
   • Re-applying the Terraform configuration
   • Bringing up a new TheHive container

A sample Terraform file

You can examine a sample Terraform file that will deploy STIR on AWS EKS and expose its components to the Internet through F5 Distributed Cloud LoadBalancers here.

Note: Terraform will output a kubeconfig file (./_output/kubeconfig) that will be useful in connecting to the cluster via kubectl.

A basic Helm chart configuration file

You can examine a sample Helm chart configuration file here. This is the initial STIR configuration applied by Terraform. Once STIR components (Cortex, MISP, TheHive) get configured by the administrator through the GUI with user accounts (and API keys are generated) we will modify the Helm chart configuration file accordingly and re-apply it via Terraform, configuring TheHive with the new information - this is the last step of this procedure.  

Note: The Helm chart configuration file should be placed in the same folder as the Terraform script.

Initial setup up of Cortex

Cortex will require a database update when is accessed for the first time after it was deployed:

Note: the URL to access Cortex (and all the other STIR components) will be shown as the output values of Terraform.

You will be required to create a new administrator account:

You will then see the login page:

Once logged in as administrator, proceed to create a new organisation:

 Create new admin and analyst user accounts for this organisation:

Create new passwords for both these user accounts and a new API key for the analyst user account.

Initial setup of MISP

Login with default admin credentials (admin@admin.test / admin)

Change the admin account password:

 

You can edit and change the name of the default local organisation:

Create a Sync user account and retrieve its authentication key:

Initial setup of TheHive

Login with default administrator credentials (admin@thehive.local / secret) and change the administrator’s password.

 

Create a new organisation:

 

Create an analyst and an organisation admin user account:

 

Create new passwords for both these accounts and a new API key for the analyst account:

Activate the webhook that will allow TheHive to send event notifications to Node-Red by executing the following bash script and providing the organisation admin credentials (having permission manageConfig) created above:    

read -p 'Enter the URL of TheHive: ' thehive_url
read -p 'Enter your login: ' thehive_user
read -s -p 'Enter your password: ' thehive_password


curl -XPUT -u$thehive_user:$thehive_password -H 'Content-type: application/json' $thehive_url/api/config/organisation/notification -d '
{
  "value": [
    {
      "delegate": false,
      "trigger": { "name": "AnyEvent"},
      "notifier": { "name": "webhook", "endpoint": "node-red" }
    }
  ]
}'

Applying the new configuration file

Edit the Helm chart configuration file by providing the Cortex analyst user API key and the MISP sync user authentication key under their respective TheHive sections and TheHive analyst account API key under the ElastAlert section.

Re-apply the configuration by issuing “terraform apply” command.

Delete the stir-thehive-xxxx pod using the “kubectl delete pod stir-thehive-xxxx --kubeconfig ./_output/kubeconfig” command. TheHive should restart in a new pod having the updated configuration.

At this moment, TheHive should successfully connect to Cortex and MISP components – you can check this by verifying the icons in the lower right part of the main TheHive screen – and send event notifications to Node-Red while ElastAlert should be able to push alerts from ELK to TheHive.

Conclusion

This article describes the procedure required to provide STIR with the minimal configuration needed for internal connectivity between its components. More advanced configurations like setting up Node-Red automation flows or MISP connectivity to other organisations are not part of the scope of this article but this minimalistic setup can be used as a starting point for building a true open source security incident response system for the masses.