Integrating ChatOps Into Your SOAR Program

What is ChatOps?

ChatOps is the built-in, no plugin required integration between InsightConnect and Slack. You can utilize this guide for detailed configuration instructions if you would like to get the connection up and running in your environment. Before we begin, let’s cover some of the amazing features of ChatOps.

ChatOps allows you to utilize the following actions:

Post Message - This can be used to send a message to Slack. This can be a response to a message, or a new thread altogether.

Post Interactive Message - This posts a message that is essentially a decision tree, allowing users to respond by clicking a button directly from the message that will take the workflow down alternating paths.

Look Up User By Email - This is exactly what it says. Perhaps you have a variable in an alert that contains an email address, and you would like your workflow to message the user. You can pass the email to this action, and then have a follow on step that sends a message to that user.

Create a Channel - Are there certain incidents or events that need immediate attention from multiple teams and personnel? We can have a workflow that spins up a war room.

Add Users to Channel - What good is a war room without the generals? Taking the scenario above, you know your key stakeholders for various types of incidents. Have them automatically added to the channel without wasting time.

ChatOps can be used as a trigger that kicks off your automation workflow, and it can also be used as a response step. I built two quick workflows that we will be using to highlight both. If you want to follow along in your own environment and you already have your integration setup, just remember that before InsightConnect can listen to or post in a Slack environment, the Rapid7 Slack App must be added to the channel you wish to use it in. You can find more details about the App here:

Workflow Examples

Now that we have our integration setup and we have the InsightConnect App added to the appropriate Slack channels, we are ready to get started with a workflow.

The first workflow we will be covering uses an EDR tool as the trigger. It monitors my SentinelOne environment for new threats and alerts, and then sends the alert to Slack for me to review. After reviewing, I have two options:

  1. I can mark the alert as a false positive and then close the ticket, or…
  2. I can quarantine the endpoint with SentinelOne.

Really quite basic, but how nice to be away from your computer at lunch, yet still have the comfort knowing you can perform quick triage and containment if needed.


I am going to start by choosing SentinelOne as my trigger that fires off the workflow anytime new threats/alerts are detected.

I named my trigger NewThreat. All the variables created from this trigger will follow a naming pattern that begins with {{[“NewThreat”].[something]}}. InsightConnect intuitively creates the variables for you as you create steps, and the variables are named in accordance to how you name your steps. If you are following along and wondering why the variable names don’t match, it is due to your step name not being the same as mine.


Next, I want the alert to go to my designated Slack channel. This is accomplished by selecting ChatOps, and then choosing “Post Interactive Message.” Notice how ChatOps a unique step in the workflow builder.

Screen Shot 2022-11-11 at 11.11.03 AM

Every time the ChatOps step is used, we will need to fill out the Slack channel that we want to use. Generally I have multiple ChatOps steps in a workflow, so I utilize parameters for the channel name. To do this:

  • Click inside of the white box where you can enter the channel or @username, then select the blue + icon in the bottom right.
  • To create or use a parameter from within a step you will always scroll to the very bottom, as seen in the screenshot below.

Screen Shot 2022-11-11 at 11.14.51 AM

We see no parameters here because we haven’t created one, so let’s do that now.

  1. Select “+ Add Workflow Parameter” and give it a name. I will name it “Slack Channel.”
  2. Choose the input type. This parameter will be a string.
  3. You can give a description. If you are building this for other people, you might put something like “Input the name of the Slack channel where this workflow will run.”
  4. Lastly, we will provide the actual channel name that we are using for this workflow.

Now that we’ve created the parameter, let’s click that blue + icon one more time, scroll all the way to the bottom and choose our newly created parameter called {{[$workflow].[Slack Channel]}}. Now anytime you have a ChatOps step and need to input the channel name, you can simply choose the parameter that you created. Once your testing is done and the workflow is ready to move to production, you need only change the channel name one time in the workflow setup wizard, and it will change it everywhere you used that parameter.

Now I will choose the message that I want to go to Slack. I want the alert to go to Slack, but I only want key details so that I can make a quick decision. My SentinelOne trigger automatically created a crazy list of variables that are available for me to choose from when deciding what I want in my message. For simplicity’s sake, I will choose the threat description and the computer name.

Screen Shot 2022-11-03 at 10.00.34 PM

If you notice in my screenshot above, a message will be presented to the user when the alert comes through. The question “How would you like to proceed?” is generated by filling out the “Response Question” in the “Post an Interactive Message” configuration.

Interactive message 1

Because I chose to post an interactive message, I have to give my analyst some choices. These choices are accomplished through buttons, which are visual representations of the paths that you create in the workflow. The default is two buttons, but you can add more if you have more than two paths. My two paths are “Quarantine Endpoint” and “Mark as False Positive.”

Button Style is the color of the button, and there are a couple different options:

  • Primary buttons display in a green font and border
  • Default buttons display in black
  • Danger buttons display in red

Since quarantining the endpoint could be considered the more destructive path, I will choose Danger for the style so that the button displays in red.

When you hit Continue, you will see an example of the message that will be sent to your Slack channel. Upon hitting Continue again, we will choose our timeout settings. This lets you select one of the two paths created as the default path when a timeout occurs, or you can choose to go down an entirely new path altogether, should no one from your security team choose an option within the set amount of time.

Screen Shot 2022-11-21 at 2.37.20 PM

This is really powerful, because it allows you to take something like a critical alert, and know that even if it is Christmas Day and nobody is available to respond to an alert, the asset could be contained within the specified timeframe.

As you can see below, the “Post Interactive Message” action that we titled ThreatFound has essentially created a decision tree. We now need to map out what will happen when our analyst selects one of these paths: “Quarantine Endpoint” or “Mark as False Positive.”

Screen Shot 2022-11-21 at 3.31.48 PM

Path 1: Quarantine Endpoint

For my Quarantine Endpoint path, I’m going to add a new step using the SentinelOne plugin. This time, I’ll use the Quarantine action.

I like the warm and fuzzy feeling of confirmation, so I want to use the amazing power of ChatOps to post a response that shows me the status of the quarantine success in the form of True or False. To accomplish this, I’ll do the following:

  • In the workflow builder, add a new ChatOps step and choose the “Post Message” action. Since this message is only intended to inform the analyst whether the quarantine was successful, there’s no need to use “Post Interactive Message.”
  • For our channel name, I will again select the Slack Channel parameter that was created earlier: {{[$workflow].[Slack Channel]}}.
  • I want to post the quarantine success status to the same thread the original alert came into, so I will utilize the “To post in a thread, select parent message timestamp” section. I’ll populate it with the timestamp variable of the original Slack message that the new SentinelOne alert triggered. My original ChatOps step is labeled ThreatFound, and that is the thread that I want to reply to, so I will click that blue box with the + icon again…

Screen Shot 2022-11-11 at 11.33.50 AM

…and select the variable {{[“ThreatFound”].[timestamp]}}. If you do not select a timestamp, the message will create an entirely new thread.

Now we’ve added steps to our workflow to Quarantine the endpoint, and send us a Slack message confirming that the Quarantine was successful.

Path 2: Mark as False Positive

For the second button, if my analyst selects “Mark as False Positive”, I want my automation to update the analyst verdict to “False Positive” and then update the incident status to “Resolved.”

To accomplish this, I need two more SentinelOne actions. Before that, however, I’ll have to add a new step type due an incompatibility between the output from the SentinelOne Trigger and the expected input of the SentinelOne actions.

More specifically, the new SentinelOne actions want the threat ID as an array (AKA a list), but the trigger output of threat ID is a string of text. To overcome this, I can use an awesome plugin from the Extension Library called Type Converter. Once installed:

  • Add a new step in the workflow builder, choose Action, and select the Type Converter plugin. Choose “String to List”, and select the threat ID variable as the input. Mine is called {{[“NewThreat”].[threat].[id]}}

Screen Shot 2022-11-03 at 10.01.32 PM

  • Next, I’m going to add a new SentinelOne step to my workflow. Select the “Update Analyst Verdict” action and choose the output from the previous type conversion step as the Threat ID input for this step.

Lastly, we want to update the status of the alert to be “Resolved”, and confirm in chat that the incident was closed successfully.

  • Add a new SentinelOne step to the workflow, and select the action “Update Incident Status.” Choose the output from the previous type conversion step as the Threat ID input for this step.

  • Add a new step, this time ChatOps. Choose the Post Message action and input the channel name parameter used in previous ChatOps steps. Now we can use the $success variable created from the previous SentinelOne step to show that it was successful. Mine is called {{[“update verdict”].[$success]}}

Final Workflow

This completes our workflow. Remember, this was a simple example of what can be done with ChatOps. We will dive deeper into ChatOps in the next post where we utilize Slack as the trigger to kick off a workflow.

Feel free to post any questions or comments relating to this workflow, or other workflows where you want to utilize the power of ChatOps.

Workflow Overview

1 Like