Sign up for a live Kubernetes or DevSecOps demo

Click here
Back to blog results

May 4, 2017 By Mark Bloom

The Importance of Logs

Across all of the nation-state targeted attacks, insider thefts, and criminal enterprises that CrowdStrike® has investigated, one thing is clear: logs are extremely important. Event logs from individual computers provide information on attacker lateral movement, firewall logs show the first contact of a particular command and control domain, and Active Directory authentication logs build a timeline of user accounts moving throughout the network. Sounds great, right? It is, as long as all the logs are saved and searchable.

Retention Recommendations

Logs that provide an effective source of data for identifying targeted attacks as well as helping to determine what actions have been taken need to be protected. Since some attackers attempt to remove all traces of their actions, it is critical that logs are centralized, making it more difficult for the complete removal of log data.

Enterprises also need to look at future potential investigations and determine where their weaknesses might be. For instance, if an organization does not track DHCP logs, it will be harder to track older activity that originated from an internal system. In the example of targeted attacks, businesses that track failed VPN logins might see a pattern and have warning when an attacker is knocking on the door.

At a high level, CrowdStrike recommends organizations collect remote access logs, Windows Event Logs, network infrastructure device logs, Unix system logs, Firewall event logs, DHCP logs, and DNS debug logs. Businesses intent on using logs for troubleshooting and investigation should strive to collect and store the items below.

Log SourceLog TypesRetention Period
DNS LogsRequests3 months
Windows Event LogsApplication, Security, & System12 months
Web Proxy LogsAccess, Errors6 months
Active Directory Authentication LogsAuthentication6 months
Remote Access Authentication LogsAuthentication6 months
DHCP Lease LogsLease information12 months
Router LogsNetflow3 months
IDS/IPS Alert LogsConnections, Access12 months
VPN LogsConnections, Access12 months
Two-Factor Authentication LogsConnections, Access12 months
SNMP LogsAudit6 months
Firewall LogsConnections, Access, Health3 months

Storing and Searching

Outside of the logs themselves, it is critical for organizations to be able to aggregate, correlate, monitor, and analyze event logs from multiple sources in a network. Many papers have been written about central log management (CLM and security information and event management systems (SIEM) and it is impossible to do the topic justice in a short blog post due to the importance and complexity of undertaking such a project. However, the impact of an efficient CLM/SIEM is immediately evident when an investigation occurs.

Mature companies are also able to identify log sources or individual events that do not need to be kept as too much information can also be a downfall. If information cannot be quickly retrieved from the CLM/SIEM or other log aggregation source, then the collected data is not helping the company. Choosing and managing a log correlation engine is a difficult, but necessary project.

Example Investigation

To help highlight the importance and useful of logs, a recent CrowdStrike investigation involved assisting a client with an investigation into a malicious insider. The organization had an employee in IT who decided to delete an entire SAN volume while out of the office. Our analysts used six different sets of logs to help create a complete timeline of events for the client. As the client had robust logging in place and completed timely searches in response to our queries, we were able to quickly sequence the malicious actions. A portion of the timeline appears below to highlight how using different log sets can provide a clear view of events.

Date/Time (UTC)DescriptionSource
2015-10-15 14:49:33Suspected employee from external IP Address 204.32.xx.xx started VPN session as USER-A and was assigned internal IP Address 10.x.xx.101.VPN Logs
2015-10-15 14:51:20IP Address 10.x.xx.101 initiated Remote Desktop session with system 10.x.xx.202.Netflow Logs
2015-10-15 14:51:25Suspected employee logs into the desktop workstation with IP Address 10.x.xx.202 as USER-B.Active Directory Authentication Logs
2015-10-15DHCP logs showed IP Address 10.x.xx.202 was previously assigned to hostname ABC-123, a desktop computer belonging to USER-C.DHCP Logs
2015-10-15 14:53:46IP Address 10.x.xx.202 successful logs into SAN using Administrator account.SAN Logs
2015-10-15 14:54:32SAN Volume “ImportantDatastore” deleted.SAN Logs
2015-10-15 14:55:03VPN Session for USER-A ended.VPN Logs

Through log analysis we were able to show the actions of an outside user who logged into the VPN, began an RDP session with a desktop computer assigned to a separate user, used the desktop to log into the SAN, and delete an entire SAN volume. Without good log aggregation, the company wouldn’t have been able to produce the entries above.

Conclusion

Aggregating logs is critical to successful troubleshooting and investigation. Businesses need to spend time knowing what to collect, what not to keep, and how to search older records. Organizations should conduct regular self assessments to determine if the current level of logging is sufficient across the enterprise and find any gaps that can be fixed. Many times businesses do not see their deficiency until an investigation occurs and it’s too late to fix it. We have found that organizations that conduct table-top or similar simulation exercises are much better prepared than businesses that do not undertake periodic assessment.

This guest blog was written by Matt Churchill, who manages the Technical Operations team for CrowdStrike, helping to drive innovation and build a world class forensic lab and services. Matt can be reached at https://www.linkedin.com/in/mchurchill/.

This blog post – part 1 – focuses primarily on logging within a traditional on-prem datacenter. Stay tuned for an upcoming post – part 2 – that will discuss logging within AWS IaaS.

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Mark Bloom

More posts by Mark Bloom.

People who read this also enjoyed