Whose Rules Are These?
Most access-boundary detection ships somebody else's org chart as a rule and reports your firm for not matching it. Chronolith learns what your estate actually does, and tells you when that changes.
In short
- No policy is hardcoded. The product does not assume how your firm is organised, because that assumption is always somebody else's firm.
- Boundaries are observed, not declared. A boundary that exists shows up as a combination that never happens — and the first time it happens is the finding.
- The same code is correct for a firm of six and a firm of eight hundred, and neither had to answer a question.
- Asset and account inventory builds itself from what is actually seen, with directory information layered on where it exists.
- A failed query never looks like a clean estate — the difference is enforced, because here it would produce a wave of false findings.
The tiering model that is right for exactly one customer
The obvious way to detect access-boundary violations is to write down a model — domain administrators never touch workstations, helpdesk never touches production — and alert on departures from it.
That model is real, and it is well run at some sites. It is also precisely what must not be hardcoded, because it is one organisation's policy rather than a law of nature.
One administers databases from a dedicated tier your vendor has never heard of. One has a single administrator who does everything from a laptop and is not wrong, merely small. One outsources entirely and every privileged action comes from a supplier's account.
Ship one firm's org chart as a detection rule and every other customer receives findings that describe somebody else's company.
Report what the estate does; compare it with what it used to do
A boundary that genuinely exists in your firm appears in the data as a combination that never occurs. The first time it occurs is the finding — phrased in the estate's own vocabulary rather than a framework's.
A boundary that does not exist is simply part of the baseline, and never fires. That is why the same logic is correct for a firm of six and a firm of eight hundred, without either being asked to describe itself.
A question nobody answers becomes the configuration permanently. Ask a six-person firm to define its privilege tiers and you will get an empty form — and a detection that therefore never works. Derive it instead and the detection works on day one, everywhere.
An asset list that maintains itself
Estate inventory is assembled from what is observed, enriched with directory information where a directory exists, and annotated by hand where somebody wants to.
- Hosts appear because they generated activity, not because somebody added them. A machine nobody documented shows up the first time it does anything.
- Accounts are classified — administrative, service, standard — seeded automatically from directory attributes and correctable by hand, with the manual classification winning permanently.
- Machine roles are inferred from what a machine does, so “workstation” and “server” mean something without anyone maintaining a list.
- Contact details come with the account. Desk and mobile numbers are read from the directory, so an alert whose correct response is ring this person and check arrives knowing the number. Looking it up mid-incident is minutes spent at the worst possible moment.
- Newly appearing hosts are a finding, because on a small estate a machine you did not know about is worth thirty seconds of attention.
A phone number is read at the moment somebody asks for it and is not copied onto the alert record. Two reasons, pointing the same way. Alert records feed the compliance report and the insurance renewal pack and are archived for years — a staff mobile number does not belong in a document an underwriter reads. And a stored number is the number as it was: whoever is ringing wants the one that works now, because a stale copy sends them to a dead line while they believe they tried.
It is also a deliberate action rather than a column on every list. A page of two hundred alerts does not put staff numbers on screen for people who did not ask.
An inventory built from observation only contains what reported. Where a directory is available, machines present there but silent here are listed as not reporting rather than omitted — because the machine missing from your monitoring is the one worth asking about.
Why a database hiccup must not become a security incident
Learned baselines have a specific and severe failure mode: if the baseline query fails and returns nothing, every combination looks brand new.
A momentary database problem would produce first-time-seen findings across the entire estate — every account, every machine, all at once. The operator's rational response is to distrust the feature permanently, and they would be right to.
So an unavailable baseline is explicitly not an empty one. The detector stays silent and reports that it could not establish a baseline, rather than treating an absence of history as a history of absence. This distinction is enforced by an automated check across the whole product before every release.
Common questions
How long before it knows what normal looks like?
Enough activity has to accumulate for a combination's absence to mean something. The product reports that it is still establishing a baseline rather than reporting a clean estate — an empty result from an empty baseline is not a clean result.
What if our normal is bad?
Then it is learned as normal, and this capability will not tell you otherwise. It detects change, not badness. Concrete misconfigurations — a share open to everyone, an account whose password never expires, remote access exposed externally — are covered by checks that do make judgements, and those are deliberately separate from this.
Does it need Active Directory?
No. A directory improves classification, supplies the contact numbers an incident response needs, and lets the product tell you which machines are not reporting. Without one, inventory is built purely from observation, and the product says so rather than presenting a partial view as complete.
Can we tell it our own tiering model?
Account classifications can be set by hand and those choices are respected permanently. A full policy model is not something we ask for, because the firms this is built for do not have one written down — and a product that requires one simply does not work for them.