Audit logs are a vital tool for ensuring the software and systems an organization relies upon are all operating smoothly and effectively. Audit logs can be generated automatically at specific time periods, automatically when an event triggers a log to be generated, or they can be generated manually by a database administrator or network manager.
Audit logs contain priceless information about the systems that generate them, often in hundreds of pages at a time. As powerful as they are for systems diagnostics and data compromise detection, they can also be a treasure trove of information for hackers.
Understanding the Uses of Audit Logs
Audit logs are used by IT professionals like developers, engineers, administrators and technicians as diagnostic tools for both corrective and preventive maintenance. A backup server, for example, can generate an audit log detailing errors in a backup, as well as the times files were successfully backed up. Even a successful operation can have problems that aren’t visible until they are logged; for instance, a sizable delay in backing up files from one drive to another can indicate network connectivity issues, backup software malfunctions, or an impending storage drive failure.
Audit logs are a routine part of normal security compliance requirements and certifications, including their use and how they are stored. Because of the detailed information audit logs contain, they need to be treated as highly sensitive documents, never accessible except to those who need them.
As an example, some of the information that appears on operating systems and system audit logs can include the following:
- Login attempts
- Operations performed after logging in, like accessed files or installed software
- Changes to user accounts and permissions
- Successful and failed account actions
- Successful and failed account authentication
- Changes to application configurations
Email servers can include email addresses, email subjects and attachment names for each email sent and received. Business applications can include which users accessed specific financial records.
Audit Logs and IOCs
System audit logs are invaluable in detecting and identifying hacking attempts and weaknesses in a system that could jeopardize data integrity. System experts use logs to identify indicators of compromise (IOCs) just as they use data breaches, malware infections and other threats to data integrity to identify hacks. By monitoring logs, they can identify attacks as they happen, as well as identify weaknesses that could lead to a system breach — like failed updates or failures in security measures.
A Brief Example of IOC Data
Systems experts use audit logs to identify problems like unusual account activities, unusual network patterns, unauthorized configuration changes and unknown files appearing on systems. What they look for varies with the software being used, but administrators looking at logs generated by a web server or business information server may look for the following:
- Unusual outbound network traffic
- Anomalies in privileged user account activity
- Geographic irregularities
- Increases in database read volume
- HTML response sizes
- Numerous requests for the same file
- Mismatched port-application traffic
- Unusual DNS requests
Because systems are often complicated, identifying IOCs is often a team effort, involving forensic detective work between professionals with different specialities. It often takes comparisons of logs from different sources to look for correlations between different events, often on different systems. This means that logs must sometimes be shared within an IT department, with engineers at manufacturers and with independent security consultants.
System Audit Logs as a Security Threat
Unfortunately, audit logs can be a double-edged sword when it comes to a system compromise. All of the information they contain can be used in three malicious ways if a hacker got his hands on them. First, logs themselves can contain sensitive data, like usernames and client information that can simply be read by anyone with access to the log.
The second vulnerability of logs is that they contain system information that hackers can use to infiltrate your systems to access data. It can provide them with information on where information is stored, what internal pathways login efforts take to access data, the software being used to protect the systems and the versions of patches and upgrades applied to those systems. In the right hands, these logs can be a treasure map to the right group of hackers looking for sensitive data.
The third vulnerability is that when a hacker does compromise a system, he can attempt to modify the logs to hide any evidence that he has been there.
For these reasons, audit logs need to be stored securely, in a manner that allows access only to those who need them, when they need them, with safeguards that allow you to trace when they were accessed and by whom.
Storing and Tracking Audit Logs
A systems admin or data security expert may likely tell you that audit logs should only be saved for as long as they are useful. As a general rule of thumb, this could be a couple of months, or a couple of years. However, utility is only one deciding factor in this question. Just as importantly are the issues of corporate governance and governmental requirements, which could make storage of these logs a long-term relationship.
HIPAA: An Example of Log Storage Requirements
As an example, organizations involved in the healthcare sector should be familiar with HIPAA (the Health Insurance Portability and Accountability Act of 1996), which has a six-year storage requirement for sensitive information. Whether or not this six-year requirement includes system audit logs on which the data is stored and accessed may be something still up for debate.
However, as the compliance experts at Schellman point out, there are at least two reasons to believe that audit logs are included in the six-year rule. First is the wording of the Guide to Computer Security Log Management (NIST SP 800-92), which states that “documentation of actions and activities need to be retained for at least six years.” Second is the wording of a 2017 HHS memo, Understanding the Importance of Audit Controls. While it doesn’t explicitly state that audit logs need to be retained for this long, it does correlate them to the type of information that does need to be retained for this time period.
Schellman essentially sums up the discussion by pointing out that storing data isn’t expensive and, if it’s stored securely, keeping audit logs for at least six years is just a matter of being safe rather than sorry.
Using a VDR to Store Audit Logs
Because of the highly sensitive data stored on them, a virtual data room (VDR) is the ideal place to store audit logs. There are many good uses for VDRs when you need to secure and limit access to digital documents, but for audit logs there are three primary benefits.
First, data is secured on certified, state-of-the-art systems to ensure their protection. Data stored in a secure Caplinked VDR is encrypted using 256-bit Advanced Encryption Standard (AES 256). When data is transferred, it’s encrypted again using SSL/TLS-encrypted endpoints employing current-grade TLS v 1.2 cipher suites.
Second, you have the ability to control who has access to each file, when files are accessible and from where they are accessible.
Third, each audit log can be digitally watermarked, allowing you to track when the audit logs have been accessed and by whom. Watermarking data can include the time the file was accessed, the user’s name, IP address and email address. To discover the benefits of using a state-of-the art VDR yourself, start your free trial today.
David Weedmark is a published author and ecommerce consultant. He is an experienced JavaScript developer and a former network security consultant.
Sources:
https://www.darkreading.com/attacks-breaches/top-15-indicators-of-compromise/d/d-id/1140647
https://www.hhs.gov/sites/default/files/january-2017-cyber-newsletter.pdf?language=es
https://digitalguardian.com/blog/what-are-indicators-compromise
https://www.hhs.gov/hipaa/index.html
https://logz.io/blog/audit-logs-security-compliance/
https://www.logsign.com/blog/how-long-should-security-logs-be-kept/
https://digitalguardian.com/blog/what-are-indicators-compromise
