Security Fundamentals Are Key To Successful Cloud Migration

by Lorenz Jakober on August 2, 2019

Earlier I wrote about the importance of patching, or more accurately the importance of transferring the need to patch (& the associated risk) to someone else by using their cloud security service. While patching definitely falls into the security fundamentals category it remains as relevant as ever, but it’s not the only security best practice we need to collectively remember.

If recent security events (yes, you all know what I am talking about) are anything to go by, a back to basics approach to security–across all of our workloads–is as important as ever.

The old faithfuls of least privilege and default deny are clearly as relevant in your favorite cloud environment as your own colo. While we all (or at least I do) love talking about the latest security frameworks and sophisticated attack patterns, the stark reality remains that we need to continue to focus on security fundamentals.

As the old adage goes: crawl, walk and then run.

That’s not always easy as we shift our workloads to cloud environments. Who owns securing our IaaS workloads? Is it us, is it our providers, or (everyone’s favorite) is it a shared responsibility model? Many blogs and Twitter conversations have been spent on this topic. At the end of the day the shared responsibility model is well documented; you are responsible for applying the appropriate security controls to your own apps and data.

Sponsorships Available

Case in point. Let’s look at a recent example of an alleged misconfiguration that led to data leakage. In this case a forward thinking financial services company with years of experience deploying technology in cloud environments fell victim to a data breach. According to a released statement by the cloud services provider the cloud infrastructure was “…not compromised in any way and functioned as designed.” This clearly points to the shared responsibility model: the cloud provider is responsible for providing infrastructure that is inherently secure, but the responsibility falls to the company using the cloud service to apply security controls to protect its apps and data.

Now most IaaS providers have helpful defaults and controls around who or what can access what. Using the prior example, cloud storage buckets are private by default, so they can only be accessed by users that are explicitly granted access. But as we all know there is some inherent complexity there. Even with those safeguards in place open IaaS storage buckets, and their content, have been a security blog/breach staple for what feels like ages.

The evolving workforce profile of most organizations including contractors, transient consultants, off-shore devs and remote workers, who often use unmanaged devices, contributes to this access provisioning and maintenance nightmare.

Further compounding this problem of who has access to what is the fact that some of us try to lift and shift our broken security and access best practices (moats and castles anyone?) to our IaaS environments which often results in trading real boxes to create a DMZ, to virtual boxes with the same overly permissive access model. Once authenticated, of course I can move laterally in my environment… but I am getting ahead of myself.

Let’s start with the fundamentals: isolate your IaaS workloads and data from the Internet.

Yes, there are audits, assessments and controls made available by most IaaS providers so start there, but let’s be frank. We all know something will slip through the cracks somewhere. Ultimately you want to focus on securing what matters: your users, apps and data.

Securing apps and data in your IaaS environment adds some inherent complexity, because a simple misconfiguration can expose your data to the world. Don’t we all love Shodan?

Either way, the best place to start protecting your users, apps and data – whether in your colo or IaaS environment – is at the edge.

Security at the edge helps you deploy consistent policy that is infrastructure agnostic. If we believe that 85% of businesses will pursue a hybrid or multi-cloud architecture and we recognize that cloud provider security solutions only offer basic controls for the apps and data provisioned to that particular environment, then the criticality of edge protection–across all infrastructure–becomes abundantly clear.

Akamai can help you hit your stride with securing access to corporate IaaS workloads and data by continuously evaluating access and trust based on a risk score calculated from a multitude of signals including:

Identity & contextual signals such as time of day, location, specific URL & HTTP method, user agent string, authentication state, MFA, group membership, etc.
Device signals such as presence/validity of a client certificate, OS version, auto update, disk encryption, firewall status, etc.
Threat protection signals from EDRs like Carbon Black or Akamai’s own Enterprise Threat Protector

Here’s the bottom line: leveraging an automated approach to protecting your IaaS workloads and data is clearly the only viable way to backstop any potential gaps you have in your native IaaS access control model.

Remember, start with security fundamentals to effectively crawl, walk and then run.

If you want help getting started take our Zero Trust self assessment, sign up for a free Zero Trust evaluation workshop, or check out our paid security services to start hitting your stride.