Too much and too little
There are two ways to fail with logs. The first: switch everything on, pay an enormous storage bill and find nothing when you need it, because nobody knows what to look for among millions of lines. The second: not switch on the logs that matter, and discover during an incident that there is no way of knowing who did what.
What to log
The essentials, almost always:
- Identity: sign-ins, failures, second factor, changes to permissions and roles.
- Cloud control plane: every configuration change (who, what, when, from where).
- Confidential data: access and exports.
- Keys and secrets: every use.
- Deployments: what was deployed, with which digest and who approved it (the same chain as what is running, where and why).
The rest (application debug logs, detailed traffic) is switched on where it adds value and for as long as it adds value.
Where and for how long
- Somewhere separate from the systems doing the logging, in an account of its own (the logs account from the account structure), so that an attacker who gets into a system cannot erase their traces.
- Protected against modification: they are only written and read; they are not edited or deleted early.
- With retention by kind: security and compliance logs for as long as the standard or the regulation requires; operational ones, less.
- With a planned cost: log volume is one more cost, and it is managed as such (with lifecycles that move older data to cheap storage).
Logging well is the raw material. What turns those logs into protection is detecting in them what should not be happening.
How we apply it: Cybersecurity.