4 Quick and Dirty SaaS Technical Controls

It seems cloud has gone from “emerging” to “entrenched” faster than any technology in recent memory — and much of cloud adoption is of the Software as a Service variety. For example, 71 percent of the organizations that responded to a 2012 Gartner survey had been using SaaS for less than three years, highlighting just how quickly enterprises were adopting.

This isn’t just a U.S. trend: Fifty-five percent of respondents to a recent TechTarget and Computer Weekly survey in the UK indicated they were prioritizing SaaS as their cloud service deployment of choice in 2013.

Because of this rapid pace of SaaS adoption, many security practitioners have found themselves scrambling to ensure the security of the specific technologies their enterprises want to employ. However, the dynamics of SaaS can make this a challenging exercise. This is because most of the options for specific security controls are, by necessity, of the contractual or procedural variety — e.g., audit controls, contractual language about breach notification, etc. Also, security teams often discover SaaS systems only after they are already in use, and implementing those types of controls after a contract has been signed isn’t always in the cards.

SaaS Security Shortfalls

Why are technical controls not used more often to protect SaaS deployments? It’s because of the way SaaS is designed to work: Vendors commoditize technology components below layer 7 (i.e., the application layer) and employ them as a black box substrate. As a practical matter, this means that many of the specific technical controls that shops would deploy for a traditional in-house business application are out of scope in a SaaS.

For example, they don’t have access to the network where tools like IDS and firewalls live; they don’t have access to the host to run tools like antimalware or DLP; they don’t have access to the database for enhanced DB-level reporting or access controls; and they can’t modify the application source to add application-layer controls like encryption.

In a traditional in-house implementation, a security team has options for how to supplement possible problematic areas in an application with technical security controls at lower levels of the stack. With SaaS, the organization is almost entirely reliant on the way the vendor has implemented security — meaning there’s little the security team can bolt on to help supplement weak areas, particularly when time and budget are factors.

Fortunately, though, technical options are not entirely absent. There are a few that organizations can consider — in some cases, the use of technologies they have already fielded. Following are a few things worth considering if contractual options are off the table and procedural controls don’t address the risks.

These aren’t the only controls available or necessarily the best controls — however, they can be implemented in a pinch while you and your team work out a grander plan. It’s a given that not every one of these will apply to every circumstance — but depending on the app, your users and the usage, one or more of these might be an avenue worth pursuing.

1: Consider an HTTP Proxy

Most SaaS applications use HTTP or HTTPS as the underlying protocol for communication. One mature, stable, and well-used technology to inject security controls into HTTP is the use of a Web proxy; both forward and reverse proxies can potentially have a role to play in a SaaS context, just as they would in any other application context.

For example, if your organization uses a forward proxy (e.g., for performance or content protection), you could consider adding a mechanism to notify you when a new or unexpected user accesses a SaaS URL. Is it a perfect solution? No, but it could give you a heads up if use of a SaaS spreads — or help you enforce licensing (e.g., per head pricing).

A reverse proxy can help you enforce security as well. For example, if your SaaS doesn’t employ TLS but should, situating a reverse proxy outside the organization (e.g., at an IaaS or colo) could help you enforce TLS (i.e., TLS to the proxy, HTTP only on the back end), or you could interrupt the stream.

Interrupting has upsides and downsides: It could break a secure channel, but it might allow you to introduce controls like a WAF, an authentication filter, or enhanced monitoring. In fact, there are commercial products that specialize in proxy-based solutions to encrypt, tokenize, and add monitoring or access control (e.g. CipherCloud and Perspecsys). However, you could do similar things with tools you already have or open source components.

2: Consider Web App Testing

Another strategy is to consider the use of the Web application testing. Obviously, you’d want to get the provider to agree with this before you unleash the hounds, since you don’t want them suing you. They may not be inclined to balk at giving you permission, since attackers scan Internet-facing services relentlessly anyway.

While the vendor would obviously need to own the fixing of any issues you might find, foreknowledge of particularly problematic areas could help give you leverage — e.g., during contract renegotiation — or could give you ammunition to push back on your business’ usage when issues are dire enough.

3: Consider Application Monitoring

Application performance monitoring tools have been around for decades — think network agents reporting when a host is unreachable or if an application is unresponsive. In fact, you probably have some of these in place already.

Knowing about a SaaS outage can be every bit as critical as knowing about an outage in an application you host internally. Using a tool in this way isn’t rocket science by any stretch, but you’d be surprised how useful it can be to know ahead of time — before users start calling — that a SaaS application is just down.

4: Consider IAM Strategies

Many SaaS providers have embraced flexibility in how they manage user identity and authentication. The reason for this is that pushback from customers about account sprawl is tremendous, so giving users an option to use existing accounts — e.g., their domain credentials — is a huge selling point.

In many cases, this can give you a hook into the logic of the application you wouldn’t otherwise have. Concerned about fraud? Maybe require certain types of users to employ multifactor when certain applications request a SAML assertion. Concerned about inability to log user access? Consider implementing access alerts when authentication requests are made to provide a quick and dirty log of which users accessed the app and when.

There are numerous other creative solutions that you might employ, of course, given your particular technical ecosystem and your particular SaaS apps. Even though you can’t access the underlying infrastructure components of a SaaS app, with a bit of creativity you can exert control over and influence some tech areas — any of which could be an avenue to explore in deploying additional technical-level controls.