Every attack has a tell.

What TillTell sees

Each product writes an event with the same shape: who (a user, a service or an unknown caller, with the address and country when known), did what (an action such as auth.login_failed or secret.reveal), to what, with what outcome. Two fields matter for trust:

• trust is server when a Till service recorded the event itself and client when an app SDK or the endpoint agent reported it. Most library rules demand server evidence; a rule that would revoke or block never fires on a client-reported record.
• drill marks traffic from a labelled exercise. Drill findings prove a rule sees the pattern; they never alert and never count toward a rule’s record.

Events are kept for detection and hunting for the workspace’s retention tier: 30, 90 or 400 days. Change it under Shield → Settings → TillTell; it applies to events recorded from then on.

The rules that ship

Every rule names the ATT&CK technique it covers, the false positives to expect, a playbook it would suggest, and fixtures that must both fire and stay quiet before it ships. Some rules match one event; others correlate a burst, an order of events, a count of distinct values or a first-time value per account. The library today holds 62 rules:

Open any rule on the rules page or with tilldev shield tell rules show to read its YAML, its fixtures and its record in your workspace. The tell-host- rules read events from the endpoint agent; the tell-insider- and tell-service- rules watch your own members and credentials, and Insider risk ranks who set them off.

Rules of your own

A workspace can add up to 100 rules of its own, in the same format, held to the same tests, and run on the same stream. Write one from scratch, or copy a library rule and tune it, then try it on your recent events before it runs. See Writing TillTell rules.

Stages: a rule earns its way

Every rule is at one of four stages in your workspace. New library rules and new workspace rules start in shadow.

Owners and admins move rules up. The system only ever moves a rule down, and only for one reason: too many false positives. When 20% or more of the last 20 triaged findings were judged false positive or benign (once at least 10 have been triaged), the rule falls back to shadow and the move is written to the workspace audit log with the numbers behind it.

Unattended playbooks

A live rule may run its playbook without a person once it has earned it: 30 or more triaged findings, 5% or fewer false positives, and none in the last 10. Even then two humans stand in the way: the workspace switch under Shield → Settings → TillTell must be on, and an owner or admin confirms automation for that rule. A demotion clears the confirmation. Both thresholds can be overridden per workspace and per rule through the API.

Triage feeds the lifecycle

Every finding takes a verdict from any member of the workspace. Verdicts are appended, never edited, so a rule’s record is a history nobody can tidy up after the fact.

The ATT&CK map, scored honestly

Shield → TillTell → Coverage lays out the MITRE ATT&CK Enterprise and Mobile matrices by tactic and scores every technique against the rules running in your workspace. A rule counts once it is out of draft; a draft runs nowhere, so it covers nothing.

Prove a rule with a defense drill under Shield → TillDrill. Changing the rule takes its proof away until it is drilled again.

What your sources can see

ATT&CK says which kinds of records each technique is detected from. TillTell checks that against the Till products that have written to your security stream in the last 90 days. Techniques none of them can see are faded rather than counted as gaps, and the ones they can see with no running rule are listed as gaps, each naming the Till product whose records would make it visible. Techniques only a host can show, such as process execution and persistence, stay faded until the endpoint agent reports from your hosts: the map never claims what the stream cannot observe.

Incidents no rule saw

A technique also carries the number of real incidents from the last 180 days that were resolved with it and had no TillTell finding in them. That is the rule backlog laid on the map: detection you needed and did not have.

From the terminal

# what fired, newest first (open findings by default)
tilldev shield tell findings
tilldev shield tell findings --rule tell-cred-stuffing --stage live --json

# read one, with its record and evidence, then judge it
tilldev shield tell finding <id>
tilldev shield tell verdict <id> fp --note "shared office egress during a password reset"
tilldev shield tell escalate <id>          # open an incident from it, or show the one it is in

# the library and your own rules as your workspace runs them
tilldev shield tell rules ls
tilldev shield tell rules show tell-secret-mass-read
tilldev shield tell rules stage tell-cred-stuffing advisory --reason "two weeks clean in shadow"
tilldev shield tell rules automate tell-cred-stuffing

# rules of your own: check, try on recent events, save
tilldev shield tell rules validate rule.yaml
tilldev shield tell rules backtest rule.yaml --hours 72
tilldev shield tell rules create rule.yaml

# the ATT&CK map, and the techniques you can see but don't cover
tilldev shield tell coverage
tilldev shield tell coverage --domain mobile
tilldev shield tell coverage --gaps

# retention and the unattended-playbook switch
tilldev shield tell settings
tilldev shield tell settings set --retention long --automation

The same operations are on the HTTP API under /api/shield/tell/…, documented in the API reference. Stage changes, automation confirmations, verdicts, settings changes and every change to a workspace rule land in the workspace audit log.