Friday, March 16, 2012

PCI Practices for Protecting Management Infrastructure

[Update: Added content in a downloadable spreadsheet]

A peer asked me a question about best practices for hardening a management environment - not necessarily related to PCI. It just so happens I like the results of the PCI-DSS as a starting point to answering this question. This post covers PCI - of course - but it can also be applied to other management environments.

Controls Commensurate with Your Risk.
I've written in detail about the need to implement controls commensurate with your risk. There are several approaches, some quite lengthy and difficult to navigate. I'm not naive to the volumes of material and wide range of preferences... The objective here is to protect data, using a set of easy to navigate, understand, and effective controls. I have several friends at prominent security companies that fail to see the benefit of a structured approach to security, and instead prefer to wing it based on the latest technology and a security magazine article.

PCI just happens to care about credit card data. The management systems that connect into this sensitive environment must be protected. The PCI-SSC (the council) recognized this, and mandated controls to protect the management systems/functions connecting into a sensitive environment. Here is a compiled list of controls derived from the PCI-DSS (the PCI standard). I took some liberty to consolidate, clarify, and add brief commentary as appropriate.


Secure Management Environment Assumptions:
  • Not Internet accessible 
  • Is considered essential to protected environment
  • Does not store sensitive data (e.g. CHD, IP, ePHI, PII, etc)
  • Does not process  sensitive data (e.g. CHD, IP, ePHI, PII, etc)
  • Facility controls apply but are not discussed below.  


Original PCI Assumptions:
  • Not Internet accessible (PCI-DSSv2 Req. 1.2, 1.3, and appropriate subsections) 
  • Is part of the CDE (PCI-DSSv2 Req. 1.3 all) 
  • Does not store CHD. (PCI-DSSv2 Req. 3 and others) 
  • Does not process CHD. (PCI-DSSv2 Req. 6 and others) 
  • Facility controls apply but are not discussed below. (PCI-DSSv2 Req. 9) 

Systems fall within the scope for PCI compliance if they are used to manage the CDE. PCI scope encompasses all of the following for a merchant:
  • Primary systems: Any system, component, device, application, that processes, stores, or transmits cardholder data (CHD) 
  • Secondary systems: These systems can connect to the primary systems without going through a (specifically) Stateful Packet Inspection (SPI) firewall. 
  • Administrative systems: Includes all management tools and systems which have direct access to the primary (and peripheral) scope systems. 
Requirements Summary:
The current standard and navigation document provide additional guidance. These documents and many other supporting materials are found on the PCI Security Standards Council website: https://www.pcisecuritystandards.org/security_standards/documents.php

Key Administrative and General Configuration Requirements:
Applies to All Components

Requirement

Summary Details

Reference

Supply a network diagram.
Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data.
1.1.2.a
Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system.
Document ALL services, protocols, and ports used. Use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc. If these insecure services are not necessary for business, they should be disabled or removed.
1.1.5 (a-b),
2.2.2 (a-b)
Default passwords are not allowed.
All default passwords must be changed; every component must have a unique password.
2.1
Develop and use hardened configuration standards.
Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Specific requirements include (among others):
• Configure system security parameters to prevent misuse (2.2.3)
• Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers (2.2.4.a)
2.2 (a-c),
2.2.3 (a-c),
2.2.4 (a-c)
Encrypt all non-console administrative access.
Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
• Verify strong encryption for authentication (2.3.a)
• Disable Telnet, other remote login commands (2.3.b)
• Require encrypted administrative access (2.3.c)
2.3 (a-c)
Install all vendor supplied security patches, including all critical patches within one month of release.
Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.
6.1 (all)
Restrict account creation and access rights to least privileges and job function using an automated access control system.
Limit access to system components and cardholder data to only those individuals whose job requires such access, including:
• Lease privileges (7.1.1)
• Documented roles and authorizations (7.1.2-3)
• Using an access control system (7.1.4, 7.2 all)
7.1 (all)
7.2 (all)
Provide all users with a unique user ID. Group IDs are not allowed.
All users must have a unique user ID before allowing them to access system components or cardholder data.
8.1
8.5.8 (a-c)
Authenticate all internal user IDs.
In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users: something you know, have, or are.
8.2
Deploy two-factor authentication for all remote CDE access.
Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dial- in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.)
Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.
8.3
Encrypt all passwords during transmission and storage.
Render all passwords unreadable during transmission and storage on all system components using strong cryptography.
8.4
Enforce strong password controls.
Ensure proper user authentication and password management for non-consumer users and administrators on all system components including:
• First time passwords unique and require immediate change (8.5.3)
• Vendor account remote access only enabled when needed and monitored during use (8.5.6.a-b)
• Do not use group, shared, or generic accounts and passwords, or other authentication methods (8.5.8.a-c)
• Passwords change every 90 days (8.5.9)
• Additional strong password controls for construction (7 char; alpha-numeric), attempts (6), lockout (30 min), idle timeout (15 min), password history (4) (8.5.10-15)
8.5 (all)
SIEM – Log management: Track and monitor all access to network resources and cardholder data to unique users.
Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user, including:
• Detailed automated audit trails for all events on system components (10.2 all)
• Detailed automated audit trail entries containing all information (10.3 all)
• Audit trail protection (10.5 all)
• Daily log reviews (10.6)
• Audit trail retained for one year (10.7)
10.1
10.2 (all)
10.3 (all)
10.5 (all)
10.6 (all)
10.7 (all)
NTP – Implement time-synchronization technology.
Using time-synchronization technology, synchronize all critical system clocks and times (e.g. using NTP) and ensure that time is correct, protected, and received from industry accepted sources.
10.4 (all)
Perform quarterly vulnerability scans.
Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
• Review the scan reports and verify that the scan process includes rescans until passing results are obtained, or all "High" vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved. (11.2.1.b)
• Internal (private) IPs must be performed by a qualified resource (e.g. formal training, experience). (11.2.1.c)
• External (public) IPs must be performed by an Approved Scanning Vendor (ASV). (11.2.2 all)
• Rescan after any significant changes. (11.2.3 all)
11.2.1 (all)
11.2.2 (all)
11.2.3 (all)
Perform annual penetration tests.
Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following:
• Network layer penetration test (11.3.1)
• Application layer penetration test (11.3.2)
11.3 (all)

Additional Key Network Requirements

Requirement

Summary Details

Reference

Prohibit direct public access between the Internet and any system component in the cardholder data environment (CDE).
If the management is determined to be part of the CDE, then a DMZ bounded by SPI firewalls must be implemented to separate the management from non-CDE networks, whether internal or external. There are several requirements regarding the specific configuration of the firewall to provide specific access controls, limiting the types of acceptable connections and addresses. See the standard for additional details.
1.3 (all)
IDS/IPS – Monitor perimeter access to the CDE and critical points inside the CDE.  
IDS/IPS devices should be implemented such that they monitor inbound and outbound traffic at the perimeter of the CDE as well as at the critical points within the CDE. Critical points inside the CDE may include database servers storing cardholder data (CHD), cryptographic keys, processing networks, or other sensitive components as determined by an entity's environment and documented in their risk assessment.
11.4 (all)

Additional Key Server Requirements

Requirement

Summary Details

Reference

Implement only one primary function per server.
Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.
2.2.1 (a-b)
Deploy anti-virus software on all systems commonly affected by malicious software.
Primarily applies to Windows-based operating systems.
Specific requirements include (among others):
• Software must be enabled for automatic updates and periodic scans (5.2.a-c)
• Log generation must be enabled and logs retained in accordance with PCI DSS Requirement 10.7 (5.2.d)
5.1 (all)
5.2 (all)
Deploy File Integrity Monitoring (FIM) software.
Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files; configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. (11.5)
Use file integrity monitoring and change-detection software on logs to ensure that existing log data cannot be changed without generating alerts. (10.5.5)
Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity.
10.5.5
11.5