Picking a Secure Hybrid Cloud Security Solution

In the past we have discussed the various aspects of the secure hybrid cloud, ranging from the data center through a transition stage and finally to and from the cloud. Unfortunately, picking just one security solution, or even one family of solutions, does not work, so we need to start thinking outside the box and pick the best based on our needs, which cover compliance as well as security. So how do we pick a security solution based on our needs? First, we need to have a picture of the secure hybrid cloud so that we can better demonstrate to ourselves and others (management) how our data moves around the secure hybrid cloud as well as how the users interact with that data.

Secure Hybrid Cloud

Figure 1 shows us a picture of the secure hybrid cloud that we can use to discuss how our data moves and how the users interact with the data. The aside to the right gives some definition around the figure. We could try to pick a tool that lies at every junction, but that would be ineffectual, as sometimes we cannot place tools within other organizations’ systems (such as is the case with SaaS providers).
We could also place controls around how people within our security bastions can access the data, but that does not work if they access the data directly. Our security must consider the bastionless nature of the secure hybrid cloud. So where can we begin?

Assume Data Is Already Out There

We need to assume first that some of our sensitive data is already out in the cloud, out of our control. The simplest thing, which is considered organizational data, is the telephone book. We can assume pretty easily that part of that telephone book is sitting on every employee’s smart phone. If we can make that assumption, can we not make others? It is best to assume the data is already somewhere else. This way, we do not waste our time and money determining ways of closing the barn door after the data is out.

Determine Which Cloud Services Are In Use

After you make that assumption, it is then desirable to understand exactly which cloud services are in use and what data is moving in and out of the cloud. Depending on how the cloud is accessed, you may be able to place something like Skyhigh Network’s Cloud Access Security Manager or another packet filtering–type device in the path between the cloud and the edge firewall of your office or data center.
But we may not be able to get all the cloud services in use, as we cannot put this device in line with those not on our network (smartphones, tablets, etc.)

Data Classification

The second step is to classify all data. Determine which data require advanced styles of protection such as encryption, tokenization, or some form of redaction. Once we know what data is already in moving from our data center, office, etc. to the  cloud, we can then determine from our data classification stage what data needs to be protected.
In essence, why waste time protecting data that is public knowledge, unclassified, and not necessary to protect. Perhaps, for example, the entire phone book is worth protecting, but a few items are not. If that is the case, then why expend the energy trying to protect a small usage case when instead we could easily encrypt the entire phone book so that if it does leave the safe haven of our data center (or wherever it is), it is protected in some fashion. However, if it has already left the building, as they say, then a new method of protection needs to be developed. One that understands that not only is there an old form of the data available, but also a new form.

Encryption: Not the Only Solution

In many cases, the need to protect data as it moves around the secure hybrid cloud falls onto the shoulders of encryption. The best solution is often to encrypt your data so that when it is in a place it should not be, the key to that data is not in the same place. The key is a combination of what you have (perhaps an application on your smart phone), who you are (some form of biometrics), and what you know (your secret code, handshake, path through a specific set of routines, etc.), which provides an identity that can be associated with a specific key to access the encrypted data. However, sometimes you may just want to know if the data has been modified and not encrypted.
If all we want to know is the integrity of the data, we can digitally sign the data such that if the data is modified, the digital signature will not match the data. This is similar to all-out encryption, but instead of encrypting the entire document, a cryptographic hash (signature) is produced for the document using a similar type of key mechanism as encryption. Actually, to verify a document takes the same mechanisms to determine identity.
Some software such as AFORE Cypher X works with applications, why others from Symantec, Vormetric, High Cloud Security, and SafeNet work with the specific data providing encryption and cryptographic hashes through out the secure hybrid cloud. In the case of Vormetric, the format preserving encryption works within smart phone browsers without add on software.

Identity

Tied into everything, however, is the concept of identity. In order to be able to decrypt, check a digital signature, or perhaps even access the data via a SaaS solution, we need to understand the user’s identity. But identity must include location, device, user, etc., and it must be passed as a whole to the internal applications. We mentioned above, under Encryption, that to get the key we need at least two factors of authentication. I think it should be at least three these days, with some augmentation to all of those based on location and device. Unfortunately, currently we can only get this data as far as the gateway; we need it to go further perhaps by adding into Active Directory, etc. Even so, with all this, we need to constantly inspect our authentication and authorization sources to ensure least privilege. One tool that meets this need is IdentityLogix. The goal is to ensure a user has least privileges across their body of knowledge. When it comes to AD, it is possible to have users in a myriad of groups, each contradictory when it comes to authentication. Depending on the tool, the users could have more access than they need.

Concluding Thoughts

It is crucial within the secure hybrid cloud to classify all data within your organization, assume that the data has left the building, and concentrate on tracking down how the data moves, what cloud services are in use, and finally control of the identity around access (encryption) and verification (digital signatures) of the data. Ultimately, we also want to use tools that produce adequate logs that can tell us who had access to the data, when they accessed it, what they accessed, from where they accessed it, and how they accessed it so that we can determine the why of the access. Unfortunately, not all cloud services produce such logs. Perhaps you can redirect users based on using tools that produce the adequate logs.
When you pick tools for the secure hybrid cloud, you need to meet compliance—which could mean implementing a typical IDS/IPS/Firewall combination—but realize that this is severely limited to only one place of the hybrid cloud. We need to think of other ways to determine exactly what services are in use, where our data is currently, and how to protect that data if and only if it actually needs protection without being draconian; security should meet the needs of the users as well as policy.
This may be a slow process, but it is an important start to the process of securing the hybrid cloud.