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.

Threat Intelligence

4/11/2019
02:30 PM
Joe Partlow
Joe Partlow
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

In Security, All Logs Are Not Created Equal

Prioritizing key log sources goes a long way toward effective incident response.

Like a triage nurse, security professionals have to prioritize the data that will help them best identify problems and keep the organization, its data, and devices safe from intruders and cyberattacks.

However, logging and monitoring all relevant events from across the IT environment can be challenging. For instance, some common log sources, such as servers, firewalls, Active Directory, intrusion detection systems, and endpoint tools, are fairly easy to ingest and parse. But other sources that are particularly valuable for incident response (IR) are difficult to manage at scale and rarely ingested because of the effort it takes.

In fact, a new 451 Research survey of 150 large enterprises found that enterprise security information and event management (SIEM) platforms are only ingesting logs from about 45% of their organizations' log-producing systems. This means teams risk missing critical information that could indicate a compromise and affect their overall security posture.

To maximize the benefits of logging, organizations must evaluate and adapt existing processes to fit current needs and threats, as well as consider logging additional — often overlooked — sources that are invaluable for IR and threat-hunting exercises. Here are five log sources that should be prioritized.

1. Database Logs
Database logging poses challenges for a number of reasons. Administrators often avoid enabling features, like auditing, that could impact server performance. Auditing databases and tables is very difficult given the large number of database servers resident in the typical enterprise environment. In addition, security teams struggle to gain access and visibility into operations occurring in databases created by third parties that have restrictions on viewing the data or table structures.

To gain sufficient visibility into the databases without enabling auditing functions, consider correlating built-in rules and alerts into your SIEM if database activity monitoring is present. You could also create stored procedures that watch for specific actions, and write an event log with the record ID, date, and time of the violating record entry to trigger an alert.

2. Web Server Logs
Of the major data breach vectors, holes in web applications – which typically have access to highly sensitive customer account information – represent the greatest percentage, according to the "2018 Verizon Data Breach Investigations Report." Unfortunately, security teams have the least visibility into web application logs.

In addition, parsing web server logs is challenging because they are often in a multi-line or custom format and logged in a nonstandard way to a text file or database, as opposed to the native web server log, such as Microsoft IIS or Apache. If you're using standard web server logs, be sure to enable all the relevant fields since the default W3C layout in IIS doesn't capture some critical elements, such as page size and cookie values. Logging events from a web application firewall (WAF) already watches for potentially malicious actions.

3. Domain Name System Logs
DNS server logs provide rich information about what sites users visit, and they show whether any malicious applications reach out to command-and-control sites. However, DNS also is a common tunneling protocol for exfiltrating data since firewalls typically allow the data out. DNS logs are challenging because of the volume of data, their multi-line format, and the difficulty posed in exporting them.

Consider using BIND, Infoblox, or even Microsoft's new Analytical Event Logging method, which uses a more standard logging format rather than the traditional debugging and flat file importing. The new Analytical logs have significant performance gains over the debug method, and the events are stored in the common Windows Event Log format.

4. Cloud Platform Logs
Enterprises are rapidly adopting cloud services, including Amazon Web Services, Google Cloud Platform, Microsoft Azure, Salesforce, and Dropbox, to store data and applications. However, many such services don't have consistent logging formats and require different parsers and methods of logging events from various applications housed on the platform. Building parsers to scale to the number of events is a challenge for most teams, but effectively prefiltering data before ingesting will prevent overwhelming your SIEM or logging tool by handling only the actionable events.

Cloud application security broker (CASB) solutions may not be all-encompassing enterprise platforms, but they provide granular auditing capabilities at the application or service level and need to have the same logging and monitoring considerations as full cloud platforms. CASB solutions are essential for IR and forensic investigations since alerting on unauthorized access to cloud services can signal potential insider threats.

5. Physical Security Logs
It is extremely valuable to monitor for insider threats logs from camera systems, biometric/card access readers and alarm systems. Combining these with evidence correlated from servers, workstations, firewalls, VPNs, and remote access devices is essential to demonstrate whether credentials were stolen and establish insider location at specific points in time. However, the physical security team and the IT security team tend not to work together, which makes it difficult to gather and correlate the different log sources. Despite that, it's not impossible to ingest logs from the disparate systems. The focus should be on things like unauthorized physical access to remote facilities, visitor/contractor access to unauthorized areas, and after-hours alarm triggers.

Stay Alert  
These five log sources are helpful in improving visibility into the entire enterprise security environment, but enterprises need to be smart about how they handle all the new alerts generated by their security products. The 451 Research report found that 43% of enterprises are unable to act on at least a quarter of the alerts, and nearly half said their SIEM, endpoint detection and response, and other data-capture systems were overwhelming their security operations capacity.

A good best practice is to create a roadmap with all of the possible log sources and have IT teams work with affected business units to set priorities, taking into account the level of effort ingesting will require and the potential risks that will be mitigated by doing so. Having security teams work with the data or application owners ahead of time ensures they can review the actionable event types together and disoverer where the source owners might need more visibility.  

Related Content:

 

 

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Joe Partlow is currently the chief technology officer at ReliaQuest, an enterprise cybersecurity company. He has been involved with InfoSec in some capacity or role for over 15 years, mostly on the defensive side. Current projects include mobile and memory forensics, SIEM ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
secdatanoms
50%
50%
secdatanoms,
User Rank: Author
5/9/2019 | 11:44:16 AM
Strategic logging
Excellent points Joe about the need to prioritize certain log types. With phishing the continued #1 source of malware, I would throw email logs on that priority list. For secondary log sources, it is critically important to create detailed logs and then decide on where to store them (local host, network share, commodity data lake, or SIEM). The cost tends to increase as you move right in that list. The security of those logs is important and must be considered when weighing the risk and cost of each option. A recent Twitter thread started by Jake Williams touched on this topic: https://twitter.com/malwarejake/status/1126075545547100160?s=21
For Cybersecurity to Be Proactive, Terrains Must Be Mapped
Craig Harber, Chief Technology Officer at Fidelis Cybersecurity,  10/8/2019
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17593
PUBLISHED: 2019-10-14
JIZHICMS 1.5.1 allows admin.php/Admin/adminadd.html CSRF to add an administrator.
CVE-2019-17594
PUBLISHED: 2019-10-14
There is a heap-based buffer over-read in the _nc_find_entry function in tinfo/comp_hash.c in the terminfo library in ncurses before 6.1-20191012.
CVE-2019-17595
PUBLISHED: 2019-10-14
There is a heap-based buffer over-read in the fmt_entry function in tinfo/comp_hash.c in the terminfo library in ncurses before 6.1-20191012.
CVE-2019-14823
PUBLISHED: 2019-10-14
A flaw was found in the "Leaf and Chain" OCSP policy implementation in JSS' CryptoManager versions after 4.4.6, 4.5.3, 4.6.0, where it implicitly trusted the root certificate of a certificate chain. Applications using this policy may not properly verify the chain and could be vulnerable to...
CVE-2019-17592
PUBLISHED: 2019-10-14
The csv-parse module before 4.4.6 for Node.js is vulnerable to Regular Expression Denial of Service. The __isInt() function contains a malformed regular expression that processes large crafted input very slowly. This is triggered when using the cast option.