Sally Security Concerns - PSA

So wait, just to make sure I understand this correctly:

If say Gainsight were to have customer (not employees) from Company ABC added to their internal Slack instance, a Gainsight employee could add Sally to a channel those customers were a part of and share other customers (e.g., Company 123) data?

Does that mean that Gainsight could be exposing customer data to other customers as well? @anirbandutta even if 0 customers use Sally, seems like a potential liability for Gainsight as well no? Can we get a response from security on this?

@bradley exactly. That’s what we did in our testing, with our shared Slack Connect channel with Gainsight. 

I received no response from security on my support ticket. The TL;DR I was told by the support agent was “tell your users not to do that”. 

Copied the response below:

Hello Gunjan, 

The sally bot when it is added to any slack channel(private or public) by a user of your Gainsight Instance for whom Sally is enabled, the commands given by that user in the channel to sally bot, then the bot throws the info as the output irrespective of who are the members of that channel.

So here, we cannot restrict or constraint Sally Bot to display only specific fields into the output. Added to that, when a member of the slack channel who is not a user of your Gainsight Instance and also not have Sally enabled for him/her cannot give commands to sally bot. 

So here, it is up to the users of Amplitude's gainsight instance who have sally access to add the sally bot to a slack channel or not. So considering the above mentioned specifications of the sally bot, I suggested that this can be raised as an enhancement request mentioning that slack workspace admins can restrict or constrain the bot to display only selected fields with data when given command to bot in any channel. 

Now coming to the workaround I suggested in my video, the Amplitude's Slack workspace admin can navigate to Slack App directory and remove the Sally Bot from entire workspace, which eventually Sally Bot gets removed from all the channels of your Slack. Then you can inform your internal users to not add Sally bot in any private or sensitive channels in which Amplitude's customers are present. After informing this information internally, then again Amplitude's Slack workspace admin can re-install the Sally Bot.

It’s use it or lose it. And NO callout of this on the Knowledge Base at minimum, like a warning of how this would work with Slack Connect channels. 

Oooof this is a fabulous/awful call-out!!! 
This is an “accident” waiting to happen

Thank you for documenting this friends… I’m getting attention on this.

Hi Gunjan,

This is Ajay Agrawal (CISO of Gainsight) we acknowledge the concern you raised, it is getting investigated at this moment at highest level, we will come back with update on this in next 24 hours. I am personally monitoring the investigation.

Thank you for bringing this up

Thank you @Ajay Agrawal standing by for further updates. Please note that internally, we have discussed and will be pulling access to Sally tomorrow morning. We are in the process of alerting our security team as well.

@Ajay Agrawal Thanks for looking into this issue, just wanted to make sure you saw my comment as well.

@bradley When I looked at the original post I did see the comment by you, sorry missed to acknowledge that in my earlier post

Thank you 

Thank you for bringing this to our attention! 

This has been the behavior from the beginning of adding Sally in Slack channels and invoking intents so it’s upto the discretion of the admin on where and how they want to invoke Sally. We just discussed this on a call and found out that technically, there is no way for us to restrict information to only a subset of people in the channel because Slack does not support it. We can restrict it to only the person querying but then that beats the whole purpose of Sally. Although, I do agree that this can be called out in support documentation. I will work with our tech comm folks to get this updated. I hope this would suffice for now.

We are also going to evaluate solutions such as warning customers when they add Sally to a public channel however that will be an enhancement. Since there are other org level initiatives which have a higher priority at the moment, I will not be able to commit to when this will get prioritized. 

Thanks!

cc @Abinash @Ajay Agrawal @pallavig @jayaprakash_vunnam @anirbandutta

@arunabhat @Ajay Agrawal so it is working as designed. I understand there can be other priorities. Noting @bradley’s comment about this being a potential liability for Gainsight exposing the data, I am very surprised this is not being picked up faster. 

Is there not anything you can do to change the functionality to fundamentally NOT show the data at all, or restrict app responses to DMs only, no channels? Can we crowdsource ideas from the admin community to help rectify this sooner than later? We all want to work with you to figure out a solution because any companies using Sally effectively are getting value out of it, and it is heartbreaking to have to remove it. 

At this point, we have to make the decision to completely halt all usage of Sally. This is totally against the strategy and purchase decision altogether. Any other admin reading about this has an ethical obligation to report this to their security teams if they use Slack Connect channels with customers or external parties. How is this not a bigger priority automatically? Especially with the recent announcements of Sally for All...it is truly ALL. 

To be clear - we are also accordingly taking action to review any other Slack apps now to see how they may function. But this surfaced due to Gainsight Sally, and so you guys are hearing the most about it so far. 

Does Slack provide a control over 3rd party apps and Slack Connect? We don’t use Slack Connect but as an admin, I would like to have control over whether the app is added to a channel.

Hi Gunjan,

If it helps can we get into a call to discuss on this and conclude if it make sense please do invite your security team to the call so that we can cover the point in holistic way.

According to our IT team's chat with Slack, they do not, and are pointing back at the third party aka Gainsight here. We also tested the Salesforce app and found that they go through a pop-up instead, which shows the information strictly to the querying user, then gives them a prompt asking whether they want to share the info. If they click share, it will give them yet another prompt to ask which channel they want to share it in. Even that much would be much more secure IMO. 

Ajay, please email me on this. We are meeting with the security team on Tuesday as it is a long weekend in the US and will be discussing next steps and options accordingly. Thanks. 

Hi Gunjan

I have sent an email, let us connect and take this discussion forward on email/call. 

I tested this with Salesforce’s Slack app. They have two security tactics in play: one method of querying strictly sets it as "only visible to you" with an optional button that says "post to channel". 

The other method provides the information in that Slack popup style with a big green "Share" button that further puts you through a secondary validation of which channel you want to post to - and get this: external channels do not appear in this list. I can type one out and it will not be an option.

I am meeting further with Gainsight on this today, thanks, Ajay. 

How is this an idea/enhancement request?! It’s a security hole!

We are looking into this on priority. Sally was built prior to Slack Connect, so we have to revisit some of our original assumptions. 

Agreed, Manu - and might I add one thing: as different elements of the platform are built on other platforms, your PD owes it to your customers to have a vested interest in re-validating these builds and assumptions proactively.

A quick update:

• We are planning to provide an admin setting to know which channels should not be supported. We can then make this check every time and block both conversations (querying or engaging with Sally) and notifications (alerts pushed to such channels).
• For channels that are not blocked, we are going to change the base interaction to include a warning message + consent before posting anything. We looked into showing responses privately as well (called ephemeral messages), but are running into some text size limitations.

We are making these changes as quickly as possible, and will keep you all posted on the progress here. Furthermore, we are doing a similar assessment for Sally in MS Teams as well.

This might be less feasible from your side, but given that we have 26k Slack channels and new ones would be impossible to monitor, could it be an opt in process rather than an opt out process?

Manu, might I suggest the reverse? We cannot consistently maintain a block list, but an allow list is far more reasonable. 

If we do that, I'm assuming we would want to block only external channels by default? Otherwise, it'll be significant overhead to keep adding all the internal channels as well. If yes, that's where things can get tricky. When Sally is invoked from a channel, we don't get information on whether or not that channel is external. So we'd have to do something like this: 

1. Preload and save external channels on our end as a block list.
2. Any external channel added to an admin's allow list gets removed from #1.

I'll discuss this with Engineering in more detail.

I think by default any external channel would need blocking.

In general, if the solution is to mitigate possible data issues, if I have to opt out every channel I don’t want it on I’d need an admin just to play whack a mole with Slack channels to find out if it needs to be blocked or not and is a solution that doesn’t really address the problem.

If long term we can bulk manage channels that’s great, but for short term use we’d want to start with an opt in if it’s a channel by channel thing.