Verizon Business Assessment for: Cisco PCI Solution for Retail

Table Of Contents

Based on PCI DSS v. 1.2

Report Version 1.0

01/27/2009

Verizon Business Assessment for: Cisco PCI Solution for Retail: Cisco Systems, Inc.

Table of Contents

Contact Information

1. Executive Summary

Assessment Description

Processors Used

Connections to Payment Card Companies

High Level Network Diagram

Quarterly Vulnerability Scans

2. Description of Scope of Work and Approach Taken

PCI DSS Version

Timeframe

Locations Visited

Environment on which Assessment Focused

Network Segmentation

Exclusions

Wholly-Owned Entities

International Entities

Wireless LANs and/or Wireless Applications

3. Details about Reviewed Environment

Description of Cardholder Data Environment

List of Hardware and Critical Software in Use in the Cardholder Environment

List of Service Providers

List of Third-Party Payment Application Products

List of Individuals Interviewed

List of Documents Reviewed

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software or programs

Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know

Requirement 8: Assign a unique ID to each person with computer access.

Requirement 9: Restrict physical access to cardholder data.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data.

Requirement 11: Regularly test security systems and processes.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for employees and contractors.

Verizon Business Assessment for: Cisco PCI Solution for Retail: Cisco Systems, Inc.

---

	Based on PCI DSS v. 1.2
	Report Version 1.0 01/27/2009

Table of Contents

Contact Information

Verizon Business - Security Solutions Powered by Cybertrust Aaron Reynolds Sr. Security Consultant CISSP, PCI QSA aaron.reynolds@verizonbusiness.com 425.239.2284 (Cell)
Cisco Customer contact information	Customer logo

1. Executive Summary

Assessment Description

Cisco Systems, Inc engaged Verizon Business to conduct a PCI assessment of their "PCI Solution for Retail" architecture, based on the PCI DSS v1.1 standard. The assessment against the PCI DSS v1.1 standard was broken into two phases, which included an initial assessment of the Cisco PCI Solution for Retail network architecture, configurations, security applications, and web consoles, and third-party POS and infrastructure applications. The second phase expanded the scope of the PCI Solution for Retail environment to include review of "at rest" data, remote connectivity solutions, Internet Edge infrastructure, Cisco's ACE XML firewall, additional network security compliance applications, and review of updated system component versions. The latest phase (phase 3) of the assessment did not include an onsite visit or updated versioning review, with exception to updates to the Cisco ACS software, which fixed a number of password/lockout setting capabilities within Section 8 of the PCI DSS. The focus of phase 3 was to map the previously assessed environment (assessed in August, 2007 - December 2007) against the PCI DSS v1.2 standard. This report captures the results of the v1.2 PCI DSS mapping.

Cisco Systems, Inc will continue to market the assessed solution to retail customers looking to meet PCI requirements, specifically within their retail environment and within their back-end data center infrastructure. Cisco has used findings from the assessment to ensure configurations within their solution meet PCI requirements specific to their solution, and plan to provide the results of the assessment to Cisco Sales Engineers interfacing with retail customers.

Verizon Business' assessment covered three PCI retail architectures (see "Scope" section), targeted to small, medium, and large retail environments. Verizon Business found the three solution architectures to directly address several technical PCI requirements, and can address other requirements either as a compensating control, or in conjunction with compensating controls. The retail architectures are designed to be deployed within a POS retail location, with central management/logging components deployed in a data center environment.

As Cisco's PCI Solution for Retail architecture only addresses some aspects of a merchant's overall PCI compliance responsibility, several areas of PCI compliance are left to the merchant to obtain full compliance. The overall approach to the assessment was to focus validation efforts on components which are core to Cisco's PCI Solution for Retail environment. System components outside of the Cisco PCI Solution for Retail environment (e.g. corporate email, corporate Internet/DMZ firewalls, central cardholder databases, mainframes, and corporate networks) were not included in the scope of the assessment.

Processors Used

The assessment took place within Cisco's PCI lab. There were no online transactions or processors involved with the assessment.

Connections to Payment Card Companies

There were no connections to payment card companies from the Cisco PCI lab.

High Level Network Diagram

Quarterly Vulnerability Scans

N/A - Quarterly scanning (internal and external) is the responsibility of the merchant / service provider, and was not part of the assessment.

2. Description of Scope of Work and Approach Taken

PCI DSS Version

PCI DSS v.1.2 was used for this assessment.

Timeframe

The assessment took place through several remote interviews, onsite and remote validation during the following two phases:

•Phase 1: 11/16/2006 - 12/29/2006

•Phase 2: 8/24/2007 - 12/12/2007

•Phase 3: 12/28/2008 - 01/26/2009

Locations Visited

The following Cisco Systems, Inc. locations were visited:

•Cisco Systems, Inc. - PCI Lab (Building J, 255 W. Tasman Drive, San Jose, CA)

Environment on which Assessment Focused

The assessment included the following "in scope" components:

•Large Retail environment

–Cisco Security Agent (CSA) software used for HIDS, host-based firewall, malware/spyware protection, behavioral anti-virus protection, file monitoring / access control (file integrity): Managed by CSA Manager from Data Center environment.

–Cisco 3845 Integrated Services Router (ISR) - (2): ISRs are configured with Firewall and IDS/IPS feature set.

–Cisco switches - (4 - 2 layer 3 switches (Catalyst 4506), 2 layer 2 access switches (Catalyst 3750))

–Wireless controllers - (1): Used to monitor and update wireless APs.

–Wireless APs - (1): Used for wireless POS networks. Wireless APs have been configured with WPA-TKIP security enabled,

–NCR Advanced Checkout Solution (ACS) software: Payment Application Best Practice (PABP) certified POS software.

–Verifone POS devices: MX/Vx Series (Wired and wireless POS devices). Verifone POS devices have been PCI PED (Pin Entry Device) certified.

–Intermec POS: Wireless POS handheld.

–RSA Key Manager Client - Used for cardholder data encryption (AES-256) within the NCR ACS server. RSA Key Manager provides application development libraries that support a wide range of development languages and can simplify the integration of encryption into point-of-sale, payment, and other applications that create or process cardholder information.

–RSA File Security Manager Client - Used to demonstrate secure storage of centralized data within datacenter environment. SFTP process transparently decrypts data on the POS server and sends to a central file server within the data center. The data is re-encrypted (AES-256) using RSA File Security Manager (FSM) before being written to the file system on the central file server.

•Medium Retail environment

–Cisco Security Agent (CSA) software used for HIDS, host-based firewall, malware/spyware protection, behavioral anti-virus protection, file monitoring / access control (file integrity)

–Cisco 3845 Integrated Services Router (ISR) - (2): ISRs are configured with Firewall and IDS/IPS feature set.

–Cisco 3560 layer 2 switches - (2)

–Wireless APs - (1) : Used for wireless POS networks. Wireless APs have been configured with WPA-TKIP security enabled,

–NCR Advanced Checkout Solution (ACS) software: Payment Application Best Practice (PABP) certified POS software.

–Verifone POS devices: MX/Vx Series (Wired and wireless POS devices). Verifone POS devices have been PCI PED (Pin Entry Device) certified.

–Intermec POS: Wireless POS handheld.

–RSA Key Manager Client - Used for cardholder data encryption (AES-256) within the NCR ACS server. RSA Key Manager provides application development libraries that support a wide range of development languages and can simplify the integration of encryption into point-of-sale, payment, and other applications that create or process cardholder information.

–RSA File Security Manager Client - Used to demonstrate secure storage of centralized data within datacenter environment. SFTP process transparently decrypts data on the POS server and sends to a central file server within the data center. The data is re-encrypted (AES-256) using RSA File Security Manager (FSM) before being written to the file system on the central file server.

•Small Retail environment

–Cisco Security Agent (CSA) software used for HIDS, host-based firewall, malware/spyware protection, behavioral anti-virus protection, file monitoring / access control (file integrity)

–Cisco 2821 Integrated Services Router (ISR) - (1) - ISR is configured with Firewall and IDS/IPS feature set.

–Wireless APs - (1): Used for wireless POS networks. Wireless APs have been configured with WPA-TKIP security enabled,

–NCR Advanced Checkout Solution (ACS) software: Payment Application Best Practice (PABP) certified POS software.

–Verifone POS devices: MX/Vx Series (Wired and wireless POS devices). Verifone POS devices have been PCI PED (Pin Entry Device) certified.

–Intermec POS: Wireless POS handheld.

–RSA Key Manager Client - Used for cardholder data encryption (AES-256) within the NCR ACS server. RSA Key Manager provides application development libraries that support a wide range of development languages and can simplify the integration of encryption into point-of-sale, payment, and other applications that create or process cardholder information.

–RSA File Security Manager Client - Used to demonstrate secure storage of centralized data within datacenter environment. SFTP process transparently decrypts data on the POS server and sends to a central file server within the data center. The data is re-encrypted (AES-256) using RSA File Security Manager (FSM) before being written to the file system on the central file server.

•Data Center Environment

–Cisco Wireless Control System (WCS): Central platform for wireless configuration, management, and monitoring.

–Cisco Security Monitoring, Analysis and Response System (CS-MARS): Central log monitoring, correlation, and reporting platform for Cisco network device security alerts (e.g. ASA/FWSM/ISR firewall logs and IDS/IPS alerts) within the Large, Medium, and Small retail environments, as well as the data center environment. In addition, Cisco Security Agent alerts are forwarded to CS-MARS.

–CiscoWorks LAN Management Solution (LMS): Network device configuration management (e.g. routing and switching)

–CiscoWorks Network Compliance Manager (NCM): CiscoWorks NCM tracks and regulates configuration and software changes across network infrastructure within the retail store and data center environments. Changes to network device configurations (e.g. enabling telnet, disabling exec timeout, enabling default usernames) are audited and reported through CiscoWorks NCM.

–Cisco Security Manager (CSM): Central provisioning of device configuration and security policies, including: ASAs, FWSMs, IDS/IPS, ISRs and switches (e.g. firewall policy, IDS/IPS configuration and signature management, https access).

–Cisco Security Agent (CSA) Manager - CSA software used for HIDS, host-based firewall, malware/spyware protection, behavioral anti-virus protection, file monitoring / access control (file integrity)

–Cisco Secure Access Control Server (ACS) - AAA server

–Cisco Application Control Engine (ACE - XML Gateway): Although initially designed for XML and SOAP-based web services, ACE XML Gateway demonstrated capabilities to provide application layer defense against html-based web vulnerabilities and attacks. ACE XML Gateway was deployed in the Internet Edge (DMZ) segment of the data center environment.

–Cisco Adaptive Security Device Manager (ASDM): Secure, web-based configuration management of ASA firewalls.

–Cisco IPS Device Manager (IDM): IDS/IPS configuration management.

–Cisco Security Device Manager (SDM): Secure, web-based configuration management of 7206VXR routers.

–Cisco 7206 VXR router (2 at Internet Edge, 2 at WAN aggregation): Access lists, routing, IPSec VPN termination.

–Cisco Catalyst 3750 switch (6 - 2 Internet Edge, 4 WAN aggregation): Layer 3 switch (routing and access lists).

–Cisco Catalyst 6509 Switch (8 - 2 Internet Edge, 2 core datacenter switch, 2 service aggregation switch, 2 access switch): Internet Edge - Routing, FWSM, IDSM2, and Application Control Engine (ACE - load balancer) modules, Core datacenter - layer 3 switch (routing and access lists), core service aggregation - layer 3 switch (routing, access lists, and IDSM module)

–Cisco Catalyst 4948 Switch (2): Layer 2 access switch.

–Cisco Adaptive Security Appliance (ASA) 5540 (2): Stateful firewall filtering and integrated IDS/IPS @ data center boundary.

–RSA File Security Manager: Used to demonstrate secure storage of centralized data within datacenter environment. SFTP process transparently decrypts data on the POS server (within retail store environment) and sends to a central file server within the data center. The data is re-encrypted (AES-256) using RSA File Security Manager (FSM) before being written to the file system on the central file server. This was a small demonstration of RSA File Security Manager's capabilities to transparently encrypt/decrypt data using strong AES and/or 3DES encryption. The configuration of RSA File Security Manager within the assessed environment was found to meet all key management requirements under PCI DSS v1.1.

–RSA Key Manager: Used for cardholder data encryption (AES-256) within the NCR ACS server. RSA Key Manager provides application development libraries that support a wide range of development languages and can simplify the integration of encryption into point-of-sale, payment, and other applications that create or process cardholder information. RSA Key Manager is the central platform to manage security policies for encryption and decryption of data. The configuration of RSA Key Manager within the assessed environment was found to meet all key management requirements under PCI DSS v1.1.

–RSA Access Manager: Used for central authentication/logging for access to RSA Key Manager within the assessed environment.

–RSA Authentication Manager: Central management/logging of RSA SecurID (two-factor) authentication for remote access into the data center environment.

–RSA enVision: RSA's solution for compliance and security information management. RSA enVision was used to centrally collect RSA SecurID authentication logs on the RSA Authentication Manager server, using a batch process that runs several times a day.

The following system components were part of the sample:

Component	Brand(s) Used	Version
Firewall	•Cisco Integrated Services Router (FWSM Firewall), Cisco ASA	•FWSM v3.1(3) •ASA 7.2.(2)
Network IDS	Cisco Integrated Services Router (integrated IDS/IPS), IDSM2	IOS v12.3(11r)T2, 12.4(1r), IDSM 6.0.(2)E1
Router	Cisco Integrated Services Router (IOS Firewall), Cisco 7206VXR	IOS v12.2(18)SXF10a, v12.3(11r)T2, 12.4(1r), 12.4(11)T3 (VXR)
Wireless AP	Cisco 1131AG, 1242AG
Wireless Controller	AIR-LAP1131AG-A-K9, AIR-LAP1242AG-A-K9	IOS 12.3(11)JA
POS Software	NCR ACS, NCR RealPOS	ACS v6.01.04.16
POS Devices	NCR, Verifone, Intermec	NCR RealPOS 80c, Verifone MX870, MX850, Vx670 (wireless), and Intermec Mobile POS CN3 (wireless)
Windows Server	Windows Server 2003	SP1, SP2
ECOM Web Server (demo server)	Foundstone Hackme Bank	v2.0
Database	N/A - Not reviewed/Not in scope
Windows Server Anti-Virus	McAfee VirusScan Enterprise + Anti-spyware Module	8.0.0
Firewall, Router, Switch, IDS/IPS Management	Cisco Security Manager (CSM), Cisco ASDM, Cisco IDM	CSM v3.0.1, ASDM v5.2.(2), IDM v6.0.2
Router, Switch management	CiscoWorks (LMS), CiscoWorks (NCM)	LMS v2.6, NCM v1.2.1
Desktop/Server Firewall (Host-based firewall)	Cisco Security Agent (CSA)	v5.1.0.69, v5.2.0.210
Central Logging / Correlation /Analysis	CS-MARS, RSA enVision	CS-MARS (v4.3.1), enVision (v3.5.1)
Wireless Management	Wireless Control System (WCS)	v4.1
AAA (TACACS+) authentication	Cisco ACS	v4.1(3) Build 12
Web Services (application) firewall	Cisco ACE XML Gateway	V5
Load Balancer	Cisco ACE Load Balancer	V3.0(0)A1(4a)
Two-factor Authentication	RSA SecurID (RSA Authentication Manager)	V6.1(300)
RSA Key Manager Authentication	RSA Access Manager	v6.0
Desktop E-mail Encryption	N/A - not in scope
File Integrity	Cisco Security Agent (CSA)	v5.1
Cardholder Storage Encryption	•NCR ACS (128-bit 3DES) •RSA Key Manager (192-bit 3DES, 128-bit, 192-bit, 256-bit AES) •RSA File Security Manager (192-bit 3DES, 256-bit AES)	•ACS v6.01.04.16 •RSA Key Manager v2.1.1 •RSA File Security Manager v2.1.0.9

Network Segmentation

Cisco has designed three network architectures for small, medium, and large retail environments. Cisco has chosen Cisco Integrated Services Routers (ISRs) to provide firewall, IDS/IPS, and routing functionality. Extremely explicit access-lists are applied through CSM firewall policies, which are pushed to the ISRs in each architecture. Access-lists implicitly deny all inbound and outbound traffic to the PCI Solution for Retail; all traffic approved within each design is explicitly allowed to the port level. Additionally, Cisco has incorporated wireless into the design, using WPA-TKIP w/PEAP authentication, for secure wireless networking. All wireless traffic must pass through the ISRs and IOS firewall access-lists to traverse any part of the PCI Solution for Retail network.

The data center environment is segmented into multiple VLANs, including Internet Edge, WAN aggregation, and Core service aggregation. Multiple layers of network security are included in all data center segments, including FWSM and ASA stateful firewall filtering, IDSM and integrated IDS/IPS detection/prevention, access lists, secure VPN (WAN aggregation and remote VPN), and two-factor authentication using RSA SecurID tokens.

All network devices within the PCI Solution for Retail are centrally managed through the following:

•Cisco Security Manager (CSM) - (Central security management for ISRs and switches (e.g. firewall policy, IDS/IPS signatures))

•CiscoWorks LAN Management Solution (LMS) - (Central configuration management for ISRs and switches (e.g. routing, switching, VLANs))

•CiscoWorks Network Compliance Manager (NCM) - (Central platform for auditing changes and enforcing configuration standards across network devices within the environment.

•Cisco Wireless Control System (WCS) - (Central wireless management)

•Cisco Security Agent (CSA) Manager - (Central CSA software manager: HIDS, Host-based firewall, file monitoring / Access Control, Malware protection, zero-day, behavioral A/V protection)

•Cisco ACS - (Central TACACS+ (central authentication) server for ASA firewall, FWSM, ISR, 7206 VXR router, switch, wireless controller, CiscoWorks (LMS and NCM), CS-MARS, WCS, and CSM).

•CS-MARS - (Central logging / Correlation / Analysis / Alerting server. Alerts from IDS/IPS alerts, CSA alerts, firewall logs)

•Cisco ASDM - (Central configuration for ASA firewalls).

•Cisco IPS Device Manager (IDM): IDS/IPS configuration management.

•Cisco Security Device Manager (SDM): Secure, web-based configuration management of 7206VXR routers.

Exclusions

Due to the nature of this assessment, several areas of a normal PCI assessment were excluded, including:

•Central cardholder data storage (limited to central storage on secure file repository, using RSA File Security Manager for data encryption)

•Authorization / Settlement processes

•Policies, procedures, and standards

•Assessment of "in transit" cardholder data (limited to transmission of test files between large store and data center using SCP to securely transmit file from back-office POS system (NCR ACS server) to secure file repository in data center environment)

•OS security for WCS, CS-MARS, CiscoWorks (LMS), CSM, CSA Manager, Cisco ACS, RSA enVision, RSA Key Manager, RSA File Security Manager, NCR Advanced Checkout Solution (ACS), RSA Authentication Manager, RSA Access Manager, Cisco Network Compliance Manager (NCM),

•Physical Security

•SDLC policies and procedures

•Live cardholder transactions (A fully functional POS environment, which includes authorization responses, was not available during the assessment)

Wholly-Owned Entities

N/A - There were no wholly-owned entities involved in the assessment.

International Entities

N/A - There were no international entities involved in the assessment.

Wireless LANs and/or Wireless Applications

Wireless networks within the PCI Solution for Retail environment have been configured to use WPA-TKIP w/PEAP authentication, for secure wireless networking. All wireless traffic must pass through the ISRs and IOS firewall access-lists to traverse any part of the PCI Solution for Retail network. Additionally, best practice security parameters have been applied to wireless networks, including: https access for wireless management, SSID broadcast disabled, default SSID has been changed, SNMPv3 used (default strings changed), and http access has been disabled.

3. Details about Reviewed Environment

Description of Cardholder Data Environment

NCR Advanced Checkout Solution (ACS) POS software was used within the Cisco Solution for Retail environment. NCR ACS software has been successfully certified through the Payment Application Best Practice (PABP) certification process. NCR ACS software handles both online and offline cardholder transactions, including debit and credit transactions. NCR ACS software protects "at rest" cardholder data through 3DES encryption, truncation, and masking, including for offline transactions.

List of Hardware and Critical Software in Use in the Cardholder Environment

The following hardware and software are critical for the cardholder environment:

Component	Brand(s) Used	Version
Firewall	•Cisco Integrated Services Router (FWSM Firewall), Cisco ASA	•FWSM v3.1(3) •ASA 7.2.(2)
Network IDS	Cisco Integrated Services Router (integrated IDS/IPS), IDSM2	IOS v12.3(11r)T2, 12.4(1r), IDSM 6.0.(2)E1
Router	Cisco Integrated Services Router (IOS Firewall), Cisco 7206VXR	IOS v12.2(18)SXF10a, v12.3(11r)T2, 12.4(1r), 12.4(11)T3 (VXR)
Wireless AP	Cisco 1131AG, 1242AG
Wireless Controller	AIR-LAP1131AG-A-K9, AIR-LAP1242AG-A-K9	IOS 12.3(11)JA
POS Software	NCR ACS, NCR RealPOS	ACS v6.01.04.16
POS Devices	NCR, Verifone, Intermec	NCR RealPOS 80c, Verifone MX870, MX850, Vx670 (wireless), and Intermec Mobile POS CN3 (wireless)
Windows Server	Windows Server 2003	SP1, SP2
ECOM Web Server (demo server)	Foundstone Hackme Bank	v2.0
Database	N/A - Not reviewed/Not in scope
Windows Server Anti-Virus	McAfee VirusScan Enterprise + Anti-spyware Module	8.0.0
Firewall, Router, Switch, IDS/IPS Management	Cisco Security Manager (CSM), Cisco ASDM, Cisco IDM	CSM v3.0.1, ASDM v5.2.(2), IDM v6.0.2
Router, Switch management	CiscoWorks (LMS), CiscoWorks (NCM)	LMS v2.6, NCM v1.2.1
Desktop/Server Firewall (Host-based firewall)	Cisco Security Agent (CSA)	v5.1.0.69, v5.2.0.210
Central Logging / Correlation /Analysis	CS-MARS, RSA enVision	CS-MARS (v4.3.1), enVision (v3.5.1)
Wireless Management	Wireless Control System (WCS)	v4.1
AAA (TACACS+) authentication	Cisco ACS	v4.0(1) Build 27
Web Services (application) firewall	Cisco ACE XML Gateway	V5
Load Balancer	Cisco ACE Load Balancer	V3.0(0)A1(4a)
Two-factor Authentication	RSA SecurID (RSA Authentication Manager)	V6.1(300)
RSA Key Manager Authentication	RSA Access Manager	v6.0
Desktop E-mail Encryption	N/A - not in scope
File Integrity	Cisco Security Agent (CSA)	v5.1
Cardholder Storage Encryption	•NCR ACS (128-bit 3DES) •RSA Key Manager (192-bit 3DES, 128-bit, 192-bit, 256-bit AES) •RSA File Security Manager (192-bit 3DES, 256-bit AES)	•ACS v6.01.04.16 •RSA Key Manager v2.1.1 •RSA File Security Manager v2.1.0.9

List of Service Providers

There were no Service Providers that were included in the assessment.

List of Third-Party Payment Application Products

NCR Advanced Checkout Solution (ACS) POS software was used within the Cisco Solution for Retail environment. NCR ACS software has been successfully certified through the Payment Application Best Practice (PABP) certification process. NCR ACS software handles both online and offline cardholder transactions, including debit and credit transactions. NCR ACS software protects "at rest" cardholder data through 3DES encryption, truncation, and masking, including for offline transactions.

List of Individuals Interviewed

The following staff was interviewed:

Interviewee(s)	Title	Date
Christian Janoff, Bart Mcglothin, Chris Tobkin, Stephan, Christina Hausman, Josh Huston	Environment Overview, Cisco PCI designs (CS-MARS, CSA, CSM, CiscoWorks (LMS), ACS, WCS)	11/16/06
Christian Janoff, Bart Mcglothin, Chris Tobkin, Stephan, Christina Hausman, Josh Huston	Environment Overview, Cisco PCI designs (CS-MARS, CSA, CSM, CiscoWorks (LMS), ACS, WCS)	11/17/06
Christian Janoff, Bart Mcglothin	Network architecture, firewalls, routers, switches, wireless, IDS/IPS	12/04/06
Christian Janoff, Bart Mcglothin	Audit Logging	12/04/06
Christian Janoff, Bart Mcglothin	Access Control / Authentication	12/04/06
Christian Janoff, Bart Mcglothin	CSA	12/04/06
Christian Janoff, Bart Mcglothin	MARS	12/04/06
Christian Janoff, Bart Mcglothin	CSM	12/04/06
Christian Janoff, Bart Mcglothin	Wireless	12/04/06
Christian Janoff, Bart Mcglothin	CiscoWorks (LMS)	12/06/06
Christian Janoff, Bart Mcglothin, Eric	MARS	12/13/06
Christian Janoff, Bart Mcglothin	Remediation items	12/20/06
Christian Janoff, Bart Mcglothin, Paul Jones	Assessment Results - Messaging	12/21/06
Christian Janoff, Bart Mcglothin, Christina Hausman, Josh Huston	CSA validation	12/22/06
Christian Janoff, Bart Mcglothin	IRoC review, remediation, and clarifications	12/27/06
Rupesh Chakkingal, Karen Chan	Cisco Retail Solution (Phase II overview)	9/13/07
Karen Chan, Sam Rao	CiscoWorks NCM	9/21/07
Karen Chan	Datacenter topology (WAN aggregation, DMZ, Internet Edge)	10/2/07
Karen Chan, Edmond Lam	7206VXR configuration review	10/4/07
Rupesh Chakkingal, Prakash Sinha	ACE XML Gateway	10/9/07
Rupesh Chakkingal, Scot Delancey (NCR)	NCR ACS Server	10/9/07
Rupesh Chakkingal, Ken Moore (Verifone), Marco (Verifone), Dave (Verifone)	Verifone MX/VX Series Pin Pads	10/9/07
Rupesh Chakkingal, Joe Vittorioso (RSA)	RSA Key Manager	10/10/07
Rupesh Chakkingal, Mohan Atreya (RSA)	RSA File Security Manager	10/10/07
Karen Chan, Don Lanoue, Mark King, Scott Seal	Cisco Configuration Assurance Solution (CAS)	10/11/07
Karen Chan	Cisco Network Compliance Manager (NCM)	10/15/07
Karen Chan	Data Center Network review	10/15/07
Rupesh Chakkingal, Mohan Atreya (RSA)	RSA File Security Manager	10/15/07
Karen Chan	Cisco router secure configuration reviews	10/16/07
Rupesh Chakkingal, Joe Vittorioso (RSA)	RSA Key Manager	10/16/07
Karen Chan, Pete Davis, Sridharan Srinivasan	Cisco ASA - Secure configuration reviews	10/17/07
Rupesh Chakkingal, Bryan Finch (NCR), Scot Delancey (NCR)	NCR ACS Server (Encryption/Key Management, Retention, password/lockout security, least-privilege access)	10/17/07
Rupesh Chakkingal, Chris Paggen	Cisco ACE XML Gateway (Web application security)	10/17/07
Karen Chan	VSAN Storage (EMC Storage) security - Zoning/LUN Masking	11/19/07
Rupesh Chakkingal, Josh Huston, John Eppich	Cisco Security Agent	11/19/07
Rupesh Chakkingal, Joe Vittorioso (RSA)	RSA File Security Manager	11/19/07
Rupesh Chakkingal, Joe Vittorioso (RSA), Duke Corey (RSA)	RSA enVision	12/6/07
Rupesh Chakkingal, Joe Vittorioso (RSA)	RSA Authentication Manager, RSA SecurID	12/6/07
Rupesh Chakkingal, Martin Pueblas	Cisco IDSM review	12/6/07
Rupesh Chakkingal, Joe Vittorioso (RSA)	RSA Key Manager, RSA Access Manager, RSA Authentication Manager	12/7/07
Rupesh Chakkingal, David Paschich	Cisco ACE XML Gateway (web application security)	12/7/07
Karen Chan	VSAN Storage - Security review	12/7/07

List of Documents Reviewed

The following documents were interviewed:

Document	Version / Date
LAB Servers and PC's V12 2006-12-27.doc	12/26/07 / v13
NTPVMapp_FAQ.txt	12/27/06
PCI Lab Application Flows v6 2006-12-27.xls	12/27/06
PCI LAB DOC DIAGRAMS 2006-12.01.vsd	12/01/06
Cisco Retail PCI Lab 11.20.06.doc	11/20/06
Cisco Security Agent v5.1 Test Guide.pdf	2006
CSA for corporate clients.pdf
CSA deployment best practices.pdf
Firewall Documentation.doc	11/16/06
PCI DIG v3. 12.19.06.doc	12/19/06

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Firewalls are computer devices that control computer traffic allowed between a company's network (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within a company's internal trusted network. The cardholder data environment is an example of a more sensitive area within the trusted network of a company.

A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.

All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employees' Internet access through desktop browsers, employees' e-mail access, dedicated connection such as business to business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
1.1 Establish firewall and router configuration standards that include the following:	1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. Complete the following:
1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations	1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.	N/A - Firewall/Router configuration standards (documentation).		Responsibility of merchant / service provider.
1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks	1.1.2.a 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, including any wireless networks.	Cisco provided a current network diagram, which documents all connections to the cardholder data, applicable to the reference architecture environment, including wireless networks.
	1.1.2.b Verify that the diagram is kept current.	Current diagrams were provided for each PCI Solution for Retail environment (e.g. Small, medium, and large POS environments, and data center environment).		Note: Since each network environment will be unique to the merchant or service provider, updating network diagrams remains the responsibility of each merchant / service provider.
1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone	1.1.3 Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone. Verify that the current network diagram is consistent with the firewall configuration standards.	N/A - Firewall/Router configuration standards (documentation)		Responsibility of merchant / service provider to document in configuration standards.
1.1.4 Description of groups, roles, and responsibilities for logical management of network components	1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.	N/A - Firewall/Router configuration standards (documentation) Note: Verizon Business confirmed role-based groups were created within Cisco ACS for logical management of network devices (e.g. Administrator, System Monitoring, and Config Manager groups).		Responsibility of merchant / service provider to document in configuration standards.
1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure	1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.	N/A - Firewall/Router configuration standards (documentation) Note: Verizon Business reviewed access-lists, in addition to a documented list of required services/protocols for the PCI Solution for Retail environment, and confirmed traffic is limited to that which is required for the environment.		Responsibility of merchant / service provider to document in configuration standards.
	1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service. An example of an insecure service, protocol, or port is FTP, which passes user credentials in clear-text.	N/A - Firewall/Router configuration standards (documentation)		Responsibility of merchant / service provider to document in configuration standards.
1.1.6 Requirement to review firewall and router rule sets at least every six months	1.1.6.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.	N/A - Firewall/Router configuration standards (documentation)		Responsibility of merchant / service provider.
	1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months.	N/A - Firewall/Router configuration standards (documentation)		Responsibility of merchant / service provider. Note: Requirement to review rule sets is to identify and remove stale, unnecessary rules, as well as audit rule set for soundness against current network design.
1.2 Build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment.	1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:
Note: An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.
1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.	1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.	Verizon Business confirmed that inbound traffic to and outbound traffic from the PCI Solution for Retail environment is limited to protocols necessary for the environment. ASA firewalls, FWSM firewalls, Integrated Services Routers (ISRs), and router access-lists are configured with "default-deny" rules and explicitly allow traffic to the service/port level.		Configurations for perimeter firewalls/routers outside the PCI Solution for Retail environment are the responsibility of merchant / service provider.
	1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit "deny all" or an implicit deny after allow statement.	Verizon Business confirmed that all inbound and outbound traffic not necessary for the PCI Solution for Retail environment is specifically denied.
1.2.2 Secure and synchronize router configuration files.	1.2.2 Verify that router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.	Verizon Business confirmed Cisco ISR and Cisco router device configurations are stored locally and within CiscoWorks (LMS, NCM), which has been implemented with least privilege access. CiscoWorks (LMS, NCM) can be configured to log and alert on configuration inconsistencies between active (running) and startup configurations.
1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.	1.2.3 Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.	Verizon Business confirmed the PCI Solution for Retail environment architecture was designed and segmented to require all wireless traffic destined for any wired host (e.g. POS system, WCS Manager, etc.) to pass through ISR firewall access-lists before being permitted.
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.	1.3 Examine firewall and router configurations, as detailed below, to determine that there is no direct access between the Internet and system components, including the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment.
1.3.1 Implement a DMZ to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment.	1.3.1 Verify that a DMZ is implemented to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment.	Verizon Business reviewed access-lists for inbound and outbound Internet traffic and confirmed traffic is limited to only protocols that are necessary for the cardholder data environment.
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.	1.3.2 Verify that inbound Internet traffic is limited to IP addresses within the DMZ.	Verizon Business reviewed access-lists for inbound Internet traffic and confirmed traffic is limited to IP addresses within the DMZ and restricted to only those services/protocols necessary.		Perimeter firewall/router configurations and rule sets are the responsibility of the merchant / service provider.
1.3.3 Do not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment.	1.3.3 Verify there is no direct route inbound or outbound for traffic between the Internet and the cardholder data environment.	Verizon Business reviewed network diagrams, configurations from network-infrastructure system components, including wireless APs, and confirmed there are no direct routes inbound or outbound for Internet traffic to/from the retail reference architecture.		Merchant / Service Provider would be responsible for ensuring POS devices and other servers in the retail (POS) environment are not configured to communicate directly with the Internet.
1.3.4 Do not allow internal addresses to pass from the Internet into the DMZ.	1.3.4 Verify that internal addresses cannot pass from the Internet into the DMZ.	Verizon Business reviewed access-lists on the Internet edge router and confirmed that Internet sourced RFC-1918 addresses are explicitly denied and that internal addresses cannot pass from the Internet into the DMZ.
1.3.5 Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.	1.3.5 Verify that outbound traffic from the cardholder data environment to the Internet can only access IP addresses within the DMZ.	Verizon Business reviewed outbound access-lists from the PCI Solution for Retail environment and confirmed that all outbound traffic is destined for "data center" systems. There is no outbound Internet access from the PCI Solution for Retail environment.
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only "established" connections are allowed into the network.)	1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering). [Only established connections should be allowed in, and only if they are associated with a previously established session (run a port scanner on all TCP ports with "syn reset" or "syn ack" bits set—a response means packets are allowed through even if they are not part of a previously established session).]	Verizon Business confirmed the PCI Solution for Retail environment configurations for the Cisco ASA firewalls, FWSMs, and ISRs were configured to perform stateful packet inspections.
1.3.7 Place the database in an internal network zone, segregated from the DMZ.	1.3.7 Verify that the database is on an internal network zone, segregated from the DMZ.	All databases within the PCI Solution for Retail environment are on an internal segment, segregated from the DMZ.
1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).	1.3.8 For the sample of firewall and router components, verify that NAT or other technology using RFC 1918 address space is used to restrict broadcast of IP addresses from the internal network to the Internet (IP masquerading).	Verizon Business reviewed DHCP reservations, static IPs, and access lists across firewalls and routers and confirmed RFC 1918 addresses were used within the PCI Solution for Retail environment.
1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization's network.	1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization's network, have personal firewall software installed and active.	N/A - Security Policy (Remote Access - Desktop firewalls) Note: Remote access to the PCI Solution for Retail environment was assessed for two-factor authentication (requirement 8.3) only.		Installation of personal firewall software for any mobile and employee-owned computers with direct Internet connectivity, and which are used to access the merchant / service provider network, is the responsibility of the merchant / service provider.
	1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by mobile computer users.	See 1.4.a above.		See 1.4.a above.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
2.1 Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.	2.1 Choose a sample of system components, critical servers, and wireless access points, and attempt to log on (with system administrator help) to the devices using default vendor-supplied accounts and passwords, to verify that default accounts and passwords have been changed. (Use vendor manuals and sources on the Internet to find vendor-supplied accounts/passwords.)	Verizon Business observed administrators during the login process, while attempting to logon with default accounts and passwords. Verizon Business confirmed all default passwords, including passwords for interactive administrator accounts and SNMP community strings have been changed. Verizon Business confirmed all default administrator accounts have been removed, where possible. Some default administrator accounts cannot be removed from the system, due to application dependencies; however, unique administrator accounts have been created, in order to eliminate the need to use all default administrator accounts.
2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission.	2.1.1 Verify the following regarding vendor default settings for wireless environments and ensure that all wireless networks implement strong encryption mechanisms (for example, AES): Encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions Default SNMP community strings on wireless devices were changed Default passwords/passphrases on access points were changed Firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks (for example, WPA/WPA2) Other security-related wireless vendor defaults, if applicable	Verizon Business reviewed wireless settings within the PCI Solution for Retail environment and verified the following: - Although default configurations support WEP, WEP keys had been disabled and were not used within the wireless environment. WPA/TKIP (w/PEAP authentication) is used for all wireless security. - No Default SSID exists. This must be entered at initial installation, and is recommended by Cisco to be unique. - SSID broadcast was disabled. - Default SNMP community strings have been changed and (SNMPv3 is being used). - No default passwords exist within the wireless environment. These are entered at initial login. Only unique, non-default accounts exist for interactive administration within the wireless environment. - WPA technology is enabled (WPA/TKIP w/PEAP authentication). - Wireless management and web mode is disabled.
2.2 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.	2.2.a Examine the organization's system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards—for example, SysAdmin Audit Network Security (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS).	N/A - System configuration standards (e.g. Firewall/Router standards, server standards, wireless standards). Note: Verizon Business reviewed configurations across all ASA/FWSM firewalls, ISR routers, switches, and wireless devices and confirmed they were configured according to best practice standards. CiscoWorks NCM can be used to further support best practice standards across network devices. Network device templates can be created to standardize secure configurations across network devices. Additionally, NCM can be used to periodically (e.g. once a day) audit network configurations to ensure secure configurations are being used and have not been altered contrary to best-practice standards. Note: Host Operating Systems were not included in the secure configuration review, as the OS chosen for management applications could vary with each merchant/service provider. Secure configuration for chosen OS platforms would be performed by the merchant/service provider. Verizon Business reviewed administrative accounts (default username/passwords, password/lockout settings, audit log settings, and secure channels for administration of applications and systems.		Documentation and implementation of system configuration standards is the responsibility of the merchant / service provider.
	2.2.b Verify that system configuration standards include each item below (at 2.2.1 - 2.2.4).	N/A - System configuration standards (e.g. Firewall/Router standards, server standards, wireless standards). Note: Verizon Business reviewed configurations across all ASA/FWSM firewalls, ISR routers, switches, and wireless devices and confirmed they were configured according to best practice standards.		Documentation and implementation of system configuration standards is the responsibility of the merchant / service provider.
	2.2.c Verify that system configuration standards are applied when new systems are configured.	N/A - System configuration standards (e.g. Firewall/Router standards, server standards, wireless standards). Note: Verizon Business reviewed configurations across all ASA/FWSM firewalls, ISR routers, switches, and wireless devices and confirmed they were configured according to best practice standards. Verizon Business also confirmed all management consoles were configured to support https access, and that http access had been disabled.		Documentation and implementation of system configuration standards is the responsibility of the merchant / service provider.
2.2.1 Implement only one primary function per server.	2.2.1 For a sample of system components, verify that only one primary function is implemented per server. For example, web servers, database servers, and DNS should be implemented on separate servers.	N/A - System configuration standards (e.g. Firewall/Router standards, server standards, wireless standards). Within the PCI Solution for Retail environment Cisco has used Virtual (VMware) servers to logically segment system functionality within a single hardware device (e.g. CSA Manager and CSM (Cisco Security Manager) running under separate VMware servers on a single system.		Note: Logical system partitioning (e.g. lpars (IBM mainframe), VMware servers) is an acceptable means to separate server functions within a single server platform.
2.2.2 Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device's specified function).	2.2.2 For a sample of system components, inspect enabled system services, daemons, and protocols. Verify that unnecessary or insecure services or protocols are not enabled, or are justified and documented as to appropriate use of the service. For example, FTP is not used, or is encrypted via SSH or other technology.	Verizon Business reviewed configurations for ASA/FWSM firewalls, ISR routers, switches, and wireless devices and found insecure services and protocols to be disabled. Note: Although Cisco followed a configuration standard to harden the OS for management consoles and POS servers (e.g. WCS, ACS, CSM, CSA, CiscoWorks (LMS, NCM), ACE XML Gateway, RSA File Security Manager, RSA Key Manager, RSA Access Manager, RSA Authentication Manager, and RSA enVision), Verizon Business did not review those configurations beyond secure administrative access (e.g. https, SSH), audit logging, and password/lockout settings. OS hardening is the responsibility of the merchant / service provider, and would vary significantly, depending on OS platform and POS applications deployed.		Host OS hardening for POS applications, Management servers (e.g. Cisco CSM, RSA Authentication Manager, etc) is the responsibility of the merchant/service provider.
2.2.3 Configure system security parameters to prevent misuse.	2.2.3.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.	Verizon Business interviewed administrators, architects, and SMEs from business units to determine they have knowledge of common security parameters for the ASA firewalls, FWSMs, ISRs, routers, switches, wireless components, and management platforms within the PCI Solution for Retail environment.		Interviews to be conducted within respective administrator/security groups for each merchant / service provider.
	2.2.3.b Verify that common security parameter settings are included in the system configuration standards.	N/A - System configuration standards (e.g. Firewall/Router standards, server standards, wireless standards). Note: Verizon Business reviewed configurations across ASA/FWSM firewalls, ISR routers, switches, and wireless devices and confirmed they were based on best practice standards. Verizon Business also confirmed all management consoles were configured to support secure access (e.g. SSH, https, High-Encryption RDP), and that http, Telnet, and other insecure protocols commonly used for administrative access had been disabled.		Documentation and implementation of system configuration standards is the responsibility of the merchant / service provider.
	2.2.3.c For a sample of system components, verify that common security parameters are set appropriately.	Verizon Business reviewed configurations across all ASA/FWSM firewalls, ISR routers, switches, and wireless devices and confirmed they were based on best practice standards, and that common security parameters were set appropriately. Verizon Business also confirmed all management consoles were configured to support secure access (e.g. SSH, https, High-Encryption RDP), and that http, Telnet, and other insecure protocols commonly used for administrative access had been disabled. Additionally, role-based administration was configured for administration of network devices (e.g. ASA/FWSM firewalls, ISRs, routers, switches, wireless controllers) and for management of WCS, CSA, CiscoWorks (LMS, NCM), CSM, CS-MARS, and ACS, ACE XML Gateway, NCR ACS server, RSA File Security Manager, RSA Key Manager, RSA enVision, RSA Authentication Manager, and RSA Access Manager.		Server hardening, including appropriate security settings for all system components, is the responsibility of the merchant / service provider.
2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.	2.2.4 For a sample of system components, verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed. Verify enabled functions are documented and support secure configuration, and that only documented functionality is present on the sampled machines.	Verizon Business reviewed configurations across all ASA/FWSM firewalls, ISR routers, switches, and wireless devices and confirmed they were based on best practice standards, and that all unnecessary functionality was disabled.		Server hardening, including appropriate security settings for all system components, is the responsibility of the merchant / service provider.
2.3 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.	2.3 For a sample of system components, verify that non-console administrative access is encrypted by: •Observing an administrator log on to each system to verify that a strong encryption method is invoked before the administrator's password is requested; •Reviewing services and parameter files on systems to determine that Telnet and other remote log-in commands are not available for use internally; and •Verifying that administrator access to the web-based management interfaces is encrypted with strong cryptography.	Verizon Business reviewed non-console administrative access for ASA firewalls, FWSM firewalls, ISR routers, switches, wireless devices, and the following management consoles: CSA Manager, ACS (TACACS+ server for all network device authentication), CSM, CiscoWorks (LMS,NCM), WCS (wireless console), and ACE XML Gateway, CS-MARS, NCR ACS Server, RSA File Security Manager, RSA Key Manager, RSA enVision, RSA Authentication Manager, and RSA Access Manager . Verizon Business confirmed the following methods were used: - ssh (CLI access for ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2 modules, ACE XML Gateway, CS-MARS, and wireless controllers) - RDP (High Encryption) enabled. This forces RDP clients to used 128-bit encryption. RDP access is used to for OS access for the following: NCR ACS server, all Windows-based Cisco management consoles (e.g. CiscoWorks (LMS, NCM), WCS, CSA, ACS, etc), RSA File Security Manager, RSA Key Manager, RSA Authentication Manager, RSA Access Manager, RSA enVision. - 128-bit SSL (https) or SSL encrypted thick-client access for management console access, including wireless console access (WCS). - Http access has been disabled on all management consoles, ASA/FWSM firewalls, ISRs, routers, switches, and wireless controllers.		Note: Verification of telnet presence within the management consoles (Windows Server 2003) was not performed. This is the responsibility of the merchant / service provider, as part of secure configuration standard processes.
2.4 Shared hosting providers must protect each entity's hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.	2.4 Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect their entities' (merchants and service providers) hosted environment and data.	N/A - Hosting provider (testing procedures) requirement		This requirement is specific to hosting providers.

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.

Please refer to the PCI DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of "strong cryptography" and other PCI DSS terms.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.	3.1 Obtain and examine the company policies and procedures for data retention and disposal, and perform the following: •Verify that policies and procedures include legal, regulatory, and business requirements for data retention, including specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons) •Verify that policies and procedures include provisions for disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data •Verify that policies and procedures include coverage for all storage of cardholder data •Verify that policies and procedures include a programmatic (automatic) process to remove, at least on a quarterly basis, stored cardholder data that exceeds business retention requirements, or, alternatively, requirements for a review, conducted at least on a quarterly basis, to verify that stored cardholder data does not exceed business retention requirements	N/A - Data retention / Data disposal policy and procedures.		Data retention / Data disposal policies and procedures are the responsibility of the merchant / service provider.
3.2 Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:	3.2 If sensitive authentication data is received and deleted, obtain and review the processes for deleting the data to verify that the data is unrecoverable. For each item of sensitive authentication data below, perform the following steps:	VzB observed test transactions and "at rest" data within the NCR POS terminal and NCR ACS application. Verizon Business also reviewed NCR's PABP assessment results and confirmed that NCR ACS software used within Cisco's PCI Solution for Retail environment is PABP certified. As a result of the review, Verizon Business has confirmed that sensitive authentication data is not stored subsequent to authorization. Like other POS applications, the NCR ACS software does retain full track data in 128-bit 3DES encrypted format, only in an offline scenario (link to authorizer is down), and is purged at the point the connection is available and the transaction is sent for authorization.		It is the responsibility of the merchant to ensure POS systems used do not store sensitive authentication data (e.g. full track data, CVV2, PIN/PIN block) post authorization (even if encrypted). A large step to ensure POS systems meet PCI requirements is to work with POS vendors that have certified their POS application/s according to PABP standards.
3.2.1 Do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: •The cardholder's name, •Primary account number (PAN), •Expiration date, and •Service code To minimize risk, store only these data elements as needed for business. Note: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information.	3.2.1 For a sample of system components, examine the following and verify that the full contents of any track from the magnetic stripe on the back of card are not stored under any circumstance: •Incoming transaction data •All logs (for example, transaction, history, debugging, error) •History files •Trace files •Several database schemas •Database contents	See 3.2 above. Verizon Business confirmed that full track data is not written to disk, other than temporarily in an offline scenario. During this temporary period the track data is encrypted using 128-bit 3DES encryption, and is immediately purged at the point an authorization response is obtained. Verizon Business reviewed the following: •Database transaction files •User access log •EFT Journal Report •EFT Offline Report •EFY Rejection Report •Electronic Journal Report •TRMOFF (FOH offline transaction file) •EFTOFF (back office offline transaction file)		See 3.2 above
3.2.2 Do not store the card-verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions. Note: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information.	3.2.2 For a sample of system components, verify that the three-digit or four-digit card-verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance: •Incoming transaction data •All logs (for example, transaction, history, debugging, error) •History files •Trace files •Several database schemas •Database contents	See 3.2 above. Verizon Business observed that CVV2/CVC2 data was not received at POS swipe. Verizon Business reviewed the following to confirm CVV/CVC2 data is not present: •Database transaction files •User access log •EFT Journal Report •EFT Offline Report •EFY Rejection Report •Electronic Journal Report •TRMOFF (FOH offline transaction file) •EFTOFF (back office offline transaction file)		See 3.2 above
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.	3.2.3 For a sample of system components, examine the following and verify that PINs and encrypted PIN blocks are not stored under any circumstance: •Incoming transaction data •All logs (for example, transaction, history, debugging, error) •History files •Trace files •Several database schemas •Database contents	See 3.2 above. Verizon Business observed that PIN/PIN block data was not required at POS swipe. Verizon Business reviewed NCR's PABP assessment results and the following to confirm CVV/CVC2 data is not present: •Database transaction files •User access log •EFT Journal Report •EFT Offline Report •EFY Rejection Report •Electronic Journal Report •TRMOFF (FOH offline transaction file) •EFTOFF (back office offline transaction file)		See 3.2 above
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). Notes: •This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN. •This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, for point-of-sale (POS) receipts.	3.3 Obtain and examine written policies and examine displays of PAN (for example, on screen, on paper receipts) to verify that primary account numbers (PANs) are masked when displaying cardholder data, except for those with a legitimate business need to see full PAN.	Verizon Business reviewed NCR's ACS application and confirmed that only masked data is accessible through the application, even for administrators.		Data control / Data classification policies and procedures, including masking PAN data, except for those with a specific need to see full PAN data, is the responsibility of the merchant.
3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches: •One-way hashes based on strong cryptography •Truncation •Index tokens and pads (pads must be securely stored) •Strong cryptography with associated key-management processes and procedures The MINIMUM account information that must be rendered unreadable is the PAN. Notes: •If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls. •"Strong cryptography" is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms.	3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using one of the following methods: •One-way hashes based on strong cryptography •Truncation •Index tokens and pads, with the pads being securely stored •Strong cryptography, with associated key-management processes and procedures	Verizon Business reviewed vendor documentation regarding NCR's ACS POS server and observed application files (see 3.2.x comments for application files reviewed) to determine that the following methods are used to render cardholder data unreadable within the POS environment: •128-bit 3DES encryption •Truncation Additionally, Verizon Business reviewed RSA File Security Manager and RSA Key Manager applications, related to protecting sensitive data (including cardholder data) within Cisco's PCI Solution for Retail environment. Verizon Business confirmed the following methods can be used to render cardholder data unreadable: •RSA File Security Manager - 192-bit 3DES or 256-bit AES encryption. •RSA Key Manager - 192-bit 3DES or 128-bit, 192-bit, or 256-bit AES encryption.		Ensuring PAN data, at a minimum, is unreadable anywhere it is stored, is the responsibility of the merchant / service provider. At least one of the following methods must be used: •One-way hashes based on strong cryptography •Truncation •Index tokens and pads, with the pads being securely stored •Strong cryptography, with associated key-management processes and procedures
	3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).	Verizon Business reviewed NCR's ACS POS server and POS register and confirmed that cardholder data was truncated or encrypted in all locations. Verizon Business also reviewed encryption capabilities for RSA File Security Manager and RSA Key Manager products. Verizon Business confirmed that all test files used during the review were successfully rendered unreadable using strong encryption.		See 3.4 above
	3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is rendered unreadable.	N/A - Tape backups were not included in the scope of the review.		See 3.4 above
	3.4.d Examine a sample of audit logs to confirm that the PAN is sanitized or removed from the logs.	Verizon Business reviewed NCR's ACS POS server and POS register and confirmed that cardholder data was truncated or encrypted in all locations. Verizon Business also reviewed encryption capabilities for RSA File Security Manager and RSA Key Manager products. Verizon Business confirmed that all test files used during the review were successfully rendered unreadable using strong encryption.		See 3.4 above
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.	3.4.1.a If disk encryption is used, verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating systems mechanism (for example, not using local user account databases).	N/A - Disk encryption was not used in the environment.		See 3.4 above
	3.4.1.b Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).	N/A - Disk encryption was not used in the environment.		Encryption / Key Management policies and procedures, including technical controls is the responsibility of the merchant / service provider.
	3.4.1.c Verify that cardholder data on removable media is encrypted wherever stored. Note: Disk encryption often cannot encrypt removable media, so data stored on this media will need to be encrypted separately.	N/A - Disk encryption was not used in the environment.		See 3.4 above
3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse:	3.5 Verify processes to protect keys used for encryption of cardholder data against disclosure and misuse by performing the following:
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.	3.5.1 Examine user access lists to verify that access to keys is restricted to very few custodians.	Verizon Business confirmed that restricted access to encryption keys is as follows: •NCR ACS: Encryption keys are generated using the "Interactive Key Maintenance" tool. Only administrators have access to this tool. The encryption key is stored in an encrypted format within a binary file and is not disclosed to the key administrator at key generation time or at any other time. •RSA File Security Manager: Data encryption keys are never disclosed to the key administrators and cannot be exported to a key administrator. RSA File Security Manager security policies provide access keys to use encryption keys, but not view or export encryption keys. •RSA Key Manager: Data encryption keys are never disclosed to the key administrators and cannot be exported to a key administrator. RSA Key Manager security policies require public key authentication to access key material for encryption/decryption purposes.		Protection of encryption keys is the responsibility of the merchant / service provider.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.	3.5.2 Examine system configuration files to verify that keys are stored in encrypted format and that key-encrypting keys are stored separately from data-encrypting keys.	Verizon Business reviewed protection/storage for encryption keys and confirmed the following: •NCR ACS: Data encryption keys are stored in an encrypted format within the ENCKEY binary file. The key-encrypting key is statically compiled into the application. •RSA File Security Manager: The data encryption key is protected using a private RSA 1024-bit role key. The role key is encrypted using a unique access key. The access key is not stored on the system in its entirety, but is derived by seeding the PRNG with a SID (unique) and additional salt, resulting in unique key material for each user and process configured within FSM. •RSA Key Manager: Key encryption key is stored in memory and data encryption keys are stored in encrypted format within Oracle or MS SQL database.		See 3.5.1 above
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:	3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.	N/A - Key Management policy and procedures		Key Management policies and procedures is the responsibility of the merchant / service provider.
	3.6.b For service providers only: If the service provider shares keys with their customers for transmission of cardholder data, verify that the service provider provides documentation to customers that includes guidance on how to securely store and change customer's keys (used to transmit data between customer and service provider).	N/A - Key Management policy and procedures		See 3.6.a above
	3.6.c Examine the key-management procedures and perform the following:
3.6.1 Generation of strong cryptographic keys	3.6.1 Verify that key-management procedures are implemented to require the generation of strong keys.	Verizon Business confirmed that generation of strong keys is included for the following: •NCR ACS: 128-bit 3DES keys •RSA File Security Manager: 192-bit 3DES or 256-bit AES keys •RSA Key Manager: 192-bit 3DES or 128-bit/192-bit/256-bit AES keys		See 3.6.a above
3.6.2 Secure cryptographic key distribution	3.6.2 Verify that key-management procedures are implemented to require secure key distribution.	Verizon Business confirmed that secure distribution of keys is included for the following: •NCR ACS: Encryption keys are generated locally, using the Interactive Key Maintenance tool and imported into the ENCKEY binary file. •RSA File Security Manager: Encryption keys are stored centrally on the RSA File Security Manager server and sent in encrypted format to the client system requiring encryption/decryption functions. •RSA Key Manager: All key transfers are done over SSLv3/TLSv1 connections between Key Manager server and Key Manager Clients.		See 3.6.a above
3.6.3 Secure cryptographic key storage	3.6.3 Verify that key-management procedures are implemented to require secure key storage.	Verizon Business confirmed that secure key storage is included for the following: •NCR ACS: Encryption keys are encrypted using a 128-bit 3DES key-encryption key. •RSA File Security Manager: The data encryption key is protected using a private RSA 1024-bit role key. The role key is encrypted using a unique access key (256-bit AES encryption). The access key is not persistently stored on the client system in its entirety, but is derived by seeding the PRNG with a SID (unique) and additional salt, resulting in unique key material for each user and process configured within FSM. •RSA Key Manager: Key encryption key is stored in memory and data encryption keys are stored in encrypted format within Oracle or MS SQL database.		See 3.6.a above
3.6.4 Periodic cryptographic key changes •As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically •At least annually	3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.	Verizon Business confirmed that key rotation capabilities are included for the following: •NCR ACS: New keys can be generated using the Interactive Key Maintenance tool. Data encrypted with a particular key is stored with a key index, so that multiple keys can be used for data encryption. •RSA File Security Manager: Client adapters can rotate encryption keys as defined by RSA File Security Manager policies, or manually, in the event of a key compromise. Client adapters decrypt "at rest" data and re-encrypt with new key. •RSA Key Manager: RSA Key Manager assigns lifetimes for key use, and policies can be created to rotate (generate and use new key) as frequently as defined. Encryption keys can be assigned different key states, depending on known state of key. Examples include: Active, deactivated, destroyed, compromised, or destroyed-compromised.		See 3.6.a above Note: NCR ACS application. There was no reasonable way to rotate encryption keys, without manually decrypting all data and re-encrypting with a new key. NCR ACS application allows multiple keys (up to 255) to be used to limit the amount of data encrypted with a single key.
3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys	3.6.5.a Verify that key-management procedures are implemented to require the retirement of old keys (for example: archiving, destruction, and revocation as applicable).	Verizon Business confirmed that destruction of keys is included for the following: •NCR ACS: New keys can be generated using the Interactive Key Maintenance tool. Old keys can be removed from use or overwritten through the Interactive Key Maintenance tool. •RSA File Security Manager: Client adapters can rotate encryption keys as defined by RSA File Security Manager policies, or manually, in the event of a key compromise. Client adapters decrypt "at rest" data and re-encrypt with new key. •RSA Key Manager: RSA Key Manager assigns lifetimes for key use, and policies can be created to rotate (generate and use new key) as frequently as defined, or delete, when necessary. States are assigned to encryption keys to limit transition use of key. Examples include: Active, deactivated, destroyed, compromised, or destroyed-compromised.		See 3.6.a above
	3.6.5.b Verify that the key-management procedures are implemented to require the replacement of known or suspected compromised keys.	Verizon Business confirmed that replacement of known or suspected compromised keys is included for the following: •NCR ACS: Compromised keys can be removed or destroyed using the Interactive Key Maintenance tool. •RSA File Security Manager: Client adapters can rotate encryption keys as defined by RSA File Security Manager policies, or manually, in the event of a key compromise. Client adapters transparently decrypt "at rest" data and re-encrypt with new key. •RSA Key Manager: RSA Key Manager assigns lifetimes for key use, and policies can be created to rotate (generate and use new key) as frequently as defined. Different states can be assigned to encryption keys in the event of a suspected or known key compromise. Key state examples include: Active, deactivated, destroyed, compromised, or destroyed-compromised.		See 3.6.a above
3.6.6 Split knowledge and establishment of dual control of cryptographic keys	3.6.6 Verify that key-management procedures are implemented to require split knowledge and dual control of keys (for example, requiring two or three people, each knowing only their own part of the key, to reconstruct the whole key).	Verizon Business confirmed that split knowledge/dual control of keys is included for the following: •NCR ACS: Encryption keys are generated using the "Interactive Key Maintenance" tool. Only administrators have access to this tool. The encryption key is stored in an encrypted format within a binary file and is not disclosed to the key administrator at key generation time. •RSA File Security Manager: Data encryption keys are never disclosed to the key administrators and cannot be exported at any time in clear-text format. RSA File Security Manager security policies provide access keys to use encryption keys, but not view or export encryption keys. Additional roles exist within RSA File Security Manager to further segregate key management capabilities between "Security Admin" (responsible for management of security officers and has no visibility into encryption keys or security policies) and "Security Officers" (creates security policies, assigns encryption keys, but has no visibility into data being protected). •RSA Key Manager: Data encryption keys are never disclosed to the key administrators and cannot be exported at any time in clear-text format.		See 3.6.a above
3.6.7 Prevention of unauthorized substitution of cryptographic keys	3.6.7 Verify that key-management procedures are implemented to require the prevention of unauthorized substitution of keys.	Verizon Business confirmed that prevention of unauthorized substitution of keys is included for the following: •NCR ACS: Encryption keys are generated using the "Interactive Key Maintenance" tool. Only administrators have access to this tool. CSA has also been installed on the ACS server and further restricts access, monitors access, and logs access to tools necessary for key replacement. •RSA File Security Manager: Data encryption keys are never disclosed to the key administrators and cannot be exported at any time in clear-text format. RSA File Security Manager security policies provide access keys to use encryption keys, but not view or export encryption keys. Additional roles exist within RSA File Security Manager to further segregate key management capabilities between "Security Admin" (responsible for management of security officers and has no visibility into encryption keys or security policies) and "Security Officers" (creates security policies, assigns encryption keys, but has no visibility into data being protected). Security Officers can only conduct key administration functions, they cannot access decrypted data, assuming separation of duties has been implemented on the client OS (e.g. key administrators are not users on the client system that uses encryption functions). •RSA Key Manager: Data encryption keys are never disclosed to the key administrators and cannot be exported at any time in clear-text format. Key administration functions can only be access through the Key Manager server, via access controls (authentication) through the RSA Access Manager server. Additionally, Verizon Business confirmed that firewall segmentation and granular firewall access lists exist to further restrict access to POS systems and encryption key management servers.		See 3.6.a above
3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities	3.6.8 Verify that key-management procedures are implemented to require key custodians to sign a form specifying that they understand and accept their key-custodian responsibilities.	N/A - Key custodian lists are the responsibility of the merchant/service provider.		See 3.6.a above

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

PCI DSS Requirements		Testing Procedures		In Place		Not in Place		Target Date/ Comments
4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are: •The Internet, •Wireless technologies, •Global System for Mobile communications (GSM), and •General Packet Radio Service (GPRS).	4.1.a Verify the use of encryption (for example, SSL/TLS or IPSEC) wherever cardholder data is transmitted or received over open, public networks •Verify that strong encryption is used during data transmission •For SSL implementations: –Verify that the server supports the latest patched versions. –Verify that HTTPS appears as a part of the browser Universal Record Locator (URL). –Verify that no cardholder data is required when HTTPS does not appear in the URL. •Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit. •Verify that only trusted SSL/TLS keys/certificates are accepted. •Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.)		4.1.a Verizon Business reviewed the following configurations to confirm that secure transmission of cardholder data would be accomplished: •The wireless network within the large, medium, and small store environment (WPA (128-bit RC4 encryption)) •128-bit SSL (Secure FTP (SFTP) of cardholder data from store environment to PCI file server within data center). Cisco's PCI solution would allow for both transmission of data over private circuit to the WAN edge of the data center, or over IPSec VPN back to data center. •Verizon Business confirmed that the proper encryption strength (128-bit RC4) has been implemented for all wireless traffic within the PCI Solution for Retail environment. Verizon business also confirmed the SFTP sever was configured with strong encryption. Note Wireless networks have been configured to provide PCI required security necessary to support cardholder traffic.
4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission. •For new wireless implementations, it is prohibited to implement WEP after March 31, 2009. •For current wireless implementations, it is prohibited to use WEP after June 30, 2010.	4.1.1 For wireless networks transmitting cardholder data or connected to the cardholder data environment, verify that industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.		Verizon Business reviewed wireless settings within the PCI Solution for Retail environment to confirm WPA (128-bit RC4) encryption has been implemented for all wireless traffic.
4.2 Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat).	4.2.a Verify that strong cryptography is used whenever cardholder data is sent via end-user messaging technologies.		N/A - Data Control / Encryption policy and procedures				Responsibility of merchant / service provider
	4.2.b Verify the existence of a policy stating that unencrypted PANs are not to be sent via end-user messaging technologies.		N/A - Data Control / Encryption policy and procedures				Responsibility of merchant / service provider

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software or programs

Malicious software, commonly referred to as "malware"—including viruses, worms, and Trojans—enters the network during many business approved activities including employees' e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).	5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists.	Verizon Business confirmed A/V software is installed on Windows systems within the PCI Solution for Retail environment; however, the assessment focus for PCI A/V requirements was placed on Cisco Security Agent software, and its ability to meet the intent of A/V requirements. Cisco Security Agent software is installed on the following Windows system components within the environment: •Cisco ACS console •WCS console •CiscoWorks (LMS, NCM) consoles •CSA console •CSM console •RSA Authentication Manager •RSA Access Manager •RSA File Security Manager •RSA Key Manager •NCR ACS Server Although Verizon Business recommends installing Anti-Virus software on the above system components, CSA software could be used, in conjunction with existing firewall segmentation and restricted Internet access, in order to mitigate the majority of common anti-virus risks (see comments). Important: Because POS environments vary with each vendor, a full assessment of		Note: CSA can be configured to protect against the following virus and malware threats: Virus propagation prevention through intrusion detection/prevention and port blocking Unauthorized/malicious application execution Application hijacking Buffer overflows Instant Messaging (IM can be configured through CSA policy to prohibit downloading files) Important: Any attempt to use CSA as a compensating control for A/V would be subject to examination of the environment, the configuration of CSA
		the POS environment, Internet/email connectivity to the POS environment, corporate connectivity to the POS environment, CSA configuration, and all compensating controls would need to be made for each merchant, in order to make an "In Place/Not in Place" assessment (If CSA software is used as a compensating control for Anti-Virus software).		and its ability to mitigate risks from virus threats, and the opinion of the individual assessor.
5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.	5.1.1 For a sample of system components, verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits).	See 5.1 above		See 5.1 above
Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.	5.2 Verify that all anti-virus software is current, actively running, and capable of generating logs by performing the following:	Verizon Business observed A/V software installed on Windows components within the PCI Solution for Retail environment. Verizon Business also reviewed vendor documentation and observed a demo of CSA's capabilities to provide layered security through multiple security controls. The PCI Solution for Retail environment implementation addresses the following AV requirements (5.2.b and 3rd bullet items):		Important: Any attempt to use CSA as a compensating control for A/V would be subject to examination of the environment, the configuration of CSA and its ability to mitigate risks from virus threats, and the opinion of the individual assessor.
	5.2.a Obtain and examine the policy and verify that it requires updating of anti-virus software and definitions.	N/A - Written A/V policy		Responsibility of merchant / service provider
	5.2.b Verify that the master installation of the software is enabled for automatic updates and periodic scans.	Verizon Business confirmed a central (master) console for CSA exists in the PCI Solution for Retail environment, which centrally manages all CSA client policies.
	5.2.c For a sample of system components including all operating system types commonly affected by malicious software, verify that automatic updates and periodic scans are enabled.	Verizon Business confirmed a central (master) console for CSA exists in the PCI Solution for Retail environment, which centrally manages all CSA client policies. As
	5.2.d For a sample of system components, verify that antivirus software log generation is enabled and that such logs are retained in accordance with PCI DSS Requirement 10.7	N/A - Central storage and retention of A/V logs is the responsibility of the merchant / service provider		PCI DSS v1.2 now requires that anti-virus logs be retained in accordance with PCI DSS requirement 10.7.b (minimum of 90 days online and 1 year online/on tape).

Requirement 6: Develop and maintain secure systems and applications

Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.

---

Note Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

---

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.	6.1.a For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security patch list, to verify that current vendor patches are installed.	Verizon Business reviewed configurations for the PCI Solution for Retail environment components, including management consoles for components within the PCI Solution for Retail environment and confirmed they are running current software releases and contain current vendor patches as of the time of this assessment (Feb 2008).
	6.1.b Examine policies related to security patch installation to verify they require installation of all critical new security patches within one month.	N/A - Patch management policy and procedures		Patch management policies and procedures is the responsibility of the merchant / service provider.
6.2 Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues.	6.2.a Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities.	N/A - Patch / Risk management policy and procedures		Patch / Risk management procedures are the responsibility of the merchant / service provider.
	6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information and updating the system configuration standards reviewed in Requirement 2.2 as new vulnerability issues are found.	Verizon Business reviewed vendor documentation for CiscoWorks (LMS) and confirmed its ability to generate upgrade reports for active devices under CiscoWorks configuration management.		Overall Patch / Risk management procedures are the responsibility of the merchant / service provider. Verizon Business recommends using multiple outside sources (e.g. SANS, CERT, SecurityFocus, vendor websites, etc) to identify new vulnerability issues within the environment.
6.3 Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle. These processes must include the following:	6.3.a Obtain and examine written software development processes to verify that the processes are based on industry standards, security is included throughout the life cycle, and software applications are developed in accordance with PCI DSS.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
	6.3.b From an examination of written software development processes, interviews of software developers, and examination of relevant data (network configuration documentation, production and test data, etc.), verify that:	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.1 Testing of all security patches, and system and software configuration changes before deployment, including but not limited to the following:	6.3.1 All changes (including patches) are tested before being deployed into production.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)	6.3.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.1.2 Validation of proper error handling	6.3.1.2 Validation of proper error handling	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.1.3 Validation of secure cryptographic storage	6.3.1.3 Validation of secure cryptographic storage	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.1.4 Validation of secure communications	6.3.1.4 Validation of secure communications	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.1.5 Validation of proper role-based access control (RBAC)	6.3.1.5 Validation of proper role-based access control (RBAC)	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.2 Separate development/test and production environments	6.3.2 The development/test environments are separate from the production environment, with access control in place to enforce the separation.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.3 Separation of duties between development/test and production environments	6.3.3 There is a separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.4 Production data (live PANs) are not used for testing or development	6.3.4 Production data (live PANs) are not used for testing and development, or are sanitized before use.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.5 Removal of test data and accounts before production systems become active	6.3.5 Test data and accounts are removed before a production system becomes active.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.6 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers	6.3.6 Custom application accounts, user IDs and/or passwords are removed before system goes into production or is released to customers.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
6.3.7 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle required by PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel or third parties. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.	6.3.7.a Obtain and review policies to confirm all custom application code changes for internal applications must be reviewed (either using manual or automated processes), as follows: •Code changes are reviewed by individuals other then the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. •Appropriate corrections are implemented prior to release. •Code review results are reviewed and approved by management prior to release.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
	6.3.7.b Obtain and review policies to confirm that all custom application code changes for web applications must be reviewed (using either manual or automated processes) as follows: •Code changes are reviewed by individuals other then the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. •Code reviews ensure code is developed according to secure coding guidelines such as the Open Web Security Project Guide (see PCI DSS Requirement 6.5). •Appropriate corrections are implemented prior to release. •Code review results are reviewed and approved by management prior to release.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.
	6.3.7.c Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.7a and 6.3.7b above.	N/A - SDLC policy/procedures		SDLC processes are the responsibility of the merchant / service provider.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
6.4 Follow change control procedures for all changes to system components. The procedures must include the following:	6.4.a Obtain and examine company change-control procedures related to implementing security patches and software modifications, and verify that the procedures require items 6.4.1 - 6.4.4 below.
	6.4.b For a sample of system components and recent changes/security patches, trace those changes back to related change control documentation. For each change examined, perform the following:	N/A - Security Policy/Procedures (Change Control)		Change control policies and procedures is the responsibility of the merchant / service provider.
6.4.1 Documentation of impact	6.4.1 Verify that documentation of customer impact is included in the change control documentation for each sampled change.	N/A - Security Policy/Procedures (Change Control)		Change control policies and procedures is the responsibility of the merchant / service provider.
6.4.2 Management sign-off by appropriate parties	6.4.2 Verify that management sign-off by appropriate parties is present for each sampled change.	N/A - Security Policy/Procedures (Change Control)		Change control policies and procedures is the responsibility of the merchant / service provider.
6.4.3 Testing of operational functionality	6.4.3 Verify that operational functionality testing is performed for each sampled change.	N/A - Security Policy/Procedures (Change Control)		Change control policies and procedures is the responsibility of the merchant / service provider.
6.4.4 Back-out procedures	6.4.4 Verify that back-out procedures are prepared for each sampled change	N/A - Security Policy/Procedures (Change Control)		Change control policies and procedures is the responsibility of the merchant / service provider.
6.5 Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following: Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.	6.5.a Obtain and review software development processes for any web-based applications. Verify that processes require training in secure coding techniques for developers, and are based on guidance such as the OWASP guide (http://www.owasp.org).	N/A - Web-based application development (secure coding) not in scope for assessment		Web-based software development processes, including secure coding practices, are the responsibility of the merchant / service provider. In scope web-based applications include external and internal applications which process or transmit cardholder data. Cisco installed Foundstrone's "Hacme Bank" application. Hacme Bank simulates a "real-world" online banking application, which is built with a number of known and common vulnerabilities such as SQL injection and cross-site scripting. This allows users to attempt real exploits against a web application, and thus learn the specifics of the issue and how best to fix it. In addition, external websites were used to demonstrate Cisco XML Gateway's capabilities. Verizon Business observed the use of Cisco's ACE XML Gateway to protect against common web vulnerabilities and web based attacks identified under 6.5.1 - 6.5.10 (See 6.5.1 - 6.5.10 for specific details).
	6.5.b Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques.
	6.5.c Verify that processes are in place to ensure that web applications are not vulnerable to the following:
6.5.1 Cross-site scripting (XSS)	6.5.1 Cross-site scripting (XSS) (Validate all parameters before inclusion.)	Verizon Business observed the use of ACE XML Gateway to protect web applications from XML and HTML based XSS attacks. For example, ACE XML Gateway can prevent submission of XML and HTML tags to the web server (required for XSS attacks). All XSS attacks were manual and required custom configuration of the ACE XML Gateway application.		See 6.5.a above
6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws.	6.5.2 Injection flaws, particularly SQL injection (Validate input to verify user data cannot modify meaning of commands and queries.)	Verizon Business observed the use of ACE XML Gateway to protect web applications from XML and HTML based injection attacks, including SQL injection. Limiting input to specific criteria, including restricting required characters/strings for SQL attacks, was demonstrated to prevent such attacks. All SQL injection attacks were manual and required custom configuration of the ACE XML Gateway application.		See 6.5.a above
6.5.3 Malicious file execution	6.5.3 Malicious file execution (Validate input to verify application does not accept filenames or files from users.)			This vulnerability is new to the OWASP guide since the last assessment of the ACE XML Gateway. As such, the ACE XML Gateway was not assessed at that time to determine capabilities to prevent malicious file execution. This prevention capability will be assessed within the next six months as part of the next PCI Solution for Retail phase.
6.5.4 Insecure direct object references	6.5.4 Insecure direct object references (Do not expose internal object references to users.)			This vulnerability is new to the OWASP guide since the last assessment of the ACE XML Gateway. As such, the ACE XML Gateway was not assessed at that time to determine capabilities to prevent insecure direct object references. This prevention capability will be assessed within the next six months as part of the next PCI Solution for Retail phase.
6.5.5 Cross-site request forgery (CSRF)	6.5.5 Cross-site request forgery (CSRF) (Do not reply on authorization credentials and tokens automatically submitted by browsers.)			This vulnerability is new to the OWASP guide since the last assessment of the ACE XML Gateway. As such, the ACE XML Gateway was not assessed at that time to determine capabilities to prevent cross-site request forgery (CSRF). This prevention capability will be assessed within the next six months as part of the next PCI Solution for Retail phase.
6.5.6 Information leakage and improper error handling	6.5.6 Information leakage and improper error handling (Do not leak information via error messages or other means.)	Verizon Business observed the use of ACE XML Gateway to protect web applications from XML and HTML based information leakage and improper error handling vulnerabilities. HTML/XML errors from the web server can be intercepted by the ACE XML Gateway and re-written as a generic, non-descript error message. This was demonstrated during the review. All error handling attacks were manual and required custom configuration of the ACE XML Gateway application to prevent improper error handling.		See 6.5.a above
6.5.7 Broken authentication and session management	6.5.7 Broken authentication and session management (Properly authenticate users and protect account credentials and session tokens.)			See 6.5.a above Examples of broken authentication and session management prevention were not demonstrated. Such prevention could be demonstrated through secure web-coding and clean results from vulnerability scanning/penetration testing for such vulnerabilities. Additionally, Cisco is working to address additional XML and HTML based web-vulnerabilities in future releases of the product.
6.5.8 Insecure cryptographic storage	6.5.8 Insecure cryptographic storage (Prevent cryptographic flaws.)			See 6.5.a above Insecure cryptographic storage is not designed to be prevented by the ACE XML Gateway. Secure storage should be addressed through secure coding and secure web application architecture, which includes implementation of best-practice encryption/key management for storage of sensitive data.
6.5.9 Insecure communications	6.5.9 Insecure communications (Properly encrypt all authenticated and sensitive communications.)
6.5.10 Failure to restrict URL access	6.5.10 Failure to restrict URL access (Consistently enforce access control in presentation layer and business logic for all URLs.)
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: •Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes •Installing a web-application firewall in front of public-facing web applications	6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows: •Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows: – At least annually – After any changes – By an organization that specializes in application security – That all vulnerabilities are corrected – That the application is re-evaluated after the corrections •Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks. Note: "An organization that specializes in application security" can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team.			Since the last assessment of the ACE XML Gateway (December 2007), the OWASP Guideline has introduced a number of new web-application attack vectors and vulnerabilities which should be prevented by an acceptable web-application firewall solution. Since the ACE XML Gateway has not been assessed against the new Top 10 OWASP vulnerabilities, the assessor cannot make a determination as to its ability to meet this requirement at this time. The ACE XML Gateway will be assessed against the new OWASP Top 10 within the next 6 months, as part of the next PCI Solution for Retail phase.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.

"Need to know" is when access rights are granted to only the least amount of data and privileges needed to perform a job.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:	7.1 Obtain and examine written policy for data control, and verify that the policy incorporates the following:	N/A - Security Policy (Data Control / Data Classification)		Documentation for data classification / data control, including: least privilege access, role based access, authorization forms for all access, and requirements for automated access control systems, is the requirement of the merchant / service provider.
7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities	7.1.1 Confirm that access rights for privileged user IDs are restricted to least privileges necessary to perform job responsibilities.	N/A - Security Policy (Data Control / Data Classification)		Documentation for data classification / data control, including: least privilege access, role based access, authorization forms for all access, and requirements for automated access control systems, is the requirement of the merchant / service provider.
7.1.2 Assignment of privileges is based on individual personnel's job classification and function	7.1.2 Confirm that privileges are assigned to individuals based on job classification and function (also called "role-based access control" or RBAC).	N/A - Security Policy (Data Control / Data Classification)		Documentation for data classification / data control, including: least privilege access, role based access, authorization forms for all access, and requirements for automated access control systems, is the requirement of the merchant / service provider.
7.1.3 Requirement for an authorization form signed by management that specifies required privileges	7.1.3 Confirm that an authorization form is required for all access, that it must specify required privileges, and that it must be signed by management.	N/A - Security Policy (Data Control / Data Classification)		Documentation for data classification / data control, including: least privilege access, role based access, authorization forms for all access, and requirements for automated access control systems, is the requirement of the merchant / service provider.
7.1.4 Implementation of an automated access control system	7.1.4 Confirm that access controls are implemented via an automated access control system.	N/A - Security Policy (Data Control / Data Classification)		Documentation for data classification / data control, including: least privilege access, role based access, authorization forms for all access, and requirements for automated access control systems, is the requirement of the merchant / service provider.
7.2 Establish an access control system for systems components with multiple users that restricts access based on a user's need to know, and is set to "deny all" unless specifically allowed. This access control system must include the following:	7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows:	Verizon Business reviewed system settings, EMC SAN storage (zoning and LUN masking configuration), vendor documentation, and interviewed SMEs for platforms within the PCI Solution for Retail environment to confirm access control systems within the environment include the following:
7.2.1 Coverage of all system components	Confirm that access control systems are in place on all system components.	Verizon Business confirmed that access control systems are in place on the following reviewed system components: Coverage of all system components within the PCI Solution for Retail environment: •WCS (wireless console) •Cisco ACS (authentication for all network components (e.g. ISRs, routers, switches, and wireless controllers) •CiscoWorks (LMS, NCM) •CSM (Cisco Security Manager) •CSA Manager •CS-MARS •ACE XML Gateway (direct SSH or https - auth forwards to ACS -> AD) •ASA and FWSM firewalls (direct SSH or ASDM - forwards to ACS -> AD) •ISRs (direct SSH or SDM - auth forwards to ACS -> AD) •Routers and switches (direct ssh access forwards authentication to ACS -> AD) •Wireless controllers (direct ssh access forwards authentication to ACS -> AD) •Cisco IDSM-2 modules (direct SSH or IDM - local auth) •RSA Authentication Manager •RSA Access Manager •RSA File Security Manager •RSA Key Manager •RSA enVision •NCR ACS Server •CSA client software provides additional access control protection at the OS level for POS systems and all management consoles running on Windows. CSA can be configured to restrict, monitor, and alert on access to OS/application binaries, configuration and log files
7.2.2 Assignment of privileges to individuals based on job classification and function	Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.	Verizon Business confirmed that access control systems include role-based privilege assignment for all management consoles (e.g. WCS, ACS, CSA, CiscoWorks (LMS, NCM), CSM, CS-MARS, ACE XML Gateway, RSA Authentication Manager, RSA Access Manager, RSA File Security Manager, RSA Key Manager, RSA enVision, and NCR ACS Server)
7.2.3 Default "deny-all" setting	Confirm that the access control systems has a default "deny-all" setting. Note: Some access control systems are set by default to "allow-all," thereby permitting access unless/until a rule is written to specifically deny it.	Verizon Business confirmed that access control systems include default "deny-all" settings on all management consoles and network devices. ASA firewalls, FWSMs, and ISRs contain "default-deny" access lists with explicit "permit" rules defined to the port level.

Requirement 8: Assign a unique ID to each person with computer access.

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.	8.1 Verify that all users are assigned a unique ID for access to system components or cardholder data.	Verizon Business reviewed access lists for the following, to confirm all users have a unique username for access to components within the PCI Solution for Retail environment: •CS-MARS •WCS central wireless server •Cisco ACS •Cisco Security Agent (CSA) Manager •CSM (Cisco Security Manager) •CiscoWorks (LMS) •Cisco ASDM •All access to ASA firewalls, FWSMs, ISR routers, switches, and wireless controllers (authentication through Cisco ACS (which is configured to forward to Active Directory), using unique accounts. •Cisco ACE XML Gateway •CiscoWorks NCM •Cisco IDM •RSA enVision •RSA Key Manager •RSA Access Manager •RSA Authentication Manager (unique PIN + tokencode) •RSA File Security Manager - RSA File Security Manager does not support renaming the default Security Admin "SA" account. Only one SA account is allowed, so this generic account must be used for all SA functions within RSA File Security Manager. In the Cisco lab environment the RSA File Security Manager system is accessed over RDP. This would allow unique AD credentials to be captured for system access. Additionally, Cisco leveraged CSA software to further restrict, monitor, and log access to the RSA File Security Manager executable. •NCR ACS Server (unique AD credentials)
8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users: ß Password or passphrase ß Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys)	8.2 To verify that users are authenticated using unique ID and additional authentication (for example, a password) for access to the cardholder data environment, perform the following: •Obtain and examine documentation describing the authentication method(s) used. •For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).	Verizon Business reviewed authentication methods, including observation of live login attempts to confirm a unique ID and password was required for each authentication attempt to the following: •CS-MARS •WCS central wireless server •Cisco ACS •Cisco Security Agent (CSA) Manager •CSM (Cisco Security Manager) •CiscoWorks (LMS) •Cisco ASDM •All access to ASA firewalls, FWSMs, ISR routers, switches, and wireless controllers (authentication through Cisco ACS (which is configured to forward to Active Directory), using unique accounts. •Cisco ACE XML Gateway •CiscoWorks NCM •Cisco IDM •RSA enVision •RSA Key Manager •RSA Access Manager •RSA Authentication Manager (unique PIN + tokencode) •RSA File Security Manager (see 8.1 above) •NCR ACS Server (AD auth)
8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS); terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.	8.3 To verify that two-factor authentication is implemented for all remote network access, observe an employee (for example, an administrator) connecting remotely to the network and verify that both a password and an additional authentication item (for example, smart card, token, PIN) are required.	Verizon Business confirmed the use of two-factor authentication, using RSA SecurID PINs + tokencode for all remote authentication into the data center environment.		Two-factor authentication for all remote access, including for employees, contractors, and third parties, is the responsibility of the merchant / service provider.
8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography (defined in PCI DSS Glossary of Terms, Abbreviations, and Acronyms).	8.4.a For a sample of system components, examine password files to verify that passwords are unreadable during transmission and storage.	Verizon Business confirmed local ISR and switch passwords are rendered unreadable, per review of configurations. All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), ASDM, and CSM) are forwarded to Active Directory, which renders passwords unreadable. Authentication to CSA Manager is forwarded directly to Active Directory. Verizon Business also confirmed the following render local authentication credentials unreadable: •WCS (hashed) •CS-MARS (hashed) •Cisco ACE XML Gateway (hashed) •Cisco IDM (hashed) •CiscoWorks NCM (hashed) •RSA enVision (encrypted hash) •RSA Key Manager (Auth through RSA Access Manager (hashed), local auth (hashed)) •RSA Access Manager (hashed) •RSA File Security Manager (hashed) •NCR ACS (AD auth - passwords unreadable)		• RSA Authentication Manager (Evidence for RSA Authentication Manager was not provided)
	8.4.b For service providers only, observe password files to verify that customer passwords are encrypted.	N/A - Service Provider requirement		Responsibility of service provider.
8.5 Ensure proper user authentication and password management for non-consumer users and administrators on all system components as follows:	8.5 Review procedures and interview personnel to verify that procedures are implemented for user authentication and password management, by performing the following:
8.5.1 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.	8.5.1.a Select a sample of user IDs, including both administrators and general users. Verify that each user is authorized to use the system according to company policy by performing the following: •Obtain and examine an authorization form for each ID. •Verify that the sampled user IDs are implemented in accordance with the authorization form (including with privileges as specified and all signatures obtained), by tracing information from the authorization form to the system.	N/A - Security policy and procedures (ID / Account Management)		Creation of access request (authorization) forms for access to PCI "in scope" systems, including: firewalls, routers, switches, VPNs, AD domain access, servers, databases, and applications, is the responsibility of the merchant / service provider.
8.5.2 Verify user identity before performing password resets.	8.5.2 Examine password procedures and observe security personnel to verify that, if a user requests a password reset by phone, e-mail, web, or other non-face-to-face method, the user's identity is verified before the password is reset.	N/A - Security policy and procedures (ID / Account Management)		Account management / password reset procedures are the responsibility of the merchant / service provider.
8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use.	8.5.3 Examine password procedures and observe security personnel to verify that first-time passwords for new users are set to a unique value for each user and changed after first use.	N/A - Security policy and procedures (ID / Account Management)		Account management / password reset procedures are the responsibility of the merchant / service provider.
8.5.4 Immediately revoke access for any terminated users.	8.5.4 Select a sample of employees terminated in the past six months, and review current user access lists to verify that their IDs have been deactivated or removed.	N/A - Processes to ensure prompt revocation of granted access rights and deletion / disabling of user IDs is the responsibility of the merchant / service provider.
8.5.5 Remove/disable inactive user accounts at least every 90 days.	8.5.5 Verify that inactive accounts over 90 days old are either removed or disabled.	N/A - Manual audit procedure or third party ID management tool.		Note: Because most authentication systems, including Active Directory, do not have built-in audit tools to easily identify inactive user accounts, manual procedures or third party tools are necessary to identify and remove inactive accounts.
8.5.6 Enable accounts used by vendors for remote maintenance only during the time period needed.	8.5.6 Verify that any accounts used by vendors to support and maintain system components are disabled, enabled only when needed by the vendor, and monitored while being used.	N/A - No external vendor accounts were identified during the assessment.
8.5.7 Communicate password procedures and policies to all users who have access to cardholder data.	8.5.7 Interview the users from a sample of user IDs, to verify that they are familiar with password procedures and policies.	N/A - Security Policy (Security Awareness)		For each merchant / service provider - Individual interviews to be conducted with a sample of users to confirm security awareness for password procedures is in place.
8.5.8 Do not use group, shared, or generic accounts and passwords.	8.5.8.a For a sample of system components, examine user ID lists to verify the following •Generic user IDs and accounts are disabled or removed. •Shared user IDs for system administration activities and other critical functions do not exist. •Shared and generic user IDs are not used to administer any system components.	Verizon Business reviewed user ID lists for the following components within the PCI Solution for Retail environment to confirm generic and shared IDs are disabled or removed, or that unique administrative accounts are used in place of default accounts that cannot be renamed or removed: •CS-MARS •WCS central wireless server •Cisco ACS •Cisco Security Agent (CSA) Manager •CSM (Cisco Security Manager) •CiscoWorks (LMS) •Cisco ASDM •All access to ASA firewalls, FWSMs, ISR routers, switches, and wireless controllers (authentication through Cisco ACS (which is configured to forward to Active Directory), using unique accounts. •Cisco ACE XML Gateway •CiscoWorks NCM •Cisco IDM •RSA enVision •RSA Key Manager •RSA Access Manager •RSA Authentication Manager •NCR ACS		Note: "pnadmin" account on CS-MARS cannot be deleted, due to application dependencies. This account is not used interactively. All administrative accounts are unique. Additionally, RSA File Security Manager "SA" account cannot be deleted, and is the only Security Admin account on the system. See 8.1 for compensating controls used to restrict RSA File Security Manager access and capture unique credentials for RSA File Security Manager access.
	8.5.8.b Examine password policies/procedures to verify that group and shared passwords are explicitly prohibited.	N/A - Security Policy (Password policy/procedures)		Password policy/procedures are the responsibility of each merchant / service provider.
	8.5.8.c Interview system administrators to verify that group and shared passwords are not distributed, even if requested.	N/A - Security Policy (Password policy/procedures)		Password policy/procedures are the responsibility of each merchant / service provider.
8.5.9 Change user passwords at least every 90 days.	8.5.9 For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to change periodically and that customers are given guidance as to when, and under what circumstances, passwords must change.	Verizon Business reviewed system settings for authentication methods to confirm the following: •All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), ASDM, and CSM) are forwarded to Active Directory, which is set to expire passwords after 42 days. •CSA Manager (AD auth = 42 days) •Cisco ACE XML Gateway (ACS or AD auth = 42 days) •Cisco ACS (Local ACS auth - 30 day expiration) •CS-MARS (AD auth through Cisco ACS = 42 days) •WCS (AD auth through Cisco ACS = 42 days) •CiscoWorks NCM (ACS or AD auth) •RSA enVision (ACS or AD auth = 42 days) •RSA Key Manager (RSA Access Manager auth = 60 days) •RSA Access Manager (60 days) •RSA Authentication Manager (tokencode changes every 60 seconds) •NCR ACS (AD auth = 42 days)	The following do not currently support password expiration, and do not currently support external authentication (e.g. TACACS or AD): - Cisco IDM - RSA File Security Manager (to be addressed in FSM v2.2 release)	Note: A combination of documented password policies, manual audit procedures to ensure passwords are being changed every 90 days, and internal firewall segmentation of these components within the data center, would be reasonable compensating controls for password setting limitations within these applications.
8.5.10 Require a minimum password length of at least seven characters.	8.5.10 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least seven characters long. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to meet minimum length requirements.	Verizon Business reviewed system settings for authentication methods to confirm the following: •- All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), ASDM, and CSM) are forwarded to Active Directory, which enforces passwords to contain a minimum of 7 characters. •CSA Manager (AD Auth = min 7 chars) •Cisco ACE XML Gateway (ACS or AD auth = min 7 chars, local auth= 8 characters) •CS-MARS (AD auth through Cisco ACS = min 7 chars) •Cisco ACS (local ACS auth = 8 character minimum) •WCS (AD auth through Cisco ACS = min 7 chars) •CiscoWorks NCM (ACS or AD auth, local auth= 8 characters) •RSA enVision (ACS or AD auth = min 7 chars) •RSA Key Manager (RSA Access Manager auth = 8 characters) •RSA Access Manager (8 characters) •RSA Authentication Manager (PIN + tokencode = min 10, max 16) •NCR ACS (AD auth = min 7 chars)	The following do not currently enforce password complexity (e.g. length, alpha-numeric, history, etc), and do not currently support external authentication (e.g. TACACS or AD): •Cisco IDM •RSA File Security Manager (to be addressed in FSM v2.2 release)	Note: A combination of documented password policies, manual audit procedures to ensure strong password generation, using periodic dictionary attacks against passwords, and internal firewall segmentation of these components within the data center, would be reasonable compensating controls for password setting limitations within these applications.
8.5.11 Use passwords containing both numeric and alphabetic characters.	8.5.11 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to contain both numeric and alphabetic characters. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to contain both numeric and alphabetic characters.	Verizon Business reviewed system settings for authentication methods to confirm the following: •- All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), and CSM) are forwarded to Active Directory, which enforces alpha-numeric passwords. •CSA Manager (AD Auth = alpha-numeric) •Cisco ACE XML Gateway (ACS or AD auth = alpha-numeric) •Cisco ACS (local ACS auth = alpha-numeric) •CS-MARS (AD auth through Cisco ACS = alpha-numeric) •WCS (AD auth through Cisco ACS = alpha-numeric) •CiscoWorks NCM (ACS or AD auth = alpha-numeric, local auth requires upper/lower case + at least 1 special character or digit) •RSA enVision (ACS or AD auth = alpha-numeric) •RSA Key Manager (RSA Access Manager auth = alpha-numeric + dictionary check) •RSA Access Manager (alpha-numeric + dictionary check) •RSA Authentication Manager (supports alpha-numeric) •NCR ACS (AD auth = alpha-numeric)	The following do not currently enforce password complexity (e.g. length, alpha-numeric, history, etc), and do not currently support external authentication (e.g. TACACS or AD): •Cisco IDM •RSA File Security Manager (to be addressed in FSM v2.2 release)	Note: A combination of documented password policies, manual audit procedures to ensure strong password generation, using periodic dictionary attacks against passwords, and internal firewall segmentation of these components within the data center, would be reasonable compensating controls for password setting limitations within these applications.
8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.	8.5.12 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords. For service providers only, review internal processes and customer/user documentation to verify that new customer passwords cannot be the same as the previous four passwords.	Verizon Business reviewed system settings for authentication methods to confirm the following: •- All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), ASDM, and CSM) are forwarded to Active Directory, which enforces password history for the last 24 passwords. •- CSA Manager (AD Auth = last 24 passwords) •Cisco ACE XML Gateway (ACS or AD auth = last 24 passwords) •Cisco ACS (local ACS auth = last 5 passwords) •CS-MARS (AD auth through Cisco ACS = last 24 passwords) •WCS (AD auth through Cisco ACS = last 24 passwords) •CiscoWorks NCM (ACS or AD auth = last 24 passwords) •RSA enVision (ACS or AD auth = last 24 passwords) •RSA Key Manager (RSA Access Manager auth = last 10 passwords) •RSA Access Manager (last 10 passwords) •RSA Authentication Manager (tokencode changes to random value every 60 seconds) •NCR ACS (AD auth = last 24 passwords)	The following do not currently enforce password complexity (e.g. length, alpha-numeric, history, etc), and do not currently support external authentication (e.g. TACACS or AD): •Cisco IDM (will be addressed in Cisco IDM v6.1 release) •RSA File Security Manager (to be addressed in FSM v2.2 release)	Note: A combination of documented password policies and internal firewall segmentation of these components within the data center would be reasonable compensating controls for password setting limitations within these applications.
8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts.	8.5.13 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that a user's account is locked out after not more than six invalid logon attempts. For service providers only, review internal processes and customer/user documentation to verify that customer accounts are temporarily locked-out after not more than six invalid access attempts.	Verizon Business reviewed system settings for authentication methods to confirm the following: •- All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), ASDM, and CSM) are forwarded to Active Directory, which enforces account lockouts after 5 invalid logon attempts. •CSA Manager (AD Auth = 5 invalid attempts) •Cisco ACE XML Gateway (ACS or AD auth = 5 invalid attempts, local auth= 3 invalid attempts) •Cisco ACS (local ACS auth = 6 invalid attempts) •CS-MARS (AD auth through Cisco ACS = 5 invalid attempts) •WCS (AD auth through Cisco ACS = 5 invalid attempts) •CiscoWorks NCM (ACS or AD auth = 5 invalid attempts, local auth= 6 invalid attempts) •Cisco IDM (5 invalid attempts) •RSA enVision (ACS or AD auth = 5 invalid attempts) •RSA Key Manager (RSA Access Manager auth = 3 invalid attempts in one day) •RSA Access Manager (3 invalid attempts in one day) •RSA Authentication Manager (3 invalid passcodes forces "next token" mode, which requires two consecutive tokencodes to be entered. 6 failed attempts disables token use) •NCR ACS (AD auth = 5 invalid attempts)	The following do not currently support account lockouts, and do not currently support external authentication (e.g. TACACS or AD): •RSA File Security Manager (to be addressed in FSM v2.2 release)	Note: Using CSA or other monitoring software to alert on continuous invalid logon attempts, combined with internal firewall segmentation of these components, would be reasonable compensating controls for account lockout setting limitations within these applications.
8.5.14 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.	8.5.14 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account.	Verizon Business reviewed system settings for authentication methods to confirm the following: •All authentication through ACS (access to ASA firewalls, FWSMs, ISRs, routers, switches, and wireless controllers), CiscoWorks (LMS), ASDM, and CSM) are forwarded to Active Directory, which enforces account lockouts for 30 minutes. •CSA Manager (AD Auth = 30 min lockout) •Cisco ACE XML Gateway (ACS or AD auth = 30 min lockout, local auth= admin must reset) •Cisco ACS (local ACS auth = admin must reset) •CS-MARS (AD auth through Cisco ACS = 30 min lockout) •WCS (AD auth through Cisco ACS = 30 min lockout) •CiscoWorks NCM (ACS or AD auth = 30 min lockout, local auth= admin must reset) •Cisco IDM (Admin must reset) •RSA enVision (ACS or AD auth = 30 min lockout) •RSA Key Manager (RSA Access Manager auth = admin must reset) •RSA Access Manager (admin must reset) •RSA Authentication Manager (admin must reset) •NCR ACS (AD auth = 30 min lockout)	The following do not currently support account lockouts, and do not currently support external authentication (e.g. TACACS or AD): •RSA File Security Manager (to be addressed in FSM v2.2 release)	Note: Using CSA or other monitoring software to alert on continuous invalid logon attempts, combined with internal firewall segmentation of these components, would be reasonable compensating controls for account lockout setting limitations within these applications.
8.5.15 If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal.	8.5.15 For a sample of system components, obtain and inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less.	Verizon Business confirmed the following components within the PCI Solution for Retail environment have sufficient idle timeout settings: •ISRs and switches: (15 minute session-timeout and 15 minute exec-timeout) •ASA firewalls (15 minutes - ssh) •Wireless controllers (15 minutes - ssh) •CiscoWorks (LMS): (15 minutes) •CS-MARS: (15 minutes) •CSM Manager: (15 minutes) •Cisco ACS: (15 minutes) •CSA Manager: (15 minutes) •Cisco ACE XML Gateway (15 minutes) •CiscoWorks NCM (15 minutes) •RSA enVision (10 minutes) •RSA Key Manager (15 minutes) •RSA Access Manager (10 minutes) •NCR ACS (configurable to 1 minute)	The following do not support idle session timeouts (15 minutes or less) for administrative connections: •WCS •IDM •Wireless controllers (web interface) •ASDM •IDM •RSA File Security Manager (to be addressed in FSM v2.2 release) •RSA Authentication Manager	Note: Screensaver timeouts can be used as a compensating control, when idle session timeouts are not available or impact application/business operations (e.g. backup jobs).
8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.	8.5.16.a Review database and application configuration settings and verify that user authentication and access to databases includes the following: •All users are authenticated prior to access. •All user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures). •Direct access or queries to databases are restricted to database administrators.	N/A - Database security not part of the PCI Solution for Retail environment assessment.		Note: Ensuring authentication is enabled on all database components storing cardholder data is the responsibility of the merchant / service provider.
	8.5.16.b Review database applications and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes).	N/A - Database security not part of the PCI Solution for Retail environment assessment.		Note: Database security, including prohibiting direct SQL queries to the database is the responsibility of the merchant / service provider. Database login accounts should be limited to application accounts and very few dba accounts.

Requirement 9: Restrict physical access to cardholder data.

Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.	9.1 Verify the existence of physical security controls for each computer room, data center, and other physical areas with systems in the cardholder data environment. •Verify that access is controlled with badge readers or other devices including authorized badges and lock and key. •Observe a system administrator's attempt to log into consoles for randomly selected systems in the cardholder environment and verify that they are "locked" to prevent unauthorized use.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law. Note: "Sensitive areas" refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store.	9.1.1 Verify that video cameras or other access control mechanisms are in place to monitor the entry/exit points to sensitive areas. Video cameras or other mechanisms should be protected from tampering or disabling. Verify that video cameras or other mechanisms are monitored and that data from cameras or other mechanisms is stored for at least three months.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.1.2 Restrict physical access to publicly accessible network jacks.	9.1.2 Verify by interviewing network administrators and by observation that network jacks are enabled only when needed by authorized employees. For example, conference rooms used to host visitors should not have network ports enabled with DHCP. Alternatively, verify that visitors are escorted at all times in areas with active network jacks.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices.	9.1.3 Verify that physical access to wireless access points, gateways, and handheld devices is appropriately restricted.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.2 Develop procedures to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder data is accessible. For purposes of this requirement, "employee" refers to full-time and part-time employees, temporary employees and personnel, and contractors and consultants who are "resident" on the entity's site. A "visitor" is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter the facility for a short duration, usually not more than one day.	9.2.a Review processes and procedures for assigning badges to employees, and visitors, and verify these processes include the following: •Granting new badges, changing access requirements, and revoking terminated employee and expired visitor badges •Limited access to badge system	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
	9.2.b Observe people within the facility to verify that it is easy to distinguish between employees and visitors.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.3 Make sure all visitors are handled as follows:	9.3 Verify that employee/visitor controls are in place as follows:	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.3.1 Authorized before entering areas where cardholder data is processed or maintained	9.3.1 Observe visitors to verify the use of visitor ID badges. Attempt to gain access to the data center to verify that a visitor ID badge does not permit unescorted access to physical areas that store cardholder data.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.3.2 Given a physical token (for example, a badge or access device) that expires and that identifies the visitors as non-employee	9.3.2 Examine employee and visitor badges to verify that ID badges clearly distinguish employees from visitors/outsiders and that visitor badges expire.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.3.3 Asked to surrender the physical token before leaving the facility or at the date of expiration	9.3.3 Observe visitors leaving the facility to verify visitors are asked to surrender their ID badge upon departure or expiration.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.4 Use a visitor log to maintain a physical audit trail of visitor activity. Document the visitor's name, the firm represented, and the employee authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law.	9.4.a Verify that a visitor log is in use to record physical access to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
	9.4.b Verify that the log contains the visitor's name, the firm represented, and the employee authorizing physical access, and is retained for at least three months.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location's security at least annually.	9.5 Verify that the storage location is reviewed at least annually to determine that back-up media storage is secure.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.6 Physically secure all paper and electronic media that contain cardholder data.	9.6 Verify that procedures for protecting cardholder data include controls for physically securing paper and electronic media (including computers, removable electronic media, networking, and communications hardware, telecommunication lines, paper receipts, paper reports, and faxes).	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.7 Maintain strict control over the internal or external distribution of any kind of media that contains cardholder data, including the following:	9.7 Verify that a policy exists to control distribution of media containing cardholder data, and that the policy covers all distributed media including that distributed to individuals.	N/A - Security Policy/Procedures (Physical Security/Data Classification)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.7.1 Classify the media so it can be identified as confidential.	9.7.1 Verify that all media is classified so that it can be identified as "confidential."	N/A - Security Policy/Procedures (Physical Security/Data Classification)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.7.2 Send the media by secured courier or other delivery method that can be accurately tracked.	9.7.2 Verify that all media sent outside the facility is logged and authorized by management and sent via secured courier or other delivery method that can be tracked.	N/A - Security Policy/Procedures (Physical Security/Data Classification)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.8 Ensure management approves any and all media containing cardholder data that is moved from a secured area (especially when media is distributed to individuals).	9.8 Select a recent sample of several days of offsite tracking logs for all media containing cardholder data, and verify the presence in the logs of tracking details and proper management authorization.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.9 Maintain strict control over the storage and accessibility of media that contains cardholder data.	9.9 Obtain and examine the policy for controlling storage and maintenance of hardcopy and electronic media and verify that the policy requires periodic media inventories.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.	9.9.1 Obtain and review the media inventory log to verify that periodic media inventories are performed at least annually.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.10 Destroy media containing cardholder data when it is no longer needed for business or legal reasons as follows:	9.10 Obtain and examine the periodic media destruction policy and verify that it covers all media containing cardholder data and confirm the following:	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.10.1 Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed.	9.10.1.a Verify that hard-copy materials are cross-cut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
	9.10.1.b Examine storage containers used for information to be destroyed to verify that the containers are secured. For example, verify that a "to-be-shredded" container has a lock preventing access to its contents.	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.
9.10.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.	9.10.2 Verify that cardholder data on electronic media is rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise physically destroying the media (for example, degaussing).	N/A - Security Policy/Procedures (Physical Security)		Physical security (policies, procedures, and controls) is the responsibility of the merchant / service provider.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data.

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.	10.1 Verify through observation and interviewing the system administrator, that audit trails are enabled and active for system components.	Verizon Business confirmed through interviews and review of configured log settings, as well as review of the audit trail, that audit trails are enabled and active for the following components within the PCI Solution for Retail environment: •ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers (direct ssh access) –AD auth logs (Cisco ACS auth requests forwarded to AD). –CiscoWorks (LMS) - for configuration management (non-security related) - (wireless logs not sent to LMS) –CSM (security alerts (e.g. firewall logs, IDS alerts, etc) sent from devices to CSM are forwarded to CS-MARS) –CiscoWorks NCM (configuration changes, policy/standards violations) •Cisco ACS –Local and AD authentication logs (auth requests forwarded to AD) –Local audit trail for ACS management •CSM (Cisco Security Manager) –AD auth logs (Cisco ACS auth requests forwarded to AD). –Local audit trail for CSM management •-CSA (Cisco Security Agent) Manager –AD authentication logs (authentication requests sent directly to AD). –All CSA logs, alerts/events sent to CSA manager –Local audit trail for CSA management •CS-MARS –Local authentication logs (no ACS or AD authentication available) –CSA logging/alerts, CSM security events (firewall logs (ASAs and ISRs), IDS/IPS alerts) –Local audit trail for CS-MARS •WCS (Wireless Console Server) –Local authentication –Local audit trail for WCS management and wireless configuration changes •CiscoWorks (LMS) –AD auth logs (Cisco ACS auth requests forwarded to AD). –ISR (router) and switch configuration management logs –Local audit trail for LMS management		Note: WCS audit trail exists for authentication and administrative access; however, the audit trail is difficult to follow and could require significant time, including experienced Cisco support to fully understand and piece together the audit trail.
		•CiscoWorks NCM –AD auth logs (Cisco ACS auth requests forwarded to AD). –Audit trail of network device configuration changes (date and time of change, who made the change, and lines of configuration changed). –Local audit trail for NCM management •Cisco ASDM –AD auth logs (Cisco ACS auth requests forwarded to AD). –ASA firewall configuration changes and IDS/IPS alerts sent to CS-MARS. •Cisco IDM –IDM local auth logs and local configuration changes. •Cisco ACE XML Gateway –AD auth logs (Cisco ACS auth requests forwarded to AD). –Local audit trail for ACE XML Gateway management. •RSA SecurID –RSA SecurID access logged through RSA Authentication Manager. –RSA SecurID logs captured by RSA enVision for reporting, alerting, and long-term storage. •RSA Authentication Manager –RSA SecurID authentication attempts –Local audit trail for RSA Authentication Manager administrative access/mgmt. –Audit log SFTP'd to RSA enVision every 60 minutes for reporting, alerting, and long-term storage. •RSA Access Manager –RSA Key Manager authentication logs –Local audit trail for RSA Access Manager access/management. •RSA File Security Manager (RSA File Security Manager) –Local/AD auth logs (access to server) –CSA (Monitors and logs RSA File Security Manager binary use) –Access to RSA File Security Manager protected resources (e.g. access to cardholder data) –Local audit trail for RSA File Security Manager access/management.
		•RSA Key Manager –Local/AD auth logs (access to server) –CSA (Monitors and logs Key Manager binary use) –Key Material requests –Local audit trail for Key Manager access/management. •RSA enVision –RSA local/AD auth logs –Local audit trail for RSA enVision access/management. –Local audit trail for RSA enVision log repository access. –RSA SecurID access logs (SFTP'd from RSA Authentication Manager every 60 minutes). •NCR ACS Server –Local/AD logs for server access –CSA (Monitors and logs NCR ACS binary use and access to NCR ACS application log files) –Local audit trail for NCR ACS access/management.
10.2 Implement automated audit trails for all system components to reconstruct the following events:	10.2 Through interviews, examination of audit logs, and examination of audit log settings, perform the following:
10.2.1 All individual accesses to cardholder data	10.2.1 Verify all individual access to cardholder data is logged.	Verizon Business confirmed the following log access to cardholder data within the Cisco's PCI Solution for Retail environment: •NCR ACS (logs to EFT log file and Transaction Log) •RSA File Security Manager (logs access to cardholder data protected by RSA File Security Manager) •RSA Key Manager (logs key material requests (necessary for decryption of cardholder data)) •Cisco CSA (installed on all Windows servers within the PCI Solution for Retail environment and configured to monitor and log use of NCR ACS application binaries and log files. Only encrypted cardholder data is accessible within NCR application log files. These files have been configured through Cisco CSA to only allow necessary process and administrative accounts access. Only masked data is accessible through the NCR ACS application.)
10.2.2 All actions taken by any individual with root or administrative privileges	10.2.2 Verify actions taken by any individual with root or administrative privileges is logged.	Verizon Business reviewed audit log configurations to confirm administrative actions are logged for the following: •Management of ASA firewalls, FWSMs, ISRs, routers, IDSM2, switches (ASDM, SDM, CSM, or SSH (forwarded to CS-MARS), CiscoWorks (LMS)) •CS-MARS administration (CS-MARS audit trail) •ACS administration (CSA and local ACS audit trail) •CSA administration (CSA and local CSA audit trail) •CiscoWorks administration (LMS) (CSA and local LMS audit trail) •Wireless controllers (WCS logs) •WCS (CSA and local WCS audit trail - Administrative changes to WCS are logged to the audit trail, but difficult to determine the details of the change) •CSM administration (CSA and local CSM audit trail) •NCM administration (CSA and NCM audit trail) •Cisco ACE XML Gateway (local ACE XML Gateway audit trail) •Cisco IDM (local IDM audit trail) •RSA Authentication Manager (CSA, local RSA Authentication Manager audit trail, RSA enVision (SFTP'd from RSA Authentication Manager every 60 minutes)) •RSA Access Manager (CSA, local RSA Access Manager audit trail) •RSA Key Manager (local audit trail for Key Manager administration) •RSA enVision (local audit trail for enVision administration) •NCR ACS Server (local EFT and Transaction Log files) Note: Reference to CSA is for administrative changes on Windows host OS for each application running on Windows.	The following have limited audit trails, related to administrative actions: •RSA File Security Manager (not all administrative actions are logged - to be addressed in FSM v2.2 release)	Note: Wireless audit trail exists for authentication and administrative access; however, the audit trail is difficult to follow and could require significant time, including experienced Cisco support to fully understand and piece together the audit trail.
10.2.3 Access to all audit trails	10.2.3 Verify access to all audit trails is logged.	Verizon Business observed CSA Manager policies, log directories and log files monitored by CSA, and CSA event logs generated upon unauthorized access of audit log files and directories, to determine access to the following audit trails is being logged: •ACS, CiscoWorks (LMS, NCM), CSA Manager, CSM, WCS Manager, RSA Authentication Manager, RSA Access Manager, RSA File Security Manager, RSA Key Manager, NCR ACS: –Live log directory and files (CSA is configured to allow application services to write/delete/modify files in the live log directory and rotate (archive) log files to an archive directory. All other users and processes are restricted from accessing, modifying, or deleting files within the live log directories. This prevents users from accessing the audit trail outside of the application (ACS, CiscoWorks (LMS, NCM), WCS, CSM, CSA console, RSA Authentication Manager, RSA Access Manager, RSA File Security Manager, RSA Key Manager, NCR ACS). Cisco created a custom archive script which is run from a central backup server and copies all audit logs to a central backup server, where additional CSA protection can be applied. The archive directories are monitored to protect all processes and users from deleting or modifying files written to the archive directory, other than the backup user account which copies files to this directory (necessary to copy files and delete files older than 1 year). •CS-MARS (appliance server, which does not support CSA) –Audit log files backed up daily to an NFS backup server are monitored by CSA and all processes and users (except the application processes responsible for writing data to the NFS server) are prohibited from modifying or deleting files from this directory. •RSA enVision (not monitored by CSA, because log files are stored within a proprietary database) –Access to application is restricted to least privilege, role-based accounts, and logged –Details on reports run/viewed is logged Verizon Business observed unauthorized attempts to access the audit trail, outside the application. CSA alerts were generated, sent to the CS-MARS central server, and an email alert was sent to the administrator.		Note: Management consoles reviewed did not log access to audit trails, without CSA monitoring of audit logs. Cisco used a custom archive/backup method to copy the audit trail to a central backup server. Cisco has inserted the script within the Appendix of their implementation guide.
10.2.4 Invalid logical access attempts	10.2.4 Verify invalid logical access attempts are logged.	Verizon Business confirmed that invalid logical access attempts are logged for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers •Access to CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, CSM, and ACE XML Gateway, IDM •Access to RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager •NCR ACS Server
10.2 5 Use of identification and authentication mechanisms	10.2.5 Verify use of identification and authentication mechanisms is logged.	Verizon Business confirmed that userID for authentication is logged for authentication to the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, CSM, ACE XML Gateway, IDM •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager •NCR ACS Server
10.2.6 Initialization of the audit logs	10.2.6 Verify initialization of audit logs is logged.	Verizon Business confirmed that RSA enVision does not provide capabilities to delete the audit trail through the application. See 10.2.3 (CSA protection for audit trail access applies to initialization of audit trail)		See 10.2.3 (CSA protection for audit trail access applies to initialization of audit trail)
10.2.7 Creation and deletion of system-level objects	10.2.7 Verify creation and deletion of system level objects are logged.	Verizon Business confirmed CSA is installed on all Windows servers within the PCI Solution for Retail environment and is configured to capture deletion of system level objects. Additionally, CiscoWorks (LMS, NCM), and CSM capture all administrative actions for ASA firewalls, FWSMs, ISRs, IDSM2 and switches.
10.3 Record at least the following audit trail entries for all system components for each event:	10.3 Through interviews and observation, for each auditable event (from 10.2), perform the following:
10.3.1 User identification	10.3.1 Verify user identification is included in log entries.	Verizon Business confirmed userID is captured in the audit trail for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, ACE XML Gateway, IDM, and CSM. •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager •NCR ACS Server
10.3.2 Type of event	10.3.2 Verify type of event is included in log entries.	Verizon Business confirmed event type is captured in the audit trail for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers (LMS, NCM, and CSM contain detailed audit trail records for security and device configuration changes) •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, ACE XML Gateway, IDM, and CSM (contained within local audit trails) •CSA generated logs and alerts contain event type within each record. •ACS and AD contain event type within each authentication record. •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager (contained within local audit trail records) •NCR ACS Server (contained within EFT and Transaction Log files)
10.3.3 Date and time	10.3.3 Verify date and time stamp is included in log entries.	Verizon Business confirmed date and time stamp is captured in the audit trail for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers (LMS, NCM, and CSM contain detailed audit trail records for security and device configuration changes) •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, ACE XML Gateway, IDM, and CSM (date and time stamp contained within local audit trail records) •CSA generated logs and alerts contain a date and time stamp within each record. •ACS and AD contain date and time stamp for each authentication record. •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager (contained within local audit trail records) •NCR ACS Server (contained within EFT and Transaction Log files)
10.3.4 Success or failure indication	10.3.4 Verify success or failure indication is included in log entries.	Verizon Business confirmed "success or failure" indication is captured in the audit trail for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers (LMS, NCM, and CSM contain detailed audit trail records for security and device configuration changes - audit events would indicate a successful change to the configuration. Failed actions based on insufficient permissions would be logged in the ACS audit trail.) •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, ACE XML Gateway, IDM, and CSM (success or failure is evident based on event type and/or event detail). •"Success" or "Failure" indication is evident within CSA generated logs and alerts based on the event type. •ACS and AD logs contain success or failure indication for each authentication record. •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager (evident based on details within audit trail records) •NCR ACS Server (evident based on details within audit trail records)
10.3.5 Origination of event	10.3.5 Verify origination of event is included in log entries.	Verizon Business confirmed "origination of event" is captured in the audit trail for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers (LMS, NCM, and CSM contain detailed audit trail records for security and device configuration changes - security and syslog messages indicate originating device.) •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, ACE XML Gateway, IDM, and CSM (local audit trail indicates whether event is locally generated or sent from managed device). •CSA generated logs and alerts indicate originating host. •ACS and AD logs contain originating system for each authentication record. •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager (contained within local audit trail records) •NCR ACS Server (all records are local to system)
10.3.6 Identity or name of affected data, system component, or resource	10.3.6 Verify identity or name of affected data, system component, or resources is included in log entries.	Verizon Business confirmed "name of affected data, system component, or resource" is captured in the audit trail for the following: •All ASA firewalls, FWSMs, ISRs, routers, switches, IDSM2, and wireless controllers (LMS, NCM, and CSM contain detailed audit trail records for security and device configuration changes - security and syslog messages indicate specific configuration changes being made.) •CS-MARS, CSA Manager, Cisco ACS, CiscoWorks (LMS, NCM), WCS, ACE XML Gateway, IDM, and CSM (local audit trail indicates affected data or resource through event type). •CSA generated logs and alerts indicate detailed information on affected data. •RSA enVision, RSA Key Manager, RSA File Security Manager, RSA Authentication Manager, and RSA Access Manager (evident based on details within audit trail records) •NCR ACS Server (evident based on details within audit trail records)
10.4 Synchronize all critical system clocks and `times.	10.4 Obtain and review the process for acquiring and distributing the correct time within the organization, as well as the time-related system-parameter settings for a sample of system components. Verify the following is included in the process and implemented:	Verizon Business reviewed device configurations to confirm management consoles, ACE XML Gateway, ASA firewalls, FWSMs, IDSM2, ISR routers, switches, and wireless devices synchronize system clocks as follows:
	10.4.a Verify that a known, stable version of NTP (Network Time Protocol) or similar technology, kept current per PCI DSS Requirements 6.1 and 6.2, is used for time synchronization.	NTP is used for all time synchronization on all system components reviewed.
	10.4.b Verify that internal servers are not all receiving time signals from external sources. [Two or three central time servers within the organization receive external time signals [directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT)], peer with each other to keep accurate time, and share the time with other internal servers.]	Verizon Business reviewed network device configurations and Windows registry settings to confirm all servers and network devices within the PCI Solution for Retail environment point to at least two internal NTP servers.
	10.4.c Verify that specific external hosts are designated from which the timeservers will accept NTP time updates (to prevent a malicious individual from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the NTP service (to prevent unauthorized use of internal time servers). See www.ntp.org for more information	Verizon Business reviewed vendor documentation for the NTP appliances. Internal NTP appliances point to a pool of IP addresses under pool.ntp.org and time.nist.gov. Internal NTP servers do not receive NTP updates, but poll external servers for time updates.
10.5 Secure audit trails so they cannot be altered.	10.5 Interview system administrator and examine permissions to verify that audit trails are secured so that they cannot be altered as follows:
10.5.1 Limit viewing of audit trails to those with a job-related need.	10.5.1 Verify that only individuals who have a job-related need can view audit trail files.	Verizon Business confirmed CS-MARS and RSA enVision, as well as all back-end management consoles, are segmented behind multiple firewalls within the data center environment. All firewalls have been configured to only allow necessary inbound and outbound traffic. See 10.2.3 for additional audit trail access details.		See 10.2.3
10.5.2 Protect audit trail files from unauthorized modifications.	10.5.2 Verify that current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.	See 10.2.3/10.5.1 above		See 10.2.3
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.	10.5.3 Verify that current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.	Verizon Business confirmed centrally stored audit logs within CS-MARS are archived once an hour and sent to a central NFS server running CSA software. CiscoWorks (LMS) is archiving audit trail once a day. (See 10.2.3 for additional details of audit trail archiving) RSA enVision centrally stores RSA SecurID log records (sent every 60 minutes from RSA Authentication Manager).		See 10.2.3
10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.	10.5.4 Verify that logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are offloaded or copied onto a secure centralized internal log server or media.	Verizon Business confirmed wireless logs and firewall logs are sent to WCS and CS-MARS central servers.
10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).	10.5.5 Verify the use of file-integrity monitoring or change-detection software for logs by examining system settings and monitored files and results from monitoring activities.	Cisco Security Agent (CSA) software is used to monitor and protect access to audit trail files, and alert on unauthorized attempts to modify the audit trail (only application services responsible for writing log data can write/modify/delete the audit trail). Cisco has created an additional backup script to copy the audit trail to a central backup server, where CSA protection has been applied to eliminate all access, modification, and deletion, except for the account responsible for backing up the audit trail (see 10.2.3 for additional details). RSA enVision's proprietary database uses 32-bit checksums for log record integrity, in addition to it's write-once, read-many design. Audit records cannot be modified through the application.
10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6	10.6.a Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.	Verizon Business confirmed the use of CS-MARS, RSA enVision, and CSA software, which perform correlation and analysis of system events, and alert on those warranting immediate action. Note: Documented security policies and procedures need to require daily review of security logs, including follow-up to exceptions (responsibility of merchant / service provider)		Note: Although manual log review, escalation, and follow-up procedures would be the responsibility of the merchant / service provider, automated log correlation, analysis, and alerting is the most efficient way to stay on top of copious amounts of log data.
	10.6.b Through observation and interviews, verify that regular log reviews are performed for all system components.	See 10.6.a above.		Interviews to be conducted with each merchant / service provider.
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).	10.7.a Obtain and examine security policies and procedures and verify that they include audit log retention policies and require audit log retention for at least one year.	N/A - Security Policy (Data Retention)		Retention policy and procedure documentation is the responsibility of the merchant / service provider.
	10.7.b Verify that audit logs are available for at least one year and processes are in place to restore at least the last three months' logs for immediate analysis.	Verizon Business reviewed online logs and audit trail archive methods within the PCI Solution for Retail environment to confirm audit trails can be retained for at least one year, with at least three months available online.		Note: Due to the nature of the lab environment reviewed, and the recent addition to some components within the environment, archive logs were not available for the full 90 days, for all components; however, sufficient disk space is available to accommodate this logging. Additionally, log retention is directly dependant on the amount of logging within the environment. Proper sizing, based on expected traffic patterns, is critical to ensuring sufficient space is available for online logs.

Requirement 11: Regularly test security systems and processes.

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.	11.1.a Verify that a wireless analyzer is used at least quarterly, or that a wireless IDS/IPS is implemented and configured to identify all wireless devices.	Verizon Business confirmed that wireless controllers are configured to continually scan and detect rogue APs and wireless devices.
	11.1.b If a wireless IDS/IPS is implemented, verify the configuration will generate alerts to personnel.			Wireless IDS/IPS is a new (optional) control within the PCI DSS v1.2 standard. The wireless infrastructure assessed as part of phase 2 was not assessed to determine wireless IDS/IPS capabilities.
	11.1 c Verify the organization's Incident Response Plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider
11.2 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). Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by the company's internal staff.	11.2.a Inspect output from the most recent four quarters of internal network, host, and application vulnerability scans to verify that periodic security testing of the devices within the cardholder data environment occurs. Verify that the scan process includes rescans until passing results are obtained. Note: External scans conducted after network changes, and internal scans, may be performed by the company's qualified internal personnel or third parties.	N/A - Internal quarterly scanning		Responsibility of merchant / service provider.
	11.2.b Verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, by inspecting output from the four most recent quarters of external vulnerability scans to verify that: Four quarterly scans occurred in the most recent 12-month period; The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities); The scans were completed by an Approved Scanning Vendor (ASV) qualified by PCI SSC. Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.	N/A - Third party external, quarterly scanning		Responsibility of merchant / service provider.
	11.2.c Verify that internal and/or external scanning is performed after any significant change in the network, by inspecting scan results for the last year. Verify that the scan process includes rescans until passing results are obtained.	N/A - Third party external scanning / Internal scanning		Responsibility of merchant / service provider.
11.3 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:	11.3.a Obtain and examine the results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment. Verify that noted vulnerabilities were corrected and testing repeated.	N/A - Penetration Testing (at least annually)		Responsibility of merchant / service provider. Note: Penetration testing needs to be conducted on internal and external system components (network devices, applications, and servers), which are "in scope" for PCI.
	11.3.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).	N/A - Penetration Testing (at least annually)		Responsibility of merchant / service provider. Note: Penetration testing is to be conducted by a qualified internal resource or qualified external third party. Internal resources should be independent from resources responsible for the systems being tested (e.g. should not be the network / system administrator).
11.3.1 Network-layer penetration tests	11.3.1 Verify that the penetration test includes network-layer penetration tests. These tests should include components that support network functions as well as operating systems.	N/A - Penetration Testing (at least annually)		Responsibility of merchant / service provider.
11.3.2 Application-layer penetration tests	11.3.2 Verify that the penetration test includes application-layer penetration tests. For web applications, the tests should include, at a minimum, the vulnerabilities listed in Requirement 6.5.	N/A - Penetration Testing (at least annually)		Responsibility of merchant / service provider.
11.4 Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines up-to-date.	11.4.a Verify the use of intrusion-detection systems and/or intrusion-prevention systems and that all traffic in the cardholder data environment is monitored.	Verizon Business reviewed the PCI Solution for Retail environment, including device configurations and confirmed Cisco ASA firewalls (with integrated IDS/IPS), ISRs (with integrated IOS IDS), and IDSM-2 modules were configured with full IDS functionality. Verizon Business reviewed IDS placement within the retail and datacenter (Internet Edge, WAN edge, and core data center segments) networks, and confirmed that all critical traffic to, from, and within the PCI Solution for Retail environment would be subject to IDS monitoring. Cisco CSA (host-based IDS/IPS) is also used on critical POS servers and management consoles (e.g. CSM, CiscoWorks (LMS, NCM), CSA console, ACS, and WCS console).
	11.4.b Confirm IDS and/or IPS are configured to alert personnel of suspected compromises.	Verizon Business confirmed IDS/IPS is in place and can be configured to monitor and alert personnel of suspected compromise.
	11.4.c Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection.	Verizon Business confirmed ASA firewalls, FWSMs, ISRs, and IDSM-2 versions are running updated releases, and are configured to automatically update IDS/IPS signatures. CSA (host-based IDS/IPS) does not rely on signatures, but is behavioral based, eliminating the need to update signatures.
11.5 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. 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 (that is, the merchant or service provider).	Verify the use of file-integrity monitoring products within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities. Examples of files that should be monitored: •System executables •Application executables •Configuration and parameter files •Centrally stored, historical or archived, log and audit files	Verizon Business reviewed vendor documentation and observed Cisco Security Agent software in the PCI Solution for Retail environment. In addition to logging and alerting on critical file modification, CSA can also log and alert on attempted access, allowed or denied. Since the initial phase I review of CSA, CSA has been updated with new PCI rules, complete with critical OS files.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for employees and contractors.

A strong security policy sets the security tone for the whole company and informs employees what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of this requirement, "employees" refers to full-time and part-time employees, temporary employees and personnel, and contractors and consultants who are "resident" on the company's site.

PCI DSS Requirements	Testing Procedures	In Place	Not in Place	Target Date/ Comments
12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following:	12.1 Examine the information security policy and verify that the policy is published and disseminated to all relevant system users (including vendors, contractors, and business partners).	N/A - Security Policy Note: Verizon Business has assisted numerous merchants and service providers to create new and augment existing policies and procedures to meet PCI requirements.		Responsibility of merchant / service provider
12.1.1 Addresses all PCI DSS requirements.	12.1.1 Verify that the policy addresses all PCI DSS requirements.	N/A - Security Policy		Responsibility of merchant / service provider
12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.	12.1.2 Verify that the information security policy includes an annual risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment.	N/A - Security Policy		Responsibility of merchant / service provider
12.1.3 Includes a review at least once a year and updates when the environment changes.	12.1.3 Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.	N/A - Security Policy		Responsibility of merchant / service provider
12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).	12.2.a Examine the daily operational security procedures. Verify that they are consistent with this specification, and include administrative and technical procedures for each of the requirements.	N/A - Security Policy and Procedures		Responsibility of merchant / service provider
12.3 Develop usage policies for critical employee-facing technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants (PDAs), e-mail usage and Internet usage) to define proper use of these technologies for all employees and contractors. Ensure these usage policies require the following:	12.3 Obtain and examine the policy for critical employee-facing technologies and perform the following:
12.3.1 Explicit management approval	12.3.1 Verify that the usage policies require explicit management approval to use the technologies.	N/A - Acceptable Use Policy		Responsibility of merchant / service provider
12.3.2 Authentication for use of the technology	12.3.2 Verify that the usage policies require that all technology use be authenticated with user ID and password or other authentication item (for example, token).	N/A - Acceptable Use Policy		Responsibility of merchant / service provider
12.3.3 A list of all such devices and personnel with access	12.3.3 Verify that the usage policies require a list of all devices and personnel authorized to use the devices.	N/A - Acceptable Use Policy / Asset List		Responsibility of merchant / service provider
12.3.4 Labeling of devices with owner, contact information, and purpose	12.3.4 Verify that the usage policies require labeling of devices with owner, contact information, and purpose.	N/A - Acceptable Use Policy / Asset List		Responsibility of merchant / service provider
12.3.5 Acceptable uses of the technology	12.3.5 Verify that the usage policies require acceptable uses for the technology.	N/A - Acceptable Use Policy		Responsibility of merchant / service provider
12.3.6 Acceptable network locations for the technologies	12.3.6 Verify that the usage policies require acceptable network locations for the technology.	N/A - Acceptable Use Policy		Responsibility of merchant / service provider
12.3.7 List of company-approved products	12.3.7 Verify that the usage policies require a list of company-approved products.	N/A - Acceptable Use Policy		Responsibility of merchant / service provider
12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity	12.3.8 Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.	N/A - Acceptable Use / Remote Access Policy		Responsibility of merchant / service provider
12.3.9 Activation of remote-access technologies for vendors only when needed by vendors, with immediate deactivation after use	12.3.9 Verify that the usage policies require activation of remote-access technologies used by vendors only when needed by vendors, with immediate deactivation after use.	N/A - Acceptable Use / Remote Access Policy		Responsibility of merchant / service provider
12.3.10 When accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media.	12.3.10 Verify that the usage policies prohibit copying, moving, or storing of cardholder data onto local hard drives, and removable electronic media when accessing such data via remote-access technologies.	N/A - Acceptable Use / Remote Access Policy		Responsibility of merchant / service provider
12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all employees and contractors.	12.4 Verify that information security policies clearly define information security responsibilities for both employees and contractors.	N/A - Security Policy		Responsibility of merchant / service provider
12.5 Assign to an individual or team the following information security management responsibilities:	12.5 Verify the formal assignment of information security to a Chief Security Officer or other security-knowledgeable member of management. Obtain and examine information security policies and procedures to verify that the following information security responsibilities are specifically and formally assigned:	N/A - Security Policy		Responsibility of merchant / service provider
12.5.1 Establish, document, and distribute security policies and procedures.	12.5.1 Verify that responsibility for creating and distributing security policies and procedures is formally assigned.	N/A - Security Policy		Responsibility of merchant / service provider
12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel.	12.5.2 Verify that responsibility for monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel is formally assigned.	N/A - Security Policy (Risk / Vulnerability management)		Responsibility of merchant / service provider
12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.	12.5.3 Verify that responsibility for creating and distributing security incident response and escalation procedures is formally assigned.	N/A - Security Policy (Incident Response)		Responsibility of merchant / service provider
12.5.4 Administer user accounts, including additions, deletions, and modifications	12.5.4 Verify that responsibility for administering user account and authentication management is formally assigned.	N/A - Security Policy (ID / Account management)		Responsibility of merchant / service provider
12.5.5 Monitor and control all access to data.	12.5.5 Verify that responsibility for monitoring and controlling all access to data is formally assigned.	N/A - Security Policy (Data Control / Monitoring)		Responsibility of merchant / service provider
12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.	12.6.a Verify the existence of a formal security awareness program for all employees.	N/A - Security Policy (Security Awareness)		Responsibility of merchant / service provider
	12.6.b Obtain and examine security awareness program procedures and documentation and perform the following:
12.6.1 Educate employees upon hire and at least annually.	12.6.1.a Verify that the security awareness program provides multiple methods of communicating awareness and educating employees (for example, posters, letters, memos, web based training, meetings, and promotions).	N/A - Security Policy (Security Awareness)		Responsibility of merchant / service provider
	12.6.1.b Verify that employees attend awareness training upon hire and at least annually.	N/A - Security Policy (Security Awareness)		Responsibility of merchant / service provider
12.6.2 Require employees to acknowledge at least annually that they have read and understood the company's security policy and procedures.	12.6.2 Verify that the security awareness program requires employees to acknowledge (for example, in writing or electronically) at least annually that they have read and understand the company's information security policy.	N/A - Security Policy (Security Awareness)		Responsibility of merchant / service provider
12.7 Screen potential employees (see definition of "employee" at 9.2 above) prior to hire to minimize the risk of attacks from internal sources. For those employees such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.	12.7 Inquire with Human Resource department management and verify that background checks are conducted (within the constraints of local laws) on employees prior to hire who will have access to cardholder data or the cardholder data environment. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)	N/A - Security Policy (Background Checks)		Responsibility of merchant / service provider
12.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers, to include the following:	12.8 If the entity being assessed shares cardholder data with service providers (for example, back-up tape storage facilities, managed service providers such as Web hosting companies or security service providers, or those that receive data for fraud modeling purposes), through observation, review of policies and procedures, and review of supporting documentation, perform the following:
12.8.1 Maintain a list of service providers.	12.8.1 Verify that a list of service providers is maintained.	N/A - Connected Entity List (List of Service Providers with whom cardholder data is shared)		Responsibility of merchant / service provider
12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.	12.8.2 Verify that the written agreement includes an acknowledgement by the service providers of their responsibility for securing cardholder data.	N/A - Third party contracts		Responsibility of merchant / service provider
12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.	12.8.3 Verify that policies and procedures are documented and were followed including proper due diligence prior to engaging any service provider.	N/A - Policies and Procedures for sharing cardholder data with third parties / Service Providers		Responsibility of merchant / service provider
12.8.4 Maintain a program to monitor service providers' PCI DSS compliance status.	12.8.4 Verify that the entity assessed maintains a program to monitor its service providers' PCI DSS compliance status.	N/A - Policies and Procedures for sharing cardholder data with third parties / Service Providers		Responsibility of merchant / service provider
12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.	12.9 Obtain and examine the Incident Response Plan and related procedures and perform the following:
12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: •Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum •Specific incident response procedures •Business recovery and continuity procedures •Data back-up processes •Analysis of legal requirements for reporting compromises •Coverage and responses of all critical system components •Reference or inclusion of incident response procedures from the payment brands	12.9.1 Verify that the Incident Response Plan includes: •Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum •Specific incident response procedures, •Business recovery and continuity procedures, •Data back-up processes •Analysis of legal requirements for reporting compromises (for example, California Bill 1386 which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database) •Coverage and responses for all critical system components •Reference or inclusion of incident response procedures from the payment brands	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider
12.9.2 Test the plan at least annually.	12.9.2 Verify that the plan is tested at least annually.	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider
12.9.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.	12.9.3 Verify through observation and review of policies, that there is 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes.	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider
12.9.4 Provide appropriate training to staff with security breach response responsibilities.	12.9.4 Verify through observation and review of policies that staff with security breach responsibilities are periodically trained.	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider
12.9.5 Include alerts from intrusion-detection, intrusion-prevention, and file-integrity monitoring systems.	12.9.5 Verify through observation and review of processes that monitoring and responding to alerts from security systems including detection of unauthorized wireless access points are covered in the Incident Response Plan.	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider
12.9.6 Develop process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.	12.9.6 Verify through observation and review of policies that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.	N/A - Incident Response policy and procedures		Responsibility of merchant / service provider