Our last post in Data Security in a SaaS World discussed how the use and sharing phases of the (frankly partially defunct) Data Security Lifecycle remain relevant. That approach hinges on a detailed understanding of each application to define appropriate policies for what is allowed and by whom. To be clear, these are not – and cannot be – generic policies. Each SaaS application is different and as such your policies must be different, so you (or a vendor or service provider) need to dig into it to understand what it does and who should do it.

Now the fun part. The typical enterprise has hundreds, if not thousands, of SaaS services. So what’s the best approach to secure those applications? Any answer requires gratuitous use of many platitudes, including both “How do you eat an elephant? One bite at a time.” and that other old favorite, “You can’t boil the ocean.”

Whichever pithy analogy you favor for providing data security for SaaS, you need to think small, by setting policies to protect one application or service at a time. We’re looking for baby steps, not big bangs. The big bang killed initiatives like DLP. (You remember DLP, right?) Not that folks don’t do DLP successfully today – they do – but if you try to classify all the data and build rules for every possible data loss… you’ll get overwhelmed, and then it’s hard to complete the project.

We’ve been preaching this small and measured approach for massive, challenging projects like SIEM for years. You don’t set up all the SIEM rules and use cases at once – at least not if you want the project to succeed. The noise will bury you, and you’ll stop using the tool. People with successful SIEM implementations under their belts started small with a few use cases, then added more once they figured out how to make a few sets set work.

The Pareto principle applies here, bigtime. You can eliminate the bulk of your risk by protecting 20% of your SaaS apps. But if you use 1,000 SaaS apps, you still need to analyze and set policies for 200 apps – a legitimately daunting task. We’re talking about a journey here, one that takes a while. So prioritization of your SaaS applications is essential for project success.

We’ll also discuss opportunities to accelerate the process later on — you can jump the proverbial line with smart technology use.

The Process

The first SaaS app you run through the process should be an essential app with pretty sensitive data. We can bet it will be either your office suite (Office365 or G Suite), your CRM tool (likely Salesforce), your file storage service (typically Dropbox or Box), or your ERP or HR package (SAP, Workday, or Oracle).

These applications represent your most sensitive data, so you’ll then want to maximize risk mitigation. Start with the app with the most extensive user base. We’ll illustrate the process with CRM. We get going by answering a few standard questions:

1. What’s the data? Your CRM has all your marketing and sales data, including a lot of sensitive customer/prospect data. It may also have your customer support case data, which is pretty sensitive.
2. Who needs to see the data? Define who needs to see the data, and use the groups or roles within your identity store – no reason to reinvent the wheel. We discussed the role of federation in our previous post, and this is why. Don’t forget to consider external constituencies – auditors, contractors, or even customers.
3. What do they need to do with the data? For each role or group, figure out whether they need to read, write, or otherwise manage data. You can get more specific and define different rights for different data types as required. For example, finance people may have read access to the sales pipeline, while sales operations folks have full access.

Do you see what we did there? We just built a simple entitlement matrix. That wasn’t so scary, was it?

Once you have the entitlement matrix documented, you write the policies. At that point, you load your policies into the application. Then wash, rinse, and repeat for the other SaaS apps you need to protect.

Each SaaS app will have a different process to implement these policies, so there isn’t a whole lot of leverage to be gained in this effort. But you probably aren’t starting from scratch either. A lot of this work happens when deploying the applications initially. Hopefully, it’s a matter of revisiting original entitlements for effectiveness and consistency. But not always. To accelerate a PoC, the vendor uses default entitlements, and the operations team doesn’t always revisit them when the application goes from testing into production deployment.

Continuous Monitoring

Once the entitlements are defined (or revisited), and you’ve implemented acceptable policies in the application, you reach the operational stage. Many organizations fail here. They get excited to lock things down during initial deployment but seem to forget that moves, adds, and changes happen every day. New capabilities get rolled out weekly. So when they periodically check policies every quarter or year, they are surprised by how much changed and the resulting security issues.

So continuous monitoring becomes critical to maintain the integrity of data in SaaS apps. You need to watch for changes, with a mechanism to ensure they are authorized and legitimate. It sounds like a change control process, right? What happens if the security team (or even the IT team in some cases) doesn’t operate these apps?

We’ve seen this movie before. It’s like dealing with an application built in the cloud by a business unit. The BU may have operational responsibilities, but the security team should assume responsibility for enforcing governance policies. Security needs access to the SaaS app to monitor changes and ensure adherence to policy.

And that’s the point. Security doesn’t need to have operational responsibilities for SaaS applications. But they need to assess the risk of access when building the entitlement matrix and to monitor the application to ensure changes don’t violate policies or add attack surface.

Buy vs. Build

A described above, thinking small and building access rules and monitoring each SaaS app will be resource-intensive. So is there a scalable way to secure SaaS apps? SaaS providers may provide deployment tools to define access rules quickly and efficiently. It’s in their interest to get your organization up and running as quickly as possible.

You could also send alerts about entitlement changes to your SIEM or security analytics tool to monitor for potentially malicious activity. Once you’ve identified a problem, it can be sent to your work management system (ServiceNow, Jira, etc.) to apply the requested changes. Or you can DIY (Do It Yourself).

Alternatively, you can accelerate your security process by looking at SaaS management tools that have already done the work to understand each SaaS app. These tools provide a quick assessment of current entitlements, and then both manage and monitor access rules going forward. They also provision and deprovision users from the SaaS application, and stay on top of frequent changes within the app.

For example, when Salesforce rolls out a new service (or more likely acquires it and bundles it into your package), how should that impact your entitlements? DIY requires that you evaluate the new service yourself, while a vendor should have those changes enumerated in their tool sooner than you can.

Are these tools a panacea? Of course not – no tool offers everything you need for every application you need to protect. It comes down to resource allocation and risk management. If you have the resources to do it yourself, have at it. And if you aren’t worried about losing data from a particular SaaS app, don’t worry about it. It’s not like you don’t have other worries.

But if your security team remains resource-constrained and a SaaS app stores sensitive data, a SaaS management tool warrants investigation. Here are a few things to consider:

• Application support: Does the tool support your top 10-15 applications? Over time the library of supported applications should grow, but you need to protect your highest-profile applications initially. Understand how well the vendor SDK can support fo new and unsupported apps, and how well the vendor will support the SDK.
• Granularity of policy: Does the tool offer the ability to set sufficiently detailed policies for the application? Can you restrict access to certain parts of the application? Are geographic limitations and device restrictions supported? Many policy knobs are available – make sure you can adequately protect your applications.
• Supported Use Cases: Does the tool offer the capabilities you need? Consider the critical use cases of access control, data security, and provisioning/deprovisioning; and understand how the application’s API capabilities will constrain your use cases.
• Integration with existing Ops tools: Make sure the tool will integrate with your SIEM/monitoring platform, work management tool (to track service tickets), and an automation tool.

The build versus buy decision is challenging in an early market. The tool you like may only support a handful of the SaaS applications you use, so its immediate value may be limited. But don’t just consider today’s capabilities – also think about the 18-24 month roadmap for new application support, and how confident you are in the vendor hitting those milestones. Or you can always build it yourself.

We’ll wrap up this series in our next post by detailing a quick win, where we apply these concepts to a simplified but realistic scenario to show how the approach could work out for you.