Every Cloud has a Silver Lining or frankly no lining at all

Every Cloud has a Silver Lining or frankly no lining at all

Saturday 24th February 2018
Sean Davin

A recent report in the IT Security press highlighted "2017 was the worst year regarding number of breaches and data compromises. By one estimate, there were 5,207 breaches in total - a 20% increase from the previous high in 2015. Cloud security incidents dominated headlines during the year, with Amazon Web Services (AWS) data exposures becoming a recurring theme." (Cloud Security blog)

Recent exposures in the press such as Tesla's AWS S3 hack and FedEx's AWS S3 data breach are just showing that Cloud computing remains a seriously complex issue for use as an Enterprise IT asset.

There have been many other high-profile cases (such as the Los Angeles times) where CryptoMining software infected insecure Cloud environments. Here, the hackers responsible are using Cloud computing hardware to run their mining software by hacking an organisation's web services, while the organisation paying the bills pay for that hijacked processing too.

As we've highlighted in the past, "in the old days" we used to all have our computer equipment within our company premises which meant we could control it, but we would have to maintain it too.

More recently, with the advent of Cloud computing, the mass maintenance of hardware in large data centers supporting our IT applications has brought certain elegances about equipment life and failure modes....making them someone else's problem.

However, by now relying on those Cloud resources it is all too easy to miss out on some of the vital security procedures that need to go along with this technology. High profile exposure has shown, for example, that Amazon S3 buckets might still be left insecure by users and therefore open to the World for their nefarious access and activities.

Albeit these problems may not have existed when equipment was on-premises, but if they were, we could tackle these issues close to hand while we could see them and audit them.

On another online resource WeLiveSecurity, it has been pointed out that "friendly" hackers are acting as vigilantes to place messages onto corporate IT held in insecure AWS S3 buckets (, and they are doing this to get around being harangued by the IT owners for exposing their shortcomings by public airing.

Whether harmlessly defacing a corporate IT to highlight an issue is right or not is a different matter, but this is starting to show an incredible number of organisations who are not securing their Cloud IT assets.

Because of the way the Internet works, all Cloud equipment is effectively accessible to anyone (because the owner can also get to it remotely) unless measures are put in place to restrict that access. As IT applications are hosted on these Cloud environments, these IT applications are open to connections from any computer that can access its host machine and network port, and these applications are practically advertising that information to the World.

The settings and other security applications required to properly secure an organisation's IT infrastructure in a Cloud environment are here today and very real, yet appear to be missing from many Cloud installations. Why?

It is all too easy to just create the software and application versions of the previous corporate IT infrastructure within a Cloud environment, but equally easy to completely forget the extent of trust placed in an [open] physical infrastructure located in another company's premises - which could be in any geography.

It can be easy to neglect the transition of the previous security architecture to the Cloud platform. For example; Group Policy Objects, Firewalls, physical segregation, network monitoring or in this case, connection monitoring on a Cloud, etc. IT needs to extrapolate their security architecture for transition into a potentially hostile external physical infrastructure and improve it where possible.

So there is a mix of misunderstanding of where trust boundaries lie, but also errors are being made when transitioning to a Cloud environment, and the Amazon S3 buckets problem highlighted recently, is only one example of this.

It would be far better for companies transitioning to cloud-based applications and services, perform regular soul-searching audits on their Cloud reliance, and follow our pattern for examining security holes, Detect, Analyze, Defend.