Cloud security is getting attention and that’s as it should be.  But before you get hung up on techie security details, like whether SAML is more secure than OpenID Connect and the like, it’s good to take a step back.  One of the tenets of information security is to follow the risk.  Risk is largely a measure of damage and likelihood.  When you are looking at different threats to the same cloud-based data then it becomes a function of the likelihood of those risks.

In the cloud we worry about the technology and the host of the cloud.  Let’s focus on industrial-strength infrastructure and platform-as-a-service clouds like AWS and Azure.  And let’s throw in O365 – it’s not infrastructure or platform, but its scale and quality of hosting fits our purposes in terms of security and risk.  I don’t have any special affection for any of the cloud providers, but it’s a fact that they have the scale to do a better, more comprehensive, more active job on security than my little company does, and I’m far from alone.  This level of cloud doesn’t historically get hacked because of stupid operational mistakes or flimsy coding practices with cryptography and password handling, or because of obscure vulnerabilities in standards like SAML and OpenID Connect (they are present). It’s because of tenant-vectored risks.  Either poor security practices by the tenant’s admins or vulnerabilities in the tenant’s technology which the cloud is exposed to or on which it is reliant.

Here are just a few scenarios of cloud intrusions with a tenant origin vector

I’m going to focus on the latter scenario.  The point is that most organizations integrate their cloud with their on-prem Active Directory, and that’s as it should be.  We hardly want to go back to the inefficient and insecure world of countless user accounts and passwords per person.  We were able to largely reduce that of the years by bringing more and more on-prem apps, databases and systems online with Active Directory.  Let’s not lose ground on that with the cloud.

But your greatest risk in the cloud might just be right under your nose here in AD on your local network.  Do you monitor changes in Active Directory?  Are you aware when there are failed logons or unusual logons to privileged accounts?  And I’m not just talking about admin accounts.  Really, just as important, are those user accounts who have access to the data that your security measures are all about.  So that means identifying not just the IT groups in AD, but also those groups which are used to entitle users to that important data.  Very likely some of those groups are re-used in the cloud to entitle users there as well.  Of course the same goes for the actual user accounts.

Even for those of us who can say our network isn’t connected by VPN or any direct connections (like ExpressRoute for Azure/O365) and there’s no federation or sync between our on-prem and cloud directories your on-prem, internal security efforts will make or break your security in the cloud and that’s simply because of #1.  At some point your cloud admin has to connect to the cloud from some device.  And if that device isn’t secure or the cloud admin’s credential handling is lax, you’re in trouble.

That’s why I say that for most of us in the cloud need to first look inward for risks.  Monitoring, as always, is key.  The detective control you get with a well implemented and correctly used SIEM is incredible and often the only control you can deploy at key points, technologies or processes in your network.