(This post originally appeared on Anton Chukavin’s blog)
There is a lot of hilarity in how some organizations move to the cloud. Today, there are many stories of people who “lift and shift” during the migration. As a result, they bring pre-cloud tools and pre-cloud thinking along with them — and of course their pre-cloud problems. Hence, they miss their chance to improve when they migrate. Note that all this persists despite the fact that a second decade of cloud computing history is well underway.
As a funny aside, it is rather peculiar that I first learned the term “lift and shift” in its pejorative sense, akin to “forklift migration” and “anti-cloud patterns.” Only later I realized that some people follow this as a strategy when pursuing “digital transformation” and literally go to cloud with much of their legacy encumbrances …
Keep in mind that while at some level “cloud is just somebody else’s computer”, that is not entirely true. Modern cloud computing implies very different operational processes, new tools and practices — and concepts alien to traditional IT. Treating your cloud environment like just “another server farm” will set you up for both a failure and a big missed opportunity.
What if your move to the cloud is an opportunity to rethink not just your IT but also your security? Can you do security differently, better in fact, when you move? Why are organizations needlessly migrating their legacy security problems to new environments?
For example, cloud security research by analysts in recent years revealed that real cloud security incidents are most often not about new cloud technologies, but often about weak passwords, loose permissions, misconfigured systems. Essentially, these are the problems born in the 1980s, way before cloud was even on the horizon.
Gartner wisely reminds us that “Through 2025, 99% of cloud security failures will be the customer’s fault.” To be honest, to me this is an incomplete thought: don’t cloud providers also play a role in making this no longer true?
I think it is more useful to think that problems due to users tripping over overly-complicated security controls are not the users, but largely providers’ fault. Now, this is not about absolving IT organizations of any responsibility — the epidemic of ransomware, for example, revealed plenty of examples of extreme IT negligence. This is about a unique role cloud providers play in making security work.
Furthermore, can we also use cloud migration as a chance to break the famous security curse: that security is always late, always a bolt-on, always added after the system has been running in production?
Even today, many customers treat security as an annoying bastard child that gets in the way, a source of friction and delays. I’d venture a guess that this has some grounding in reality and such grounding is connected to security always being bolted-on later… And, sadly, often when you migrate to the cloud, security that greets you there is of a similar bolt-on variety…
Can we somehow transform this? At a bare minimum, ideal cloud security should meet the following standards:
- Default security (e.g. logging that just works and is always centrally collected and analyzed)
- Opt-out security (e.g. tight permissions that loudly object to being loosened :-))
- Transparent security (e.g. encryption of data in transit and at rest)
- Native to the system (e.g. not sold separately and requiring integration work and thus introducing new breakage points)
- Automated security (e.g. turned on after deployment via an API without installing and deploying)
- Role-based without the associated headaches (e.g. specific roles must be granted for safe management and access)
- Obvious security (e.g. not requiring the failure-prone user education)
For example, exposing a cloud web server externally should require adequate security checks and controls, possibly additional authentication, to ensure you have a securely configured, patched service facing the horrors of the internet. The responsibility here is shared by both the cloud provider and cloud customer who will need to make adjustments to security at the very least to adapt it to their business priorities. But a provider can make the customer’s job easy and make mistakes harder to make.
As another example, a multi-factor authentication (MFA) with some logic for intelligent step-up based on context and assigned role is becoming an inherent part of cloud management. The systems can be built by the providers with that in mind, rather than painfully retrofitted for MFA, introducing friction and user complaints, like legacy systems were.
Another example is related to container deployment, an area where provider — client responsibilities overlap appear really complex. Securing application within the container seems like a responsibility of a customer, but what about Docker daemons and other management components? In fact, there are certainly more things that a cloud provider do to decrease the chance of insecure containers going live (a recent case can be found here)
A final example is: systems that are pre-configured with logging useful for security that needs no configuration and with logs automatically retained and analyzed would make a huge step towards securing the public cloud. Note that today many struggle with enabling and collecting logs, with security processes breaking down before any chance of log analysis and threat detection. Default, transparent and usable logging is within reach if built that way by the cloud providers.
To conclude, migration to cloud infrastructure is a unique opportunity to dismantle the legacy security debt of the past two decades. Cloud providers will be doing more to make it easier to do so…
(this post is written jointly by Brandon Levene and Anton Chuvakin)
