Wrangling Backoffice Security in the Cloud Age: Part 2
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
