The Case for Altitude Networks: Cloud-Native DLP for SaaS Collaboration
Many organizations are making the shift to cloud-based collaboration and productivity tools because they make it easier--and cheaper--to deploy, manage, and use the tools people need. With services such as Google GSuite, Microsoft Office 365, DropBox, or Box, organizations can start small and scale quickly with predictable costs. Mobile device support is a given, and with a central storage facility for documents and other data, sharing is easier and more consistent. These benefits enable a dramatic reduction in organizational friction, driving higher participation, and facilitating better business outcomes.
As significant as these benefits are, however, the ease with which people can share data using these cloud services brings new challenges to security and risk management teams. With SaaS tools, it’s easier for users to make an innocent mistake, sharing data with the wrong people, sharing the wrong data, or providing broader access than necessary, thus creating risk for the organization. At the other end of the spectrum, malicious insiders find it easier to locate and share data with outsiders. Making matters worse, most organizations lack the tooling to find and manage these risks.
In one sense, data leakage of this kind isn’t a new problem. But SaaS collaboration products significantly increase the speed with which risks can accrue and the difficulty of identifying, prioritizing, and responding to those risks. The challenge is managing the risks that SaaS collaboration platforms create without reducing the inherent value these platforms bring to the organization.
While serving as Twitter’s CISO, Michael Coates saw this challenge and realized that he lacked the tools to address it. Traditional data loss prevention (DLP) products are heavy-handed enforcement mechanisms that don’t work well with lighter-weight SaaS products. And while cloud access security brokers (CASBs) can track down shadow IT, they typically don’t help security teams identify and remediate cloud data sharing risks with enough granularity. Coates saw an unmet need for a cloud-native solution for a cloud-native problem, one that could manage risk in real-time without compromising the user experience SaaS platforms provide.
So Coates teamed up with Amir Kavousian, a data scientist who had been working on machine learning for fraud detection on Capital One’s payment platform, and launched Altitude Networks. The result is Altitude’s “cloud-native DLP.”
Altitude Networks is a SaaS security solution, integrating with SaaS collaboration services at the API level. Customers don’t have to deploy client agents or slog through difficult back-end integration work. It applies a spectrum of tools and automation to the problem, ranging from common sense rules to more complex behavioral and relationship analysis, working in the background while giving security teams the tools to manage risks in SaaS platforms. This cloud-native approach was the leading factor in Rain’s investment in Altitude Networks.
The Problem
The data sharing risks on SaaS collaboration platforms aren’t indications that Google, Microsoft, Dropbox, and Box have failed when it comes to security. Generally speaking, their products include robust authentication and access control capabilities. But as Coates points out, many of the problems crop up when users, who happen to be human beings, fail to meet unrealistic expectations. In fact, SaaS collaboration products lack any guardrails that remind users they are sharing sensitive or notifying them (and security personnel) when sharing data creates undue risk. Those risks fall into these general categories:
Accidents: Accidental sharing constitutes a large percentage of the security and risk events teams see on cloud collaboration platforms. Sending a link to a draft of the quarterly financials to the CFO of a public company is easy. But a typo in the email address facilitates the sharing of sensitive data with the wrong people, and a public company faces regulatory risk. That’s just one of many well-known examples. Assuming that human beings will execute every task perfectly every day of every year is simply unrealistic. Organizations need automated mechanisms that kick in during accidental sharing incidents, helping both users and security teams address them quickly.
Poor (or uninformed) Risk Decisions: To an employee under a deadline, it may seem perfectly reasonable to share sensitive data with herself, using her personal email address. Sharing to a personal email address may not be acceptable under company policy, but it’s difficult to detect. And even if it is acceptable, she still has access to shared data via her personal email address when she leaves the company. Knowing that such things happened, who did it, and what data was shared--and shutting access off when she quits--are clear requirements, and automation is the only way to address them at scale.
Malicious Insiders: While they are a smaller percentage of the risk problems organizations face, malicious insiders are a reality. Former employees may download the entire contents of their Google Drives before leaving. A disgruntled engineer may steal intellectual property, or a mole could be harvesting sensitive data for a competitor. SaaS tools that make it easy to share data appropriately also make it easier to share data inappropriately. Organizations need a way to identify abnormal behavior quickly, understand the severity of the risk, and take action if necessary. Again, automation is the only way to address these problems at scale.
Problems like these crop up quickly on cloud collaboration platforms. Finding and dealing with them is much more difficult. Manually digging through logs isn’t scalable, and doesn’t come close to matching the speed at which risks accrue. And given the number of users and potential incidents, reliable automated mechanisms are baseline requirements.
On-Prem vs. Cloud-Native
Traditionally, enterprises have deployed on-premise DLP products to address the risks associated with sharing and using sensitive data, often driven by compliance requirements. More recently, CASBs emerged in an attempt to extend an enterprise’s security policies and management capabilities into the cloud. But neither DLP nor CASB products are well-aligned with cloud-native architectures, creating significant mismatches in deployment, management, and usage models. These include:
Adding another layer of security technology to already complex environments: Typical DLP solutions are the antithesis of lightweight, cloud-based collaboration services. They are enforcement mechanisms and, like CASBs, create duplicative security controls that can make managing risk more complicated, and thus more prone to failure.
Requiring long deployment cycles: DLP systems cross departmental boundaries and technology silos, making them hard to deploy and manage. More traditional DLP systems require organizations to integrate multiple appliances and servers with the network, email systems, web proxies, and identity and access management systems. Agent-based approaches eliminated backend-end integration, but require organizations to install agents on every endpoint, which often creates conflicts with operating systems and applications. Given the long deployment cycles these products require, it’s usually months before organizations start to realize any value from them.
Frustrating users: Heavy-handed enforcement mechanisms can be intrusive, negating many of the benefits SaaS collaboration brings to end-users. And long deployment cycles can’t keep up with the pace at which users adopt cloud products that help them meet their objectives. If they prevent people from doing their work, security tools also create a perverse incentive to subvert controls. Users will find a way around them to do their jobs.
Lacking tools to address the problem: While a CASB can help organizations identify any cloud services in use by shadow IT, most don’t identify and prioritize risks with enough granularity. A CASB may reveal that an organization has 10,000 files shared publicly, for example, but it can’t tell a security manager which of those 10,000 files creates real risk for the company. Nor does it give the security team a mechanism for remediating threats, other than manually dealing with them.
Figure 1
These mismatches and shortcomings are simply yet more evidence of the mismatch between traditional, on-premise security models and cloud-native systems. As we’ve said before, securing cloud-native systems requires aligning security systems with cloud-native architecture.Altitude ArchitectureAltitude is a cloud-native security service, sold as a SaaS product, operating within the collaboration platform’s environment, according to its rules. Altitude does not create yet another management layer, such as a duplicative access control structure.
As Figure 1 illustrates, Altitude integrates with the SaaS platform’s APIs, gathering the metadata on every file and person in the platform. Altitude discovers the name of every file, who created it, when they created it, its security settings, who has access to it (including third parties), and every action taken on that file (such as renaming, viewing, and editing). (Altitude limits its intake to the metadata, having no need to access the actual data in any file.) Altitude’s Risk Engine operates on that meta-data, performing the following functions:
Meta-Data Analysis: Altitude comes with a baseline set of assumptions and rules based on common sense. If a file name includes terms such as “confidential” or “internal,” Altitude assumes that file should not be shared externally and flags any cases that violate the rule. Likewise, Altitude assumes that file names that include terms such as “salary” or “board deck” shouldn’t be shared either internally or externally. These are just a few examples. Companies can modify or add rules and terms as they go, such as project code names and other sensitive data file naming conventions.
Relationship Analysis: Using the meta-data and learning from usage patterns, Altitude builds relationship graphs that reveal how, and with whom, users share data, assigning confidence scores to relationships that weren’t obvious or even visible before. It will discover and map the relationship between employee company email addresses and personal email addresses, allowing security teams to understand how employees are sharing data using those mechanisms. Altitude also maps relationships with third parties, including business partners, teams that span organizational boundaries, and so on.
Behavioral Analysis: Altitude uses machine learning techniques to model behavior and find anomalies that may constitute risk. If employees suddenly start downloading a large number of files or sharing data with third parties they’ve never worked with before, the system flags the behavior in real-time, allowing security managers to address the problem.
Figure 2
As Figure 2 illustrates, Altitude puts this information in a dashboard, allowing them to view risks to the organization in an organized fashion, by severity. Managers can see a history for specific files or specific users, allowing them to audit previous activity as part of the remediation process. They can also take action in real-time, including notifying the end-user of the problem, complete with instructions on how to fix it. In severe cases, a security manager can remove access to a file for a third party, or lock the file from sharing completely.
Today, Altitude supports Google’s GSuite offering. The company plans to release support for additional SaaS collaboration platforms in the future.
Conclusion
SaaS collaboration platforms have become popular because they work. They help people get their work done, and their deployment and usage patterns match the speed of the business. Instead of getting in the way of that progress, security systems must keep pace, giving security teams the tools they need to quickly discover, understand, and remediate risks in these SaaS platforms, without degrading their functionality. That’s the goal of Altitude Networks and its product. And that’s why we at Rain Capital invested in the company.