Endpoint Telemetry Analytics & Operations Reporting
SIEM-based system that converts endpoint telemetry into session summaries, capture-quality diagnostics, and operational reports.
Executive overview
The system centralises endpoint events, classifies operational signals, reconstructs sessions, evaluates capture quality, produces reports, and supports routine investigation through read-only tools.
The difficult part was not chart generation. The real challenge was preventing incomplete, missing or duplicated telemetry from becoming confident but misleading conclusions.
I directly contributed to telemetry troubleshooting, reporting workflows, operational validation and tooling, while also defining the solution direction and handover approach.
Business problem
- Multiple endpoint event types arrive independently.
- Login and logout do not equal confirmed active time.
- Some devices lose browser or lock telemetry.
- Re-registration creates duplicate records.
- Overnight sessions cross reporting boundaries.
- Missing telemetry can create false conclusions.
- Business users need understandable summaries rather than raw events.
Architecture
- Endpoint Devices
- Local Collectors
- Central SIEM Ingestion
- Search & Retention
- Normalization & Classification
- Session Reconstruction
- Capture-Quality Validation
- Aggregation & Reporting
- Raw Event Search
- Device Health Checks
- Person & Date Investigation
- Report Generation Runbook
| Stage | Responsibility | Input | Output | Failure risk | Control |
|---|---|---|---|---|---|
| Ingestion | Centralise events from collectors | Endpoint event streams | Searchable event store | Missing collector = silent gap | Fleet health check |
| Normalization | Classify operational signals | Raw events | Typed events | New event shapes drift | Sampling + review |
| Session Reconstruction | Pair login/lock/unlock/logout | Typed events | Session records | Unpaired or duplicated events | Duplicate control + boundary handling |
| Capture Quality | Grade the reliability of each record | Session records + coverage | Verified / Degraded / Unverified | False confidence | Explicit quality label on every row |
| Reporting | Summarise for business users | Graded session records | Operational report | Misinterpretation | Runbook + exception review |
Why activity calculation is difficult
- 09:00 — Login
- 11:10 — Lock
- 11:35 — Unlock
- 13:00 — Lock
- 13:45 — Unlock
- 18:00 — Logout
Login minus logout represents session duration, not confirmed activity. Reliable estimation requires event ordering, lock and unlock pairing, duplicate control, session boundaries and confidence in the underlying capture.
Key engineering decisions
Use session, lock, unlock and endpoint activity rather than trusting one event source.
Classify records as verified, degraded or unverified.
Do not manufacture confident figures from incomplete evidence.
Activity data can support investigation but does not independently define employee performance.
Allow internal users to run routine checks without modifying production configuration or data.
Failure and investigation stories
A required operating-system signal existed locally but did not reliably enter the central monitoring flow. Supplemental collection and validation were required.
Re-registered machines created new records while older empty records remained visible.
Some endpoints continued sending system events but lacked sufficient browser-event coverage.
Sessions crossing midnight required explicit date-boundary handling.
Longer retention improved investigation value but introduced capacity-planning responsibility.
Capture-quality methodology
Required telemetry is sufficiently complete and internally consistent.
Some signals are missing, but cautious partial interpretation remains possible.
Capture is too weak or inconsistent for reliable interpretation.
Operational toolkit
The toolkit was designed for read-only routine diagnostics and reporting.
Confirm telemetry flow after enrolment.
Surface devices with degraded coverage.
Inspect a specific device on a specific date.
Check that session events are landing centrally.
Reconstruct a session for a named individual.
Drop from summary values back to source events.
Repeatable steps for producing operational reports.
Validation approach
- Compare report values against raw source events.
- Review selected devices and dates.
- Validate lock and unlock sequences.
- Confirm session boundaries.
- Identify duplicates.
- Check browser and activity coverage.
- Mark unreliable rows.
- Review report exceptions.
- Provide runbooks for internal operators.
My role
I led the solution direction and directly contributed to telemetry troubleshooting, session and reporting workflows, validation, read-only operational tooling, documentation and handover.
Outcome
- Endpoint telemetry became accessible through structured reporting.
- Weak capture was clearly surfaced.
- Internal users received tools for routine checks.
- Report generation became less dependent on one individual.
- Investigation could move from summary data back to source events.
- The system remained an operational evidence source rather than an automated performance-scoring tool.
Limitations
- Endpoint policies and collectors may fail independently.
- Browser telemetry can be incomplete.
- Some session signals require supplemental collection.
- Active windows remain estimates.
- Reports require human interpretation.
- The system should not be used alone for disciplinary decisions.
Interview preparation
Interview preparationHow I explain this project in an interview
A SIEM-based endpoint telemetry system that converts fragmented events into session summaries and operational reports, while making capture quality explicit so incomplete data cannot masquerade as confident findings.
Endpoint collectors send events to central SIEM ingestion with search and retention. Events are normalised and classified, then sessions are reconstructed by pairing login, lock, unlock and logout signals with duplicate control and date-boundary handling. A capture-quality layer grades each session as verified, degraded or unverified. Aggregation produces reports; a parallel operational branch offers read-only tools for raw event search, device health, and person/date investigation. The design deliberately favours visible uncertainty over false precision — activity is an estimate supported by evidence, not an automated performance score.
- Why was capture quality necessary?
- What did I personally implement?
- What was handled through scripts or collectors?
- What failed in the original approach?
- How were report values checked?
- Why is active time still an estimate?
- What should the system never be used for?
- What would need to change at larger scale?