OIT Security Event Logging Standard

Introduction

Security event logging is a critical component of Portland State University's technology infrastructure and information security programs. With the continuous increase of emerging technologies and their associated security threats, authentication and access logging from critical systems, applications, and services have become an essential control to identify, respond, and prevent operational problems and security incidents.

Furthermore, event logs recording assists in business recovery activities and compliance requirements dictated by federal, state, and local regulations applicable to the University.
 

Scope

Authentication and access logging should be implemented on all PSU information technology hardware (including networking equipment, IoT devices, cameras, servers, and client endpoints), web servers, software, databases, and cloud infrastructure by the service administrator.

This standard applies to any university system or service and includes resources hosted in the cloud or systems identified by the Information Security Team as 'High-Risk' to security operations. 
 

Standards and Procedures

• In-scope assets shall record and retain audit logs sufficient to identify the type of event, the subject that triggered the event, the object impacted by the event, the timestamp, and the status or result of the event. Procurement of products and deployment of services that cannot support this principle must have a documented exception and will be assessed on a case-by-case basis.
• Access to logs shall be authorized by system owners.
  • The authorization process for users or third parties to gain access to logs must be based on the need-to-know principle.
  • A user is entitled to review logs which unambiguously refer solely to their own activity. Requests should be validated by a manager or the Information Security Team before fulfilled.
• Access to logs in the OIT centralized log management solution must be formally requested from the responsible system administration team. 
  • Requests should be directed to the Linux Application Platform Team, including access to existing indexes or the creation of a new index.
• Third-party sharing of logs with organizations not covered under contract must be approved by the Information Security Team.

Events to be Logged

Service administrators are encouraged to enable log creation whenever any of the following activities are requested to be performed by an in-scope system:

• Create, update, or delete confidential or restricted information, including authentication information such as passwords.
• User authentication and authorization for activities such as user login, logout, or access denial.
• 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 services 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.
• Logs of denied or malicious activity from security systems such as firewalls, IDS/IPS, malware prevention, and network monitoring solutions.

Minimum Elements

Logs shall identify or contain at least the following minimum elements, directly or indirectly:

• Type of action.
• Subsystem performing the action.
• A unique identifier for the subject requesting the action.
• A unique identifier for the object the action was performed on.
• Before and after values when action involves updating a data element, when available.
• 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 event was denied and, where appropriate, allowed by access-control mechanisms.
• Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.
   

Logs Destination, Storage, and Formatting

• Logs shall be forwarded and stored at the central log service managed by OIT when possible. Logs shall be categorized in domains (e.g. Windows, Linux, Client Endpoints) and sent to the appropriate aggregate log file within the central log service. 
• Secondary systems employed to store or process logs shall support the formatting, storage, and processing of logs in such a way as to ensure the integrity and confidentiality of the logs and to support analysis and reporting as required.
• When determined that it is not appropriate or possible to forward and store logs at the central log service, the exception shall be documented in a central registry of such systems. This registry shall be reviewed by the Information Security Team on a biannual basis. 
   

Logs Retention

• Event log data should be retained for a minimum of one year unless different retention requirements are mandated by university policy; federal, state, or local laws; or other regulations, contracts, or agreements applicable to a specific set of systems or services.
  • In situations where retention requirements exceed one year, the Service Offering Manager shall confer with the Log Aggregation Service Manager and Information Security Team to determine an appropriate strategy for their service.
• The Service Offering Manager is responsible to ensure events are logged and forwarded to the central log service. Where practical, logs should be stored locally for a minimum of 30 days.
• The Log Aggregation Service Manager is responsible for ensuring that logs are retained for one year.
   

Log Review & Security Incidents

• Logs must be reviewed within a 24-hour period in response to suspected or reported security events on systems or as requested by the Information Security Team. 
• Security incident investigation must follow the OIT Computer Incident Response Plan. 
• The Security Team might require System Administrators to create and review alerts in a defined frequency based on compliance requirements applicable to specific information technologies.
   

Exceptions

Any exception to this standard must be approved by the Chief Information Security Officer.

Related Policies, Procedures, and Information

• Information Security Policy
• Computer Security Incident Response Standard
• LPT Confluence for Splunk [Log aggregation]
• OIT Service Catalog

Point of Contact

If you have any questions regarding this security standard, please contact the Information Security Team at help-security@pdx.edu.

Definitions