I work with dozens of companies on the development of their IT delivery strategy. The acceptance and attitude regarding cloud adoption has changed dramatically over the past few years. Previously, IT and business leaders were suspect of cloud technologies and hesitant to use them for anything other than low-business impact workloads. Now, the approach is often a “cloud first” mindset with a push to drive production applications and workloads into cloud environments. While cloud-centric deployments often provide great benefits, recent examples have led me to believe that, too often, IT leaders inadvertently – and inappropriately – have outsourced their responsibility for key components of IT delivery to their cloud partners. Thus, IT leaders must have an attitude of “trust, but verify” when it comes to running core services in the cloud or with any vendor that they engage. Let me walk you through a recent example.
Our organization adopted electronic signatures of contracts. As a growing company with over fifty directors signing client contracts on behalf of the organization, West Monroe’s legal team has benefited from streamlined contract management and our directors have commented that eSignatures helps with faster contract execution. We deployed it without the use of federated single-sign-on (SSO) against our internal Active Directory environment. We believe that single-sign-on should be utilized for these services because it provides a better user experience, lowers service desk costs for password resets, and most importantly, makes it less likely that a cloud account remains enabled when a person leaves the company.
For these reasons, Active Directory federation and SSO is strongly preferred for all of our cloud hosted application deployments. Our eSignature vendor supports single-sign-on and our team initially configured our instance of Active Directory Federation Services (ADFS) in order to work with their implementation of Security Assertion Markup Language (SAML). It was a fast setup and it worked. Once enabled, our users could access the application without an additional username and password. If we had simply trusted the vendor’s security capabilities, we would have rolled out the feature as implemented – but our team continued their testing through a number of different scenarios to confirm it worked as expected for all functional requirements.
While the sign-in piece appears to work correctly, there is a problem with the sign-out component. When a user logs into the application using SSO, it redirects them to our ADFS instance for authentication, and the federated login process occurs correctly. However, when a user clicks Logoff, the eSignature application does not actually sign them out. This is happening because the application redirects the user to its non-federated login page instead of our ADFS sign out page. If the application instead redirected the user to our ADFS sign out page, it would immediately destroy the authentication cookie/token. We consider the incorrect re-direction to be a security issue because it appears to the users that they have correctly signed out; however, users remain logged into our system until the browser cookie times out or until the user manually closes the browser. Unfortunately, this negates the non-repudiation for signed documents since a user believes they have signed out, yet someone else could access the system to sign a document.
Worse yet, this flaw has the potential to not only affect our eSignature application by allowing a user to access the system again without authentication, but it also allows a “signed out” user continued access to other federated corporate applications. For example, after a user accesses the eSignature application and attempts to sign out, someone else could use the browser and access our expense management system without any authentication.
In looking to resolve this, we followed the standard approach of reaching out to our account team at the vendor to report this issue. While we made a formal product enhancement request, almost a year later – including several escalations to the Director of Product Security– the issue is not yet resolved. While there are mitigating controls that help address the risk (access to the workstation within the timeout period of our ADFS implementation is required), we have chosen not to deploy this functionality until the issue is resolved later this year.
Recently I attended Microsoft’s Ignite conference, which included a heavy dose of Microsoft Azure content. One of the sessions related to high availability and business continuity of applications hosted within Azure. The speaker asked the audience a series of questions and asked them to raise their hand if the following applied to them:
Nearly all of the hands raised for question two were still raised for question three. This did not surprise me as I have led a number of educational sessions with IT leaders to help them understand that, while cloud vendors have great features to support scale, availability, and disaster recovery, most of them take no responsibility for ensuring your application stays online. At the scale these public cloud vendors operate, they simply cannot understand your application well enough to have their cloud technologies magically manage your risk. Microsoft has gone to great lengths to build capabilities to provide for both high availability and disaster recovery – but your architects and engineers need to carefully design for update domains, fault domains, paired regions and data synchronization to meet your uptime service level agreements as well as your recovery time and recovery point objectives.
Additionally, the “designed for failure” nature of public IaaS environments is not always a good fit for more traditional applications. Often times, vendors did not design legacy applications with the level of service granularity and server ubiquity that “design for failure” clouds require. Designed correctly, there are very few instances where a problem within the Azure platform should cause an outage to your application, but the application needs to fit within the new paradigms of application architecture and availability mechanisms.
Unfortunately, based upon the number of hands raised regarding unexpected business impact, and based upon my guess that many customers are using the single-sign-on feature of our eSignature vendor, far too many people are still trying to outsource availability and security management to their cloud providers. I am a strong advocate for cloud technologies and believe that adoption will increase over time, but IT leaders must understand that adoption of cloud technologies does not absolve them of their responsibilities to ensure that they have deployed their applications in a secure manner and have met the business needs for high availability and disaster recovery. IT leaders should have high expectations of their cloud providers and expect them to meet their service level agreements security requirements, but IT leaders must also accept their responsibilities to design their cloud deployments correctly and “trust, but verify” that the cloud vendor is delivering their application securely.
As you consider cloud deployments for your organization, having an outside perspective may help you accelerate your project by bringing leading practices and experience with the various cloud platforms.