Log file integrity is an oft-overlooked aspect of a privileged access management (PAM) program, yet a critical piece of Unix and Linux security. Considering the potential risk to Unix and Linux log files in advance of an incident will contribute to a positive outcome during audits and deliver a healthy PAM posture for any company.
Most IT compliance regimes require the capture of session keystroke logs and regular event logs. During the collection of this data, however, it is important to take care and consideration to who may access these logs, under what circumstances, and for how long this data should be available. It is important to understand and differentiate between metadata, and session data when considering how log file information is handled and retained.
This blog will:
- Explain the difference between event logs and session logs
- Provide best practices for log file management
- Explain how to maintain the integrity of log data for legal purposes and enhancing Unix/Linux server security
We will also cover how BeyondTrust Privilege Management for Unix & Linux can address use cases around maintaining and security event logs and session logs.
Event Logs versus Session Logs – What’s the Difference?
For simplicity’s sake, standard event logs contain ‘metadata’ – high-level events with the ‘who,’ ‘what,’ ‘where,’ and ‘when’ of an activity. Session logs, however, are vastly different, and contain all the information entered and displayed by a privileged user during a session. Session logs may be stored encrypted and may only be accessible on specific servers. However, session logs require enhanced protection due to the potentially privileged information they contain.
An important distinction between event logs and session logs is information in event logs rarely contain any type of Personally Identifiable Information (PII), or other secret information. Since session logs capture everything taking place during a privileged activity, depending on the nature of the activity, these logs could contain PII.
A database administrator (DBA) uses Privilege Management for Unix & Linux to access an id on a system to troubleshoot a problem with a database serving customer account information via a web page. During troubleshooting, the DBA queries a database table to review information, and this data contains customer account information including names, addresses, banking information, and other personal information.
The event log would simply capture ‘who,’ ‘where,’ ‘what,’ and ‘when,’ and this information is not sensitive in most cases.
The session log would contain any information displayed within the session. Since the records were visible to the DBA, the PII data is also stored within the session log.
Guidelines for Developing Log Retention Policies
Retention policies should specifically define:
- How long log data is stored for each type of log
- The users who should have access to the logs
- Under what circumstances should you share and review the logs
Unix & Linux Log Retention Best Practices
Here are 5 log file management and retention best practices related to these Unix and Linux log files to help inform the development of retention policies:
1. Automate Retention
Both session and event logs may be subpoenaed during legal proceedings as part of the discovery, or evidentiary process. Usually, in legal processes, supplying any information related to the warrant, or subpoena, must be done. For this reason, it’s important to define a retention period, and build automated processes to ensure data retention complies with policy.
2. Retain Log Data for the Minimum Allowable Time Period
Retaining log files for too long may expose a company to legal or compliance risks. On the other hand, retaining log files for too short a time may expose other regulatory, or compliance risks. It is a best practice to retain log data for the minimum period allowable, as determined by legal counsel.
3. Define Specific Policies for Event Logs and Session Logs
Create specific retention policies for both metadata and session logs. Also develop a clearly defined process definition document to provide to auditors. Auditors may review controls within the document to determine compliance with the policy, and if the process is working as defined. Make sure to automate these processes, wherever possible.
4. Define and Automate Log Backups
Retention policies and automation should ensure destruction of any backup or stored copies of retained logs as the final part of the data lifecycle. Removing data will reduce the space required for backups, as well as eliminate the risk of data exposure. Again, develop a clearly defined process definition document for auditors. Auditors may review controls within the document to determine compliance with the policy, and t the process is working as defined. Automate these processes, wherever possible.
5. Limit Log Access to as Few People as Possible
Both session event logs can be an invaluable forensic tool to determine what happened on systems. Whether this is in response to a breach, an operational system event, or a legal requirement, “who” may access these logs is an important consideration within a privileged access management (PAM) program.
In general, it is wise to limit the number of people who can access logs to as few as possible. If practical, building records of who accessed the logs, and a reason for the access, should be part the process.
Carefully consider the reasons for log access and implement a mechanism to validate those reasons.
Six Common Log File Review Use Cases
When determining who should access logs and under what circumstance, consider the following common use cases.
1. Assist with ‘Root Cause Analysis’ for System Outages and Incidents
When investigating an unscheduled system outage, it is a good practice to pull all available information together to determine what caused the outage. Session logs can be an invaluable tool in this process. However, due to the sensitive nature of the data potentially contained in session logs, extraction of only the pertinent parts should occur during the analysis. Using ‘REDACTED” tags data output indicates sensitive (non-pertinent) data was removed. This process should be undertaken by a specialized team that understands systems and can identify sensitive information.
2. Verify Activities Within a Scheduled Change Took Place as Defined in the Change Management Record
Reviewing change records and validating what was performed during the change matches the proposed implementation, is a longstanding best practice. BeyondTrust’s dedicated management platform (BeyondInsight Unix/Linux) enables designated Unix/Linux admins to review and replay session command history.
3. During an Investigation into Unscheduled Changes or Modifications to Systems
As in the root cause analysis above, reviewing activity that took place on systems to determine whether it was authorized, unauthorized, or potentially malicious is an important aspect of compliance. Redacting irrelevant or sensitive information to the investigation should be done before delivering this data.
4. When Investigating User Activity to Determine Whether it was Malicious or Appropriate
This use case typically falls under the domain of an internal investigation into the activities of specific individuals within an environment. Develop a process with guidance from legal and privacy officers to define the exact circumstances where this can be done.
5. Using Session Recorded Activities to Develop Training, or Procedural Guides, as Part of a Documentation Process
This is another session log use case where BeyondTrust Privilege Management for Unix & Linux excels. When an ideal change occurs and can be used to train or document an activity, the session logs may provide step by step instructions for next time. Session logs can be reviewed for sensitive data, and if approved, used to record training videos for certain change activities.
Whenever proposing a new use case, consider the potential legal, compliance, or privacy risks associated with delivering the information. Rules vary widely by industry, and geographical location, and it is important to engage experts as part of this process.
6. Finding and reviewing log file or session log data
Privilege Management for Unix and Linux integrates with Elasticsearch. The product’s Elastic ELK stack integration enables administrators and auditors to centralize and index all their event log and session log data. This information is accessible using our BeyondInsight platform.
A built-in unified search provides easy search capabilities to find and access event logs and session logs. The search syntax can be simple, but also available is the ability to perform advanced searching using logical operators (and/or) Precedence, Wildcard searching, Field-specific searching, and/or Exact match searching using double quotes and any combination of the advanced searching. You can read more about the Elastic integration with Privilege Management for Unix & Linux here: https://www.beyondtrust.com/blog/entry/elasticsearch-is-here-privilege-management-for-unix-linux-and-active-directory-bridge
Log file integrity – Keys to remember
Unix and Linux secure log files are an invaluable part of compliance and can play an important role in forensic analysis of activities in a customer environment. Always consider the nature of the data contained within the logs prior to exposing them for any purpose. There is always a balance between data retention, and the liability of retaining data, and it is important to engage the appropriate counsel to assist with developing policies that govern data delivery and exposure.
Legal experts and corporate counsel should understand the exact nature of the data contained in session logs so they can render an opinion providing sound guidance for policy development. Compliance experts should work in concert with legal experts to determine the exact requirements for audit and regulatory concerns. Privacy and risk officers should be engaged to assist with policy development based on the consideration of their programs.
Check out our paper: 15 Server Privilege Management Use Cases for Unix & Linux for more information on common use cases BeyondTrust Privilege Management for Unix & Linux can help you address to reduce cyber risk and improve administration and auditing. We also welcome you to contact BeyondTrust today to directly ask us your PAM questions.
Colin Bretagne, Senior Product Manager
Originally from South Africa, Colin has worked and lived in 3 countries. Through his career, he has worked his way from a Support Engineer to a Technical Manager, before arriving in Montreal Canada in 2009. Colin has extensive experience in hardware and software and has achieved certifications in HP, Novell, Microsoft, Linux, and Pragmatic Marketing. In his spare time, Colin enjoys Rugby, Judo, and is a qualified FA Soccer referee.