The fact is, it's an enormous, centralized application written in PHP (not always a bad thing, but certainly not a language that keeps you from shooting yourself in the foot), with a massive target painted on its back.
How is it acceptable to you to use a chat solution hosted by a third party? Why not use an alternative you can host yourselves? It's just a matter of time before there's a huge incident.
Larger companies usually have the budget, tools and expertise. But even then there are lots big companies with mediocre security too.
All we can do is assume that Slack cares about security enough to be sufficient. Last I checked, they didn't have any form of compliance certification, yet HIPPA, PCI, etc. compliant clients use them without reservation.
I don't assume it. I know it for a fact; I've met some of their team and I know others by reputation. And I'm not exactly a slouch when it comes to this stuff (I don't eat and sleep crypto but a large part of my business is building secure infrastructure/consulting on the systems running on that infrastructure for regulated as well as non-regulated environments).
Compliancy only tells a story about management and how many MBA's you have, it doesn't actually mean you have good security. Only being compliant isn't going to help you not get data leaks or data loss!
There's no question that Slack's budget is greater than my own. They have a large, full-time security team. I have a bit of attention from myself or a colleague when setting a system up.
There's also no question their expertise is better. These are life long security professionals with direct experience at other SaaS companies.
If you use a service, you're outsourcing your security to perhaps more competent people, but you're making yourself a larger target.
Self-hosting makes you a smaller target, but you're taking all the risk on yourself.
Neither is a panacea.
I'm not exposing it to the WAN, just the LAN. :\
I don't think people really appreciate how massive of a security difference that is. It doesn't matter how big your budget is if you sit on the WAN all day. Someone will _always_ tag you eventually.
LAN with hardened VPN/SSH setups are virtually impossible to get into in a software-is-at-fault kind of way. And even if they did, they'd then have to launch the attack from someone's workstation at which point you've already been compromised anyway.
Oh, and then to get to the chat service they'd still need to break the security of an open source chat service which is non-trivial.
The majority of non-trivial breaches involve some sort of pivot or lateral movement inside the "protected" LAN. These often originate from a workstation.
Slack has an entire security organization dedicated exclusively to securing its stuff. My security team is focused on securing our operational systems.
Do you run your own bank? How could you outsource something so critical (literally all your money and financial details!) to a 3rd party who doesn't even let you audit their stuff?! It's just a matter of time before there's a huge incident.
Do you run your own electrical generation facility? How could you outsource something so critical to a 3rd party? I bet they don't even have an SLA!
etc. etc.
The notion that self-hosted is more secure is curious, though. Slack's security team is almost certainly better than yours, for most--not all, but most--values of "yours". You might be the rare exception (I'm certainly not, and I build reasonably secure systems by habit, if only because I don't have the time or money to focus solely on a chat service), but I doubt it.
In terms of security, I would propose that professionals dealing with sensitive data are often more comfortable with a self-hosted solution. As an example, former members of the CIA, FBI and NSA have used Mattermost on national television in the US: https://about.mattermost.com/open-source-mattermost-software...
We recently evaluated many chat systems for a large tech consulting project that includes security needs.
Slack was the frontrunner because of ubiquity, ease of use, plentiful third-party integrations, openness to free areas, and helpful in-person meetings with the Slack staff.
We picked Slack for our informal connections with external developers for non-confidential discussions.
For our own teams' use, I really like Ryver. The security is better (IMHO), the team-oriented features are stronger, and the billing is much clearer. The Ryver team is fully open to discussions about how to grow the platform and improve the security.
Ultimately the security team chose self-hosted Mattermost. We liked the combination of intranet deployability, plus a ramp toward security compliance capabilities that we do need for a few projects.
EDIT: Security-wise, I would think Slack, as a bigger company, would have better security, but that's all assumption. Do you have anything to back up the idea that Ryver is more secure? If so Ill definitely give it another look.
My threat model emphasizes ease of security by normal users. For example, is it easy for my teammates to see when they're in a public area or private area? Can my teammates manage access controls the ways that they want? IMHO Ryver is better at this than Slack.
My sec team's threat model emphasizes the underlying platform getting hacked. IMHO Ryver and Slack are both SaaS, so both in the same boat on this: the info is outside the firewall, which incurs legal issues, compliance issues, revocation issues, etc. I believe that SaaS providers can be excellent at security, yet the SaaS target is much bigger, and the alerting is murkier, and revocation is not thorough. This is why we chose Mattermost for secure chat.
However, most of the backend services at Slack (the ones you'd actually want to attack) aren't even in PHP anymore: according to their job reqs, they're in Java and Go.
1. The Slack model is such that your staff could start using it without even getting permission from the top. This is the Slack strategy for sales. It comes into companies from the bottom, so companies are more responding to the fact that their employees are using it vs bringing it in from the top.
2. Yes there are risks with cloud products, but risk is a cost consideration so you look at cost impact to the company of a breach and you compare that to a self-hosted high maintenance solution. This is a much more difficult calculation and it really depends on the size of your company, the value of the information Slack will be holding, etc. It's also possible Slack could be seen as more secure because an internal system breach may not include a complete Slack hosted breach. It could be seen as data segregation and diversification.
3. Slack is not the only company that is making inroads here. Slack is known well in the tech industry, but less-so in other industries. Microsoft is a giant because Skype for Business is huge, and there's many others.
But then again, that assumes an honest question and not an agenda...
At minimum, in the case of a lawsuit, they will be subject to document retention and subpoena.
Why would a zebra have evolved to have black and white stripes? You could see a zebra from miles away due to how it stands out! Yet.. when it's in a herd of zebra, it's hard to pick any individual one out, and that's why the pattern works.
And so it goes with using services like Slack, Gmail, S3, etc. My account on its own may not be the most secure thing ever but it's hidden in such a large pool of data - much of it far more valuable than mine - that the safety of the herd becomes relevant.
I suppose that's correct. When (or maybe if, but probably when) Slack gets breached/hacked/owned it's going to be huge because a huge number of people are going to lose something that they didn't want to lose.
When I'm self hosting something and that thing gets breached/hacked/owned it's going to be huge for me because I and/or my company are going to lose something that we didn't want to lose.
I don't believe I can keep my stuff much safer than the big guys, though the point about Slack having a massive target is a good one. Maybe that makes it less secure?
I really don't know what's better for us in the case.
I read a story from a blogger [1] who was visiting an Airbus facility for an A350 presentation and when he came back in plane, his neighbor, an Airbus sensitive contractor, was editing internal documents on a Chromebook using google doc. Yep. No fear.
[1] https://korben.info/vous-proteger-de-lespionnage-industriel-...
Based on their security practices document, they seem to store documents unencrypted on their servers. It's encrypted in transit, sure, but not in storage? I was shocked when I found out.
https://help.salesforce.com/servlet/servlet.FileDownload?fil...
At least Slack encrypts data at rest https://slack.com/security
For example, it is hard with C API for databases or templates to get SQL injection or XSS bugs. With PHP it is trivial and such usage still simpler than safer versions.
- Because self hosted HipChat / IRC / XMPP / is not cool enough.
- Because we are all supposed to use Lync / Skype for Business, but it sucks on OSX / Linux / in general.
- Because we are a small team, and maintaining a chat server is too much for us.
- Because we don't know (or want to know) how Slack works.
- Because shiney, such giffy, such memes.
- Because its free.
- Because my software engineers don't know how to connect to IRC
There is varying levels of good and bad reasons in there. (personally I am still a irrsi / IRC person, but I fully acknowledge I am not in the majority anymore)
