The mainstream adoption of mobile and cloud technology has not only transformed the way we work, but created a pressing need to re-engineer IT security.
Traditional IT security is built on the notion that we put trusted users, devices, and applications in one place and surround them with a firewall. However, this approach no longer works in a world where devices are personal, where applications are available from any network, and where not only employees but also partners, contractors, and customers must be supported over the big, bad Internet.
For example, many employees use personal mobile devices to log into corporate assets, access sensitive information through email, and store company files on cloud storage services, opening security holes that leave organizations vulnerable. The problem is exacerbated by the fact that most employees don’t follow official IT security policies.
Hackers are bypassing traditional perimeter security and firewalls altogether by compromising weak and stolen passwords to take sensitive personal data right off the network. Moreover, as more companies embrace infrastructure as a service (IaaS), these expanded threats loom over both on-premise and cloud infrastructures.
As a result, companies must shift the security focus away from firewalls and the corporate perimeter toward using identity as the crucial element throughout the new security stack.
Explicit vs. implicit security
When we talk about identity-based security, we're really talking about the idea of explicit versus implicit security. Think about work a decade ago. If you were sitting in front of a PC, the implicit security assumption was that you were authorized to use it and some kind of physical security would protect access to the keyboard. Over the years, many implicit assumptions have been made -- both in deployment and design -- that have created opportunities for misuse. As attackers started finding their way inside the firewall and grabbing data from relatively unprotected applications, perimeter security gained a reputation for having a hard and spiky shell with a soft and chewy center.
Identity-defined security is explicit. Authorization and access is specifically tied to the individual and to the context of the user’s current digital interaction. Users are only one kind of identity in this paradigm; device identity, network identity, and the identity of the software that the user is interacting with are all evaluated to make security decisions. Ideally, this identity- and permissions-based scrutiny permeates all the way to the usage of databases and back-end services.
Historically, designers of authentication systems naturally assumed their products would operate in isolation. If a user were to type their password incorrectly into the login screen three times, the answer was simple: Lock out the user, and forget they tried to log in. Thus, the initially perceived risk was mitigated, and no administrators were bothered with what was likely to be a benign misuse of the resource. However, in today’s world of interconnected systems and global threats, there are no simple answers. A failed password attempt is a single data point that is meaningless in isolation. What if the same user experiences 100 failed password attempts, all within 24 hours and spread across 100 different applications?
When identity is intrinsic to interactions and when the capability exists to collect and interpret trends, it becomes possible to track how systems are being used on behalf of users in greater detail, over time, and across the entire enterprise. Collection of small data points that contain contextual clues about who might be using the resource are analyzed for trends that can be used to enhance security understanding over time. In this new world, failures or omissions of context could prove as illuminating as successes. For example, repeated password success followed by failure of a second factor might indicate that a password has been compromised and is being used by someone not in possession of the owner’s mobile device.
The identity platform difference
Identity-based security works by integrating all enterprise applications into a central identity platform. A central platform allows companies to apply authorization policy and leverage security tools such as multifactor authentication across all applications. The platform can consist of multiple solutions that are layered to represent unique business needs -- as long as those solutions interface with applications via standardized protocols such as SAML or OAuth 2.0.
Identity platforms are evolving to enable holistic security evaluation. What devices and apps are in use? Are users logging in from a company network or from a remote site? Do the keyboard biometrics match standard patterns for this user? In other words, the system will continuously authenticate the user in real-time based on access patterns, contextual factors such as location, and active factors that challenge the user in some way.
The evolving technology behind this “contextual authentication” allows us to go far beyond merely challenging the user for a password. Rather, the system can check multiple factors in real time and make access decisions based on the outcome of those contextual checks.
For example, consider a user session established with the proper password and that passes initial authentication checks but subsequently behaves in a way that does not match the usual patterns, by attempting to access confidential documents or downloading large amounts of data in a short period of time. In this case, though the user has a valid session and has theoretically proven their identity, the identity platform can choose to revoke that session or to further challenge the user to prove that they are who they claim to be.
Many consumer sites already operate on these principles today. For example, if you do something unexpected with your credit card, you may receive a phone call from your bank. But contextual authentication systems for the enterprise will take more time to mature, as best practices emerge and the industry better understands how to connect applications and apply identity analytics to take advantage of the technology. Today, enterprise-oriented identity platforms can evaluate “passive” factors such as device posture, network location, and physical location in real time, and they can present users with active challenges that range from voice recognition to simply “knocking” your knuckles on your smartphone. But those simple building blocks are only the beginning.
In contrast to the contextual authentication unlocked by identity platforms, perimeter security is stateless, with identification events occurring only in isolation. In a perimeter-controlled organization, user-identification data typically reside on each system, rather than in a central platform, and system authentication methods vary considerably by system. These pools of isolation make the perfect playground for an intruder to try out various username and password combinations without being caught. When authentication for all applications is integrated into a central identity platform, patterns of repeated password pinging can be quickly flagged as possible intrusions.
Identity-defined security also has distinct advantages from a compliance perspective. Because application membership is directly tied to a central platform, authorization can also be centrally applied. This means the burden of reporting on who has access to what is no longer an application-by-application affair, and the data within those reports will be more uniform. Additionally, account administration can be automated through identity standards like system for cross-domain identity management (SCIM) so that name changes, role changes, or user termination can be executed once and instantly recognized by the application.
Organizations with identity platforms often proactively pass their compliance needs on to vendors, by ensuring that identity requirements are in every technology RFP. Thus, identity-defined security becomes a critical factor in product selection.
Implementing identity-defined security
Building on open standards like OAuth 2.0, SAML, and OpenID Connect allows IT to manage changes at the identity platform level rather than the application level. It also enables IT to easily integrate with applications outside of the organization’s control, such as partner systems or SaaS apps. For example, many cloud-based applications support the SAML 2.0 standard for Web single sign-on, allowing the SaaS application to redirect the user’s browser to the organization’s identity platform for authentication, rather than storing a password in the cloud. By connecting the cloud application in such a way, users have one fewer password to remember, and the organization gains control over how and when their users authenticate.
APIs and native mobile application security are also critical parts of an identity-defined security architecture. The practice of caching usernames and passwords within mobile applications and relaying those sensitive credentials to APIs puts those credentials at risk of being harvested by attackers. Identity standards give application and API developers a safer and simpler alternative. Instead of prompting users for their credentials directly, developers can redirect users to the identity platform to authenticate. The identity platform returns an “access token” to the application, for use at authorized APIs; this access token, if stolen, cannot be employed to impersonate a user, only to execute a small amount of functionality on the user’s behalf.
Identity-defined security need not replace existing legacy identity systems, but rather may serve as the integrative hub. Existing solutions such as Web access management systems or Windows domains can effectively authenticate users, but they’re meant only for single domains. These systems can easily work as part of an identity platform, in conjunction with a federation server that can securely transform a local session into a security “assertion” that can be validated and enforced remotely.
There are many different ways to structure an identity platform. Some organizations keep everything on premise and in the data center. Others opt to move the entire identity platform to a hosted IaaS environment. Still others use a cloud-based, identity-as-a-service (IDaaS) offering. IDaaS usually covers the more common use cases at a more reasonable price point, and it relieves IT of much of the design and operation burden. Hybrid architectures are also common, where lightweight identity bridges are operated by organizations, in order to leverage existing identity repositories, while keeping the rest of the identity platform in the cloud.
In the final analysis, network perimeter security is not going away -- rather, it should work in tandem with identity-defined security. Indeed, perimeter security solutions can serve as valuable data points in an identity-defined security architecture. The ultimate goal is to harden the chewy center by making every application into both a sensor and an enforcement point, giving organizations the opportunity to understand the ways that users should and should not be interacting with the organization as a whole. When the patterns of legitimate and illegitimate user behavior are known, the power exists to make smarter security decisions and more accurately protect corporate assets and people.
Pamela Dingle is a senior technical architect within the Office of the CTO at Ping Identity. Pamela has a long history with identity management, having worked in implementation, architecture, and strategy over 10 years of evolution of systems such as directories, application servers, Web access management systems, provisioning, and now federation. Pamela is also on the board of directors of both the Information Card Foundation and the OpenID Foundation. In addition, she runs the Pamela Project, an open source project for Information Card relying parties.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.