3 ms·

I think it's harsh to call it extreme paranoia. I've heard that one of the reasons Amazon won't use Slack for its chat is because it isn't self-hosted. I'm su

by mdasen 9y ago

I think it's harsh to call it extreme paranoia. I've heard that one of the reasons Amazon won't use Slack for its chat is because it isn't self-hosted. I'm sure many major companies won't use Gmail. I don't think Slack or Google have done anything that suggests they'd mine their platforms for corporate espionage. Slack isn't even in the same industry as Amazon. Is Amazon paranoid? According to the article, Walmart seems hesitant to support so much profit running to Amazon. While Amazon's retail business runs on razor thin margins, their cloud business reaps enormous profits. That means that the cloud business is helping Amazon put a lot of pressure on Walmart. Without it, would they be able to eat such thin to negative margins in the retail business or would they need to raise prices and make Walmart's offerings look better for consumers? In the article, they note that AWS was 89% of Amazon's operating income. It's likely that Amazon's thin retail margins would bother investors if AWS wasn't raking in money. It's also likely that AWS margins are helping Amazon be more aggressive in retail. Still, I don't think it would be more paranoid than most companies to avoid using a competitor's infrastructure at that size. Amazon will prefer self-hosing email rather than using Gmail regardless of assurances. It's not even just about trusting that the competitor wouldn't actively decide to peek into your data. It's trusting that no one in that company would take a peek even though that the competitive data could give them a huge career boost. Let's say Amazon hosts their email with Gmail. You're a struggling middle-manager at Google Cloud who has seen some failures. Maybe peek at Amazon's email and see what their cloud plans might be and when you're able to get out in front of Amazon you amaze your colleagues - maybe you have to bribe someone with access.* It's not just trusting that Google doesn't want to do this. *Now, I'm sure that Google has safeguards to make sure that employees can't do this (or it's at least hard), but the point is that you have to trust 1) the company, 2) the employees, and 3) procedures the company has put in place to prevent nefarious data access.

snowwolf 9y ago
Isn't Slack on AWS? So effectively it is self-hosted for them :) https://aws.amazon.com/solutions/case-studies/slack/ https://aws.amazon.com/solutions/case-studies/slack/
- discodave 9y ago
  But AWS can't control Slacks security practices. AWS also has many compliance certifications (HIPAA, FedRAMP etc), sending data outside your organisation may be a no-go from a compliance perspective.
Twirrim 9y ago
The story there is more complicated, and security plays a large part of it. 1) Slack uses AWS. While it's perfectly possible to operate without slack, chat services are valuable during outages. The kind of incident where it would be most valuable is precisely the kind of incident that would take it down. Communication services must be completely independent of the AWS infrastructure. Likewise, something like PagerDuty is effectively off limits. Though they've done a good job building resilience, PagerDuty have been affected by AWS outages. 2) Slack communication isn't encrypted end to end. While it may be stored encrypted at rest, it is stored in a method they can decrypt, read and analyse (inherent in the features they provide). Chat is filled with critical operational information, and (no matter how well you train people) passwords and other critically sensitive information. There's always an extremely slim chance that a rogue actor could choose to access information they shouldn't. That information is, also, potentially accessible to someone who might hack in and compromise the service. We've already seen Atlassian's hosted HipChat service compromised and some chats leaked. Slack has, arguably, an even bigger bullseye painted on it. (fun thought exercise: what damage could a malicious actor with access to yours slack channel do with your chat ops bots? How long would it take to stop them?) 3) feeding on from 2, to some degree, you don't control the security of hosted solutions. Audit compliance is a checklist game, it is perfectly possible to check every point on those checklists and still be inherently insecure. If you're even remotely paranoid, you've got to assume that anything you don't host will be compromised, and weigh up the risks associated, against the value and necessity of the service. Leaking operational information is a big, big risk. Amazon's security sets a high bar for paranoia. They are determined to never have a New York Times front page article "Amazon hack, credit card information stolen", or similar. There's just no strong value in them switching to Slack, just a whole mass of unnecessary risks.

by mdasen 9y ago

snowwolf 9y ago

Isn't Slack on AWS? So effectively it is self-hosted for them :) https://aws.amazon.com/solutions/case-studies/slack/ https://aws.amazon.com/solutions/case-studies/slack/

discodave 9y ago
But AWS can't control Slacks security practices. AWS also has many compliance certifications (HIPAA, FedRAMP etc), sending data outside your organisation may be a no-go from a compliance perspective.

Twirrim 9y ago

The story there is more complicated, and security plays a large part of it. 1) Slack uses AWS. While it's perfectly possible to operate without slack, chat services are valuable during outages. The kind of incident where it would be most valuable is precisely the kind of incident that would take it down. Communication services must be completely independent of the AWS infrastructure. Likewise, something like PagerDuty is effectively off limits. Though they've done a good job building resilience, PagerDuty have been affected by AWS outages. 2) Slack communication isn't encrypted end to end. While it may be stored encrypted at rest, it is stored in a method they can decrypt, read and analyse (inherent in the features they provide). Chat is filled with critical operational information, and (no matter how well you train people) passwords and other critically sensitive information. There's always an extremely slim chance that a rogue actor could choose to access information they shouldn't. That information is, also, potentially accessible to someone who might hack in and compromise the service. We've already seen Atlassian's hosted HipChat service compromised and some chats leaked. Slack has, arguably, an even bigger bullseye painted on it. (fun thought exercise: what damage could a malicious actor with access to yours slack channel do with your chat ops bots? How long would it take to stop them?) 3) feeding on from 2, to some degree, you don't control the security of hosted solutions. Audit compliance is a checklist game, it is perfectly possible to check every point on those checklists and still be inherently insecure. If you're even remotely paranoid, you've got to assume that anything you don't host will be compromised, and weigh up the risks associated, against the value and necessity of the service. Leaking operational information is a big, big risk. Amazon's security sets a high bar for paranoia. They are determined to never have a New York Times front page article "Amazon hack, credit card information stolen", or similar. There's just no strong value in them switching to Slack, just a whole mass of unnecessary risks.