To Log Or Not To Log
A breakdown of important information to have in an incident
During an incident logs are crucial. I honestly don’t care where they are, we just need them during an incident. An important question that need to be answered is:
Who did What and When
I’ll break it down a little here. The goal here is that this breakdown will help you determine what you need to log exactly.
This can be any of the following. The more information, the better of course.
username or service account name
unique identifier (UUID, GUID, etc)
IP Address (attribution is hard - YMMV)
What action was performed?
Authentication attempts (successful, failed)
File Delete, Writes, Reads, Modifications
Connections established / attempted
Self-explanatory here. Having a synced system is crucially important when trying to piece things together. One mistake or difficulty I see often is not taking into consideration time zone or the time standard context of the log. Whether it was in GMT or UTC (not a time zone) or if DST (Daylight Savings Time), this is very important to understand and configure. If you’re logs do not include time zone inside the log time, then make sure to configure your log aggregation tool accordingly. Many times it will assume a time zone for the incoming log.
Having your time off will lead to inconclusive evidence, or worse, false positives.
Now if you have all of the above, but the logs are only retained for a couple weeks, well that’s not going to be so useful. My general recommendations are to have at least 90 days worth of logs easily searchable, and at least 12-18 months of retention total.
What Do I Need To Log?
Logging everything will not only cost you more, but make it harder to find what you’re looking for. The key takeaway here is to start with authentication logs as a minimum. Once an attacker has access to credentials, they will try to pivot and access other systems.
Note: If you have SSO enabled and required for authentication into your apps this will ease the log burden overall. 💪🏼
Here’s a list of applications and sources to start with:
Google Workspaces Audit Logs
O365 Audit Logs
Slack audit logs
Wiki Audit Logs (Confluence, Jira, Notion)
AWS / Azure / GCP / Heroku / Hosting Provider
Cloudflare / CDN
Web Application Logs
This is not a comprehensive logging guide or manual, but meant to help you prepare in the event of a security incident. With so many 3rd parties being affected by security incidents, it’s become ever more important to prepare.