-
Cisco PCI Solution for Retail Design and Implementation Guide
-
Preface
-
Solution Overview
-
Solution Architecture
-
Solution Components—Best Practices and PCI
-
Implementing and Configuring the Solution
-
Bill Of Materials of Devices for Branch Stores
-
Data Center/Internet Edge Components and Versions
-
Application Protocols
-
Detailed Implementation and Configuration Steps
-
Device Configurations
-
Report on Compliance (ROC)
-
Verizon Business Assessment for: Cisco PCI Solution for Retail
-
Glossary
-
Table Of Contents
Detailed Implementation and Configuration Steps
Small Store (HREAP + Controller Architecture)
Medium Store (Controller-Based)
Large Store (Controller-Based)
Section 2.1 of PCI Requirements
Point-of-Sale Application Systems
Cisco Secure Access Control Server
Global CS-M Access Policy (Mandatory)
Data Center WAN Access Policy (Mandatory)
Cisco Security Agent (CSA) Custom Policy for RSA Products
Cisco Security Agent (CSA) Custom Policy for NCR
RSA Key Manager Administration Console
Starting and Stopping the Key Manager Server
RSA Key Manager Server and Client Deployment
Open Web Application Security Project (OWASP)
PCI 6.5.1 Cross-Site Scripting (XSS) Attacks
Cisco ACE XML Gateway Blocking XSS Attack
Detailed Implementation and Configuration Steps
This appendix includes the implementation and configuration steps for the following:
•
Point-of-Sale Application Systems
•
•
•
Wireless Configuration
Small Store (HREAP + Controller Architecture)
In this configuration, the AP is remotely located from the WLAN controller (WLC). In this architecture, the AP communicates with the WLC to obtain its configuration and via the UDP-based Lightweight Access Point Protocol (LWAPP) for control data, but bridges its traffic locally. This is referred to as "hybrid REAP" (H-REAP) operation. Initial configuration requirements are as follows:
•
•
•
•
•
Medium Store (Controller-Based)
In this configuration, the AP is connected on a network local to the ISR and employs the controller for both configuration/control data and bridging of traffic. Thus, all AP/wireless data is sourced from the WLC. This is referred to as "local" AP operation. Initial configuration requirements are as follows:
•
•
•
•
•
Large Store (Controller-Based)
In this configuration, the WLC is a standalone appliance (WLC-4402) with APs connected on a common subnet with the WLC "management" interface. The management interface is employed for both configuration and maintenance of the WLC as well as communication with the APs for configuration and wireless payload. Note that the wireless user traffic is encapsulated in the LWAPP protocol as it flows from AP to controller, and is bridged to its respective VLAN only upon termination/decapsulation at the WLC. Initial configuration requirements are as follows:
•
•
•
•
Section 2.1 of PCI Requirements
•
•
•
•
"config snmp community create <string>"
"config snmp community mode enable <string>"
"config snmp community accessmode <ro/rw> <string>"
•
•
"config mgmtuser add <username> <password> read-write/read-only". If using Wireless Control System (WCS), change default username and password via GUI (PCI Section 2.1.1)
•
Figure D-1 WLAN Configuration
•
PCI Section 2.3
•
Figure D-2 Management > Summary Controller Output
•
PCI Section 4.1.1
•
Figure D-3 WPA Authentication and Encryption Configuration
Note
PCI Section 9.1.3
Note that console access to wireless APs used with the Cisco Controller does not provide access to any configuration or system information. Note that user access to the console port on the controller may be authenticated via user database or RADIUS.
•
PCI Section 10.4
•
PCI Section 10.5.4
•
•
"config syslog <ip address of syslog destination>"
Figure D-4 Enabling Syslog
•
Figure D-5 Verifying Syslog Logging
PCI Section 11
Note that WLC is enabled for IDS/rogue AP detection by default. When WLC is performing rogue AP/ wireless IDS operation, it periodically scans all active WLAN frequencies to detect any unauthorized or malicious WLAN traffic (Section 11.1).
Verify via the Cisco Controller GUI or via WCS that rogue WLAN devices on the network are detected by the WLC. (See Figure D-6.)
When a rogue AP is detected, the Cisco Controller may invoke a "containment" event, as directed by administrative control. A WLAN containment event is an active mechanism that dis-associates all WLAN clients from a WLAN rogue device.
Figure D-6 Detecting a Rogue AP
Verify that the rogue AP may be detected and contained using the Cisco Controller or WCS user interface. (Section 11.4).
Point-of-Sale Application Systems
Wincor-Nixdorf TP.net and PCI
The Wincor-Nixdorf application was not audited by the QSA. The Wincor product does not directly process credit card payments and therefore is not directly affected by PCI. Following is a summarization of their product in regards to PCI guidelines and its interface to payment system applications. Wincor uses an open standards-based interface called the Open Payment Initiative (O.P.I).
•
•
•
•
•
•
Cisco Secure Access Control Server
CS-ACS was installed on a Windows MCS 7825 server running Windows 2003 server R2. A typical default installation was performed of the CS-ACS product. No individual user accounts were added. Several groups were defined based on typical enterprise roles such as the following:
•
•
•
•
•
•
•
The system interface was then configured for only HTTPS/SSL-encrypted communications by installing an appropriate certificate. (See Figure D-7.)
Figure D-7 Cisco Secure ACS—Certificate
Additional local administrator accounts were added for specific individuals and systems, and the generic Admin account was removed. (See Figure D-8.)
Figure D-8 Administration Control Configuration
CS-ACS does not meet PCI requirements for user administration password complexity and history; it requires only a four-character password, with no complexity, and no history maintained.
As a compensating control, restrict access to the administration interface and leverage an additional authentication method such as Windows login. In the Cisco lab, the configuration of the CS-ACS was allowed only from the server desktop, and remote web access was only allowed from the two management platforms that required it (CiscoWorks LMS and CS Manager).
Connectivity was further restricted to allow only HTTPS connections. (See Figure D-9.)
Figure D-9 Access Policy Setup
Sessions were restricted to 15 minutes, and admin accounts disabled after three successive failed attempts. The automatic local login was removed. (See Figure D-10.)
Figure D-10 Session Policy Setup
PEAP authentication was configured for support of 802.1x when authenticating wireless or LAN users. (See Figure D-11.)
Figure D-11 Global Authentication Setup
Domains were configured against which to authenticate. (See Figure D-12.)
Figure D-12 Configure Domain List
The local CS-ACS groups were then mapped to similar Microsoft Active Directory user groups. (See Figure D-13.)
Figure D-13 Group Mappings for Domain
Local user mapping is performed dynamically between groups. No local user accounts exist directly in CS-ACS because of the limited password strength enforcement capabilities with regard to meeting PCI requirements. (See Table D-1.)
Logging was set to rotate authentication and system logs daily.
The best practice is to set the log file management to generate a new file daily, and have CS-ACS manage the directory to delete files older that 366 days or per your own security policy. This version of CS-ACS has a bug in that the manage directory feature is stuck on the seven-day default. To overcome this limitation, until an update is available, the manage directory was disabled for all logging. Removal of old logs is performed manually and an audit maintained via the CSA events for the log directory on CS-ACS.
As an additional measure, all log files are also copied daily to the Log backup server via a scheduled batch file. (See Figure D-14.)
Figure D-14 Log File Management
Each network device that is authenticating against the CS-ACS was defined individually, but all were given the same key. Different keys can be used for different groups of devices, and Cisco recommends rotating the keys quarterly. (See Figure D-15.)
Figure D-15 AAA Client Authentication
With the installation of CiscoWorks components and Cisco Security Manager, several shared profile components were added that allow greater refinement in role-based access to these products when authenticating to CS-ACS. (See Figure D-16.)
Figure D-16 Shared Profile Components
Cisco Security Manager
This section describes the firewall rules in place for the Cisco Retail Store PCI Certification Lab. This section also contains firewall use methodology as well as explanation for the rules used within the firewall for ease of explanation during audit.
Firewall Use Methodology
The firewalls used within the Retail PCI design are based on the Cisco IOS running on specialized Cisco router hardware at the branch, FWSM on the Internet Edge, and the Adaptive Security Appliance at the data center WAN aggregation layer. Throughout this document, references to firewalls or routers are synonymous because the devices provide both functions. The firewall policy can be applied to particular interfaces in an inbound and/or outbound methodology. The management of the firewall configuration is achieved by either Cisco Security Manager (CS-M), a centralized, GUI-based management product, or by the GUI-based local device management software such as the Adaptive Security Device Manager (ASDM) for the Adaptive Security Appliance. Based on the belief that there will be many similarly deployed store implementations, the baseline for devices is divided into small, medium, and large store deployments. The use of Cisco Security Manager detailed here is designed to achieve the proper level of security to each store while keeping the complexity of management to a minimum to reduce errors and oversight.
The management paradigm is based on the following five principles:
1.
2.
3.
4.
5.
Firewall rules are applied in a single-match, top-down, one-at-a-time manner. All firewalls at the store sites have the same policy, which is detailed below. The following four tables signify the different pieces of a hierarchical policy. All of them are combined together to form a single security policy.
Global CS-M Access Policy (Mandatory)
Store Policy (Mandatory)
Store Policy (Default)
Data Center WAN Access Policy (Mandatory)
1
deny
any
any
IP
All-Interfaces
in
Log (IOS)
Drop anything that is not explicitly allowed
CSA Manager
CSA was installed using the typical installation steps available in the published documentation. After CSA manager was installed, a policy was created to use CSA to protect the various logs on the CS-ACS server. This is similar to the process used to protect the logs on the other management servers.
First a new policy was created and named "A_PCI LAB Policy". Then a Windows Rule Module was created called "A_PCI Sensitive LAB Data", and associated with the policy "A_PCI LAB Policy". (See Figure D-17.)
The Rule module initially contained two combined policy rules. The first was to monitor and alert on the log files for all management servers (CSA, CS-ACS, CS-M, C-LMS, WCS and the Mars logs on the NFS backup server). The second was to protect the CS-ACS logs from access by any user or process other than the application processes via the web interface.
Figure D-17 Policy Configuration
The file access control rule with the description "A_ACS Protect logs" takes the action of denying and logging access to any files in the identified CS-ACS log directories except for the CS-ACS application processes.
The directories monitored include the following:
•
•
•
•
•
•
•
•
The permitted processes are identified as follows:
•
•
•
•
•
•
•
•
•
•
•
These were located in the "C:\Program Files\CiscoSecure ACS v4.0\bin" directory. (See Figure D-18.)
Figure D-18 Management Center for CSA
These rules use the CSA agent to enforce blocking of a user or other process from making any direct changes to the files in the prescribed folders.
When a user attempts to save a change, they receive the error message shown in Figure D-19.
Figure D-19 Error Message
This created an Event in the CSA Manager Event Log (see Figure D-20.)
Figure D-20 CSA Manager Event Log
An event in the CS-MARS log was created as well (see Figure D-21.)
Figure D-21 CS-MARS Log
The CS-MARS log can be configured to send an e-mail alert, as shown in Figure D-22.
Figure D-22 E-mail Alert
The application is still able to exercise full control over all the files in the protected directories to manage the logs and perform log switches daily.
An attempt was made to prevent the application from being able to delete historical logs by setting the directory privileges for the system account to prevent file deletion. This was not successful because it also prevented the log switch/roll event that occurs daily. The recommended practice to ensure the integrity and availability of historical logs is to switch out the logs at least daily, and then copy or backup those logs to a protected storage location.
A batch file was created to copy the logs daily to the Log backup server, where CSA was then used to restrict access and protect these files. (See Figure D-23.)
Figure D-23 Batch File for Copying Logs
Following is an example of the batch file created to archive the log files off the various management servers:
REM===Backup ACS Server LOGS======================================REM===Map a drive letter to the admin share=======================net use x: \\TACACS\C$E:cd \ACSFOR /f "tokens=2-4 delims=/ " %%a in ('DATE/T') do SET /a oldyear=%%c-1FOR /f "tokens=2-4 delims=/ " %%a in ('DATE/T') do SET /a oldmonth=%%a-1If %oldmonth% EQU 0 set /a oldyear=%oldyear%-1If %oldmonth% EQU 0 set oldmonth=12If %oldmonth% LEQ 9 set oldmonth=0%oldmonth%REM===Remove Logs older than 1 year=============================FOR /F "" %%k in ('dir /a:d /o:-N /b %oldyear%-%oldmonth%*') do rd /s /q %%kREM===Make new folder for today's daily backup=====================FOR /f "tokens=2-4 delims=/ " %%a in ('DATE/T') do SET date=%%c-%%a-%%bmd %date%cd %date%REM===Copy Log Files to Server====================================md logscd logsxcopy "x:\Program Files\CiscoSecure ACS v4.0\Logs\*.*" /e /h /ocd \ACS\%date%MD CSAdmincd CSAdminxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSAdmin\Logs*.*" /e /h /ocd \ACS\%date%MD CSAuthcd CSAuthxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSAuth\Logs*.*" /e /h /ocd \ACS\%date%MD CSDBSynccd CSDBSyncxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSDBSync\Logs*.*" /e /h /ocd \ACS\%date%MD CSLogcd CSLogxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSLog\Logs*.*" /e /h /ocd \ACS\%date%MD CSMoncd CSMonxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSMon\Logs*.*" /e /h /ocd \ACS\%date%MD CSRadiuscd CSRadiusxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSRadius\Logs*.*" /e /h /ocd \ACS\%date%MD CSTacacscd CSTacacsxcopy "x:\Program Files\CiscoSecure ACS v4.0\CSTacacs\Logs*.*" /e /h /ocd \ACS\%date%md TACACS-Backupcd TACACS-Backupxcopy "x:\TACACS-Backup\*.*" /e /h /oe:cd \REM===Remove Share drive=============================net use x: /deleteREM===Sample Schedule Statement========================rem at 01:00:00 /every:m,t,w,th,f,s,su "e:\backupacs.cmd"Cisco Security Agent (CSA) Custom Policy for RSA Products
Based on QSA's request, a new custom policy "PCI_auditors_request" was created. This new policy is associated with two new window custom rule modules, which are as follows:
•
•
C:\Program Files\RSA File Security Manager
•
•
•
•
•
•
•
•
C:\Program Files\RSA Adapter Manager Common
•
•
•
•
•
•
•
•
•
•
•
C:\Program Files\RSA File Security Windows Adapter
•
•
•
•
•
Figure D-24 CSA Manager Event Log—RSA File Security Manager
The file access control rule with description "Monitor RSA File Security Manager audit logs" monitors attempts to read or write files matching the file sets listed below (see Figure D-25) in the RSA File Security Manager by all applications, if the attempt causes the process to be terminated or is denied. An event is logged when the rule is triggered.
The directories monitored include the following:
•
C:\Program Files\RSA File Security Windows Adapter\AuditLog
•
C:\Program Files\RSA File Security Manager\AuditLog
Figure D-25 CSA Manager Event Log —RSA File Security Manager Audit Logs
•
Figure D-26 RSA_RKM_10.2.3_10.2.6_10.5.5 File Access Control Rule
The file access control rule with description "RSA_RKM_audit_file_protection" denies unauthorized applications access to the RSA Key Manager log files .
In the example shown in Figure D-27, Notepad (the unauthorized application), is denied access to the RSA Key Manager log files. An event is logged when the rule is triggered.
The directories monitored include the following:
•
–
–
Figure D-27 CSA Manager Event Log—RSA Key Manager Tomcat Logs
Cisco Security Agent (CSA) Custom Policy for NCR
The following were created:
1.
2.
The Rule Module initially contained two combined policy rules. The first protects the files and executables in the NCR-ACS directory from unauthorized access. The second protects the NCR-ACS authorized applications from being overwritten.
Figure D-28 NCR Policy Configuration
The "NCR Advanced Checkout Solution" rule module protects the NCR-ACS directory and the executables associated with these applications from unauthorized access. The file access control rule with the description "PCI 11.5 NCR ACS directories and files" takes the action of denying unauthorized access to all the files and executables contained in the NCR-ACS directories. An event is logged when the rule is triggered.The NCR-ACS directories include the following:•
where @fixed can be any local drive where the \ACS directory is located.
The authorized NCR applications are:
Directories matching
–
–
–
Files matching
•
•
See Figure D-29.
Figure D-29 PCI-11.5 NCR ACS Directories and File, File Access Control Rule
The file access control rule with the description "PCI 11.5 NCR ACS directories and files" takes the action of denying unauthorized access to the PCI 11.5 NCR ACS directories and files. In the example shown in Figure D-30, the unauthorized application (explorer.exe) is trying to access the NCR POS system's NCR-ACS directory.
Figure D-30 CSA Manager Event Log - Accessing NCR POS System's ACS Directory
The file access control rule with the description "Protect NCR Executables from being overwritten" takes the action of preventing the authorized PCI 11 NCR Applications from being overwritten. See Figure D-31.
Figure D-31 Protect NCR Executables from Being Overwritten, File Access Rule
RSA Key Manager
RSA Key Manager Administration Console
This section describes the main use cases and configuration for Key Manager Administration console.
Starting and Stopping the Key Manager Server
The RSA Key Manager requires a startup key that can be stored on an HSM, entered manually at startup (in the form of a password) or cached locally to be replayed during a server restart. The Cisco PCI Retail lab configuration replays the cached password whenever the server is restarted. This enables no user interaction during restart. If this option is not selected, user intervention is required (see Figure D-32). If an HSM is used, the policies dictated by the deployment (possibly m of n) are invoked. If the key material is not presented, no key requests is serviced.
At installation time, the Key Manager Server can be configured to either start automatically (unattended restart) or, for added security, require a master password to be entered. The Enable Unattended Restart option, selected during installation, specifies that the Key Manager Server can service Key Manager Client requests immediately after a start or restart. If this option is not selected, then after a start or restart, Key Manager Client requests are ignored, and any attempt to access the Key Manager Administration Console is redirected to a Key Manager Startup page where an administrator must enter the master password that is set during the Key Manager Server installation.
Figure D-32 Key Manager Startup Page
Apache Tomcat was used in the lab environment. Whenever this Tomcat instance is stopped, the RSA Key Manager server stops taking requests. Upon restart the key material in the form of a password is presented automatically. The Key Manager Server is stopped via the application server for your deployment. In this case, we used Tomcat Apache as application server and the Key Manager was stopped by stopping the Tomcat Apache service.
RSA Key Manager Server and Client Deployment
Typical branch architecture could include the transmission of customer credit card data that could be exposed during transmission if encryption mechanisms are not employed. Figure D-33 shows a typical deployment scenario whereby customer credit card information is processed in the branch and encrypted for storage in the point-of-sale server. During the process key material is requested from the RSA Key Manager located in the data center. The key material is then used to encrypt the credit card data and may be transported over any secure point-to-point VPN tunnel (e.g., Cisco VPN) to be stored in the data center repository. This model provides security for both data at rest and data in transit.
Figure D-33 Typical Branch Deployment
In this scenario, the POS server becomes a client to the RSA Key Manager and requests keys based on the client's ability to establish a mutually authenticated SSL session with the RSA Key Manager and policy dictated by the security officer. In the lab environment, RSA Key Manager sample program was installed on a Windows XP PC (which acted as client to RSA Key Manager). Keys from the RSA Key Manager are requested via a command-line utility running on the RSA Key Manager Client's PC running Windows XP that leverages the RSA Key Manager Client (a sample program) application programming interface (API).
Successful key generation from a sample RSA Key Manager Client program running on Windows XP PC:•
•
•
•
•
•
•
•
•
•
Demonstrating Get Key Operation
Getting key by Key Class keyclass1...Key ID: 1508515971UUID: b8 36 ca b1 5a b8 46 46 80 2f b2 1b ac b5 a2 69 [.6..Z.FF./.....i]Aliases:Key class: KeyClass1Key Data:71 a5 17 97 2f a8 e4 a4 d1 83 4b 3a 01 60 35 c6 [q.../.....K:.`5.]7a 4a 03 60 d0 b8 1f c2 68 89 63 74 ba 97 2f 2d [zJ.`....h.ct../-]Integrity check:54 0a bb 5e 25 22 e3 2f 05 85 4a e9 87 c5 fa b6 [T..^%"./..J.....]bf 01 81 8c 04 63 c2 8d bd 46 f2 2b a7 61 a6 8f [.....c...F.+.a..]Attributes:Key algorithm: AES_256_CBCNot before: 1199314224893Not after: 1199400624893Create date: 1199314224893Not Before Generalized Time: 20080102225024ZNot After Generalized Time: 20080103225024ZCreate Date Generalized Time: 20080102225024ZKey version: 2.1Key type: UNKNOWNKey Format: RAWExportable: TRUEKey state: ACTIVATEDKey sub_state: PROTECT_AND_PROCESSKey state description: Internal creation.Key bytes (32 bytes):71 a5 17 97 2f a8 e4 a4 d1 83 4b 3a 01 60 35 c6 [q.../.....K:.`5.]7a 4a 03 60 d0 b8 1f c2 68 89 63 74 ba 97 2f 2d [zJ.`....h.ct../-]Demonstrating Key Sync Operation
Key ID: 1508515971UUID: b8 36 ca b1 5a b8 46 46 80 2f b2 1b ac b5 a2 69 [.6..Z.FF./.....i]Aliases:Key class: KeyClass1Key Data:71 a5 17 97 2f a8 e4 a4 d1 83 4b 3a 01 60 35 c6 [q.../.....K:.`5.]7a 4a 03 60 d0 b8 1f c2 68 89 63 74 ba 97 2f 2d [zJ.`....h.ct../-]Integrity check:54 0a bb 5e 25 22 e3 2f 05 85 4a e9 87 c5 fa b6 [T..^%"./..J.....]bf 01 81 8c 04 63 c2 8d bd 46 f2 2b a7 61 a6 8f [.....c...F.+.a..]Attributes:Key algorithm: AES_256_CBCNot before: 1199314224893Not after: 1199400624893Create date: 1199314224893Not Before Generalized Time: 20080102225024ZNot After Generalized Time: 20080103225024ZCreate Date Generalized Time: 20080102225024ZKey version: 2.1Key type: UNKNOWNKey Format: RAWExportable: TRUEKey state: ACTIVATEDKey sub_state: PROTECT_AND_PROCESSKey state description: Internal creation.Get Key Successful
C:\rkm\samples\2.1
RSA Key Manager Logging
The Key Manager Server provides logging of runtime operations to a log file, for audit purposes. All log messages include the time and date, the full class name of the file where the log message was generated, the level of the log message and context information from the application.
Logging Levels
The Key Manager Server provides the following levels of logging:
•
Debug messages are produced to allow diagnostic and application management of the Key Manager Server.
•
Information messages are produced when:
–
–
–
–
–
–
•
Error messages are produced to report on all error conditions that arise in the Key Manager Server at run time. An error condition is any abnormal state of the system that stops the Key Manager Server from executing a business process (for example, the inability to access system resources such as memory or disk space).
The system administrator specifies the logging level, and the Key Manager Server outputs log messages that are greater than or equal to the specified logging level. Table D-1 shows the types of messages that are logged at each logging level.
Figure D-34 shows the RSA Key Manager logging in the lab environment (C:\Program Files\Apache Software Foundation\Tomcat 5.5\logs).
Figure D-34 RSA Key Manager Logs
Figure D-35 shows the RSA WebServer logging (Microsoft IIS 6.0).
Figure D-35 Web Server Logging
RSA File Security Manager
Detailed System Architecture
Figure D-36 illustrates a typical store architecture. In this architecture, the stores have a POS server that aggregates the transaction logs at each store before transmitting them to the central repository at the data center. To comply with PCI-DSS requirements, merchants are required to secure the transaction log data stored at each POS server and the central repository.
In this specific example, the transaction log data is stored in files, in a folder called "D:\TLOG". These files are then replicated across to the server attached to EMC storage in Cisco data center for transaction log repository when possible. The TLOG repository stores the files in a folder called "X:\TLOG". Due to significant sizing and performance requirements, this server's file system resides on an EMC Symmetrix-based Storage Area Network (SAN).
Before RSA File Security Manager is used to secure data at rest on the payment systems, the sensitive data in the files stored on the POS Server and the TLOG repository are subject to a variety of internal and external threats.
Figure D-36 POS System and TLOG repository without RSA File Security Manager
Figure D-37 illustrates the same store infrastructure as Figure D-36, after the RSA File Security Manager components are incorporated into it. RSA File Security Manager does not impose or require and specialized or additional hardware requirements.
The RSA File Security Manager "file system adapters" are installed on each POS server and the central TLOG repository server. In this scenario, these servers run a general purpose operating system such as Windows 2003 Server. The file security adapters are managed and administered from the central data center via the RSA File Security Manager management console (aka "the adapter manager").
Figure D-37 POS system and TLOG repository with RSA File Security Manager
Detailed Configuration Steps
Note
There are two types of security custodians who manage RSA File Security Manager. The Security Administrator (SA) is at the top of the hierarchy. The SA's duty is to manage the lifecycle of Security Officers (SO). The SA has no visibility into the servers or the files/folders that are secured by the file security adapters.
The SO's role is to manage the security policy for the servers/systems that have the file security adapters installed. The SO has visibility into references to encryption keys and high-level file system structure. But, note that the SO has no visibility into the actual data in the protected file system.
RSA File Security Manager implements this security model to ensure that we can achieve separation of duties between system administration, actual usage, and security administration. When RSA File Security Manager uses with your server infrastructure, you can ensure that there is no single entity/person who can compromise the security of your system either by accident or malice.
Figure D-38 illustrates the workflow involved with the management of SOs. This is what the SA sees on the RSA File Security Manager graphical management console after a successful login.
Figure D-38 SO Management Screen
To ensure that events and actions associated with security administration as well as access to secured folders are non-repudiable, RSA File Security Manager captures a detailed audit trail of all events and actions. Figure D-39 illustrates the audit log, which is visible to the security administrator.
Figure D-39 SA Access to Audit Log
The SO's management console looks very different from that of the SA's. A sample GUI is shown in Figure D-40. All security administration is performed by a simple, graphical workflow.
Figure D-40 SO GUI
RSA File Security Manager implements a role-based access control methodology. First, the security officer has to define a role and specify what type of access members the role has. Next, the security officer has to specify members of the role, which can either be local or domain users and fingerprinted applications.
For authorized users and applications, the file security adapter's default policy transparently "encrypts" file data when data is written and transparently "decrypts" file data when data is read. An example of a role is illustrated in Figure D-41.
Figure D-41 A Sample Role Screen
PCI Section 6.5
The requirement for PCI 6.5 section was met using Cisco ACE XML Gateway product. Verizon Business observed the use of Cisco's ACE XML Gateway to protect against common web vulnerabilities identified under PCI section 6.5.1 to 6.5.10.
Open Web Application Security Project (OWASP)
The OWASP top ten provides information and awareness about web application security. The OWASP top ten focuses on a broad agreement about what the most critical web application security flaws are. The primary aim of the OWASP top ten is to educate developers, designers, architects, and organizations about the consequence of the most common web application security vulnerabilities. For more information, visit - http://www.owasp.org.
In the PCI DSS 1.2 specification, the OWASP Top 10 are based on the 2008 list. The earlier version of the PCI DSS 1.1 was based on the OWASP Top 10 of 2006.
PCI 6.5.1 Cross-Site Scripting (XSS) Attacks
Cross site scripting, better know as XSS, is a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.
XSS allows attackers to execute scripts in the victims browser, which can hijack user sessions, deface websites, insert hostile content, conduct phising attacks, and take over the user's browser using scripting malware.
Environments Affected
All web application framework are vulnerable to cross scripting.
Implications
•
•
•
•
Verizon Business observed the use of ACE XML Gateway to protect web applications from XML and HTML-based XSS attacks. For example, ACE XML Gateway can prevent submission of XML and HTML tags to the web server (required for XSS attacks). All XSS attacks were manual and required custom configuration of the ACE XML Gateway application.
In the PCI lab environment, a malicious script is echoed back in an HTML format returned from a trusted website. The script is locally executed on the client PC.
Figure D-42 XSS Example
Mitigation
The Cisco ACE XML Gateway offers the following two ways of protecting a site from XSS:
•
•
In the lab environment, whitelist approach was used to show how the Cisco ACE XML Gateway can block XSS attack.
Cisco ACE XML Gateway Blocking XSS Attack
The following are the steps for setting XSS attack blocks in the Cisco ACE XML Gateway.
Step 1
Figure D-43 Defining Which Hosts Need to Protected
Step 2
Figure D-44 Defining Policies Per Host
Step 3
Figure D-45 Defining GET and POST Query Parameter
Step 4
Figure D-46 Detection of Attack and Blocking
Event log can be found under Reports and Tools section of the Cisco ACE XML Gateway (see Figure D-47).
Figure D-47 Event Log—Invalid Message
For more information on request message specification and configuration in the Cisco ACE XML Gateway Configuration Guide (v5.1), refer to the following URL:
http://www.cisco.com/en/US/products/ps7314/products_installation_and_configuration_guides_list.html
PCI 6.5.2 Injection Flaws Injection)
Injection flaws, particularly structured query language (SQL) injection, are common in web applications. There are many types of injections: SQL, LDAP, Xpath, HTML, and XML. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the applications and the underlying systems.
Environments Affected
All web application framework that use interpreters or invoke other processes are vulnerable to injection attacks. In the PCI lab environment, the attacker injects a "single quote" in a application (see Figure D-48). The user supplied data is interpreted by the application code as command and query or data. The application error message reveals the database structure as shown in Figure D-48.
Figure D-48 Injection Flaw Example
Figure D-49 Application Error Message
Verizon Business observed the use of the Cisco ACE XML Gateway to protect web applications from XML and HTML-based SQL injection attacks. Limiting input to specific criteria, including restricting required characters/strings for SQL attacks, was demonstrated to prevent such attacks. All SQL injection attacks were manual and required custom configuration of the Cisco ACE XML Gateway application.
For more information on the Cisco ACE XML Gateway configuration (v5.1), refer to the following URL:
http://www.cisco.com/en/US/products/ps7314/products_installation_and_configuration_guides_list.html
PCI 6.5.6 Information Leakage and Improper Error Handling (Do not leak information via error messages or other means)
Applications can unitentionally leak information about their configurations, internal workings or violate privacy through a variety of application problems (see Figure D-50, for example). Applications can also leak internal state via how long they take to process certain operations or via different responses to different inputs, such as displaying the same error text with different error numbers. Web applications often leaks information about their internal state through detailed or debug error messages. Often, this information can be used to launch or even automate more powerful attacks.
Environments Affected
All web applications framework are vulnerable to information leakage and improper error handling.
Implications
•
•
Figure D-50 Improper Handling Example
Mitigation
In the lab environment, Verizon Business observed the use of the Cisco ACE XML Gateway to protect web applications from XML and HTML-based error handling vulnerabilities. HTML/XML errors from the web server can be intercepted by the Cisco ACE XML Gateway and rewritten as a generic, non-descriptive error message. This was demonstrated during the review. All error handling attacks were manual and required custom configuration of the Cisco ACE XML Gateway application to prevent improper error handling.
The AXG can return customized messages or page instead of standard HTTP return codes as shown in Figure D-51.
Figure D-51 Customized Message Configuration
For improper error handling, the AXG can offer full regular expression-based search and replace functions for request and response. Figure D-52 shows how the response message was replaced with new string.
Figure D-52 Improper Error Handling Request
A content screening rule is a regular expression that defines the content to be matched in the outgoing or incoming messages. The custom content screening rule can be accessed from policy portion of navigation menu (see Figure D-53).
Figure D-53 Custom Content Screening Rule
Here the string "Topic Search" was replaced with string "General Query" in the response message as shown in Figure D-54.
Figure D-54 Improper Error Handling Response
The associated event log generated by the replacement of "Topic Search" with string "General Query" is shown in Figure D-55. The replacement activity was configured as "searchreplace" in the custom content screening rule.
Figure D-55 Event Log Search and Replace
For more information on Custom Content Screening Rule configuration, refer to the Cisco ACE XML Gateway Configuration Guide (v5.1) at the following URL:
http://www.cisco.com/en/US/products/ps7314/products_installation_and_configuration_guides_list.html
