The occasion for this eye-opener was a meeting with our CIO and his IT team, who were preparing to investigate single sign-on (SSO) for the company and wanted my input on requirements and vendor selection.
When your employees have to sign on to just about every application they use in the course of getting their work done, SSO starts to make a lot of sense. As a matter of fact, we’re still using just two on-premise corporate applications: one to manage our source code, and a collaboration software package that our engineers use to track product road map changes. Everything else, from email to sales and marketing to our financial and accounting software, is all cloud-based now. We even migrated a password vault to the cloud. When you count them all up, we have about 20 corporate applications (that we know about) in the cloud, and that means 20 different passwords to remember.
So, yes, SSO makes sense. But it also scares me to death.
Which isn’t to say that it won’t help in the areas of security and compliance. Because our cloud initiatives were often undertaken not by the IT team but by various departments, we have the marketing team administering its own application, the HR team managing the performance management application, and so on. This decentralization has resulted in many departed employees retaining access to some of our cloud applications. SSO can help resolve that sort of problem.
But if not deployed properly, SSO can cause a company more harm than good. What makes it so convenient for users — just one password for all SSO-enabled applications — is also what can make it a threat. You log onto your PC in the morning, and that authentication extends to all the corporate applications you need. Wonderful! Except that the same holds true for any hacker who gets a hold of your credentials. Not wonderful at all!
A directory service such as Microsoft Active Directory, which we use, can help. Active Directory streamlines account management, providing one place to configure an employee and one place to remove or disable any employee who departs or no longer needs access. Ideally, once an employee’s identity is created, the accounts, services and roles are enforced within Active Directory, and associated accounts are created for the various applications that employee needs to access (and only those applications), both on-premises and in the cloud. This doesn’t always work, however, because not all applications provide integration with Active Directory, and some don’t support SSO capabilities, which include SAML (Security Assertion Markup Language) or other direct integration or synchronization. When that happens, an employee can bypass the SSO access and browse directly to the application.
I’m also wary about going with an SSO service that offers an application portal, which gives employees point-and-click access to all the appropriate corporate applications and even personal applications, such as banking, Amazon and eBay. No need to remember passwords for any of them, or even to bookmark them. For employees who travel or work from home frequently, it’s a great feature. I, however, always see danger when I think about employees using public PCs at an Internet kiosk or hotel lobby; if they don’t log off properly and leave that portal up, anyone could get access to sensitive corporate information. For that reason, I would want the login to such a portal to be protected by two-factor authentication and encryption. And the inactivity and session timeouts need to be set to mitigate the risk that arises when a user walks away from an untrusted public PC.
Finally, in choosing an SSO vendor, whether cloud or on-premises, we’ll need to conduct appropriate due diligence, since we will be entrusting credentials and availability of the service to a third party.
As we progress, I’ll be putting together a complete set of security requirements and due diligence questions for a potential vendor.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.