SBN

Cloud Migration Security Woes

As I hear of organizations dealing with security when migrating to the cloud, I occasionally observe cases of “extreme lift and shift.” I use this label to describe a case when an organization wants to keep every single security technology that they use on-premise after they move to the public cloud. The list can be very long and tedious; it may include such staples as firewalls, anti-malware, SIEM, EDR, NIDS, and even network forensics and NDR.

Let’s ponder this situation without judgement. Two things come to mind first:

  1. Focusing on controls vs control intent
  2. Adapting to threat model changes

First, why are existing controls being replicated verbatim if there are cloud-style controls available from your cloud provider or from a cloud-focused third party vendor? Won’t you be better off if you “deduce” (or: find the documentation for) the intent of the existing controls and then deploy cloud controls that serve the same intent? “Better” here may mean both more effective, less expensive (!) and likely more secure. For example, you may have used a security configuration scanner on-premise, but now you can use the tools your cloud provider has for the same purpose?

Second, why are the same controls even considered if the threat model may be different? Assuming your on-premise controls served your compliance, security and risks perfectly (it IS possible, no?), why do you then assume that your requirements are the same in the cloud? In fact, you have robust evidence that they are not! Here is a trivial example: physical security is well taken care of so some threats are clearly gone from your model. There are in fact both added and removed threats. In theory, you now have a new class of insider threat. And you have a broad range of threats that either become irrelevant or are effectively addressed by the provider.

So.

Mini-conclusions / actions:

  • When migrating to the public cloud, look at how your threats change as a result (this came out as “duh!” advice, but it seems needed nonetheless …)
  • When reviewing your existing security controls before migration, look at their intent and then (if the changed threats above make this intent still relevant) consider cloud-focused/cloud-native controls to address the same intent.
  • To do the above well, you do need to spend a bit of time learning about the cloud-native security controls (example)
  • Don’t just copy/paste security stuff from the data center world to the cloud world!

P.S. Well, this came out more of an incomplete thought (because, frankly, there is a lot more security choices when migrating), but I feel that these two deserve a lot of attention.

Related blog posts:


Cloud Migration Security Woes was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.


*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/cloud-migration-security-woes-14d7301b9e3b?source=rss-11065c9e943e------2