I think that it might be a novel approach to build a flat cloud security control model centered around consumers (stake holders, users and developers) of business applications software and the performance of the cloud services that they consume.
This might be a more productive and relevant control model than then the current complex, multiple layer, IT infrastructure and compliance-centric cloud security models that are being copied and pasted today.
It’s also more consistent with a technology shift towards consumer devices and services and an emerging transformation of the security industry from an end-user service industry to a B2B product. Intel bought Mcafee. Two years ago, we still had end user customers. Today we only deal with technology vendors.
The cloud security reference model published by the CSA (Cloud Security Alliance) is a detailed and comprehensive guide to “Security for Critical Areas of Focus in Cloud Computing“. The latest version was released in December 2009, back when Facebook had less than 80 million members.
It’s a long, eloquently written document with pearls of wisdom like:
Cloud computing is about gracefully losing control while maintaining accountability even if the operational responsibility falls upon one or more third parties.
I could not agree less.
We all use the term “IT Governance” – as if security of customer data was dependent on the governor of the IT department. Since we have lots of IT governance and lots of data breaches, we may safely assume that writing procedures while the hackers attack software and steal data is not an effective security countermeasure.
Management information systems, (aka Information technology) is about empowering management with information.
Cloud computing is about replacing the hegemony of management with the freedom of choice of business units.
Cloud computing has nothing to do with gracefully losing control – it’s about getting out from under the thumb of the CIO.
This is why a performance-oriented security control model is a better and more relevant fit for consumers of cloud services. What interests cloud computing consumers are the following questions:
- Does the application or service help me sell more, faster and cheaper with something different my customers haven’t heard yet?
- Can I deploy (HIPAA, PCI DSS …fill in the blanks) applications in the cloud at a price I can afford?
When we buy software application services (SaaS) using a utility model, then the security should not interest us, since it’s built in.
When we develop our own application software and run it in the cloud using an IaaS (infrastructure as a service) provider then the IT security infrastructure does not interest us, since it’s built into the infrastructure.
What should interest us is business performance and service costs.
Neither of these are addressed in the CSA cloud security reference model, which is still fixated on familiar infrastructure controls:
This rigidity often manifests in the inability to gain parity in security control deployment in cloud environments compared to traditional IT. This stems mostly from the abstraction of infrastructure, and the lack of visibility and capability to integrate many familiar security controls — especially at the network layer.
Why should we be concerned with parity in security control deployment when I buy a service?
When we buy electricity, are we comparing our utility and safety expertise in electricity generation with the electric company?
I don’t think so.
Consider, a consumer-service provider cloud security control model that is focused on performance.
The fundamentals of scalable cloud computing systems are fast networking and non-blocking design—the rest is message passing.
Current Web applications running in the cloud are fairly high latency (200-600 ms round trips for Ajax transactions) and demanding on the server infrastructure (forking threads and blocking IO on the Web server for every request).
Looking at business performance we know that time is money. We know that high latency applications are less responsive (making customers unhappy and reducing revenue). Since the cloud service provider charges per CPU cycle, if the cloud service consumer deploys inefficient applications his revenue goes down and his costs go up.
Since cloud computing is a utility, it’s a business decision to write inefficient, buggy code and pay more for the privilege. It’s also a business decision to use services like Microsoft Azure which locks you into the Microsoft application development platforms or Salesforce.com that locks you into the SF.com way of doing things.
There is something counter-intuitive about locking yourself into a cloud computing service. The price has to be right long term and long term may be a decision that your successor is taking. Hmm. Food for thought.
Power to people baby.