TL; DR

As Slack becomes a dominant part of the infrastructure in your organization, it will become a target for attacks and at some point, it is likely to be breached (just like any other technology that we use). The impact of that breach, however, depends on how we prepare for it, by limiting its potential propagation and allowing for fast response.  

Slack (and similarly, Microsoft Teams) has gained immense popularity and adoption in the last few years, and there is a good reason for that — it is an amazing collaboration tool. This new experience, however, comes with the usual challenges of adopting innovative technologies, including security. While Slack itself is a secure platform, the way it is used by organizations can lend itself to various attacks, leveraging misconfigurations, insecure practices, supply chain attacks (through 3^rd party apps), and user mistakes. The amount of data stored on Slack, as well its sensitivity, makes the potential impact of such a breach extremely high. Furthermore, detecting and responding to Slack attacks can be difficult, due to limited available technology, processes, and skills.  

Readiness can reduce the impact of potential Slack breaches. The time you spend now considering the potential challenges and security risks of a Slack breach and preparing for one will help you when it happens. This article provides an in-depth analysis of Slack risks as well as detection and response challenges, and actions you can take to reduce the impact and likelihood of potential Slack breaches.  

Background

Over the last decade, Software as a Service (SaaS) platforms have become increasingly popular with enterprises, replacing traditional legacy corporate applications with modern, cloud-based solutions. This move has accelerated during COVID, and even the most conservative organizations are gradually migrating to SaaS applications. The shift to an as-a-service model offers many advantages over the need to maintain (and secure) legacy on-prem applications, yet it also introduces new risks and challenges.  

While many of the potential risks and challenges in this space have been long known by cloud security practitioners, the recent Okta breach caught many in our industry by surprise. Okta is a critical SaaS infrastructure component, yet this breach demonstrated that most of the industry was poorly prepared for such an incident. Many organizations using Okta did not have the infrastructure to investigate and respond to a breach coming through Okta (regardless of whether the breach was due to an issue with Okta itself, or simply because LAPSUS$ was able to leverage it), and there was a lot of confusion once the breach became public. In the hours following the breach, we released internal research on Okta Log Investigation to support the community, which needed actionable information to conduct their own investigations.  

The Okta breach caught attention, but it is just a timely example. Of the dozens of SaaS applications adopted by each organization, many are critical to the organization’s infrastructure and hold extremely sensitive data. In most cases, these critical SaaS applications replace an existing critical infrastructure, such as corporate email or enterprise resource planning (ERP). While still introducing a modern technology stack in many cases, this 1:1 replacement allows for (at the very least) some benchmarking regarding expected security controls, permissions, monitoring, and even communications culture.  

The Slack Experience

Slack, on the other hand, represents an entirely new solution for most organizations. Very few companies had on-prem chat solutions, and even then, adoption was usually limited to the technology teams. We use Slack daily here at Mitiga to coordinate and communicate across teams and time zones; most organizations moved to some form of hybrid work when the pandemic began, and Slack provide an important way for teams to work and collaborate efficiently regardless of physical locations.  

This new experience, however, comes with the usual challenges of adopting new technologies — around culture, functionality, expected user behavior, and, of course, security. One of the most interesting cultural aspects of Slack usage is the place that it is taking in the organizational communication and knowledge management stack. For many, Slack has become the main communication channel within the organization, replacing email for most tasks. Moreover, Slack channels are becoming sources of knowledge and replacing knowledge management repositories.  

As a result, we see more and more organizations where Slack is becoming one of the most sensitive collections of organizational data. Indeed, Slack contains far more sensitive information than the corporate email system or even an organization’s internal knowledge management system.  

The Security Challenge in Slack

Before diving into the challenges, it is important to state — Slack is a secure platform. It offers great security capabilities, and Slack itself, as a vendor, invests substantial resources in securing its infrastructure, platform, and the software itself.  

Nonetheless, like any other technology platform, Slack can serve as a basis for attacks, many of which do not require abusing a new vulnerability, but take advantage of built-in features, insecure usage, or misconfigurations. But while other collaboration and communication platforms (such as email) have been around for years and have an entire ecosystem of security solutions and best practices built for them, messaging apps such as Slack have only a very small subset of these security solutions and practices in place.  

Before discussing how organizations can deal with such breaches, let’s first examine some of the risks and challenges that Slack (or similar technologies) introduces. At the top of that list is something that has nothing to do with technology, but rather (as always) with people.  

The Slack culture is incredibly open, collaborative, and trusting. It is so by nature, but it is that nature that makes it easier to attack. Years of phishing attacks have made us very suspicious of any out of the ordinary email, but very few users will ever suspect a message from a coworker on Slack. In this way, an attacker can easily leverage a single compromised account in Slack to deceive other users and gain additional access. Furthermore, the open culture presents itself in Slack groups. Most organizations believe in leaving as many groups as possible public, encouraging participation, and allowing users to search them (as part of the Slack as a Knowledge Base approach). However, many users don’t think about the significance of that and post sensitive information in public Slack groups. Furthermore, the “casualness” of a Slack chat often makes people share more sensitive comments or even secrets, such as passwords or cloud Application Programming Interface (API) keys. Shared as part of a conversation, people never think about it being stored forever and forever — and accessible to a single compromised account.  

‍

But culture is not the only problem. Like many other SaaS platforms, Slack offers an extensive marketplace of applications and allows you to build additional applications outside of this marketplace. Third party apps in SaaS platforms are a huge supply chain risk, creating an attack vector for pretty much any SaaS platform. Slack is no different. This risk, however, is further augmented when considering the culture of Slack usage. Many 3^rd party apps will ask for extremely extensive permissions, but even the seemingly benign request to “read from all public channels,” allows access to endless amounts of data. Data its original authors have not considered to be easily accessible outside the organization.  

Unfortunately, these examples are just the tip of the iceberg. Spending a few hours threat modelling how we use Slack at Mitiga required us to invest substantial efforts in securing our Slack. While almost all our Slack groups are private and we are extremely strict about which apps, if any, are given permissions to Slack, we still uncovered many additional potential risks, including issues around content filtering, lateral movement, 3^rd party communication (Slack Connect), and many more.  

Slack Detection & Response

Making things just a little harder, the Slack security challenge extends beyond the materialization (or prevention) of these risks. As Slack becomes a dominant part of the infrastructure in your organization, it will become a target for attacks, and as it becomes a target for attacks, at some point, it will be breached (just like any other technology that we use).

Organizations must be able to timely identify, contain, and respond to security incidents and breaches to reduce the impact to the bare minimum. Unfortunately, both the technology and practices required to do so for Slack are limited and in their infancy. For a start, Slack will only provide access to security logs to customers using its Enterprise (most expensive) tier. Without security logs, both detection and response are almost impossible. This is part of other advanced security features (such as SSO) that are not available in their standard and pro plans, leaving many mid to large organizations exposed.  

But having access to the logs themselves is not sufficient on its own. Having the logs, or even streaming them to your security information and event management (SIEM) and security operations center (SOC) will not help without the relevant knowledge and understanding of those logs and how to identify attacks in them. With little to almost no out-of-the-box rules and information, most organizations simply lack the knowledge and skill to detect, investigate, and respond to Slack incidents or breaches.  

Furthermore, what many users don’t know is that (unlike some other SaaS technologies), Slack does not keep history or revisions of anything that has been erased. If an attacker can delete messages, these messages are gone forever. This can turn into an effective ransomware attack, which is hard to respond to without upfront preparations (predominantly backups).  

So Should I Stop Using Slack?!

NO! Definitely NO!

Slack is an amazing platform that, ideally, makes your business work more efficiently. While the last few paragraphs may have been scary, it is part of the world we live in. Any platform we use — whether it is email, file collaboration, finance, or something else — is susceptible to risk and may be an attack vector. It is through understanding of these risks that we can become more secure and more resilient in facing those attacks. 

Top 5 Things to Consider in Preparation for a Slack Breach

By preparing for an incident, organizations can become more resilient, allowing them to respond and recover quickly, while containing the breach itself and its impact to the business to the bare minimum.  

Here are the top five things to consider as you think about a potential Slack breach:  

• Private/Public Groups Culture – Defining a clear policy on what types of groups can be public and what types need to be private, enforcing it, and educating the users around it. It is not an easy shift, but nonetheless, it is an essential one for something that becomes critical infrastructure and a repository of data.  

• Limited 3^rd Party App Permissions – Restricting 3^rd party apps to the bare minimum permissions is a necessary step in limiting the impact of a 3^rd party breach. Sometimes it is better to simply give up on an app that is not necessary. At other times you can restrict the app to the minimum privileges needed to allow functionality. Many app vendors normally ask for excessive permissions without any real need.

• Backups for Slack – Backing up your Slack is essential if Slack serves as a knowledge management repository and a critical asset in the organization. Backups can be done through automation of Slack’s export capabilities or using 3^rd party vendors that offer this service.  

• Enable Advanced Security Features – Requiring multi-factor authentication (MFA) (directly or via SSO) is the bare minimum, but you can enable additional security features, including additional encryption, compliance, security management, and more when purchasing the Enterprise license for Slack.  
  
• Collect and Prepare Slack Logs (Forensics) – Collecting, analyzing, enriching, and preparing Slack logs makes it easier to quickly respond to an incident or a breach, so that it can be contained and eradicated as quickly as possible — and with minimal impact. Forensics analysis sits at the baseline of any major breach response. Through forensics analysis incident responders can understand and block the entry path, assess the damage that has been done, and respond quickly and effectively.

Readiness can reduce the impact of potential Slack breaches

The time you spend now considering the potential challenges and security risks of a Slack breach and preparing for one will help you when it happens. The steps outlined above can help you reduce the impact, as well as the likelihood, of potential Slack breaches.  

‍

A version of this post appeared in Dark Reading on June 6, 2022.

‍