Endpoint Security Maturity Model

Introduction

A maturity model turns a set of technical states into something a person outside the team can act on. It is useful for exactly that and misleading everywhere else.

This section gives you five levels defined as configuration rather than as adjectives, a way of scoring each layer separately, and the mapping to the two frameworks somebody will eventually ask you about. It also names the number that is routinely quoted as a maturity level and is not one.

You will finish able to produce a score you can defend line by line from readings you have already taken, say why a single figure for an estate hides the thing that matters, and answer the question about frameworks without conceding that your score means something it does not.

Most maturity models fail the same way. They describe levels in words like ad hoc, repeatable and optimized, and two competent people reading the same estate produce different answers with no way to settle it. A level worth using is one where the criteria are configuration states somebody can go and read.

PS C:\> $p = Get-MpPreference
PS C:\> ($p.AttackSurfaceReductionRules_Actions |
             Where-Object { $_ -eq 1 }).Count
3
PS C:\> (Get-MpComputerStatus).AMRunningMode
Normal

Two commands and a level three claim is either supported or it is not. That is what a checkable criterion buys: being challenged becomes a matter of running something rather than a matter of opinion.

That constraint is what makes the model survive contact with a review. If level three means every attack surface reduction rule your audit data supports is in block mode, that is a claim with an answer, and being challenged on it is a matter of running a query rather than a matter of opinion. If level three means proactive, the challenge has nowhere to go and the model becomes a thing your team asserts about itself.

It also decides whether the model can be used to plan. A level defined by a configuration tells you what would have to change to reach the next one, because the difference is a list of settings. A level defined by an adjective tells you nothing about how to move, which is why those models get produced annually and acted on never.

One more property separates the two, and it only shows up a year later. An adjective cannot be compared with itself. Told that the estate was developing last year and is developing now, nobody can say whether anything happened, and the natural response is to change the adjective rather than the estate. Five numbers taken the same way twice tell you what moved, and they tell you that even when the answer is nothing, which is the case a maturity report is least willing to state and most needs to.

This is also why the criteria have to be written down before the scoring rather than derived from it. A model whose definitions are settled after the readings are in will be settled, unconsciously and by reasonable people, at whatever makes the current position defensible. Write the five levels once, get them agreed, and score against them afterwards.

The second version is also harder to present and that is the real reason the first survives. Somebody has to be willing to say a set of numbers out loud to a person who wanted a reassuring adjective, and the rest of this section is about doing that in a way that gets you a decision rather than a difficult meeting.

The levels below are cumulative, so each assumes everything under it. They are written against the five layers from ES0.3 and every criterion is something you have already been shown how to read.

Level one is licensed and installed. Antivirus present, sensor perhaps deployed, defaults everywhere, no configuration decisions taken. This is the estate ES0.6 describes and it is where most organizations sit when somebody first asks the question.

Level two is visible. Every device onboarded and reporting, telemetry landing, policy reaching the fleet, and the readings from ES0.5 all returning. Nothing is enforced yet and that is correct: this is the level at which decisions become possible rather than guesses.

Level three is enforcing. The standard protection rules in block, every other rule that audit data supports promoted, exclusions written per rule with owners, and hardening deployed. This is the level most estates should be targeting and the one that removes the most risk per unit of effort.

Level four is detecting. Custom detections written for the estate's own patterns, tuned against a true positive rate, technique coverage measured against a threat model that exists on paper, and response automation chosen per alert class rather than per tenant.

Level five is adaptive. Detections reviewed against emerging technique intelligence, exclusions carrying removal conditions and actually being removed, and the whole set re-measured on a cadence rather than when somebody asks.

Notice that the jump from one to two produces no protection whatever and is still the largest single step available, because nothing above it can be decided without it. That is the same argument as gate one in ES0.7, arriving as a level rather than as a sequence.

The criterion that decides each level, per layer

  LEVEL  HARDENING        PREVENTION      DETECTION       READINESS
  1      defaults         installed       sensor only     nothing
  2      baseline         rules deployed  telemetry       partial
           assigned         audit only      lands           logging
  3      LAPS, baseline   audit-supported  built-in        logging
           enforcing        rules in block   analytics       complete
                            per-rule excl    tuned           and verified
  4      exceptions       promotion queue  custom rules,   evidence
           owned, dated     empty            TP rate,        tested in
                                             coverage        an exercise
  5      exceptions       exclusions       reviewed        readiness
           removed on       removed on       against new     re-measured
           condition        condition        intel           on cadence

Read down a column, not across a row. Layers move independently.

Read the readiness column against the others. It reaches level three with a configuration and level four only when somebody has tried to use the evidence in an exercise, which is the one criterion in this table that cannot be satisfied by a setting. That is why it is the layer most estates score lowest and the one they discover last.

Two things about the levels are worth stating before anybody uses them. They are cumulative, so an estate with excellent custom detections and no onboarding across a third of its fleet is not at level four with a gap; it is level one for that third, and a fleet's level is that of its weakest population rather than its best. That reads as pedantry until the population behind is the one an operator reaches.

The criteria are also about state rather than intent. A rule scheduled for promotion is auditing today, an exclusion somebody means to narrow is wide today, and a detection written and not deployed catches nothing today. Scoring intent is how a model drifts from the estate it describes, gradually, because each individual optimism is reasonable.

An estate does not have a maturity level. Its layers do, and they are usually two or three levels apart, so any single figure is an average across states that need completely different work.

Northgate is the ordinary shape. Prevention is licensed and unconfigured, detection has telemetry and no rules, response has every action available and no decisions about them, and readiness does not exist. Averaging that to level two produces a number that is defensible, uninformative, and hides that one of the five cannot be fixed after an incident starts.

Northgate, scored per layer

  LAYER                LEVEL   THE ONE THING THAT SETS IT
  hardening                1   no LAPS, ASR audit only, defaults
  prevention               2   rules deployed, 3 of 18 enforcing
  detection                2   telemetry lands, 0 custom rules
  response                 2   actions available, no automation
                               decision per alert class
  forensic readiness       1   script block logging unconfigured

  average                1.6   a number that describes nothing
  lowest                   1   two layers, and one of them is the
                               only layer you cannot fix later

Report the profile rather than the average, and report the lowest layer first. The average invites the response that things are broadly on track; the profile invites a question about the lowest number, which is the conversation you wanted. It also happens to be more honest, because an average of five layers moves when the easiest one improves.

There is a further reason to score separately, which is that the layers are not equally expensive to move. Hardening from one to three is policy changes with no purchase. Detection from two to four is continuing engineering effort with no end date. Presenting those as one number implies they can be planned as one piece of work, and they cannot.

The profile also changes what a follow-up looks like. Given one number, the next question is whether it went up. Given five, the next question is about a specific layer, and that question has an owner, a cost and a next action attached to it. Getting asked a harder question is the outcome you want here, because the alternative is a conversation that closes without a decision.

Score the layer at its weakest criterion rather than averaging within it too. Prevention with rules enforcing and exclusions that are all global is not partway to level three, it is level two with a quality problem, and recording it as two-and-a-half loses the thing an engineer would act on.

Half-levels are worth refusing generally, not just here. They feel more precise and they are less useful, because a half is a way of recording that a criterion is partly met, and a criterion that is partly met is a criterion that is not met with a note explaining why. Write the note.

Nothing in this scoring needs a new tool or a new query. Every criterion resolves to a reading from an earlier section, which is deliberate: a maturity assessment that requires its own data collection exercise gets done once.

// Level 2 evidence: is the fleet visible, and how much of it
DeviceInfo
| summarize LastSeen = max(Timestamp) by DeviceName, OSPlatform
| summarize Devices = count(),
            Reporting = countif(LastSeen > ago(7d))
            by OSPlatform

That query answers level two on its own, per platform, which matters because the platform breakdown is usually where the failure hides. An estate reporting ninety per cent overall can be at level two for Windows and level one for macOS, and a single figure conceals a whole population.

PS C:\> $p = Get-MpPreference
PS C:\> [pscustomobject]@{
            RulesEnforcing = ($p.AttackSurfaceReductionRules_Actions |
                                Where-Object { $_ -eq 1 }).Count
            RulesAuditing  = ($p.AttackSurfaceReductionRules_Actions |
                                Where-Object { $_ -eq 2 }).Count
            PerRuleExcl    = $p.AttackSurfaceReductionRules_RuleSpecific`
                                Exclusions.Count
            GlobalExcl     = $p.AttackSurfaceReductionOnlyExclusions.Count
        } | Format-List

RulesEnforcing : 3
RulesAuditing  : 13
PerRuleExcl    : 0
GlobalExcl     : 2

Four numbers and the level falls out of them. Three enforcing is above zero, so prevention has left level one. Thirteen auditing means the promotion work is unfinished, so it has not reached level three. And zero per-rule exclusions against two global ones is the ES0.7 finding: the exclusions that exist are wider than they need to be, which is a level three criterion failing on quality rather than on count.

Take the reading on a sample across sites, images and hardware generations rather than on one machine. Every failure mode in this module clusters that way, and a score taken from a single well-managed laptop is a score of that laptop.

Record the readings themselves alongside the score, not just the level they produced. A score with its evidence attached can be re-derived by somebody else and re-run next quarter to see what changed; a score without it has to be redone from scratch every time, which is the practical reason maturity assessments are annual rather than quarterly. The evidence is four or five command outputs and a query result, which fits on a page.

Two of the five layers cannot be scored from a device at all, and it is better to say so than to invent a proxy. Response maturity is about whether automation decisions exist per alert class, which lives in a portal setting and in whether anybody made the decision. Readiness has a device reading for the logging and no reading at all for whether anybody has ever tried to use it. Score those from the artifacts they produce, a configuration page and a post-incident report, and mark them as such.

The other reason to keep the raw readings is that criteria change. If you decide next year that level three also requires tamper protection everywhere, having last year's readings means you can restate the old score against the new criteria rather than comparing two numbers that meant different things.

Sooner or later somebody asks what your level maps to, usually because an auditor or a customer questionnaire wants a framework name. Two answers cover almost every version of that question and one of them contains a trap.

The Center for Internet Security's controls are prescriptive: eighteen controls, each broken into safeguards, grouped into three cumulative implementation groups. IG1 is essential hygiene and is described as implementable without a dedicated security team. IG2 assumes somebody whose job includes operating security controls. IG3 is for organizations facing targeted attacks. The selection is about organizational capacity rather than headcount, which is why an eight-hundred-person engineering firm with one part-time security person is honestly an IG1 organization whatever its size suggests.

The NIST Cybersecurity Framework is the other, and it is outcome-based rather than prescriptive: it organizes a program into functions, Govern, Identify, Protect, Detect, Respond and Recover, and describes what a mature program achieves without naming the controls that achieve it. Version 8.1 of the CIS controls carries an official mapping to it, which is what lets one body of evidence answer both.

The practical use of the mapping is narrower than it looks and is worth being clear about. It lets one set of evidence answer several questionnaires and it does not tell you what to do next. The thing that tells you what to do next is the layer with the lowest number, which came out of your own readings rather than out of anybody's framework.

It is worth knowing why the two frameworks exist side by side rather than one having won. The prescriptive one tells you which safeguards to implement and in what order, which is what an engineer needs and what a board cannot act on. The outcome-based one describes how a program is organized and governed, which is what a board needs and what an engineer cannot deploy. An organization using both is not duplicating effort; it is answering two questions that genuinely differ.

For this course the useful consequence is narrow. Neither framework replaces the five readings, both can be answered from them, and if a questionnaire arrives that cannot be answered from your readings then the honest response is that you do not know rather than an estimate that later becomes a commitment.

Level three is the right target for most estates and level five is right for very few, and stating that plainly is more useful than an aspirational roadmap nobody funds.

The reason is the shape of the effort. Reaching level three is bounded work with an end: a set of promotions, a set of exclusions, a hardening baseline, and then it is done and stays done with maintenance. Level four and above are continuing commitments, because a detection estate that is not being tuned degrades, and coverage measured once is coverage measured never. Committing to a level you cannot staff produces an estate that reached level four briefly and is now at level two with a lot of stale rules in it.

// Is your detection layer a standing capability, or was it a project?
DeviceEvents
| where Timestamp > ago(180d)
| where ActionType == "CustomDetectionMatch"
| summarize Matches = count() by bin(Timestamp, 30d)
| sort by Timestamp asc

A result that falls away after the first two bins is the signature of a level four that was reached and not staffed. It is the cheapest way to find out whether the rented half was ever actually rented.

That distinction is the one to put in front of whoever funds it. A request to reach level three is a request for a piece of work; a request to reach level five is a request for a role, and the two get approved by different mechanisms and different budgets. Asking for the second while describing the first is why maturity programs stall a year in.

There is one circumstance where aiming higher than three is right, and it is worth naming so the advice does not read as a ceiling. Where an organization is genuinely a target rather than incidentally exposed, the detection layer is not optional and level four is the floor rather than the aspiration. The test is not company size or sector; it is whether anybody has attempted something specific against you, which is a question your incident history answers and a framework does not.

The failure to avoid in either direction is the same: choosing a target because it sounds appropriate. Three because it is achievable and five because it is impressive are both answers to the wrong question, and the right one is which layers your own threat picture requires and which of those you can staff.

The model has to serve two conversations that want different things, and the mistake is producing two documents rather than one document read two ways.

An executive wants the position, the direction and the ask. Prevention is at two, the target is three, here is what that takes, and here is the date I will report against it. They are not being simplistic in wanting that; they are being asked to allocate against several such requests and the layer profile is what makes yours comparable to the others.

Endpoint posture, Northgate, 30 September

  hardening             1   no LAPS; one local admin credential
                            authenticates on every workstation
  prevention            2   3 of 18 enforcing; servers passive
  detection             2   telemetry on 712; 0 custom rules
  response              2   all actions available; no decision
                            recorded per alert class
  forensic readiness    1   command line on; script block unset;
                            last incident produced no conclusions

  lowest layer          readiness. cannot be improved after the fact.

That is the whole document, and it fits on a page because each line is a number and the reading behind it. Both versions above are written from this, and if either stops being derivable from it, the profile has become a presentation.

An engineer wants the criterion that is failing. Not that prevention is at two but that thirteen rules are auditing and the promotion queue is ordered by event count, which is a work item rather than a status. Both readings come from the same five numbers, and that is the property worth protecting: the moment the executive version stops being derivable from the engineering version, the model has become a presentation.

Both audiences also need the same thing said about the lowest layer. If readiness is at level one, the executive needs to know it is the only layer that cannot be improved retrospectively and the engineer needs to know it is a policy change with a storage cost. Neither of those is a rating and both come out of the same row.

There is a third audience worth preparing for even though they arrive rarely, which is somebody external: an auditor, a customer's security team, or an insurer. They want the evidence rather than either summary, and the thing they are actually testing is whether the two versions above reconcile. A profile whose executive summary cannot be traced to a reading is the finding, regardless of what the numbers say.

Keep the numbers identical across both and resist rounding for the executive version. A profile that is derivable in one direction only is a profile somebody will eventually check, and the value of this whole exercise rests on it surviving that.

The next section turns the whole model around and looks at the same estate from the other side, asking which of these levels an attacker would notice and which they would not.