When it comes to improving an organisation’s holistic security, it’s important to be realistic. If security implementations become too onerous, staff will become frustrated. Frustrated team members are less likely to be proactive about their security, and now your brilliant 45-step plan for perfect security culture has been foiled. Blast!
This scenario can be avoided by simply meeting people where they are.
One big gap in many organisations’ security culture is the use of Slack. In a dream world, we would all have the capacity and resources to manage our own servers and implement an open source alternative. Right now that’s just not realistic for most, so if an organisation needs to use Slack it makes sense to help them use it more intentionally – meeting them where they are – rather than brute-force their switch to a Mattermost server, for example.
One of the concerns I have about Slack is that the data doesn’t necessarily stay on Slack’s servers, but could also potentially be shared with over 100 different external services. While there are many articles about the dangers of Slack, I didn’t find many about security of these apps or apps.
Given this dearth of advice, we worked with an advocacy organisation to devise a simple workflow for ensuring both security and flexibility of our Slack apps. If you’re thinking, “I don’t use Slack so THIS ISN’T RELEVANT”, don’t close this tab! We feel this workflow could easily be modified for any tool that allows for 3rd party integrations, like WordPress, NextCloud or Google Suite.
Is Slack slacking on security?
Before I outline our approach, it’s worth knowing a little about Slack’s approval process for apps. Developers need to list all the permissions their app asks for and list reasons why each exist. In other words, if there is an odd permission that seems to take a lot of information from the user and there is no practical need for this data to be collected, it could be grounds for rejection. In addition, the developers have to agree to allow Slack to conduct a security review of their app by terms laid out in the Slack App Directory Agreement and the Security Review Guide.
It’s encouraging to know that each app undergoes a security review, but even Slack admits that users who enable the apps do so at their own risk (from the Slack Security Review Guide):
The Slack Application Security Review is not a certification, or proof of a secure application. Additional vulnerabilities may exist after a review, and we may revisit your application in the future to re-evaluate the security of your offering.
Even if Slack gives their stamp of approval, it’s possible they don’t have the same philosophy or threat model as your organisation, so we think it’s worth thinking more critically about what data you share and who you share it with. This is how we do that.
Our Process
Current Challenge:
Slack allows anyone within an organization or team to enable any of their approved apps. These apps, however, require vastly different access to user-generated data and many don’t have data or privacy policies.
Goal:
Create a standardized process for intentionally enabling Slack apps, so that a team knows what is happening to their data at any given moment.
Lock it Down
Once you become aware that staff can (and will) download any app they feel like using, the first step is to prevent staff from adding any new apps. While Slack officially recommends giving all staff the power to enable any apps they please, this isn’t a sound practice from an organisational security perspective.
Thankfully, it’s easy to change the Slack’s user permissions to require an admin to whitelist any app.
Take Time to Triage
The next step is to figure out what apps are currently in use and to organise them based on a few values:
- Name
- Team – Which team uses this app?
- Status [Enabled, Enabled (Restricted), Disabled, Removed ] – Are staff able to enable and use this app?
- Who enabled? – Who originally enabled this app?
- Popularity [Widely used, Used by a few people, Not actively used] – Roughly how many people use this app?
- Functionality – What does this app do?
- Data Policy – What is the company’s data policy, if present?
- Approval [Approved, More Research Needed, Not Approved (Awaiting Justification), Not Approved] – Has this app been vetted by the security team?
- Comments – Is there anything else we should know about this app?
Though the spreadsheet can’t tell you which apps are safe to use, it will help you pull together diverse pieces of information to standardise your decision-making process, and make the call on which apps you will use in your organisation. The three most important variables featured are: Popularity, Functionality, and Data Policy.
If the app is very popular with the team, but has an unclear data policy, you might want to spend more time researching the exact permissions it asks for.
If an app isn’t widely used, but has very useful functionality and a well-written data policy, then you may want to approve it.
Some apps might require more research or a larger discussion. The purpose of organising them is to have an omnibus so you know what apps your teams are using and the justification for enabling them.
Enter the World of Whitelisting
Once you’ve decided which apps you trust, it’s time to whitelist them. To do this, your Workspace Owners (and others within a team who are given explicit permission) can create a list of approved apps that are specific to your Workspace. Now, anyone on the team can enable these apps and won’t need to ask for permission.
With a whitelist, of course, come apps not on the whitelist. These non-whitelisted apps require explicit approval from the administrator or owner of the Slack team. This could be a bottleneck, but at least it’s a bottleneck with a purpose — more intentional security practices.
Set Up a Survey
While it makes sense for technical administrators to have the final say on what apps can be used, it’s still important that staff feel empowered to research and suggest new apps that might be particularly helpful for their work. When a staff member sends a request to enable a new app, administrators can ask them to fill out a short survey detailing why they want to use the app, what research they’ve done so far and how important the app is to the work they do. Here’s an example of the survey we use, which you can modify to fit your own needs.
This survey ensures admins get all the context they need to make a strategic decision about the app. The tech team may not know exactly what the finance team needs; similarly the finance team may not know how to assess the app from a technical perspective. Diversity of experience and needs are necessary in order to make the best decisions around tools and security. (Inspiration for the survey came from 18F’s documentation on their Slack policies.)
What’s next?
We hope the process outlined is helpful for other organisations looking to make realistic but impactful change in their security practices.
If you’ve got other tricks to making tools like Slack more secure, let us know!