Logging, time, and evidence integrity
Keep source records, clock information and transformation history together. Record which device produced each event and how the application processed it.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
An incident timeline may join door events, video, alarms, operator actions, API requests, broker delivery, controller logs, identity provider decisions and network telemetry. Their timestamps and identifiers aren't automatically comparable or trustworthy.
Event record minimum#
- stable event type and schema version;
- event/source identity and site/tenant scope;
- occurrence, device, ingestion and processing times kept distinct;
- clock quality, uncertainty or synchronisation state where available;
- actor/workload identity and authentication context;
- requested action, target, authorisation decision and outcome;
- correlation and causation identifiers;
- sequence/counter and duplicate/replay disposition where meaningful;
- configuration/firmware/policy version needed to interpret the event;
- redaction/data classification marker.
Time model#
Use UTC for interchange and store the original offset when operational context needs it. Don't infer event order solely from wall clock timestamps. Prefer protocol sequence, monotonic duration and ingestion evidence for causal analysis. Handle leap seconds, clock steps, daylight saving display, device reboot, oscillator drift, NTP source change and loss of synchronisation explicitly.
NTPv4 is defined by RFC 5905, while Network Time Security adds cryptographic protection for NTP client/server time synchronisation in RFC 8915 RFC 5905 RFC 8915. Product support and deployment configuration must be checked per model; authenticated time doesn't guarantee the upstream time source itself is correct.
Integrity and custody#
- Send security relevant records off device promptly to a separately administered store.
- Restrict append, modification, deletion and export; log those operations too.
- Preserve original exports and hashes alongside derived/transcoded working copies.
- Record exporter, source system, exact time range, timezone, device/stream identifiers, software version and transformation steps.
- Use product supported signing/verification when available, but document what it covers and how trust is established.
- Protect encryption/signing keys independently from stored evidence.
- Validate in a representative environment that retention, rollover, storage pressure, and failover don't silently discard critical logs.
Privacy and utility#
Logging everything can create a second surveillance database. Don't log raw credentials, authentication tokens, biometric templates, passwords, full private URLs, unnecessary faces/audio, or unrestricted operator screen content. Preserve enough identifiers for investigation through controlled lookup and access.
Sources#
- RFC 5424, RFC 5424: The Syslog Protocol, accessed 25 August 2026.
- RFC 5905, RFC 5905: Network Time Protocol Version 4, accessed 25 August 2026.
- RFC 8915, RFC 8915: Network Time Security for NTP, accessed 25 August 2026.
- NIST 800 92, NIST SP 800-92: Guide to Computer Security Log Management, accessed 25 August 2026.