Single Sign-On (SSO) Security
Working in IT is a constant battle to find the perfect balance of security and productivity. This is no better personified than in the need for Active Directory (AD) users to access multiple systems through the use of Single Sign-On (SSO) platforms.
SSO solutions eliminate the need for users to remember a unique, complex password for each application and platform they access, replacing it with a single logon facilitating access to multiple systems and applications.
Offering faster access times to applications, with reduced password requirements (usually, one), it’s a no-brainer technology that reduces administrative overhead and support costs, while being a non-disruptive technology with a high adoption rate.
It also does come with some security benefits: Since SSO only utilizes a single credential it often equates to requiring a very complex single password. Additionally, the act of disabling access enterprise-wide becomes as simple as disabling the initial account.
But, as with any technology designed to improve productivity, there are often losses on the security side. And in the case of SSO, there are some implied security risks.
What are the Security Risks in SSO?
In general, SSO is more concerned with providing access than restricting it. And, at a time when malware-based attacks are rampant, it’s not the perfect time to be giving it all away. Despite the benefits previously mentioned, there are quite a few risks that come along with utilizing SSO:
1. Instant Access to More Than Just the Endpoint
Logon credentials are a major focus for external attackers (81% of data breaches involve credential misuse1). With SSO in place, once a malicious user has initial access to an authenticated SSO account, they automatically have access to all linked applications, systems, data sets, and environments the authenticated user is provisioned for. Most SSO environments leverage a portal of some kind that facilitates access without requiring additional passwords. While great for users, it’s terrible for security!
External attacks using malware to gain control over an endpoint would have post-logon access to everything connected via SSO immediately after infection, increasing an attacker’s footprint within the organization.
2. Less-Than-Perfect Control over Access Once Granted
Let’s say a user has successfully logged on via SSO and is granted access to additional external applications in the cloud. Then the user falls prey to a phishing attack, giving an attacker access to the endpoint.
If detected, the account certainly can be disabled, but given the way Windows works, the user remains logged on and, depending on the SSO solution in place and the linked application’s security model, it’s possible for the attacker to remain logged on with access to a given application.
3. Little-to-No Adherence to the Principle of Least Privilege
The principle of least privilege dictates that users should have access to the minimum data, applications and systems necessary to do their job, and usually involves requiring separate credentials for elevated access.
Because SSO is all about giving you access with a single authentication, it runs contrary to the idea of requiring the user to authenticate each and every time they need to access something new.
Even with risks, organizations like the benefit of the improvement in productivity and reduction in support costs. So how can you facilitate the simplified access of SSO while still maintaining a solid security posture?
Reducing the Risk in Active Directory SSO
Surprisingly, the answer doesn’t lie in getting rid of SSO. On the contrary, it’s about filling in the security gaps by taking a few additional steps in a way that is as non-disruptive as possible.
Step 1: Address password vulnerabilities with two-factor authentication (2FA)
Two-Factor Authentication introduces an additional security layer of security to protect AD accounts whose password has been compromised. After the usual login and password check, the system will ask for a security code.
Using 2FA for Active Directory accounts puts a few security controls in place:
- It can stop a data breach before any damage is done
- It protects all users, including the most privileged ones
- It makes compromised credentials useless to the attacker
- It can be customized for any user, user group or organizational unit
- It can be used in conjunction with logon management to become even more powerful (see next step)
2FA solutions are not widely adopted and most likely because they are thought to impede end-users with additional security steps that prove costly, complex and time-consuming for the IT department to set up and manage. Well, that’s not true, those are 2FA myths.
Combining SSO with 2FA allows organizations to verify the identity of the users while giving them easy access to work applications.
Step 2: Securing the Logon to Active Directory with Logon Management
A Logon Management solution puts a few security controls around the initial Windows logon:
- It restricts when and from which endpoint(s) or IP addresses a particular user account can logon
- It restricts logon frequency and concurrency
- It restricts based on session type (local, RDP, etc.)
- It monitors logons for unusual activity such as attempting logon on after hours or from an unusual endpoint
- It can require approvals from another user – normally a manager, or IT
- It can force a full logoff from a Windows session based on permitted hours or in response to IT directive
It’s that last part (underpinned by all the other Logon Management capabilities) that fills in one of the gaps of SSO – killing access via SSO is only effective if you also kill access to all of the external applications. With an ability to kill the entire Windows session, you know every accessible data set, system, and application is equally secure.
Usually run as an integrated part of the logon process, Logon Management is a non-disruptive technology that aligns with the productivity-focused mindset of those implementing SSO.
Step 3: Improving a Least Privilege Posture with Privileged Session Management
SSO desires to give users access to additional applications without requiring a logon. But good least privilege practice dictates that elevated access require additional authentication. A happy medium might be the use of Privileged Session Management (PSM).
PSM is a proxy of sorts between the user and the system or application with elevated access. Low-level users can request access (by means of a portal) with access granted without providing the password to the user. Now, this sounds like it’s no different than SSO, and in some ways, that’s true.
What PSM would add to the mix is its policy-driven controls under the hood that put a few additional controls in place:
- It can define which users can access which systems, when, from where, etc.
- It can require approvals of a peer or a manager before allowing access
- It can notify IT of access granted
- It can record the session to create an audit trail of activity
The addition of PSM creates a similar end-result to SSO, with a comparable level of “non-disruptiveness” but with the addition of having several layers of security controls in place.
Step 4: Use Security Policy-Driven SSO
SSO has a place in any organization and, in the case of organizations with many cloud-based apps, you can successfully leverage AD as the system of record for all external access. By having solid AD controls in place (such as Logon Management and PSM), you create a secure foundation for SSO. But you can’t stop there.
Below are some suggested SSO security controls to have in place:
Ensure SSO least privilege – think about the access SSO should provide using the lens of Least Privilege. Define roles for each type of user in the organization, identifying the specific applications they need to do their job, limiting access to only those IT deems absolutely necessary.
Require Multi-Factor Authentication – asking for more than just one additional factor significantly improves security.
Use Modern Authentication Protocols – Make sure your SSO solution is leveraging OpenId Connect or OAuth 2.0.
Limit Device Access – Put restrictions on which devices with which a user can leverage SSO.
Enforce Frequent Password Changes – for accounts with elevated access, consider requiring new passwords more often.
Achieve Both Elevated Security & Productivity with AD Logon & SSO
The risk in SSO exists only if you see SSO as a means to gain access. But by recognizing the inherent security gaps that exist, and compensating by implementing additional controls in the form of Two-Factor Authentication, Logon Management and Privilege Session Management, you effectively reduce SSO risk, making it a source of elevated productivity and security.
1 Verizon, Data Breach Investigations Report (2017)