The Cloud’s Achilles heel(s)

I’ve come to believe the Wall Street Journal has the best coverage of cyber security issues of any general news publication. Exhibit A is today’s follow-up, by Robert McMillan, to their article last Monday on the Capital One breach. Here are six important statements from the article:

1. In a court filing on Tuesday, prosecutors said Paige Thompson had stolen “multiple terabytes” of data from more than 30 companies, educational institutions, and others.
2. Ms. Thompson had “expressed frustration over her 2016 dismissal from Amazon…” in online discussion forums.
3. Amazon had previously said that “..none of its services were the underlying cause of the break-in.”
4. However, on Wednesday a company spokesman said the company is now “running checks and alerting customers if they have the kind of firewall mis-configuration that Ms. Thompson allegedly exploited.” Furthermore, “Amazon is also considering additional changes it can make to its cloud subsystems that will better protect its customers”, according to a letter dated Wednesday.
5. Winning my 2019 Clueless in Seattle award hands down, an Amazon spokesman said “Other than Capital One, we haven’t yet heard from customers about a significant loss.” This is roughly the equivalent of the White Star Line, in their annual report for 1912, saying “Other than the loss of our ship the Titanic, we had a very good year.”
6. The most significant statement in the article – from my point of view, anyway - is “Security experts who have viewed her posts said Ms. Thompson displayed a high level of technical knowledge of the inner workings of Amazon’s cloud.”

Here are my takeaways from the article:

a)      It seems very possible that all of the 30+ organizations that Ms. Thompson may have breached were Amazon customers. It wasn’t that she was pinging random IP addresses and just happened to find C1 and these other Amazon customers, who had poorly-configured firewalls. She was almost certainly just attacking Amazon customers.

b)      Ms. Thompson had been terminated by Amazon in 2016, and obviously felt she was treated unfairly. So there’s the motive (she doesn’t seem to have been trying to make money off all of the data she stole, although that’s not certain yet, of course).

c)       The sentiment last week – both Amazon’s and I believe the online community’s in general – was that this breach was mainly a result of Capital One’s poor management of their online firewalls. However, that position is a little hard to maintain, now that there are at least 30 other victims. Sure, they all probably had made mistakes on their firewalls. But if any system is so difficult to figure out that 30 companies don’t get it right (plus God knows how many other Amazon customers who weren’t lucky enough to be on Ms. Thompson’s target list), it seems to me (rude unlettered blogger that I am) that Amazon might look for a common cause for all of these errors, beyond pure stupidity on the customers’ part. After all, there’s another large American company that’s in a bit of a pickle nowadays because they have a system that, while it probably works as specified, requires airline pilots to figure out a previously unknown (to them) problem in the 2-3 minutes they have left before they and their passengers all die – not exactly a great design, IMHO. So far, nobody has been killed by an Amazon breach – that’s one thing they can be happy for in Seattle.

d)      Fortunately, it does sound like Amazon is finally acknowledging that they have to share the blame for these problems, as well as figure out a solution – better training for customers, hopefully redesign of the systems to make them more understandable, etc.

But I almost forgot – this blog is about securing the Bulk Electric System, as well as information about the systems that run it. What does the above mean for that?

I think today’s WSJ article shows there’s a big Achilles heel (in fact, two of them) to cloud security. The first is the one we already knew about last week: that making security totally the customer’s responsibility is inviting trouble. The CSP’s have to do a much better job of educating customers on the risks they face and how to mitigate them, as well as of providing them tools that are understandable. And the CSP’s probably do need to look over their customers’ shoulders as they configure their firewalls, even if their lawyers will probably get apoplectic about the liability this might cause (memo to Amazon’s lawyers: It’s a little late to be worrying about liability in this matter. If you think Amazon is going to get off scot free in court when the lawsuits from Ms. Thompson’s breaches are all settled, you’re grievously mistaken).

But the big Achilles heel is the fact that, while the CSP’s are probably doing an excellent job of protecting against insider threats, they’re not doing any job at all (at least one of them isn’t) in protecting their customers against a disgruntled employee who was fired three years ago and has lots of knowledge of how internal security works at the CSP – as well as of how that security is typically misconfigured by customers. How do they protect against this threat? I suggested last week that maybe there’s a machine that can suck from an employee’s brain all of the knowledge they’ve accumulated about the CSP’s security, once they’ve left the company. At the moment, that’s about the only practical solution I can think of – but I’m sure it’s not ready yet (perhaps it’s in beta). Or maybe they can incarcerate any employee they fire on a desert island somewhere for say five years – at which point any knowledge they may still have would probably be useless. Or maybe they can bring new meaning to the term “employee termination”.

So many possibilities.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. To discuss this, you can email me at the same address.