There are over 19,000 cloud services available today. While you’ve likely heard of popular file sharing services Dropbox and Google Drive, you may be less familiar with 4shared, ZippyShare, and Sendspace, which are far riskier services in that category. Until recently, many organizations have resorted to simply blocking well-known cloud services with their web proxy or firewall. However, it’s not scalable to extend this to thousands of services, and this approach often ends up blocking relatively secure cloud services while forcing users to adopt far riskier cloud services that may claim ownership of data uploaded to them.
A more systematic approach is needed to create risk-based cloud usage policies. These policies increasingly are not simply allow/block, but include more nuanced enforcement such as allowing users to download data shared by third parties within a cloud service without being able to upload data to that same service. A Cloud Security Alliance survey found that 34.8% of enterprises with more than 5,000 employees have a cloud governance committee today charged with creating and enforcing these cloud policies. In this whiteboard walkthrough, McAfee (formerly Skyhigh Networks) Product Manager Neeraj Mathur explains how to create a cloud governance framework, and what company departments are typically involved in this process.
Hi, my name is Neeraj Mathur, and I’m part of the product management team here at McAfee running the Shadow IT product line. Today, we are going to talk about cloud service governance, one of must-have CASB capabilities. As more and more enterprises go down the path of adopting cloud services, it is becoming increasingly challenging for IT to be able to, 1) have visibility into all these different cloud services that are coming in, 2) be able to provide a governance model to ensure that they’re able to protect intellectual property of the enterprise, and 3) have policies in place to ensure only folks that need to have access or appropriate access are able to do that.
If you think about it from a discovery standpoint, what we find is that even in the shadow IT space, there are two different types of services that are being brought in by enterprise users, who, by the way, are bringing these services at a relentless pace and many at any given point of time. If you look at it from a shadow IT standpoint, there are a personal cloud services, such as Facebook, Pinterest, or Youtube that users are using for their personal usage, but there’s also cloud services such as Expensify and Github that line of businesses are actually purchasing to be able to enable their users to get their job done. And on the side of sanctioned IT, you have Salesforce, Box, or Workday.
So at a macro level, what’s really going on is that IT is not able to have control that they had in the pre-cloud era where they were part of the procurement process, where they were also part of the application security, application rollout, and basically onboarding of a service inside the enterprise. With the unfettered access that users have to the cloud services these days, IT loses all that control. How many cloud service requests do you get today to be able to onboard within your enterprise? In a recent survey, we found out that, on average, an IT person is getting about 10 requests a week to onboard a cloud service their line of business is requesting within a given enterprise. There needs to be some sort of a model in place to ensure that you can bring these cloud services within the enterprise, instead of saying no to your users for everything that they come to you, be able to say, “Well, here’s a governance process that we have in place for a cloud service to come in and for our users to actually be able to get their job done.”
So at a macro level, what you really end up looking at is that there are services such as Salesforce, Box.com where you’ve bought the service, you’ve procured the service, you have as large control as possible, where you can actually see what data is going in, who has access to it, what kind of access they have to it. Those kinds of services, from a classification standpoint, could be called “approved services”. Then comes the notion of, okay, these are some services that are approved, but what about some of those other services that may be required for the business process but not something that we’ll go and buy ourselves.
Well, one example that comes to mind is, in the case of a financial institution such as a bank who’s engaged with mortgage applications, they’re constantly dealing with users who actually take these really long mortgage applications and upload into a file sharing system. Now, we all know that bank employees most likely are required not to be able to upload anything, but they need to have the capability to download the mortgage application and make sure that they can process the work for the user who’s applying for this mortgage, right? So in that scenario, your focus is actually on preventing data exfiltration, but enabling the job that a mortgage person is going to do and the end user to be able to carry it out. Those types of applications become “permitted applications” where you are preventing data exfiltration but enabling the business process workflow to actually move forward.
Then comes the notion of denying. Well, why would you want to deny anything? Well, this is not about denying a CSP. The idea really behind this is preventing users from making mistakes. For example, if a user wants to just quickly get a doc into a PDF, he or she uploads this to a PDF converter online that they find because they’re trying to get something done fast. What happens in that case is the user doesn’t realize that as soon as they upload that intellectual property up into a cloud service, that information, that data is now owned by that cloud service, and that becomes a challenge. Those kinds of services should actually be denied or classified as a “denied service”.
Denied services also bring a very interesting opportunity to coach the user and say, “Well, this particular offering may be denied, but there are other similar services that we already have either in the approved or permitted category that are available for you to be able to get your job done.” When you do this classification between approved, permit, and denied, you also discover a category of services that are yet to be classified into any of these sort of governance categories, and the job of a governance committee should be to make sure there are very few, if any, unclassified services within an enterprise.
I mentioned the term governance committee; 35% of enterprises have a cloud governance committee. Within those committees, they have constituents from IT security and IT compliance, risk management, or line of business. If you notice, IT security is present in 84% of committees, whereas line of business is only present in 43. Whereas line of business is really the one who’s actually going and getting Expensify and Github to get their users to be able to get their job done. Perhaps line of business would want to be more involved in setting up these governance policies, making sure that the usage policies that are created are more in line with their users to be able to get their job done.
About the Author
Categories: Cloud Security