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 that due care and consideration be given 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.
In this blog I will explain the difference between the two and offer up some best practices for maintaining the integrity of log data for legal purposes.
Event Logs and Session Logs – What is the Difference?
For simplicity 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 that was both entered and displayed to a privileged user during a session. Session logs may be stored encrypted, and may only be accessible on specific servers, however, they require greater protection due to the potentially privileged information they contain.
An important distinction between the two is that information in event logs rarely contains any type of Personally Identifiable Information (PII), or other secret information. Since session logs capture everything that takes place during a privileged activity, depending on the nature of the activity, these logs could contain PII.
For example:
A database administrator uses PowerBroker to access an id on a system to troubleshoot a problem with a database that serves 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 that information is not sensitive in most cases.
The session log would contain any information that was displayed within the session, and since the records were visible to the DBA, that PII data is also stored within the session log.
Guidelines for Developing Log Retention Policies
Retention policies should be developed that specifically define how long log data is stored for each type of log, the users who should have access to them, and under what circumstances they may be reviewed and shared. General guidelines related to these log files that should help develop retention policies include some of the following considerations.
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, any information related to the warrant, or subpoena that is requested, must be supplied if it is available. For this reason, it is important to define a retention period, and build automated processes to ensure that data retention complies with that policy.
Retain Log Data for the Minimum Allowable Time Period
Retaining log files for too long a period may expose a company to legal or compliance risks, but retaining them for too short a period 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.
Define Specific Policies for Event Logs and Session Logs
Specific retention policies should be created for both metadata, and session logs. A clearly defined process definition document should be developed to provide to auditors. Auditors may review controls within that document to determine compliance with the policy, and that the process is working as defined. Wherever possible, these processes should be automated.
Define and Automate Log Backups
Retention policies and automation should ensure that any backup or stored copies of retained logs are destroyed as the final part of the data life-cycle. Removing data will reduce the space required for backups, as well as eliminate the risk of data exposure. A clearly defined process definition document should be developed to provide to auditors. Auditors may review controls within that document to determine compliance with the policy, and that the process is working as defined. Wherever possible, these processes should be automated.
Limit Log Access to as Few People as Possible
Both session and 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 PAM program.
In general, it is a good idea to limit the number of people who can access logs to as few as possible. If possible, records of who accessed the logs, and a reason for that access, should be built into the process.
Reasons for accessing the logs should be carefully considered, and a mechanism should be in place to validate that reason.
Common log file review use cases
When determining who should access logs and under what circumstance, consider the following common use cases.
Use Case: Assist with ‘Root Cause Analysis’ for System Outages and Incidents.
When investigating an unscheduled outage on a system, 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 that may be contained in them, it is important that only the pertinent parts be extracted as part of this analysis. Using ‘REDACTED” tags in data output indicates that sensitive (non-pertinent) data was removed. This should be done by a specialized team that understands systems, and can identify sensitive information.
Use Case: Verify that Activities Within a Scheduled Change Took Place as Defined in the Change Management Record.
It is always a best practice to review change records, and to validate that what was performed during the change matches the implementation that was proposed. Using the PowerBroker central console, it is possible to review session command history without revealing the underlying session data.
Use Case: 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. Information that is not pertinent to the investigation, or that is sensitive should be redacted before delivering this data.
Use Case: When Investigating User Activity to Determine Whether it was Malicious or Appropriate.
This use case typically falls under the auspices of an internal investigation into the activities of specific individuals within an environment. It is important that a process be developed that includes guidance from legal, and privacy officers to define the exact circumstances where this can be done.
Use Case: Using Session Recorded Activities to Develop Training, or Procedural Guides as Part of a Documentation Process.
This is a strong benefit of the PowerBroker session logs. When a change goes very well, or is done in such a way that it can be used to train or document an activity, using the session logs to provide step by step instructions for the next change is a best practice. Session logs can be reviewed for sensitive data, and if approved, used to record training videos for certain change activities.
It is important that whenever a new use case is proposed that careful consideration be given to the potential legal, compliance, or privacy risks associated with delivering that information. Rules vary widely by industry, and geographical location, and it is important that experts be engaged as part of this process.
Summary
Log files are an invaluable part of compliance, and can be an important tool in forensic analysis of activities in a customer environment. The nature of the data contained within the logs should always be considered 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 that the appropriate resources be engaged to assist with developing policies that govern data delivery and exposure. Legal experts and corporate counsel should be informed of the exact nature of the data contained in session logs, and they can render an opinion that provides guidance for policy development within an organization. Compliance experts should work in concert with legal experts to determine the exact requirements for audit and regulatory concerns, and privacy and risk officers should be engaged to assist with policy development based on the remit of their programs.
This is an often-overlooked aspect of a privileged access management program, and considering the potential risk in advance of an incident will contribute to a positive outcome during audits, and deliver a healthy PAM posture for any company.
For more information on how PowerBroker for Unix & Linux can help you simplify Unix/Linux security and compliance, download our white paper, “Simplifying Unix & Linux”, or contact us for a demo today.
Chad Erbe, Professional Services Architect, BeyondTrust
Chad Erbe is a Certified Information Systems Security professional (CISSP), with nearly 30 years’ experience in a Unix/Linux administration role. Chad has worked in DoD high-security environments, manufacturing, and with large financial services companies throughout his career. This broad experience has lead him to an architectural role with BeyondTrust where he focuses on Privileged Access Management, particularly in the Unix suite of products. Chad also maintains his PCI ASV certification from the PCI council.