Evolutions in Authentication, Authorization, and Accountability: Exploring Zero Trust and Conditional Access
Who are you, and what do you want?
A system is only as secure as the weakest security control deployed to protect it; typically, that starts with an identity and access management (IAM) system as the highest priority control: who can access a given object or resource, and how? The number objects that require access and authorization policies has increased with the growth in the volume of sensitive data stored digitally. Our users work remotely, on different devices, with external parties, and have a variety of means to identify themselves. The same goes for non-human users AKA entities. This article offers a construct in which to consider Authentication, Authorization, and Accountability (AAA) and surveys some recent trends in the enterprise space: Conditional Access and Zero Trust.
An object to be accessed could be a system, website, network, endpoint, or parts thereof. Access, based on one’s identity, is only one dimension of sound IAM practice: once granted, it must be possible to determine which features and functions of the object an authenticated user requires permissions to alter or see. Access and trust are typically determined based on role, a relatively static element that is becoming obsolete. In its place, we are seeing privileges with a shelf life. Identity brokers also tend to defer to role to define authorization (i.e. permissions). Increasingly, user and entity behaviour is accounted for to grant or refuse read/write capabilities.
“Authentication: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.” — NIST
My very rough graphic depicts the interplay.
We likely cannot achieve ironclad AAA for every system or resource. Rigorous standards must apply to the most sensitive systems, regardless of how exposed they are. Hence, segmentation is critical to ensuring that access to one system cannot result in lateral movement to another until a user’s session is authorized to do so. The logging of sessions and events based on use cases to support auditing and alerting is critical and should be prioritized for implementation. Only with AAA logs can a system support accountability and non-repudiation.
What are the factors that can be used to confirm identity to grant access, and if necessary, authorizations?
Something I have, something I am, or somewhere I am can all be factors to establish both identity and the level of authorization to be granted to a system. The second factor (after a user ID) in any access and authentication exchange is nearly always a typed password. The second factor is typically a code sent via SMS or email. The former is no longer endorsed by NIST and new, more user friendly, second factors have popped up in recent years. Some are easier to spoof than others.
Consider the one-time link, like Slack’s magic link. In another instance, I was impressed how easy it was to authenticate myself on a new ChromeCast to activate different services, like youTube.
These additional factors were used to confirm my identity and authorizations: was I already permitted to access another system (email) or was I in the vicinity of a displayed link (ChromeCast and TV)? Very cool stuff.
For enterprises, it’s a little more complicated. As with consumer goods, there’s still a need to balance security with the user experience while accounting for the uniqueness of business requirements and the sensitivity of numerous, interconnected systems. And, machines used for automated business processes don’t have the means to relay the same additional factors that a human user might. How are these complexities being addressed today? Let’s explore the concepts of conditional access and the zero trust model.
Conditional Access
Spearheaded by Microsoft, Conditional Access (CA) is a means accounting for a user’s or entity’s context: the broker is aware of what device is being used to access what object, from where, and who is using it. For example, a traveling executive may be issued a temporary device from which to access certain company data considered relatively innocuous, and only for a certain period of time. Conditions are just additional factors, but can equal contextual challenges: the same traveling executive might face additional authentication steps to remotely access corporate data from an approved device, while an unenrolled device coming from the same location with the same credentials would be blocked. CA appears to be the MS implementation of taking more factors into account and can dynamically add identity factors to the mix or fingerprint a device (to either allow or disallow). The focus of CA remains on the human user.
Zero Trust
The OPM (series of) Breach(es) is one of many high profile loss events that teaches us what happens when weak AAA procedures are used or fail. You can read about it here. Of the key recommendations, the prompt to move to a zero trust (ZT) model is the most interesting, because of the lack of good precedent and the others are fairly boilerplate. This passage about ZT from the report is worth quoting at length:
To combat the advanced persistent threats seeking to compromise or exploit federal government IT networks, agencies should move toward a “zero trust” model of information security and IT architecture. The zero trust model centers on the concept that users inside a network are no more trustworthy than users outside the network. The zero trust model requires strictly enforced user controls to ensure limited access for all users and assumes that all traffic traveling over an organization’s network is threat traffic until authorized by the IT team. In order to effectively implement a zero trust model, organizations must implement measures to visualize and log all network traffic, and implement and enforce strong access controls for federal employees and contractors who access government networks and applications.
Real-time analysis of user / entity session activity is key to a smooth Zero Trust model implementation. With ZT, enterprises have no trusted zones or locations; AAA policies are applied evenly regardless of where the user or entity is located in the network or time and space. So, location is out as a primary factor. Furthermore, POLP is key: it’s important to articulate roles and permissions in the back-end, and to audit these user attributes on a routine basis. As previously stated, logging and the ability to act on alerting are essential.
PAN has a good getting started guide for those interested in ZT.
In a recent episode of Enterprise Security Weekly, the CISO of Aetna shared one vision of IAM in the enterprise. “Authentication was an event at the front end of the application… It [should] be based on behaviour and integrated in the entire lifecycle of the application so that a behavioural risk score is determining the risk at different junction points, alerting the app to determine how much functionality to serve up. It’s models driving the behaviour pattern and then identifying anomalies.” While not widespread, the concept of behaviour-based access control is receiving increased credence. By combining User and Entity Behaviour Analytics (UEBA) tools with access, enterprises can eliminate the password as one factor of identity.
Further reading
*Elsewhere, accounting is substituted when billing is a use case.
