Cloud Security

Have you ever performed a security review or audit of a 3rd party hosting provider before your employer signs on the dotted line?  Did you ever “have that moment?”.  It’s that time when exhausted from review fatigue you find yourself banging your head on the desk screaming ‘there must be a faster way’.  Well, you’re not the only one…

The scene goes something like this:

The provider rolls their eyes as yet another customer security team sends in their 500 deeply probing security questions, transmitted in some homegrown template in Word, Excel or $diety forbid, Powerpoint.  The customer security team, naturally suspicious of the provider and irked by managements apparent keenness to outsource the farm, has created the security questionnaire from hell:

• it’s the result of 100 hours of internal team meetings
• it’s gone through 14 drafts, 20 reviewers inboxes, 76 yellow highlighter comment fields and was printed at least 6 times
• it only asks IT security questions (no input from other relevant functions such legal/compliance/audit - HA!)
• it’s laced with a few tricky landmine questions based on potential security issues raised (but not satisfactorily answered) in online forums and provider support forums
• it contains 25 attachments detailing all the company security policies that *must* be followed (huh, Bluetooth policy requirements for a cloud storage provider…interesting)

In the context of cloud providers, they are slammed - a raft of audits in progress right now - with more expected soon.  The provider is experiencing an ADoS (Audit Denial of Service).  Instead of innovating new service offerings (including security!), the talented security professional at the provider is stuck cut and pasting answers from internal cheatsheets to customers questionnaires in the knowledge that the customer likely has no idea how much money it would cost to fulfill some of these security requests.  The sheer number of questions is confusing given that the customer IT team had stated they were only looking to host non-critical, non-sensitive data…

Audits are time consuming, repetitive across customers, costly and generally a motivational drain for everyone involved.  Moreover in the context of Cloud, time consuming audits seriously delays a key benefit of cloud - agility.  Its the “on demand” part of “Infrastructure on demand” that is a primary benefit of cloud.  If the security review process takes 3 months to complete, how much business opportunity has your employer lost?  Don’t like that question?  OK, another one: how much time could you have spent doing something more interesting?

Which leads me to some questions:

• what does the cost/benefit ratio look like of the “questionnaire security review method”? (to be clear, I’m not arguing against the need for security reviews)
• why do we all use different format questionnaires? (note: format)
• why are we asking these questions? (are the bulk of our questions simply an expression of our policy asked in a question format?)
• how many of these questions/policies are predictable and duplicated?  As in, you and I ask some of the same questions…we may differ in the details (e.g. password complexity..eek!) but we both probably ask the same base question even if our thresholds around answers are slightly different.
• what if we were to agree a set of common questions/policy statements?  We don’t all have to subscribe to them, we can pick the ones that reflect our policy…  There could be thousands, you search, pick and mix just like an iTunes playlist (Ed: Genius!)
• for those standard policy questions, could we “digitize” them and express them electronically?  Could the provider host a policy oracle that we could post these questions to?
• for those “uncommon” questions that the providers oracle cannot automagically answer, could we agree a standard way to “ask/transmit” those with some simple agreements about response formats? (um, freetext fields ;-).
• ultimately, could we “digitize” a significant portion of our questions to get near instant answers? (and could we make that multi-lingual…)
• would the provider recognise this as a benefit too?
• would the provider also see the legitimate opportunity this presents to charge for higher assurance services around cloud compute/storage/network based on our policy requirements?  “You want triple cycle, double buffering?  You got it - for an extra 5c per MB”).  Yes, the cost of  your security policies in a pay per drink model are revealed!
• would the provider recognise the opportunity to offer incentives to customers for choosing this low friction path of policy compliance instead of tying up their skilled employees filling out ad-hoc questionnaires?

Is there an existing system/application/protocol whereby I can transmit my policy requirements to a provider, they can respond in real-time with compliance level and any additional costs, with less structured/known requirements responded to by a human (but transmitted the same way)?  In other words, I’m looking for human driven, machine to machine policy exchange/agreement.

I propose that the benefit of quickly ascertaining policy compatibility along with any additional costs involved would reduce the on-ramp to cloud, reduce switching costs, drive a form of policy interoperability and take us closer to where we need to be in the long run: the ability to express security policy for a single unit of compute/storage/network in a cloud.  Ultimately, I want to be able to tie my security policy to the information asset I need to protect and push that to a cloud broker who performs policy reconciliation to determine which of my approved provider(s) can meet my needs without any human intervention (yeah, I can hope ;-).

And before everyone jumps on me and says ‘but the point of an on-site audit/security review is to get assurance that the provider is doing what they claim they are doing” I’d like to point out that policy and assurance are two different things.  Before you and the provider invest time in the optional on-site audit, why not get the bulk of the policy questions out the way in a fast and low cost manner? (i.e. “death to the questoinnaire?”).

If you’re following along thus far, you’ll also see the possibility for trusted 3rd party auditors to digitally ’sign’ individual policy statements made by cloud providers they have audited. That signature could itself reflect the assurance level you need.  This in turn could help drive the nascent cyberinsurance market for cloud…assuming the auditor is open to counterclaims by the insurer ;-).

If you do need to go on-site (and assuming the cloud provider tells you where “on-site” is ;-), you’ll have a list of items the provider categorically stated they do, meaning you can cherry pick the areas where you want to deep dive for assurance.  If upon inspection you find reality does not match stated policy, you can scream bloody murder.  Providers that mislead customers will soon get known.

Thoughts?

Yesterday, Amazon released a whitepaper called ‘Creating HIPAA-compliant Medical Data Applications with AWS’.  There is plenty to comment on, but for now I want to draw attention to some security concerns I have around AWS and thus its current readiness to handle data that falls under HIPAA.

I’m a big fan of Amazon AWS - they are true innovators and the diversity of their service offerings is astonishing.  There are many use cases for Cloud Computing and not all have high assurance needs. But when touting HIPAA compliance for the processing and storage of medical data, I can’t help feeling there are (amongst other things) glaring API level control gaps that would make me extremely uncomfortable with my medical data stored in the Amazon Cloud today.

Amazon is marketing their Cloud - with its current security controls - as able to support HIPAA compliant applications.  The whitepaper does a good job talking up their existing security controls but omits to mention a number of serious control gaps that decision makers should be aware of prior to committing “other peoples data” medical data to the Amazon Cloud.

I’m not a HIPAA expert and therefore in my ignorance, it may well be that AWS can satisfy covered entities security requirements (if so, it says more about HIPAA than AWS or, more about a specific use case).  Consequently, I’ll step aside from the ‘compliance’ angle for a moment and confine my comments to ’security’ and encourage those with first hand HIPAA compliance experience to comment as they see fit.

There is no customer accessible AWS API call audit log

In other words, you have no way to know if, when and from where (source IP) your AWS key was used to make API calls that may affect the security posture of your AWS resources (an exception is S3, but only if you turn on logging (off by default)). For example; if your key is compromised without your awareness and your EC2 “security groups” (firewall) are changed, there is no customer accessible log record. The only way to detect this is to poll the API on a regular basis (DescribeSecurityGroups) and compare with the output of previous calls or to call up Amazon support on a regular basis and ask them “is all well?”  (j/k).  I can think of much more sinister API calls to invoke, the security groups is just an example.

They also afford no customer visibility over failed authentication attempts at the AWS web interface or at the API.  Again, no visibilty to understand if your infrastructure in the sky is under attack.  Fine for some workloads, not so fine for others.

Oh, and while we are at it, why is there no firewall log for the built in ’security groups’ firewall functionality?  To get visibility today, you have to run a host based firewall with logging enabled but even then you will not see what was dropped by Amazon (when doing network security investigations, this information can be really helpful).  Basic reporting accessible to customers would be a good start.

There is no way to restrict the source IP address from which the sacred AWS API key can be used from

The AWS API interface can be used from any source IP at any time (and as above, you have no audit trail for EC2 API calls).  This is equivalent of exposing your compute and storage management API to the entire planet.  To be clear, they are not exposing their *internal* management plane - the infrastructure that the Amazon AWS team uses to manage the AWS infrastructure, rather its *your* hosted infrastruture management plane that is exposed.

Why can’t the EC2 security group concept (aka firewall) be applied to the AWS API, to limit access from approved management stations? After creating my key I should have the option to limit use to specific subnets of my organisation.  I’d love to hear this option is on the Amazon security roadmap (along with visibility of failed attempts).

Each AWS account is limited to a single key - exposure results in total security failure

I’ve said it before and I’ll say it again - you only get a single key per AWS account.

That makes it really hard to segregate environments.  To do so, you have to create multiple AWS accounts with different credit cards and even then that only gives a very coarse grained access model.

With your master key, why can’t you generate a handful of subkeys for different use cases?

If you could link those subkeys to roles that reflect your security policies, then you’d really have flexibility.  This would also mean you could lock away the all-powerful master key for use only when such power is warranted (thus reducing potential exposure).

The failure mode of a single key is ‘complete and utter’.  If my key is compromised, my entire AWS environment is compromised - all my virtual machines, all my data.  I don’t know about you, but that scares the living daylights out of me in the context of medical data.

Takeaway

Hopefully we all know by now that “compliance” does not equal “security”, but HIPAA compliance not withstanding, would you really want your medical data in a Cloud without some or all of these fundamental control gaps resolved or mitigated?  I can’t find anything in this new whitepaper or the old AWS Security Whitepaper that speaks directly to these issues.  If I missed something, please share below and I’ll update the post.

When medical data is stored at the medical provider, I can believe they will have a firewall that doesn’t allow outsiders to make API calls to their compute and storage management plane from anywhere in the world…  I can believe that leakage of an internal infrastructure management password cannot be used from *outside* the firewall.  At least, not without first exploiting an unrelated security weakness to gain access to the environment in the first place.

I can appreciate that providers are keen to demonstrate use cases but I can’t help feeling that in their eagerness to market ‘compliance’, Amazon is putting the cart before the horse from a security perspective.

What do you think?