Wrangling Backoffice Security in the Cloud Age: Part 2

Posted under: Research and Analysis

This is the second part in a two part series/paper on managing your increased use and reliance on SaaS for traditionally back office applications. [Part 1 is here]. This will also be including in a webcast with Box on March 6 and you can [register here]

Where to start

Moving your back office applications to the cloud is the classic frog in a frying pan scenario. Sure, there are a few orgs out there that plan everything out ahead of time, but for most of the companies and agencies we work with it tends 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 the next thing you know your cloud footprint is WAY bigger than expected.

This is a challenge for security teams who are often tasked with fixing one cloud at a time as the requests come in, without having the 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 the first step is to build 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 “do this” as “adopt this way of thinking”. It’s also probably the most important piece of advice we have for you.

There are two ways to approach the problem of enforcing your security needs onto an external platform. 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 seems best on the surface since you gain the appearance of consistency, but the practical reality is the only way to pull that off is to break some of the cloud’s functionality, and it’s more an illusion anyway due to the large underlying technical difference between platforms.

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

SaaS is the Wild West of the cloud with a mixture of some amazing, best of breed security combined with providers that will set your hair on fire with their negligence.

Start with updating your rise assessment process

The next step is to put some rigor into which cloud providers you support. The objective is to have a supported SaaS platform for each major back office application category, which minimizes the odds 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 the components you need to integrate the cloud provider into your security program.
• Know your compliance requirements and check the provider’s compliance certifications. You may end up only approving some providers for some kinds 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.
• Pull and review the provider’s security documentation and validate features and capabilities.
• If you use a CASB (Cloud Access and Security Broker) many of them include internal risk ratings you can use to help your selection process.
• Once you pick the provider then document which kinds of data it is approved for in the registry. Ideally you only want one major provider per application category and new requests can be steered in that direction. However, be open to diverging business unit needs that might require a second provider in the same category.
• Include fast and slow assessment paths, with the fast path for providers that won’t have any sensitive data (e.g. marketing related 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 towards full federated identity and single sign on than cloud. It’s pretty much the only way to operate.

Although you can handle things with direct federation to your directory servers, in our experience this is an area where a commercial tool is a big help. We recommend build 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 to get 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 on an update.
• Require MFA for at least all administrative users, and ideally all users. When possible, further enforce MFA by requiring it as an attribute for authentication on the cloud platform (the cloud will look for an MFA attribute from the identity broker, this isn’t a 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 with a good process for selecting providers and solid identity management to handle your users.

While specific technologies and options change constantly and vary greatly across SaaS providers and security toolsets there are some consistencies we can build a program around:

• Use a CASB or something similar for your security management console for consistency, but not to the point where you fail to leverage inherent controls in your SaaS platform. CASBs can be great to provide multi-platform visibility and implement some controls, but this abstraction layer means you might miss some powerful capabilities in your platform itself. For your most critical cloud providers don’t rely just on the CASB, also make sure you understand the full native security capabilities. Fortunately, this is usually a short list (handful) of key providers, and the CASB will work for most of the rest.
• Always try to avoid having to proxy (Man in the Middle) your connections to the cloud provider just to integrate your CASB. If you follow our Critical Security Capabilities you will tend to choose providers the 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. Yes, these seems blindingly obvious but we have to mention it since we see a lot of programs that 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. More than anything else, know who to call in an incident and make sure you know the provider’s process to authenticate that you are a valid customer contact for incidents.
• 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 gain visibility and monitoring, then determine what compromises 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 in the cloud provider.
• Go back and make sure you keep up to date on your providers and their security capabilities. Embrace new security features. You may not use them all, but you certainly need to know they are there and if they would bring you value.

Additional tips for success

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

• Learn to love automation. Especially when you have the API support you need from the provider, just as with IaaS you should consider writing some of your own automation tools to validate controls, implement common processes, and speed up response.
• Audit the controls you set in the SaaS platform as well as in any management tool (CASB). Don’t wait until the auditor calls to find out someone disabled a key control (like making sensitive data public) and 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 use providers with robust encryption support and avoid the proxy models.
• Keep track of your providers, at least the most important ones. They are constantly adding new capabilities and some of these 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 the ad-hoc adoption of a few services, to moving essentially every back office application into the cloud. Building out your security program to support this rapid evolution will reduce risk and support agility without killing the security team as they learn new skills and techniques.

- Rich
(0) Comments
Subscribe to our daily email digest

The post Wrangling Backoffice Security in the Cloud Age: Part 2 appeared first on Security Boulevard.

from Wrangling Backoffice Security in the Cloud Age: Part 2