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.

Who

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)

  • machine name

  • user agent

  • key id

What

What action was performed?

  • Authentication attempts (successful, failed)

  • File Delete, Writes, Reads, Modifications

  • Commands executed

  • Processes initiated

  • Connections established / attempted

When

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.

Retention

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?

Everything!

Just kidding.

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)

  • Platform Logs

    • 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.