Logging and Activity Review

Overview

This standard provides guidelines on the monitoring and logging of the UVa Medical Center's information resources including the UVA Medical Center's network and communication systems.

Purpose

This standard is established to protect the integrity, availability, and confidentiality of information; to prevent loss of service; and to comply with legal requirements. This standard helps ensure that all information systems generate appropriate audit logs that cannot be modified by system owners.

Scope

This standard applies to all UVA Medical Center System Administrators and HIT Security Staff that install, configure, and maintain UVA Medical Center information systems, network and communication systems

Description

Without frequent monitoring and logging, it is difficult to assess the effectiveness of access controls.  Unauthorized access can remain undetected, enabling information to be disclosed to persons with possible malicious or fraudulent intent.

Access to UVa Medical Center information systems, networks, and communication shall be logged and monitored to identify potential misuse.  System access must be monitored regularly to prevent attempts at unauthorized access and to confirm that access control systems are effective.

Logs are one of the primary tools used by Administrators to detect and investigate attempted and successful unauthorized activity and to troubleshoot problems.  Detailed procedures that support this policy shall be developed to protect against log security risks such as:

  • Log administration - the contents of system logs should be protected from unauthorized access, modification, and/or deletion.  Write once read many (WORM) drives may be an acceptable solution.
  • Emergency access to systems shall only be used in extreme circumstances and only when authorized by IT Management.  Emergency access may by-pass traditional security controls and access to information resources or Company data shall be logged.
  • As a log approaches its maximum size, it can either overwrite old events or stop logging new events.  This makes it susceptible to attacks in which an intruder can flood the log by generating a large number of new events. A partial defense against this is to increase the maximum log size so that a greater number of events is required to flood the log.
  • System Administrators and those with operating system command line access can disable or circumvent access control and audit log mechanisms. Log settings should be set to track and record log policy changes (audit policy change setting).
  • Given the ability of administrators to manipulate log files to cover unauthorized activity, UVa Medical Center IT Security Office shall create of separation of duties between operations and security monitoring.  A frequent backup of the log to a server is only accessible to the IT security staff.

Logs shall be kept secure and are only available to personnel authorized by the Director of IT Security.  Such logs shall only be kept as outlined in the University of Virginia Records Management on Records Retention and Disposition Schedules.

UVa Medical Center’s information systems (servers, workstations, firewalls, routers, switches, communications equipment, etc.) shall be monitored and logged to:

  • Ensure use is authorized
  • Manage and administer systems
  • Protect against unauthorized access
  • Verify security procedures
  • System and operational security
  • Comply with UVa Medical Center’s policies and procedures
  • Detect and prevent crime

 

A. Underlying Recommendations

All systems that handle confidential information, accept network connections, or make access control (authentication and authorization) decisions shall record and retain audit logging information:

  • Determine the activity that was performed
  • Who or what performed the activity, including where or on what system the activity was performed (subject)
  • Systems involved (object)
  • When the activity was performed
  • Tools used
  • The status (such as success vs. failure), outcome, or result of the activity

Any information systems that cannot not meet the recommendations listed above must complete the Security Exception Form located here:  https://hscssqlrm.hscs.virginia.edu/arsys/shared/login.jsp

 

B.  Activities To Be Logged

Logs shall be reviewed when an incident has occurred. Procedures should verify that logging is active and working properly:

  • Ensure the event has been properly classified
  • Review the log for indication of performance delays
  • Ensure that compliance related logging cannot be “turned off”
  • Verify access to log file is properly restricted
  • To assist with investigations, systems should have their date and time synchronized using Network Time Protocol (NTP)

 

Recommendations for activities logged:

  • Write or delete confidential information, including confidential authentication information such as passwords.
  • Write or delete information.
  • Initiate or accept a network connection.
  • User authentication and authorization 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 services configuration changes, including installation of software patches and updates, or other installed software changes.
  • Application process shutdowns.
  • Application process failures 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 Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.

 

C.  Elements Of The Log

System events and activities that should be monitored and logged to include:

  • System administrator and system operator activities
  • System start-ups and shut-downs
  • Logging start-ups and shut-downs
  • Backups
  • Exception events
  • Security events
  • Protection software events
  • Intrusion Detection Systems (IDS) and Intrusion Prevention Systems
  • Modifications to data characteristics including permissions, location, file type
  • Authentication successes and failures (e.g. log in, log out, failed logins)

Application logging requires more than relying on server logs.  Application logs help identify security incidents, establish baselines, providing information about problems and unusual conditions, assist with incident investigation, and help detect attacks.  Application events and activities that should be monitored and logged include:

  • Application authentication (e.g. successes, failures, logouts)
  • Data audit trails (e.g. access to sensitive data, adding data, modifying data, deleting data, exporting and importing data)
  • Input validation failures (e.g. protocol violations, unacceptable encodings, invalid parameter names and values)
  • Output validation failures (e.g. database record mismatch, invalid data encoding)
  • Suspicious behavior (e.g. multiple records deleted in a short period of time, invalid access attempts)
  • Session management failures (e.g. cookie session identification value modification)
  • Application errors and events (e.g. syntax and runtime errors, connectivity problems, third party service error messages, file system errors, sequencing failure)
  • Higher-risk functionality (e.g. network connections, adding and deleting users, changes to privileges, assigning users to tokens, adding or deleting tokens, use of administrative privileges, access by application administrators, access to sensitive data, use of data encrypting keys, key changes, creating and deleting system-level objects, data import and export including screen-based reports, submission of user-generated content)
  • Legal and other opt-ins (e.g. permissions to access credit history, terms of use, permission to receive marketing communications)
  • Security events or warnings

Log entries and automated audit trails should include:

  • Host name
  • Date
  • Time
  • User initiating action (e.g. user ID)
  • Event type
  • Result status (e.g. success, failure, defer)
  • Resource (e.g. identity or name of affected data, component)
  • Location (e.g. IP address or location)
  • Severity of event (e.g. emergency, alert, fatal error, warning, information only)
  • Other (e.g. parameters, debug information, system error message)

D.  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.  Mechanisms known to support these goals include but are not limited to the following:

  • Microsoft Windows Event Logs should be collected by a centralized log management system.
  • Logs should be stored in a documented format and sent via reliable network protocols to a centralized log management system.
  • Logs stored in a SQL database that itself generates audit logs in compliance with the requirements of this Policy.
  • Other open logging mechanisms supporting the above requirements.

Within the scope of a Security Incident/Investigation the HSTS IT Security Office shall be responsible for:

  • Ensuring a review of activity audit logs, access reports for security incidents.  Approving the types of logs and reports to be generated, review activities to be performed, and procedures that describe the specifics of the reviews.
  • Procedures that specify monitoring log-in attempts, reporting discrepancies, and processes used to monitor log-in attempts.
  • Procedures that specify audit controls, hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use sensitive information.  Procedures ensure that the audit controls meet security requirements by recording and examining activity related to sensitive information.

Document Supporting Resources