Logs Are Incomplete Without the “Why”

When we talked about observability, we mentioned how logging and auditing is a mainstay of access control tools. One of the problems we see with logging today is a focus on the input and output, but lacking the system’s reasoning. This reasoning, known as the why, is important for simplifying the time to resolve issues.

Logging the why can be taken beyond just access control as the underlying philosophy applies to logging of any kind. The goal of logging is to expedite triaging and resolution: it is critical to understand why the system executed an action or decision instead of making practitioners run back to analyzing the system’s processes each time.

To better iterate and improve upon their access control infrastructure, organizations must prioritize the inclusion of the why in their logging practices.

The result will enable deeper insights and efficient iteration.

Where Logging Tools Fail

Today, many tools log the same thing:

• who did

• what at

• where during

• when , which they accomplished this

• how ?

The how may include the action taken (the input) and the result (the output). But if this is broken, the practitioner needs to manually piece together the why by cross-referencing this information with the system’s processes.

• Why did this happen the way it did?

• Why was this allowed or denied?

• Why did the input result in this output?

Take Tailscale’s logs for example:

ailscale’s logging answers who what when where (and is missing the how). While this answers some questions, it doesn’t tell the IT team why a user was approved or denied for those actions. The team needs to then chart that process while looking at authorization policy to determine if the policy was written incorrectly, what was checked, and what worked (or didn’t work). Only then can actionable data be gleaned, the system improved upon, and the situation avoided next time.

Why Add “Why”?

When we were building Pomerium, we had to make these same considerations and more:

• Level of criticality?

• who is acting?

• what did they do?

• when did they do this?

• where did they do this from?

• how was it done?

• why was it approved or denied?

There shouldn’t be a tradeoff between sampling data (which results in situations where you miss information) and data overload, so all logs should start off with a way to signify its own importance. After that, it should answer all the questions that the DevSecOps team will have and show exactly where the process broke down.

The resulting observability log should be the single source of truth and provide actionable data to hasten the process of iterative remediation.

Saved Time Improves Efficiency and Workflow

Not only do we have the best granular logs for auditing and workflow, but we’ve managed to do this for new applications and legacy services together. Observability logging including the why is a welcome addition to your access control with Pomerium proxy.

This has made Pomerium the top choice for companies looking for an open-source context-aware reverse proxy to manage secure, identity-aware access to applications and services.

Our users depend on Pomerium to secure zero trust, clientless access to their web applications everyday. You can check out our open-source Github Repository or give Pomerium a try today!