Somebody else’s problem? Don’t rely on cloud service cybersecurity

In his Hitchhiker’s Guide to the Galaxy books, Douglas Adams introduced his audience to the “SEP Field“, which was capable of rendering even massive objects, such as space ships, pretty much invisible to the human eye. That was possible because SEP was, he explained “someone else’s problem,” and therefore only ever glimpsed out of the corner of one’s eye, and even then, ignored.

In the world of cloud computing, cybersecurity and to some extent, data viability itself, becomes SEP. Users of public cloud providers’ services are wont to ignore many issues surrounding cloud security and protection of data— some of it mission-critical, or representing priceless IP (intellectual property).

If it’s on AWS, security is AWS’s problem, not that of the IT department that created the bucket.

It would be easy to blame the end-users who, empowered by notions of citizen development or the ease of creating a new service, develop new tools and services for themselves, their departments or their customers. But the buck stops with the IT department: IT might now be enablers and supporters of a new generation of technologically-savvy end-users, but when things go awry, it’s the IT department who will cop the blame.

Cloud security survey

And according to research by Unit 42, part of Palo Alto Networks, it’s often the IT department who set up the instance of the remote platform, especially as many use cases for remote, public clouds involve not the signing-up to a useful app online, but rather setting up an IaaS/PaaS instance. Leasing bare metal hardware or a VM in an old-style server farm had its complexities with regard to cybersecurity (which required competent handling), so why should an EC2 or equivalent be any different?

What the researchers at Unit 42 found was that there were several potential vulnerabilities left “open” in services from all the major providers, with only a couple of discrepancies caused, Unit 42 surmised, by the details of the sign-up and initial configuration routines.

Chief among the concerns— at least in terms of numbers of issues— was the exposure of SSH services unprotected by key pairs, and relying on password access. While SSH is a relatively secure method of “dialing in” to remote servers, brute-force attacks are possible when the protocol can use simple password protection.

The company found that Microsoft Azure’s services were particularly at risk due to this issue, probably because the configuration process for new Azure instances gave would-be systems administrators a choice between using public-private key pairs and passwords. The other providers’ insistence on key pairs may explain the anomaly, although a cynic might also point to the fact that Microsoft’s own documentation states the best tools on the Windows desktop for keypair creation are in WSL 2; Windows users struggle with basic security concepts, being the subtext.

Cloud safety vs. bare metal cybersecurity

Unit 42’s Jay Chen said:

“Users need to have minimal security awareness to work in the cloud. Although Function-as-a-Service removes a lot of maintenance burden from the users, developers still need to write the code and assign proper permission to each function. If new vulnerabilities are found in the libraries that the functions use, only the developer can patch and update the source code. If CSP alerts an exposed SSH service and recommends a firewall configuration to restrict inbound traffic, only the system admins know what IPs the firewall should whitelist. These trivial tasks are too often neglected, which can lead to catastrophic outcomes.”

He went on: “Different organizations simply repeat the same mistakes at different cloud service providers.”

Did you know that a single insecure configuration put an entire #cloud infrastructure at risk? Our newest blog shares more details: https://t.co/ardFSfoGQ2 pic.twitter.com/D0HNYB4a62

— Unit 42 (@Unit42_Intel) August 13, 2019

As Douglas Adams explained, the SEP “field” relies on “people’s natural predisposition not to see anything they don’t want to, weren’t expecting, or can’t explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there.”

The tale’s moral is simply one that a remote Something-as-a-Service is subject to the same scrutiny online as a physical server in an organization’s head office server room: to the bots and algorithms that trawl for weaknesses, both are just IP addresses. Similarly, when the finger of blame points, on which platform the fault occurred— on remote Google Cloud or closer to home — is irrelevant.