Cloud Access Control and the Balance Between Complexity and Compromise

Many of us in the security field are addressing the complex and often misleading functionality assertions made by our outsourced service providers in the “cloud” when it comes to security. Functionality like: Data Loss Prevention, eDiscovery, Federated authentication access, SAML, OAUTH2, etc..

Security… the bugaboo in the “cloud”.

However, there is a lot of IT service management that forms the very foundation of security, and because of that, cloud services are becoming extremely attractive from a security perspective. From personnel support costs, to hardware maintenance, you can address some of the most aggressive security challenges we all face by adopting cloud services. And they include; patching, configuration management, and inventory control. The top three SANS controls. I’ll repeat that; the top three (3) security controls. Despite the concern that all of us face in moving to the cloud, there are a lot of compelling security reasons to do just that. E.g. Consider the benefits of platform as a service in the cloud the next time a HeartBleed bug arises in the news, and your organization needs to address it. How long did it take to update all of the SSL libraries on your myriad webservers to calm the fears of your customers, and clients? In nearly all cases, the PaaS cloud offerings had the patch and remediation online within 24 hours of the issue.

Still, like any security blog, this is a cautionary tale focused on the concern with what happens when things are headed in the wrong direction, and more specifically where they can go wrong. Because many of us know what happens when outsourcing some part of their services and maintenance to a third party vendor - you need to understand the risk of doing so. Take Target, for example, putting their HVAC vendor on the network to manage their heating/cooling systems which subsequently led to the compromise of their PoS systems. Knowing the risk is the first step toward addressing that risk.

I want to focus on one area where the risk may not outweigh the reward: Cloud access security brokers (CASB).

A CASB can address your biggest challenge in easing user acceptance of cloud services – which is: using the systems as easily as if they were in your own data center. How many of you have been asked; “why can’t we have single sign-on (SSO) to the hosted corporate website?” Or to Salesforce, or DropBox, or Google, etc.? A CASB can provide that solution: secure authenticated access to an externally hosted service. Yet like the hosted service itself, it is another cog in the machinery of third party vendors out of your control: providing the enterprise with client-to-service authentication, just like your internal Active Directory would do for internal resource access. Only in the cloud.

The old folks from Cambridge will quickly chime in to state – “yup, Kerberos, we get the idea” - the OASIS group in Burlington – “done that with SAML”. It should be clear, that the requirements to enabling transparent authentication to external systems and services have been defined for nearly 20 years, though only with SAML 2.0 has it been relatively widely adopted. And even then, it is a lot of effort to get it to work right. To quote one writer: “it is an extremely complex, and obfuscated protocol” based on XML. And it is because of this complexity that the next generation of SSO vendors have taken advantage of this great market opportunity to fill that gap: Okta, OneLogin, PingIdentity, Netskope SkyHigh, etc.

To highlight this concept; let’s use a third party vendor to handle access to another third party vendor by providing our most sensitive access control: authentication.

To a security professional this seems risky right out of the box. If not for the concern of; yet another third party vendor exacerbating your third party vendor risk further, then because that external entity is getting access to your most sensitive data; authentication credentials for your personnel. Similarly, it would be a concern that such a vendor had access to your personnel data at all. How many of you want the world to know who your entire ‘C’ level staff is, where they are located, their phone number, and e-mail addresses to use for phishing?

Security 101 – never release more information into the wild than what is necessary.

Unfortunately, more information is just what is needed; relational information, because it is not just authentication we are looking for, be authorization as well – what areas of a cloud service should the members of your enterprise get access to? Should developers see the CRM data entered in by Sales? How does one collaborate with members in your group without knowing who the members in that group are? Despite the available standard, SAML is only the component of authentication in the solution of cloud services access control. What is also needed is authorization. Fortunately, like SAML, there is a standard for this portion of the solution as well: OAUTH.

Currently many CASBs eschew both security standards.

The market leaders in this space provide an increasingly necessary solution that many of us are looking for: easy access control to information in the cloud. It is how this is done that is the devil in the details. Let’s look at the market leader for this segment (according the Gartner), OneLogin, for insight into this process (noting right up front, that not all CASBs are made the same). OneLogin’s design introduces a system running in the enterprise to connect OneLogin in the cloud to the enterprise’ security data: known as an active directory connector (ADC). To use an engineering term; it is a “black box”. A non-standards based application whose functionality is unpublished, and non-interactive. It requires NetBIOS to identify the domain servers in your environment, connect to them, and subsequently enable the OneLogin services in the cloud access to that data. And while that is a blunt assessment of the functionality of what is happening, it is not that far from what a SAML gateway might also provide, with a lot less effort.

It is how this is done that is disquieting.

OneLogin requires this black box be equipped with a domain administrator account to access your domain controller with. Despite any publications on their website to the contrary, any less privileged account causes the synchronization process to fail. I.e., if the black box, cannot read specific attributes and Organizational Units (OUs) in your active directory, the ADC fails. The ADC has no configurable settings for the user, it is a dumb LDAP replicator; cloning the client AD information from your Active Directory into the cloud. The cloud however, does have configuration control, and it can be configured to publish a reduced subset of the over 1300 Active Directory attributes for use in subsequent federation. What it does with the rest of the data from your organization is left to the imagination. And this is particularly troubling when the on-premise client reports problems with reading OUs that were specifically configured NOT to be read. Like deleted accounts. So the agent tries to read AD information that you specifically configured it not to read regardless of your cloud configuration settings. Whether

that is an artifact of the query and the agent is subsequently filtering this data out before it is sent to the cloud is less important than the fact that data is coming out of your Active Directory and going into the OneLogin infrastructure that you do not want going there.

..like all of the account information for your domain administrators. …and your user password hashes. Better yet, let’s take them together: your domain administrator password information. How many of us are willing to trust their third party vendor to this level of authentication information? How about to a third party vendor that is specifically used to enable access to yet another third party – and is being used by that other party to access your information? In a federated cloud model, your company may not be the only administrators over your identity data, particularly because you are trying to federate access data.

I would argue that this is not a good idea. Surprisingly, OneLogin is not alone in this model; Okta also provides a non-standard on-prem box to access your domain authentication credentials, and according to Gartner these are the two market leaders in this segment at the moment. Perhaps because they are so easy to implement.

For those of you that like to go the last page and skip the beginning, let’s take a moment to summarize where we are:

1) You have a third party vendor using a black box construct to access your most sensitive data and send it to the cloud

2) You have no idea what is being sent out to the cloud3) You have no administrative controls over the black box to discover or control that data

The cold hard truth is this - unless you can configure NetBIOS across your firewall to isolate this system, you can’t even limit the impact of what happens to your environment when the cloud vendor is hacked and those responsible decide to take over that box on your inside network, because you could not firewall the system off. All you know is what is shown on a UI in the cloud to reassure you that this should never have happened…

Regardless of where any controls may in fact be with these companies, this is a nightmare scenario for all security practitioners. But there is a realistic balance between security and ease-of use, because not all CASB vendors function in this way, many support security standards such as SAML 2.0 and OAUTH2 to achieve what we all need to accomplish; federation and security.

The point? We live in an increasingly complex environment. But it is not necessary to compromise security for ease-of-use. This kind of out-of-the-box solution may come at a steep price, and in order to avoid paying that price, demand a standards-compliant solution for all of your third-party vendors whenever it is possible. There are many other CASB providers that can do this same functionality without gutting your enterprise security model. If you are curious as to who, please don’t hesitate to reach out to me via e-mail at david.humphrey@hphc.org