People wrestle with the following question. If the public cloud is so safe, why do I need a 3rd party security solution? It’s a fair question and it deserves a thoughtful answer.
The public cloud extends your threat surface in ways that are different from what you may expect. Counter-intuitively, this is not because the public cloud is unsecure: public cloud providers like Google and Salesforce are second to none when it comes to IT security controls.
The issue is users. Cloud providers can’t control what your users do with your data. This isn’t anything new. A constellation of companies like Symantec, Varonis, and Checkpoint emerged to take care of enterprise needs for augmenting the security of their IT infrastructure on premises and protecting themselves from insider threats.
The problem is that these companies stop at your perimeter and desktops. They don’t make the journey with you when you adopt a public cloud service. This means you are confronted with a new threat surface that you have to define, explain, and address in order to assure continuity of your security framework.
The new threat surface comprises:
(1) cloud users and their data, whether migrated, ingested, or created there
(2) the things users do with the data in the cloud, often things they don’t or can’t do on premises
(3) and the exposure created because on-premises enablement of strategies like compartmentalization, disk encryption, and DLP doesn’t extend to the cloud.
In a paradox, a great deal of time and effort goes into addressing non-threats: that is, verifying the controls of the cloud provider. On the one hand, it’s hard to argue against due diligence. On the other, it’s a little bit like asking your finance department to make sure General Electric is solvent before you sell them a server. Salesforce and Google can be counted on and their infrastructures are rightly regarded as an extension and improvement of your enterprise trust.
Dealing with the cloud threat surface requires that you abstract yourself from infrastructure security issues. This is because cloud threats are behavioral and stem from the desired functionality of the cloud; reducing them means you have to address either behavior or the result of behavior. Planners have to view the user as an actor who can transform a threat into a risk or exploit, even if he does exactly what he should be doing. This is not a question of passive vulnerabilities, in the classical sense of the word.
Threats are one thing. Risks are another. Users turn threats into risks in a lot of ways. OAuth is an illustration of how a feature that is immaterial in risk terms on premises can become a risk in the cloud.
People use OAuth on premises and in the cloud. On premises, IT uses compartmentalization and firewalls/ACL’s to control OAuth’s erosion of the perimeter.
In the cloud, these options aren’t available, so 3rd party apps give every user the cloud equivalent of admin rights for their SaaS account.
The risk consequence, sometimes overlooked, is that these apps can access the data of and created by the user. The user has created a vulnerability: if the app is hacked, the hacker can access the contents of the account and may have enough information to impersonate the user. The transition from threat to risk to vulnerability or exploit unfolds, quickly, in one step, with no possibility of intervention.
Yet the use of 3rd party apps is also a good thing, and the fact that IT doesn’t get involved in testing or provisioning it represents a productivity gain. So how do you protect against the risk without losing productivity?
Controlling the apps is one good way, but it is only one part of the threat reduction picture. It is also important to map the entire threat path and apply controls at a point as far upstream as possible. This reduces risk without forcing you to disable the desired cloud functionality, such as the beneficial 3rd party apps enabled by OAuth and authorized by users.
The threat path consists of multiple legs and dependencies. Thankfully, there are a lot of things you can do at each leg of the threat path to introduce controls and discontinuities that restrict the flow of risk and make whatever does arrive at the risk aperture visible and controllable. Think of a control as a way of detecting and reversing a risk and a discontinuity as an additional step a user has to take in order to bridge a gap in the risk path and reactivate a threat.
Reducing the Threat Surface Means Managing the Threats Upstream of the Surface.
In cloud environments, users tend to share files internally with abandon, a pathology known as sprawl. It is not uncommon for us to find 25% or more of an enterprise’s content accessible to every employee in the company, regardless of role or privileges: that is, every employee has access to 25 out of every 100 documents created.
This means that a malicious 3rd party app only has to find one user in order to read the 25 files. Using a solution like CloudLock, the number of files accessed by all employees can be pushed down to an acceptable level. This deprives the 3rd party app of access to the delta between the 25 and the new level, let’s say 10, a major risk reduction delivered by reducing the threat surface.
In a different example, CloudLock can identify sensitive data, such as files with credit card numbers or documents with confidential business info or IP, and remove access to them. This means the app now can’t access any sensitive data. Even if 24 files are left, if the one with sensitive data has been removed, the risk of exposure is gone. More risk reduction, even smaller threat surface.
This leg also dampens the risk of another leg, one that is further downstream. It reduces the amount of data a user has available for stockpiling: that is, storing company data in a personal cloud account or app. Or for exposure to a competitor, in the nightmare data-theft scenario that CIO’s dread. CloudLock encryption further enriches controls upstream, If the files are encrypted, the likelihood of a compromise by a 3rd party app, which will not have the decryption rights, is vanishingly small.
The effect of upstream controls is that the pressure is taken off the downstream controls. You still need to manage 3rd party apps, but can do so without carpet bombing them, since you will have addressed much of the risk upstream through content-aware control of access and encryption. At the same time, you can define policies governing who users can give files access to externally, knowing you have a last-resort means of classifying and controlling external access if a risk slips past the downstream controls and discontinuities.
The cloud security paradigm we have seen succeed is a descendant of the canonical defense in depth model, applied to the cloud. Define a risk path, break it into legs, and apply content-aware policy controls in the least intrusive, most effective way possible to each leg, ideally as far upstream of an exploit as possible. Force the threat to stop and start so many times that it runs out of risk momentum. Couple this with notifications that inform users and empower them to manage their own behavior and the threat surface shrinks, risks drop, users are happier and more productive, and CIO’s can sleep a little better.
CloudLock has been helping organizations across the globe reduce their threat surface while embracing the collaboration and productivity benefits of cloud platforms. Contact us for a free security assessment to find out how secure your environment really is. We will review and audit your organization’s Google Apps and Salesforce domains, as well as of the usage and consumption of third party applications connected to your SaaS applications to:
- Provide metrics, considerations, and recommendations that lead to the analysis
- Recommend actionable next steps for instituting Acceptable Use Policies (AUPs)
- Compare your Security Score to other customers