Get in touch
Get in touch

“My Clouds’ Secure and Compliant”…. really?

June 6, 2019

We hear a fair bit when talking to customers, statements like the following “We’ll just move this to the cloud, they will do security better than us anyway”.  When I hear statements like this and do a little more digging I find it’s more like:

  • They believe that the cloud provider will provide more robust security than they could.

OR

  • “The business wants to move a ‘Process/Application/DEVOPS’ to the cloud and I don’t want my head on the block for getting in the way raising security questions and concerns”.

There is still the belief out there among many people that I talk with that 100% of the security aspect will be managed by the cloud provider and there is nothing more for them to do – that is what I used to think before I was educated on it as well. Just like we all thought that VM’s were fully managed when the cloud first came about.

Before reading on I want to make it clear that THIS IS NOT a scare piece about moving to the cloud, fearmongering or a lecture about this topic, quite the opposite. It’s about bringing awareness to what you might need to be thinking about and making sure you have the correct metrics in place that meet your requirements (business and legislative). 

Tried and true statement – “Security in the cloud is a shared responsibility between the cloud provider and ………….blah blah blah”.

The simple fact is AZURE/AWS/GCP are not going to call you saying “Hey, APRA says you need metric A/B/C to put that data there” or the folk at 0365/Dropbox are not going to call saying “Hey, that document you just shared has accidentally been exposed to anyone on the internet”.

A Real-World Example…

As a test we ran up a Windows 2012 machine in an AZURE US region using the default metrics (HTTP/HTTPS/RDP/SSH) to get remote access to the server.  Using the Diversus Group Security Managed Platform (DG-SMP) framework the following Cloud Compliance issues where flagged:

Violation of the following cloud security compliance standards*:

  • GDPR
  • HIPAA
  • NIST 800-53 Rev 4
  • NIST CSF
  • PCI DSS v3.2
  • SOC 2
  • DG Security Policy

Across those compliance standards the following policies where flagged:

  • Machines and resources residing outside of AUS datacentres locations
  • Azure disk for VM operating system is not encrypted at rest using ADE
  • Internet exposed instance
  • Internet connectivity via tcp over insecure port
  • Storage Accounts without Secure transfer enabled
  • Azure Network Security Group (NSG) allows SSH traffic from internet on port 22
  • Azure Network Security Group (NSG) allows  internet traffic on port 3389
  • Azure Virtual Machine is not assigned to an availability set
  • Azure storage account logging for queues is disabled
  • Azure storage account logging for tables is disabled
  • Storage Accounts without Secure transfer enabled

*It all depends what compliance standards you need to adhere to, what data is hosted, etc.

Are we saying that spinning up a VM/Storage/Process to do some work in the cloud is a bad thing and scary?  Not at all.

What we are saying and trying to bring awareness to is:

1.) Would you have been aware of the potential compliance violations and

2.) Do you have the correct security controls and metrics in place to ensure that Process/Application/DEVOPS can be moved/run-in cloud without the consumer (i.e. your users/devops folk, etc) having to worry about this security stuff?

A quick high-level example using internet banking to highlight the point we are trying to make. Sure, the onus is on you to protect your credentials but everything else is on the bank – it’s inline and they don’t make it your problem. If this was anything else you would move banks.  They provide a framework for you to consume that service.

Questions you should be asking or should know the answers to for data that has been moved into the cloud and for data that resides in the cloud:

  • Any security process that is put in place, was I able to put in as an in-line process or have I now put in roadblocks and become the Soup Nazi (people born before 1983 will need to Google that one).
  • What compliance rules do I actually need to adhere to? Have I over or under cooked it?
  • Can this data reside outside of an Australia DC regardless of provider? Does it matter?
  • Do we have the correct policies and security framework in place for this data?
  • Once we move in and are compliant, how do we make sure we stay compliant going forward?
  • What if someone changes something that then breaks compliance?

If you have read this far through the post, the Diversus Group Security Managed Platform framework can help address some of these challenges.  Our ethos is in the cyber security area – it always starts with a conversation rather than a lecture and fearmongering.

Author: Matthew Agoni, Chief Technology Officer (CTO) Diversus Group

To learn more about how we can help your business
Contact us today