5.2 What a Sensor Guide Contains
Every sensor and connector guide carries the same seven sections in the same order. Consistency is the point: having deployed one sensor, the next can be deployed without re-learning where the information is.
5.2.1 Overview and What Gets Scanned
What the sensor is for.
-
What it finds: the material types and the specific artefacts, named concretely: which stores, which file formats, which object classes.
What it does not find, in the places where the opposite might reasonably be assumed.
5.2.2 Prerequisites
-
Network access: which ports, in which direction, from which component, and whether the platform connects out or the sensor connects in.
-
Supported authentication methods: the list, with a recommendation among them.
-
Required access rights: the minimum privilege on the target that will work, scoped as narrowly as the sensor allows rather than stated as “administrator”.
-
Execution requirements: which execution models this sensor supports (platform-executed, remote-executed, EDR-orchestrated, off-grid) and any constraint specific to one of them.
-
Target-side prerequisites: anything that must be enabled, installed or opened on the target.
5.2.3 Configuration Fields
Every configurable field, with its type, whether it is required, its default, and what it does.
Advanced fields in a clearly marked subsection, so the common case stays short.
A worked minimal configuration and a worked realistic configuration.
Guidance on scope fields. An over-broad scope is the main cause of a scan that never finishes, so each guide states what a sensible scope looks like.
5.2.4 Execution Modes
-
Platform execution: how to configure the sensor in a template and run it as a task from the portal.
API execution - how to trigger the same scan through the API, with a worked request.
-
Remote execution: how to include the sensor in a deployment to a host, with any configuration difference from platform execution.
-
Off-grid execution: whether the sensor works in a bundle, and any limitation. Some sensors need a live connection to the thing they interrogate, and cannot.
5.2.5 Known Limitations
What the sensor cannot see, and why.
Rate limits or throttling imposed by the target, and their effect on scan duration.
Size, depth or count limits.
This section builds trust. A guide that admits a limitation is believed on the rest of its claims.
5.2.6 Troubleshooting
Common errors in symptom, cause, resolution form.
-
Authentication failures: the most common category by a wide margin.
Permission failures, including the silent kind where the scan succeeds and returns nothing because the account cannot see the objects.
Connectivity failures.
-
Empty results where results are expected: the failure that is hardest to diagnose without guidance.
5.2.7 Getting Support
-
What to collect before contacting support: sensor version, platform version, task and template configuration, the relevant log extract, and the target system version.
What to redact.
How to reach support.