Identity as the new perimeter

Objective 1.1 · Security Operations · 34% of the exam

Why this matters

When applications moved to SaaS and users moved off the corporate network, the thing that decides whether access is granted stopped being a firewall rule and became an identity check. An attacker with valid credentials and a valid session often needs no exploit at all — they log in.

That is why CS0-004 gives identity its own place in the architecture objective, and why identity events are some of the most productive detections available. It is also why so many real intrusions look boring in the logs: a successful authentication is the least alarming line in any log file.

This lesson is about learning to read that boring line properly.

The lesson

Directory services, federation and single sign-on

A directory holds the authoritative accounts, groups and attributes — Active Directory on premises, or a cloud identity provider. It is the source of truth for who exists.

Federation lets one system trust another's assertion about identity. Rather than every application holding its own password database, the application (the service provider) redirects to an identity provider, which authenticates the user and returns a signed statement: this is who they are, and here is what they are entitled to. SAML and OpenID Connect are the two protocols you will meet.

Single sign-on is what federation buys the user: authenticate once, reach many applications.

The security consequences are the point:

  • The identity provider becomes a single point of catastrophic failure. Compromise it and every federated application is compromised, without any of them being touched.
  • Trust is transitive and often invisible. Applications trust assertions they cannot independently verify.
  • Federation can be abused directly. An attacker with sufficient access to the identity provider can forge assertions for any user, and to the application those look completely legitimate — because they are correctly signed. Detections that watch only application logins will never see it.

Which is why the identity provider's own configuration changes — new trusts, new signing certificates, new federated domains — belong on the short list of events that always deserve attention.

Tokens, sessions and what a stolen one looks like

Modern authentication rarely sends a password to an application. It issues tokens.

  • An access token grants access to a resource for a short period.
  • A refresh token obtains new access tokens without re-authenticating, and lives much longer.
  • A session cookie keeps a browser authenticated to a web application.

The critical property: a token is a bearer credential. Whoever holds it can use it. It does not care which machine presents it.

This makes token theft the most consequential attack on identity today. Steal a session cookie from a browser — via malware, a malicious extension, or a proxy that sits in the middle of the login — and you inherit the session including its multi-factor authentication, because MFA happened before the token was issued. Prompting again is not part of using an existing token.

What theft looks like in the logs, and why it is subtle:

  • The authentication event may be entirely absent, because no new authentication happened.
  • The same session appears from a new address, network or country, often while the legitimate session is still active.
  • The user agent changes mid-session, or looks slightly wrong — an automation library rather than a browser.
  • Impossible travel, but on activity rather than login.
  • Sudden use of an API where the user only ever used the web interface.

The defensive counterpart is worth knowing for the exam: shortening token lifetimes, binding tokens to a device or client certificate, and — during an incident — revoking sessions rather than just resetting passwords. A password reset alone leaves live tokens working, which is one of the most common containment mistakes there is.

Privileged accounts and service accounts

Not all accounts are equal, and the exam expects you to treat two categories with particular suspicion.

Privileged accounts — domain admins, cloud subscription owners, security tool administrators — are the objective of most intrusions. They should be few, named, monitored closely, and separated from everyday accounts. An administrator reading email as a domain admin is an incident waiting to be dated.

Service accounts are the harder problem. They exist for software rather than people, and they are typically:

  • non-interactive, with no human to notice anything odd,
  • over-permissioned, because narrowing them risks breaking production,
  • given passwords that never rotate, because rotation risks breaking production,
  • excluded from MFA, because they cannot complete it,
  • and frequently exempted from the conditional access policies that protect everyone else.

That combination makes them ideal for an attacker: powerful, quiet, and unlikely to trip a control. The detections that matter are behavioural — a service account logging in interactively, from a new host, at a new time, or being used to access resources outside its normal set.

Modern platforms offer managed identities that remove the stored password entirely, and where they are available they close most of this off. Where they are not, the analyst's job is to know which service accounts exist and what normal looks like for each.

Conditional access and its failure modes

Conditional access evaluates signals at sign-in — user, device, location, application, risk score — and decides: allow, allow with additional requirements, or block.

It is genuinely effective. It also fails in ways worth memorising, because scenarios love them:

  • Exclusions become permanent. A group exempted for a migration two years ago is still exempt.
  • Legacy authentication protocols bypass it. Older protocols that cannot perform an interactive challenge often route around modern policy entirely; disabling them is usually the highest-value single change available.
  • Break-glass accounts are excluded by design, which is correct, and makes them the most valuable accounts on the tenant. They need compensating monitoring, always.
  • Location conditions are weak. An attacker who needs to appear local simply routes through a host that is.
  • Device compliance depends on enrolment, and an attacker can sometimes enrol their own.
  • Report-only mode is not enforcement. Policies left in evaluation mode look present in the console and block nothing.

The analyst's contribution is to check whether the control that "should have stopped this" actually applied to the account in question. Frequently it did not, and that is the finding.

Identity events worth alerting on

A short list that earns its noise, roughly in order of value:

  • Changes to the identity infrastructure itself: new federated domain, new signing certificate, changes to conditional access policy, new global administrator. Rare, high impact, almost always worth a human look.
  • Privileged group membership changes, especially outside change windows.
  • MFA method registration for an existing account — an attacker who has a password often adds their own second factor to keep access. This is one of the highest-signal, lowest-volume detections available.
  • Consent granted to a new application, particularly with broad permissions. Illicit consent grants give durable access that survives password resets.
  • Authentication anomalies on privileged accounts: new country, new device, new application.
  • Service account behaving interactively, or from an unexpected host.
  • A burst of failures followed by a success — the classic spray or credential-stuffing shape.
  • Repeated MFA prompts ending in an approval, which is fatigue attacking working as designed.
  • Disabled or dormant accounts suddenly authenticating.

What deliberately is not on that list: raw failed-login volume. Failures are constant, mostly automated and mostly irrelevant. The useful signal is the transition — failures that stop because one succeeded — which is a different query and a much quieter one.

You will meet these events again in the account-compromise lesson, where the question becomes how to tell a genuine compromise from a user having a bad day.

Topics this lesson owns

  • [x] Directory services, federation and single sign-on
  • [x] Tokens, sessions and what a stolen one looks like
  • [x] Privileged accounts and service accounts
  • [x] Conditional access and its failure modes
  • [x] Identity events worth alerting on

Practise what you just read

1. A service account that normally authenticates by key from one host is seen authenticating interactively at a console. What makes this a strong detection?

Select one

  1. Interactive logons are always higher risk than automated ones
  2. The account's authentication method changed, which its owner cannot explain
  3. Console logons bypass network controls and are therefore never logged
  4. Service accounts are forbidden from having interactive shells at all
Show answer

B. The rule works because it compares against the account's own established pattern rather than an absolute threshold. A service account exists to do one repetitive thing one way, so a different method is anomalous in a way that needs almost no tuning.

2. What most distinguishes password spraying from a brute force attack in authentication logs?

Select one

  1. Spraying produces far more failures in total than brute forcing does
  2. Spraying targets privileged accounts while brute forcing targets any account
  3. Spraying is wide and shallow, so the distinct account count is the signal
  4. Spraying always originates from a single source address, brute force many
Show answer

C. Both can produce similar total failure counts, which is why a threshold on failures alone catches one and misses the other. Spraying spreads a small number of attempts across many accounts, so the number of distinct accounts seeing a failure is what separates them.

3. Why is 'impossible travel' detection prone to false positives in many organisations?

Select one

  1. Authentication logs rarely record the source address of a successful logon
  2. Geolocation databases are updated too rarely to be useful for detection
  3. Most organisations lack the retention needed to compare two logons
  4. A single user with a laptop, a phone and a VPN produces the same pattern
Show answer

D. The pattern it detects is common in legitimate use: corporate VPN egress, mobile networks and cloud service endpoints all place a user somewhere they are not. Additional fields, such as device identity or whether the session used a known token, are what make the rule usable.

9 more questions on this objective are part of the full course.

Practise the full question bank in the exam simulator

Hands-on labs

All hands-on labs

Part of the free CompTIA CySA+ CS0-004 course — 40 lessons and 56 hands-on labs.

This is an independent study companion for CompTIA CySA+ CS0-004 and is not produced by or endorsed by CompTIA.