This is the second part in a two-part series (later paper) on managing increased use and reliance on SaaS for traditional back-office applications. See Part 1. This will also be included in a webcast with Box on March 6, and you can register here.

Where to Start

Moving back office applications to the cloud is a classic frog-in-a-frying-pan scenario. Sure, a few organizations plan everything out ahead of time, but for most of the companies and agencies we work with, things tend to be far less controlled. Multiple business units run into the cloud on their own – especially since all you need for SaaS is a web browser and a credit card – and next thing you know, your cloud footprint is much bigger than you expected.

This is a challenge for security teams, who are often tasked with fixing one cloud at a time as requests come in, without time or support to take a step back and build out a program to support the transition. We don’t recommend putting the brakes on and pissing everyone off, but we do recommend a first step of building a program, instead of just blocking and tackling. Here’s how to pull that off when things are already in motion.

Build an “Embrace and Extend” Program

The first step isn’t so much a “do this”, as it is “adopt this way of thinking”. It’s also probably our most important piece of advice for you.

There are two ways to approach the problem of enforcing your security needs on an external platform. Either wedge in a standard stack of security controls across the board, or evaluate the cloud provider, embrace their security capabilities, extend them where you can, and wedge in controls where you can’t.

The first option looks best on the surface because you gain the appearance of consistency, but the practical reality is that the only way to pull it off is to break some cloud functionality, and the advantages are mostly illusory anyway due to major underlying technical differences.

We recommend a dual-path approach. Where possible build security controls and management you can extend to the cloud, while embracing your cloud platform’s security capabilities, but also have a wedge stack (usually a CASB in man-in-the-middle/proxy mode) available for providers which don’t offer effective security capabilities.

SaaS is the Wild West of the cloud – it offers a mixture of amazing best-of-breed security, alongside providers whose negligence will set your hair on fire.

Start by Updating Your Risk Assessment Process

The next step is to use some rigor to choose which cloud providers you can support. Your objective is to select a supported SaaS platform for each major back office application category, minimizing the likelihood of employees trying to use unsanctioned and insecure providers. There is no need to rip apart your existing risk assessment process for new tools and technologies, but you do need to tune it with a few specifics to handle SaaS:

• Build a registry of sanctioned applications in major categories, such as file storage and collaboration, CRM, ERP, HR, communications, etc.
• Assessing applications can be tough, but usually involves:
• See if it supports our recommended Critical Security Capabilities for Cloud Providers. This list is a good starting point for components you need to integrate a cloud provider into your security program.
• Know your compliance requirements and check each provider’s compliance certifications. You might only approve some providers for specific types of data.
• Obtain the cloud provider’s security and compliance documentation. Many now post this information in the Cloud Security Alliance’s STAR Registry and use the standardized CSA Common Assessment Initiative Questionnaire (CAIQ), so you can compare apples to apples.
• Review the provider’s security documentation and validate features and capabilities.
• If you use a CASB (Cloud Access and Security Broker), it may include internal risk ratings you can use to help with selection.
• Once you pick a provider, document which kinds of data it is approved for in your registry. Ideally you want only one major provider per application category, and new requests can be steered to your preferences. But be open to diverging business unit needs which might require a second provider in a category.
• Include fast and slow assessment paths, with the fast path for providers which won’t access any sensitive data (e.g., marketing without PII). You don’t want to slow the business down if you can avoid it, or you just might learn the limits of your control and popularity.

Build a Federated Identity Management Program

Few things push you toward full federated identity and single sign-on than the cloud. It’s pretty much the only way to operate.

Although you can handle things with direct federation to your directory servers, we have seen that a commercial tool can be a big help here. We recommend building around a federated identity broker, and including three key pieces in your plan:

• For every cloud provider, have a non-federated administrative account. That way when your federated identity broker has an issue you can still get into the cloud.
• Don’t hide your entire back office behind a single appliance. Use a high-availability service (and push hard for real uptime numbers) or multiple on-premise appliances. You do not want to be the one answering the help desk when the entire organization loses access to every back-office, application because your broker borked an update.
• Require MFA at least for all administrative users, and ideally all users. When possible further enforce MFA by requiring it as an attribute for authentication to the cloud platform (the cloud can require an MFA attribute from the identity broker – this isn’t separate MFA).

Create a SaaS Security Program

Notice that we only get into the security meat in our third step. That’s because your security program will be crippled without starting from a good process for selecting providers and solid identity management to handle users.

Technologies and options change constantly, and vary widely between SaaS providers and security toolsets, but we can build a program around some consistencies.

• Use a CASB or something similar for your security management console for consistency, but not so much that you fail to leverage your SaaS platform’s inherent controls. CASB can be great for providing multi-platform visibility and implementing some controls, but this abstraction layer can make you miss powerful capabilities inside your cloud platform. For your most critical cloud providers don’t rely just on your CASB – also make sure you understand their full native security capabilities. Fortunately you can probably focus on a handful of key providers, and rely on your CASB for most of them.
• Always try to avoid needing to proxy (man in the middle) connections to your cloud provider just to integrate your CASB. If you follow our Critical Security Capabilities guidelines, you will tend toward providers your CASB can integrate with using APIs, so it doesn’t weaken your encryption and trust model.
• Adjust your security requirements based on the type of data. We know this seems blindingly obvious, but we mention it because we see many programs which assume everything in the cloud should be treated the same.
• Have a documented incident response process for at least your major SaaS providers – and test it. The main scenarios are unapproved public data, account takeover, loss of your federation connection, and employee abuse. Most important, know who to call in case of an incident, and make sure you know the provider’s process to authenticate that you are a valid customer contact for incident response.
• Build a security log management strategy for SaaS. You will need to account for a variety of sources, connection methods, and file formats.
• Once you establish visibility and monitoring, determine what constitutes a security incident, and how you can detect them. This could be from your log feeds, external monitoring, the CASB, or some internal event trigger from a cloud provider.
• Go back and make sure you keep up to date on your providers and their security capabilities. Embrace new security features. You might not use them all but you certainly need to know they exist, and whether they can provide value to you.

Additional Tips for Success

Our recommendations are only a starting point, and cannot cover the vast majority of the technical details once you get into the weeds. This research focuses more on high-level program components than details, but here are some additional tidbits which may help as you move forward:

• Learn to love automation – especially when you have API support from a provider. Just as with IaaS, consider writing custom automation tools to validate controls, implement common processes, and speed response.
• Audit the controls you establish in your SaaS platform as well as in any management tool (CASB). Don’t wait until an auditor calls to find out someone disabled a key control (like making sensitive data public), but it didn’t trigger an alarm.
• Encryption is one of the most complex messiest aspects of SaaS, with wildly divergent security models and implementation specifics. Our general recommendation is to stick to providers with robust encryption support, and avoid proxy models.
• Keep track of your providers, at least the most important ones. They are constantly adding new capabilities, some of which may bring significant security benefits. Someone in security should be on the mailing list, and it’s worth having at least an annual capabilities review.

Enterprise adoption of Software as a Service is nothing new, but there is a big difference between ad hoc adoption of a few services and moving essentially every back-office application into the cloud. Building out your security program to support this rapid evolution can reduce risk and increase agility, without killing the security team, who is already busy learning new skills and techniques.