Slack Interactivity URL

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-actions

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

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:

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

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:

If I then refresh the page I get prompted to auth with google and when doing so get the following error:

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

@ion_ 
I recently found out that webhook.site can be hosted intnerally
https://github.com/webhooksite/webhook.site

I don't think it helps you, but wanted to add just in case
andy

Ah this is cool, thanks @SoarAndy!

The idea of hosting another server to plug a communication gap between slack and SOAR is still a really confusing pattern and I wish the documentation didn't completely exclude this detail. Based on your role at Google and who you are, Andy, are you happy with this?

Hey @ion_ 

Check out this tines story I made to help respond to cases in chronicle. This helps to address the communications gap you've mentioned. With these slack messages users can respond with the buttons presented without having to click any external URLs. 

https://www.tines.com/library/stories/1265128/?name=triage-google-chronicle-cases-from-slack

Apologies I never saw this

The approval link should be in the format
https://<redacted> 443/#/approval-link?token=NaU52dGgVAB3Ijwf%2frxmkA%3d%3d.i%2ft9EGUwDl1%2fRaNcUMvD3f5yeI3e3WuIQSzZ8e%2bDLdfZGhp9CEaHORLgOLmiMpfsBQzPX%2bi3XoSkBuXs0yUUyibTXIrZz0OCdnhxvCsxC14%3d&hash=b7f06db7b4a12299f76eaa6d29d24ecdd3ae2e8a094500bcb3e95d0c0e69bc95 

As above, approval links require 0 access to GCP/SecOps and can be sent to any user