OK, OK…

I know I’ve said this before but I am back.  New posts will be coming more regularly.  To kick it off I want to talk about a topic that has been near and dear to my heart for a long time and reared its ugly head again recently.

Over the past few weeks I’ve been involved with an incident response.  Once again, I’m reminded how important good logs are to the investigation.  There are a couple issues that I would like to point out.

  1. Verify the types and quantity of logs available from your cloud providers.  I won’t name names, but it rhymes with SicroMoft, have only certain logs available.  This post by CrowdStrike discusses logs that were available through the vendor’s API.  Unfortunately, SicroMoft closed that API shortly after it was made public.  So, during an investigation, the response team is limited by the type of logs they can review.
  2. To make matters even a little more complicated, while downloading the mailboxes involved in the investigation, SicroMoft appears to throttle the download speeds.  Your humble narrator was hitting peak speeds in the 3-4 Mbit range during the start of the download.  After a period of time those speeds dropped to the 300 kbit range.  This was confirmed by other sources who saw the same throttling.
  3. If you are logging on-premise, please test your ability to correlate your logs.  There are great tools available to help, but you must make sure silly things like timezone v. UTC are able to be reconciled.

Try this:  Can you determine when someone logged onto the network, logged into email, sent and deleted a specific email, and logged out?  Can you determine where all of this activity came from?  Don’t assume, try it.

If you don’t have adequate logging, you do yourself a disservice.  You are fighting with one hand tied behind your back.  Take time, while you aren’t fighting a fire, to make sure you can fight the fire when you need.