Beyond logs and time series: observability for security & privacy

The talk starts from observability, a term that grew out of SRE circles, and contrasts it with traditional logging, alerting and time-series monitoring. Each approach slices system data differently: logs record past events as evidence, alerts fire on conditions defined in advance, metrics capture state over time, and tracing follows a request across services. Combined, these let teams query a running system rather than reconstruct incidents by hand.

For security work, the main gain is the ability to pivot and join across data on the fly. An investigator can start from one suspicious session, check whether a credential was used elsewhere, or narrow scope by geography or subsystem. Operational and security teams often query the same data for different questions, so shared tooling can serve both if it is adapted. The speaker also covered benefits such as better alignment between development, operations and security, automation, behavioral alerting, and easier audit evidence. The costs include dynamic tracing that attackers can misuse, a false sense of completeness from single-pane dashboards, and weak support for legacy systems.

On privacy, opaque identifiers let traces follow data through a system without exposing the underlying values. The closing advice was to test vendor claims by running red-team activity against candidate tools, to treat access to observability capabilities like root access, and to decide deliberately what gets monitored and learn from each incident. The question period touched on query workflows, federating data sources, and checking whether a compromised collection agent can be caught by comparing its output with independent sensors.