Endpoint Security Part 5: How to setup an automated isolation workflow when malware is detected

Cyber Security Automation

In this continuing series on endpoint security protections I'll be showing you how to fully automate host isolation using 'Tines' and 'Elastic'.

This article assumes you are familiar with using Elastic SIEM and have some exposure to Tines.  Tines is a smart automation workflow solution that I came across last year.   What I like about it compared to other automation solutions that I have used in the past is that it is simple to use but at the same time very powerful.  It has a large library of workflow's or what Tines refers to as stories so that you don't have to start from scratch.

For more info about their offering you can check out their solution page here - Tines Solution Page.


In this example scenario I will be using a Microsoft Windows Server with an Elastic Endpoint Security agent deployed.  You may have another security agent deployed in your environment and as long as it supports host isolation the steps I'm going to show you will be fairly similar.

We will be using Elastic SIEM and this article assumes you have already configured the basics in terms of setting up the SIEM, deploying your Elastic Security agent, configuring your Elastic Defend policy and pulling logs from your host.  Once you have got to this point we will be following the steps below!


In the steps below we will be configuring and enabling a security rule to trigger whenever malware is prevented or detected on a host.

When the alert is received the rule will action a Tines workflow to isolate the host based on its unique endpoint ID.  Once the endpoint is isolated it will then:

  • email the security SOC team
  • create a  case in elastic

Step 1 - Configure your Tines Story

In this step we will configure our Tines Story which I have named 'Isolate a host in Elastic'.

The screenshot below shows the full story with all of the components that make up the workflow.

Tines Story - Isolate Elastic Endpoint

The only required parameters for the story are:

  • your Kibana url
  • your elastic user name to authenticate to your elastic instance
  • your corresponding elastic username password

Once those parameters are supplied you are all set to go.

The only other parameters and configuration you will need to supply to Elastic in order for it to connect to Tines are your Tines instance URL and your API Token.  These are shown in Step 2 below.


Step 2 - Setup your Tines Connector in Elastic

In this step we will setup a connector for Tines.  To set this up you will need the url of your Tines instance and your Tines API key.

Your Tines webhook URL is found by selecting the webhook object and looking at the details in the window to the right od the screen, as shown in the screenshot below.


webhook url for Tines

To create a Tines API Key select the 3 dots next to your profile name in the Tines console as shown below.

Tines Profile API Keys

Then Select 'Add API Key'.  Give it a name and copy the value of the key down and keep it in a safe place.  IMPORTANT: If you forget to do this you will have to create a new key as it is not shown again.

Tines Add API Key

Step 3 - Rule Settings 

In this step we configure a Tines connector.  To do this we:

  1.  Select our 'Malware Prevented on Endpoint Rule' and select edit settings
Malware Detected Rule
Endpoint Rule edit settings
  1. Then select Add Action and select the 'Tines" connector type


Tines Connector Selection

2. Then select the Tines connector from the drop down.  NOTE:  You will need to have previously created a Tines Connector and provided the URL to your Tines instance and required authentication API token.

Tines Connector Details

3. Leave the Action Frequency as default 'per rule run'

4. Then select your 'Tines Story' from the dropdown.  NOTE:  You will need to have preconfigured your Tines story in order to select it here as detailed in Step 1 above.

5. Then select your Tines Webhook action from the drop down.  This is the webhook action in your Tines story.

6. Then save your changes.


Test your rule and Tines Story

To test the Elastic Security rule and to make sure that Tines story is working correctly I'm now going to trigger some 'Test Malware' on my test host.

In this example I'm going to use a test sample from Palo Alto Networks.

Depending on your security settings in your browser you may need to make an exception so that you can test the file.


Windows Host - Download Malware

Once executed you should see an Elastic Security agent popup window appear in the right hand corner of the task bar.  This will indicate that the file is suspect and has been prevented from running.

Malware Detected Popup

View the results in Kibana

Switch back to your Kibana console and you may have to wait a couple of minutes until the rule triggers again.

Once it has you will see a tag appear next to the host status to indicate it has now been isolated.

Endpoint Isolated Tag

You should also receive an email with the details of the event and a case will have been created for your analyst to look at and comment on.

Elastic Isolation Email Alert

As well as the email alert, Tines will have also created a 'case' in your Elastic SIEM for your analyst to follow up.  This is shown below.

Elastic Case


That's it for this article.  We have showed you how simple it is to create a Tines workflow to isolate an endpoint, send an email alert and create a case in the SIEM.  You can obviously play around with your Tines story and add additional triggers / decision making to make it more intuitive but hopefully that has given you the basics to get started.

If you are interested in finding out more or would like assistance on your specific security projects please get in touch.


Leave a Comment