Hi. My name is Rich Campagna with Bitglass and I couldn't wait to get in here into the studio and record today's glass class session. Today we're going to be talking about how cloud data leaks. We just got off the phone with a Fortune 500 major technology company that is moving to Google apps and wanted to figure out what's my real risk and what's my real exposure here.
One of the things that this gentleman just said was that the biggest thing he's concerned about when he moves to Google apps is something like external sharing. They have sensitive data that they want to protect and he's scared that their employees are going to share sensitive content here outside to their own personal Gmail accounts or to people outside of the organization that they shouldn't have access to. Essentially, he basically summarizes cloud data leakage problem as external sharing that's run DLP or data leakage prevention patterns against some of these data that's at rest inside of the cloud and then figure out if it's being shared outside and control that sharing. That was basically his summary of cloud up risk.
The way that you typically do this is with an API focused cloud access security broker. The way these APIs work is they go and scan all the data at rest inside of the cloud application, identify what's sensitive, identify what's being shared outside of the company and then allow you to control whether or not that's being shared or at least provide some visibility at the very least. This is certainly something Bitglass supports and our customers use this every single day but the challenge is this is only one part of the picture.
There's another part of the picture here and let's get start to drive out which is equally if not more important, that's on the user side of things. The traditional environment within IT, we have just managed and locked on devices into our internal applications and we could control everything in between this entire transaction from application down to the device. In the cloud road, it's not that simple. Sure, we still have people accessing managed devices, we also have BYOD devices coming into play here as well. On the managed device, the cloud has made it so easy. Sync on a Google Drive, so easy to sync data. I do this on my own device on a daily basis. I have the Google Drive application installed in my Mac book and I sync a whole bunch of corporate data from Google Drive down to the device itself. That represents an area of risk and potential leakage. If I lose this device or if as an employee, I might have whole bunch of data download to the device itself and I go rogue or try to leave the company and steal data. I probably can do that.
The other issue here is BYOD. Maybe, once again, the user loses the device or maybe their account gets hijacked so this what we think is a BYOD employee device is actually someone else's device using that user's compromised credentials. There's a whole set, I could go on all day about problems related to the point of consumption itself. If we go back to this API model with cloud access security brokers and there are a large number of them that are purely API focused, they're going to be on a cover this pieces, sharing and scanning of data at rest.
This piece here, the point of access where numerous different use cases or different examples of employees or not employees with employee credentials attempting to access data, the API can't touch this. It doesn't provide any visibility and it doesn't provide any control which is where a forward or reverse proxy based Cloud Access Security Broker (CASB) comes into play as well. This is part of the strength of our Bitglass hybrid architecture and why it's so important to support not only the API mode but also the proxy mode. The only way to get full visibility and control over corporate data within an app like Google Drive.
Thanks for joining today's Bitglass session. My name is Rich Campagna. We'll see you next time.