Cisco PCI Best Practices

The information in this chapter applies to the solution architectures presented in Chapter 2, “Solution Framework,” such as doctor’s offices, clinics, hospitals, Internet edge, and data centers. Each solution component is presented with the following:

•General notes/best practices

This section provides guiding principles for each technology within a healthcare facility. The notes are Cisco recommendations but do not necessarily fall within the framework of PCI. Some notes exceed the PCI specification and are additional security features of that respective product.

•PCI sub-requirements satisfied by solution component

This section delineates which PCI sub-requirements were successfully audited and validated by the respective technology. Note that this result is directly correlated to the implementation built in the Cisco lab and presented in Chapter 4, “Implementing and Configuring the Solution.” The results of an audit may vary depending on the design implementation.

•PCI sub-requirements that require compensating controls

This section delineates which PCI sub-requirements needed additional compensating controls to successfully pass the PCI audit. These technologies required additional configuration or products to pass compliance. The results of an audit may vary depending on the design implementation.

For detailed configurations, refer to Chapter 4, “Implementing and Configuring the Solution.”

Network Systems

Cisco Integrated Services Router

The Cisco Integrated Services Router (ISR) consolidates data, network, and security into a single platform with local and centralized management services.

General Notes/Best Practices

•The security features of the ISR routers may be configured using the Cisco Security Manager. When configuring the ISR router with the Cisco Security Manager as the primary method, configuration changes using the command-line interface (CLI) should be avoided, since conflicts may arise when using them simultaneously.

•The general configuration of the ISR routers are maintained using the CiscoWorks Resource Manager Essentials (RMEs), a component of the CiscoWorks LAN Management Solution (C-LMS).

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

•Ensure that inspection rules are enabled on the ISR router so that the firewall maintains state (none are enabled by default).

•Access into a clinic/hospital router from the WAN needs to be protected by a firewall filter if the WAN technology is considered public.

•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, AUX, VTY, and line interfaces on the router.

•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 Access Control Server (CS-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 CS-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.

PCI Sub-Requirements Satisfied by Solution Component (Router)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

•PCI 1.2—Build a firewall configuration that denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment.

Each of the routers in the PCI Solution for Healthcare uses firewall feature set capabilities to satisfy this requirement.

The solution allowed the following business-related communication:

•Management protocols for Cisco Security Manager (CS-M) and CiscoWorks (C-LMS)

•Monitoring, analysis, and response system (CS-MARS)

•Authentication, authorization, and accounting (AAA) to access control server (CS-ACS) via TACACS

•Internet Control Message Protocol (ICMP) for network troubleshooting

•Network Time Protocol (NTP) for time stamp synchronization

•System logging access for network events

•Simple Network Management Protocol (SNMP)

•Secure Socket Layer (SSL)

•High availability via Hot Standby Routing Protocol (HSRP)

•Dynamic Host Configuration Protocol (DHCP)

•Everything else was denied and logged

See Appendix C, “Application Protocols,” for a complete listing of the communications used in this solution.

The following is a sample configuration from the hospital architecture:

RLRG-1#

ip access-list extended CSM_FW_ACL_GigabitEthernet0/0.1000

remark Allow CSM-Server to access device through the Serial (external) Interface

permit icmp host 192.168.42.133 host 10.10.62.1 log

permit tcp host 192.168.42.133 host 10.10.62.1 eq 22 443 log

remark ---- permit ntp ----

permit udp any host 192.168.62.161 eq ntp

permit udp any host 192.168.62.162 eq ntp

permit udp any host 192.168.42.130 eq ntp

remark ---- Send logs to their mgmt utilities through the mgmt VLAN ----

permit tcp any host 192.168.42.134 eq 69 log

permit udp any host 192.168.42.134 eq tftp snmp snmptrap syslog log

remark ---- Ciscoworks so Managed Devices ----

permit tcp host 192.168.42.134 any eq 22 telnet www 443 log

permit udp host 192.168.42.134 any eq snmp snmptrap syslog log

remark ---- System messages to MARS ----

permit tcp any host 192.168.42.121 eq 2055 log

permit udp any host 192.168.42.121 eq snmp syslog log

remark ---- Allow network devices to use the ACS server ----

permit tcp any host 192.168.42.131 eq tacacs log

permit udp any host 192.168.42.131 eq 1812 log

remark ---- ping to Datacenter ----

permit icmp any 192.168.42.0 0.0.0.255 log

remark ---- HSRP health information ----

permit udp any host 224.0.0.2 eq 1985 log

remark ---- Ping Gateway ----

permit icmp 10.10.63.0 0.0.0.255 10.10.63.0 0.0.0.255 log

remark ---- Allow DHCP to work ----

permit udp any host 255.255.255.255 eq bootps log

permit udp any host 192.168.42.130 eq bootps log

remark Drop anything not explicitly allowed

deny   ip any any log

interface GigabitEthernet0/0.1000

ip access-group CSM_FW_ACL_GigabitEthernet0/0.1000 in

•PCI 1.3.3—Implementing stateful inspection, also known as dynamic packet filtering (that is, only “established” connections are allowed into the network).

The stateful inspection in the solution is the Cisco-recommended configuration. The statements inspect the protocol for anomalies on their default ports and maintain the established dynamic connection table for each session.

The following is a sample configuration:

RLRG-1#

ip inspect name CSM_INSPECT_1 http alert on audit-trail on

ip inspect name CSM_INSPECT_1 dns alert on audit-trail on

ip inspect name CSM_INSPECT_1 radius alert on audit-trail on

ip inspect name CSM_INSPECT_1 tacacs alert on audit-trail on

ip inspect name CSM_INSPECT_1 ssh alert on audit-trail on

ip inspect name CSM_INSPECT_1 ftp alert on audit-trail on

ip inspect name CSM_INSPECT_1 ldap alert on audit-trail on

ip inspect name CSM_INSPECT_1 snmp alert on audit-trail on

ip inspect name CSM_INSPECT_1 icmp alert on audit-trail on

ip inspect name CSM_INSPECT_1 tcp alert on audit-trail on

ip inspect name CSM_INSPECT_1 udp alert on audit-trail on

interface GigabitEthernet0/0.1000

ip inspect CSM_INSPECT_1 in

•PCI 1.3.5—Restricting outbound traffic to that which is necessary for the cardholder data environment.

The routers are configured to filter and inspect all traffic inbound from each network segment. Through extensive interview and discussion with the QSA, filtering all inbound network traffic to the router was determined to be an acceptable implementation. (See Figure 3-1.)

Figure 3-1 Restricting Outbound Traffic

The following is a sample configuration:

RLRG-1#

interface GigabitEthernet0/0.11

description POINT OF SALE NETWORK

ip access-group CSM_FW_ACL_GigabitEthernet0/0.11 in

ip inspect CSM_INSPECT_1 in

•PCI 1.3.7—Denying all other inbound and outbound traffic not specifically allowed.

Deny and log all traffic not explicitly allowed within each firewall rule set. Logging all denied traffic may cause a significant performance impact depending on the environment.

The following is a sample configuration:

RLRG-1#

ip access-list extended CSM_FW_ACL_GigabitEthernet0/0.1000

< deleted for brevity>

remark Drop anything not explicitly allowed

deny   ip any any log

•PCI 1.3.8 —Installing perimeter firewalls between any wireless networks and the cardholder data environment, and configuring these firewalls to deny any traffic from the wireless environment or from controlling any traffic (if such traffic is necessary for business purposes).

The point-of-sale network and the wireless network is segmented by VLANs and secured by the integrated Cisco IOS firewall in the router. (See Figure 3-1.)

The following is a sample configuration:

RLRG-1#

interface GigabitEthernet0/0.14

description WIRELESS

<excerpted for brevity>

ip address 10.10.51.2 255.255.255.0

ip access-group CSM_FW_ACL_GigabitEthernet0/0.14 in

interface GigabitEthernet0/0.11

description POINT OF SALE

<excerpted for brevity>

ip address 10.10.48.2 255.255.255.0

ip access-group CSM_FW_ACL_GigabitEthernet0/0.11 in

ip access-list extended CSM_FW_ACL_GigabitEthernet0/0.14

remark Allow CSM-Server to access device through the Serial (external) Interface

permit icmp host 192.168.42.133 host 10.10.62.1 log

permit tcp host 192.168.42.133 host 10.10.62.1 eq 22 443 log

remark ---- permit ntp ----

permit udp any host 192.168.62.161 eq ntp

permit udp any host 192.168.62.162 eq ntp

permit udp any host 192.168.42.130 eq ntp

remark ---- E-mail ----

permit tcp any host 192.168.42.140 eq smtp www 443 log

remark ---- HSRP health information ----

permit udp any host 224.0.0.2 eq 1985 log

remark ---- Ping Gateway ----

permit icmp 10.10.51.0 0.0.0.255 10.10.51.0 0.0.0.255 log

remark ---- Clients to CSA Manager ----

permit tcp any host 192.168.42.132 eq www 443 5401 5402 log

remark ---- Required for devices to perform windows updates ----

permit tcp any host 192.168.42.150 eq www 443 log

remark ---- Allow DHCP to work ----

permit udp any host 255.255.255.255 eq bootps log

permit udp any host 192.168.42.130 eq bootps log

remark Drop anything not explicitly allowed

deny   ip any any log

ip access-list extended CSM_FW_ACL_GigabitEthernet0/0.11

remark Allow CSM-Server to access device through the Serial (external) Interface

permit icmp host 192.168.42.133 host 10.10.62.1 log

permit tcp host 192.168.42.133 host 10.10.62.1 eq 22 443 log

remark ---- permit ntp ----

permit udp any host 192.168.62.161 eq ntp

permit udp any host 192.168.62.162 eq ntp

permit udp any host 192.168.42.130 eq ntp

remark ---- E-mail ----

permit tcp any host 192.168.42.140 eq smtp www 443 log

remark ---- HSRP health information ----

permit udp any host 224.0.0.2 eq 1985 log

remark ---- Ping Gateway ----

permit icmp 10.10.48.0 0.0.0.255 10.10.48.0 0.0.0.255 log

remark ---- Clients to ActiveDirectory Server ----

permit icmp any host 192.168.42.130 log

permit tcp any host 192.168.42.130 range 1024 65535 log

permit tcp any host 192.168.42.130 eq www 88 123 135 139 389 443 445 1028 log

permit udp any host 192.168.42.130 eq domain bootps 88 ntp 135 389 log

remark ---- POS Devices talking to Wincor ----

permit icmp any host 192.168.52.98 log

permit tcp any host 192.168.52.98 eq www 139 443 445 1433 3389 4064 log

permit udp any host 192.168.52.98 eq netbios-ns 445 1433 log

remark ---- POS to MSRMS Server ----

permit tcp any host 192.168.52.99 eq www 443 1433 1434 log

permit udp any host 192.168.52.99 eq 1433 1434 log

remark ---- Clients to CSA Manager ----

permit tcp any host 192.168.42.132 eq www 443 5401 5402 log

remark ---- Required for devices to perform windows updates ----

permit tcp any host 192.168.42.150 eq www 443 log

remark ---- Allow DHCP to work ----

permit udp any host 255.255.255.255 eq bootps log

permit udp any host 192.168.42.130 eq bootps log

remark Drop anything not explicitly allowed

deny   ip any any log

•PCI 1.5—Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as Port Address Translation (PAT) or Network Address Translation (NAT).

The healthcare facilities in this solution are configured using private addressing that are not routable across the Internet. NAT or PAT must be used in the data center to convert these addresses into public available address space.

The following is an example of a hospital addressing plan:

10.10.48.0 255.255.240.0 Summarized addressing block

10.10.48.0  /24- VLAN11 (POS)

10.10.49.0  /24- VLAN12 (Data)

10.10.50.0  /24- VLAN13 (Voice)

10.10.51.0  /24- VLAN14 (Wireless)

10.10.52.0  /24- VLAN15 (Wireless POS)

10.10.53.0  /24- VLAN16 (Partner)

10.10.54.0  /24- VLAN17 (Wireless Guest)

10.10.55.0  /24- VLAN18 (LWAP Control)

10.10.56.0 ~10.10.61.0 - (Future)

10.10.62.0  /24- Other-    (Misc)

10.10.62.1  /32- LRG-1 Loop 0

10.10.62.2  /32- LRG-2 Loop 0

10.10.62.16 /30- LRG-1 Serial 0

10.10.62.20 /30- LRG-2 Serial 0

10.10.62.24 /30- VLAN101 (Router Link)

10.10.62.28 /30- VLAN102 (Router Link

10.10.63.0   /24- VLAN1000(Management)

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts.

See Appendix E, “Device Configurations.”

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function)

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

•PCI 2.2.4—Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

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

Disable services such as pad, finger, and small servers. Depending on the Cisco IOS release, these will be enabled or disabled by default and may not be displayed in the running configuration.

Only encrypted management communication was enabled. All other services were disabled.

The following is a sample configuration:

no service pad

no ip finger

no ip http server

ip http secure-server

line vty 0 4

transport input ssh

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements for Requirements 7 and 8:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Compliance of the sub-requirements in this section was achieved within the solution by implementing the Cisco Secure Access Control Server (CS-ACS) and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the router. These fallback accounts should be rotated based on a QSA-recommended policy.

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

Configure the session-timeout and exec-timeout commands to 15 minutes or less on the console, AUX, VTY, and line interfaces on the router.

The following is a sample configuration:

line con 0

session-timeout 15  output

exec-timeout 15 0

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

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS for Authentication, Authorization, and Accounting (AAA) services.

The Cisco ISR router was not configured or audited for AAA features without the use of ACS.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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 following is a sample configuration:

aaa new-model

aaa authentication login RETAIL group tacacs+ local

aaa authentication login RLOCAL group tacacs+ local

aaa authentication enable default enable group tacacs+

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

•PCI 10.4—Obtain and review the process for acquiring and distributing the correct time within the organization, as well as the time-related system-parameter settings for a sample of system components, critical servers, and wireless access points. Verify the following is included in the process and implemented:

•PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization

•PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. [Two or three central time servers within the organization receive external time signals [directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT)], peer with each other to keep accurate time, and share the time with other internal servers.]

•PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version

•PCI 10.4.d—Verify that specific external hosts are designated from which the time servers will accept NTP time updates (to prevent an attacker from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the NTP service (to prevent unauthorized use of internal time servers). For more information, see http://www.ntp.org.

The following is a sample configuration:

RLRG-1#

ntp clock-period 17179470

ntp source Loopback0

ntp server 192.168.62.162

ntp server 192.168.62.161 prefer

Requirement 11: Regularly Test Security Systems and Processes

•PCI 11.4.a—Observe the use of network intrusion detection systems and/or intrusion prevention systems on the network. Verify that all critical network traffic in the cardholder data environment is monitored.

•PCI 11.4.c—Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection.

The sub-requirements in this section are satisfied through the IPS feature set of the Cisco ISR router combined with monitoring and alerting capability of CS-MARS.

The Cisco Security Manager (C-SM) is used to configure and deploy the IDS/IPS event definitions and signatures to the Cisco ISR routers.

The following is a sample configuration:

ip ips sdf location

https://192.168.42.133:443/ids-config/servlet/com.cisco.nm.mdc.ids.config.iosids.servlet.S

DFServlet/11/sdf-complete.xml

ip ips notify SDEE

ip ips name sdm_ips_rule

PCI Sub-Requirements that Require Compensating Controls (Router)

The Cisco ISR routers within this solution complied with all relevant PCI sub-requirements and did not require any compensating controls.

Mid-Range Routers (WAN Aggregation)/Edge Routers (Internet Edge)

General Notes/Best Practices

•Configuration was done manually using the Command Line Interface (CLI) of the routers . The CiscoWorks Network Compliance Manager (NCM) was used for backing-up configurations and for monitoring configuration changes for non-compliance.

•Firewall rule sets must adhere to a “least amount of access necessary” policy. Where possible, 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.

•The perimeter firewall between the data center was provided by the Adaptive Security Appliance. As a result, the Cisco 7206VXR 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, AUX, VTY, and line interfaces on the router.

•Configure the primary login authentication of the router to be directed to the CS-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 CS-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.

•Enable anti-spoofing on all interfaces.

•For the Internet edge routers, use the following access-list on the interface that is facing the Internet. This access-list explicitly filters traffic destined for infrastructure address space. Deployment of edge infrastructure access-lists requires that a clear definition of the infrastructure space and the required/authorized protocols that access this space. The access-list is applied at the ingress to the network on all externally facing connections, such as peering connections, customer connections, and so forth.

The following is a sample configuration:

access-list 110 remark Deny special-use address sources

access-list 110 remark Refer to RFC 3330 for additional special use addresses

access-list 110 deny   ip host 0.0.0.0 any

access-list 110 deny   ip 127.0.0.0 0.255.255.255 any

access-list 110 deny   ip 192.0.2.0 0.0.0.255 any

access-list 110 deny   ip 224.0.0.0 31.255.255.255 any

access-list 110 remark Filter RFC 1918 space

access-list 110 deny   ip 10.0.0.0 0.255.255.255 any log

access-list 110 deny   ip 172.16.0.0 0.15.255.255 any log

access-list 110 deny   ip 192.168.0.0 0.0.255.255 any log

access-list 110 remark deny your space as source from entering your AS.

access-list 110 remark To be deployed only at the AS edge.

access-list 110 deny ip <YOUR_CIDR_BLOCK> any

access-list 110 permit tcp any host <public web server> eq www log

access-list 110 permit tcp any host <public web server> eq 443 log

access-list 110 remark Permit legitimate business traffic.

access-list 110 permit tcp any <Internet-routable subnet> established

access-list 110 deny ip any any log

Note The log keyword can be used to provide additional detail about source and destinations for a given protocol. Although this keyword provides valuable insight into the details of access-lists 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 MPLS network. At the writing of this document, MPLS is considered a private network and secure tunneling across the WAN is not required. However, for best practices, Cisco recommends Virtual Private Network (VPN) tunneling be implemented. For further information on implementing an IPSec VPN, refer to the IPSec VPN Direct Encapsulation Design Guide at the following URL:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a0080739e7c.pdf.

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts. See Appendix E, “Device Configurations.”

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function).

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

•PCI 2.2.4—Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

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

Disable services such as pad, finger, and small servers. Depending on the Cisco IOS release, these will be enabled or disabled by default and may not be displayed in the running configuration.

Only encrypted management communication was enabled. All other services were disabled.

The following is a sample configuration:

no service pad

no ip finger

no ip http server

ip http secure-server

line vty 0 4

transport input ssh

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements for Requirements 7 and 8:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords.

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Compliance of the sub-requirements in this section is achieved within the solution by implementing the CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the router. These fallback accounts should be rotated based on a QSA-recommended policy.

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

Configure the session-timeout and exec-timeout commands to 15 minutes or less on the console, AUX, VTY, and line interfaces on the router.

Following is a sample configuration:

line con 0

session-timeout 15  output

exec-timeout 15 0

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

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS for Authentication, Authorization and Accounting (AAA) services.

The Cisco ISR router was not configured or audited for AAA features without the use of CS-ACS.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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

Following is a sample configuration:

aaa new-model

aaa authentication login RETAIL group tacacs+ local

aaa authentication login RLOCAL group tacacs+ local

aaa authentication enable default enable group tacacs+

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

•PCI 10.4—Obtain and review the process for acquiring and distributing the correct time within the organization, as well as the time-related system-parameter settings for a sample of system components, critical servers, and wireless access points. Verifying the following is included in the process and implemented:

–PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals. Time signals are sent directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT). The time servers peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

–PCI 10.4.d—Verify that specific external hosts are designated from which the time servers will accept NTP time updates (to prevent an attacker from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the NTP service (to prevent unauthorized use of internal time servers). For more information, see http://www.ntp.org.

Following is a sample configuration:

RWAN-10#

ntp clock-period 17179470

ntp source Loopback0

ntp server 192.168.62.162

ntp server 192.168.62.161 prefer

Cisco Catalyst Ethernet Switch and Network Switch Module

The Cisco Catalyst Ethernet switch provides connectivity for the IP endpoints to the routed networks and WAN services.

General Notes/Best Practices

•The general configuration of the Cisco Catalyst switches and Network Switch Module are maintained using the CiscoWorks Resource Manager Essentials (a component of C-LMS).

•The use of VLANs on the Cisco Catalyst switch allows the healthcare provider to maintain 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.

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

•Change default passwords and community strings to appropriate complexity.

•The connection from the hospital may be a direct Ethernet connection (not WAN) to the Catalyst switch. If perimeter security is a concern, an IOS FW, FWSM, or an ASA can be deployed for firewall functionality. See IOS FW, FWSM, and ASA sections of this chapter for details on best practices.

PCI Sub-Requirements Satisfied by Solution Component (Switches)

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts.

See Appendix E, “Device Configurations.”

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function).

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

•PCI 2.2.4—Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

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

Disable services such as pad, finger, and small servers. Depending on the Cisco IOS release, these may be enabled or disabled by default and may not be displayed in the running configuration.

Only encrypted management communication was enabled. All other services were disabled.

The following is a sample configuration:

no service pad

no ip finger

no ip http server

ip http secure-server

line vty 0 4

transport input ssh

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
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 CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the router. These fallback accounts should be rotated based on a QSA-recommended policy.

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty 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-enter the password to re-activate the terminal.

Configure the session-timeout and exec-timeout commands to 15 minutes or less on the console and VTY interfaces on the switch.

The following is a sample configuration:

line con 0

session-timeout 15  output

exec-timeout 15 0

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

Compliance of these sub-requirements was achieved within the solution by implementing the CS-ACS for Authentication, Authorization and Accounting (AAA) services.

The Catalyst Switches were not configured or audited for AAA features without the use of CS-ACS.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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 following is a sample configuration:

aaa new-model

aaa authentication login RETAIL group tacacs+ local

aaa authentication login RLOCAL group tacacs+ local

aaa authentication enable default enable group tacacs+

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+

Verify the following is included in the process and implemented:

•PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization.

•PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT), peer with each other to keep accurate time, and share the time with other internal servers.

•PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

The following is a sample configuration:

SMED-2#

ntp clock-period 17179470

ntp source Vlan1000

ntp server 192.168.62.162

ntp server 192.168.62.161 prefer

PCI Sub-Requirements that Require Compensating Controls (Switches)

The Cisco Catalyst switches within this solution did not require any compensating controls to pass respective PCI sub-requirements.

Cisco Firewall Services Module (FWSM)

The Cisco FWSM is an integrated module installed inside a Cisco Catalyst 6500 Series Switch or Cisco 7600 Internet Router. The FWSM allows any port on the Cisco Catalyst switch to operate as a firewall port and integrates firewall security inside the network infrastructure.

General Notes/Best Practices

•Firewall 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

•For Internet edge, disable ICMP permit on the outside interface of FWSM. If users need to access servers in the DMZ segment then make sure that external users can reach the servers using very specific protocol and ports.

•Configure the ip verify reverse path command on all interfaces to provide anti-spoofing functionality.

•Configure the console timeout commands to 15 minutes or less on the console of the FWSM.

•Configure appropriate banner messages on login, incoming, and exec modes of the FWSM The login banner warning should not reveal the identity of the company that owns or manages the FWSM. 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 FWSM to be directed to the CS-ACS. Individual user account profiles need to be created. Configure secondary or tertiary authentication local to the FWSM itself in the event of connectivity or CS-ACS failure.

•Change default passwords and community strings to appropriate complexity.

•Allow only SSHv2 (and not Telnet or SSHv1) connection from network management station to Cisco FWSM.

PCI Sub-Requirements Satisfied by Solution Component (Cisco FWSM)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

•PCI 1.2—Build a firewall configuration that denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment.

The Cisco FWSM in the Internet edge architecture is used to meet the PCI requirement.

The solution allowed the following business-related communication:

•Monitoring, analysis, and response system (CS-MARS).

•CiscoWorks Network Compliance Manager (C-NCM).

•Authentication, authorization, and accounting to CS-ACS via TACACS.

•Network Time Protocol (NTP) for time stamp synchronization.

•System logging access for network events.

•Simple Network Management Protocol (SNMP).

•All other traffic is implicitly denied.

The following is a sample configuration of an outside interface (facing the Internet) of an Internet edge Cisco FWSM.

FWSM

access-list ECOM_OUT remark ---- permit ntp ----

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.62.161 eq ntp

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.62.162 eq ntp

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.62.130 eq ntp

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.62.161 eq ntp

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.62.162 eq ntp

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.62.130 eq ntp

access-list ECOM_OUT remark ---- System messages to MARS ----

access-list ECOM_OUT extended permit tcp host 192.168.21.4 host 192.168.42.121 eq 2055 log

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.42.121 eq snmp log

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.42.121 eq syslog log

access-list ECOM_OUT extended permit tcp host 192.168.21.5 host 192.168.42.121 eq 2055 log

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.42.121 eq snmp log

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.42.121 eq syslog log

access-list ECOM_OUT remark ---- Allow network devices to use the ACS server ----

access-list ECOM_OUT extended permit tcp host 192.168.21.4 host 192.168.42.131 eq tacacs log

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.42.131 eq 1812 log

access-list ECOM_OUT extended permit tcp host 192.168.21.5 host 192.168.42.131 eq tacacs log

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.42.131 eq 1812 log

access-list ECOM_OUT remark ---- Permit snmp to Network Compliance Manager ----

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.42.118 eq snmp log

access-list ECOM_OUT extended permit udp host 192.168.21.4 host 192.168.42.118 eq syslog log

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.42.118 eq snmp log

access-list ECOM_OUT extended permit udp host 192.168.21.5 host 192.168.42.118 eq syslog log

•PCI 1.3.3—Implementing stateful inspection, also known as dynamic packet filtering (that is, only “established” connections are allowed into the network).

The following is a sample configuration:

FWSM1#

FWSM1# sh run | b policy

policy-map global_policy

class inspection_default

 inspect dns maximum-length 512

 inspect netbios

 inspect smtp

 inspect icmp

 inspect http

service-policy global_policy global

prompt hostname context

Cryptochecksum:51ff3afd13deafb682c969655a835b71

: end

!!

•PCI 1.3.7—Denying all other inbound and outbound traffic not specifically allowed.

In the Cisco FWSM, every access-list ends with an implicit deny ip any any.

Note A new entry in an access list is always appended to the bottom of the access-list. Since access-list are evaluated in sequential order, the correct order of the access-list entry is important.

The PCI solution in the lab is configured to use private IP addresses that are not routable across the Internet. NAT is used to convert these addresses into public available address space. To simulate a real environment, we used IP address 192.168.80.25 as public IP address for testing purpose.

FWSM>

nat-control

global (ECOM_OUTSIDE) 1 interface

nat (ECOM_DMZ) 1 0.0.0.0 0.0.0.0

nat (DMZ_MGMT) 1 192.168.21.16 255.255.255.240

static (ECOM_DMZ,ECOM_OUTSIDE) 192.168.80.25 192.168.20.1 netmask 255.255.255.255

FWSM>

The following is an example of a hospital addressing plan:

10.10.48.0 255.255.240.0 Summarized addressing block

10.10.48.0  /24- VLAN11 (POS)

10.10.49.0  /24- VLAN12 (Data)

10.10.50.0  /24- VLAN13 (Voice)

10.10.51.0  /24- VLAN14 (Wireless)

10.10.52.0  /24- VLAN15 (Wireless POS)

10.10.53.0  /24- VLAN16 (Partner)

10.10.54.0  /24- VLAN17 (Wireless Guest)

10.10.55.0  /24- VLAN18 (LWAP Control)

10.10.56.0 ~10.10.61.0 - (Future)

10.10.62.0  /24- Other-    (Misc)

10.10.62.1  /32- LRG-1 Loop 0

10.10.62.2  /32- LRG-2 Loop 0

10.10.62.16 /30- LRG-1 Serial 0

10.10.62.20 /30- LRG-2 Serial 0

10.10.62.24 /30- VLAN101 (Router Link)

10.10.62.28 /30- VLAN102 (Router Link

10.10.63.0   /24- VLAN1000(Management)

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts.

See Appendix E, “Device Configurations.”

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 as defined, for example, by SysAdmin Audit Network Security Network (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS).

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function)

•PCI 2.2.3.b—Verify that common security parameter settings are included in the system configuration standards

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

•PCI 2.2.4—Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

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

Disable unwanted services on the Cisco FWSM module.

Only encrypted management communication was enabled. All other services were disabled.

The following is a sample configuration:

no ftp mode passive

ssh 192.168.42.131 255.255.255.255 inside

ssh 192.168.42.121 255.255.255.255 inside

ssh 192.168.42.118 255.255.255.255 inside

ssh timeout 5

ssh version 2

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements for Requirements 7 and 8:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the Cisco FWSM. These fallback accounts should be rotated based on a QSA-recommended policy.

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

Configure the console timeout with the following command:

console timeout 15

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

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS for AAA services.

The FWSM was not configured or audited for AAA features without the use of CS-ACS.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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 following is a sample configuration:

aaa-server RETAIL protocol tacacs+

aaa-server RETAIL host 192.168.42.131

key <removed>

aaa authentication ssh console RETAIL LOCAL

aaa authorization include ssh inside 192.168.11.2 255.255.255.255 192.168.42.131
255.255.255.255 RETAIL

aaa accounting command RETAIL

•PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization

•PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version

The FWSM does not have a standalone clock, and it does not support NTP. It relies exclusively on the switch clock for time.

PCI Sub-Requirements that Require Compensating Controls (FWSM)

The Cisco FWSM within this solution complied with all relevant PCI sub-requirements and did not require any compensating controls.

Cisco Intrusion Detection System Services Module (IDSM2)

The Cisco Catalyst 6500 Series Intrusion Detection System Services Module 2 (IDSM2) is an important intrusion prevention system (IPS) solution that protects switched environments by integrating full-featured IPS functions directly into the network infrastructure. The integration of the IDSM2 inside a Cisco Catalyst 6500 allows the IDSM2 to monitor traffic directly off the switch backplane.

General Notes/Best Practices

•Configure IDSM2 to lock accounts after a specified number of failed attempts.

•Limit secure management of the IDSM2 only from specific hosts.

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

•Change default passwords and community strings to appropriate complexity.

PCI Sub-Requirements Satisfied by Solution Component (Cisco IDSM2)

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

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

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

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

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

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

•PCI 8.5.11—Use passwords containing both numeric and alphabetic characters

•Currently, in IDSM2, there are no current password character class requirements. The sensor uses the PAM cracklib to ensure a harder password.

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

Account lockout is disabled by default on the IDSM2. Account lockout is enabled to a configurable number of failed login attempts starting with 1:

! ------------------------------

service authentication

attemptLimit 4

exit

! ------------------------------

•PCI 8.5.14—Set the lockout duration to thirty minutes or until administrator enables the user ID

•Lockout duration is not configurable in IDSM2. The user account is locked until an administrator resets it by resetting the user’s password.

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

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

•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.4.a—Verify that NTP or similar technology is used for time synchronization.

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals (directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT)), peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

The following is sample configuration:

QSA recommends that the IDSM2 have NTP configuration independent of the parent router
or switch.

IDSM2(config-hos)# ntp-option ?

disabled     Disable synchronization of the sensor's clock to an NTP time

server.  Appliance sensors will use their internal hardware clock. Sensor modules will use the
clock of the module's parent router or switch.

enabled      Enable synchronization of  the sensor's clock to a NTP (Network Time Protocol) time
server.

Requirement 11: Regularly Test Security Systems and Processes

•PCI 11.4.c—Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection

intrusion-detection module 2 management-port access-vlan 97

intrusion-detection module 2 data-port 1 autostate include

monitor session 10 source vlan 82 , 97

The sub-requirements in this section are satisfied through the IDSM2 configuration on a Catalyst switch combined with monitoring and alerting capability of CS-MARS and Cisco IPS Device Manager (IDM). The IDSM2 is configured in the promiscuous mode in the lab to monitor VLAN 82 (DMZ) and VLAN 97 (inside interface of FWSM).

The Cisco Security Manager is used to update signatures on the IDSM2.

PCI Sub-Requirements that Require Compensating Controls (Cisco IDSM2)

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

QSA recommends a combination of documented password policies, manual audit procedures to ensure passwords are being changed every 90 days, and internal firewall segmentation of these components within the data center, would be reasonable compensating controls for password setting limitations within these applications.

•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.15—If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal

QSA recommends screensaver timeouts can be used as a compensating control, when idle session timeouts are not available or impact application/business operations (e.g. backup jobs).

Cisco Application Control Engine (ACE) Module

The Cisco ACE Module is primarily used for maximizing the availability, acceleration and protection of data center and Internet edge applications. The Cisco ACE Module is not documented in the Auditor’s Report of Compliance (RoC) as it was mainly used to load balance ACE XML Gateway appliances. Since the ACE Module is a networking device, it follows the same recommendations as other Cisco networking devices in the audit.

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

PCI Sub-Requirements Satisfied by Solution Component (ACE)

•PCI 1.3.7—Denying all other inbound and outbound traffic not specifically allowed.

Deny all traffic that is not explicitly allowed.

The following is a sample configuration:

ACE2/PCI#

access-list allow2server line 20 extended permit ip any host 192.168.20.3

access-list allow2server line 21 extended permit tcp host 192.168.20.44 host
192.168.42.130 eq ldap

access-list allow2server line 22 extended deny ip any any

access-list in2out line 10 extended permit ip host 192.168.20.3 any

access-list in2out line 15 extended deny ip any any

access-list out2in line 10 extended permit tcp any host 192.168.20.1 eq www

access-list out2in line 15 extended deny ip any any

ACE2/PCI#

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts.

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function)

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

•PCI 2.2.4—Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

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

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements for Requirements 7 and 8:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the ACE. These fallback accounts should be rotated based on a QSA-recommended policy.

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

Configure the terminal session-timeout and login timeout commands to 15 minutes or less in Cisco ACE.

Following is a sample configuration:

ACE2/PCI# terminal session-timeout 15

ACE2/PCI#

ACE2/PCI# show terminal

TTY: /dev/pts/0 Type: "vt100"

Length: 24 lines, Width: 80 columns

Session Timeout: 15 minutes

ACE2/PCI#

ACE2/PCI#

login timeout 15

Note The login timeout command setting overrides the terminal session-timeout command setting.

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

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS for AAA services.

The Cisco ACE module was not configured or audited for AAA features without the use of CS-ACS.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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

ACE2/PCI#

tacacs-server host 192.168.42.131 key 7 <removed>

aaa group server tacacs+ RETAIL

 server 192.168.42.131

aaa authentication login default group RETAIL local

aaa authentication login console group RETAIL local

aaa accounting default group RETAIL local

Application Control Engine (ACE) XML Gateway

The ACE XML Gateway delivers an integrated XML firewall. It ensures that XML messages securely and efficiently reach their intended targets. It provides the critical protection needed at each service perimeter-between un-trusted and trusted zones with a comprehensive XML threat defense system.

General Notes/Best Practices

•While configuring a listening port on Cisco ACE XML Gateway, avoid using ports reserved for non-service traffic. These include ports in the range of 8200 through 8299 or 514, which are used for administrative traffic between system components.

•It is highly recommended to change the default SNMP string reactivity. The default SNMP on the Cisco ACE XML Gateway may be changed with the following commands:

–[root@AXG1 root]# vi /etc/snmp/snmp.conf

–[root@AXG1 root]# vi /etc/snmp/snmpd.conf

–# REACTIVITY 2.0-1

–com2sec theUser default reactivity

PCI Sub-Requirements Satisfied by Solution Component (Cisco ACE XML Gateway)

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

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function)

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

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

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.5— Develop all web applications based on secure coding guidelines, such as the Open Web Application Security Project Guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:

–PCI 6.5.1—Unvalidated input

–PCI 6.5.4 —Cross-site scripting (XSS) attacks

–PCI 6.5.5—Buffer overflows

–PCI 6.5.6—Injection flaws (for example, structured query language (SQL) injection)

–PCI 6.5.7—Improper error handling

–PCI 6.5.9—Denial of service

–PCI 6.5.10—Insecure configuration management

For detailed configurations, refer to Appendix D, “Detailed Implementation and Configuration Steps.”.

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

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

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

•PCI 8.1—Identify all users with a unique user name before allowing them to access system components or cardholder data

This requirement was achieved using LDAP connecting to Microsoft Active Directory. Users are authenticated using LDAP as shown in Figure 3-2.

Figure 3-2 User Authentication

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

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty 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-enter the password to re-activate the terminal

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

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

•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 Sub-Requirements that Require Compensating Controls (Cisco ACE XML Gateway)

The Cisco ACE XML Gateway within this solution complies with all relevant PCI sub-requirements and did not require any compensating controls.

Wireless Access Points and Controllers

General Notes/ Best Practices

The Wireless Control System (WCS) server version used during this solution audit lacks the capability for external authentication. However, version 4.1 and later supports external authentication via TACACS or RADIUS. For versions prior to 4.1, Cisco recommends a combination of documented password policies, manual audit procedures, and firewall segmentation for WCS servers within the data center.

•Configure unique SSID

•Disable broadcast of the SSID

•Change default passwords and community strings

•Enable WPA technology

•Configure all wired and wireless endpoints to prompt for user identification and password. Do not statically configure these properties as healthcare wireless units such as inventory scanners may not be physically secure.

PCI Sub-Requirements Satisfied by Solution Component (Unified Wireless: Wireless Access Points, Wireless Controller and Wireless Control System)

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts.

See Appendix E, “Device Configurations.”

•PCI 2.1.1— For wireless environments, change wireless vendor defaults, including but not limited to, WEP keys, default SSID, passwords, and SNMP community strings, and disabling of SSID broadcasts. Enable Wi-Fi Protected Access (WPA) technology for encryption and authentication when WPA-capable.

Step 1 Verify that the Cisco Controller is configured by default for administrative restriction and AAA authentication for administrative users.

Step 2 There is no default SSID in the Unified Wireless Architecture. The initial SSID is configured through the controller setup wizard.

Step 3 Disable/remove default SNMP strings of “public/private”.

Step 4 Create new community strings:

config snmp community create <string>

config snmp community mode enable <string>

config snmp community accessmode <ro/rw> <string>

Step 5 Verify that default community strings are no longer accessible.

Step 6 Configure administrative user either via initial controller setup script or via CLI:

config mgmtuser add <username> <password> read-write/read-only

Step 7 Configure wireless system for WPA authentication.

Note that SSID Broadcast is enabled by default, but may be disabled. Figure 3-3 shows configuration of WLAN on the Cisco Controller for WPA security using RADIUS client authentication.

Figure 3-3 Configuring Wireless System for WPA Authentication

Step 8 Verify that WLAN security configuration (SSID broadcast disabled, WEP/WPA in use) is enabled.

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function).

•PCI 2.2.3—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

•PCI 2.2.4—Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

•PCI 2.3—Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS (transport layer security) for web-based management and other non-console administrative access.

Following is a sample configuration:

Step 1 Verify that the Controller is enabled only for secure management protocols- i.e. HTTPS (SSL) only, Telnet disabled, SNMP v1 disabled, SSH permitted).

Figure 3-4 shows an output from controller “Management> Summary” that shows the controller default settings, which include HTTP disabled, Telnet disabled, and HTTPS (SSL)/ SSH enabled.

Figure 3-4 Controller Default Settings

Step 2 Verify that administrative access is denied to users accessing over unpermitted interfaces/addresses that are not permitted. Verify that only encrypted protocols are permitted.

•Access points—Configuration to the access point is via the controller with the exception of the console port. Role-based configuration of the console port is defined via the controller.

•Controller—Central management of the controller is the recommended configuration method via WCS. Local management of the controller is configured to authenticate via CS-ACS.

•WCS—The WCS is capable of defining role-based administrator account locally.

Requirement 4: Encrypt Transmission of Cardholder Data Across Open, Public Networks

•PCI 4.1—Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.

Examples of open, public networks that are in scope of the PCI DSS are the Internet, WiFi (IEEE 802.11x), global system for mobile communications (GSM), and general packet radio service (GPRS).

•PCI 4.1.1—For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN.

If WEP is used, do the following:

•Use with a minimum 104-bit encryption key and 24 bit-initialization value

–Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS

–Rotate shared WEP keys quarterly (or automatically if the technology permits)

–Rotate shared WEP keys whenever there are changes in personnel with access to keys

–Restrict access based on media access code (MAC) address

Step 1 Configure wireless equipment for WPA authentication and encryption. (See Figure 3-5.)

Figure 3-5 Configuring WPA Authentication and Encryption

Note WLAN security data (that is, Pairwise Master Key (PMK used in WPA or WEP key used with 802.1X dynamic WEP) is stored/cached on WLAN controller and only transferred to AP upon client association. Control and configuration traffic between controller and AP is authenticated and encrypted. AES encryption is used on this link.

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

•PCI 8.5.1.b—Verify that only administrators have access to management consoles for wireless networks.

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords.

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Access points satisfied this requirement because all operation is handled by the controller. Access point console access is configured at the wireless controller.

Controllers satisfied this requirement by using administrator user authentication via RADIUS through CS-ACS.

Wireless clients use RADIUS authentication via CS-ACS prior to enabling encrypted wireless communication.

Wireless Control System (WCS) satisfied requirements PCI 7.2-PCI 8.5.8 by configuring unique user name and passwords on the WCS server itself. WCS did not satisfy 8.5.9-8.5.15 because it does have a session timeout setting and was not able to take advantage of the CS-ACS via RADIUS.

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

Compliance of the following sub-requirements for access points and controllers was achieved within the solution by implementing the CS-ACS for AAA services.

WCS satisfied these requirements by use of a local user database and corresponding user authentication policy.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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.2.3—Access to all audit trails

•PCI 10.2.6—Initialization of the audit logs

WCS satisfied these requirements by implementation of the CSA client on the WCS server for protection of the local audit trail.

Controllers are configured to use the two NTP servers to satisfy the requirements in this section.

The WCS server satisfied these requirements by configuring the operating system of the WCS server to use NTP.

•PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization

•PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version

The CSA client was applied to the WCS server and configured to monitor the logs and audit trails, to satisfy the following requirements:

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

•PCI 10.5.2—Protect audit trail files from unauthorized modifications

WCS only

•PCI 10.5.4—Copy logs for wireless networks onto a log server on the internal LAN.

The controllers are configured to send Syslog message to the CS-MARS appliance.

Note Currently there is no documented standard for wireless.

Requirement 11: Regularly Test Security Systems and Processes

•PCI 11.1.b—Verify that a wireless analyzer is used at least quarterly to identify all wireless devices.

The LWAPP unified wireless system has the wireless analyzer capability. Verizon Business confirmed that wireless controllers are configured to continually scan and detect rogue APs and wireless devices.

The following is a sample configuration (CLI of Controller):

Untrusted AP Policy

 Rogue Location Discovery Protocol.............. Disabled

   RLDP Action.................................. Alarm Only

 Rogue APs

   Rogues AP advertising my SSID................ Alarm Only

   Detect and report Ad-Hoc Networks............ Enabled

PCI Sub-Requirements that Require Compensating Controls (Wireless Control System)

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

This section applies to WCS server only and not to the wireless controllers or access points.

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty 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-enter the password to re-activate the terminal.

Caution

WCS does not support external authentication methods. It was not able to take advantage of the Active Directory, CS-ACS, or other authentication solutions. WCS does not have local individual user password duration enforcement, password complexity, password history or automated failed lockout capability.

Compensating Control for Compliance

The QSA recommends a combination of documented password policies, manual audit procedures to ensure passwords are being changed every 90 days, and firewall segmentation for WCS servers within the data center. These would be reasonable compensating controls for password setting limitations within these applications.

The sub-requirements were not met in this lab environment because the data center infrastructure and company policies are not within the scope of the audit, prohibiting deploying the QSA-recommended compensating controls.

PCI Sub-Requirements that Require Compensating Controls (Wireless Controllers)

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

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

Caution

The web-based interface of the controllers does not support a 15 minute timeout. The SSH terminal interface of the controller does support the 15 minute timeout.

Compensating Control for Compliance

Cisco recommends disabling the local web-based management of the Wireless Controller. The central WCS server should be used for configuration management of the Wireless Controller.

Adaptive Security Appliance (ASA)

General Notes/Best Practices

•The ASA is a multi-purpose security appliance that combines firewall, intrusion prevention/detection, and virtual private network (VPN) services in small, medium, and large sizes and throughput levels.

•The ASA is commonly used when connecting to an untrusted WAN connection (i.e. Internet or a managed service provider).

•The ASA is also used at the data center, where larger appliances support higher throughput levels. They may be used to terminate VPN connections from the WAN, or from Internet-based VPN connections.

•The ASA may be configured using the Adaptive Security Appliance Device Manager (ASDM). The graphical interface was used to configure the ASA in the solution. All configuration snapshots used the ASDM.

•The Intrusion Protection Service (IPS) v5.1 module on the ASA was managed via the Intrusion Device Manager (IDM) graphical software. All configuration snapshots are given using the IDM interface.

PCI Sub-Requirements Satisfied by Solution Component (Adaptive Security Appliance)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

•PCI 1.2—Build a firewall configuration that denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment.

As shown in Figure 3-6, the interfaces on the ASA were configured with higher security on the inside interface (LAN-side) than the outside interface. In this case, the values chosen were 0 and 100, although the values have meaning only relative to each other.

Each interface must have a security level from 0 (lowest) to 100 (highest). Typically, the most secure network, such as the inside host network is assigned a 100. The outside network connected to the Internet is typically a 0. Other networks, such as DMZs can have values in between.

Figure 3-6 ASA Interface Configuration

The ASA was configured to allow only the following business-related communication between the hospital and the data center:

•Management protocols for CiscoWorks Network Compliance Manager (NCM), Cisco Security Manager (CS-M), and CiscoWorks (C-LMS)

•Monitoring, analysis, and response system (CS-MARS)

•Authentication, authorization, and accounting to CS-ACS via TACACS

•Network troubleshooting protocols (ICMP)

•Network Time Protocol (NTP) for time stamp synchronization

•System logging access for network events

•Simple Network Management Protocol (SNMP)

•SSL for secure management access to routers sitting on the outside of the ASA in the WAN aggregation segment of the datacenter as well as the routers and the RSA Key Manager clients sitting in the hospital network.

•Dynamic Host Configuration Protocol (DHCP)

•Communication between RSA File Security Manager server and File Security Manager client (TCP ports 19978, 5766)

•Communication between NCR POS systems in the hospital and the data center: FTP and SSH.

•PCI 1.3.3—Implementing stateful inspection, also known as dynamic packet filtering (that is, only “established” connections are allowed into the network).

•PCI 1.3.5—Restricting inbound and outbound traffic to that which is necessary for the cardholder data environment.

The ASA was configured to filter and inspect all traffic inbound from the remote health facilities (see Figure 3-7). Through extensive interview and discussion with the QSA, filtering all inbound network traffic was determined to be an acceptable implementation. This effectively restricts the outbound traffic

Figure 3-7 Inspection Rules on ASA Appliance

•PCI 1.3.7—Denying all other inbound and outbound traffic not specifically allowed.

Deny and log all traffic not explicitly allowed within each firewall rule set.

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

Configure passwords with required complexity and length for local accounts.

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function)

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

HTTPS was enabled on the ASA so all web access to the ASA, including access through the Adaptive Security Device Manager (ASDM) was secure over SSL. With this setting, HTTP access was disabled. SSH access to the ASA was enabled and Telnet access disabled as a result. Figure 3-8 shows the settings.

Figure 3-8 HTTP and HTTPS Settings on ASA

–PCI 2.2.3.b—Verify that common security parameter settings are included in the system configuration standards

–PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

The ASA was configured according to security best practice standards. The following settings were configured to ensure secure access to the device itself and to harden security for traffic across the ASA. Figure 3-9 shows how management access is limited to the out-of-band management interface.

Figure 3-9 Anti-Spoofing Configuration on ASA

Figure 3-10 shows how the default ASA password is changed from its factory default.

Figure 3-10 Out-of-band Management Setting on ASA

Figure 3-11 shows the AAA configuration to use an external TACACS server for authentication.

Figure 3-11 Default Password Configuration on ASA

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements for Requirements 7 and 8:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the ASA. These fallback accounts should be rotated based on a QSA-recommended policy.

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

Only SSH, Telnet, and console access to the ASA can be configured with a session timeout. In the case of managing the ASA with ASDM, the workstation on which the ASDM is installed can be configured with a password-protected screensaver set to appear after 15 minutes of idle time. Because of Requirement 2, Telnet should not be used for device management. Figure 3-12 and Figure 3-13 show how to configure the SSH and console timeouts using the ASDM for SSH.

Figure 3-12 Session Timeout for SSH

Figure 3-13 Configuring Session Timeout for Console

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS for AAA services. Time synchronization was configured with central NTP servers and syslog messages were configured to be sent to the central CS-MARS server. See Figure 3-14, Figure 3-15, and Figure 3-16 below.

The ASA firewall was not configured or audited for AAA features without the use of CS-ACS.

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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.a—Verify that NTP or similar technology is used for time synchronization

•PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version

Figure 3-14 NTP Server Configured for Requirement 10.4.a.

Figure 3-15 Syslog Server Configured to Point at CS-MARS Server

Figure 3-16 Syslog Events Configured for Logging to CS-MARS

•PC 11.4—Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up-to-date.

The AIP-SSM-20 module with IPS v5.1 was used for IDS/IPS services on the ASA for traffic between the branches and the data center. In evaluating the strength of the IDS/IPS system, the QSA considers the following parameters:

•Number of pre-defined signatures available. Typically, the QSA looks at the number as an order of magnitude. In this solution, more than 2000 signatures were available and considered satisfactory.

•Since the IPS module has its own management interface (through the IPS Device Manager), the set of 2.X and 8.X requirements are applied. The following is a listing of the requirements and how the IPS module satisfies them. See Cisco Intrusion Detection System Services Module (IDSM2) for details of how the Device Manager features is mapped to PCI requirements.

VPN Tunnel Configuration on Adaptive Security Appliance (ASA) for Remote Access with Two-Factor RSA SecurID Authentication

General Notes

The ASA in the WAN Aggregation layer was used as the termination point for remote access IPSec VPN tunnels. A Windows client with the Cisco VPN client v. 4.0.5 was used as the remote client.

For details on configuring VPN tunnel groups and policies for remote access configurations, refer to the Cisco ASA 5500 Series Getting Started Guide, Version 7.2 at the following URL:

http://www.cisco.com/en/US/docs/security/asa/asa72/getting_started/asa5500/quick/guide/remvpn_b.html

System Management

CiscoWorks LAN Management System

The CiscoWorks LAN Management System (C-LMS) provides a network management function that addresses specific PCI 1.1 requirements.

General Notes/Best Practices

C-LMS was installed using the following modules:

•Common services (CS) provides an operating foundation that allows CiscoWorks applications to share data and system resources. It also provides a common desktop for launching CiscoWorks applications and centralizes login, user role definitions, and access privileges.

•CiscoWorks CiscoView is a web-based device management application that provides dynamic status, monitoring, and configuration for a broad range of Cisco devices. CiscoWorks CiscoView aids network management by graphically displaying physical views of Cisco devices, with color-coded modules and ports for at-a-glance performance and status monitoring. Configuration capabilities allow comprehensive changes to devices, when requisite security privileges are granted. CiscoWorks CiscoView offers the following advantages:

–Viewing real-time front and back panel display of Cisco devices

–Monitoring device performance, device environmental status, and mini-Remote Monitoring (mini-RMON)

–Making direct device-configuration changes

–Taking advantage of CiscoWorks LAN Management Solution common device inventory

–Defining granular CS-ACS-authenticated multiple-user access rules

•CiscoWorks Campus Manager provides powerful tools for configuring, managing, and understanding complex physical and logical Layer 2 infrastructures. CiscoWorks Campus Manager includes the following tools:

–User tracking (and end-host tracking)

–Discrepancy reporting

–Topology services

–VLAN, private VLAN (PVLAN), and VLAN Trunking Protocol (VTP) management

–Spanning-tree management and visualization

–Path analysis

–Data-extraction engine

•CiscoWorks Resource Manager Essentials (RME) provides lifecycle management of Cisco network devices. Designed to reduce human error and eliminate many of the manual tasks associated with maintaining a network, RME helps make Cisco networks the most manageable and available in the world. The RME suite includes the following tools for simplifying the administration of a Cisco network:

–Inventory management

–Device configuration management

–Software image management

–Change audit services

–Syslog analysis

•CiscoWorks Device Fault Manager (DFM) performs real-time fault analysis of Cisco devices. Through a variety of data collection and analysis techniques, CiscoWorks DFM generates intelligent traps, which can be forwarded to other event management systems installed in the network, sent to e-mail/pager gateways, or displayed in the DFM alarm window. DFM features include the following:

–Problem-focused fault analysis

–Integration with the CiscoWorks desktop and server

–Integration with enterprise management systems

–Support for Layer 2 and Layer 3 Cisco devices

–Incremental device support

CiscoWorks Common Services was configured with Server > Security Browser_server_security_mode enabled. In addition, CS-ACS AAA mode is selected as the authentication option.

Figure 3-17 shows a sample configuration.

Figure 3-17 Common Services Configuration

Change the system identity user as shown in Figure 3-18.

Figure 3-18 System Identity Username Configuration

CiscoWorks can be used to update routers and switches to meet required timelines for PCI 6.1.

PCI Sub-Requirements Satisfied by Solution Component (C-LMS)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

•PCI 1.3.6—Securing and synchronizing router configuration files. For example, running configuration files (for normal functioning of the routers), and start-up configuration files (when machines are re-booted), should have the same, secure configuration.

C-LMS maintains a database of configuration files in a highly secure manner. The suite is capable of alerting administrators of configuration file synchronization issues. The system is also able to correct synchronization inconsistencies (RME). Cisco provides additional value because the switches are capable of this feature as well as the routers.

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts).

Configure passwords with required complexity and length for local accounts.

See Appendix E, “Device Configurations.”

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

The management console was configured to support HTTPS access, with HTTP access disabled. CiscoWorks is configured to use SSL as a highly secure management portal technology, and uses SSH and SNMPv3 as primary configuration protocols.

Role-based administration was configured for administrative tasks.

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

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

•PCI 6.2 (6.2b)—Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update standards to address new vulnerability issues.

C-LMS can aid in the execution of a configuration change process by maintaining a history of system configuration changes of routers and switches and alerting operators when changes are made. C-LMS also has the capability of defining exception periods during which no configuration changes are made. Exceptions will be noted in the exception report.

C-LMS can also ensure baseline configuration information is consistent and static. Using baseline templates (RME > Archive Management), configuration templates can be developed to enforce mandatory configuration aspects. Changes to these mandatory items can result in the triggered assertion of the selected template, updating the device configuration to include the mandatory items.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID

Compliance of these sub-requirements was achieved within the solution by implementation of CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the C-LMS console. These fallback accounts should be rotated based on a QSA-recommended policy.

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

The text following this list refers to the following sub-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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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

Compliance of these sub-requirements was achieved within the solution by implementing the CS-ACS for AAA services. (See Figure 3-19.)

Figure 3-19 AAA Mode Setup

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

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

C-LMS has the capability of a local 15-minute timeout to satisfy this requirement.

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

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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

Compliance of these sub-requirements was achieved within the solution by implementing the CS-ACS for AAA services. (See Figure 3-17.)

•PCI 10.2.3—Access to all audit trails

•PCI 10.2.6—Initialization of the audit logs

C-LMS satisfied these requirements by implementation of the CSA client on the C-LMS server for protection of the local audit trail.

The following requirements were satisfied by configuring the operating system of the C-LMS server to use NTP:

–PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization.

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT), peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

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

•PCI 10.5.2—Protect audit trail files from unauthorized modifications.

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

The CSA client was installed on the C-LMS server and configured to monitor the logs and audit trails to satisfy this requirement.

PCI Sub-Requirements that Require Compensating Controls (C-LMS)

The C-LMS did not require any compensating controls to pass respective PCI sub-requirements.

Cisco Security Manager

The Cisco Security Manager is a powerful yet easy-to-use solution for configuring firewall, VPN, and IPS policies on Cisco security appliances, firewalls, routers, and switch modules.

General Notes/Best Practices

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

Following is a sample configuration:

## Iterate on the interface names and for each give the following template to prevent DoS
attacks

#if($SYS_INTERFACE_NAME_LIST != [])

  #foreach ($int in $SYS_INTERFACE_NAME_LIST)

		#if (($int != "Tunnel0") && ($int != "Tunnel1") && ($int != "Loopback0"))

       interface $int

            no ip directed-broadcast

            no ip mask-reply

            ip verify unicast source reachable-via rx

       exit

	  #end

  #end

#end

PCI Sub-Requirements Satisfied by Solution Component (CS-M)

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

•PCI 2.1—Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, SNMP community strings, and elimination of unnecessary accounts.

Configure passwords with required complexity and length for local accounts.

See Appendix E, “Device Configurations.”

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

The management console was configured to support HTTPS access, with HTTP access disabled. CS-M is configured to use SSL as a highly secure management portal technology, and uses SSH and SNMPv3 as primary configuration protocols.

Role-based administration was configured for administrative tasks.

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

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID

Compliance of these sub-requirements was achieved within the solution by implementing the CS-ACS and Microsoft Active Directory for user account services.

Fallback authentication, in the event of the CS-ACS not being reachable, was configured local to the C-LMS console. These fallback accounts should be rotated based on a QSA-recommended policy.

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

CS-M has the capability of a 15-minute timeout to satisfy this requirement.

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

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

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

•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

Compliance of these sub-requirements was achieved within the solution by implementing the CS-ACS for AAA services.

•PCI 10.2.3—Access to all audit trails

•PCI 10.2.6—Initialization of the audit logs

CS-M satisfied these requirements by implementation of the CSA client on the CS-M server for protection of the local audit trail.

The following requirements were satisfied by configuring the operating system of the CS-M server to use NTP:

–PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization.

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT), peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

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

•PCI 10.5.2—Protect audit trail files from unauthorized modifications.

The CSA client was installed on the CS-M server and configured to monitor the logs and audit trails to satisfy this requirement

PCI Sub-Requirements that Require Compensating Controls (CS-M)

The Cisco Security Manager did not require any compensating controls to pass respective PCI sub-requirements.

CSA Manager

The Cisco Security Agent (CSA) Manager manages the CSA that delivers application firewall, file integrity, and host intrusion prevention services.

General Notes/Best Practices

•Install the CSA client on all servers and workstations for supported operating systems

•Configure policies to monitor audit trails and logs of respective servers

PCI Sub-Requirements Satisfied by Solution Component (CSA Manager)

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

Configure passwords with required complexity and length for local accounts. (See Appendix E, “Device Configurations.”)

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately

The management console was configured to support HTTPS access, with HTTP access disabled. CSA Manager is configured to use SSL as a highly secure management portal technology, and uses SSH and SNMPv3 as primary configuration protocols.

Role-based administration was configured for administrative tasks.

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

Requirement 5: Use and Regularly Update Anti-virus Software or Programs

•PCI 5.1—Deploy anti-virus software on all systems commonly affected by viruses (particularly personal computers and servers).

Note Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.

•PCI 5.1.1—Ensure that anti-virus programs are capable of detecting, removing, and protecting against other forms of malicious software, including spyware and adware.

•PCI 5.2—Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.

A/V software was installed on Windows systems. The assessment focus for PCI A/V requirements depended on Cisco Security Agent software and its ability to meet the intent of A/V requirements. Cisco Security Agent software is installed on all system components commonly affected by viruses, including the following:

•CS-ACS console

•WCS console

•C-LMS console

•CSA console

•CS-M console

Although Verizon Business recommends that anti-virus software be installed on the above system components, CSA software can be used, in conjunction with additional compensating controls, to mitigate the majority of common anti-virus risks.

Verizon Business reviewed vendor documentation and observed a demo of the capabilities of CSA to provide layered security through multiple security controls. The PCI Solution for healthcare addresses the following AV requirements:

•A central (master) console centrally manages all CSA client policies.

•Log generation is enabled and alerts/logs are centrally stored within CSA and CS-MARS. The retention period is determined by the merchant/service provider. However, because such alerts can be vital for audit trail construction, Verizon Business recommends retaining CSA alerts for at least one year, commensurate with PCI audit trail requirements.

Note Because POS environments vary with each vendor, a full assessment of the POS environment, Internet/e-mail connectivity to the POS environment, corporate connectivity to the POS environment, and all compensating controls need to be made for each merchant, to make an “In Place/Not in Place” assessment (if CSA software is used as a compensating control for anti-virus software).

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID

Compliance of these sub-requirements was achieved within the solution by implementing the LDAP authentication to Microsoft Active Directory for user account services.

Fallback authentication: In the event of LDAP authentication failure, CSA Manager was configured with local role-based accounts. These fallback accounts should be rotated based on a QSA-recommended policy.

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

CSA Manager has the capability to support a 15-minute timeout.

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

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

Compliance of these sub-requirements was achieved within the solution by implementation of the following:

•Active Directory (AD) authentication logs (authentication requests sent directly to AD).

•All CSA logs, alerts/events sent to CSA Manager.

•Local audit trail for CSA management.

•CSA Manager has the CSA client installed.

•CSA is configured to monitor access to all files containing cardholder data.

The following requirements were satisfied by configuring the operating system of the CSA Manager server to use NTP:

–PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization.

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT), peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

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

•PCI 10.5.2—Protect audit trail files from unauthorized modifications.

•PCI 10.5.5—Use file integrity monitoring and 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).

CSA software is used to monitor and protect access to audit trail files, and alert on unauthorized attempts to modify the audit trail (only application services responsible for writing log data can write/modify/delete the audit trail). Cisco has created an additional backup script to copy the audit trail to a central backup server, where CSA protection has been applied to eliminate all access, modification, and deletion, except for the account responsible for backing up the audit trail.

•PCI 10.6.a—Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.

•PCI 10.6.b—Through observation and interviews, verify that regular log reviews are performed for all system components.

CSA performs correlation and analysis of system events, and is configured to alert on those events, warranting immediate action.

Note Documented security policies and procedures need to require daily review of security logs, including follow-up to exceptions (responsibility of the merchant/service provider).

Requirement 11: Regularly Test Security Systems and Processes

•PCI 11.4.b—Confirm IDS and/or IPS is in place to monitor and alert personnel of suspected compromises.

•PCI 11.4.c—Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection.

Cisco CSA (host-based IDS/IPS) is installed on management consoles (for example, CS-M, C-LMS, CSA console, CS-ACS, and WCS console).

CSA is configured to monitor and alert personnel of suspected compromise.

CSA (host-based IDS/IPS) does not rely on signatures, but is behavior-based, eliminating the need to update signatures.

•PCI 11.5—Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files; and configure the software to perform critical file comparisons at least weekly.

Critical files are not necessarily only those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is the merchant or service provider).

Application of the CSA client to each of the management consoles (C-LMS, CS-M, CSA Manager, WCS, and Active Directory) satisfied this requirement for those servers. CSA logs and alerts on attempted access, regardless of whether it is allowed or denied. CSA also logs and alerts on critical file modification.

PCI Sub-Requirements that Require Compensating Controls (CSA Manager)

CSA Manager did not require any compensating controls to pass respective PCI sub-requirements.

Cisco Security Monitoring, Analysis and Response System (CS-MARS)

CS-MARS is an appliance-based, all-inclusive solution that allows network and security administrators to monitor, identify, isolate, and counter security threats.

General Notes/Best Practices

•The PNADMIN account cannot be deleted from the CS-MARS appliance. This account should be configured with appropriate password security and distributed only to authorized staff. It should not be used for configuration.

•The version of CS-MARS appliance used during the audit lacks the capability for external authentication; however, version 4.3 and later of CS-MARS supports external authentication via RADIUS. Cisco recommends a combination of documented password policies, manual audit procedures and firewall segmentation within the datacenter for the version of CS-MARS used for this solution audit and for prior versions not supporting RADIUS authentication.

•CS-MARS should be configured to store its audit logs and database to an external NFS server storage facility.

•CS-MARS does not enforce adequate password strength and complexity. A security policy needs to be enforced when developing management passwords.

PCI Sub-Requirements Satisfied by Solution Component (CS-MARS)

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

Configure passwords with required complexity and length for local accounts.

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

CS-MARS supports secured communication only through HTTPS and SSH.

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords.

CS-MARS allows the configuration of unique users and passwords. However, the PNADMIN account is a general administrator account that cannot be deleted. The default password must be changed on this account and stored in a secure location to prohibit the use of a general account.

CS-MARS does not allow alternative or external authentication methods. It cannot be configured to authenticate to CS-ACS or Active Directory.

CS-MARS uses AES encryption method for its passwords.

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

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

Individual role-based user authentication logs are local (no CS-ACS or AD authentication available).

CS-MARS receives CSA logging/alerts, CS-M security events, ISR firewall logs, and IDS/IPS alerts.

There is a local audit trail for CS-MARS.

Audit log files backed up daily to an NFS backup server are monitored by CSA, and all processes and users (except the application processes responsible for writing data to the NFS server) are prohibited from modifying or deleting files from this directory.

CSA alerts are generated, sent to the CS-MARS central server, and an e-mail alert is sent to the administrator e-mail account.

The following requirements were satisfied by configuring the CS-MARS appliance to use NTP:

–PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization.

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT), peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

The following is a sample configuration:

[pnadmin]$ ntp ?

Usage : ntp server [ntp server1] [ntp server2]

       ntp sync

       ntp disable

[pnadmin]$ ntp server ntp1.retailpcilab.local ntp2.retailpcilab.local

Thu Jan 11 12:54:41 PST 2007

[pnadmin]$

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

•PCI 10.5.2—Protect audit trail files from unauthorized modifications.

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

CS-MARS has centrally stored audit logs.

CS-MARS logs are archived once an hour and sent to a central NFS server running CSA software.

•PCI 10.5.4—Copy logs for wireless networks onto a log server on the internal LAN.

Wireless Syslogs are sent to CS-MARS central servers from the Wireless Controllers. CS-MARS does not have predefined event triggers for wireless logs. They need to be manually defined based on customer requirements.

•PCI 10.6.a—Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.

•PCI 10.6.b—Through observation and interviews, verify that regular log reviews are performed for all system components.

CS-MARS performs correlation and analysis of system events, and alerts on those warranting immediate action.

Note Documented security policies and procedures require daily review of security logs, including follow-up to exceptions (the responsibility of the merchant/service provider).

PCI Sub-Requirements that Require Compensating Controls (CS-MARS)

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

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty 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-enter the password to re-activate the terminal.

Caution

CS-MARS does not have individual user password duration enforcement, password complexity, password history, or automated failed lockout capability. CS-MARS does not support external authentication methods. It was not able to take advantage of the Active Directory, CS-ACS, or other authentication solutions.

Compensating Control for Compliance

The QSA recommends a combination of documented password policies, manual audit procedures to ensure passwords are being changed every 90 days, and firewall segmentation for CS-MARS servers within the data center. These would be reasonable compensating controls for password setting limitations within these applications.

The sub-requirement was not met in this lab environment because the data center infrastructure and company policies are not within the scope of the audit, prohibiting deploying the QSA-recommended compensating controls.

CiscoSecure Access Control Server (CS-ACS)

The CS-ACS provides secured authentication service for ISRs, switches, wireless APs, wireless controllers, C-LMS, and CS-M.

General Notes/Best Practices

•CS-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 CS-ACS. This provides the granularity of secure authentication needed to address the PCI specification.

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

•Remove the default accounts for administration.

•Enable HTTPS and disable HTTP.

PCI Sub-Requirements Satisfied by Solution Component (CS-ACS)

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

Configure passwords with required complexity and length for local accounts. (See Appendix E, “Device Configurations.”

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

The management console was configured to support HTTPS access, with HTTP access disabled. CS-ACS is configured to use SSL as a highly secure management portal technology.

CS-ACS employs port hopping to a random high port for secured communication transport.

Role-based administration is configured for administrative tasks.

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

Requirement 6: Develop and Maintain Secure Systems and Applications

•PCI 6.1—Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.

Smartnet services enable Cisco customers to have the ability to keep current with the latest versions of code, including security patches and bug fixes.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords.

Role-based privilege assignment is configured on CS-ACS for all management functions.

The Access Control Server allows for the configuration of unique users and passwords. CS-ACS administrative accounts do not allow alternative or external authentication methods. The ACS cannot be configured to authenticate to Active Directory for management functions of the server itself. (See Figure D-8.)

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

CS-ACS is configured with a 15-minute timeout. (See Figure D-10.)

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

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

Individual role-based user authentication logs are local (no AD authentication available).

There is a local audit trail for CS-ACS.Audit log files are backed up daily to a log backup server are monitored by CSA. All processes and users (except the application processes responsible for writing data to the log server) are prohibited from modifying or deleting files from the backup directory.

CSA alerts are generated, sent to the CS-MARS central server, and an e-mail alert is sent to the administrator e-mail account.

The following requirements were satisfied by configuring the operating system of the CSA Manager server to use NTP:

–PCI 10.4.a—Verify that NTP or similar technology is used for time synchronization.

–PCI 10.4.b—Verify that internal servers are not all receiving time signals from external sources. Two or three central time servers within the organization receive external time signals directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT), peer with each other to keep accurate time, and share the time with other internal servers.

–PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version.

These requirements were satisfied by configuring the operating system of the Access Control Server to use NTP.

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

•PCI 10.5.2—Protect audit trail files from unauthorized modifications.

Cisco Security Agent (CSA) software is used to monitor and protect access to audit trail files, and to alert on unauthorized attempts to modify the audit trail (only application services responsible for writing log data can write/modify/delete the audit trail). Cisco has created an additional backup script to copy the audit trail to a central backup server, where CSA protection has been applied to eliminate all access, modification, and deletion, except for the account responsible for backing up the audit trail.

PCI Sub-Requirements that Require Compensating Controls (CS-ACS)

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

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Caution

CS-ACS does not have individual user password duration enforcement, password complexity, password history or automated failed lockout capability for administration of the server itself. CS-ACS administration does not support external authentication methods. It was not able to take advantage of the Active Directory or other authentication solutions.

Compensating Control for Compliance

Cisco recommends a combination of documented password policies, manual audit procedures to ensure passwords are being changed every 90 days, and firewall segmentation for CS-ACS servers within the data center. These would be reasonable compensating controls for password setting limitations within these applications.

Compliance Management

CiscoWorks Network Compliance Manager (C-NCM)

General Notes/Best Practices

The C-NCM can be used to prepare for a PCI audit by leveraging the following capabilities:

•Maintain comprehensive device configuration change history archive for security audits.

•Monitor and enforce compliance with security standards such as Visa CISP/PCI for credit card transactions.

•Create security compliance policies (regex pattern match on firewall configurations) and check if firewall configurations are in compliance with applied security policies.

•Provide role-based access control and lockdown to devices and their configurations.

•Provision configuration changes on firewall devices.

•Maintain audit trail of changes made on firewall devices.

•Maintain a history of changes made to ACLs.

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

Configure passwords with required complexity and length for local accounts.

The text following this list refers to the following sub-requirements:

•PCI 2.2.2—Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function).

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

Unsecured access to CS-NCM via HTTP and Telnet were disabled while HTTPS and SSH were configured. See Figure 3-20.

Figure 3-20 Configure CS-NCM to Accept SSH Connections, Disabling Telnet

Services such as Telnet, FTP, and TFTP were not selected for the connection methods to the network devices. CS-NCM was managing according to PCI requirements for services running on CS-NCM as well as services that should be running on the managed network devices. See Figure 3-21.

Figure 3-21 Device Access settings on CS-NCM for Secure Connection Methods to Network Devices

•PCI 2.2.3.b—Verify that common security parameter settings are included in the system configuration standards.

•PCI 2.2.3.c—For a sample of system components, critical servers, and wireless access points, verify that common security parameters are set appropriately.

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

The text following this list refers to the following sub-requirements for requirements 7 and 8:

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

Compliance of the sub-requirements in this section was achieved within the solution by implementing the CS-ACS and Microsoft Active Directory for user account services.

In the event of a CS-ACS failure fallback authentication was configured local to the CS-NCM. These fallback accounts should be rotated based on a QSA-recommended policy.

•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.2—All actions taken by any individual with root or administrative privileges

•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.a—Verify that NTP or similar technology is used for time synchronization

•PCI 10.4.c—Verify that the Network Time Protocol (NTP) is running the most recent version

•PCI 11.1—Test security controls, limitations, network connections, and restrictions annually to assure the ability to adequately identify and to stop any unauthorized access attempts.

The above requirements were met by the CS-NCM as they pertain to configuration change events on the network devices.

CS-NCM was used to capture configuration snapshots of the ASA, routers, and Catalyst switches in the datacenter. It was used to check whether a device had the proper commands configured in order to satisfy PCI requirements. Configuration changes were monitored and tracked, with the ability to determine which user made changes on a particular device. Figure 3-22 shows an example of CS-NCM configured with a rule to check that devices are configured with passwords for console access according to industry standards and best-practices for securing access to routers and such devices.

Figure 3-22 Requirement 2.2-2

Clients and Servers

Point-of-Sale (POS)

General Notes/Best Practices

The NCR Advanced Checkout Solution Point -of-Sale system was audited for PCI compliance. They were installed to provide the necessary transaction traffic to validate the security of the infrastructure. The QSA audited the POS system by analyzing different files of NCR’s CS-ACS software. Few of files were Database transaction files, user access logs, EFT Journal Report, EFT Offline Report, EFY Rejection Report, Electronic Journal Report, TRMOFF (FOH offline transaction file) and EFTOFF (back office offline transaction file)

Visa maintains a web page with best practices to secure payment applications at: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_payment_applications.html.

The QSA or security services company should provide more details for a specific implementation. The QSA from Verizon Business found that POS servers installed with the CSA client provide tremendous value to an organization seeking PCI compliance.

Servers

General Notes/Best Practices

NCR provided the point-of-sale (POS) client work station and servers. One of the servers was loaded with NCRs Advanced Checkout Solution (NCR-ACS) and other server was loaded with NCRs Advanced Store Workbench (ASW) client software. The client station is NCR RealPOS80c system running Windows embedded XP version 2.

NCR-ACS Software (version 6.01.04.16) is a highly customizable group of applications that provide the healthcare environment with a complete system solution. NCR-ACS includes the application software that runs on the back office computer and at the front-end POS workstations used to check out customers.

•NCR advises its customers to store cardholder data according to CISP Implementation Documentation. Since NCR-ACS is a POS system, NCR advises its customers not to store or place any systems with cardholder data facing the Internet.

•NCR recommends customers implementing the application with any network configuration use only securely encrypted communications.

Advanced Store Workbench (ASW) is the main NCR-ACS software installed on the backoffice computer system. The ASW provides back office reports and applications.

QSA found that the NCR-CSA client installed on POS systems would provide tremendous value to an organization seeking PCI compliance.

PCI Sub-Requirements Satisfied by Solution Component (NCR POS Systems)

Requirement 3: Protect stored cardholder data

•PCI 3.2—Do not store sensitive authentication data subsequent to authorization (even if encrypted).

Sensitive authentication data includes the data as cited in the following requirements 3.2.1 through 3.2.3. It is the responsibility of the merchant to ensure the POS systems used do not store sensitive authentication data (e.g., full track data, CVV2, and PIN/PIN block) post authorization (even if encrypted). A major step to ensure POS systems meet PCI requirements is to work with the POS vendors who have certified their POS application/s according to PABP standards.

–PCI 3.2.1—Do not store the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data

–PCI 3.2.2—Do not store the card-validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.

–PCI 3.2.3—Do not store the personal identification number (PIN) or the encrypted PIN block

•PCI 3.3—Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Figure 3-23 Masked PAN Information

•PCI 3.4—Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:

–Strong one-way hash functions (hashed indexes)

–Truncation

–Index tokens and pads (pads must be securely stored)

–Strong cryptography with associated key management processes and procedures

The minimum account information that must be rendered unreadable is the PAN.

•PCI 3.5—Protect encryption keys used for encryption of cardholder data against both disclosure and misuse:

–PCI 3.5.1—Restrict access to keys to the fewest number of custodians necessary

–PCI 3.5.2—Store keys securely in the fewest possible locations and forms

•PCI 3.6.1—Generation of strong keys

•PCI 3.6.2—Secure key distribution

•PCI 3.6.3—Secure key storage

•PCI 3.6.4—Periodic key changes

–As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically

–At least annually

Note NCR-ACS application—There was no reasonable way to rotate encryption keys, without manually decrypting all data and re-encrypting with a new key. NCR-ACS application allows multiple keys (up to 255) to be used to limit the amount of data encrypted with a single key.

•PCI 3.6.5—Destruction of old keys.

•PCI 3.6.6—Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key.

•PCI 3.6.7—Prevention of unauthorized substitution of keys

•PCI 3.6.8—Replacement of known or suspected compromised keys

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

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords.

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty minutes or until administrator enables the user ID.

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

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

Note NCR-ACS application: NCR-CSA was used to monitor and log access to use of NCR-ACS application binaries and access to NCR application log files.

•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

Note NCR-ACS application—Any actions taken by any individual administrative privileges is logged to NCR-ACS EFT log file and in the Transaction LOG.

•PCI 10.2.3—Access to all audit trails.

Note NCR-ACS application—Unauthorized access to audit log files and application log directories triggered CSA events, which were logged at CSA Management console.

•PCI 10.2.6—Initialization of the audit logs

Note NCR-ACS application—CSA protection for audit trail access applies to initialization of audit trail.

•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 Sub-Requirements that Require Compensating Controls (NCR POS System)

NCR POS system did not require any compensating controls to pass respective PCI sub-requirements.

Encryption and Key Management

RSA Key Manager

General Notes/Best Practices

Public Key Infrastructure (PKI) is a key requisite for installing RSA Key Manager Server (based on RSA Key Manager version 2.1.1).

Public Key Infrastructure (PKI) Requirements

In an RSA Key Manager deployment, a PKI needed to enable highly secure communication and authentication between entities. In an RSA Key Manager PKI trust model, SSL communications is used for the following purposes:

•Highly secure communications between network entities in the RSA Key Manager deployment.

•Mutual authentication between RSA Key Manager Clients and the web server.

•Highly secure communication for delivery of application certificates to the RSA Key Manager Server.

Figure 3-24 illustrates the RSA Key Manager PKI requirements.

Figure 3-24 RSA Key Manager PKI Requirements

The certificates and credentials that need to be prepared include:

•Key Manager Client PKCS#12 credentials.

Contains the application certificate, application private key, and optionally, the middle Certificate Authority (CA) certificate chain if the application certificate is not signed directly by the web server’s trusted CA certificate.

•Web server SSL certificate and private key.

Used by RSA Key Manager Clients to authenticate the server.

•Application server SSL certificate and private key (optional).

Used by the web server to authenticate the application server. It is recommended to encrypt communications between the web server and the application server, especially if the servers are running on different machines.

•Trusted CA certificate.

Installed on each network entity in a RSA Key Manager deployment 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 web 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.

Security Best Practices

A RSA Key Manager Server deployment securely stores security objects, generates and stores cryptographic keys, manages cryptographic policies, and brokers access to security objects by RSA Key Manager Clients. It is crucial to implement best practice security measures to secure and limit access to this functionality. These measures include, but are not limited to:

•Placing all RSA Key Manager components within a highly secure zone, protected by firewalls and by user authentication and authorization (using RSA Access Manager, for example).

•Highly secure communication between entities in a RSA Key Manager deployment via SSL.

•As much as possible, keeping the RSA Key Manager entities separate from the rest of the organizational systems.

•Suppressing logging of plain text keys in log files on the web server.

•Prevention of memory modification and direct access to data on disk.

•Highly secure database backup procedures.

A RSA Key Manager Server deployment brings together other third-party products (such as web server, application server, and database server products) to provide a complete cryptographic key management solution.

For the latest information on how to configure and secure Microsoft SQL Server in a RSA Key Manager deployment, refer to the following URLs:

•10 steps to help secure SQL Server

http://www.microsoft.com/sql/prodinfo/previousversions/securingsqlserver.mspx

•SQL Server security considerations

http://msdn2.microsoft.com/en-us/library/ms161948.aspx.

•Backing up and restoring databases in SQL Server

http://msdn2.microsoft.com/en-us/library/ms187048.aspx.

PCI Sub-Requirements Satisfied by Solution Component (RSA Key Manager)

Requirement 3: Protect Stored Cardholder Data

•PCI 3.5.1—Restrict access to keys to the fewest number of custodians necessary

•PCI 3.5.2—Store keys securely in the fewest possible location and forms

•PCI 3.6.1—Generation of strong keys

•PCI 3.6.2—Secure key distribution

•PCI 3.6.3—Secure key storage

•PCI 3.6.4—Periodic key changes

•PCI 3.6.5—Destruction of old keys

•PCI 3.6.6—Split knowledge and establishment of dual control of keys

•PCI 3.6.7—Prevention of unauthorized substitution of keys

•PCI 3.6.8—Replacement of known or suspected compromised keys

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed

•PCI 8.1—Identify all user with a unique user name before allowing them to access system components or cardholder data

The RSA Access Manager was used to provide the above functionality for RSA Key Manager.

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

–Password

–Token devices

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

For RSA key Manager, authentication through RSA Access Manager is hashed and also local authentication is hashed.

•PCI 8.5.8—Do not use group, shared or generic accounts and passwords

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

For RSA Key Manager, this requirement is satisfied using RSA Access Manager

•PCI 8.5.10—Require a minimum password length of at least seven characters

For RSA Key Manager, this requirement is satisfied using RSA Access Manager (8 characters)

•PCI 8.5.11—Use passwords containing both numeric and alphabetic characters

For RSA Key Manager, this requirement is satisfied using RSA Access Manager (alpha-numeric+dictionary check).

•PCI 8.5.12—Do not allow individual to submit a new password that is the same as any of the last four passwords he or she has used

For RSA Key Manager, this requirement is satisfied using RSA Access Manager (last 10 passwords).

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

For RSA Key Manager, this requirement is satisfied using RSA Access Manager (3 invalid attempts in one day)

•PCI 8.5.14—Set the lockout duration to thirty minutes or until administrator enables the user ID

For RSA Key Manager, this requirement is satisfied using RSA Access Manager (admin must reset)

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

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

•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

For RSA Key Manager, in addition to local audit trails, CSA was used to monitor and log access to RSA Key Manager binaries.

–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

For RSA Key Manager, unauthorized access to audit log files and application log directories triggered CSA events which were logged at CSA Management console.

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2.5—Use of identification and authentication mechanisms

•PCI 10.3.1 through 10.3.6—Record audit trail entries for user identification, type of event, date and time, success or failure indication and origination of event

PCI Sub-Requirements that Require Compensating Controls (RSA key Manager)

RSA Key Manager did not require any compensating controls to pass respective PCI sub-requirements.

RSA Access Manager

General Notes/Best Practices

RSA Access Manager is used within the lab environment to protect administrative access to RSA Key Manager. See Figure 3-25 for a sample configuration.

PCI Sub-Requirements Satisfied by Solution Component (RSA Access Manager)

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed.

•PCI 8.1—Identify all user with a unique user name 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:

–Password

–Token devices

–Biometrics

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components.

•PCI 8.5.8—Do not use group, shared or generic accounts and passwords.

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

•PCI 8.5.10—Require a minimum password length of at least seven characters.

•PCI 8.5.11—Use passwords containing both numeric and alphabetic characters

•PCI 8.5.12—Do not allow 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 thirty 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-enter the password to re-activate the terminal.

Figure 3-25 RSA Access Manager – Password Policy

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

•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.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.3.1 through 10.3.6—Record audit trail entries for user identification, type of event, date and time, success or failure indication and origination of event

PCI Sub-Requirements that Require Compensating Controls (RSA Access Manager)

RSA Access Manager did not require any compensating controls to pass respective PCI sub-requirements.

RSA File Security Manager

General Notes/Best Practices

RSA File Security Manager is a software-based security solution that provides transparent encryption of files/folders in conjunction with role-based access control on heterogeneous platforms.

RSA File Security Manager comprises of two integrated components:

•Adapter Manager—Defines the access control rules for network/domain users & applications

•Adapters—Enforces the access control rules at the host/server level

The following are best practices for deploying RSA File Security Manager product:

•Ensure that the systems meet and exceed the minimum system requirements for the adapter and adapter manager console before installation. This information is available in the adapter and adapter manager console installation guides.

•Ensure that the adapter manager console host is able to reach the host on which the file security adapter is installed.

•The adapter and adapter manager console require the use of a control port and audit port to interoperate fully. Ensure that the required firewall ports (default TCP 5766 and 19978) are open to bi-directional traffic to enable full communication between the adapter and adapter manager. Note that the actual port numbers are user configurable.

•Ensure that the policy database is frequently backed up at the adapter manager. A backup is highly recommended after every significant change to the system.

•By default, the file security adapter generates an audit log for all types of access to the protected folder. The audit log data is stored in “day files” on the protected host.

–Monitor the file security adapter for the amount of audit log data being generated and plan for appropriate storage.

–Disable the actions for which the adapter should not create an audit trail.

–A backup strategy should be in place for the audit log data files generated at the file security adapters. At the end of every 24 hours, the file security adapters switch over to a new audit log file (day file).

PCI Sub-Requirements Satisfied by Solution Component (RSA File Security Manager)

Requirement 3: Protect Stored Cardholder Data

•PCI 3.5.1—Restrict access to keys to the fewest number of custodians necessary

•PCI 3.5.2—Store keys securely in the fewest possible location and forms

•PCI 3.6.1—Generation of strong keys

•PCI 3.6.2—Secure key distribution

•PCI 3.6.3—Secure key storage

•PCI 3.6.4—Periodic key changes

•PCI 3.6.5—Destruction of old keys

•PCI 3.6.6—Split knowledge and establishment of dual control of keys

•PCI 3.6.7—Prevention of unauthorized substitution of keys

•PCI 3.6.8—Replacement of known or suspected compromised keys

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed

•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.1—All individual accesses to cardholder data

•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.3.1 through 10.3.6—Record audit trail entries for user identification, type of event, date and time, success or failure indication and origination of event

PCI Sub-Requirements that Require Compensating Controls (RSA File Security Manager)

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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

For 8.5.9 through 8.5.12, QSA recommends a combination of documented password policies, manual audit procedures to ensure strong password generation, using periodic dictionary attacks against passwords, and internal firewall segmentation of these components within the data center, would be reasonable compensating controls for password setting limitations within these applications.

•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 thirty minutes or until administrator enables the user ID

For 8.5.13 through 8.5.14, QSA recommends using CSA or other monitoring software to alert on continuous invalid logon attempts, combined with internal firewall segmentation of these components, would be reasonable compensating controls for account lockout setting limitations within these applications.

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

QSA recommends that screen saver timeouts be used as a compensating control, when idle session timeouts are not available or impact application/business operations (e.g., backup jobs).

Note Sub-requirements from 8.5.9 through 8.5.15 is addressed in roadmap of RSA File Security Manager in version 2.2 to be released in Q12008.

RSA® Authentication Manager and RSA SecurID®

The RSA Authentication Manager works with RSA Authentication Agents to enhance security with strong, two-factor user authentication provided by time synchronous-based RSA SecurID tokens.

The RSA® Authentication Manager is the management component of the RSA SecurID® solution, used to verify authentication requests and centrally administer user authentication policies for access to enterprise networks. Working in conjunction with RSA SecurID authenticators and RSA® Authentication Agent software, the solution provides two-factor user authentication that protects access to more VPNs, wireless networks, web applications, business applications, and operating environments.

General Notes/Best Practices

RSA Authentication Manager should be installed first before installing any of its components like RSA Authentication client and RSA SecurID seeds.

PCI Sub-Requirements Satisfied by Solution Component (RSA Authentication Manager and RSA SecurID)

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

•PCI 7.2—Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

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

•PCI 8.1—Identify all users with a unique user name 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:

–Password

–Token devices (for example, SecureID, certificates, or public key)

–Biometrics

•PCI 8.3—Implement two-factor authentication for remote access to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS) or terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.

•PCI 8.4—Encrypt all passwords during transmission and storage on all system components

•PCI 8.5.8—Do not use group, shared, or generic accounts and passwords

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

•PCI 8.5.10—Require a minimum password length of at least seven characters

•PCI 8.5.11—Use passwords containing both numeric and alphabetic 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.

•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 thirty 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-enter the password to re-activate the terminal.

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

•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.2—All actions taken by any individual with root or administrative privileges

•PCI 10.2.4—Invalid logical access attempts

•PCI 10.2 5—Use of identification and authentication mechanisms

•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.5.1—Limit viewing of audit trails to those with a job related need

•PCI 10.5.2—Protect audit trail files from unauthorized modifications

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

PCI Sub-Requirements that Require Compensating Controls

RSA Authentication Manager:

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

QSA recommends that screensaver timeouts be used as a compensating control, when idle session timeouts are not available or impact application/business operations (e.g., backup jobs).

Note Cisco security advisories and notice are published for significant security issues that directly involve Cisco products and require an upgrade, fix, or other customer action. Security Advisories are posted on Cisco.com and sent to the cust-security-announce@cisco.com as well as various public mailing lists and newsgroups. The cust-security-announce@cisco.com mailing list is an external list that allows anyone interested to subscribe and receive Cisco security announcements. Customers should also visit the Cisco Security Advisories and Notices website (http://www.cisco.com/en/US/products/products_security_advisories_listing.html#advisory) to get details and information about the most recent security vulnerabilities.

Solution Component Summary

Table 3-1 shows how the solution components for the respective compliance themes.

Table 3-1 Solution Component Summary
Solution Component Functions
Technology	Authentication	Configuration Management	Audit Trail
Network Systems
ISR Router	CS-ACS + AD	C-LMS/General (CS-M/Security)	Syslog to C-LMS and CS-MARS
Mid-range/ WAN Aggregation Router	CS-ACS + AD	Local, C-NCM	Syslog to CS-MARS
Catalyst switch	CS-ACS + AD	C-LMS	Syslog to C-LMS and CS-MARS
Adaptive Security Appliance (ASA)	CS-ACS + AD	Local, C-NCM	Syslog to CS-MARS
Wireless Access Points	Local	WCS	LWAPP to controller
Wireless Controller Administration	CS-ACS + AD	WCS	Syslog to CS-MARS, SNMP to WCS
Edge Router (Cisco 7200)	CS-ACS + AD	General/C-NCM	Syslog to CS-MARS
Cisco Firewall Services Module	CS-ACS + AD	General/ASDM	Syslog to CS-MARS
Cisco Intrusion Detection System	Local	IDM/General	Attacks to CS-MARS, Syslog to local flat files
Cisco ACE XML Gateway (AXG)	AD	AXG Manager	Local flat files
System Management
C-LMS	CS-ACS + AD	Local	Local flat files
WCS	Local	Local	Local flat files
CS-M	CS-ACS + AD	Local	Local flat files
CSA Manager	AD	Local	Local database
Compliance Management
C-NCM	CS-ACS + AD	Local	Local database
Monitoring
CS-MARS	Local	Local	Local database/external NFS share
WCS	Local	Local	Local flat files
Authentication
CS-ACS	Local	Local	Local flat files
Clients
Wired users	None	NA	NA
Wireless users	ACS + AD	NA	NA
CSA client	CSA Manager	CSA Manager	NA
Third-Party Products
RSA Key Manager Server	RSA Access Manager	RSA Key Manager	local flat files
RSA File Security Manager	RSA File Security Manager	RSA File Security Manager console	local flat files
NCR POS Servers	AD	Advanced Checkout Solution configuration tool	local flat files
RSA Authentication Manager/RSA SecureID	RSA Authentication Manager/RSA SecureID	RSA Authentication Manager/RSA SecureID

The information in this chapter applies to the solution architectures presented in Chapter 2, “Solution Framework,” such as doctor’s offices, clinics, hospitals, Internet edge, and data centers. Each solution component is presented with the following:

Network Systems

Cisco Integrated Services Router

General Notes/Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Router)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

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

Requirement 6: Develop and Maintain Secure Systems and Applications

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

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

Requirement 11: Regularly Test Security Systems and Processes

PCI Sub-Requirements that Require Compensating Controls (Router)

Mid-Range Routers (WAN Aggregation)/Edge Routers (Internet Edge)

General Notes/Best Practices

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

Requirement 6: Develop and Maintain Secure Systems and Applications

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

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

Cisco Catalyst Ethernet Switch and Network Switch Module

General Notes/Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Switches)

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

Requirement 6: Develop and Maintain Secure Systems and Applications

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

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

PCI Sub-Requirements that Require Compensating Controls (Switches)

Cisco Firewall Services Module (FWSM)

General Notes/Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Cisco FWSM)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

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

Requirement 6: Develop and Maintain Secure Systems and Applications

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

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

PCI Sub-Requirements that Require Compensating Controls (FWSM)

Cisco Intrusion Detection System Services Module (IDSM2)

General Notes/Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Cisco IDSM2)

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

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

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

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

Requirement 11: Regularly Test Security Systems and Processes

PCI Sub-Requirements that Require Compensating Controls (Cisco IDSM2)

Cisco Application Control Engine (ACE) Module

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

PCI Sub-Requirements Satisfied by Solution Component (ACE)

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

Requirement 6: Develop and Maintain Secure Systems and Applications

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

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

Application Control Engine (ACE) XML Gateway

General Notes/Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Cisco ACE XML Gateway)

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

Requirement 6: Develop and Maintain Secure Systems and Applications

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

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

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

PCI Sub-Requirements that Require Compensating Controls (Cisco ACE XML Gateway)

Wireless Access Points and Controllers

General Notes/ Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Unified Wireless: Wireless Access Points, Wireless Controller and Wireless Control System)

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

Requirement 4: Encrypt Transmission of Cardholder Data Across Open, Public Networks

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

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

Requirement 11: Regularly Test Security Systems and Processes

PCI Sub-Requirements that Require Compensating Controls (Wireless Control System)

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

Compensating Control for Compliance

PCI Sub-Requirements that Require Compensating Controls (Wireless Controllers)

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

Compensating Control for Compliance

Adaptive Security Appliance (ASA)

General Notes/Best Practices

PCI Sub-Requirements Satisfied by Solution Component (Adaptive Security Appliance)

Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

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

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access

Requirement 7: Restrict Access to Cardholder Data by Business Need-to-Know and
Requirement 8: Assign a Unique ID to each Person with Computer Access