One of the CASB vendors in our space has a storyline that goes like this: “Sanction [insert cloud app name here] and block all others at the firewall.” That sounds blissfully simple, and may even give you a warm fuzzy feeling for about 30 seconds. But if you think about it for any length of time, it sounds – and is – ridiculous.
Of course there are exceptions. We’d block really risky file sharing apps, ones with ongoing unremediated vulnerabilities, and ones hosted in risky countries. We get it. Some apps just don’t belong in your enterprise.
But the “sanction one and block the rest” regimen as a cloud security strategy simply isn’t practical in the real world. Here are seven reasons why:
- People need to collaborate with partners, suppliers, and customers.
- People need to test and use innovative tools…and those tools are in the cloud.
- IT can’t – and won’t ever want to – administer every cloud app.
- You will create “exception sprawl.”
- People will use worse tools than what you’ve blocked.
- People will use personal and corporate instances of the same apps.
- Cloud apps aren’t even in your network.
Let’s go through each one:
People need to collaborate with partners, suppliers, and customers.
Let’s say you sanction Box and block all other cloud storage or file-sharing services. You have a salesperson. That salesperson has a customer that uses Dropbox. The customer sends your salesperson a packet of documents from Dropbox. Your salesperson can either ask her customer to re-send the documents via Box, leave the office and use another (possibly less secure) network to access Dropbox, or forego the business altogether. All of those are bad choices. Now multiply this by all of your salesperson-customer, business development professional-partner, manager-supplier relationships and you can easily see the magnitude of the problem this creates. The way some of our customers handle this is by enforcing a policy that says “Allow download from any (or most) cloud storage app and block upload to any app except [sanctioned app].” Some variations include blocking upload of confidential documents only or requiring a business justification before a user uploads anything to an unsanctioned app.
People need to test and use innovative tools…and those tools are in the cloud.
After performing hundreds of Cloud Risk Assessments for our customers, our observation is that there are numerous cloud services in use by virtually every business unit in nearly every enterprise. By all measures, these apps are beneficial. Take HR. There are apps for talent acquisition, employee onboarding, talent management, payroll, benefits, 360-degree reviews, testing and compliance, and more. These tasks are business-critical for any modern HR department to function properly. And this is the case not just for HR, but across Finance, R&D, Sales, Marketing, Operations, and more. Virtually any new, innovative technology in the market today is being delivered in the cloud, which means that any group that is evaluating and adopting a new tool by definition has to use several cloud apps. If IT sanctions one app and blocks the rest, whole lines of business won’t get to test and try new products. Or IT will have an unacceptably long list of apps to review and approve before business units can test or use them. Or IT will have to make tons of exceptions, but won’t be able to govern usage of the apps for which they make exceptions. All of these options are completely impractical.
IT can’t – and won’t ever want to – administer every cloud app.
Continuing the prior point, the new model is that each business unit chooses best of breed cloud services (versus suites) because those apps solve real problems and are easy enough to integrate with each other. This means that the organization will have many more apps in use for legitimate business purposes than before. IT cannot – and most wouldn’t want to – administer each and every one of those apps. We have seen many of our customers adopt the following model: IT maintains control of broadly-adopted apps and suites like Office 365 and allows the business unit to administer functional apps. That said, IT maintains visibility of those apps and enforces broad policies to ensure the overall data protection and compliance goals of the organizations. Examples of these policies may be: “Block people outside of HR from downloading anything from any HR app,” “Alert me if anyone modifies data by either ‘editing’ or ‘deleting’ any data in any Finance app,” or “Require and log a business justification for anyone wishing to download data from any of our CRM apps.”
You will create “exception sprawl.”
Another thing we measure in the Cloud Risk Assessments we perform for our customers is the amount of usage in apps that have been blocked by perimeter tools. The number is shockingly high – upwards of three-quarters of all sessions are in cloud apps that have been blocked in some way, shape, or form at the firewall or proxy. The reason for this phenomenon is one of two things: The firewall rule isn’t implemented correctly or (way more often) exceptions have been made for the cloud app. Here’s how this happens: Take Twitter. First, marketing requests access because they are responsible for promoting the company and social media is a big part of their amplification strategy. Then the CEO and her executive team want access because they want to build their personal brands. Then other thought leaders in the company request access because they also want to build their personal brands. Then customer support requests access because, these days, unhappy customers take to social media before they’ll ever call your 800 number. And so it goes, until nearly all of your usage is in the exceptions.
People will use worse tools than what you’ve blocked
People will find a way to use the tools they need to get their jobs done. If they can’t get an exception easily, they will resort to using lower-quality tools than the ones you’re blocking. When we measure “exception sprawl” for our customers, we also look at blocked apps by quality (measured by our Cloud Confidence Index, an objective yardstick that we adapted from the Cloud Security Alliance’s Cloud Controls Matrix). We find that there is – literally – a near mathematical step-wise relationship in app quality and blocking. Apps rated “excellent” are blocked the most, “high” second most, and so on. “Poor” apps are blocked the least. This is because most perimeter tools have very coarse-grained app categories (like “web apps” or “computer services”), which makes it necessary for IT to block app-by-app rather than at a category level. The result is that IT ends up blocking the apps they know, like Box and Dropbox, which happen to be very high-quality, and allowing the apps they’ve never heard of, like FreakShare, which is rated poorly. This analysis shows that blocking apps has the exact opposite outcome than IT intended.
People will use personal and corporate instances of the same app.
If you think about the real risk we’re talking about, which is the intentional or inadvertent leakage of sensitive data, sanctioning one app and blocking the rest at a coarse level (such as at the perimeter) won’t work. Say you sanction Dropbox and block everything else at the perimeter. Someone who wants to steal sensitive data will simply create a personal instance of Dropbox and then, because Dropbox is allowed at the perimeter, will steal to their heart’s content. Customers who have thought about this issue end up creating a layered policy around their sanctioned instance of their cloud storage app and another one around all other instances. The one around their sanctioned instance may dictate encryption for all content meeting “sensitive data” criteria per their DLP profiles, and the one around all other instances may block the upload of that same content. That way, they ensure that sensitive data are in the right repository, and also protected.
Cloud apps aren’t even in your network.
If you go back a decade, most remote users in an enterprise were required to connect to their corporate VPN to do their job, whether to check their email, update a sales forecast, review marketing campaign statistics, or perform employee reviews. At that time, it made sense to use perimeter controls to enforce acceptable use policies. At that time, cloud services were also nascent and there were many fewer of them. Now, all of the functions mentioned above can be performed in the cloud, usually without a VPN. The cloud is omnipresent. IT may block Dropbox at the perimeter but an employee can get to it from a nearby coffee shop. This use case exposes the folly of blocking at the perimeter.
Coarse-grained blocking was a good enough strategy last decade because it was the only choice people had and most people didn’t expect to use cloud services for work. But the world has changed, users and lines of business have different expectations about how they’ll use technology, and IT leaders now have more – and better – choices for how they can safely enable cloud while also protecting data and ensuring compliance for their organizations.
