Cyber-Security Concerns to Know Before You Sign On


David Monahan is Research Director for Enterprise Management Associates (EMA) and is a featured guest blogger.

Any of us who use the Internet with regularity enjoy the benefits of Federated Identity Management (FIM) and Single Sign-On (SSO) without much thought. Because of these technologies, we are able to move between our favorite blog site, news center, or social media site (Twitter, Facebook, LinkedIn, etc.) without having to struggle for log in information.

FIM is the organizational and contractual arrangement that separate entities use to allow shared or in-common users to leverage a common identity to access their services. They must agree on who owns the identities, what privileges are allowed to be passed, how they will interact as an asserting party (the one that receives the first authentication request and validates it), the relying party (the one that receives the authentication validity assertion), and the back end authentication protocols as well as liability issues for misuse or mis-authentication and a few other contractual issues.

SSO is the capability of using a single identity and password to access desired/permitted resources. This is generally done within an organization but can also be used within a FIM construct between organizations.

The most obvious benefit is low user friction. This is the largest single driver for implementation from the user perspective. Once authenticated to the asserting party, the user has nothing else they need do to access the various resources within not only that identity realm, but in any associated or relying realm.

The most significant security issue is based upon the same situation, full access to all of the users’ entitlements with one identity. Once an attacker is in, everything associated with that single identity is accessible so there are no gates or controls stopping total take over or compromise.

I first began working with SSO at the enterprise level back in 2004. The IT team assigned to the project was ahead of their time; they were able to glue together access between Microsoft Active Directory (AD), third party applications for Microsoft and even elements of the Linux environments that IT managed. In ’04 this was pretty cool and cutting edge. Those not involved in the leading edge project expected a high level of interoperability, but had no idea of the combination of technical artistry and Frankenstein-ian patchwork required on the back side to synchronize the identities across the environments and pass authentication between applications that weren’t designed for SSO.

Now, zoom forward to 2015…

Microsoft has expanded its SSO so it not only works with all (99%) of the applications in a local environment, email, shared infrastructure resources, and SharePoint but it also operates between forests and other shared trust implementations in Microsoft and non-Microsoft environments without the need for cobbling. It doesn’t stop there. They have created a SSO authentication so identities that are maintained with the local AD can be used to access organizational resources from the Internet and access Microsoft owned, customer assigned infrastructure and resources across the globe including Windows Azure, and Office 365.

This is done using a model similar to Kerberos, where credentials are not passed in the clear during the authentication process and once authenticated, the user maintains a token provided by the authentication server that is presented to the resources (s)he attempts to access and validated by the system responsible for authenticating access to that resource.  As previously mentioned, this is a boon for usability with users benefiting from years of research and development. However, there are still security configurations and concerns that need to be managed.

Since a “single” server is responsible for access, some form of redundancy should be followed, clustering, master-slave, multiple physical locations, etc. It should also have a back-up set up in case of corruption or other unexpected failure/disaster.

The SSO server itself contains a master secret that is shared with the other services it has authority for so that server and key store must be protected.  Proper access controls, firewalls and activity monitoring are crucial.  It should also be a standalone installation meaning that the system should not support any applications or additional services not requiring the SSO as those increase the attack surface of the system making risk of compromise greater.

Organizations also need to ensure that local system and application administrator accounts are treated as equally sensitive as domain administrator accounts.

The SSO authentication service account and SSO administrator accounts should be unique for their purpose, not shared accounts or accounts used for other purposes so they can be easily isolated and identified as itself for logging and troubleshooting.  It also helps to compartmentalize sensitive functions in case of compromise.

Users should understand the scope of impact their accounts can have if credentials are shared or compromised.  As mentioned earlier, with compromised SSO accounts, the attacker has unfettered access to all resources the user had. 

This makes user security awareness paramount. 

  • Users need training on how to avoid phishing attacks and how to surf the Internet safely.  Such attacks can subject them to malware embedded in a requested download (Trojan horse) or a drive-by download (malicious content from a web page that downloads without user request as part of the visited page). 
  • Users should also refrain from downloading content from sites they have no knowledge of.  Compromise of the user identity or system with the identity token on it means attackers have access to everything the user does.  The malicious activity can appear to be coming from the user putting their livelihood and reputation in jeopardy. 

SSO and FIM are great tools but also deserve a level of user respect that they do not yet receive.  This mostly comes from an out-of-sight, out-of-mind situation with the users.  Users need to understand that they have access to information that someone wants and is willing to break the law to get without remorse or likelihood of getting caught leaving him or her holding the [broken] bag and having to pick up the pieces.

David Monahan

David is a senior information security executive with over 15 years of experience. He has organized and managed both physical and information security programs, including Security and Network Operations for organizations ranging from Fortune 100 companies to local government and small public and private companies. He has diverse Audit and Compliance and Risk and Privacy experience – providing strategic and tactical leadership, developing, architecting and deploying assurance controls, delivering process and policy documentation and training, as well as other aspects associated with educational and technical solutions. Aside from his full-time practice in the security field, David has been an adjunct faculty member for Capitol College in Laurel, Maryland since 2007, providing security instruction on both the undergraduate and graduate level. He has also presented briefings to numerous forums including SANSFire, Forrester and the Colorado Digital Government Conference.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center