When an incident occurs, response teams regularly face the same obstacle: the lack of usable logs. Between a lack of logs and poor configuration, companies are often more blind than they think, until a cyberattack happens. 

Logs are files that store actions from events in a computer system or application. Even though they're simple, event logs are the main source of information for the analysts responsible for determining the cause, nature, and impact of a cybersecurity incident. Yet these files are often lacking or, even worse, nonexistent.

This isn't a secret, either. Most incident responders believe their response could have been dramatically quicker if the right logs were available to them from the outset — and normally, they're not.

The most surprising thing is that system administrators only realize that they're sorely lacking in logs after an incident occurs. This leads root cause analysis to often require after-the-fact forensics instead of immediate action. Additionally, it often takes forensic analysts an extremely long time to determine the scale of an attack. What's worse is that sometimes a full analysis can't even be carried out because the right information wasn't collected, let alone stored for a sufficient period of time, and has been overwritten.  

How did it come to this? Let's take a look at why so many companies have an insufficient log management strategy and how they can fix it before a cyber-incident occurs.  

Default Settings Lead to Failure 
The reality is that very few companies implement a true logging strategy. Often companies run with default configurations that generate a basic log and are set to overwrite to save storage. The idea is that they then keep only the information that is most useful. This becomes the lowest common factor, which doesn't always correspond with companies' cybersecurity needs. 

With products generating logs into their own location (often unknown to the admin), the lack of centralized logs makes the process of identifying a cyberattack even more complicated. Typically, when an incident occurs, the IT department isn't prepared to respond to requests from the incident response team. Without being able to identify which machine or user was on the IP that was affected, companies are challenged to determine how the incident occurred and how wide its impact is on the network. 

So, even if an admin redirects to a central log service, it's not enough. They need to collect all logs while also being set for audit and verbose. These are two settings often ignored. Instead of real data, businesses are storing things like generic "start" and "stop," showing a piece of software was opened and then closed with no details, instead of collecting compromised events with details such as "user BadActor started Y program" and "User BadActor copied files to X share."

As if the absence of logs and the restricted information wasn't disabling enough in itself, privileged compromise makes it worse. Without a proper logging strategy, it's a good bet that the accounts in question will be able to delete or manipulate available logs. So, when compromised, an attacker can remove the most useful information from a log in order to make an investigation more challenging — if not impossible — to complete.   

Creating an Effective Logging Strategy 
Determining an effective logging strategy is the key to a strong incident response program. This strategy may vary depending on the company and the sensitivity of its information system. Additionally, the logs themselves need to be protected. The issue is that businesses need collectors from all systems, cloud, on-premises, hybrid, or application, and it needs to be aggregated and searchable from a single location. These also need to be secured — remember the most notorious breaches of the last 10 years have involved insecure logs.

Once businesses have the logs, they need to audit them and stage some tabletop events in attempt to use the logs to identify an activity. This will help corporate teams understand why having a single interface to launch queries on all logs multiplies the effectiveness and shortens the intervention time by several days. 

It's also important to implement special monitoring for privileged accounts to ensure that privileged events are logged. The goal is to have enough events to track a complete session and easily determine the actions taken by an administrator or a privileged account. Often, hundreds of critical events can be missed or deleted without careful consideration. Through dedicated solutions that keep logs from different systems for over a year, versus 90 days, IT teams can ensure they have the resources to properly analyze an incident.

Strong logging strategies aren't a new concept, but when companies neglect logs they're setting themselves up for failure when a cyberattack occurs. Implementing a solid logging strategy will not only enable organizations to react quickly and effectively in times of crisis but also speed resolution and root cause analysis.