Skip to content
[New School IT logo]

Standard for Event Logging

Introduction

Logging is an essential information security control that is used to identify, respond to and prevent operational problems, security incidents, policy violations, and fraudulent activity. Logging facilitates the optimization of system and application performance and assists in business recovery activities. In many cases, logging may be required in order to comply with international, federal, state, and local laws and regulations.

Logging also provides system administrators, supervisors, and compliance officers with information useful for diagnostics and auditing.

Purpose

This Standard details the requirements for event logging to support information security and also addresses some operational needs to support availability.

Scope

This standard applies to all university systems that are used to Process Institutional Information classified at Protection Level PL-3 or above and/or or Availability Level AL-3 or above, irrespective of whether they are maintained by The New School or a third party on the university’s behalf or whether they are accessed from on-campus or off-campus locations.

A “system” is any IT Resource to which the safeguards described in this standard can be applied. Examples of systems include, but are not limited to:

  • Desktop and laptop computers running general-purpose operating systems such as Windows, Mac OS X, and Linux, when those computers are being used to perform work governed by a grant, contract, or regulation that requires event logging
  • Server computers (including virtual servers) running general-purpose operating systems such as Windows and Linux
  • Web-based applications (generally, any application accessed via a web browser)
  • Client-server applications (generally, any application using a “fat” client)
  • Network server applications, such as a VPN or an FTP server
  • Databases

This standard does not apply to:

  • End-user devices owned and used by students for purposes of attending the university and completing coursework
  • Single-user desktop and laptop computers, except as described above
  • Personal or non-New School devices not managed by the university

Definitions

Special terms used in this document will be Capitalized and underlined, signifying that they have special meaning. A comprehensive glossary of terms, with examples, can be found at https://ispo.newschool.edu/glossary/.

Requirements

The Information Security and Privacy Office identifies security and operational concerns to establish event-logging requirements. IT Workforce Members must ensure the implementation of the requirements detailed in this section.

Plan and inventory

IT operational areas must establish a logging plan. The plan must include:

  • A method to inventory systems that are required to log events for information security purposes
  • Steps to manage information security risk by assessing risk levels and resources for logging
  • The level(s) of logging detail to be implemented
  • Centralized logging
  • Log storage
  • Log access
  • Log monitoring
  • Time synchronization
  • Testing plan(s) and interval(s)
  • Gaps and mitigations

Areas processing, storing, or transmitting Institutional Information classified at Protection Levels PL-3 or PL-4 must submit and review their plan with the Information Security and Privacy Office at inception and whenever material changes to the plan are implemented.

Log details

When managing information security risk within their areas of responsibility, IT operational areas and other designated individuals have some flexibility in determining the type and amount of detail contained in system logs in order to achieve the desired outcome. The following requirements, however, do apply:

See Logged Events Examples.

Event sources

IT Workforce Members must include all relevant event sources that are needed to manage information security risk in the area’s logging implementation. Possible event sources include, but are not limited to:

  • Access control systems/physical security
  • Application appliances
  • Cloud services (e.g., IaaS, SaaS, PaaS)
  • Databases
  • End points
  • Industrial control systems
  • Internet of Things (IoT) devices
  • Network devices
  • Printers, scanners, and multifunction devices
  • Security and other network-attached appliances
  • Security devices or systems
  • Server/OS
  • Systems (Applications)

Note

For requirements like those found in the PCI DSS (credit cards), Gramm–Leach–Bliley Act (GLBA—impacts student loans and other financial transactions) and NIST 800-171 (supporting financial aid and some research contracts), application logs will also need to identify who accesses and who changes records.

Segregated log storage and tamper protection

A copy of log data must be stored on a separate logical device that is protected from unauthorized access with at least the same control set as the source system. This is required for all:

and recommended for other systems.

Logging facilities and log information must be protected against tampering, modification, destruction, and unauthorized access.

Time synchronization

System clocks must be synchronized to an authoritative time source. In order of decreasing preference, acceptable synchronization methods are Network Time Protocol to multiple clocks from pool.ntp.org, Network Time Protocol to time.newschool.edu, Windows Time Service, one-per-day sync (set clock) with time.newschool.edu.

Timestamp format

Timestamps must not be truncated or abbreviated in any way and must be formatted in accordance with RFC 3339 (preferred) or ISO 8601:2004.

Log management framework

For Institutional Information classified at Protection Levels PL-3 or PL-4, event logging must use ISPO-approved logging tools and framework(s).

Example frameworks and tools include, but are not limited to:

  • Syslog
  • Windows event log
  • CLF/ELF for web servers
  • GELF (Graylog Event Log Format)
  • log4j and log4net (applications)
  • SNMP (network)
  • ELK

Handling sensitive information in logs

Log management procedures require appropriate handling of sensitive information. IT Workforce Members must apply these controls:

  • Logs containing Institutional Information classified at Protection Levels PL-3 or PL-4 must require the same security controls as the Institutional Information they contain.
  • Logs must be only available on a need-to-know basis.
  • All transmissions of logs must require secure protocols and reliable mechanisms.
  • Change management processes must be followed when erasing, purging, or trimming event logs outside of standard log rotation procedures (e.g., to reclaim space in a full file system).

IT Workforce Members must not log the following information:

  • Social Security Numbers (SSN) or Individual Taxpayer Identification Numbers (ITIN)
  • Unencrypted financial information (e.g., personal account numbers, financial account numbers, credit card numbers, etc.)
  • Cleartext authentication credentials (e.g., passphrases, passwords, secret questions)
  • Other Institutional Information classified at Protection Levels PL-3 or PL-4

Use of a SIEM

As of this writing, there is no requirement to transmit logs to a Security Incident and Event Management (SIEM) system.

Logging actions of privileged users

For Institutional Information classified at Protection Level PL-2 or higher and IT Resources classified at Availability Levels AL-3 or AL-4, actions performed by privileged user accounts in performance of their duties must be logged.

Limiting administrator access to logs

When possible, IT Workforce Members acting as system administrators on systems classified at Protection Levels PL-3 or PL-4 and Availability Levels AL-3 or AL-4 must not have permission to erase, deactivate, or modify logs of their own activities.

Log retention

IT Workforce Members must retain logs based on:

  • Applicable record retention schedules
  • Contractual obligations
  • Litigation holds, preservation orders
  • Applicable regulatory requirements
  • Other prescribed retention requirements

Logged events examples

System logging configurations (i.e., which entries and data fields are sent to the centralized log servers, what log format should be used) must be established to manage operational and security risks.

The Workforce Member’s ability to configure each log source is dependent on the features offered by that particular type of log source. For example, some log sources offer very granular configuration options, while some offer no granularity at all—logging is simply enabled or disabled, with no control over what is logged.

When planning what details to log, IT Workforce Members should consider:

  • The classification of Institutional Information and/or the system(s)
  • The past experiences of system vulnerability, exploitation and/or misuse
  • The extent of system interconnectedness
  • The primary purpose of logging for the system (operational, security, or both)
  • The effects on system performance
  • The costs of logging and reviewing log data vs. security and operational risks

Logged events might include, but are not limited to:

  • Access and access attempts to root, administrator, or other privileged credentials
  • Access to audit logs
  • Account activation (enabled)
  • Account creation
  • Account de-activation
  • Account lockouts
  • Account login with explicit credentials
  • Activation and deactivation of protection systems (e.g., anti-virus, intrusion detection, encryption, and file integrity systems)
  • Alarms raised by systems (e.g., console alerts or messages, system log exceptions, network management alarms, alarms raised by access control systems).
  • Application error
  • Application hang
  • Application/server reboot
  • Authentication failure and login failures
  • Authentication success and login success
  • Boot events
  • Changes to IT Resource(s) or system configuration
  • cron events
  • Domain Controller authentication events
  • Event log change
  • Event log cleared
  • Failed logon attempts
  • Firewall and security tool rule changes (add, delete, modify, suspend, etc.)
  • Group membership changes (created, changed, deleted)
  • Group or other system policy failed to load
  • Kernel events
  • Locked out
  • Login types
  • Modifications to privileged groups
  • Name change
  • Other authentication or account management events, which can include, but are not limited to:
    • Kerberos authentication ticket (TGT) requests
    • Kerberos pre-authentication failures
    • Kerberos authentication ticket request failures
    • Kerberos events
    • Kerberos failure codes
  • Password change (by privileged user)
  • Password change (by user)
  • Privilege change
  • Proxy events
  • Remote desktop sessions (connect, reconnect, disconnect)
  • Screensaver events
  • Security tool detection events
  • Service starts and stops
  • Successful logons
  • System or application audit or logging policy change
  • Termination of database related processes
  • The addition of a user to a privileged group
  • The creation of a new privileged user account
  • Unlocked
  • User initiated log-off
  • Workstation locked events

For each logged security event, including the ones above, the following must be recorded, as appropriate:

  • User identification
  • Type of event
  • Date and time
  • Success or failure indication
  • Data accessed
  • Application, program, or utility used
  • Origination of event (e.g., network address)
  • Target of event (e.g., network address, host name)
  • Protocol
  • Identity or name of affected data, information system, or network resource

Open source workstation logging baseline projects (review required before use):

Note

The list above provides examples and is not exhaustive. Operating systems, applications, run-time environments (or run-time containers), security tools and devices vary in their logging capabilities and event detail. IT Workforce Members should use best practice guides and tools from SIEM vendors and other sources to tune what is logged locally and what is forwarded to centralized tools. This is important for detection, response, and recovery from adverse incidents. This approach is necessary for both security and operational events.

References

Review

This standard is reviewed on a periodic basis and updated as necessary by the Information Security and Privacy Office to ensure it remains accurate, relevant, and fit for purpose.

Document history
Date Author Description
Jun 2020 D. Curry
  • Initial publication

Parts of this standard are adapted from the University of California’s Event Logging Standard, coordinated by Robert Smith, the contents of which are used with permission.