How Signal works

The five steps#

1. 1. Read what Windows recorded

   Signal reads the host's own records: event logs, the registry, the service and process tables, scheduled tasks, Prefetch, browser databases, antivirus status and more. Each source is read once per run, and shared by every module that needs it.

2. 2. Turn records into evidence

   Each record becomes a piece of evidence of a known type - a process_creation, a logon, an autostart entry - with named fields such as process.name or account.sid. The same thing seen in two places (a service in the System log and in the service table) is merged into one record that names both sources.

3. 3. Run the rules

   Each module runs its rules over the evidence. A rule fires when its condition is true for a record (a shell started by Word) or for the run as a whole (no audit policy enabled at all).

4. 4. Group matches into signals and entities

   Every match of a rule about the same thing becomes one signal, with a count and its first and last time. Signals about the same program, account or service are grouped into one entity, across modules.

5. 5. Say what could not be seen

   Signal records the health of every source: read, partly read, not read and why. A rule whose data was missing is not run - never "clear". This is the "what you can't see" half of every run.

Modules: one question each#

Signal's work is divided into modules. Each module answers one question an analyst asks about a host:

The ideas behind it#

Signals, not inventories#

Signal does not dump every process, every logon or every command line for you to read. It outputs what the rules matched, plus small capped tables. You get a list to act on, not a new pile of data to analyse.

One thing, one record#

A user, a process, a service or a task is read from every source that records it and merged into one record, with each part attributed to its source. An account is matched by its SID, never by its name alone.

Unknown is never "no"#

When Signal cannot read something, it says so. A log that does not exist is absent; a rule that could not be evaluated is not run. Silence in Signal's output never means "nothing happened" unless the source was actually read.

Never disrupt the host#

Signal only reads. Locked files are read without taking locks; no process is stopped; no shadow copy is ever created. It runs at below-normal CPU priority, so the host's own work comes first.

Next#

See where Signal fits beside the other tools of incident response.