Are you really who you say you are? This has long been the key question and the key challenge in managing user access to corporate networks and IT systems. In recent years, capabilities for context-aware security have expanded this WHO question to identify the WHAT, WHEN, WHERE, and HOW details for each login attempt at the network level. Now, a planned deployment of application connector software for the Cisco Identity Services Engine (Cisco ISE) will extend our context-aware security down to the application level.
How Context Awareness Supports More Control
Network security has traditionally operated on trust that the person behind a login name and password is indeed the right one. The problem is when hackers capture usernames and passwords. They can simply login and access anything authorized for that user, even the most sensitive data and most critical systems. Context-aware security limits that open access by evaluating more factors in the login and detecting variations from the user’s norms.
Context awareness changes security from an approach of “you have access to everything when you login” to an approach of “you’ll have access to some things based on where you are and what you’re trying to do, on what device and at what time.” For example, context awareness will detect when an employee is trying to login with their company laptop from an airport lounge using the public Wi-Fi service instead of a secure VPN connection—and limit their application access accordingly.
Traditional user authentication methods focus only on WHO is trying to access the network and WHAT they can do once they get in. Today, with greater user mobility and more applications in the cloud, we need the ability to authenticate users by evaluating the additional factors of HOW, WHERE, and WHEN before allowing a login to proceed.
As shown in the diagram, when all of these factors are evaluated together, they provide more extensive and relevant information for determining whether to allow, reduce, or block application access for each login.
- WHO: The username, password, and any other information that confirms the identity of the user who is attempting a login.
- WHAT: The device being used for the login attempt. This factor could be used to block logins from a user’s personal mobile device if it has not been authorized or updated.
- HOW: The type of access network being used by the device.
- WHERE: Confirmed geographic location for the device.
- WHEN: Logins can be managed to block access during certain times, for example, on weekends.
Why Security Context at the Application Level Is ImportantCombining all of these user login factors gives us the benefit of more control with layered security, deeper authentication, and more granular access policies. Users also benefit because context-aware security can give them a zZero sign-on experience when all of the factors comply with access policies.
Two major trends are driving the need for context-aware security at the application level. The first trend is on the network side, where borderless architectures mean that applications are scattered across the enterprise network and multiple clouds. No longer is there a single entry point to the enterprise network, a point that can be protected by security solutions that use only limited context information.
Changing user expectations for doing work are the second trend driving the need for context-aware security. Employees want to use their own mobile devices to access the enterprise network and conduct business at any hour of the day, no matter where they happen to be. This mobility means a lot of factors are outside of the enterprise’s control, making it even more important to see the full context of a login attempt. Similarly, business applications need more contextual data beyond WHO the user is so the application can enforce fine-grained security policies.
Next Up: The Cisco IT Deployment
As of late 2015, we are deploying the application connector software in the Cisco IT production network to extend the Cisco ISE capabilities for context-aware security. In a future blog post, I’ll discuss this deployment and the lessons it offers to help Cisco customers in their implementations.
Nice article, thanks! Looking forward to learning more about Cisco IT’s internal deployment of ISE.
Also, an odd use of ISE just occurred to me, when you described “Logins can be managed to block access during certain times, for example, on weekends.”
I’ve been told that France regulates the number of hours an employee is allowed to work per week (37.5 hours / week).
With “work / life balance” being, sometimes, rather unbalanced; I wonder if someday government regulations might require businesses to reduce or block employee access to work systems – maybe not to weekends, exactly, but maybe set a timer for the number of hours per week an individual can be logged on …