Slack Interactivity URL

Hello

We finally moved to SOAR and are experiencing an issue with our first integration. 

I've enabled the Slack integration to allow SOAR -> Slack communication, however, it appears that Slack -> SOAR won't work unless I provide slack with an interactivity URL. This makes perfect sense, however, I can't find a good reference to this in the documentation. I've tried our base secops instance URL as well as a webhook that I created on SOAR, neither worked.

In my mind SOAR needs to host some code that catches these webhooks and give me a URL to configure in my slack app, is this correct? Alternatively, am I meant to self host the source code that is linked in the documentation and then put the URL I control into my slack app?

Any help would be appreciated, it feels like i'm missing something obvious

0 7 127
7 REPLIES 7

Hello,

Please read through Handling user interaction in your Slack apps here

As you mentioned you will need to self host the code (our public docs uses https://webhook.site/ as an example)as SOAR does not host this from what I understand. 

 

 

Hey Tony

Thanks a bunch for the response. I'm not sure if we're looking at different information, or if you're able to draw much better inferences than I am from the available information.

What I believe you're describing looks like this:
1). Playbook sends data from SOAR -> Slack (e.g. a message with a Yes/No response)
2). Slack sends data back to interactivity URL (e.g. Information about what was selected) 
3). Interactivity URL catches data and sends it back to SOAR

The documentation on slack app interactivity seems quite straightforward to me. If SOAR was not involved and I was fully in control of the code communicating with slack, I would feel confident that I can handle interactions. My uncertainty is based on not fully understanding how the slack integration works within chronicle and what is being expected. 

If I open up the IDE and compare the zip file vs the slack integration code, it looks the same. If I were to host the same code elsewhere, would that somehow link them? Im worried that self hosting just means I can catch the data from slack, but doesn't send it back to Chronicle (where I assume it needs to be to work within my playbook). 

Taking a look at the public docs at: https://cloud.google.com/chronicle/docs/soar/marketplace-integrations/slack
I can see mention of webhook.site in some sample output. Is this what you mean when you say that the docs use webhook.site? I've replicated this by sending data to a sample webhook.site URL and confirmed my belief that I can receive the slack data. However, i'm still not sure how to get it from the webhook back to SOAR. Can you help me understand how the last leg is meant to work? Is there another integration that sends slack data INTO chronicle that i'm missing?

Put plainly, how does the SOAR get data in asynchronously? Does it need to be processed elsewhere and sent to the API? Is there a way to tie in to the existing python code that seems to be running? Is there another paradigm I haven't encountered yet?


 

Ion, I don't know the end use case here, but have you seen Approval Links?  This is a native way (not limited to Slack) for SOAR to push a question to Slack (in the form of hyperlinks), and the user hits the URL taking them to a SOAR landing page.  In this method no 'interactivity URL' is needed, it's handled natively by the platform 

https://cloud.google.com/chronicle/docs/soar/respond/working-with-playbooks/assign-approval-links-in...

Then in the Slack action we can post the question, and each link with the slack markdown syntax embedded

Hi user, to follow playbook path 1 <[MultiChoiceQuestion_1.approval_link.answer1]|click here>

Or to follow playbook path <[MultiChoiceQuestion_1.approval_link.answer2]|click here>




Hi @SoarAndy 

I'm not quite sure on my use case as I thought I was just exploring basic functionality to see whats possible.  Lets say for now I just want to ask in a channel for a Yes/No response and then add that to the SOAR view.

Approval links look like a nice solution for the security team, but i'm not sure how I feel about my normal users clicking through on links to our SIEM. I'd like to avoid that if possible.

Going back to the slack integration, I think i've managed to understand the part that was confusing me. The slack integration is tightly coupled with webhook.site. It will only ever work with webhook.site. One can change the URL, but that won't change the functionality. Heres an example that didn't make sense to me until I lowered my expectations:

Screenshot 2024-07-23 at 11.42.41.png

The webhook.site api docs contain a very similar snippet:

Screenshot 2024-07-23 at 11.44.50.png

If we want this to work without webhook.site, we need to either create a webserver that functions in the exact same way as webhook.site OR update the native slack integration's python code.

We can draw up this flow if we make the following definitions: Chronicle instance (A), Slack (B), and webhook.site (C), we can draw up the flow:

0). We have to generate a webhook.site URL and put it into the Chronicle integration config and the slack app's interaction URL
1). Playbook triggers connection from Chronicle (A) to Slack (B)
2). Slack (B) receives the incoming message and writes it somewhere
3). Interactions with the message on slack (B) are sent to webhook.site (C)
4). Chronicle (A) queries webhook.site (C) for all responses and sorts by newest

@TonyH is this correct? And should it be this way?

re Approval Links
They point to a landing page on SOAR, they have no access to anything at all, other than to confirm, so no licencing/enablement/logon/access is required. 

But if you still prefer the other method I'll let you chat with Tony 🙂

Update - I see that not all Actions use Webhook site, 'Send Interactive Message' does , but 'Send Advanced Message', 'Send message',  'Wait for reply' do not, I assume you've tried those in combation?

Noted on that, I definitely don't want to die on this hill. I'm just concerned I start training my users for a weird flow. The way I see it, i'm asking people to get used to clicking on links to a website they've never heard of and don't have access to. A button abstracts the link click away and doesn't physically open their browser. Does that make sense?  

Happy to just get in line if approval links are the way forward and have better support throughout the platform though.

Hey Andy

Thought i'd give it a try. When I test with another user, I get a blank screen:

Screenshot 2024-07-23 at 16.31.19.png

If I then refresh the page I get prompted to auth with google and when doing so get the following error:
Screenshot 2024-07-23 at 16.03.28.png

If we want to use approval links, is it recommended that we give basic view rights on the GCP project to the entire org?