Identity is the control surface that matters most, because most intrusions are not break ins. They are logins. An attacker with a valid credential does not need an exploit, is difficult to distinguish from a user, and inherits whatever that account was permitted to do.
That last clause is why access management is inseparable from authentication. Preventing credential theft is worth a great deal. Limiting what a stolen credential can reach is worth more, because the first will eventually fail.
Least privilege, and why it decays
Least privilege means an account can do what its holder needs and nothing further. Every organization endorses it. Rather fewer sustain it, and the reason is structural rather than cultural.
Permissions accumulate because granting is easy and revoking is invisible. A person moves between roles and gains the new access without losing the old. A project needs temporary elevation that nobody removes. A group was created for one purpose and became the convenient way to grant several. Nobody is at fault at any step, and after three years a substantial share of accounts can reach things their holders have not needed for years.
The corrective is not a one off cleanup, which produces a good month followed by the same decay. It is a recurring review with a default of removal, which is discussed below.
Authentication: what multifactor actually buys
Multifactor authentication is the single highest value control most organizations can deploy, because it breaks the economics of credential theft. A password harvested by phishing stops being sufficient.
NIST frames the requirement in terms of factors rather than products: at the higher assurance level, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocols. Distinct is the operative word. Two things the user knows are not two factors, and a code delivered over a channel an attacker can redirect is weaker than a factor bound to a device.
The practical failure is rarely absence and usually coverage. Multifactor is enabled for most users, with exclusions: the legacy application that cannot support it, the service account, the executive who found it disruptive, the emergency access account, the third party contractor. Every one of those exclusions is where an attacker will look, and an organization reporting high multifactor coverage without naming its exclusions is reporting an average rather than a posture.
Phishing resistant methods materially change the picture where they can be deployed, because they remove the interception that defeats a code based factor. Where they cannot be deployed everywhere, deploying them for administrators first is the highest value ordering.
Privileged accounts
Administrative accounts deserve separate treatment because compromising one usually ends the argument. The practices that matter are well established and unevenly applied.
Administrators should hold a separate account for privileged work rather than elevating their daily account, so that routine browsing and mail do not occur in a session that can rebuild the domain. Privileged access should be time bound where the platform supports it, so that standing administrative rights become requested rights with a reason attached. Administrative sessions should originate from controlled workstations rather than from whatever machine is convenient. And privileged actions should be logged somewhere the account holder cannot alter.
Emergency access accounts are a special case worth naming. Every environment needs a route back in when the identity provider fails, and that route is by definition exempt from the usual controls. It should exist, be documented, have credentials split or escrowed, and be monitored such that any use raises an immediate alert. What it should not be is undocumented and shared, which is the common state.
The account lifecycle
Joiners, movers and leavers is an unglamorous process and is where most access problems originate.
Joining is usually handled well because somebody is waiting to work. Leaving is handled adequately when it is planned and poorly when it is not, and the gap between a departure and a disabled account is a window in which a credential exists with nobody accountable for it. Moving is handled worst of all, because there is no trigger: nothing fails when old access is retained, so nothing prompts its removal.
The fix is to make movement a trigger with the same force as departure, which usually means driving the process from the authoritative people system rather than from a helpdesk ticket. Where that link does not exist, the compensating control is the access review.
Access reviews that are not theater
Periodic access review is a control that frequently exists and frequently achieves nothing, because a manager presented with a list of eighty entitlements they do not understand will approve all of them.
Three things make a review real. Scope it by risk, reviewing privileged and sensitive access more often and more carefully than general access, rather than reviewing everything shallowly. Present it in terms the reviewer understands, describing what the access permits rather than naming a group. And default to removal, so that a non response revokes rather than retains.
That last change alters the outcome more than any tooling, because it moves the burden onto retaining access rather than onto removing it.
Service accounts and other non human identities
Non human identities now outnumber human ones in most environments, and they are subject to none of the lifecycle controls above. Nobody leaves the organization, so nothing triggers a review.
Service accounts typically hold broad standing privilege, use credentials that never expire because rotation risks an outage, are shared between systems because that was expedient, and are excluded from multifactor because they cannot present a second factor. Each of those is individually defensible and collectively produces the most attractive target in the environment.
What helps is ownership, so every service account names a person and a system; scoping, so it holds only the permissions its function needs; platform managed identities where available, which remove the stored credential entirely; and a rotation process that has been tested rather than theorized. Cloud environments make the good option available far more often than on premises ones, which is discussed in cloud security.
Authorization, and the model behind it
Authentication establishes who. Authorization decides what they may do, and it is the half that ages badly. Role based models work well when roles reflect how the organization actually operates and poorly when they were derived from an organizational chart that has since changed.
The useful discipline is to review the model itself occasionally, not merely the memberships within it. A role that has accumulated permissions for three different job functions is no longer a role, and reviewing its membership will not reveal that.
Third parties, contractors and federated access
External identities are the category most likely to sit outside whatever process the organization has built, because they were provisioned by an exception.
A supplier needs access for an implementation and receives an account. A contractor joins for six months and is created manually because the people system does not hold them. A partner organization is federated so its users can reach a shared system. In each case the account exists outside the joiner and leaver process that governs employees, and nothing signals when it should end.
Three habits address most of it. Give every external account an expiry date at creation, so that continuation is a deliberate act rather than the default. Name an internal sponsor who is accountable for whether the access is still needed, because the supplier will not volunteer that it is not. And scope the access to the specific system rather than granting a general account, which is the path of least resistance and the one that turns a supplier compromise into yours.
Federated access deserves particular care, because trusting another organization's identity provider means inheriting its authentication standards. If the partner does not enforce multifactor, neither do you for those users, regardless of your own policy. That is worth knowing before the federation is configured rather than after an incident traces back through it.
Identity in a zero trust posture
Zero trust is frequently described as a network idea and is substantially an identity one. NIST is explicit that in such an architecture there is no implicit trust granted to assets or user accounts based solely on their physical or network location.
If location confers no trust, identity carries the weight that the perimeter used to. That raises the stakes on everything above, and it is why identity controls tend to be the first thing examined during an assessment. The network side of the same posture is covered in network security.
Running it as a service
Identity administration is continuous and is rarely anybody's whole job, which is the standard condition for decay described in the managed cybersecurity lifecycle.
LABUSA operates account lifecycle, privilege review, authentication standards and service account hygiene within the LABUSA managed security service, and the monitoring that detects misuse of a valid credential is covered in security monitoring and incident detection.
Sources
- NIST, Digital Identity Guidelines: Authentication and Lifecycle Management, SP 800-63B.
- NIST, Zero Trust Architecture, SP 800-207, August 2020.
- NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.