PCI-DSS Requirement 10: Configuration Port Security

By Tom Kearns

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate a broad adoption of consistent data security measures globally. PCI-DSS includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. It is a comprehensive standard that is intended to help organizations proactively protect customer account data.

PCI-DSS Version 2.0, Requirement 10 covers tracking and monitoring of all access to network resources and cardholder data. The intent of this requirement is that logging mechanisms and the ability to track privileged user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. This includes all actions, taken by any individual with root or administrative privileges to configuration ports.

My IT operations customers often struggle with the intent of this requirement as it relates to providing highly privileged access utilizing configuration ports. Since configuration ports are, by default, the emergency access point for every IT device, they are critical for improving mean time to repair (MTTR). Common vendor names for these type of ports are iLO2 (HP), DRAC (Dell), ALOM, ILOM (Sun/Oracle) and CIMC (Cisco).

For a discussion on privileged access to configuration ports, the significant threat they pose as it relates to the intent of PCI-DSS Version 2.0, Requirement 10, see our whitepaper on this subject at: http://www.tditechnologies.com/whitepaper-pci-requirement-10-configuration-ports

ConsoleWorks provides a comprehensive solution for tracking, monitoring, analyzing and alerting on actions taken by privileged individuals with administrative privileges as required by PCI-DSS V2.0, Requirement 10.

CIP-005-4 R5 in the IT Foundation

By Pam Johnson

CIP-005-4 is focused on Electronic Security Perimeter(s). Section R5 is titled “Documentation Review and Maintenance” and is further defined as:

R5. Documentation Review and Maintenance — The Responsible Entity shall review, update, and maintain all documentation to support compliance with the requirements of Standard CIP-005-4a. R5.1. The Responsible Entity shall ensure that all documentation required by Standard CIP-005-4a reflect current configurations and processes and shall review the documents and procedures referenced in Standard CIP-005-4a at least annually. R5.2. The responsible Entity shall update the documentation to reflect the modification of the network or controls within ninety calendar days of the change. R5.3. The Responsible Entity shall retain electronic access logs for at least ninety calendar days. Logs related to reportable incidents shall be kept in accordance with the requirements of Standard CIP-008-4.

There are really two categories of information this section refers to: 1) Access records and 2) Reportable incidents. ConsoleWorks automatically captures and generates compliance records for privileged user access over all interfaces managed by ConsoleWorks. The information ConsoleWorks captures includes each access (what was accessed, who accessed it, when the access occurred) along with the actual down-to-the-keystroke records of what was actually done in each of these access sessions. This data is digitally signed to meet audit requirements as a true forensic activity log. Of course, ConsoleWorks does not do this for interfaces that are not managed by ConsoleWorks.

In addition, if desired ConsoleWorks can also capture and record any/all data output by the devices it manages – data that resides in log files or that is output as an SNMP Trap or SYSLOG message. Because there is no real work involved other than minor configuration, the best practices recommendation is to look at both the output stream (information output by the hardware/software of an IT asset) and the input stream (actions taken by privileged users). The capture and reporting by ConsoleWorks is automatic once the system is setup and configured.

Reportable incidents are a different story altogether. These are the events as defined by NERC-CIP that must be detected and then the appropriate action taken based on the nature and severity of the incident. For this issue ConsoleWorks uses its NERC-CIP IEM (Intelligent Event Module) to detect NERC-CIP incidents in the input/output information streams to identify NERC-CIP incidents properly related to the NERC-CIP requirements. Once the NERC-CIP IEM is setup, ConsoleWorks performs detection, alerting, recording, and report generation automatically.

The primary concern in meeting documentation requirements is that they meet internal and external stakeholder requirements with the least amount of effort and manual work possible. ConsoleWorks is directly aligned to this goal, dramatically simplifying the effort behind producing the appropriate NERC-CIP documentation. The information is retained by ConsoleWorks until such time as an administrator archives or deletes it.