Purpose

This document establishes a formal network monitoring standard and outlines the related requirements specified in the Payment Card Industry Data Security Standards that must be implemented in all University of Maryland (UMD) network infrastructures that process cardholder data.

Top

Additional authority

The following standards help guide the content of this document: Payment Card Industry Data Security Standard - Requirement 10.

Top

Scope

This standard applies to all UMD network infrastructure used to transmit or process cardholder data. Payment Card Industry Data Security Standards (PCI DSS) consider a full primary account number accompanied by cardholder name, expiration date, a service code, information from a magnetic strip or card chip, or a personal identification number as cardholder data.

Top

Standard

Logging mechanisms and the ability to track user activities are critical for effective forensics and vulnerability management. The presence of logs allows thorough tracking and analysis if something goes wrong. Determining the cause of a compromise is very difficult without system activity logs.

NOTE: As a general rule, every PCI Standard should be reviewed annually and updated as needed to reflect changes to business objectives or the risk environment.

Top

Requirements

• Auditing must be enabled to track all individual user, administrative and root account access to system components and cardholder data.
• Periodic checks must be performed to ensure audit trails are continuously being captured.
• Automated audit trails for all system components must be implemented for reconstructing these events:
  • Individual user access to cardholder data.
  • Actions taken by any individual with root or administrative privileges.
  • Access to all audit trails.
  • Invalid logical access attempts.
  • Use of, and changes to, identification and authentication mechanisms (including creation of new accounts and elevation of privileges).
  • All changes, additions or deletions to accounts with root or administrative privileges.
  • Initialization, stopping or pausing of the audit logs.
  • Creation and deletion of system-level objects.
• Audit trail entries for all system components must be recorded for each event, including at a minimum:
  • User identification.
  • Type of event.
  • Date and time.
  • Success or failure indication.
  • Origination of event.
  • Identity or name of affected data, system component or resource.
• Periodic checks must be performed to ensure that all clocks are set to the correct time.
• Limit who has access to view and modify audit trails.
• Audit trail files must reside in a location on the network that is not easily accessible.
• File integrity monitoring or change detection software must be utilized to ensure that alerts are generated when audit trail files are altered.
• Audit trails must be automatically copied to Splunk to protect the integrity of its contents.
• Review logs and security events for all system components to identify anomalies or suspicious activity. Perform critical log reviews at least daily.
• Documented procedures must be in place to guide the review of logs and security events. These procedures must include:
  • Who performs log reviews.
  • What is considered suspicious activity.
  • What steps should be taken if suspicious activity is discovered.
• Documented proof that log and security events reviews have been performed must be retained for the same time period that audit trails are retained.
• Retain audit trail history for at least one year; at least three months of history must be immediately available for analysis.
• Service providers must implement a process for timely detection and reporting of failures of critical security control systems.
• Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

Top