Separation of Duties within Cloud Environments

2nd June 2017

Feeling cautious about the cloud?

It is now 2017 and more and more businesses are realising the brilliance of cloud technology to reduce costs, create secure environments, and transform their business. However, we are still seeing some of the more traditional types of businesses (e.g. Financial Institutions) who are a bit cautious about their journey to the cloud. As these types of business handle extremely sensitive data, it is imperative that they are able to maintain their security stance while transitioning to the cloud.

For the most part these institutions will dig out their old Policy documents and attempt to shoe horn their current solution to fit the cloud environment which can produce some interesting results…

In this blog post we are going to look at one of the big problems that frequently pops up.

Separation of Duties

The purpose of having a separation of duty is to prevent a single person having “God-Like” powers within an environment. It means that more than one person has to agree on a given action. This provides an audit trail to show what was requested and highlights the governance surrounding it. This type of scenario normally happens around elements such as Access Control (In AWS for example IAM, Security Groups, Routes and NACLs).

So what can we do to maintain similar systems of control within cloud environments? A system that leverages the same tactic of separating duties between Teams or Individuals that gives us all that “Warm Fuzzy Security Feeling” that comes from well defined security policies?

Automation, Automation, Automation

So far the security teams I have had the privilege to work with through Cloudreach have been on the small side… and have the mission to maintain security in an environment where things are changing faster than Theresa May can change her mind on having an election before 2020 or her views on Brexit. This can make it a challenge for these overburdened teams to keep everything locked down and ensure that all policies have been followed.

How does automation help this?

Well, why don’t we look at some tools that are vital for most DevOps teams:

A benefit of the flexibility and adaptability of these tools is that we are able to separate all the different parts to fit with our teams/individuals structure. For example:

Developers are responsible for submitting rule sets to a Security Repository to describe what they would like from a Security Group or IAM Role/User Permissions.

Policy Security Teams can create “Stories” to describe the Security Policy using Behaviour Driven Development.

Technical Security Team will vet the rules and if applicable will accept the rule set into their repo and also create the Logic for the BDD tests mentioned above and maintain the verification endpoint.

Admins can manage the infrastructure of the Developer “submission” endpoint. Where the Developers will shoot their requests for new rules to be created

Auditors get to see real time logs of requests and submissions and can crawl through commit messages to see how the rule set has developed over time and matured.

The above is just one example of what could be possible, it is clear that automated tooling not only allows a small team to scale and service large organisations but to also in a secure and auditable fashion. If you are interested in taking this approach there is no end to the technologies you could add to this setup to build a totally customised and secured environment on top of your favourite Cloud Provider!

Whilst today most people are convinced of cloud’s many benefits – scalability, availability, cost reductions to name but a few – the cloud security piece is still falling into place. In order for companies, particularly those dealing with sensitive data, to feel comfortable scaling their cloud efforts, it’s important to adopt the appropriate tooling and roles/responsibilities to lay solid and secure foundations for the future.