No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Capability Assessment

Each component requires specific capabilities to be deployable in a compliant environment. Customers and vendors alike have complained that it is difficult to understand what capabilities are required when developing or purchasing equipment for the purpose of compliance. Therefore, Cisco has developed a simplified approach to clarify the scales that are relevant. Sub-requirements have been grouped for ease of assessment, as shown in Table 5-2.

Table 5-2 Capability Assessment Example

The PCI DSS 2.0 security standard is written from the perspective of helping an organization become compliant. It is not grouped in a clear manner for the evaluation of hardware or software. The following grouping of sub-requirements is an extrapolation of the standard to simplify the assessment of hardware and software:

•Secure services comprises sub-requirements that affect the secure administration and hardening of the component, and include the following:

–Disable any unnecessary services—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system; Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. (Sub-requirements 2.2.2, 2.2.4)

–Vendor supported—Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. (Sub-requirement 6.1)

•Authentication comprises sub-requirements that affect the identity of personnel accessing systems in the cardholder data environment, including the following:

–Role-based access—Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following. 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. (Sub-requirement 7.1, 7.2)

The component has the capability to use other components to satisfy the requirement.

The component requires compensating controls to satisfy the requirement.

The component has no capability to satisfy the requirement.

Design Considerations

This section provides compliance principles as well as best practices for each technology deployed within an enterprise environment.

PCI Assessment Detail

This section includes the following:

•PCI sub-requirements satisfied by solution component—Lists which PCI sub-requirements were successfully audited and validated by the respective technology. Each sub-requirement includes a configuration example or reference of how the sub-requirement was met. This result is directly correlated to the implementation built in the Cisco lab and presented in Chapter 4, "Implementing and Configuring the Solution."

•PCI sub-requirements that failed—Lists which PCI sub-requirements could not be satisfied.

Endpoints

The endpoints layer of the solution framework addresses the components such as voice, e-mail, and physical security.

Voice

Cisco Unified Communications Manager and IP Phones

The Cisco Unified Communication Manager is a suite of voice applications, signaling control, and utilities that provide IP communications capabilities using devices such as the IP phones. It is configured as an appliance that is easy to deploy, flexible to manage, and allows robust security.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

The Cisco Unified Communication Manager appliance operating system includes only the components needed to run the application. Root access to the OS is disabled and this prevents any unwanted services from being implemented. Telnet and HTTP access to the server administration is disabled. The communication between phones and server over HTTP can be secured using SSL. (See Figure 5-1.)

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team (PSIRT) site tracks and publishes information about any relevant exposures and vulnerabilities in the Cisco Unified Communication Manager appliance. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise through a web browser or CLI.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using the Cisco Unified Communication Manager's internal database. Cisco Unified Communication Manager also supports linking to a centralized user database such as Active Directory using LDAP. Within Cisco Unified Communication Manager, individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

The Cisco Unified Communication Manager uses various role definitions for permitting access to various application components on the server. (See Figure 5-2.)

Figure 5-2 Find and List Roles

•PCI 7.2.1—Coverage of all system components

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

The role configuration menu in the Cisco Unified Communication Manager server allows specifying the assignment of privileges based on the role description. No systems access is permitted without an account. (See Figure 5-3.)

Figure 5-3 Role Configuration

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution through configuration of local accounts in the database, as shown below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

Sub-requirements 8.1, 8.2, and 8.4 are met by configuring user IDs and passwords in the User Management section of the Cisco Unified Communication manager web interface, as shown in Figure 5-4.

The system provides trivial credential checks to disallow credentials that are easily hacked. You enable trivial credential checks by checking the Check for Trivial Passwords check box in the Credential Policy Configuration window.

Passwords can contain any alphanumeric ASCII character and all ASCII special characters. A non-trivial password meets the following criteria:

–Must contain three of the four allowable characteristics: uppercase character, lowercase character, number, and symbol.

–Must not use a character or number more than three times consecutively.

–Must not repeat or include the alias, username, or extension.

–Cannot consist of consecutive characters or numbers (for example, passwords such as 654321 or ABCDEFG)

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Sub-requirement 8.5.15 is part of the default system behavior. The system locks the user's session if the session has been idle for fifteen minutes, requiring the user to login again.

This requirement is met by disabling the PC port setting in the phone configuration window for ports that are not in use, as shown in Figure 5-6.

Figure 5-6 Phone Configuration

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

The Cisco Unified Communications Manager is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco Unified Communication manager uses Network Time Protocol (NTP) to update and synchronize local clock facilities to meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. This requirement is met by configuring the NTP server, as shown in Figure 5-7.

Figure 5-7 NTP Server List

To meet all of the requirements listed below, the PCI solution uses a central logging repository located in the data center. RSA enVision collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

The Cisco Unified Communication Manager can be configured to send the logs to an external syslog server where it cannot be altered by the appliance users. Figure 5-8 and Figure 5-9 show the configurations necessary for log forwarding.

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Physical Security

Cisco Physical Security solutions provide broad capabilities in video surveillance, IP cameras, electronic access control, and groundbreaking technology that converges voice, data, and physical security in one modular platform. Cisco Physical Security solutions enable customers to use the IP network as an open platform to build more collaborative and integrated physical security systems while preserving their existing investments in analog-based technology. As customers converge physical security infrastructures and operations and begin using the IP network as the platform, they can gain significant value through rapid access to relevant information and interoperability between systems. This creates a higher level of situational awareness and allows intelligent decisions to be made more quickly.

Cisco Video Surveillance

Video surveillance technology provides security monitoring capabilities within a branch and data center environment. Video surveillance for loss prevention can now be extended into the area of protecting the cardholder data environment.

As the core component of Cisco's video surveillance software portfolio, the Cisco Video Surveillance Media Server offers the power and flexibility to meet a diverse range of video surveillance requirements. The media server:

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

The Cisco Video Surveillance Manager includes only the required services, ports, applications, and access required for standard operation of the system. Use the Cisco Video Surveillance Operations Manager Secure Login feature, found within the Administrative Settings, to enable and force secure HTTPS application login.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

The Cisco Video Surveillance Manager uses SSL for web-based administration and operator access, and uses SSH for remote terminal access. Use the Cisco Video Surveillance Operations Manager Secure Login feature, found within the Administrative Settings, to enable and force secure HTTPS application login. SSH access should be used to securely login to the VSM host.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team (PSIRT) site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco Video Surveillance Operations Manager. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of requirement 7 were met using VSOM's Role-based Access Control (RBAC) system to logically group each user within a role based on their need to know. This restricts unauthorized access and usage of system components. The VSOM RBAC allows granular access control for each system component, including devices such as servers, cameras, and encoders, along with application-level functionality of accessing these resources.

This configuration was used to address the following individual requirements.

•PCI 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:

•PCI 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:

–PCI 7.2.1—Coverage of all system components

–PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

–PCI 7.2.3—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.

The role configuration menu in Video Surveillance Operations Manager server allows specifying the assignment of privileges based on the role description. No systems access is permitted without an account.

Individual users and roles are created locally and authentication directed to LDAP, as shown in Figure 5-10.

Figure 5-10 VSOM Users Authenticate to LDAP Service

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution by implementing LDAP connectivity for AAA services and Microsoft Active Directory for user account services. Configure AAA services via LDAP, as shown below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

•PCI 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.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Using the Video Surveillance Management Console, configure LDAP as specified in the installation guide. Figure 5-11 shows the LDAP configuration implemented for validation.

Figure 5-11 VSOM LDAP Configuration

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Cisco VSOM has a minimum session timeout of 30 minutes in the configuration for the version validated. Administration time limits would need to be enabled systemically through an active directory policy to the admin workstation desktops, locking them when there is no activity after 15 minutes.

•PCI 9.1.1—Use video cameras and/or 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 branch.

Physical access to sensitive areas and cardholder data is restricted by solutions in video surveillance management and IP cameras by securing data center facilities and cashier areas within branches. This includes video recording options for flexible configuration of video recording archives and low-latency, high-quality, event-tagged video. Also available is the following:

–A web-based interface for configuration, management, display, and control of video from a wide variety of surveillance and monitoring endpoints

–Management of a large number of video surveillance media servers, video walls, cameras, and users

–Comprehensive control of users and user roles including scheduling of operator shifts, event filters, and user-specific video views

–Detailed activity reports and system audit

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco VSOM is able to track and monitor all administrative user access and events.

Cisco VSOM uses the local clock facilities of the host server on which it is installed to meet the following requirements:

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

•PCI 10.4—Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. Note: One example of time synchronization technology is Network Time Protocol (NTP).

–PCI 10.4.2—Time data is protected.

–PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. Network Time Protocol (NTP) is supported and must be enabled within both the IP cameras and Video Surveillance Manager.

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects information from all devices to ensure the integrity and correlation of events.

Requirement 10.5 was met using the integrated Log Backup functionality to send the logging data to the RSA enVision server.

•PCI 10.5—Secure audit trails so they cannot be altered.

–PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

–PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

–PCI 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).

The following configuration script was implemented to send the local log files to the RSA enVision server to be secured and the integrity established:

Cisco Physical Access Control

•Secure access to the server by supporting secure protocols such as HTTPS and also securing the accounts using strong passwords

•Role-based access to the system by making use of profiles that can restrict access to the modules, depending on the roles

•Automated backup of events to a centralized server

•Ability to archive audit reports on a centralized server

Cisco Physical Access Control is a comprehensive IP-based solution that uses the IP network as a platform for integrated security operations (see Figure 5-12). It works with existing card readers, locks, and biometric devices and is integrated with Cisco Video Surveillance Manager (VSM) and with Cisco IP Interoperability and Collaboration System (IPICS).

Figure 5-12 Scalable, Modular Architecture

Cisco Physical Access Control has two components:

•The hardware component, Cisco Physical Access Gateway, provides a modular and scalable platform to connect readers, inputs, and outputs to the system. The gateway scales from a single door to thousands of doors at a fixed cost per door.

No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Primary PCI Function

The primary function of the CPAM appliance is to configure, manage, monitor, and report on the physical doors and door hardware, protecting sensitive areas within the cardholder data environment (9.1).

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

The Cisco PAM appliance can be configured to disable unsecure protocols. To disable unsecure protocols, you must edit one of the configuration files on the Cisco PAM appliance. The step-by-step instructions are as follows:

–SSH into the Cisco PAM server

–sudo su

–Enter the cpamadmin password

–/etc/init.d/cpamadmin stop

–Comment out a configuration from the file /opt/cisco/cpam/apache-tomcat/conf/server.xml.

Remove or comment the snippet below.

<Connector executor="tomcatThreadPool"

port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443" />

/etc/init.d/cpamadmin start

When you try to launch the web UI using HTTP, you see "Page cannot be displayed".

The Cisco PAM appliance operating system includes only the components needed to run the application.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

On the Cisco PAM appliance, SSL is enabled by default. All the communication between the Cisco PAM client and the gateway is encrypted using the 128-bit AES encryption. Console access to Cisco PAM is through SSH.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco PAM. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

To meet all of the requirements listed below, the PCI solution uses a centralized user database in the Active Directory, which is linked via LDAP, RADIUS, and TACACS+ services. This server is located in the data center. Individual user IDs are assigned, and roles are based on group membership. Cisco Physical Access Manager connects to this resource via LDAP to address the following individual requirements:

•PCI 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:

Role-based access can be configured on Cisco PAM by making use of profiles. Profiles are pre-defined sets of access privileges that define the Cisco PAM modules and commands available to a user. For example, users that should have all privileges can be assigned to the Administrators profile.

Step 7 Click the Device Commands tab to define the hardware configuration commands available to the user (see Figure 5-18).

Figure 5-18 Profile—Device Commands Tab

a. Expand or collapse the list of commands for a device.

b. Highlight a command.

c. Select the following options:

•Allow command to be issued:

–Default—If user has access to issue device commands, the command access is enabled by default.

–No—Denies access to the command.

–Yes—Allows access to the command.

•Filter—Apply a filter to limit the devices for the command.

Step 8 Click the Data Types tab to define the data available to the profile, as shown in Figure 5-19.

Figure 5-19 Profile—Data Types Tab

a. Select a module and the type of data in the list.

b. To restrict the data, click the check boxes for the properties listed in Table 5-11.

Table 5-11 Profile—Data Types

Field

Description

View

Allows the user to view the selected data type.

Create

Allows the user to add and create the selected data types.

Modify

Allows the user to modify existing data.

Delete

Allows the user to delete data.

Default Filter...

Allows the user to apply a default filter to limit objects from view.

Step 9 Click Save and Close to save the profile settings.

Step 10 Assign the profile to one or more Cisco PAM operators using the Loginsmodule. (See the following section).

Creating User Login Accounts and Assigning Profiles

To give users access to Cisco PAM functionality, create a login account and assign one or more access profiles to the username.

Step 1 Select Logins from the Users menu. The main window (Figure 5-20) lists all the usernames in the system.

Figure 5-20 Logins Module Main Window

Step 2 To add a login, choose Add.

•To modify an existing login, select the entry and choose Edit.

•To remove a login, select the entry and choose Delete.

Note Most properties of the cpamadmin login are read-only.

Step 3 Complete fields in the General tab, as shown in Figure 5-21. Table 5-12 describes the field properties.

Figure 5-21 Logins Module—General Tab

Note The Username, Password, and Confirm password fields are required.

Table 5-12 General Tab Fields

Field

Description

Username

Required—The username of the login.

Password

Required—Password to access the system.

Confirm password

Required—The value must be entered exactly as it was in the Password field.

Assigned to

The personnel record the login is assigned to.

If the login is for an operator already entered in the Personnel module, click the
Select... button. For more information on adding personnel to the system, see Chapter 8, "Configuring Personnel and Badges" of the CPAM User guide.

Validity

Active or Inactive—Only active accounts can access the system.

Effective

The beginning date the user can log in—If left blank, the user can log in immediately.

Expires

The day the login expires and access is denied—If left blank, access is allowed indefinitely.

Step 5 To verify the changes, log off and then log in with the new username and password. Verify that you can access the modules and functions specified by the assigned profiles.

•PCI 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:

–PCI 7.2.1—Coverage of all system components

–PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

–PCI 7.2.3—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.

Cisco PAM has a default policy of "Deny-all". If a specific badge has to get access to certain set of doors, an access policy must be created.

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance with the sub-requirements in this section was achieved within the solution by implementing LDAP connectivity for AAA services and Microsoft Active Directory for user account services. Configure AAA services via LDAP, as shown in Requirement 8.2.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco PAM integrates with Microsoft Active Directory (MS AD) to pull user information into CPAM. MS AD supports creation of unique ID for users. Cisco PAM has an option to generate a unique number for users using the Personnel ID Number Generator. It is disabled by default. Following are the instructions to enable and use this feature.

Step 1 On the Cisco PAM client application, open the System Configuration module by clicking Admin -> System Configuration.

•PCI 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.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Cisco PAM has a hard-coded session timeout of 30 minutes in the configuration for the version validated. Administration time limits would need to be enabled systemically through an active directory policy to the admin workstation desktops, locking them when there is no activity after 15 minutes.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco PAM is able to track and monitor all administrative user access and events to meet the following requirements:

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco PAM and the gateways use the local clock facilities to meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. All the events in the Access Control system have a time stamp associated to them. Cisco PAM and the gateway are configured to use NTP, as shown in Figure 5-28.

Figure 5-28 Cisco PAM NTP Configuration

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects logging information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

Cisco PAM allows for the creation of global I/O rules to trigger sending audit reports to a centralized server. Following are the instructions to create a global I/O with audit reports.

Cisco IronPort Email Security Solution

Note The Cisco IronPort Email Security Solution was initially reviewed by Verizon Business and determined to be outside the scope of the PCI Audit. There is no Assessment Summary or Capability Assessment details for this product. However, Cisco IronPort Email Security Solution could potentially store or transmit sensitive cardholder data if used with the default settings for message tracking. Sensitive information in messages would be automatically forwarded in clear text to administrators, and recipients. These same messages would also be stored un-encrypted. The design considerations below detail how to properly configure the Cisco IronPort Email Security Solution to avoid this pitfall.

Cisco IronPort Email Security Solution provides sophisticated and scalable mechanisms that help to minimize the downtime associated with e-mail-borne malware and simplify the administration of corporate e-mail systems, while offering insight into the e-mail system operation. Capabilities include the following:

•Spam protection

•Data loss prevention (DLP)

•Virus defense

•E-mail encryption tracking and reporting tools

Primary PCI Function

Although data loss prevention is not covered by a specific PCI requirement, Cisco IronPort Email Security Solution helps in achieving PCI compliance by preventing the transmission of cardholder data over open public networks via e-mail.

Design Considerations

•For IronPort to analyze messages passing through it, message tracking must be enabled, as shown in Figure 5-37.

Figure 5-37 Enable IronPort Message Tracking

•Create policy in IronPort to drop messages containing credit card numbers, but not to forward that message to administrators. Ensure that the "include original message" checkbox is not selected, as shown in Figure 5-38.

Figure 5-38 Policy in IronPort Excluding Original Message

•To ensure that messages identified as containing credit card information are not stored in the local system, you must disable logging of matched content, as shown in Figure 5-39. The local log of the IronPort server is not a safe encrypted place to store cardholder data.

Figure 5-39 IronPort DLP—Matched Content Logging Disabled

Hosts

Cisco Unified Computing System

The Cisco Unified Computing System (UCS) is used to securely deploy sensitive and compliance-related applications. Provisioning options, including virtualization technology, allow the mixing of sensitive and non-sensitive applications without compromising scope boundaries.

Improve IT responsiveness to rapidly changing business demands with this next-generation data center platform. Cisco UCS accelerates the delivery of new services simply, reliably, and securely through end-to-end provisioning and migration support.

Benefits include the following:

•Streamlines data center resources to reduce total cost of ownership

•Scales service delivery to increase business agility

•Radically reduces the number of devices requiring setup, management, power, cooling, and cabling

No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Primary PCI Function

The main function of Cisco UCS is to securely host one primary compliance-related function per physical or virtual server.

It provides segmentation of sensitive applications from out-of-scope applications via physical and virtualization technology. Although technically, a firewall or ACL is used to enforce PCI Requirement 1, Cisco UCS extends Layer 3 boundaries to virtual network and storage adapters within the chassis. Using VLANs and VSANs, Cisco UCS allows an organization to separate its payment systems (in-scope) from other non-sensitive data (out-of-scope).

Design Considerations

•Cisco UCS allows for the provisioning of individual servers on blades. Each blade can host a native operating system such as Windows 2008 server, or a virtualization hypervisor system such as VMware ESX/ESXi. These provisioning options represent a primary function for the server blade. In the lab validation, VMware ESX was installed on each of the Cisco UCS blades, and several VM hosts were then configured, each with one primary function. Each server blade is provisioned via a profile. Profiles can be created locally in Cisco UCS Manager or centrally using the Vblock provisioning utility, Unified Infrastructure Manager (UIM), which provides simplified Vblock management by combining provisioning with configuration, change, and compliance management.

•EMC SAN is a primary component of the VCE architecture for Vblock Infrastructure Platforms. Vblock 1 is designed for medium to high numbers of virtual machines, and is ideally suited to a broad range of usage scenarios, including shared services, e-mail, file and print, virtual desktops, and collaboration.

•Cisco UCS allows for the provisioning of individual servers on blades. Each blade can host a native operating system such as Windows 2008 server, or a virtualization hypervisor system such as VMware ESX/ESXi.

•The PCI standard requires one primary function per server. When using virtualization technology, the single primary server function is extended to individual virtual machines.

•The hypervisor of an individual blade is considered insecure for segmenting scopes of compliance. Therefore, when putting non-sensitive VM servers with sensitive VM servers on the same physical blade, the non-sensitive would be included in the scope of the audit.

•The UCS system securely segments network and storage to each blade, which allows mixing of sensitive and non-sensitive applications across different physical blades of the chassis.

•PCI requires a 15-minute timeout for administrative functions. Cisco UCS does not feature an explicit session timeout. Administration time limits would need to be enabled systemically through active directory policy to the admin workstation desktops, locking them when there is no activity.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Cisco UCS allows for the disabling of non-secure administrative interfaces. Figure 5-40 shows the secure management protocols of SSH and HTTPS for administration. Telnet, HTTP, and other unused protocols are disabled.

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco UCS. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory). It is accessed by Cisco Secure ACS TACACS+ services. Individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

Add the Cisco Secure ACS server under the TACACS+ protocol option, as shown in Figure 5-42.

Figure 5-42 Adding the Cisco Secure ACS Server

Select tacacs from the Console and Default dropdown menus on the Authorization page, as shown in Figure 5-43.

Figure 5-43 Authorization—Selecting Console and Default Settings

On the TACACS+ server, create custom attributes defining the desired role for the user or group accessing the Cisco UCS Manager (see Figure 5-44):

–TACACS+ custom attributes for UCS Manager:

cisco-av-pair*shell:roles="admin aaa"

–If combined with other systems roles, such as for the Nexus;

cisco-av-pair*shell:roles="network-admin admin aaa"

Figure 5-44 Group Configuration Page on TACACS+ Server

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution by implementing the Cisco Secure ACS for AAA services and Microsoft Active Directory for user account services. Configure AAA services as shown above in Requirement 7.

The Cisco UCS is able to meet some of the requirements locally as identified below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco UCS supports the creation of local user accounts with unique IDs through the use of the Create User option when you alt-click on Locally Authenticated Users (see Figure 5-45). These can be used for local fallback user accounts.

Figure 5-45 Create User

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

Local user accounts on Cisco UCS require setting of a password for admin role accounts.

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

Local passwords are stored encrypted on the Cisco UCS system and are not displayed.

Cisco UCS servers allow for an administrator to specify an expiration date for the local user accounts passwords, effectively disabling their accounts after a specified period of time.

•PCI 8.5.9—Change user passwords at least every 90 days.

Cisco UCS does not support an automated capability to perform this function at this time; user passwords management would have to be manually performed every 90 days per a company policy if a centralized authentication service with this capability could not be used.

Cisco UCS servers require at least three of the following character types for passwords:

–Lower case letters

–Upper case letters

–Digits

–Special characters

•PCI 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.

Cisco UCS does not support an automated capability to perform this function at this time; user account management would have to follow this policy manually if a centralized authentication service with this capability could not be used.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

Cisco UCS does not support the ability to lock out local accounts after failed login attempts. This would have to be met through a compensating control and corporate policy if a centralized authentication service with this capability could not be used.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Cisco UCS does not support the ability to lock out local accounts after failed login attempts. This would have to be met through a compensating control and corporate policy if a centralized authentication service with this capability could not be used.

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Cisco UCS does not feature an explicit session timeout. Administration time limits would need to be enabled systemically through an Active Directory policy to the admin workstation desktops, locking them when there is no activity after 15 minutes.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco UCS is able to track and monitor all administrative user access, events such as profile creation, interface up/down, and device authentications.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco UCS is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco UCS uses NTP to update and synchronize their local clock facilities and meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices (see Figure 5-46). This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

Cisco UCS is capable of sending system events to a centralized repository using the syslog function and/or SNMP traps. In the solution, only syslog was used. (See Figure 5-47.)

Cisco UCS E-series is a converged networking, computing, and virtualization platform for hosting essential business applications in the branch location. The SRE modules are router blades for the second generation of Cisco Integrated Services Routers (ISR G2) that provide the capability to host Cisco, third-party, and custom applications. A service-ready deployment model enables branch applications to be provisioned remotely on the modules at any time. Cisco SRE modules have their own processors, storage, network interfaces, and memory, which operate independently of the host router resources and help ensure maximum concurrent routing and application performance.

Primary PCI Function

The main function of the Cisco UCS Express is to securely host one primary compliance-related function per physical or virtual server.

It provides segmentation of sensitive applications from out-of-scope applications via physical and virtualization technology. Although technically, a firewall or ACL is used to enforce PCI Requirement 1, UCS extends Layer 3 boundaries to virtual NIC and storage adapters within the chassis. Using VLANs and VSANs, Cisco UCS allows an organization to separate its payment systems (in-scope) from other non-sensitive data (out-of-scope).

Design Considerations

The major consideration when using Cisco UCS Expresss with sensitive applications is the security of the hypervisor. PCI considers all hypervisors to be insecure. Therefore, use separate Cisco UCS Express implementations when scooping. Although it is acceptable to mix non-sensitive applications onto a Cisco UCS Express deployment with sensitive applications, that brings those applications into scope and audit. (See Figure 5-48.)

Figure 5-48 Using UCS Express with Cisco SRE

•The audited version 1.5 of UCS Express has several limitations with local user accounts. There is no capability to use central authentication or management. This resulted in a need for compensating controls that are detailed below.

Note Newer versions of UCS Express (version 1.5 +) enable central management of the VMware ESXi on Cisco UCS Express through vCenter (upgrade license required) as well as eliminate the Cisco console VM and local user management/VMware ESXi management restrictions. With the new release, Cisco UCS can manage users on VMware ESXi exactly as it would on a standalone VMware ESXi 4.1 server.

Note The Cisco UCS Express module comes installed with VMware ESXi. This is the primary function for the server module. Each module can host several independent operating systems as virtual servers. Each virtual server should have only one primary function.

•Cisco UCS Express requires the use of VLANs in the router. Depending on the deployment within the branch, this may require the use of bridged virtual interfaces.

•Cisco UCS Express is based on VMware's ESXi and uses vSphere client for management.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Cisco UCS Express and the underlying VMware ESXi have no unnecessary services enabled by default.

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco UCS Express. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using the vCenter database for administrator users. Individual administrative user IDs are created and assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

•PCI 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.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco UCS Express is able to track and monitor all administrative user access, events such as profile creation, interface up/down, and device authentications.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco UCS Express uses the local clock facilities to meet the following requirements:

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers, as shown in Figure 5-49.

Figure 5-49 UCS E-Series NTP Servers

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

PCI Assessment Detail—PCI Sub-Requirements with Compensating Controls

No sub-requirements were failed.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Administration

Authentication

Cisco Secure Access Control Server

Cisco Secure Access Control Server (ACS) was used as a central authentication system for the majority of products validated in this solution. It links user authentication to Windows Active Directory using group mapping that segments users based on their role and function.

Cisco Secure ACS is an access policy control platform that helps you comply with growing regulatory and corporate requirements. By using a single authentication method for all system devices, insight into who made changes is simplified for internal administration, assessors, and post-breach audits. It supports multiple scenarios simultaneously, including the following:

•Network admission control—Communicates with posture and audit servers to enforce admission control policies

Cisco Secure ACS lets you centrally manage access to network resources for a growing variety of access types, devices, and user groups. These key features address the current complexities of network access control:

•Support for a range of protocols including Extensible Authentication Protocol (EAP) and non-EAP protocols provides the flexibility to meet all your authentication requirements

•Integration with Cisco products for device administration access control allows for centralized control and auditing of administrative actions

•Support for external databases, posture brokers, and audit servers centralizes access policy control and lets you integrate identity and access control systems

Design Considerations

•Cisco Secure ACS has been configured to authenticate individual users using Active Directory (AD). This is accomplished by creating user groups in AD and mapping them to role-based groups in Cisco Secure ACS. This provides the granularity of secure authentication needed to address the PCI specification.

•The solution used the windows versions of Cisco Secure ACS. The CSA client was installed to protect and alert on unauthorized access of the log and audit trail.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

If Cisco Secure ACS is deployed on a server, it should be installed on a hardened operating system. Hardening guidance can be found at the National Checklist Program Repository: http://web.nvd.nist.gov/view/ncp/repository

If Cisco Secure ACS is deployed as an appliance, no unnecessary services are enabled by default.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

If Cisco Secure ACS is deployed as an appliance, no unnecessary services are enabled by default.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

The management console was configured to support HTTPS access, with HTTP access disabled. Cisco Secure ACS is configured to use SSL as a highly secure management portal technology (see Figure 5-50). Cisco Secure ACS employs port hopping to a random high port for secured communication transport.

Figure 5-50 HTTP Configuration

Note Server hardening, including appropriate security settings for all system components, is the responsibility of the organization/service provider.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco Secure ACS. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using the Cisco Secure ACS internal database for administrator users. Within Cisco Secure ACS, individual administrative user IDs were created and assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

Through company policy inactive users should be removed or disabled every 90 days. As shown in Figure 5-51, Cisco Secure ACS password policy also enables setting of an inactivity option where an administrator will be locked out after 90 days of inactivity.

•PCI 8.5.9—Change user passwords at least every 90 days.

The password lifetime option must be enabled configured to require users to change their password every 90 days. This setting can be configured as shown in Figure 5-51.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco Secure ACS is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco Secure ACS uses the local clock facilities of the host server on which it is installed to meet the following requirements:

•PCI 10.4—Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. Note: One example of time synchronization technology is Network Time Protocol (NTP).

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

Time synchronization for Windows servers is specified through the domain policy. Servers synchronize their clocks with the domain controller, which in turn is synchronized using NTP. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers.

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

Cisco Secure ACS can be configured to send its log data to the RSA enVision log management platform to meet the above requirements. The configuration procedure is documented in the RSA enVision Event Source Configuration Guide for Cisco Secure ACS, which can be found at RSA Secure Care Online (https://knowledge.rsasecurity.com/).

RSA enVision requires that specific attributes for each reporting function to be specified and configured in a particular order. Figure 5-53 shows the required items for generating Syslog Passed Authentications. Settings for other event types are available in the RSA enVision Event Source Configuration Guide for Cisco Secure ACS.

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

RSA Authentication Manager

RSA Authentication Manager is the management component of the RSA SecurID®, a two-factor authentication solution, which provides a much more reliable level of user authentication than reusable passwords. SecurID authentication is based on something you know (a password or PIN) and something you have (an authenticator), and can be used to achieve compliance to PCI requirement 8.3, which requires two-factor authentication for remote access to the network by employees, administrators, and third parties. As the management component, RSA Authentication Manager is used to verify authentication requests and centrally administer authentication policies for enterprise networks.

Design Considerations

RSA Authentication Manager stores and processes highly sensitive authentication information and should be deployed and operated in a secure manner. Detailed recommendations are found in the RSA Authentication Manager Security Best Practices Guide, which can be downloaded from RSA Secure Care Online (https://knowledge.rsasecurity.com/).

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

There are no unnecessary services enabled by default on RSA Authentication Manager. RSA Authentication Manager should be installed on a hardened operating system. Hardening guidance can be found at the National Checklist Program Repository: http://web.nvd.nist.gov/view/ncp/repository

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

RSA Authentication Manager web consoles are protected with SSL.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using the RSA Authentication Manager's internal database. RSA Authentication Manager also supports linking to a centralized user database such as Active Directory using LDAP. Within RSA Authentication Manager, individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

RSA Authentication Manager has powerful access control capabilities to limit access to system components and cardholder data based on user role or group membership. Users and groups are created under the Identity tab of the Security console, as shown in Figure 5-54.

Figure 5-54 Users and Groups

•PCI 7.2.1—Coverage of all system components

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

RSA Authentication Manager's access control system defaults to deny access.

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution through configuration of local accounts in the database as shown below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

RSA Authentication Manager supports the creation of local users or linking to a central repository of users. Through company policy, each user must be assigned a unique ID.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

Local user accounts in RSA Authentication Manager require setting of a password according to the assigned password policy as shown in Figure 5-55.

Figure 5-55 User Password Requirements Based on Policy

Additional authentication tokens can also be assigned to each user, as shown in Figure 5-56.

Figure 5-56 Assigned Tokens

•PCI 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. (For example, remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.) Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

Through company policy, inactive users should be removed or disabled every 90 days. RSA Authentication Manager also enables setting of an account expiration date for individual accounts, as shown in Figure 5-57.

Figure 5-57 User Account Expiration

•PCI 8.5.9—Change user passwords at least every 90 days.

The default Initial Password Policy is created when a new realm is established, and requires users to change their passwords every 90 days.

The default Initial Password Policy must be updated to require both alphabetic and numeric characters, as shown in Figure 5-58.

•PCI 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.

The default Initial Password Policy is created when a new realm is established, and restricts users from re-using their last five passwords.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

The Initial Lockout policy is enabled by default and locks accounts after six consecutive failed authentications within one day.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

The Initial Lockout policy is enabled by default; the only change for PCI compliance is to change the auto-unlock parameter from 15 minutes to 30 minutes. This change is made under the Authentication > Policies > Lockout Policies.

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

RSA Authentication Manager supports session policies under the Access tab. Change the Session Time-out for the Console/Command API to 15 minutes from the default, as shown in Figure 5-60.

Figure 5-60 Session Lifetime for Console

RSA Authentication Manager has very powerful and flexible capabilities to define password and account lockout policies to meet all of the above criteria.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

RSA Authentication Manager is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

RSA Authentication Manager uses the local clock facilities of the host server on which it is installed to meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

Time synchronization for Windows servers is specified through the domain policy. Servers synchronize their clocks with the domain controller, which in turn is synchronized using NTP. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers.

•PCI 10.5—Secure audit trails so they cannot be altered.

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

RSA Authentication Manager can be configured to send its log data to the RSA enVision log management platform to meet the above requirements. The configuration procedure is documented in the enVision Event Source Configuration Guide for RSA Authentication Manager, which can be found at RSA Secure Care Online (https://knowledge.rsasecurity.com/). One step is editing the IMS.Properties file, as shown in Figure 5-61.

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Cisco Identity Services Engine

Cisco Identity Services Engine (ISE), a security component of the Cisco Borderless Network architecture, provides visibility and control into who and what is connected to the network. Cisco ISE allows organizations to embrace the rapidly changing business environment of mobility, virtualization, and collaboration while enforcing compliance, maintaining data integrity and confidentiality, and establishing a consistent global access policy. Cisco ISE allows businesses to gain complete control over the access points into their networks. This includes all wired, wireless, and VPN network entry points.

Cisco ISE ensures that you know what devices and users are on your network, and that those devices and users comply with your security policies via the following components:

•Cisco Identity Services Engine—A next-generation policy manager that delivers authentication, authorization, and accounting (AAA); posture; profiling; and guest management services on a single platform. The Cisco ISE automatically discovers and classifies endpoints, provides the right level of access based on identity, and provides the ability to enforce endpoint compliance by checking a device's posture. The Cisco ISE also provides advanced authorization and enforcement capabilities, including Security Group Access (SGA) through the use of security group tags (SGTs) and security group access control lists (ACLs). Administrators can centrally create and manage access control policies for users and endpoints in a consistent fashion, and gain end-to-end visibility into everything that is connected to the network.

•Cisco ISE Identity on Cisco Networking Infrastructure—Identity-based networking services on the Cisco routing, switching, and wireless infrastructure provides the ability to authenticate users and devices via features such as 802.1x, MAC authentication bypass, and web authentication. In addition, this same infrastructure is what enforces the appropriate access into parts of the network via VLANs, downloadable or named ACLs and security group ACLs.

•Client—Cisco Anyconnect is a software client that enables you to deploy a single 802.1x authentication framework to access wired and wireless networks while the Cisco NAC agent delivers endpoint posture information. The Cisco ISE architecture also supports native O/S supplicants.

The Cisco Identity Services Engine solution offers the following benefits:

•Allows enterprises to authenticate and authorize users and endpoints via wired, wireless, and VPN with consistent policy throughout the enterprise

No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Primary PCI Function

Cisco ISE identity features detect and prevent rogue wireless devices from connecting to in-scope PCI networks (11.1); in addition, Cisco ISE locks down publicly accessible network ports to only authorized devices and users (9.1.2). In addition to its primary focus, Cisco ISE can also help with compliance and enforcement of requirements 6.1, 7.1, 7.2, 8.3, 8.5, and 10.

Design Considerations

For the purposes of this guide, Cisco ISE is configured to authenticate individual users and ISE Admin users using Active Directory (AD). Cisco ISE is also used to profile and assess the posture of individual wired and wireless devices to ensure that they comply with the PCI standard. Cisco ISE relies on TrustSec wired and wireless identity features such as 802.1x, MAB, and web portal authentication on Cisco infrastructure to collect user identity information. It relies on the Cisco ISE NAC agent and the Cisco ISE profiler engine to collect posture and profiling information from devices.

Note the following ISE configuration best practices for PCI compliance:

•The solution tested used the virtual machine appliance version of Cisco ISE running on an ESX platform.

•The default accounts for administration are removed.

•ISE only supports HTTPS and SSH access

•Cisco ISE communicates with the Cisco switches and wireless controllers using RADIUS.

•Cisco ISE can use dynamic VLAN and port or VLAN access control rules to provide PCI segmentation of a network. For example, members of the PCI active directory group are automatically moved to the PCI VLAN when they connect to the network. Cisco ISE can then apply strong access lists to this VLAN or directly to the user switch port to accomplish segmentation.

•Access control rule sets must adhere to a "least amount of access necessary" policy. Rules must be defined by specific source/destination addressing and TCP/UDP ports required for the cardholder data environment on the point-of-sale networks.

•Configure appropriate banner messages on login, incoming, and exec modes of the router. The login banner warning should not reveal the identity of the company that owns or manages the router. The incoming and executive banners should state that these areas are considered private and that unauthorized access will result in prosecution to the full extent of the law.

•The Cisco ISE system is configured to be compliance with all of the access controls, logging controls, and other general system controls required by PCI DSS 2.0.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure. (For example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.)

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

The Cisco Identity Service Engine appliance does not allow changes to the operating system, to the database, installation of unsupported hardware, or of unsupported third-party software.

The Cisco ISE management console supports only HTTPS access.

Cisco ISE is configured to use SSL as a highly secure management portal technology.

Role-based administration is configured for administrative tasks.

Cisco ISE was locked down according to generally accepted industry standards and the above PCI requirements.

Figure 5-63 Admin Access Using Active Directory for Authentication

Requirement 6: Develop and maintain secure systems and applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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, systems, and databases) and higher than less-critical internal devices, ensuring that high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.

Cisco ISE can be upgraded and patched manually.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in the Cisco Identity Service Engine. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

ISE is used for ensuring network-wide compliance with PCI 6.1 for all Windows and Mac OSX systems. Systems are posture-assessed for compliance upon connection to the network. If found not to be compliant, remediation and access restrictions can be put in place on the network.

Cisco ISE is able to check all hosts connecting to the network to make sure they are compliant with requirement 6.1. Cisco ISE has several auto-update configuration options you can use to keep its posture assessment database current. Operating system patches and application patches can be enforced before allowing network access. Cisco ISE can offer remediation options to users who are out of compliance. In addition to OS updates, ISE can also ensure anti-virus software is installed, running and up to date.

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

To meet all of the requirements listed below, the Cisco PCI Solution uses a centralized user database in the Active Directory. This server is located in the data center. Individual user IDs are assigned, and roles are based on group membership. Cisco ISE connects to this resource via native Windows services to address the following individual requirements:

ISE ensures that only privileged users can access the CDE. This is done using the authentication credentials supplied by the wired and wireless infrastructure, along with the AD attributes of a user connecting to the network. Based on a Cisco ISE authorization profile match, that user is put onto the proper VLAN and given a group-specific port access control list to control where they can go on the network. Additionally, a Cisco SmartPort macro can be run on the switchport to ensure they have the proper configuration.

The relevant sub-requirements below were met using the Cisco ISE linked to the windows Active Directory domain. Cisco ISE also supports linking to other authentication servers.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco ISE supports the creation of local user accounts with unique IDs through the use of the username command in the CLI or via the Web GUI. These can be used for local fallback user accounts if connectivity to Active directory is lost.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

When configuring local user accounts, you must specify a password to achieve PCI compliance.

Cisco ISE can use any of the methods indicated above to authenticate RADIUS users. The audited configuration for this guide used passwords stored on an Active directory server.

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography. All local passwords on the Cisco ISE are stored using strong encryption

Cisco ISE can assist with this requirement by ensuring that all network jacks require AAA, posture assessment, and profiling. ISE can then determine the type of access to grant to that switchport based on the results of the above and/or based on the switchport's location. This type of authorization to the network would prohibit a non-authorized endpoint/user from access PCI data through publicly accessible network jacks.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco ISE uses the local clock facilities of the host server on which it is installed to meet the following requirements.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco ISE uses the local clock facilities to meet the following requirements.

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. Cisco ISE uses NTP to meet these requirements by implementing the following configuration statement:

ntp server 192.168.62.161 192.168.62.162

Figure 5-69 Administrator Summary

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

Cisco ISE NAC capabilities can be configured on the store switches to automate the verification of approved devices being attached to the network. In addition to configuring the ISE authentication services in the data center, add the following configurations to all switch and switch interface ports where ISE network access control is required. In most cases, every access switch port in your network should be protected using ISE. However, as a minimum, any switchport that could potentially let a host find its way to the PCI security domain should be protected by Cisco ISE.

Methods that may be used in the process include but are not limited to wireless network scans, physical site inspections, Network Access Control (NAC), or wireless IDS/IPS.

Cisco ISE Identity features were enabled on the wired infrastructure to authenticate users and devices. The Cisco ISE Policy Manager was configured to not allow an unauthorized access point to connect to the wired network. Cisco ISE was configured to alert and mitigate this rogue wireless threat.

Cisco ISE was configured to profile all devices connected to the network. Any access points detected were allowed only if they were in the approved list. All wired ports were set up to authenticate and posture-assess users and devices connecting to the network switches. The device posture assessment included checks for the setup of peer-to-peer wireless network and the setup of a wireless card as an access point on the device. If either of these were true, the device would be denied network access.

No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Primary PCI Function

LMS simplifies compliance by ensuring that all of the devices across the network adhere to the security policy of the company. In addition, it will verify that device configurations; match templates, are synchronized, and includes a customized PCI compliance dashboard to simplify the ongoing management for administrators (1.2.2).

Design Considerations

•Provide proper host system sizing including CPUs, memory, and storage for the selected operating system.

•Restrict access behind a firewall or access list to only those administrative clients that need access.

•Activate the NMC capability license for compliance audits.

Compliance and Audit

The compliance and audit reports provide the compliance status of the network, lifecycle, and contract information about network devices, security advisory, and service reports based on device and software capabilities, and the services that are enabled.

The compliance reports provide information about the compliance state of the network for specific compliance requirements and can be found in LMS by navigating to Reports > Compliance and Audit.

Licensed/Unlicensed Compliance and Audit Reports

The following compliance and audit reports require a regulatory compliance management license:

•HIPAA Compliance Reports

•SOX (COBIT) Compliance Reports

•ISO/IEC 27002 Compliance Reports

•NSA Compliance Reports

•PCI DSS Compliance Reports

•DHS Checklist Reports

•DISA Checklists Report

•CIS Benchmarks

The following compliance and audit reports are supported by the LMS license alone and do not require a regulatory compliance management license:

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Firewall, router, and switch configuration files are backed up centrally using Cisco Prime LMS. LMS automatically verifies that running and startup configurations of firewalls, routers, and switches are synchronized for the devices managed.

The Out-Of-Sync Summary report can be used to view which systems configurations need to be synchronized and provides the ability to select and synchronize the devices. (See Figure 5-72.)

Figure 5-72 Out-of-Sync Summary Report

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, and so on.

The Cisco Prime LMS soft appliance does not have any unnecessary services enabled by default.

Cisco Prime deployed on other server platforms such as Windows or Solaris should first be hardened using industry best practices for those systems before installing the LMS application. Server hardening best practices guidelines can be found at a variety of Internet resources provided by the vendor or sites such as the NSA, NIST, and SANS.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

Cisco Prime LMS supports encrypted administrative access via SSH and HTTPS. SSH is enabled by default after installation. HTTPS can be enabled with a self-signed certificate or public certificate. To enforce the use of only SSL for the web interface of LMS, perform the following configurations, as shown in Figure 5-74). These configuration steps can also be found in the LMS 4.2 Administration Guide, page 53.

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory). It is accessed by Cisco Secure ACS using TACACS+ services. Individual user IDs are assigned. Roles are defined within LMS and based on group membership. This configuration was used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

Cisco Prime LMS supports role-based user access. Users can be assigned to role groups and, based on privilege levels, have access to only the tasks they require for their job function. By default in Cisco Prime LMS, authenticated users are allowed help desk level access unless specifically configured and assigned to appropriate roles. To restrict access to only configured users, clear the default role option under Admin > System > User Management > Role Management Setup (see Figure 5-75).

Figure 5-75 Role Management Setup

Local user accounts are configured to authorize role privileges and can also be used as fallback if the central authentication server cannot be reached. These accounts must be manually updated to maintain compliance requirements regarding password rotation and expiration as specified in PCI Requirement 8. (See Figure 5-76.)

Figure 5-76 LMS Local User Profile and Roles

Several AAA services are available to externally authenticate users assigned to administer the system. Roles for these individuals are created and managed within the LMS system (see Figure 5-77). As of version 4, LMS no longer supports external authorization.

Figure 5-77 Authentication Mode Setup

In the TACACS server configuration, either all accounts or only specified accounts can be allowed for authenticaiton in the event that the ACS server cannot be reached. (See Figure 5-78.)

Figure 5-78 Login Module Options

Cisco LMS does not include the capability to restrict access to its CLI and HTTPS interfaces from only authorized systems. This server should be implemented in a network segment that includes firewalling or access list restriction capabilities to ensure proper access is limited as necessary.

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution by implementing the Cisco Secure ACS for AAA services and Microsoft Active Directory for user account services. Configure AAA services as shown in Requirement 7.

The Cisco Prime LMS is able to meet some of the requirements locally, as identified below.

• PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco Prime LMS supports the creation of local user accounts with unique IDs through the use of the username command in the CLI and via the web interface Admin > System > User Management > Local User Setup. (See Figure 5-79.) These users are necessary to role assignment and can be used for local fallback user accounts.

Cisco Prime LMS does not support an automated capability to perform this function at this time; the user account would have to be manually reviewed in the device configurations every 90 days.

•PCI 8.5.9—Change user passwords at least every 90 days.

Cisco Prime LMS does not support an automated capability to perform this function at this time; user passwords would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Security Manager.

Cisco Prime LMS supports the ability to specify a minimum password length for local accounts in the Admin > System > User Management > Local User Policy Setup. The default minimum password length must be changed from 6 to 7 characters, as shown in Figure 5-80.

•PCI 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.

Cisco Prime LMS does not support an automated capability to perform this function at this time; user account creation would have to follow this policy manually if a centralized authentication service with this capability could not be used.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

Cisco Prime LMS does not support an automated capability to perform this function at this time. This would have to be met through a compensating control and corporate policy if a centralized authentication service with this capability could not be used.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

This would have to be met through a compensating control and corporate policy if a centralized authentication service with this capability could not be used.

• PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Change the Session TimeOut to 15 minutes from the default 120 minutes, as shown in Figure 5-81 on the Admin > System > System Preferences menu.

Figure 5-81 LMS System Preferences for Idle Timeout

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco Prime LMS is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

The majority of LMS system activities on the server are accomplished through jobs. Each of these jobs tracks the requestor, the success or failure, the type of event, and the systems against which they are executed. The Job Browser shows status of scheduled, current and past jobs. The jobs browser is located at Admin > Jobs > Browser.

Additional audit trail information for system configuration changes (for example, changing the authentication mode of the LMS Server from local to TACACS and back to local) require enabling debug mode logging for the Tomcat service. With debug mode enabled, the server is able to capture sufficient information for logging this configuration change and other similar system changes.

To enable debug mode for the Tomcat console, navigate to Admin > System > Debug Settings > Common Services Log Configurations (see Figure 5-82). Select "Console logs from Tomcat" in the component dropdown. Click the Enable radio button and then click Apply.

Figure 5-82 Common Services Log Configurations

Note Enabling debugging may have a significant performance impact on the LMS system, depending on the number of users who are simultaneously accessing and managing the system. All web front end activity is logged in detail.

The "accesslogfilter.log" captures source IP address, date, time, and username for logged-in users as well as failed logins. Failed logins in this log have a "null" username. The attempted usernames of the failed logins appear in the Audit-Log-{date}.CSV report. These reports do not include the user's source IP address, so some manual correlation must be done between the two logs. These reports are generated at Reports > System Audit Reports > System, or available in \CSCOpx\MDC\log\audit. Informkation about currently logged-in users is available in Reports > System > Users > Who is logged On.

The "stdout.log" and "accesslogfilter.log" files should be added to the Log Rotation under Admin > System > Log Rotation.

To add these logs to the rotation, click Add at the bottom of the page. (See Figure 5-83.)

Figure 5-83 Adding Logs to the Rotation

In the popup window, set the max file size needed to capture about a days' worth of information for your environment and usage. Set the number of backups to the maximum of 99. (See Figure 5-84.)

Figure 5-84 Configure Logrot

Click Browse and navigate to the file location as appropriate for the operating system; for example, C:/PROGRA~2/CSCOpx/MDC/tomcat/logs/stdout.log. (See Figure 5-85.)

Figure 5-85 Server Side File Selector

Click OK to complete the file section, and then Apply to complete the addition of the log rotation file.

Cisco Prime LMS uses the local clock facilities meet the following requirements:

•PCI 10.4.1—Critical systems have the correct and consistent time.

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. The Cisco Prime LMS appliance uses NTP to meet these requirements by implementing the following configuration statements:

ntp server 192.168.62.161 192.168.62.162

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 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).

The Cisco Prime LMS GUI and console scripts support periodic log rotation based on file size and can be configured for the maximum size of the file and number of files to maintain. A script must be created to copy these log files off the system to an external secure repository (for example, a directory on the RSA enVision server) because LMS is not natively capable of sending system events to a centralized repository or ensuring the integrity of the logs to the standards required for PCI. This script file should be automated and scheduled to run periodically at least daily (for example, every 1, 2, or 24 hours) via the operating system (Linus, Solaris, Windows) based on the deployment OS. Logs stored locally are buffered and require operator level privileges on the system to be viewed.

Logging enabled by implementing the following configuration statements in the CLI is only for system events such as software updates via the cars application utility:

logging 192.168.42.124

logging loglevel 6

RSA enVision supports the periodic collection of log files from Cisco LMS versions 3.2 and 4.0. The old method required the daily running of a .VBS script on the server (Windows only) where a file is created in the directory/files/rme/archive directory. It then required the installation of an RSA enVision NIC SFTP Agent, which is used to transfer the log files to the RSA enVision appliance. RSA recently added support for ODBC collection of change audit information from Cisco LMS. It is highly recommended to update to the latest RSA enVision ESU and move to this ODBC method as log collection occurs more frequently. ODBC importing was not validated for LMS at the time of this publication.

The high-performance and easy-to-use integrated event viewer allows you to centrally monitor events from IPS, ASA, and FWSM devices and correlate them to the related configuration policies. This helps identify problems and troubleshoot configurations. Then, using Configuration Manager, you can make adjustments to the configurations and deploy them. Event Viewer supports event management for Cisco ASA, IPS, and FWSM devices.

In addition to the Primary Event Data Store, events can be copied and stored in the Extended Event Data Store. The Extended Event Data Store can be used to back up and archive a larger number of events. This is useful for historical review and analysis of events where Event Viewer can gather event data from both the Primary Event Data Store and the Extended Event Data Store. The Extended Event Data Store can be enabled in Event Management in Security Manager's Administration settings.

The new integrated report management allows you to generate and schedule ASA, IPS, and remote access VPN reports. Reports for ASA and IPS devices are created by aggregating and summarizing events collected by the Event Viewer. Security reports can be used to efficiently monitor, track, and audit network use and security problems reported by managed devices. Report Manager helps in developing and customizing reports for Cisco ASA and IPS devices.

Design Considerations

•Use descriptive notes for each rule set. These are displayed as remarks in the running configuration.

•Virtualize firewall rule set deployment by using a consistent interface naming standard.

•Apply the anti-spoofing feature to all interfaces using FlexConfig.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

There are no unnecessary services enabled by default Cisco Security Manager. Cisco Security Manager should be installed on a hardened operating system.

Cisco Security Manager should be installed on a hardened operating system.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

Figure 5-86 shows how the Cisco Security Manager is configured in Common Services for ensuring that only encrypted communications for administration are used.

Figure 5-86 CSM Secure Administration and AAA Policy

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco Security Manager. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory). It is accessed by Cisco Secure ACS TACACS+ services. Individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

Compliance of the sub-requirements in this section was achieved within the solution by implementing the Cisco Secure ACS for AAA services and Microsoft Active Directory for user account services. Configure AAA services as shown in Requirement 7.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

•PCI 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.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Figure 5-87 shows the configuration setting in the client for setting the idle timeout.

Figure 5-87 Customize Desktop

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco Security Manager is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco Security Manager uses the local clock facilities of the host server on which it is installed to meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

Time synchronization for Windows servers is specified through the domain policy. Servers synchronize their clocks with the domain controller, which in turn is synchronized using NTP. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers.

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

RSA Archer

The RSA Archer eGRC Suite for enterprise governance, risk, and compliance allows your organization to jumpstart your PCI compliance program by conducting continuous, automated assessments to gain the visibility you need to manage and mitigate risk.

Note RSA Archer was initially reviewed by Verizon Business and determined to be outside the scope of the PCI Audit. RSA Archer does store, process, or transmit sensitive cardholder data. There are no Assessment Summary or Capability Assessment details for this product.

RSA Archer provides a comprehensive library of policies, control standards, procedures, and assessments mapped to PCI DSS and other regulatory standards. RSA Archer is designed to orchestrate and visualize the security of both VMware virtualization infrastructure and physical infrastructure from a single console. (See Figure 5-91.)

Figure 5-91 Using Firewall and IDS/IPS

One of the major changes to PCI DSS 2.0 is its clarification on the use of virtualization technology in the cardholder data environment. If virtualization technology is used, the virtualization platform is always in scope for PCI. More than 130 control procedures in the Archer library have been written specifically for VMWare environments and have been mapped to PCI requirements. The RSA Cloud Security and Compliance solution includes software that substantially automates the assessment of whether VMware security controls have been implemented correctly. The results of these automated configuration checks are fed directly into the RSA Archer eGRC Platform, which also captures the results of configuration checks for physical assets via pre-built integration with commercially available scan technologies.

Although a significant number of the VMware control procedures are tested automatically, the remainder must be tested manually because their status cannot be directly inferred from the environment. For these control procedures, project managers can issue manual assessments from the RSA Archer eGRC Platform, using a pre-loaded bank of questions. Project managers can create new questionnaires within minutes and issue them to appropriate users based on asset ownership. Those users are automatically notified of their assessments via rules-driven workflow and My Tasks lists, and can complete their assessments online.

Results for both automated and manual assessments are consolidated in the RSA Archer eGRC Platform and mapped to PCI DSS and other regulations and standards. IT and security operations teams can then monitor compliance with regulations and internal policies across the physical and virtual infrastructure by device, policy, procedure, regulation, and other criteria. This information is presented through a graphical dashboard view, making the information easy to digest and understand.

Configuring the physical and virtual infrastructure according to best-practice security guidelines and regulatory requirements is critical. However, the security and compliance process does not stop there. Organizations also require the ability to monitor misconfigurations, policy violations, and control failures across their infrastructure; and to respond swiftly with appropriate remediation steps. Deficiencies identified through automated and manual configuration checks are captured within the RSA Archer eGRC Platform for management. Control failures are then assigned to appropriate personnel, who can respond by completing remediation tasks or logging exception requests that identify effective compensating controls and are tracked in a Policy Management dashboard, as shown in Figure 5-92.

Figure 5-92 RSA Archer Policy Management

Encryption

A subtle, yet potentially significant change to key management has been introduced with the PCI 2.0 standard. With past versions of the DSS, annual key rotations were required for encryption keys. PCI DSS 2.0 now requires that keys are rotated at the end of their cryptoperiod, and references the NIST 800-57 Special Publication to determine what an appropriate cryptoperiod is. The NIST 800-57 Special Publication is a 324-page, three-part document. Organizations, and even QSAs, may not have the expertise to fully understand such a document that includes countless encryption scenarios, with cryptoperiods ranging from as short as a day and as long as three years.

In an ideal world, with all parties being expert cryptographers, this risk-based change to the standard would be very appropriate and most welcome. However, given the number of scenarios and criteria for determining an appropriate cryptoperiod, it could suggest that this change is too subjective and may become a point of contention between an organization and QSA assessor, as to what is an appropriate cryptoperiod, whereas the former, more prescriptive control, did not allow for flexibility in this area.

RSA Data Protection Manager is an easy-to-use management tool for encrypting keys at the database, file server, and storage layers. It is designed to lower the total cost of ownership and simplify the deployment of encryption throughout the enterprise. It also helps ensure that information is properly secured and fully accessible when needed at any point in its lifecycle through a powerful management console and built-in high availability features. RSA Data Protection Manager provides a comprehensive platform for enforcing and managing the security of sensitive data.

Design Considerations

RSA Data Protection Manager's encryption and key management capabilities can be used to store the data in a compliant manner. RSA Data Protection Manager provides application development libraries that support a wide range of development languages and enables developers to easily integrate encryption into point-of-sale, payment, CRM, ERP, and other business applications that create or process sensitive information. RSA Data Protection Manager can also be used to encrypt data as it flows to both disk and tape by providing key management services to Cisco MDS or EMC storage systems.

Because there were no card handling applications in the simulated lab environment, RSA Data Protection Manager was integrated with Cisco MDS to encrypt all data in the environment regardless of whether it was cardholder data or not.

Public Key Infrastructure (PKI) Requirements

In an RSA Data Protection Manager deployment, a PKI needs to be set up to enable secure communication between the RSA Data Protection server and its clients. (See Figure 5-93.)

•Trusted CA certificate—Installed on both clients and the server to verify the signature of certificates sent by a peer. For example, a RSA Key Manager Client has a trusted CA certificate to verify the signature of the Server certificate.

•Middle CA certificate (optional)—If a certificate is not signed directly by a trusted CA certificate, a middle CA certificate should be installed and sent during SSL connection to verify the certificate chain.

Security Recommendation

Because of vulnerabilities with RSA signatures with a small public exponent, especially 3, RSA recommends that an exponent of F4 (216+1) be used.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

The appliance version of RSA Data Protection Manager comes pre-hardened. The software version must be installed into a hardened operating system, application server, and database server.

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using the included RSA Access Manager Internal Database. Within RSA Data Protection Manager (and the included Access Manager), individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

RSA Data Protection Manager embeds and is protected by RSA Access Manager, which has very powerful and flexible capabilities to define password and account lockout policies that can meet all of the above criteria.

Configuration of user policies is performed via the administration console that can be accessed at the following URL: https://<server address>/admingui/Login.jsp.

RSA Data Protection Manager embeds and is protected by RSA Access Manager, which has very powerful and flexible capabilities to define password and account lockout policies that can meet all of the above criteria.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

RSA Data Protection Manager is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

RSA Data Protection Manager uses Network Time Protocol (NTP) to update and synchronize their local clock facilities and meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. The appliance uses NTP to meet these requirements by specifying the appropriate NTP servers during the installation steps. If NTP servers need to be modified, use the following steps:

1. Open the /etc/ntp.conf file.

2. Under the List Servers section, provide the ntp server ip address or host name to the server parameter.

3. Save the /etc/ntp.conf file.

4. Execute the following commands (as root) to forcibly synchronize the clock of the appliance to the NTP server:

a. Stop the NTPD daemon by typing the following:

service ntpd stop

b. Execute the following command at least three times (to minimize the offset):

ntpdate -u <ntpserver>

c. Start the NTPD daemon by typing the following:

service ntpd start

•PCI 10.5—Secure audit trails so they cannot be altered.

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

•PCI 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).

RSA Data Protection Manager can be configured to send its log data to the RSA enVision log management platform to meet the above requirements. The configuration procedure is documented in the enVision Event Source Configuration Guide for RSA Data Protection Manager, which can be found at RSA Secure Care Online (https://knowledge.rsasecurity.com/)

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Storage

EMC SAN Disk Array

The EMC SAN disk array is used to securely store sensitive compliance data within the data center. Using virtual storage technology, organizations are able to safely combine (in-scope) sensitive date with (out-of-scope) data while maintaining the compliance boundary.

No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Primary PCI Function

The main function of the EMC SAN disk array is to store cardholder data. There is no direct PCI requirement for this storage function.

Table 5-31 lists the component assessment details for the EMC SAN disk array.

Table 5-31 Component Capability Assessment—EMC SAN Disk Array

Design Considerations

The EMC SAN disk array is a primary component of VCE Vblock architecture. Vblock 1 is designed for medium-to-high numbers of virtual machines, and is ideally suited to a broad range of usage scenarios, including shared services, e-mail, file and print, virtual desktops, and collaboration.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

The storage management server provides 256-bit symmetric encryption of all data passed between it and the client components that communicate with it, as listed in the "Port Usage" section (Web browser, Secure CLI), as well as all data passed between storage management servers. The encryption is provided via SSL/TLS and uses the RSA encryption algorithm

The EMC Storage system does not run any unnecessary services by default.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

When you connect to Unisphere through http://<clariion_ip> (port 80), a Java applet is delivered to the browser on your computer. The applet establishes a secure connection over SSL/TLS (port 443) with the storage management server on the CLARiiON storage system. Therefore, even though "https://" is not displayed in the browser, the connection is secure.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

CLARiiON storage systems do not support installation of third-party utilities or patches. EMC will provide an officially released FLARE Operating Environment patch if needed to correct a security-related issue (or any other kind of issue).

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory). It is accessed by the EMC SAN disk array using LDAP services. Individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

When you start a session, Unisphere prompts you for a username, password, and scope (local, global, or LDAP). These credentials are encrypted and sent to the storage management server. The storage management server then attempts to find a match within the user account information. If a match is found, you are identified as an authenticated user.

LDAP Authentication should be used for PCI compliance because the local authentication does not meet all PCI 8 requirements for secure user access and accounts.

Step 1 To configure LDAP authentication, go to the Domains tab, then select Configure LDAP for CLARiiON Systems from the Users menu on the left.

Step 2 Add a new LDAP service by clicking Add and then OK, as shown in Figure 5-95.

Step 4 After communications are established with the LDAP service, specific LDAP users or groups must be given access to Unisphere by mapping them to Unisphere roles. The LDAP service merely performs the authentication. Once authenticated, user authorization is determined by the assigned Unisphere role. The most flexible configuration is to create LDAP groups that correspond to Unisphere roles. This allows you to control access to Unisphere by managing the members of the LDAP groups. Roles were configured as shown in Figure 5-97.

Figure 5-97 Role Mapping

Step 5 The Advanced features were left at their default settings, as shown in Figure 5-98.

Figure 5-98 Advanced Settings

Step 6 You can then log out, and log back in, selecting the Use LDAP option for centralized authentication, as shown in Figure 5-99.

Compliance of the sub-requirements in this section was achieved within the solution by implementing the LDAP authentication capabilities to the Windows Active Directory server for AAA services. Microsoft Active Directory contains the necessary user account services for all of the appropriate PCI 8 requirements. Configure AAA services as shown above in Requirement 7.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

•PCI 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.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

EMC CLARiiON is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

EMC CLARiiON uses Network Time Protocol (NTP) to update and synchronize local clock facilities and meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. EMC CLARiion uses NTP to meet these requirements by implementing the configuration statements shown in Figure 5-100.

Figure 5-100 NTP Configuration for Domain: Local

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

PCI 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).

SP event logs on CLARiiON storage systems can store only a fixed number of events and will wrap if that limit is exceeded. This may take days, weeks, months, or years depending on the logging activity. Therefore, because PCI requires keeping all logs for a set period of time, you need to archive the logs from the CLARiiON storage system on a regular basis. You can do this with the CLI getlog command, but a much more integrated method is to use the "log to system log" option of the Event Monitor template to log events to the Windows system log. You can then archive these logs as required.

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Monitoring

RSA enVision

RSA enVision is a security information and event management (SIEM) platform that provides the capability to implement PCI requirement 10 to track and monitor all access to network resources and cardholder data. RSA enVision does this by collecting, permanently archiving, and processing all the log and event data generated by devices and applications within your network, and generating alerts when it observes suspicious patterns of behavior. Administrators can interrogate the full volume of stored data through an intuitive dashboard, and can use advanced analytical software to gain visibility and understanding of how their network is used and the threats and risks to the infrastructure and applications.

The RSA enVision platform can draw logs from tens of thousands of devices at once, including Cisco network devices, the VCE Vblock infrastructure, the VMware virtual environment, Cisco ASA firewalls, Cisco IPS devices, Cisco IronPort E-mail Appliance, other RSA products, and the HyTrust appliance. Out of the box, RSA enVision can produce PCI 2.0 compliance reports and alerts based on the log and event data it collects. RSA enVision also offers powerful tools to create custom reports and alerts specific to your environment.

Design Considerations

Depending on the size of your network, RSA enVision may be deployed as a standalone, self-contained, security-hardened appliance or in a distributed deployment to cope with the demands of the largest enterprise networks. When deployed in a distributed architecture, multiple dedicated appliances are deployed where required to perform key roles. Local and remote collectors perform data collection. Data servers manage the data. Application servers perform analysis and reporting. Data itself can be stored using direct attached, online, near-line or offline storage from the full EMC storage portfolio.

RSA enVision does not require any client-side agents to pull log or event data from your infrastructure or applications. RSA enVision can integrate with event sources through standard protocols such as syslog or SNMP by configuring the event source to send data to enVision. For richer event data, enVision integrates with some event sources through their APIs or directly with their database backends. Specific event source device configuration procedures can be found at RSA Secure Care Online (https://knowledge.rsasecurity.com/)

RSA enVision is sold as a standalone appliance. It is available in a variety of hardware options based on the requirements of the enterprise design. The system comes pre-installed on an already hardened operation system.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

RSA enVision services can be independently enabled or disabled, depending on what protocols are required to collect log and event data, as shown in Figure 5-102.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

The RSA enVision web interface is protected using SSL.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

RSA enVision publishes security patches on RSA Secure Care Online (https://knowledge.rsasecurity.com/) in accordance with industry best practices to manage and respond to security vulnerabilities to minimize customers' risk of exposure.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 can be met using the RSA enVision Internal Database (as part of its local Windows Active Directory). For validation, RSA enVision was linked to the centralized user database (Active Directory) using LDAP. Within RSA enVision, individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

RSA enVision management interfaces implement role-based access control that can be used to restrict access to privileged user IDs, as shown in Figure 5-103.

Figure 5-103 RSA enVision User Profile

•PCI 7.2.1—Coverage of all system components

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

RSA enVision's access control system defaults to deny access.

RSA enVision is configurable to use its local Active Directory database, or an external database via LDAP, as shown in Figure 5-104.

Figure 5-104 RSA enVision Authentication Servers

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution by implementing the LDAP authentication capabilities to the Windows Active Directory server for AAA services. Microsoft Active Directory contains the necessary user account services for all of the appropriate PCI 8 requirements. Configure AAA services as shown above in Requirement 7.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

•PCI 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.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

RSA enVision can authenticate users against external authentication services such as Windows Active Directory using the LDAP protocol. The above policies can be implemented within Windows Active Directory as was validated in this solution.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

RSA enVision is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

RSA enVision uses the local clock facilities of the host server on which it is installed to meet the following requirements:

•PCI 10.4—Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. Note: One example of time synchronization technology is Network Time Protocol (NTP).

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

Time synchronization for this windows server is specified through the Domain Policy because the RSA enVision appliance is itself a Domain Controller. The server synchronizes its clock to know time sources using NTP as specified in the initial appliance setup. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers.

•PCI 10.5—Secure audit trails so they cannot be altered.

Requirement 10.5 was met using a central logging repository, RSA enVision, which collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

RSA enVision delivers mirrored, unfiltered data to its Internet Protocol Database, which provides the ability to retain data in its original format. Further, "write once, read many" capabilities help ensure that the mirrored copy remains intact, even if the original data is compromised. RSA enVision-captured event logs are stored on a hardened operating system and protected using an integrity check mechanism.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

RSA enVision's management interfaces implement a role-based access control system to limit who has access to log data.

RSA enVision-captured event logs are stored on a hardened operating system in a compressed form and protected via an integrity check mechanism. Access to the operating system and enVision management interfaces can be restricted through operating system and enVision access control systems.

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

RSA enVision's primary function is to provide a centralized point for tracking and monitoring access to cardholder data throughout a PCI environment.

•PCI 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).

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

HyTrust Appliance

Vblock Infrastructure Platforms from VCE allow organizations to take advantage of the architectural, operational, and financial benefits of virtualization in their PCI infrastructure. HyTrust Appliance (HTA) complements Vblock capabilities by providing:

•Access control for virtual infrastructure including least privilege, separation of duties, and two-factor authentication

•Granular and exhaustive logging and auditing

•Segmentation of infrastructure to support virtualized applications

PCI DSS 2.0 clarifies the use of virtualization technology with the cardholder data environment (CDE) and specifies that the platform is always in scope. This requirement is consistent with additional risks introduced by mobility and the fast-paced change rate of virtualized assets that can now be reconfigured, relocated, and duplicated by remote administrators. These capabilities combined with poor access control create a significant risk. Hypervisor logs geared toward software maintenance and troubleshooting are obviously useful, but not in the context of a compliance audit.

HyTrust Appliance systematically addresses the three broad areas of IT control objectives (access and user administration, change and configuration, and operations), by proactively enforcing policies for all administrative access, regardless of access method: Secure Shell (SSH) to host, VMware vSphere client to host, or VMware vCenter or any of the programmatic access. HyTrust Appliance provides two-factor authentication and role-based access control, logical segmentation of shared infrastructure, root password vaulting, and audit-quality logs of every attempted access.

Design Considerations

Define rules and deploy policy to activate protection for the virtual infrastructure.

Administrators can define custom rules that restrict entitlement based on specific virtual infrastructure objects that users need to access and manage. Rules that define entitlement can be based on pre-defined roles or administrators can use custom user-defined roles.

The Hytrust appliance provides complete logging of administrator actions by proxying VMware vCenter client connections to the vSphere management server, and clients that try to connect directly to ESX/ESXi hosts. This logging includes the source IP address of the clients, permitted actions and actions that are blocked because the client may not have sufficient privileges (all requirements of PCI that VMware cannot perform natively).

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

HyTrust Appliance configures the virtualization platform (VMware ESX server) to disable unsecure protocols. In addition, HyTrust Appliance proxies non-console management access and redirects attempts to connect via the HTTP management protocol to HTTPS-based connections. In the reference implementation, the configuration of VMware ESX 4.0 servers was performed in accordance with the HyTrust default PCI configuration template. Specifically, the following controls are set:

HyTrust Appliance configures the virtualization platform (VMware ESX server) to disable unnecessary boot services. In addition, HyTrust Appliance restricts the use of sudo and su services and ensures tighter configuration of copy and paste sharing between the host hypervisor and CDE implemented as a virtual system component.

In the reference implementation, the configuration of VMware ESX 4.0 servers was performed in accordance with the HyTrust default PCI configuration template. Specifically, the following controls were configured and monitored:

All the boot services were disabled on the VMware ESX server except as follows:

Make sure there is at least one user in the wheel group, then uncomment:

"auth required /lib/security/$ISA/pam_wheel.so

use_uid" in /etc/pam.d/su

Additionally, HyTrust establishes a system for rotating root passwords for the VMware ESX servers under HyTrust protection and allowing authorized users to check out one-time use time-limited auto-generated root passwords.

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

HyTrust Appliance is a closed system based on the CentOS operating system, which implements a limited number of necessary services. Additional security features include the following:

–Production services run unprivileged

–No root login is allowed

–The HTA administrator account is unprivileged

–Sudoers-based privilege escalation

–All unencrypted services disabled by default

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

HyTrust Appliance has the capability to download security updates and fixes directly from the HyTrust web site. When this is enabled, updates are downloaded and installed automatically. Updates can also be distributed as ISO packages and installed manually. To prevent Trojan attacks, HyTrust updates and HTA licenses are signed and validated using public keys.

Updates provided via this facility include security updates to the CentOS, application stack, and software developed by HyTrust.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory, which is linked via LDAP, RADIUS, and TACACS+ services). Individual user IDs are assigned. Roles are defined and based on group membership. HyTrust Appliance connects to this resource via LDAP to address the following individual requirements:

HyTrust Appliance implements a sophisticated policy-driven access control system that makes an authorization decision for every attempted operation in the Vblock environment. The authorization decision is based on the user ID as obtained from the vSphere session, the user function as derived from the user's assigned role in Active Directory, logical infrastructure segmentation, least privilege role defined for this activity, and object-level policy active for that user.

In the reference implementation, a policy was created that restricted CDE virtual systems to operating only on the PCI portion of the infrastructure and enforced separation of duties between the network administrators and CDE application owners.

Figure 5-105 Edit Rule Screen

Policy and privilege definition was performed by a separate group of authorized users, typically security professionals.

•PCI 7.2.1—Coverage of all system components

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

HyTrust Appliance implements default "deny all" access policy. Many of the users that gain access to Vblock infrastructure by the means of HyTrust Appliance proxying their operations do not have privileges to log into the HyTrust Appliance management console.

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution by implementing LDAP to the domain controller for AAA services and Microsoft Active Directory policy for user account services. Configure AAA services as shown in Requirement 7.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

Sub-requirement 8.2 is met by supporting RSA two-factor authentication where the user enters the AD password (something they know) in conjunction with an RSA physical token (something they have).

HyTrust Appliance acts as a compensating control for the Vblock infrastructure and enables RSA two-factor authentication to work with any methods of access to VMware vSphere or Cisco Nexus 1000V.

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

HyTrust Appliance enforces the use of one-time root passwords for all VMware ESX hosts in the environment. Unique random machine-generated passwords of 12 characters in length are set up for each host and rotated every five days (see Figure 5-106). If requested by a privileged user, a different one-time use password was generated and remained valid for a fixed time duration not to exceed 24 hours. Sub-requirement 8.5.8 was met by allowing only one temporary use password to be issued at the time, thus associating the password with a specific user who was issued the password.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

HyTrust Appliance is able to track and monitor all administrative user access and events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

HyTrust Appliance uses NTP to update and synchronize their local clock facilities and meet the following requirements:

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. The HyTrust Appliance uses NTP to meet these requirements by specifying the NTP server in the IP settings. (See Figure 5-107.)

Figure 5-107 Specifying the NTP Server

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Additional In Scope Devices

Any system that stores, processes, or transmits cardholder data is considered in scope for PCI compliance. Infrastructure components that provide network services such as load balancing or WAN optimization are often not considered when contemplating compliance. However, if these technologies pass sensitive data, they are subject to the same controls of traditional security products.

The capabilities that these components need to meet are highlighted in Table 5-1.

Infrastructure

Routing

Router—Branch

The Cisco Integrated Services Router (ISR) is the component that is used as the primary routing and security platform of the branches. It can securely scale to the requirements of the business because it has integrated firewall, VPN, and IPS/IDS capabilities. WAN options include traditional terrestrial paths using T1, T3, Ethernet, and so on; wireless options include 3G/4G/Wi-Fi modules connecting branches over public paths for higher availability.

The Cisco ISR consolidates voice, data, and security into a single platform with local and centralized management services. It delivers scalable rich media, service virtualization, and energy efficiency ideal for deployments requiring business continuity, WAN flexibility, and superior collaboration capabilities. The Cisco ISR uses field-upgradeable motherboards, with services such as security, mobility, WAN optimization, unified communications, video, and customized applications.

Table 5-36 lists the performance of the Cisco ISR in satisfying PCI sub-requirements.

No compensating controls were required to satisfy any sub-requirements.

PCI Sub-Requirements Failed

No sub-requirements were failed.

Primary PCI Function

The main function of the Cisco ISR is the segmentation of PCI scope and enforcement of that new scope boundary.

It has five primary functions/capabilities in relation to PCI.

1. As a router, directing traffic between networks

A router in its simplest form routes between networks. By segmenting a network into sub-networks, an organization can isolate sensitive information from non-sensitive information. The Cisco ISR can segment and route sensitive traffic separately from non-sensitive traffic to reduce the overall scope of a company's cardholder data environment. Depending on risk vectors within the branch, different levels of enforcement might be required at the segmented scope boundary level. (See items 2, 3 and 4 following.)

2. As a router with ACLs, restricting traffic between the cardholder data environment and other areas of the network

A router with ACLs can be used to enforce segmented traffic only if the ACLs are used to filter and segment private networks of the organization. They may not be used to filter untrusted networks. For example, many organizations have a central chokepoint in their data center that is the connection to the Internet (an untrusted network). As long as the organization has only untrusted network connections outside of the branch, (the data center, in this case), then an organization may use router access lists to protect its scope from its own private internal networks. As soon as the branch connects to untrusted networks directly, items 3 and 4 below become relevant. (See Figure 5-108.)

Figure 5-108 ACLs Segment Traffic

3. As a stateful firewall, restricting traffic between the cardholder data environment and other areas of the network

As soon as any untrusted network is introduced at the branch level, firewalling and IDS/IPS must be deployed. The following are examples of untrusted networks:

–The Internet

–Wireless

–Satellite

–3G/4G cellular backup

4. As an intrusion prevention system, inspecting all traffic going to and from the cardholder data environment

As soon as any untrusted network is introduced at the branch level, firewalling and IDS/IPS must be deployed. (See Figure 5-109.)

Figure 5-109 Using Firewall and IDS/IPS

The Cisco ISR can be used to address segmentation challenges and enforce scope boundaries depending on the levels required by the organization. Each of these features can be enabled by using a license key. This feature is particularly useful for organizations because it does not require a visit to every branch to enable the firewall/IPS/IDS capability. If these capabilities are not used within the Cisco ISR, an external component(s) can be used to address this level of scope enforcement.

5. As a VPN system, encrypting all traffic going to and from the branch across open and public networks.

The Cisco ISR can be used to address the need to encrypt the transmission of cardholder data across open, public networks such as 3G/4G/Wi-fi, and satellite technologies using SSL and IPSec technologies.

Design Considerations

•The security features of the Cisco ISR routers in the branch designs are configured using Cisco Security Manager. When adopting this as the primary method of router configuration, Cisco does not recommend making changes directly to the command-line interface (CLI) of the router. Unpredictable results can occur when central and local management are used concurrently.

•The general configuration of the Cisco ISR routers in the branch architectures are maintained with Cisco Prime LMS.

•Ensure that inspection rules and/or zones are enabled on the Cisco ISR router so that the firewall maintains state (none are enabled by default).

•Redundant Cisco IOS firewalls do not have the capability to maintain state between the routers. During a failure, client communication sessions need to be re-established through the alternate router. If high availability with statefulness is a requirement, Cisco ASA firewalls should be used.

•Access into a branch router from the WAN needs to be protected by a branch-located firewall filter if the WAN technology is considered untrusted/public (for example, Internet DSL or cable network, public 3G or 4G, satellite). In the Cisco PCI Solution lab, a private MPLS WAN is simulated, and filtering of the branch traffic occurs on the WAN link of all in-scope locations.

•Disable the HTTP server service on the router and enable the HTTP secure server.

•Disable use of Telnet and enable use of only SSH version 2.

•Configure the session-timeout and exec-timeout commands to 15 minutes or less on the console, VTY, and line interfaces on the router. Disable the AUX interface.

•Configure appropriate banner messages on login, incoming, and exec modes of the router. The login banner warning should not reveal the identity of the company that owns or manages the router. The incoming and executive banners should state that these areas are considered private and that unauthorized access will result in prosecution to the full extent of the law.

•Configure the primary login authentication of the router to be directed to the Cisco Secure ACS. Individual user account profiles need to be created. Configure secondary or tertiary authentication local to the router itself in the event of a WAN or Cisco Secure ACS failure.

•Use the no service password-recovery command in conjunction with the service password encryption command to prevent password theft by physical compromise of the router.

•Change default passwords and community strings to appropriate complexity.

•Configure logs to be sent to a centralized syslog server, such as RSA enVision.

•Configure NTP to ensure all logging is coordinated.

•Disable un-necessary services (for example, Bootp, Pad, ipv6).

•Shutdown unused interfaces.

Each of the branch designs was implemented using guidance from the following:

PCI Assessment Detail—PCI Sub-Requirements Satisfied

•PCI 1.2.1—Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

Cisco zone-based firewalls are configurable to restrict traffic through the use of class map, policy map, and zone pair service policy statements and access lists.

•PCI 1.2.2—Secure and synchronize router configuration files

Router configuration files are backed up centrally using Cisco Prime LMS. This tool also verifies that running and startup configurations of routers and switches are synchronized.

•PCI 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.

Cisco zone-based firewalls are configured with source and destination zones to control traffic passing from one zone to another. Each of these zone pairs receives a service policy, which is the mechanism that identifies permitted traffic, while all other traffic is dropped and logged.

•PCI 1.3.3—Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

•PCI 1.3.4—Do not allow internal addresses to pass from the Internet into the DMZ.

Router WAN interfaces connected to public network connections such as the Internet should have filtering applied to prevent spoofing of both public and private IP address. Typical filters for private IP address blocks are as follows:

ip access-list extended COARSE-FILTER-INTERNET-IN

remark -------------------------------------------------------

remark ---Block Private Networks---

deny ip 10.0.0.0 0.255.255.255 any log

deny ip 172.16.0.0 0.15.255.255 any log

deny ip 192.168.0.0 0.0.255.255 any log

remark -

remark ---Block Autoconfiguration Networks---

deny ip 169.254.0.0 0.0.255.255 any log

remark -

remark ---Block Loopback Networks---

deny ip 127.0.0.0 0.0.255.255 any log

remark -

remark ---Block Multicast Networks---

deny ip 224.0.0.0 15.255.255.255 any log

remark -

remark ---Block Your assigned IP's at edge---

deny ip <YOUR_CIDR_BLOCK> any log

remark -

remark ---Allow remaining public internet traffic---

permit ip any any

•PCI 1.3.5—Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

Cisco zone-based firewalls are configured with source and destination zones to control traffic passing from one zone to another. Each of these zone pairs receives a service policy, which is the mechanism that identifies permitted traffic, while all other traffic is dropped and logged.

zone-pair security CSM_S_POS-S_WAN_1 source S_POS destination S_WAN

service-policy type inspect CSM_ZBF_POLICY_MAP_16

•PCI 1.3.6—Implement stateful inspection, also known as dynamic packet filtering. (That is, only "established" connections are allowed into the network.)

Cisco zone-based firewalls are configurable to perform stateful inspection by use of the inspect statement in the associated class map, policy map, and zone pair service policy statements.

class-map type inspect match-all CSM_ZBF_CLASS_MAP_9

match access-group name CSM_ZBF_CMAP_ACL_9

match protocol tcp

policy-map type inspect CSM_ZBF_POLICY_MAP_7

class type inspect CSM_ZBF_CLASS_MAP_9

inspect Inspect-1

class type inspect CSM_ZBF_CLASS_MAP_10

inspect Inspect-1

class type inspect CSM_ZBF_CLASS_MAP_11

inspect Inspect-1

class class-default

drop log

zone-pair security CSM_S_WAN-S_POS_1 source S_WAN destination S_POS

service-policy type inspect CSM_ZBF_POLICY_MAP_7

•PCI 1.3.7—Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

In the branch design, VLANs are used to segment traffic based on function and security requirements. Each of these VLANs are assigned to an appropriate security zone using the zone-based firewall feature of the router.

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Cisco routers can be configured to use secure protocols for all system functions. This includes SSH and HTTPS for remote management, IPsec VPN for remote connectivity, and SCP for file transfers. Insecure services can be disabled or blocked using configuration statements and access lists.

Cisco routers have several services that are enabled by default that need to be disabled:

no service pad

no service udp-small-servers

no service tcp-small-servers

no ip bootp server

no mop enable

no service finger

no ip forward-protocol nd

no ip http server

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

Cisco routers support administrative protocols with strong cryptography such as SSH version 2 and HTTPS with 3DES.

Note Strong cryptography—Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 (www.csrc.nist.gov/publications/) for more information.

! Before Crypto keys can be generated hostname and domain name must be entered

•PCI 4.1—Use strong cryptography and security protocols (for example, SSL/TLS, IPSec, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

–The Internet

–Wireless technologies,

–Global System for Mobile communications (GSM)

–General Packet Radio Service (GPRS)

Public WAN link connections include technologies such as DSL, cable, satellite, Wi-Fi, and 3G/4G networks. These are considered untrusted public networks within PCI. A VPN is required to securely tunnel traffic between the branch and the enterprise network.

The following example describes equipment located at the branch and the data center headend router. The branch router is referred to as the spoke router, and the data center router as the hub. Figure 5-110 shows a simplified Cisco VPN topology.

Figure 5-110 Cisco VPN Topology

Cisco VPN technology connects the branches to the data center over the Internet. As a result, a secure, encrypted tunnel is used to secure sensitive information such as cardholder data. Cisco VPN technologies offer a choice to protect the data in transit and provide a secure access to the branches' networks, including Easy VPN and Dynamic Multipoint VPN (DMVPN).

This example shows DMVPN as the VPN technology. DMVPN uses IPSec-encrypted GRE tunnels, with dynamic routing. Two simultaneously active DMVPN tunnels are built from each branch to different hub routers, providing instant failover. If the primary tunnel fails, routing converges to use the secondary tunnel, and all sessions are kept alive. In addition, with DMVPN, branch routers can dynamically build spoke-to-spoke tunnels between each other to exchange data, without having to tunnel the traffic back to the hub, thus alleviating the load on the headend.

Following are sample DMVPN spoke and hub configurations. Enhanced Interior Gateway Routing Protocol (EIGRP) is used as the routing protocol inside the DMVPN network. Split-tunneling is used and only traffic on the POS and employee VLANs going to the servers on the 10.0.0.0 network at the headquarters is sent through the DMVPN tunnel, while any other traffic is sent straight to the Internet. Note that, if split-tunneling is not required, a default route (to 0.0.0.0) can be advertised from the hubs to the spokes, instead of specific subnets.

891 Branch Router

!! Configure the IP addresses on the VLAN interfaces

interface vlan 10

description POS VLAN

ip address 172.16.10.1 255.255.255.0

no autostate

interface vlan 20

description employee VLAN

ip address 172.16.20.1 255.255.255.0

no autostate

interface vlan 30

description guest VLAN

ip address 172.16.30.1 255.255.255.0

no autostate

!! Configure the ISAKMP and IPSec policies

crypto isakmp policy 1

encryption aes 256

crypto isakmp keepalive 35 5

crypto isakmp nat keepalive 10

crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac

mode transport

crypto ipsec profile cvs

set transform-set t1

ip multicast-routing

!! Configure the DMVPN tunnel

interface Tunnel0

bandwidth 1000

ip address 192.168.1.3 255.255.255.0

no ip redirects

ip mtu 1400

ip hello-interval eigrp 99 30

ip hold-time eigrp 99 90

ip pim sparse-dense-mode

ip nhrp map multicast <Primary-hub-public-IP>

ip nhrp map 192.168.1.1 <Primary-hub-public-IP>

ip nhrp nhs 192.168.1.1

ip nhrp map multicast <Secondary-hub-public-IP>

ip nhrp map 192.168.1.2 <Secondary-hub-public-IP>

ip nhrp nhs 192.168.1.2

ip nhrp authentication <password>

ip nhrp network-id 12345

ip nhrp holdtime 300

ip nhrp registration no-unique

ip nhrp shortcut

ip nhrp redirect

ip tcp adjust-mss 1360

load-interval 30

delay 1000

qos pre-classify

tunnel source GigabitEthernet0

tunnel mode gre multipoint

tunnel key 12345

tunnel protection ipsec profile cvs

!! Configure the DMVPN routing protocol. Only permit the POS and employee LAN !!
subnets to be advertised to the hubs

ip access-list standard dmvpn_acl

permit 172.16.10.0 0.0.0.255

permit 172.16.20.0 0.0.0.255

router eigrp 99

no auto-summary

network 192.168.1.3 0.0.0.0

network 172.16.10.1 0.0.0.0

network 172.16.20.1 0.0.0.0

distribute-list dmvpn_acl out

3945E Hub Router:

!! Configure the ISAKMP and IPSec policies

crypto isakmp policy 1

encryption aes 256

crypto isakmp keepalive 35 5

crypto isakmp nat keepalive 10

crypto ipsec transform-set t1 esp-aes 256 esp-sha-hmac

mode transport require

crypto ipsec profile cvs

set transform-set t1

!! Enable multicast routing

ip multicast-routing

!! Configure the DMVPN tunnel. Use the same bandwidth metric for both primary !! and
secondary hubs, but a lower delay metric on the primary hub

interface Tunnel0

bandwidth 2000

ip address 192.168.1.1 255.255.255.0

no ip redirects

ip mtu 1400

ip pim sparse-dense-mode

ip nhrp authentication <password>

ip nhrp map multicast dynamic

ip nhrp network-id 12345

ip nhrp redirect

ip tcp adjust-mss 1360

no ip split-horizon eigrp 99

delay 1000

qos pre-classify

tunnel source <Outside_Interface >

tunnel mode gre multipoint

tunnel key 12345

tunnel protection ipsec profile cvs

!! Configure the DMVPN routing protocol. Only the 10.0.0.0 network is !!
advertised to the spokes in this example (split-tunneling)

router eigrp 99

no auto-summary

network 192.168.1.1 0.0.0.0

redistribute static route-map split_in

ip access-list standard split_in

permit 10.0.0.0

route-map split_in permit 10

match ip address split_in

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco Integrated Services Routers. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory). It is accessed by Cisco Secure ACS TACACS+ services. Individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

Cisco routers are configured to use a AAA model for user-based access. Users can be assigned to groups and based on privilege levels, have access to only the information they require for their job function. By default in Cisco routers, no users are allowed access unless specifically configured and assigned appropriate passwords.

aaa new-model

aaa authentication login RETAIL group tacacs+ local

aaa authentication enable default group tacacs+ enable

aaa authorization exec default group tacacs+ if-authenticated

aaa accounting update newinfo

aaa accounting exec default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

aaa accounting system default start-stop group tacacs+

aaa session-id common

tacacs-server host 192.168.42.131

tacacs-server directed-request

tacacs-server domain-stripping

tacacs-server key 7 <removed>

Local user accounts are configured in the event that the centralized authentication server cannot be reached. These accounts must be manually updated to maintain compliance requirements regarding password rotation and expiration, as specified in PCI requirement 8.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

These AAA authentication groups are assigned to the administrative interfaces where users connect:

ip http authentication aaa login-authentication RETAIL

line con 0

login authentication RETAIL

line vty 0 4

login authentication RETAIL

line vty 5 15

login authentication RETAIL

Services provide on-going access to software updates and security patches for a variety of Cisco products.

Requirement 8: Assign a Unique ID to Each Person with Computer Access

Compliance of the sub-requirements in this section was achieved within the solution by implementing the Cisco Secure ACS for AAA services and Microsoft Active Directory for user account services. Configure AAA services as shown in Requirement 7.

The router is able to meet some of the requirements locally, as identified below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco routers support the creation of local user accounts with unique IDs through the use of the username command. These can be used for local fallback user accounts.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

Local user accounts on Cisco routers require setting of a password.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

In addition to the use of service password encryption to encrypt line interface passwords, the routers also support the use of AES encryption of pre-shared keys.

service password-encryption

password encryption aes

Use the username secret command to configure a username and MD5-encrypted user password when creating local fall back user accounts.

Cisco routers do not support an automated capability to perform this function at this time; the user account would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Prime LMS.

•PCI 8.5.9—Change user passwords at least every 90 days.

Cisco routers do not support an automated capability to perform this function at this time, user passwords would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Prime LMS.

Cisco routers do not support an automated capability to perform this function at this time; user account creation would have to follow this policy manually.

•PCI 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.

Cisco routers do not support an automated capability to perform this function at this time: user account creation would have to follow this policy manually.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

Cisco routers support the local ability to block logins after a specified number of failed login attempts with the following command:

login block-for 1800 attempts 6 within 65535

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Cisco routers support the local ability to block logins after a specified time after failed login attempts with the following command:

login block-for 1800 attempts 6 within 65535

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Cisco router management interfaces are configured as follows to meet this requirement:

ip http timeout-policy idle 900

line con 0

session-timeout 15 output

exec-timeout 15 0

line vty 0 4

session-timeout 15 output

exec-timeout 15 0

line vty 5 15

session-timeout 15 output

exec-timeout 15 0

Note If only thesession timeoutcommand is specified, the session timeout interval is based solely on detected input from the user. If thesession timeoutcommand is specified with theoutputkeyword, the interval is based on both input and output traffic. You can specify a session timeout on each port. Thesession-timeoutcommand behaves slightly differently on virtual (vty) terminals than on physical console, auxiliary (aux), and terminal (tty) lines. When a timeout occurs on a vty, the user session returns to the EXEC prompt. When a timeout occurs on physical lines, the user session is logged out and the line returned to the idle state. You can use a combination of theexec-timeoutandsession-timeoutline configuration commands, set to approximately the same values, to get the same behavior from virtual lines that thesession-timeoutcommand causes on physical lines.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

The Cisco ISRs are able to track and monitor all administrative user access and events such as port up/down, as well as device authentication events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco routers track individual administrator actions through several mechanisms including AAA, logging, and system events by implementing the following configuration statements:

logging trap debugging

logging 192.168.42.124

logging buffered 50000

login on-failure log

login on-success log

archive

log config

logging enable

notify syslog contenttype plaintext

hidekeys

The Cisco ISR uses Network Time Protocol (NTP) to update and synchronize their local clock facilities and meet sub-requirements 10.4.1 through 10.4.3:

•PCI 10.4.1—Critical systems have the correct and consistent time.

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP servers were hosted at the data center site. The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers. Cisco routers use NTP to meet these requirements by implementing the following configuration statements:

•PCI 10.5.3—Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

Requirement 11: Regularly Test Security Systems and Processes

•PCI 11.4—Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.

Cisco routers are capable of performing intrusion detection. Each of the branch reference designs includes untrusted networks (either a public Internet connection or wireless networks); therefore, intrusion detection capabilities are required. IPS signature updates and configurations are managed centrally through Cisco Security Manager, which implements the following configuration statements to enable the IPS inspection capability in the routers:

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Routers—Data Center

The primary function of data center routers from a PCI perspective is routing between sensitive networks and out-of scope networks. Data center routers function as WAN aggregation routers or connecting to larger networks such as the Internet. Therefore, performance and scalability are equally important as securely passing data. For this reason, and unlike the routers in the branch, security functions are typically separated physically into distinct appliances. The Cisco ASR1002 routers were used for the Internet edge and branch WAN edge portions of the network within the solution testing.

Primary PCI Function

The main function of the data center routers is the segmentation of PCI scope and enforcement of that new scope boundary. The data center router has four primary functions/capabilities in relation to PCI:

1. As a router, directing traffic between networks

A router in its simplest form routes between networks. By segmenting a network into sub-networks, an organization can isolate sensitive information from non-sensitive information. Data center routers can segment and route sensitive traffic separately from non-sensitive traffic to reduce the overall scope of a company's cardholder data environment. Depending on risk vectors, different levels of enforcement might be required at the segmented scope boundary level. (See items 2, 3, and 4 following.)

2. As a router with ACLs, restricting traffic between the cardholder data environment and other areas of the network

A router with ACLs can be used to enforce segmented traffic only if the ACLs are used to filter and segment private networks of the organization. They may not be used to filter untrusted networks. For example, if a data center router is used to segment sensitive PCI networks from internal inventory networks, an organization may use router access lists to protect its scope. As soon as the branch connects to untrusted networks directly, items 3 and 4 below become relevant.

3. As a stateful firewall, restricting traffic between the cardholder data environment and other areas of the network

As soon as any untrusted network is introduced to the connections of the data center router, firewalling and IDS/IPS must be deployed. The following are examples of untrusted networks:

–Internet

–Wireless

–Satellite

–Cellular backup

4. As an intrusion prevention system, inspecting all traffic going to and from the cardholder data environment

As soon as any untrusted network is introduced to the connections of the data center router, firewalling and IDS/IPS must be deployed at that location.

Design Considerations

•Configuration was done manually on the router CLI, and backup of configuration and monitoring of configuration for changes and non-compliance were done through Cisco Prime LMS (alternatively, CiscoWorks Resource Manager Essentials, a component of Cisco LMS, can be used as well).

•The perimeter firewalling of the data center was provided by the Cisco ASA. As a result, the Cisco Cisco ASR1002 was not evaluated according to the set of 1.x requirements for firewalls.

•Disable the HTTP server service on the router and enable the HTTP secure server.

•Configure the session-timeout and exec-timeout commands to 15 minutes or less on the console, VTY, and line interfaces on the router. Disable the AUX interface.

•Configure appropriate banner messages on login, incoming, and exec modes of the router. The login banner warning should not reveal the identity of the company that owns or manages the router. The incoming and executive banners should state that these areas are considered private and that unauthorized access will result in prosecution to the full extent of the law.

•Configure the primary login authentication of the router to be directed to the Cisco Secure ACS. Individual user account profiles need to be created. Configure secondary or tertiary authentication local to the router itself in the event of a WAN or Cisco Secure ACS failure.

•Use the no service password-recovery command in conjunction with the service password encryption command to prevent password theft by physical compromise of the router.

•Enable anti-spoofing on all interfaces.

•Routers in the data center were implemented using guidance from the following:

•For the Internet edge routers, use the access list below on the interface that is facing the Internet. This access list explicitly filters traffic destined for the infrastructure address space. Deployment of edge infrastructure access lists requires that you clearly define your infrastructure space and the required/authorized protocols that access this space. The access list is applied at the ingress to your network on all externally facing connections, such as peering connections, customer connections, and so forth.

!

ip access-list extended COARSE-FILTER-INTERNET-IN

remark --------------------------------------

remark ---Block Private Networks---

deny ip 10.0.0.0 0.255.255.255 any log

deny ip 172.16.0.0 0.15.255.255 any log

deny ip 192.168.0.0 0.0.255.255 any log

remark -

remark ---Block Autoconfiguration Networks---

deny ip 169.254.0.0 0.0.255.255 any log

remark -

remark ---Block Loopback Networks---

deny ip 127.0.0.0 0.0.255.255 any log

remark -

remark ---Block Multicast Networks---

deny ip 224.0.0.0 15.255.255.255 any log

remark -

remark ---Block Your assigned IP's at edge---

deny ip <YOUR_CIDR_BLOCK> any log

remark -

remark ---Allow remaining public internet traffic---

permit ip any any

!

Note The log keyword can be used to provide additional details about source and destinations for a given protocol. Although this keyword provides valuable insight into the details of access list hits, excessive hits to an access list entry that uses the log keyword increase CPU utilization. The performance impact associated with logging varies by platform.

The service provider network in the solution represented an Multiprotocol Label Switching (MPLS) network. At the writing of this document, MPLS is considered a private network, and secure tunneling across the WAN is not required. MPLS implementations may be public or private with regards to PCI, depending on how the service provider implements the MPLS network and whether the provider has satisfactorily completed their annual PCI audit. For best practices when in doubt, Cisco recommends VPN tunneling be implemented. For further information on implementing an IPSec VPN, see the IPSec VPN Direct Encapsulation Design Guide at the following URL: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/Dir_Encap.html

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Cisco routers can be configured to use secure protocols for all system functions. This includes SSH and HTTPS for remote management, IPsec VPN for remote connectivity, and SCP for file transfers. Insecure services can be disabled or blocked using configuration statements and access lists:

Cisco routers have several services that are enabled by default that can be disabled:

no service pad

no service udp-small-servers

no service tcp-small-servers

no ip bootp server

no mop enable

no service finger

no ip forward-protocol nd

no ip http server

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

Cisco routers support administrative protocols with strong cryptography such as SSH version 2 and HTTPS with 3DES.

Note Strong cryptography is based on industry-tested and accepted algorithms, along with strong key lengths and proper key management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 (www.csrc.nist.gov/publications/) for more information.

! Before Crypto keys can be generated hostname and domain name must be entered

• PCI 4.1—Use strong cryptography and security protocols (for example, SSL/TLS, IPSec, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

–The Internet

–Wireless technologies,

–Global System for Mobile communications (GSM)

–General Packet Radio Service (GPRS)

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco routers. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

The relevant sub-requirements of Requirement 7 were met using a centralized user database (Active Directory). It is accessed by Cisco Secure ACS TACACS+ services. Individual user IDs are assigned. Roles are defined and based on group membership. This configuration was used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

Cisco routers are configured to use a AAA model for user-based access. Users can be assigned to groups, and based on privilege levels, have access to only the information they require for their job function. By default in Cisco routers, no users are allowed access unless specifically configured and assigned appropriate passwords.

aaa new-model

aaa authentication login RETAIL group tacacs+ local

aaa authentication enable default group tacacs+ enable

aaa authorization exec default group tacacs+ if-authenticated

aaa accounting update newinfo

aaa accounting exec default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

aaa accounting system default start-stop group tacacs+

aaa session-id common

tacacs-server host 192.168.42.131

tacacs-server directed-request

tacacs-server domain-stripping

tacacs-server key 7 <removed>

Local user accounts are configured in the event that the centralized authentication server cannot be reached. These accounts must be manually updated to maintain compliance requirements regarding password rotation and expiration as specified in PCI requirement 8.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

The following AAA authentication groups are assigned to the administrative interfaces where users connect:

ip http authentication aaa login-authentication RETAIL

line con 0

login authentication RETAIL

line vty 0 4

login authentication RETAIL

line vty 5 15

login authentication RETAIL

Requirement 8: Assign a Unique ID to Each Person with Computer Access

For Cisco routers to meet all of the user access restrictions specified in Requirement 8, an external authentication service such as Cisco Secure ACS must be implemented. Configure AAA services as shown above in Requirement 7.

The router is able to meet some of the requirements locally as identified below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco routers support the creation of local user accounts with unique ID's through the use of the username command. These can be used for local fallback user accounts.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

Local user accounts on Cisco routers require the setting of a password.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

In addition to the use of service password encryption to encrypt line interface passwords, the routers also support the use of AES encryption of pre-shared keys.

service password-encryption

password encryption aes

Use the username secret command to configure a username and MD5-encrypted user password when creating local fallback user accounts.

Cisco routers do not support an automated capability to perform this function at this time; the user account would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Prime LMS.

•PCI 8.5.9—Change user passwords at least every 90 days.

Cisco routers do not support an automated capability to perform this function at this time, user passwords would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Prime LMS.

Cisco routers do not support an automated capability to perform this function at this time; user account creation would have to follow this policy manually.

•PCI 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.

Cisco routers do not support an automated capability to perform this function at this time: user account creation would have to follow this policy manually.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

Cisco routers support the local ability to block logins after a specified number of failed login attempts with the following command:

login block-for 1800 attempts 6 within 65535

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Cisco routers support the local ability to block logins after a specified time after failed login attempts with the following command:

login block-for 1800 attempts 6 within 65535

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Cisco router management interfaces are configured as follows to meet this requirement:

ip http timeout-policy idle 900

line con 0

session-timeout 15 output

exec-timeout 15 0

line vty 0 4

session-timeout 15 output

exec-timeout 15 0

line vty 5 15

session-timeout 15 output

exec-timeout 15 0

Note If only thesession timeoutcommand is specified, the session timeout interval is based solely on detected input from the user.

If thesession timeoutcommand is specified with theoutputkeyword, the interval is based on both input and output traffic.You can specify a session timeout on each port.

Thesession-timeoutcommand behaves slightly differently on virtual (vty) terminals than on physical console, auxiliary (aux), and terminal (tty) lines. When a timeout occurs on a vty, the user session returns to the EXEC prompt. When a timeout occurs on physical lines, the user session is logged out and the line returned to the idle state.

You can use a combination of theexec-timeoutandsession-timeoutline configuration commands, set to approximately the same values, to get the same behavior from virtual lines that thesession-timeoutcommand causes on physical lines.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco routers are able to track and monitor all administrative user access and events such as port up/down, as well as device authentication events.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco routers track individual administrator actions through several mechanisms including AAA, logging, and system events by implementing the following configuration statements:

logging trap debugging

logging 192.168.42.124

logging buffered 50000

login on-failure log

login on-success log

archive

log config

logging enable

notify syslog contenttype plaintext

hidekeys

Cisco routers use NTP to update and synchronize their local clock facilities and meet sub-requirements 10.4 through 10.4.3.

•PCI 10.4.1—Critical systems have the correct and consistent time.

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP server was hosted at the data center site. Cisco routers use NTP to meet these requirements by implementing the following configuration statements:

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Switching

Switches—Branch

Cisco branch switches provide connectivity for wired endpoints and the ability to segment them onto their own sensitive scope networks. Virtual local area networks (VLANs) are used to put sensitive PCI applications and devices onto their own network and segregate them from devices that are on non-sensitive networks.

Branch switches are broken into three categories to provide scale and feature relevance;

•Compact switches—Quiet, small form factor switches that can be used on branch floors to extend the capability of the network to the register. These switches use power over Ethernet (PoE) pass-through, reducing expensive power and network cabling costs to new devices at the area of sale.

•Access switches—Stackable, expandable switches that can be used for wired device port density in the branch wiring closets. Access switches offer a variety of modular and fixed configuration options, and feature operational efficiency with StackPower, FlexStack, and NetFlow to increase visibility and control.

•Core/distribution—Highly redundant, powerful core switches allow for the most demanding business requirements of the branch. Modular functionality provides the ability to insert security technology as the needs of the business expand into new areas.

Although the enforcement of these boundaries would be handled by either a router or firewall, the switch provides the port density and access required to connect the payment devices from the branch floor.

Design Considerations

•The configurations of the Cisco Catalyst switches in the branch architectures are maintained within Cisco Prime LMS (alternatively CiscoWorks Resource Manager Essentials, a component of C-LMS, can be used as well).

•The use of VLANs on the Cisco Catalyst switch enables the organization to provide same-box wired access to its devices while maintaining segregated addressing schemes.

•Disable the HTTP server on the switch and enable the HTTP secure server.

•Cisco SmartPorts simplifies connecting the right device to the right VLAN.

•Network Admission Control (NAC) protects the network from rogue devices being connected.

•Cisco compact switches can easily add more securely managed ports where needed (for example, Cash Wrap and customer service desk), and some models can use PoE.

•Set the session and exec timeout commands to 15 minutes or less.

•Configure appropriate banner messages on login, incoming, and exec modes of the switch. The login banner warning should not reveal the identity of the company that owns or manages the switch. The incoming and executive banners should state that these areas are considered private and that unauthorized access will result in prosecution to the full extent of the law.

•Configure the primary login authentication of the switch to be directed to the Cisco Secure ACS. Individual user account profiles need to be created. Configure secondary or tertiary authentication local to the switch itself in the event of a WAN or Cisco Secure ACS failure.

•Use the no service password-recovery command in conjunction with the service password encryption command to prevent password theft by physical compromise of the switch.

PCI Assessment Detail—PCI Sub-Requirements Satisfied

Requirement 2: Do not use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

•PCI 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.

•PCI 2.2.2—Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Cisco switches can be configured to use secure protocols for all system functions. This includes SSH and HTTPS for remote management and SCP for file transfers. Insecure services can be disabled or blocked using configuration statements and access lists.

Cisco switches may have several services that are enabled by default that can be disabled.

no service pad

no service udp-small-servers

no service tcp-small-servers

no service finger

no ip http server

•PCI 2.3—Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access.

Cisco switches support administrative protocols with strong cryptography such as SSH version 2 and HTTPS with 3DES.

Note Strong cryptography—Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 (www.csrc.nist.gov/publications/) for more information.

! Before Crypto keys can be generated hostname and domain name must be entered

•PCI 6.1—Ensure that all system components and software are protected from known vulnerabilities by having 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.

The Cisco Product Security Incident Response Team site tracks and publishes information about any relevant exposures and vulnerabilities in Cisco switches. When vulnerabilities are announced, administrators can securely and easily download security patches and install them throughout the enterprise.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know

To meet all of the requirements listed below, the PCI solution uses the centralized user database in Active Directory, which is linked to via LDAP, RADIUS, and TACACS+ services. This server is located in the data center. Individual user IDs are assigned, and roles are based on group membership. This resource is used to address the following individual requirements:

•PCI 7.2.2—Assignment of privileges to individuals based on job classification and function

•PCI 7.2.3—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.

Cisco switches are configured to use a AAA model for user-based access. Users can be assigned to groups and based on privilege levels, have access to only the information they require for their job function. By default in Cisco switches, no users are allowed access unless specifically configured and assigned appropriate passwords. The following configuration statements create an authentication group called RETAIL, which is assigned to various interfaces. This group uses the TACACS+ protocol to communicate with the Cisco ACS server where individual user groups and roles are configured, limiting and logging access as appropriate.

Local individual user accounts are configured in the event that the centralized authentication server cannot be reached. These accounts must be manually updated to maintain compliance requirements regarding password rotation and expiration as specified in PCI Requirement 8.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

These AAA authentication groups are assigned to the administrative interfaces where users connect.

ip http authentication aaa login-authentication RETAIL

line con 0

login authentication RETAIL

line vty 0 4

login authentication RETAIL

line vty 5 15

login authentication RETAIL

Requirement 8: Assign a Unique ID to Each Person with Computer Access

For Cisco switches to meet all of the user access restrictions specified in Requirement 8, an external authentication service such as Cisco Secure ACS must be implemented. Configure AAA services as shown above in Requirement 7.

The switch is able to meet some of the requirements locally as identified below.

•PCI 8.1—Assign all users a unique ID before allowing them to access system components or cardholder data.

Cisco switches support the creation of local user accounts with unique IDs through the use of the username command. These can be used for local fallback user accounts.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

•PCI 8.2—In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:

–Something you know, such as a password or passphrase

–Something you have, such as a token device or smart card

–Something you are, such as a biometric

Local user accounts on Cisco switches require the setting of a password.

username bart privilege 15 secret 5 <removed>

username emc-ncm privilege 15 secret 5 <removed>

username bmcgloth privilege 15 secret 5 <removed>

username csmadmin privilege 15 secret 5 <removed>

•PCI 8.4—Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

In addition to the use of service password encryption to encrypt line interface passwords, the switches also support the use of AES encryption of pre-shared keys.

service password-encryption

password encryption aes

Use the username secret command to configure a username and MD5-encrypted user password when creating local fallback user accounts.

Cisco switches do not support an automated capability to perform this function at this time; the user account would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Prime LMS.

•PCI 8.5.9—Change user passwords at least every 90 days.

Cisco switches do not support an automated capability to perform this function at this time; user passwords would have to be manually reviewed in the device configurations every 90 days. This capability could be performed centrally through the device configurations management using Cisco Prime LMS.

Cisco switches do not support the ability to specify a minimum password length for local accounts. This would have to be met through a compensating control and corporate policy if a centralized authentication service with this capability could not be used.

Cisco switches do not support an automated capability to perform this function at this time; user account creation would have to follow this policy manually.

•PCI 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.

Cisco switches do not support an automated capability to perform this function at this time; user account creation would have to follow this policy manually.

•PCI 8.5.13—Limit repeated access attempts by locking out the user ID after not more than six attempts.

Cisco switches support the local ability to block logins after a specified number of failed login attempts with the following command:

login block-for 1800 attempts 6 within 65535

•PCI 8.5.14—Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Cisco switches support the local ability to block logins after a specified time after failed login attempts with the following command:

login block-for 1800 attempts 6 within 65535

•PCI 8.5.15—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Cisco switch management interfaces are configured as follows to meet this requirement:

ip http timeout-policy idle 900

line con 0

session-timeout 15 output

exec-timeout 15 0

line vty 0 4

session-timeout 15 output

exec-timeout 15 0

line vty 5 15

session-timeout 15 output

exec-timeout 15 0

Note If only thesession timeoutcommand is specified, the session timeout interval is based solely on detected input from the user. If thesession timeoutcommand is specified with theoutputkeyword, the interval is based on both input and output traffic. You can specify a session timeout on each port. Thesession-timeoutcommand behaves slightly differently on virtual (vty) terminals than on physical console, auxiliary (aux), and terminal (tty) lines. When a timeout occurs on a vty, the user session returns to the EXEC prompt. When a timeout occurs on physical lines, the user session is logged out and the line returned to the idle state. You can use a combination of theexec-timeoutandsession-timeoutline configuration commands, set to approximately the same values, to get the same behavior from virtual lines that thesession-timeoutcommand causes on physical lines.

In addition to disabling switch port interfaces for ports that are not in use, or in public areas, ports can also be placed in the guest network VLAN. This VLAN is treated as a public network and requires the appropriate PCI requirements for public networks to be met as well (for example, IPS/IDS and stateful firewall). Cisco switches support a feature called SmartPorts, whereby devices connected to these ports can be dynamically moved to an appropriate network VLAN from a blackhole VLAN or guest VLAN based on automatic identification macros. This allows ports to be active for periodic use when devices are attached (for example, media players for in-aisle promotions, and IP phones for customer service) when these network ports are in publicly accessible areas. The following configurations show how to enable SmartPorts for a variety of default or custom devices based on MAC addresses as opposed to 802.1x authentication methods.

Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

Cisco switches are able to track and monitor all administrative user access, events such as port up/down, as well as device authentication events when using 802.1x.

•PCI 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.

•PCI 10.2—Implement automated audit trails for all system components to reconstruct the following events:

–PCI 10.2.1—All individual accesses to cardholder data

–PCI 10.2.2—All actions taken by any individual with root or administrative privileges

–PCI 10.2.3—Access to all audit trails

–PCI 10.2.4—Invalid logical access attempts

–PCI 10.2.5—Use of identification and authentication mechanisms

–PCI 10.2.6—Initialization of the audit logs

–PCI 10.2.7—Creation and deletion of system-level objects

•PCI 10.3—Record at least the following audit trail entries for all system components for each event:

–PCI 10.3.1—User identification

–PCI 10.3.2—Type of event

–PCI 10.3.3—Date and time

–PCI 10.3.4—Success or failure indication

–PCI 10.3.5—Origination of event

–PCI 10.3.6—Identity or name of affected data, system component, or resource.

Cisco switches track individual administrator actions as identified in the requirement above (10.1, 10.2, and 10.3) through several mechanisms including AAA, logging, and system events by implementing the following configuration statements:

logging trap debugging

logging 192.168.42.124

logging buffered 50000

login on-failure log

login on-success log

archive

log config

logging enable

notify syslog contenttype plaintext

hidekeys

Cisco switches use NTP to update and synchronize their local clock facilities and meet the following requirements:

•PCI 10.4.1—Critical systems have the correct and consistent time.

•PCI 10.4.2—Time data is protected.

•PCI 10.4.3—Time settings are received from industry-accepted time sources.

NTP is used to synchronize clocks among network devices. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. All devices in the network used NTP to synchronize their clocks. The NTP server was hosted at the data center site. Cisco switches use NTP to meet these requirements by implementing the following configuration statements:

Note The Cisco Lab uses two NTP servers that are synchronized to external reference sources. All systems and devices in the lab are pointed to these two servers.

To meet all of the requirements listed below, the PCI solution uses a central logging repository located in the data center. RSA enVision collects syslog and SNMP information from all devices to ensure the integrity and correlation of events.

•PCI 10.5—Secure audit trails so they cannot be altered.

•PCI 10.5.1—Limit viewing of audit trails to those with a job-related need.

Cisco NAC capabilities can be configured on the branch switches to automate the verification of approved devices being attached to the network. In addition to configuring the NAC authentication services in the data center, add the following configurations to the switch and switch interface ports where NAC is to be used (for example, publicly accessible ports):

No compensating controls were required to satisfy any sub-requirements.

PCI Assessment Detail—PCI Sub-Requirements Failed

No sub-requirements were failed.

Cisco Catalyst Switches—Data Center

The Cisco Catalyst family of data center switches securely switches data; from servers to high speed trunks, maintaining the integrity of segmented scopes of compliance. They provide scalable inter-switch connectivity, high port density for wired endpoints, and the ability to segment them into sensitive scope networks. VLANs are used to put sensitive PCI applications and devices onto their own network and segregate them from devices that are on non-sensitive networks. Data center Cisco Catalyst switches are highly redundant, capable of delivering high performance switching, with feature options depending on the needs of the business.