Log Management Standard
Scope
This document applies to all servers and network devices that handle, accept network connections, or make access control (authentication and authorization) decisions for Loyola Protected information, as defined within the Data Classification Policy.
Purpose
Checking logs daily minimizes the amount of time and exposure of a potential breach. To identify the specific requirements that information systems must meet in order to generate appropriate audit logs and integrate with the University’s log management strategy.
Standard
The University Information Security Office (UISO) will perform a daily review of security event logs as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM) systems, etc. as is necessary to identify potential issues. Additionally, the UISO will monitor and analyze alerts and distribute to appropriate personnel.
The following events are reviewed at least daily:
- All security events
- Logs of all system components that store, process, or transmit Card Holder Data (CHD) and/or Sensitive Authentication Data (SAD)
- Logs of all critical system components
- Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
Underlying requirements
All covered systems shall record and retain audit-logging information sufficient to answer the following questions:
- What activity was performed?
- Who or what performed the activity, including from where or from which system the activity was performed?
- What the activity was performed on the covered system?
- When was the activity performed?
- With which program(s) was the activity was performed?
- What was the status (such as success vs. failure), outcome, or result of the activity?
Activities to be logged
Logs shall be created whenever any of the following activities are requested to be performed by a covered system:
- Create, read, update, or delete Loyola Protected or Loyola Sensitive information, and authentication information such as passwords
- Initiate a network connection
- Accept a network connection
- User authentication and authorization for activities covered in #1 such as user login and logout
- Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes
- System, network, or service configuration changes, including installation of software patches and updates, or other installed software changes
- Application process startup, shutdown, or restart
- Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault
- Detection of suspicious/malicious activity such as from an Intrusion Prevention System (IPS), anti-virus system, or other security systems.
Elements of the log
Such logs shall identify or contain at least the following elements, directly or indirectly. In this context, the term "indirectly" means unambiguously inferred.
- Type of action – examples include authorize, create, read, update, delete, and accept network connection.
- Subsystems performing the action – examples include process or transaction name, process or transaction identifier.
- Identifiers (as many as available) for the subject requesting the action – examples include user name, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
- Identifiers (as many as available) for the object the action was performed on – examples include file names accessed, unique identifiers of records accessed in a database, query parameters used to determine records accessed in a database, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
- Before and after values when action involves updating a data element, if feasible.
- Date and time the action was performed, including relevant time-zone information if not in Universal Time. This date and time shall be synchronized using the University’s NTP servers.
- Whether the action was allowed or denied by access-control mechanisms.
- Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.
Formatting and storage
The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. All audit logs must be kept for one year, with three months available online.
Note that the construction of an actual enterprise-level log management mechanism is outside the scope of this document. Mechanisms known to support these goals include but are not limited to the following:
- Microsoft Windows Event Logs collected by a centralized log management system;
- Logs in a well-documented format sent via syslog, syslog-ng, or syslog-reliable network protocols to a centralized log management system; and
- Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the requirements of this document.
Access to Log Files
All access to log files and audit trails shall be limited to a user’s job-related need to know, as per the ITS Access Control Policy. Audit trails shall be protected from unauthorized modifications. All log information is transmitted, near real time to a SIEM for aggregation and analysis.
Exceptions
Exceptions to this policy will be handled in accordance with the ITS Security Policy.
Review
This policy will be maintained in accordance with the ITS Security Policy.
Appendix
Documents Referenced
History
- September 8, 2008: Initial Standard
- June 24, 2015: Annual review for PCI Compliance
- July 7, 2015: Added information to comply with PCI-DSS 10.6.1
- April 14, 2016: Annual review for PCI Compliance
- June 7, 2017: Defined CHD and SAD, annual review for PCI Compliance
- May 14, 2018: Annual review for PCI Compliance
- June 27, 2019: Annual review for PCI Compliance
- May 27, 2020: Annual review for PCI Compliance
Scope
This document applies to all servers and network devices that handle, accept network connections, or make access control (authentication and authorization) decisions for Loyola Protected information, as defined within the Data Classification Policy.
Purpose
Checking logs daily minimizes the amount of time and exposure of a potential breach. To identify the specific requirements that information systems must meet in order to generate appropriate audit logs and integrate with the University’s log management strategy.
Standard
The University Information Security Office (UISO) will perform a daily review of security event logs as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM) systems, etc. as is necessary to identify potential issues. Additionally, the UISO will monitor and analyze alerts and distribute to appropriate personnel.
The following events are reviewed at least daily:
- All security events
- Logs of all system components that store, process, or transmit Card Holder Data (CHD) and/or Sensitive Authentication Data (SAD)
- Logs of all critical system components
- Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
Underlying requirements
All covered systems shall record and retain audit-logging information sufficient to answer the following questions:
- What activity was performed?
- Who or what performed the activity, including from where or from which system the activity was performed?
- What the activity was performed on the covered system?
- When was the activity performed?
- With which program(s) was the activity was performed?
- What was the status (such as success vs. failure), outcome, or result of the activity?
Activities to be logged
Logs shall be created whenever any of the following activities are requested to be performed by a covered system:
- Create, read, update, or delete Loyola Protected or Loyola Sensitive information, and authentication information such as passwords
- Initiate a network connection
- Accept a network connection
- User authentication and authorization for activities covered in #1 such as user login and logout
- Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes
- System, network, or service configuration changes, including installation of software patches and updates, or other installed software changes
- Application process startup, shutdown, or restart
- Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault
- Detection of suspicious/malicious activity such as from an Intrusion Prevention System (IPS), anti-virus system, or other security systems.
Elements of the log
Such logs shall identify or contain at least the following elements, directly or indirectly. In this context, the term "indirectly" means unambiguously inferred.
- Type of action – examples include authorize, create, read, update, delete, and accept network connection.
- Subsystems performing the action – examples include process or transaction name, process or transaction identifier.
- Identifiers (as many as available) for the subject requesting the action – examples include user name, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
- Identifiers (as many as available) for the object the action was performed on – examples include file names accessed, unique identifiers of records accessed in a database, query parameters used to determine records accessed in a database, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
- Before and after values when action involves updating a data element, if feasible.
- Date and time the action was performed, including relevant time-zone information if not in Universal Time. This date and time shall be synchronized using the University’s NTP servers.
- Whether the action was allowed or denied by access-control mechanisms.
- Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.
Formatting and storage
The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. All audit logs must be kept for one year, with three months available online.
Note that the construction of an actual enterprise-level log management mechanism is outside the scope of this document. Mechanisms known to support these goals include but are not limited to the following:
- Microsoft Windows Event Logs collected by a centralized log management system;
- Logs in a well-documented format sent via syslog, syslog-ng, or syslog-reliable network protocols to a centralized log management system; and
- Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the requirements of this document.
Access to Log Files
All access to log files and audit trails shall be limited to a user’s job-related need to know, as per the ITS Access Control Policy. Audit trails shall be protected from unauthorized modifications. All log information is transmitted, near real time to a SIEM for aggregation and analysis.
Exceptions
Exceptions to this policy will be handled in accordance with the ITS Security Policy.
Review
This policy will be maintained in accordance with the ITS Security Policy.
Appendix
Documents Referenced
History
- September 8, 2008: Initial Standard
- June 24, 2015: Annual review for PCI Compliance
- July 7, 2015: Added information to comply with PCI-DSS 10.6.1
- April 14, 2016: Annual review for PCI Compliance
- June 7, 2017: Defined CHD and SAD, annual review for PCI Compliance
- May 14, 2018: Annual review for PCI Compliance
- June 27, 2019: Annual review for PCI Compliance
- May 27, 2020: Annual review for PCI Compliance