The 6/30 Virtualization Security Podcast with Simon Crosby Founder and CEO of Bromium started with a discussion of SaaS security but soon went to a discussion of Data Security. Simon left Citrix not to long ago to form a new company, Bromium, to seriously look into how the hypervisor itself can provide better security for data manipulations than it does today. But first we started off with SaaS and how you can Identify the user within a cloud.There are several key aspects to SaaS security, the first being identity. How can you ensure the identity of the user within the cloud? Or perhaps ensure the identity of the data within the cloud? So the first step to SaaS security is identity, the second then is a way to secure the data held within the cloud. Not only data at rest but data in motion?
There are several projects currently working on identity within the cloud.
- VMware Project Horizon
- RSA Trust Cloud
- Other Enterprise Portal methodologies
The key to this is to ensure that the identity of the user when he enters the application on his end-point device such as an iPad is translated into something the SaaS application understands by a third party, that third party maintains the identity correlation. In general, this would look like a single-signon mechanism but in truth the third party could possibly be using another username/password only known to the enterprise to access the SaaS service. While it appears the user is logged in, with the appropriate names and such, the credentials used are actually unknown to the user. This approach could give the enterprise a more granular view of what is happening within the SaaS application and the user’s password would be complex as would the username. Thereby alleviating the need for the user to authenticate using weak passwords.
However, single-signon has its own issues. If the iPad or device was stolen, could someone still assume an identity? It could be possible if the initial password to enter the enterprise was also weak or the enterprise portal was not also doing behavioral analysis so that there are once more two factors of authentication (what you know and what you are).
The key to data security may be being able to detect those small behavioral inconsistencies that determine that is not the proper person or action to take place and nip such actions in the bud before they actually manipulate the data. Such granular control could be what Bromium is trying to solve, by moving DLP approaches directly into the hypervisor before data can be manipulated.
Unfortunately, behavioral analysis is only so good, there are still lots of false positives, so we are still stuck with whitelisting/blacklisting approaches. Whitelisting is by far the better of the two approaches.
But ideally what we need is Zero-Trust-Anonymous Identity when using the cloud such that our identities are completely obfuscated or encrypted in such a way that the bad guys cannot see who we are. If we login to a portal to gain this, that portal needs to be in a safe arena, and the approach discussed about using unknown random string usernames and strong passwords/phrases may be the first step to achieving this.
In either case, we need to consider how to encrypt the data we put into the cloud. There are several solutions as well for this, but this level of encryption depends on the SaaS environment and unfortunately with access not available everywhere we have a data usability issue when on the road. So data needs to be downloaded and usable onto local devices. Which often means unencrypted.
However, this leads to a discussion of lawful intercept and discussions around forensics (a conversation for another times).
* The travelogue video was produced by Lars Troen
The issue here is clearly around the initial establishment of trust and then the subsequent authentications that both parties are the same ie who they say they are. Clearly a SAAS solution is required for rapid deployment and there are not that many that fit the bill and also satisfy the basic requirement of genuinely authenticating the user. Federated solutions like SSO serve merely to ‘identify’ which as is pointed out in the article is not sufficient for the basis of trust required. For a solution that does not rely on tokens, dongles, cookies, javascript or SMS’s – ie those mechanisms that have been shown to have failed ( read the news !) – then have a look at LiveEnsure which is a unique and radical approach to securing the log-in / SSO / Open ID.
Hello,
Actually I did look at LiveEnsure and I am not convinced it will solve the problem. While it seems to verify a device, how can it verify the user? How can I ensure the user of the device is really the user we want to use the SaaS solution? It is not about the device but about the identity of the user. We can never assume that a device is in friendly hands and if it is not, does LiveEnsure do behavioral analysis to be sure it is the proper user?
This is why I think some form of behavioral analysis is necessary… I.e perhaps on an iPhone it is the apps one use, in an order, and the frequency of use and actions taken (such as killing background tasks)?
Best regards,
Edward L. Haletky