MFA, and protecting administrative access

Why this matters

Administrative accounts are the most valuable thing an attacker can steal. An administrator can read any data, create accounts, disable security tools and delete backups, so attackers who get into a network with an ordinary account spend their effort trying to become one. Ransomware attacks that encrypt whole organisations nearly always involve stolen administrative credentials.

The previous lesson limited what each account can do. This one protects the accounts that can do the most: proving identity with more than a password, keeping administrative rights off everyday accounts, controlling where administration happens from, setting sensible password rules, and centralising sign-in so all of this can be enforced in one place.

The lesson

Authentication factors and multifactor authentication

Authentication proves that someone is who they claim to be. The evidence falls into categories called factors:

• Something you know: a password, passphrase or PIN.
• Something you have: a smartphone running an authenticator app, a hardware security key, a smart card or a token.
• Something you are: a biometric, such as a fingerprint or face, as in the physical access lesson.

Some schemes add somewhere you are, a location or network, and something you do, such as a typing pattern, as supporting signals.

Multifactor authentication (MFA) requires evidence from two or more different categories. A password plus a code from a phone app is MFA. Two passwords are not, because both are something you know, and a keylogger or phishing page that captures one captures both.

MFA's value is that stolen passwords stop being enough. A phished password is useless without the phone or key. Methods differ in strength: SMS codes are better than nothing but can be intercepted or redirected by taking over a phone number; authenticator apps are stronger; and hardware security keys using FIDO2 are strongest, because they are tied to the genuine site and cannot be phished. For administrative access, MFA should be treated as mandatory.

Separate privileged accounts from everyday ones

Administrators should not use their administrative account for everyday work. Each administrator has two accounts:

• a standard account for email, web browsing, documents and chat;
• a separate privileged account, used only for administration.

The reason is exposure. Email and web browsing are how most malware arrives. If an administrator opens a malicious attachment while logged on with domain administrator rights, the malware runs with those rights. If they open it with a standard account, it gets a standard account's access, and the privileged account's credentials were never on that machine to steal.

Further measures build on the same idea:

• Privileged accounts should not have email, and should not be used to browse the web.
• Administrative rights can be tiered, so an account that administers workstations cannot log on to domain controllers.
• Privileged access management (PAM) systems go further, granting administrative rights just in time for a specific task and removing them afterwards, and recording what was done.
• On Linux, administrators log on as themselves and use sudo for individual privileged commands, rather than logging on as root. sudo records who ran what, which a shared root password never can.

Jump boxes and bastion hosts

Where administration happens from matters as much as who does it. If administrators can manage servers from any workstation, every workstation is a path to the servers.

A jump box, or jump server, is a hardened server used as the single point from which administration happens. Administrators connect to the jump box first, using MFA, and from there to the servers they manage. The servers' firewalls accept management connections, such as RDP and SSH, only from the jump box.

A bastion host is the same idea at a network boundary: a hardened, heavily monitored host exposed to an untrusted network, such as the internet, providing the only way in to a protected one. In cloud environments, a bastion host or a provider's managed bastion service is the standard way to reach virtual machines that have no public addresses.

A jump box concentrates risk as well as control, so it must be hardened, kept patched, restricted to administrators, protected with MFA, and its sessions logged. Privileged access workstations, dedicated and locked-down machines used only for administration, extend the same thinking to the administrator's own device.

Password policy and account lockout

Passwords remain part of most authentication, so their rules matter. Current guidance, including the US NIST digital identity guidelines, has moved away from some traditional rules:

• Length matters most. Longer passwords and passphrases are much harder to crack than short, complex ones, so set a generous minimum length.
• Check against known breached passwords, and reject common ones.
• Avoid forced periodic changes for ordinary users unless a compromise is suspected. Frequent forced changes lead people to predictable patterns, such as adding a number to last month's password.
• Never reuse a password across systems, especially administrative ones, and use a password manager or vault to make that practical.

Password rules are applied centrally, through Group Policy or fine-grained password policies in Active Directory, or PAM configuration on Linux.

Account lockout defends against guessing by locking an account after a number of failed attempts, a threshold, for a set duration. It has a trade-off: a threshold that is too low locks out users who mistype, and lets an attacker lock out accounts deliberately, a denial of service. A moderate threshold, with monitoring of repeated failures, balances the two. Failed logon events are also an important signal for the SIEM, covered later in this domain.

Single sign-on and directory services

With dozens of systems, separate accounts on each would mean dozens of passwords, each managed separately and each forgotten when someone leaves.

Directory services, such as Active Directory and LDAP directories, store identities centrally: users, groups, passwords and policies. Servers and applications that trust the directory authenticate against it, so there is one account per person, disabled in one place.

Single sign-on (SSO) builds on this so users authenticate once and then reach many systems without signing in again. Inside Windows networks, Kerberos does this: after logging on, users receive tickets that prove their identity to other servers. For web applications and cloud services, federation protocols such as SAML and OpenID Connect let an identity provider vouch for users to other services.

SSO helps security as well as convenience. MFA and password policy can be enforced once, at the identity provider, and apply everywhere. Disabling one account removes access to every connected system at once. The corresponding risk is that the identity provider becomes critical: it must be highly available, and its administrative accounts are among the most important in the organisation to protect.