DPLens runs on the machines that matter most, with access to their logs. This page sets out what it does, what it deliberately does not do, and how to tell us if we have got something wrong.
It does not phone home
- No telemetry. DPLens sends nothing about you, your machines or your events to us. There is no usage reporting and nothing to opt out of.
- No licensing service. Licence keys are verified offline against a key built into the program. An air-gapped machine is a normal deployment.
- No auto-update. DPLens does not download anything. You decide when to upgrade, from a package you fetched and verified.
- No cloud service and no control plane. The agent is standalone.
The only outbound connections DPLens makes are to the destinations you configure — and, if you switch it on, the public-IP enrichment lookup. That one contacts a third-party address-reflection service, is off by default, and lets you point it at any endpoint you prefer.
The shape of the process
DPLens runs as two processes, not one.
The collection service does the work, as a virtual service account with no password and only the privileges it needs.
The console host is separate, with fewer privileges. It cannot read your event logs, reach your destinations, or read the secret store; it asks the service and renders the answers. A fault in the web interface cannot become a fault in collection.
See The service and its permissions.
Data at rest
| What | Where | Protection |
|---|---|---|
| Configuration | config\agent.yaml | Administrators and the service only |
| Licence | config\licence.key | As above. Signed, not secret. |
| Secrets | state\secrets\ | Sealed to this machine. Never displayed or written out in clear. The one way out is the deployment capture, which the agent performs itself and only re-encrypted under a deployment key that is shown once and never stored — see The deployment MSI. |
| Undelivered events | state\cache\<destination>\ | As above — this is your log data, so the folder permissions matter |
| Audit log | state\audit\audit.jsonl | Append-only, hash-chained |
| Console password | state\secrets\ | Stored as a hash, sealed like any other secret |
| Sign-in lockout state | state\auth\ | As above |
Permissions are applied at installation and re-applied and verified at every service start, so a change made by something else is corrected rather than inherited.
Secrets are write-only
You can set a secret and see that a handle is in use. Nothing shows you what is behind it — not the console, not a log, not the configuration file, not an export.
Sealing is to the machine: copying the state folder onto a different, separately-installed machine does not carry the values with it. That is what protects a stolen or mislaid copy of the folder.
Sealing is not a boundary between accounts on the same machine, and it is not a substitute for keeping secrets out of an image. The folder permissions are what keep other local users out, and a machine cloned from an image can carry usable material with it — so do not bake secrets into a golden image. See Golden images and VDI clones.
Data in transit
- To your SIEM: TLS with certificate validation on by default, and mutual TLS where your receiver requires it. Validation can be turned off for testing and says plainly what that costs.
- To the console: HTTPS. Loopback only unless you turn on remote access, which requires an explicit list of permitted networks. That list is checked before the TLS handshake.
- Masking runs before anything leaves. A value a masking rule rewrites is not written to the disk cache and not sent, and the console's own live stream shows the rewritten form, because that is what leaves.
How it is built
- A memory-safe language, with no unsafe code outside the small, reviewed layer that talks to Windows.
- Every parser, decoder and encoder is fuzz-tested. Anything that reads untrusted input — a syslog message, a NetFlow packet, a log line, a configuration file — gets a fuzzing target in the same change that adds it.
- Patterns you write run on an engine that does not backtrack, so a pattern cannot be written, by accident or otherwise, that stalls the pipeline.
- Bounded by construction. No unbounded queue exists anywhere. Sources are pull-based and pausable, so pressure travels back to the source rather than accumulating in memory.
- No dynamic code loading of any kind. Nothing is downloaded, plugged in or evaluated at runtime.
- A deliberately small dependency list. Every third-party crate has to justify itself against writing the code ourselves, and its licence is checked automatically.
Signing and the bill of materials
Released artefacts are Authenticode-signed and published with SHA-256 checksums and a software bill of materials in both CycloneDX and SPDX formats.
Verify what you downloaded before you run it — see Verifying a download, which also explains what an unsigned pre-release means and how to tell.
The agent checks its own signature at start-up and records what it found in the audit log.
The audit log
Every change is recorded: sign-ins and failures, configuration applies and rollbacks, password changes, certificate installation, licence changes, masking policy changes, and the agent's own start-up checks.
Each record is chained to the one before it with a cryptographic hash, so a record cannot be altered or removed without breaking the chain, and the console shows whether the chain verifies.
It is append-only and cannot be cleared from the console. Ship it to your SIEM if you want it retained off the machine.
Nothing is dropped silently
Every drop, mask, aggregation, failover and policy change increments a counter the console renders. If DPLens discards an event, it is because you configured something that discards events, and the number is on the Overview attributed to the rule that did it.
This is a design rule, not a feature: a log agent that loses data quietly is worse than no log agent, because you believe you have coverage you do not have.
Hardening checklist
| Leave the console on loopback unless you need it remotely | |
| If you need it remotely, set the allowed networks tightly | Settings |
| Install your own console certificate | |
| Use TLS to every destination that supports it | Choosing a destination |
| Keep certificate validation on | |
| Configure masking before you configure delivery | Pipeline |
| Set Allowed networks on every syslog and NetFlow receiver | Sources |
| Ship the audit log to your SIEM | Logs and health |
| Keep the default service account rather than LocalSystem | |
| Verify the download before installing | Verifying a download |
| Back up the configuration and licence | Backup and recovery |
Reporting a vulnerability
If you believe you have found a security issue in DPLens, tell us before you tell anyone else, and we will work with you on a fix and a disclosure timetable.
Please include what you found, how to reproduce it, the version affected, and how you would like to be credited. We will acknowledge your report, keep you updated while we investigate, and credit you when we publish the fix unless you ask us not to.
Please do not test against systems you do not own or have permission to test.