PCI Compliance - Where's the Beef?

I might be dating myself a bit when I reference the old Wendy's ad, but I find myself compelled to beacuse it sums up the PCI Compliance rackets unfolding before our eyes. SO I must ask - Where's the beef?

I just did a Google Search on PCI Compliance, and got a lot of data but no real information back on the first page of the search. What I got was a lot of scanning/reporting/discovery links and solutions, but no real solutions. It's the equivalent of looking for a hamburger and getting all bun. Not what I had in mind. So what did I have in mind?

How about a reference architecture?

How about something other than a nice neat document format to tell me what I already know, just repurposed and re-formatted so I get credit for producing data, vs. producing results and solutions (which is what my bonus is tied to)?

How about something specific for a solution other than self assessment forms?

How about a bullet by bullet breakdown of a solution as it relates to each part of the PCI Specification?

How about some information that I can use? That I can validate/invalidate for myself in my environment? That does something more than tell me what I already know with absolutely no direction or opinion on what I could do?

Keep reading folks. I will share what I know, what I learn, and let you decide if it's right for you, and how useful the solutions are.

pcistuff@gmail.com

PCI Sample Architecture

I have been asked quite a bit to produce a diagram that outlines at a high level, a sample architecture. I finally did it and it is posted above. There are a few things I want to point out:

1. I am no Visio expert, but you should get the point
2. This diagram assumes you have encryption on the network already
3. This solution will cost less than $100,000 and you can also add in the benefits of NAC with the same architecture.

Bottom line is that this is simple, powerful, it's deployed in production today (I helped design the solution) at a customer site, and inexpensive considering all it does. Ping me if you want to know more - pcistuff@gmail.com

Requirement 4 - All about Encryption

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


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

•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 TNT allows organizations to terminate access to ALL environments in seconds, even if the employee has access to an organization owned machine
• Restrict access based on media access code (MAC) address. TNT is more comprehensive than this. MAC addresses can be spoofed. Multiple serial numbers from multiple hardware attributes combined with authenticated user data cannot.
•4.2 Never send unencrypted PANs by e-mail.

PCI Requirement 3

This is some of the meat of the spec, in my opinion. This is yet another area for managed service providers to develop a solution for this. It wouldn't be that hard.

Requirement 3: Protect stored cardholder data


•3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
•3.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:
–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
–In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the accountholder’s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business. NEVER store the card verification code or value or PIN verification value data elements. Note: See “Glossary” for additional information.
–3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions
•Note: See “Glossary” for additional information.
–3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.

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

If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.”
–3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control

Payment Card Industry (PCI) Data Security Standard 5
–mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.

•3.5 Protect encryption keys used for encryption of cardholder data against both disclosure and misuse.TNT will allow a company to restrict and audit in real time, access to all sensitive data. Including access to the network, the server, and the application in which it is stored. TNT will also cloak all of the sensitive assets so that if a user using a specific machine tries to access an application.
•3.5.1 Restrict access to keys to the fewest number of custodians necessary TNT will enable and enforce from 2 to n users from 2 to n specific machines
•3.5.2 Store keys securely in the fewest possible locations and forms.

•3.6 Fully document and implement all key management processes and procedures for keys used for encryption of cardholder data, including the following:
–3.6.1 Generation of strong keys
–3.6.2 Secure key distribution
–3.6.3 Secure key storage
–3.6.4 Periodic changing of keys
As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically. At least annually. The TNT Solution offers one of the most compelling ways to handle this that I've seen. Their software binds the user's fully qualified domain name (post authentication) AND a unique machine ID together, hashes and encrypts it and then inserts it into the packets leaving a machine. This means that if the machine is lost and/or compromised that the machine and the user will noyt be able to gain access to that application from that device again. If hardware changes on the machine (someone installs another hard drive with hacker tools) then the machine invalidates itself and must get a new software key.
–3.6.5 Destruction of old keys
–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)
–3.6.7 Prevention of unauthorized substitution of keys
–3.6.8 Replacement of known or suspected compromised keys
–3.6.9 Revocation of old or invalid keys
–3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.

PCI Requirement 2

This entry covers Requirement 2 for PCI Compliance. In essence there is aquite a bit of common sense that went into this requirement, but as we see in other aspects of life, you should not ignore pointing out the obvious.


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


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

–2.1 Always change vendor-supplied defaults before installing a system on the network (for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts).
–2.1.1 For wireless environments, change wireless vendor defaults, including but not limited to, wireless equivalent privacy (WEP) keys, default service set identifier (SSID), passwords, and SNMP community strings. Disable SSID broadcasts. Enable WiFi protected access (WPA and WPA2) technology for encryption and authentication when WPA-capable. TNT will allow you to control access by endpoints allowing only users from authorized devices to access your environment

- 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).
–2.2.1 Implement only one primary function per server (for example, web servers, database servers, and DNS should be implemented on separate servers)
–2.2.2 Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function)
–2.2.3 Configure system security parameters to prevent misuse
–2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

-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. TNT will work with any encryption technology in place so that you can extend what you already have/own.

-2.4 Hosting providers must protect each entity’s hosted environment and data. These providers must meet specific requirements as detailed in Appendix A: “PCI DSS Applicability for Hosting Providers.” TNT’s solution is ideal for data centers, allowing the providers to audit, segment, and enforce entire customer environments with a single piece of technology. In fact if I were going to start a business, it would be to use TNT as a service offering to secure and audit the most sensitive data of customers.

Level 2, Level 3, and Level 4 PCI Solutions

I thought I would start another blog for pcistuff to keep it separate and distinct from my Identitystuff blog where I discuss Identity Management issues.

This initial entry is designed to lay out what specific parts of the PCI Specification I can satisfy in less than a week. At the highest level, I can't help with encryption or documentation, but anything to do with limiting access and auditability I will absolutely help with. The stuff in Red is where I will help. I also did all of the hard work for you if you are evaluating solutions.

PCI Requirements:

•Build and Maintain a Secure Network
–Requirement 1: Install and maintain a firewall configuration to protect cardholder data
–Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
•Protect Cardholder Data
–Requirement 3: Protect stored cardholder data
–Requirement 4: Encrypt transmission of cardholder data across open, public networks

•Maintain a Vulnerability Management Program
–Requirement 5: Use and regularly update anti-virus software
–Requirement 6: Develop and maintain secure systems and applications

•Implement Strong Access Control Measures
-Requirement 7: Restrict access to cardholder data by business need-to-know
-Requirement 8: Assign a unique ID to each person with computer access
-Requirement 9: Restrict physical access to cardholder data

•Regularly Monitor and Test Networks
-Requirement 10: Track and monitor all access to network resources and cardholder data
-Requirement 11: Regularly test security systems and processes

•Maintain an Information Security Policy
-Requirement 12: Maintain a policy that addresses information security

Specifics:

PCI Requirement 1

•1.1 Establish firewall configuration standards that include the following:
•1.1.1 A formal process for approving and testing all external network connections and changes to the firewall configuration TNT Does this in real time
•1.1.2 A current network diagram with all connections to cardholder data, including any wireless networks TNT Auto discovers users, machines, networks, servers, applications (port)
•1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone TNT will segment and enforce your policies by user, device, group, application, server, health posture or network
•1.1.4 Description of groups, roles, and responsibilities for logical management of network components TNT proactively manages this in real time
•1.1.5 Documented list of services and ports necessary for business TNT will auto discover ALL ports (even rogue) and allow you to report them in real time
•1.1.6 Justification and documentation for any available protocols besides hypertext transfer protocol (HTTP), and secure sockets layer (SSL), secure shell (SSH), and virtual private network (VPN) TNT logs all connection data between users, machines, and ports
•1.1.7 Justification and documentation for any risky protocols allowed (for example, file transfer protocol (FTP), which includes reason for use of protocol and security features implemented
•1.1.8 Quarterly review of firewall and router rule sets TNT will enable you to establish and audit policy in real time, before enforcement is enabled
•1.1.9 Configuration standards for routers.


1.2 Build a firewall configuration that denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment. This is what TNT’s solution does
1.3Build a firewall configuration that restricts connections between publicly accessible servers and any system component storing cardholder data, including any connections from wireless networks. This firewall configuration should include the following:

•1.3.1 Restricting inbound Internet traffic to Internet protocol (IP) addresses within the DMZ (ingress filters) TNT denies ALL connections that are not from a specific user, machine, IP address, etc. providing unparalleled control
•1.3.2 Not allowing internal addresses to pass from the Internet into the DMZ TNT will control access from and access to specific networks, machines, and resources in real time allowing specific segmentation policies to be set and proactively enforced.
•1.3.3 Implementing stateful inspection, also known as dynamic packet filtering (that is, only ”established” connections are allowed into the network) This is TNT’s core functionality – TNT controls access to resources and networks based on what identity attributes are in the SYN header of every TCP/IP packet on the network
•1.3.4 Placing the database in an internal network zone, segregated from the DMZ TNT establishes a virtual physical zone so that only one user from one machine has access to a single application, even if there are other applications on the same server
•1.3.5 Restricting inbound and outbound traffic to that which is necessary for the cardholder data environment TNT’s solution restricts by user, machine, subnet and health level
•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 TNT eliminates the need for this
•1.3.7 Denying all other inbound and outbound traffic not specifically allowed TNT does this in real time with unparalleled granularity
•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) Installing TNT’s solution behind an AP, allows you to track and control EVERY connection through it
•1.3.9 Installing personal firewall software on any mobile and employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network. TNT’s solution builds a unique and unalterable identity of each machine in the environment and combines this with authenticated user information to create pervasive identity against which access controls are applied

•1.4 Prohibit direct public access between external networks and any system component that stores cardholder data (for example, databases, logs, trace files). TNT would accomplish this by keeping all non identified/known users from any and all networks, infrastructure, applications and data in an enforced policy
•1.4.1 Implement a DMZ to filter and screen all traffic and to prohibit direct routes for inbound and outbound Internet traffic TNT will allow an organization to deny all signalling within and between networks in seconds
•1.4.2 Restrict outbound traffic from payment card applications to IP addresses within the DMZ. TNT will lock down specific resources by users, machines, and networks to each other
•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). TNT stops all masquerading of identity because we have a known users FQDN & unique machine ID hashed and encrypted and embedded in every packet. You cannot be anyone else from any other machine. TNT's solution is transparent to NAT. We always know it's you and what machine you're using.

Stay Tuned for PCI Requirement 2!!