The Walt Disney Company has announced that it will stop using Slack for internal communications following a breach in which data was exfiltrated by a hacker group.
The breach happened in July, but is again in the news because Disney has reportedly decided to replace Slack with MS Teams. Given the timeline and facts, there is speculation that Disney’s move is more about cost cutting, and possibly blame shifting, than security.
As a developer of document security solutions for enterprise platforms including Slack, I did some digging into what actually happened, and conclude that this was not a hack – Slack’s security wasn’t broken, but rather it was a breach enabled by a user who was, at best, granted too much access and, at worst, was an active participant.
How the hackers got in
The hacker group, an outfit called NullBulge with unclear origins and motives, gained access by compromising the private laptop of a Disney employee with malware, then scraping all the Slack content accessible to that employee.
The employee had access to 10,000 internal Disney Slack channels, and the contents of those channels include some 13,000 PDFs and an even greater number of other documents. The content appears to have been mostly related to Disney’s theme parks and the administration of websites, but as Disney is built around creating and licensing intellectual property, the potential damage from stolen documents is substantial.
It seems likely that the employee helped the hackers, at least initially. In their announcement of the hack NullBulge doxxed a Disney employee, claiming that “We tried to hold off until we got deeper in, but our inside man got cold feet and kicked us out!”
A recent blogpost by Slack on the topic of security seems to address the Disney announcement, albeit in a very polite way (“Cybersecurity is a shared responsibility”). If Slack wanted to be more blunt they’d be within their rights to say that the breach was not due to a security issue in Slack and wouldn’t have happened if Disney had not:
- Let the employee log-in to Slack on a private, non-company-issued, computer,
- Failed to scan the computer for malware (a mod for the game BeamNG),
- Permitted the user to share credentials,
- Missed data in the Audit logs that would have disclosed the breach.
Switching to Teams isn’t going to stop this from happening again, unless/until Disney’s security team addresses these issues. Indeed, Disney now faces an even greater challenge in switching thousands of employees in their creative divisions accustomed to using Slack to an unfamiliar and decidedly less engaging platform. Some of these employees will likely “go rogue” and continue to use Slack, or other messaging apps, on personal devices and/or set up new accounts that aren't administered by Disney IT, further expanding the company’s risk surface.
How it could have been avoided
That said, there are steps Disney should have taken to minimize risk. Slack lists these in the aforementioned blogpost. The main ones are:
- Set up Identity and access controls (SSO and 2FA, timed sessions, etc.)
- Implement Device Management (EMM, jailbreak detection, browser control, etc.)
- Configure data protection, detection, and alerting (EKM/DLP, Audit log APIs, etc.)
The last of these includes implementation of Enterprise Key Management (EKM) and Data Loss Prevention (DLP). These are both solutions designed to prevent the exfiltration of data.
One additional step that Disney could have implemented is to encrypt and protect content uploaded into Slack, in this case specifically the 13,000 PDFs that were stolen in the breach. Had some or all of these PDFs been encrypted using a tool like FileOpen Sharebot for Slack then those PDFs would have been unusable outside of Slack, even if downloaded along with the rest of the stolen data. As far as I know, Sharebot is the only app that addresses this issue at the document level, by encrypting the PDFs and only allowing them to be viewed in the context of a viewer that requires authentication via Slack. This case is an example of the risk that Sharebot is designed to address.
There are a number of lessons here, but the main one is that even the most security-focused SaaS platform must be monitored and properly implemented. Slack has done the work to create a secure platform (if in doubt, have a look at the stringent requirements for FedRAMP Authorization). But security is a process of continual improvement. As Marc Benioff put it :
“Our security is rock-solid. This is really important. Also, there’s no finish line when it comes to security. But companies have to also take the right measures to prevent phishing attacks and to lockdown their employees from social engineering. So, we can do our part, but our customers also have to do their part — that’s extremely important.”
Sanford Bingham is Founder and President of FileOpen Systems Inc., one of the leading developers of Digital Rights Management (DRM) software for documents, especially PDF. The company’s tools enable strong encryption and access control in accordance with the PDF (ISO 32000) specification and have been in use for over 20 years.
More information about FileOpen Sharebot for Slack is available at https://www.fileopen.com/sharebot-for-slack
The Sharebot app has been approved by Slack for distribution and can be installed from the Slack App Directory