Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


01:00 PM
Robert Meyers
Robert Meyers
Connect Directly
E-Mail vvv

Why Are There Never Enough Logs During an Incident Response?

Most security pros believe their responses could be dramatically quicker were the right logs available, and usually they're not.

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. 

Related Content:

9 Modern-Day Best Practices for Log Management

Special Report: Building the SOC of the Future

New From The Edge: Data Privacy Is in 23andMe CSO's DNA

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.

Robert Meyers is the compliance and privacy professional and channel program solutions architect at One Identity. He is a 30-year veteran of the identity and access systems and information security industry, with more than 10 years of that time focused on planning, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
User Rank: Apprentice
7/10/2021 | 6:29:18 PM
Great article
Great article, Robert. Logging is one of those fundamental security controls that is actually much harder to get right than most realize.
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-10-20
Discourse is an open source platform for community discussion. In affected versions maliciously crafted requests could lead to remote code execution. This resulted from a lack of validation in subscribe_url values. This issue is patched in the latest stable, beta and tests-passed versions of Discour...
PUBLISHED: 2021-10-20
Microsoft Surface Pro 3 Security Feature Bypass Vulnerability
PUBLISHED: 2021-10-20
Babel.Locale in Babel before 2.9.1 allows attackers to load arbitrary locale .dat files (containing serialized Python objects) via directory traversal, leading to code execution.
PUBLISHED: 2021-10-20
The Proof-of-Stake (PoS) Ethereum consensus protocol through 2021-10-19 allows an adversary to cause a denial of service (delayed consensus decisions), and also increase the profits of individual validators, via short-range reorganizations of the underlying consensus chain.
PUBLISHED: 2021-10-20
The Proof-of-Stake (PoS) Ethereum consensus protocol through 2021-10-19 allows an adversary to leverage network delay to cause a denial of service (indefinite stalling of consensus decisions).