The Falcon's View

II. The Requirements and Commentary

Following are the requirements listed within PCI with associated summary commentary and specification of actionable items.

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

Summary:
You need to implement a DMZ for your cardholder environment, within which you need to setup a bubble that contains the database wherein cardholder data is stored. You need to establish formal processes for approving and testing all firewall and router configurations and changes.

As part of this process, a current network diagram must be maintained, along with documentation of roles and responsibilities, and of all authorized services/ports that are exposed, along with a justification and description of security measures taken. In general, all "untrusted" network connections must be firewalled, including to the Internet, partner networks, and wireless environments. Rules must be narrowly focused, limiting both ingress and egress traffic.

Access controls into the cardholder environment must be IP-specific, must not expose internal (RFC1918) addresses (such as by using NAT with IP masquerading), and servers should not be allowed to open new egress connections. The firewalls must not be bypassable to the Internet and must be stateful inspection type firewalls. All rule sets must be reviewed at least every 6 months.

Action Items:
1. Establish firewall and router configuration standards.
* Document formal process for approving and testing all connections and changes.
* Maintain a current network diagram.
* A firewall is required at each Internet and DMZ connection point.
* Document roles and responsibilities for network management.
* All services/ports must be documented, justified, and secured.
* Rule sets must be reviewed at least every 6 months.

2. Firewall off untrusted networks, including the Internet and wireless networks.
* An “untrusted network” is any network not directly owned, controlled, or managed by your organization.
* Implement a DMZ for cardholder data within a further internal zone containing the database with cardholder data (a “bubble” or “enclave”).
* Specific configuration practices: use IP-specific rules that restrict both ingress and egress traffic based on a default deny-all stance, prevent bypassing the firewall, route internal address internally rather than through the internet, use stateful inspection firewalls, use NAT with IP masquerading to limit exposure of RFC1918 IP space, and be sure to properly secure, synchronize, and backup router and firewall configurations.
* 1.3.5 says “Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.” This requirement seems to be poorly written, but appears to mean that database servers in the bubble within the overall cardholder DMZ should only be allowed access to servers in the DMZ, and to nowhere else. Such a requirement could introduce interesting challenges for patch and vulnerability management if strictly adhered to.

3. Personal firewall software is required on mobile and employee-owned computers with direct Internet access.

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

Summary:
Change all vendor defaults. This includes passwords, SSIDs, SNMP strings, and anything else that could be used to expose cardholder data. Additionally, system configuration standards must be developed based on known good practices, including limiting to one primary function per server, disabling unnecessary and insecure services and protocols, configuring security parameters as appropriate, and removing unnecessary files and components. Remote administrative access must use a secured protocol.

Action Items:
1. Change default passwords, wireless SSIDs, and SNMP strings before deployment.

2. Develop system configuration standards based on known good practices that address the following:
* One primary function per server
* Disable unnecessary and insecure services and protocols
* Configure security parameter as appropriate
* Remove unnecessary files and components

3. Remote administration must use a secured protocol.

Requirement:
Requirement 3: Protect stored cardholder data

Summary:
Wherever possible, do not store cardholder data. You may not store the full magnetic strip data, the card-verification code/value, or the PIN or encrypted PIN block. You may store the cardholder's name, the primary account number (PAN), the expiration date, and the service code. With the exception of personnel authorized for specific business needs, display of the card number must be masked to at least the first six and last four digits (preferably less).

In storage, the PAN must me rendered unreadable using either a hash or strong encryption. If using disk encryption, then logical access has to be managed independent from the OS without the keys being tied to user accounts. Encryption keys must be stored securely and properly managed, with access restricted to a need-to-know basis, with minimum replication or duplication.

Formalized, documented key management must address key generation, secure distribution, secure storage, periodic key rotation (at least annually), retirement of old or compromised keys, split knowledge and dual control of keys, mechanisms to prevent the unauthorized substitution of keys. All personnel with access to key materials or systems must sign a key custodian form.

Action Items:
1. Minimize the storage of cardholder data through the development and enforcement of a data retention policy.

2. Strictly limit what data is stored and displayed. Specifically:
* Do not store the full magnetic strip, the card verification code/value, or the PIN or encrypted PIN block.
* Mask display of the full PAN to only first six and last four digits, maximum, with the exception of explicitly authorized personnel with a business need.
* Cardholder name, PAN, expiration data, and service code may be stored.

3. Render the PAN unreadable in storage using hashing, truncation, index tokens and pads, or strong encryption using good key management practices.
* If disk encryption is used, then logical access must be independent of the OS without the keys tied to user accounts.
* Access must be restricted on a need-to-know basis.
* Secure storage must be used with minimal replication or duplication.

4. Fully document and implement good key management practices that address the full lifecycle, including generation, secure distribution, storage, periodic key rotation (at least annually), and retirement of old or compromised keys.
* Key management practices must enforce split knowledge and dual control of keys, as well as preventing the unauthorized substitution of keys.
* Key custodians must sign a custodian agreement.

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

Summary:
Cardholder data must be protected with strong encryption when transmitted across public networks (e.g. Internet, wireless, GSM, GPRS). Industry best practices for wireless networks must be applied. An unencrypted PAN must never be transmitted using end-user messaging technologies (e.g. email, IM, chat).

Action Items:
1. Strong cryptographic controls must be used to protect the transmission of cardholder over open, public networks, including the Internet, wireless networks, GSM, and GPRS.

2. Industry best practices must be used for securing wireless networks (e.g. no WEP).

3. An unencrypted PAN must never be transmitted via end-user messaging technologies such as email, instant message (IM), or chat.

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

Summary:
Antivirus (AV) from a reputable AV vendor must be installed on any systems that are commonly afflicted with malware. AV must be current, active, and generating audit logs. These requirements must be addressed in security policy, including stipulating audit log retention of at least 12 months with 3 months immediately available (in accordance with 10.7).

Action Items:
1. Deploy a reputable AV solution to systems commonly afflicted with malware.

2. Ensure that the AV is current, active, and generating audit logs, in accordance with associated security policies and standards on the topic, and retaining the logs in accordance with 10.7 (at least one year, with 3 months online).

Requirement:
Requirement 6: Develop and maintain secure systems and applications

Summary:
Implement patch and vulnerability management policies and procedures. Critical security patches must be applied within 1 month, using a risk-based approach to prioritizing patches. Software must be developed using secure coding practices within a software development lifecycle. The lifecycle must address testing patches and configuration changes prior to deployment, including validating input, proper error handling, secure storage of cryptographic materials, secured communication, and access controls (preferably role-based). The lifecycle must also establish separate development/test and production environment, enforce separation of personnel duties between dev/test and prod, must not use life data in test/dev, and must clean up environments prior to deployment, including removing test data, test accounts, custom application accounts, user IDs, and passwords.
Custom code must be reviewed for vulnerabilities. Deployment must follow change control procedures that document the impact of the change, garner management sign-off, test operational functional, and prepare back-out procedures.

Secure web application development practices must be followed based, in part, on the work of OWASP, and addressing cross-site scripting (XSS), inject flaws, malicious file execution, insecure direct object refers, CSRF, information leaks and improper error handling, broken authentication and session mgmt, insecure crypto mgmt, insecure communication, failure to restrict URL access (enforced workflow, etc). Additionally, special security measures must be developed for public-facing web applications, including regular code review (at least annually) or the deployment of a web application (proxy) firewall.

Action Items:
1. Prioritize patches using a risk-based approach and apply them as appropriate
* “Critical security patches” must be applied within 1 month of release.

2. Deploy a vulnerability management plan that results in updates to configuration standards.

3. Leverage secure coding practices as part of a well-defined software development lifecycle, complete with quality assurance and code review capabilities.
* All patches and configuration changes must be tested to validate input, proper error handling, secure storage of cryptographic materials, secure communication, and role-based access controls (RBAC).
* The dev/test and production environments must be separated.
* Separation of duties must be enforced between dev/test and prod personnel.
* Live data must not be used in the dev/test environment(s).
* Test data and accounts, and custom application accounts, user IDs, and passwords, must be removed prior to production deployment.
* Custom code must be reviewed for vulnerabilities.
* Secure web application security practices, such as those advocated by OWASP, must be followed.
* The following code weaknesses must be addressed: cross-site scripting (XSS), inject flaws, malicious file execution, insecure direct object refers, cross-site request forgery (CSRF), info leaks and improper error handling, broken authentication and session mgmt, insecure crypto mgmt, insecure communication, and failure to restrict URL access (enforced workflow, etc).

4. Implement and following robust change control/management procedures. These procedures should:
* Document the impact of the change.
* Garner management sign-off for the change.
* Test operational functionality prior to deployment.
* Include back-out procedures.

5. Special security functionality is required for public-facing web applications in the form of either regular code reviews (at least annually) or deployment of a web application (proxy) firewall (for Apache users, check out ModSecurity at http://www.modsecurity.org/).

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

Summary:
Based on the principles of default deny-all and least privilege, limit access to cardholder data on a need-to-know basis. Implement an automated access control system based on roles that covers all system components.

Action Items:
1. Using automated access controls in a default deny all configuration, limit system and data access as is explicitly authorized and needed for business functions.
* Role-based controls must be based on the principles of least privilege and default deny.
* The role-based access control systems must cover all system components.

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

Summary:
All users must be assigned, and use, a unique ID that is protected by a password, passphrase, or 2-factor credentials. Remote access must be protected by 2-factor authentication. Passwords must be protected by strong cryptography (hashing is fine). All access to databases containing cardholder data must be authenticated.

User management processes must be well defined. Identities must be verified before allowing password resets. First-time passwords must be set to a unique value and an immediate password change must be forced at first use. Accounts for terminated personnel must be removed immediately. Accounts inactive for 90 days must be removed or disabled, while vendor maintenance accounts must be disabled at all times unless in use. Group, shared, or generic accounts are not to be used.

Passwords must be changed at least every 90 days, must have a minimum length of 7 alphanumeric characters, with a history of 4 passwords. 6 failed login attempts must result in a locked account, which should persist for 30 minutes unless overridden by an administrator. Accounts idle for 15 minutes must lock or logout. Password policies must be clearly communicated to all personnel.

Action Items:
1. Assign all users a unique ID and a password, passphrase, or 2-factor credentials.
* 2-factor authentication is required for remote access.
* Do not use group, shared, or generic accounts or passwords.
* All individual access to cardholder databases must be authenticated.

2. Implement proper, well-documented identity and access management.
* First-time passwords must be set to a unique value and the first login must force an immediate password change.
* Identities must be verified prior to resetting passwords or accounts.
* Passwords must be protected using strong cryptographic methods (hashing is acceptable).
* Accounts assigned to terminated personnel must be disabled or removed immediately upon termination.
* Vendor maintenance accounts must be disabled unless in use.
* Accounts inactive for 90 days must be disabled or removed.
* Passwords must be changed at least every 90 days.
* Passwords must be a minimum of 7 alphanumeric characters in length.
* A minimum password history of 4 must be set.
* Accounts must be locked or disabled after a maximum of 6 failed login attempts, resulting in a minimum 30-minute lockout, unless overridden by an administrator.
* Idle logins must timeout after at most 15 minutes, requiring the user to re-enter their credentials.
* All password policies must be communicated to applicable personnel.

Requirement:
Requirement 9: Restrict physical access to cardholder data

Summary:
Implement strict physical security controls around your cardholder environment, leveraging automated access control and monitoring mechanisms (badges, cameras, etc.), and retaining all audit/access logs for at least 3 months (unless otherwise restricted by law). All control and monitoring mechanisms must themselves be physically protected. Access logs should be reviewed and correlated (for example, badge access should correlate to video monitoring). Access to enabled network jacks, wireless APs, gateways, and handheld devices must be restricted.
A badging system must be implemented to effectively manage visitors, including requiring explicit authorization for visitors wishing to access the cardholder environment, issuing a physical token that expires, and requesting surrender of the token prior to visitor departure. Access should be logged and retained for 3 months (unless prohibited by law), capturing details including the visitor's name, company represented, and employee authorizing the visit.

Policies and procedures must be documented and enforced pertaining to the control and security of physical data. Materials must be clearly classified and labeled, backups should be maintained off-site, secure couriers or other trackable delivery methods must be used, and physical security must be reviewed at least annually. Management must approve all physical moves of cardholder data, media with cardholder data must be inventoried at least annually, and must be securely destroyed when no longer required (e.g. shredded, incinerated, pulped, or otherwise rendered unrecoverable). These practices and requirements apply to all types of media, including paper.

Action Items:
1. Implement facility access controls.
* Implement a badging system to easily distinguish between employees and visitors.
* Define specific visitor handling procedures that garner explicit authorization for accessing the cardholder environment, including assigning a physical token that expires (e.g. badge, sticker), and request surrender of the token at the end of the visit.
* Establish and retain (minimum 3 months, unless otherwise restricted by law) a visitor log that captures visitor name, entity represented, and the authorizing employee.

2. Implement facility monitoring.
* Deploy video cameras or other access control mechanisms to monitor access.
* Review and correlated collected data, and retain data for at least 3 months, unless otherwise restricted by law.
* Protect cameras and other mechanisms from tampering or disabling.

3. Implement physical security measures.
* Restrict access to enabled network jacks, wireless access points (APs), gateways, and handheld devices.
* Store back-up media in a secure location (preferably off-site) and review these security measures at least annually.
* Physically secure all paper and media containing cardholder data, including clearly classifying and labeling confidential materials.
* Maintain inventory logs of all media and conduct and inventory audit on at least an annual basis.
* All physical moves of cardholder data require management approval and, if shipped, must use a secured courier or other trackable delivery method.
* Media should be securely destroyed when no longer required, such as through shredding, incineration, or pulping physical media, or otherwise rendering electronic media unrecoverable.
* Publish physical security policies and procedures.

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

Summary:
Merchants are required to implement reasonably extensive audit logs for the cardholder environment, capturing individual access to cardholder data, all root/administrator actions, invalid logical access attempts, use of identification and authentication mechanisms, creation and deletion of system-level objects, access to audit logs, and the initialization of the audit logs. Logs are to be retained for at least a year, with 3 months of data immediately accessible. The minimum details to be logged include user identification, type of event, date and time, event disposition (success/failure), origination of the event, and identity of the name of the affected data, system component, or resource.

To support analysis, all servers should be synchronized to a proper, reliable time source (NTP server - there are more details about this, but suffice to say it needs to be locked down and explicitly allowed). Logs must be reviewed on a daily basis, though automated tools can be used to meet the requirement.

Action Items:
1. Implement and secure detailed audit trails.
* Capture all individual access to cardholder data, all root/administrator actions, all access to audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialization of audit logs, and the creation and deletion of system-level objects.
* Audits logs must minimally capture user identification, type of event, data and time, event disposition (success/failure), event origination, and identify the name of the affected data, system component, or resource.
* Audit trails must be secured, limiting access on a need-to-know basis, protecting the integrity of the logs (including using of integrity monitoring solutions), and backing the logs up to a central server or media.
* Externally facing systems must log to an internal server.
* All systems generating logs must be synchronized to a common time source that has been setup in an approved manner and that is explicitly authorized to receive time updates from specific external sources.

2. Review and retain audit logs.
* Logs must be review on a daily basis, though tools may be used to meet this requirement.
* Audit trails must be retained for at least one year, with at least 3 months online and immediately available.

Requirement:
Requirement 11: Regularly test security systems and processes

Summary:
Testing must be done on a quarterly and annual basis. Quarterly tests include checking for rogue wireless access points, external vulnerability scans, and internal vulnerability scans. Penetration testing (internal and external) must be performed at least annually and must target both networks and applications. A QSA or ASV is not required for penetration testing, but an ASV is required for the external vulnerability scans. Additionally, IDS/IPS must be in place to monitor access to cardholder data, as does file-integrity monitoring software.

Action Items:
1. Mandatory quarterly tests:
* Rogue wireless access point scans.
* External vulnerability scans by an ASV.
* Internal vulnerability scans with rescans until clean.

2. Mandatory annual tests:
* Internal network and application penetration tests.
* External network and application penetration tests.
* No QSA or ASV requirement, tester just must be qualified.

3. IDS/IPS and file-integrity monitoring software must be deployed to monitor access to cardholder data and to protect associated systems.

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

Summary:
Security policies must be drafted and maintained that address all PCI DSS requirements, and that including processes for formal risk assessment, risk management, and annual review and update of policies. The security policy framework must include the development of daily operational security procedures and must clearly define roles and responsibilities.

Usage policies must garner explicit management approval per person and device, and must explicitly inventory and track what is approved for whom, including labeling devices with owner, contact, and approved purpose, as well as explicitly detailing acceptable uses and network locations. Requirements that were previously noted must be codified, too, including automatic disconnect of idle remote sessions and disabling vendor remote access unless active. Mythically, usage policies must prohibit the copying, moving, and storage of cardholder data to local drives or media when being remotely accessed (called “mythical” because of it’s unenforceability).

Security management responsibilities must be clearly defined to establish, document, and distribute security policies and procedures, monitor and analyze security alerts and information, distribute security alerts and information as appropriate, establish, document, and distribute incident response and escalation procedures, administer user accounts, and monitor and control all access to data.

A formal security awareness program must be implemented and run at least annually, including garnering written acknowledgement of reading and understanding security policies and procedures. Background checks must be implemented as part of candidate screening. An incident response plan must be implemented. And, last but not least, if you share data with service providers, then you'll need to apply all of this good stuff to them as well (and make sure you get it into your contracts).

Action Items:
1. Publish security policies, standards, and procedures.
* Policies must address all applicable PCI requirements.
* Policies must include an annual process for formal risk assessment and risk management.
* Policies must undergo an annual review, incorporating appropriate updates.
* Policies must clearly define roles and responsibilities.
* If cardholder data is shared with service providers, then all policies and procedures outlined in the security program must be applied to the third parties as well.
* Develop daily operational security procedures.
* Implement an incident response plan.
* Implement background check as part of candidate screening.

2. Develop usage policies for critical employee-facing technologies.
* Usage policies should address topics such as remote-access technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants (PDAs), e-mail usage and Internet usage.
* All usage must be authenticated and explicitly authorized by management.
* Devices must be inventoried per person and labeled with owner, contact, and purpose.
* Devices must be authorized for specific uses and network locations.
* A list of company-approved products should be maintained.
* Usage policies must stipulate automatic disconnect for idle remote connections and the default disabling of vendor remote access.
* Policies must prohibit copying, movement, or storage of cardholder data on local drives and media while the data is being remotely accessed.

3. Assign security management responsibilities…
* …to establish, document, and distribution security policies, standards, and procedures.
* …to monitor and analyze security alerts and information, distributing as appropriate.
* …to establish, document, and distribute incident response and escalation procedures.
* …to administer user accounts.
* …to monitor and control all access to data.

4. Implement a formal security awareness program.
* The program must be run at least annually and requires written acknowledgment of reading/understanding security policy and procedures.