cloud

Sharing is usually considered to be a positive attribute – parents teach children to share and we are moving into a “sharing economy” with services like Zipcar and Airbnb. For most businesses and the security of their sensitive data, sharing is a threat. In fact, numerous laws have been created to curb or manage sharing including copyright provisions designed to protect music, books, software and more. Cloud security is no exception. For businesses, sharing responsibility for the security of their data with a cloud service provider can lead to unpleasant consequences and finger-pointing. For years, standards bodies like the PCI Council and leading cloud providers like Amazon Web Services and Microsoft Azure have fostered the perception that shared responsibility for security in the cloud with infrastructure as a service (IaaS) providers is the best approach. Times have changed, this is no longer the case.

Todd Thiemann

What is the downside of shared responsibility in the cloud?  The enterprise has ultimate accountability for security of its data, yet must share the responsibility for data security with the Cloud Service Provider (CSP).  Put another way, shared responsibility means shared access to your sensitive data.  You share responsibility for security of the overall environment, but implicit in that relationship is that your CSP can access your data.  You might not like it, but the shared responsibility model forces you to trust the CSP and face the consequences when the CSP falls short.  Amplifying these consequences for the enterprise are CSP terms of service that are typically one-sided and hand the aftermath of breached data to the enterprise customer.  Consequences can include fines, reputational risk, and lost competitive advantage – items that would not be covered by a CSP refunding your payment.  The shared responsibility model also requires elaborate and time-consuming legal contracts so the obligations of the CSP and the enterprise are understood.  While shared responsibility can be mitigated in a Software-as-a-Service (SaaS) where the SaaS vendor is fully accountable for data loss, it does not make sense in the Infrastructure-as-a-Service (IaaS) world where IaaS vendors significantly (Amazon EC2, etc.) limit their responsibility for security.

While the CSP needs to provide their service with sufficient security to satisfy customers, the CSP is usually not the one holding the bag when something goes wrong.  Interest in cloud encryption has grown as enterprises wrestle with securing their data at the CSP.  Enterprises understand the need to secure their data while at rest and while in transit by holding the encryption keys themselves. However, the shared responsibility model circumvents at-rest and in-transit encryption; the cloud service provider can access enterprise data-in-use while the cloud server runs in the CSP datacenter.  Data-in-use, or memory, contains secrets including encryption keys, digital certificates, and sensitive information such as intellectual property.  Accessing data-in-use leaves the door open to lawful or unlawful interception of data of any data on the server.  Sensitive data can be encrypted at rest or in motion, but it is “in the clear” and available to the CSP while in use.

What if a new technology allowed you to have control and visibility into the security of cloud servers without ever having to set foot in a cloud data center?  PrivateCore does just that, allowing the enterprise to take complete ownership of data security rather than relying on the CSP.  This approach also permits the CSP to focus on their core competencies and reduce liabilities.  PrivateCore vCage provides a secure foundation, ensuring that nobody at the CSP can access or manipulate your data without your consent.  Deploying vCage as a foundation of trust for your IaaS security enables you to avoid lengthy security negotiations because you control the security of your server and its data.

PrivateCore vCage secures server data-in-use with full memory encryption.  Data-in-use can contain valuable information such as encryption keys for data-at-rest, certificates, intellectual property, and personally identifiable information.  Accessing data-in-use provides a pathway to decrypt data-at-rest and data-in-motion.  Compromising data-in-use, be it through a malicious insider or lawful request, leaves a system open and available.

While security measures such as data-at-rest and data-in-motion encryption are necessary, they are insufficient if the foundation has a crack that allows information to be siphoned off.  PrivateCore vCage changes the game, obviating the need for “shared responsibility” by providing a foundation of trust in the cloud so you can take control of the security of your data in the cloud.

If you’re reading this blog, you might be wondering what this PrivateCore thing is all about.  I want to give you some perspective on the company, the problems we intend to solve, and why I believe it will leave a dent in the security universe.

What was the big problem that I saw that motivated me to co-found PrivateCore?  I’ve been in this industry for over 20 years, most of the time building information security products.  At my core, I am a security technologist trying to deliver value in the real world.

As I looked around the industry a few years back, I saw virtualization taking over the data-center and how virtualization-enabled infrastructure-as-a-service (IaaS, AKA cloud computing) was taking off. While the cloud’s agility, scale, and pay per use model offer enterprises great value, it was clear to me that cloud (in)security will be a top concern for the enterprise.

Virtualized Does Not Mean Magically Secure

Virtualization allows for the decoupling of virtual machines from the underlying hardware, making it possible to move computation around without requiring changes to the source code or the binaries of existing applications. Virtualization gave birth to cloud computing, but it did not made it secure.

The ability to consume computation as a service does not remove the enterprise need for security, and enterprises expect the same security controls in the cloud as they have in their own private data-centers. Indeed, most security controls such as network security, access controls, patch management, and application configuration, can be deployed as software solutions by the enterprise. However, there is one group of controls with which the enterprise struggles: physical security controls.

The Physical Access Gap

With physical access you don’t need to hack your way into the network, you can simply walk away with the data. Back in the enterprise data-center, physical security controls protect against physical extraction of data. With physical controls in the hands of the cloud providers, enterprises find a whole new set of people roaming unnoticed around “their” share of the cloud provider data-center, starting with the cloud provider employees, sub-contractors, and sometimes even government agencies armed with subpoenas looking to get access to data.

The concept that started dominating my brain was: how can enterprises secure their data in the absence of traditional physical security measures that the enterprise directly controls?

To eliminate the obvious, let me quickly explain why traditional data-at-rest encryption and data-in-transit encryption can not mitigate the “physical backdoor” problem. The flaw with these technologies in the cloud is that even when data is encrypted on disk and on the network, the data must be decrypted for processing. This leaves the data, as well as encryption keys, out in the clear to be grabbed via physical access.

To put it in simple and familiar terms, we use network encryption such as https, or vpn so we could use public networks, knowing that if an adversary can sniff (i.e. read) the network traffic, she will only see encrypted data rather than our plain text conversation. Similarly, an adversary with physical access to our server in the cloud, can “sniff” the memory, and access the information we process by exploiting his physical presence. It is this unfortunate truth that today requires us to trust that our cloud provider and their affiliates will resist the temptation to peek into our data in use.

PrivateCore: Building The Foundation for Secure Computing

I started PrivateCore with the purpose of solving this problem. To create the technology that will once and for all provide a secure computation environment, an environment in which cloud providers will not have the option of peeking into enterprise data flowing through their compute infrastructure. A technology enterprises can leverage and use on their own terms, to secure public computation just as they secure todays public networks and public storage.

So, that is the brief version the origin of PrivateCore and how we’re challenging the assumption that having physical access to hardware means you can gain unauthorized access to data.  In future blog postings, I and the rest of the PrivateCore team plan to periodically blog about industry happenings, what we are up to, and ways we see to improve enterprise data security.  Please join the conversation and share your opinion and viewpoint!