Chapter 7 — Identity and access foundations | Technologist Security operations and blue team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Identity and access foundations

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Authentication and authorisation"]
  N2["7.2 Least privilege"]
  N3["7.3 Shared accounts"]
  N4["7.4 Service accounts"]
  N5["7.5 MFA on remote access"]
  N6["7.6 Detecting misuse"]
  N7["7.7 Case improvement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Authentication and authorisation"]
  N2["7.2 Least privilege"]
  N3["7.3 Shared accounts"]
  N4["7.4 Service accounts"]
  N5["7.5 MFA on remote access"]
  N6["7.6 Detecting misuse"]
  N7["7.7 Case improvement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 Authentication and authorisation]
    |
    v
[7.2 Least privilege]
    |
    v
[7.3 Shared accounts]
    |
    v
[7.4 Service accounts]
    |
    v
[7.5 MFA on remote access]
    |
    v
[7.6 Detecting misuse]
    |
    v
[7.7 Case improvement]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) explain authentication, authorisation and least privilege; (2) describe shared and service accounts in small businesses; (3) apply MFA to remote access; (4) detect misuse of accounts.

7.1 Authentication and authorisation

Authentication proves who someone is; authorisation decides what they may do. A reception account should book appointments, not create administrator accounts.

In the BrightSmile incident both checks passed for the wrong person. Authentication succeeded because the attacker had the reception password, and authorisation allowed account creation because reception was a local administrator. Fixing either one would have limited the damage: a second factor stops the logon, and a lower privilege stops support2 being created. Copperleaf's later recommendations to BrightSmile address both checks separately, adding MFA to authentication and removing administrator rights from the reception account.

7.2 Least privilege

Each account gets only the rights it needs. At BrightSmile, the reception account was a local administrator because an old booking program once needed it — an excess privilege that let the attacker create support2.

The booking program that needed the right had long since been replaced, but nobody removed the privilege afterwards. Mei records this as a typical small-business gap: a right granted for one reason years ago outlives that reason, and only a review of who holds administrator rights brings it to light.

7.3 Shared accounts

Several receptionists share one "reception" login. Shared accounts make it impossible to tell who did what and often have weak passwords that everyone knows.

When reception logs on at 01:19, the log cannot say which receptionist it was, or whether it was a receptionist at all. A shared account also cannot be disabled quickly during an incident without stopping every reception desk, which makes containment harder on top of making attribution impossible. Personal accounts later solve both problems at once, since each receptionist can be identified and one account can be disabled without stopping the others.

7.4 Service accounts

Programs run under service accounts with fixed passwords. They should not be able to log on interactively.

The practice database, for example, runs under a service account whose password is set once and rarely changed. If that account is used to open an interactive logon on the server, it is almost certainly a person using stolen credentials, which is why Copperleaf alerts on it as a specific rule. Mei lists every service account found on CLINIC2-SRV in the inventory, with the program that uses it, so the rule knows exactly which accounts to watch.

7.5 MFA on remote access

Requiring MFA for remote desktop or VPN would have stopped the password-guessing attack even with a weak password.

In May the attacker needed only the reception password because remote desktop asked for nothing else. With a second factor, the correct password from the guessing list would still have failed at the next step, and the 01:19 success would have been another failure in the log. MFA does not make a weak password safe elsewhere, but on the remote access route it removes the attacker's main advantage, an unlimited number of guesses.

7.6 Detecting misuse

Rules alert on interactive logons by service accounts, logons by shared accounts outside opening hours and new administrator accounts.

Each rule follows from one of the gaps in this chapter. Service accounts should not log on interactively, the shared reception account should not be used in the middle of the night, and new administrators are rare at a clinic. Mei's worked example shows that even simple rules need tuning against real history before they go live. Each rule is documented with its purpose and the test result, so the next analyst knows why the rule exists before changing it.

7.7 Case improvement

After the incident, BrightSmile gives each receptionist a personal account, removes administrator rights from reception, and requires MFA on the new VPN.

Each of these changes closes one link of the chain used in May. Personal accounts make each logon traceable to a person, removing administrator rights stops a reception logon from creating accounts, and MFA on the VPN stops a guessed password from being enough. Remote desktop is no longer exposed directly, so the 3389 forward is gone. Mei updates the client inventory with these changes, so later alerts are judged against the new design rather than the old one.

Account reviews

Each quarter Copperleaf sends every client a list of accounts with administrator rights and asks them to confirm each one. At BrightSmile the first review removes three former staff accounts that were still enabled, closing doors nobody was watching.

Worked example

Mei writes a rule: alert when the "reception" account logs on outside 07:00–19:00 local time. Testing on a month of history shows two matches, both at 07:05 by the early receptionist — clocks differ slightly. She widens the window to 06:45 and documents why.

Synthetic case. Accounts and events are invented.

Errors and limits

Time-based rules break when business hours change; review them with the client.

Exercises

EX019 — Excess privilege. What excess privilege helped the attacker? Rubric: 3 = reception account was local admin; 2 = partial; 1 = vague; 0 = none.
EX020 — Shared account problems. Name two problems with shared accounts. Rubric: 3 = no individual accountability; weak known passwords; 2 = one; 1 = vague; 0 = none.
EX021 — Hours rule. How was the out-of-hours rule adjusted, and why? Rubric: 3 = widened to 06:45 after early receptionist matches; 2 = partial; 1 = deleted; 0 = none.

Synthesis

Least privilege, personal accounts and MFA reduce misuse; identity rules catch what remains.

Continue studying — chapter 07 of 30

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →