PCI Compliance: Detailed Requirements

PCI Compliance: Detailed Requirements

May 03, 2011 2:00 pm

(Save to cal)


Adam Goslin, co-founder of High Bit Security, will continue his 3 part series on PCI Compliance Hosting. In this second webinar, Adam will make a detailed analysis of the requirements of PCI Compliance.

Tuesday 5.3.11 @ 2pm

View Slides




Adam: Well good afternoon everyone. Welcome to the PCI DSS detailed review. My name is Adam Goslin, co-founder at High Bit Security. Want to start with a thank you to the crew at Online Tech for facilitating this webinar and opportunity to give everyone a detailed review of PCI DSS. If you were not here for last weeks webinar, we went over a high level review of PCI DSS. That is posted and available online if you missed it. We are going to go ahead and get right into this presentation.

A little bit about High Bit Security. High Bit helps companies obtain or maintain PCI compliance from Level 1 through Level 4 compliance. We also help identify with organizations where they stand against PCI DSS standards by performing a GAP analysis to see where they stand against the requirements, provide remediation advice, guide their team through the process, coordinate with their Qualified Security Assessor if going to Level 1 compliance, participate in your on site audit to ease your mind and assist with remediation items from the onsite audit. High Bit has an ongoing PCI Compliance management solution to mitigate surprises on your next year audit. That is the compliance side of High Bit.

On the other side of High Bit, we provide cost effective Penetration Testing (external or internal) against network and/ or application layers. Our manual Penetration Testing is performed by security engineers who hold industry recognized certifications, have done countless Penetration Engagements for people looking for PCI DSS specifically and also for companies looking for other compliance mandates or just looking for plain old security.

Here is a little bit of an introduction to PCI Compliance. Assistance when you are going through this process, especially in the beginning phases, is critical. Qualified guidance has the ability to save your company tens of thousands of dollars. Every environment is different. They all have different platforms, delivery mechanisms, technology already in place, skills of internal resources, skills of existing providers, etc. Every time that we approach PCI DSS it always comes with its own set of issues. There is no one size fits all regardless of what you have been told. If you store, transmit, process or receive cardholder data, be sure to do your homework when it comes to offers for PCI Compliant hosting solutions. A lot of vendors will offer up a one size fits all PCI Compliance solutions, when there are really thousands of ways to accomplish PCI compliance.

This session is going to be an extremely fast paced review of the PCI DSS requirements. These are not meant to be (nor will they be) all inclusive. We would be happy to share this presentation with any of the participants. Just send us an email at the end of the presentation and do not worry about keeping notes, because it is going to fly. Hopefully you have coffee in hand, because this is going to be a fun filled next 25 minutes!

There are some different areas of PCI compliance broken out into 12 requirements. We are going to just jump right into it.

Section 1: Install and maintain a firewall configuration to protect cardholder data.The first piece of PCI Compliance is related to installing firewall configurations to protect cardholder data. Infrastructure change control for review and approval of firewall changes needs to be in place. You also need to need to maintain a current network diagram (whether it is physical or logica) as well as cardholder data flow. Include all connections to Cardholding Data (CHD) including wireless.

Firewall configuration standards include: firewall placement in the environment, controlling rules for traffic, separating Cardholder Data Environment (CHDE); documented permission and roles; documented list of services, protocol and ports necessary for business purposes; review of firewall and router rule sets at least every six months; and security and synchronization of firewall configuration files also needs to be included. For mobile and employee owned computers with access to internet and CHDE they need to have personal firewalls configured to specific standard (i.e. you need to name that standard and document it) and be sure that personal firewalls are unalterable by employees.

Section 2: Using vendor-supplied defaults for system passwords and other security parameters. So you will need to disable and modify all vendor supplied accounts and passwords on system components. For wireless:

  • change wireless encryption keys at setup and as personnel change
  • change default accounts and passwords
  • update firmware to support strong encryption

For system configuration standards, it is based on industry accepted hardening standards. Basically, pick one and name it in the standards you have. Update those standards based on new vulnerabilities that are identified. This would apply to new systems that are stood up. One primary function per server with only necessary services and ports enabled. Regarding the one primary function per server, quite literally each server is supposed to have one primary function. So you cannot stand up one box and use it for everything with PCI. System administrators must have knowledge of common security parameter settings and you need to remove all unnecessary functionality (scripts, drivers, subsystems, etc.).

Basically what you are looking for when it comes to your system configuration, you are looking for machines that are hardened, bolted owned and have as little exposed functionality as possible, because that can mitigate the threat factors that can be used to compromise the system. Non console administrative access (network administrators connecting from their machines) need to have strong encryption for login and web based interfaces, remote login commands (telnet) not available internally. Shared providers must protect the environment and CHDE of each entity. So, if it is a platform of providers with a multi tenet system they must take steps to protect each of those environments.

Section 3: Protect stored cardholder data. You need to have policies in place for data retention with justification for keeping CHD, as well as policies for secure deletion. You need to remove any CHD that exceeds data retention policies and make sure that that process is validated quarterly. There is no storage of sensitive authentication data after authentication and secure deletion in the event that it is temporarily stored. This would include any full track data (the magnetic strip on the back), card verification value (the three or four digit code on the back of the card), and the PIN or the encrypted PIN block. You need to make the Primary Account Number (PAN) when displayed and this applies everywhere.

So if you have an instance where you need to display it on a web interface or put it in a report that could be printable, then you need to mask that PAN. The typical way that is done is ex-ing out all of the characters except the last four. There are less restrictive ways of doing it, but that is most common. The PAN must be unreadable wherever it is stored and this applies everywhere. So if you have a business requirement to store the PAN, then you must render it unreadable, i.e. encrypt it or another alternative if you do not require the storage of the PAN, just store it masked if that is applicable to your business.

Next is the disk encryption. You need a separate authentication system than the operating system, as well as secure cryptographic key storage to protect the disk or key encryption. For encryption key management when you are using or storing sensitive data make sure that you have as few custodians as possible.

Key custodians being the people who are actually in possession of parts of your encryption key. That the keys are securely stored and that the data encryption keys are separate from the key encryption keys. In other words the data encryption key should also be stored in a secure manner i.e. encrypted. That is what they mean that the keys for data encryption are stored separately from the encryption you use to encrypt those ones.

The encryption procedures themselves include making sure it is secure encryption, you have procedures any secure key distribution, secure storage, that you are periodically changing the keys, replacement of keys that are weakened or known or suspected to be compromised. This is done through split knowledge and dual control. In other words, no one person knows the full key to be able to decrypt the data by themselves. It takes at least two people to be able to decrypt the data. Also prevent unauthorized key substitutions, someone changing out the key without your knowledge. Key custodians then need to physically sign off on their responsibilities for performing that role.

Section 4: Encrypt transmission of cardholder data across open, public networks. Use strong cryptography wherever CHD is transmitted or received over open, public networks. Only support strong encryption (i.e. do not support any insecure encryption) and make sure that your CHD is not transmitted insecurely. What that basically means when we talk about not supporting insecure encryption, is you need to make sure on your web servers - if you are using https as an example - all of the ciphers that are loaded onto the web servers are strong encryption ciphers. In some cases you will get servers that have an insecure cipher loaded onto it and that is what they are looking to avoid.

For wireless, make sure you use industry best practices for strong encryption or authentication. For end user messaging make sure that the PAN is unreadable and strongly encrypted, as well as implementing a policy forbidding sending. The unreadable and strong encryption is if there is a business need for leveraging end user messaging. However, best recommendation is just set a policy in place that forbids that from happening.

Section 5: Use and regularly update anti-virus software on all systems commonly affected by malware. Anti-virus software is deployed if applicable anti-virus technology exists. Anti-virus programs detect, remove and protect against all known types of malicious software. For anti-virus configuration you have a policy covering anti-virus, regular updates, regular scans, generation of logs and that it is actually up and running on your systems.

Section 6: Develop and maintain secure systems and applications. This really covers a broad realm of things. Making sure that you regularly maintain your patching and that you have policy mandating patch releases within 30 days. The inference behind this one is that you are monitoring the patches that are applicable to your environment on a regular basis and giving yourself enough time to get those released within that 30 day window. In most cases patch reviews should be performed, if not weekly, greater than weekly. So you have to have enough time to be able to facilitate that.

For new security vulnerabilities, you need to be monitoring for any new vulnerabilities where you would apply a risk ranking and make sure you are leveraging outside resources for that information. You want to have one of your security engineers monitoring this. Software development standards should be based on industry standards and practices. There should be information security throughout the process and applications should be developed in accordance with PCI. The removal of any custom application accounts and user ID’s should be done before you move to production.

For change control, make sure you are doing at bare minimum your code reviews, using secure coding guidelines for the development of that code, making sure any corrections are done before the production release and that there has been a review and approval by management for that change control. That you have separate development tests, productions environments that have access controls. As well as separation of duties for those individuals you are leveraging your different areas of development, testing and production environments. Also make sure that you do not use live primary account numbers for development and testing and that any test data and accounts are removed before the move to production.

You also need to make sure that change control documentation includes: impact of the change control you are about to do, that it has an approval process, there was a functional testing provided, as well as back out procedures in the event that something goes sideways when you get to production and how you are going to back out of that change you just made out of the system. For secure coding you need to have developer training required for things like injection flaws, error handling, cross site scripting, etc.

You also need to implement one of two options: either a secure code review process or a web application firewall. If you go the route of the code review, you need to make sure it is somebody or an organization that specializes in security. Whether it is a third party or an internal resource and the note here is provided that they are independent from your development team. You do have the option of of implementing a web application firewall and that is always an interesting decision for an organization as to which direction it would prefer to head. Both have varying costs and different ways of implementing.

Section 7: Restrict access to cardholder data by business need-to-know. For user access make sure it is based on a least privileges methodology. That you have implemented Role Based Action Control (RBAC) where you have assigned rights that are based on a user role or function. The access must be approved and the access occurs through some sort of automated system. The access control system must be in place for all system components needs to be enforced based on the RBAC and there must be a default “deny all” that is set. In other words, if I do not have permission, I am not able to get it or do anything.

Section 8: Assign a unique ID to each person with computer access. All users are assigned a unique ID. Authentication is through something you know (password), have (token) or are (biometric). Two-factor authentication is in place for all remote access. So if you are trying to connect into your environment from afar, make sure that you have two factor authentication in place. Make sure your password files are unreadable; you control the addition deletion and modification of user accounts; verify user identity before you perform a password reset; the users are required to change their password upon initial authentication and that you immediately revoke access for any terminated users; and remove and disable inactive users accounts after 90 days. That could be done via an automated process or a manual process, that is your call.

Vendor accounts are enabled only as needed and disabled immediately after use. Training for all users on the authentication policy. Making sure that you change your password every 90 days. For passwords there are several requirements. Make sure that they contain more than seven characters that are alpha and numeric, they are not the same as any of your last four passwords, that you lock out a user after six fails, that lockout needs to be 30 min or until it is reset by an administrator who has verified the identity of the user. 15 minute idle session, in other words if I am sitting there and ave not done anything with my machine for 15 min it shuts me out and I have to re-authenticate. And finally authorize all data base access.

Section 9: Restrict physical access to cardholder data. This is where you make sure you have physical security for each area of the data center and console access. That you have video cameras for sensitive areas (i.e. entrances and exists) and that you keep those for at least 90 days of storage. That you restrict access to the publicly available network jacks. You restrict access to hardware and networking components. You have a visitor access system (badges, controlled system access, revoke access as required, etc.) For visitors they should have limited access, be escorted at all times and be required to relinquish their badges upon exit. You also need to maintain a visitor log.

Have secure backup storage and perform an annual review that is is such. Physically secure all media controls. Whenever you classify media that is created with sensitive data on it, make sure that it is classified and if it is ever sent, it is sent via secured method. That you have management approval for any management movement and log all of the media storage and access. And if you have a need for physical destruction of media that you do so with physical destruction. Shredding of any sensitive data and electronic media rendered is unrecoverable. That can actually be done through a couple of different ways either using a security wipe tool or simply a hammer.

Online Tech is that they actually has a multiple Level 1 PCI compliant vendors in their facilities and have gone through several audits for all of these requirements. So I would recommend them.

Section 10: Tracking and monitoring all access to network resources and cardholder data. This covers a whole bunch of different elements, including central logging. Central logging includes:

  • making sure you have audit trails enabled and active
  • individual access to CHD is tracked
  • any administrative actions
  • access to the audit trails themselves
  • invalid logical access attempts
  • use of identification and authentication mechanisms every time someone logs in
  • initialization of the audit logs

In other words if they are ever reset that that act is logged. As well as the creation and deletion of any system objects. For the types of details that are required for logging you need to have the user, type of event that it was, the date, the time, whether it was a success or failure of an event, where it originated from, the name or identity of the affected data, system component or resource. You also need to implement time synchronization technology, this must be implemented.

For example, Network Time Protocol (NTP), where only the central servers are receiving the time data and the computers are pulling from a central location. Access to the time data is restricted. As well as the time data is only received from industry standard sources. For example when you set up your network time protocol, making sure you are using an external system as your source.

For audit trail security, you need to make sure that you have it setup to prevent any unauthorized modifications to the audit trails themselves. That they are being backed up to a central logging box and external facing technology is pushing their logs to central logging. As well as file integrity monitoring that monitors the log data itself. In other words it ensures the preservation of the information of your central logs. For the log review you need to review your logs for the systems on a daily basis and this covers all logs for the environments.

This must be done and must be documented. And as part of your log review process, as you find the anomalies, as you find things that need to have action taken on them, be sure action is actually being taken. For log retention you must have three months immediately available and with one year stored. The log retention requirements are pivotal in the event that you do have a breach, then you have a good solid location from which to go take a look at and monitor for the activities that were being performed against all of your various systems that are dumping logs into your central logging solution.

Section 11: Regularly testing security systems and processes. You need to have a process in place where wireless action point identification is done quarterly and your incident response must include wireless. That particular process can be done in a number of ways. It can be a manual validation, it can be done through a wireless scan, etc. External and Internal Vulnerability Scans: the externals must be performed by an external scan vendor or an ASV. They need to be done quarterly and if there is a significant environment change. In other words, if your are at the mid point between your quarterly scans and you make some massive change to your environment then you need to rework and run your vulnerability scans. You also need to perform internal and external penetration testing. They need to be done quarterly by an external resource or by a qualified internal source.

The qualified internal resource basically needs to have a good solid understanding and practice of application and network layer security. Some companies are fortunate enough to have their own internal security expert, but most companies are not. You also need to test after any major infrastructure or application upgrade or modification. So if you opt for a major version release that is coming out that you have planned for the first quarter you would need to re-perform your penetration testing.

For example, let's say you did your last penetration test in June and you have a new software release, you need to run another penetration test. That penetration test needs to cover both your network and application layers. You need to have an Intrusion Detection System in place. You need to make sure it is up to date, monitored and sending alerts. You also need to have File Integrity Monitoring in place within your environment. This too needs to be monitored, sending alerts and updated. The file integrity monitors should kick off at least weekly to go in and do a baseline check against the last time it was performed.

Section 12: Maintain a policy that addresses information security. What you want is a policy that is published and distributed to all relevant personnel. Whether it is internal personnel or external personnel (partners, service providers, etc.). The policy must address all PCI DSS requirements. You need to put in place an annual risk assessment process that would identify threats and the associated vulnerabilities which have the potential to negatively impact your business.

In other words, annually going out and taking a look at your environment, your space, your industry, the types of tools and technologies that you have and new threat factors that are coming out in the security arena that may impact your organization. Take the time annually to take a look at that. The policy must be reviewed annually i.e. your information security policy. Develop daily operational security guidelines. Daily tasks need to be done to maintain your security needs to be part of that policy.

You should also develop acceptable use policies that require management use of approval; authentication for use; device listing; labeling your devices; acceptable use policy for the devices; acceptable network locations; list of company approved products; automatic disconnects for remote technologies; etc. You need to define the information security management responsibilities for all personnel.

Also, assign the information security responsibilities for policy management, monitoring security alerts and information, incident response procedures and all access to data. For the implementation of a security awareness program it needs to be performed for all personnel. Every person that comes onto your staff upon hiring should be given the security awareness training and then for all other employees it needs to be performed annually there after. As part of that process, those participants needs to acknowledge that they have received that training.

Section 12 (continued): Perform background checks for all employees at hire that have access to sensitive data. The depth of those background checks should be commensurate with the employee responsibilities. In other words, the PC tech that may be exposed to CHD, is probably going to have a deeper background check than say the CIO. If the CHD is shared with service providers (back-up tape storage facilities, managed service providers such as Web hosting companies or security service providers, etc.) you need to maintain a list of those service providers; written agreements with those service providers; proper due diligence when selecting providers; as well as make sure that entity maintains PCI compliance.

For incident response plan inclusions, you need to have an incident response plan that denotes the roles, responsibilities, communication and contact strategies in the event of a compromise. Including, notification of the card payment brands at a minimum. You need to specify the incident response procedures, business response and continuity procedures, data backup processes, analysis of legal requirements for any compromises, coverage and responses for all critical components and that you reference the inclusion of incident response procedures from the applicable card payment brands. You also need to perform annual tests against your incident response plan, have 24x7 alert response and provide staff with periodic training. Make sure alert monitoring is included in that process and that you periodically review and enhance your incident response plan.

Believe it or not that covers the detailed review of requirements for PCI DSS! There is going to be an upcoming webinar next week that will cover in depth the PCI requirements for Penetration Testing and Enhancing Security for Networks and Applications. That will include some details about the differences between Penetration Testing and Vulnerability Scanning as well as some depth on Penetration Testing itself. So at this point in the game that covers everything I had for PCI compliance. We now have time to take a couple of questions.

Question: Do you have any experience with PCI compliant cloud?

Adam: Yes. PCI compliant clouds definitely. We have actually taken an organization from start to finish through PCI compliance in the cloud. It was actually one of the earlier implementations of cloud based technology. When it comes to implementing PCI in the cloud, for organizations that have more that a couple of different devices on their network, or more than a couple of machines, there are actually a lot of advantages to going the private cloud route.

Private cloud is a virtual environment that is set up and established specifically for yourself. Certainly there are lots of advantages to it, such as being able to pre-configure the virtual machines. Let’s say you have ten different web servers that are up and in place that you need. You can pre-configure the virtuals by machine types and pretty much have them hardened and bolted down before you deploy them. And if you need to stand up a new web server, then you can go ahead and just use that same base. The real challenge there is making sure you maintain that base with the latest and greatest settings from a security perspective.

Question: Can we see the presentation offline?

Adam: Absolutely. My contact information is up on the screen right now. You can send me an email at agoslin@HighBitSecurity.com and I can get a copy of the presentation over to you.

Question: Can you review PCI in a cloud environment?

Adam: PCI compliance in the cloud, honestly, there is not a lot of difference between doing it on a standard infrastructure versus cloud. The real challenge from the cloud perspective is the fact that you have to provide equivalent security, according to the PCI counsel, as the most secure box in your environment and apply that to the hyper visor or the management interface that governs all of your virtual environment. It needs to be as secure as your most secure box in your environment. Those are the rules of PCI and that is really the only additional incremental component to it from a PCI compliant perspective.

Pretty much everything else is going to maintain, whether it is to a physical infrastructure or to a cloud based infrastructure. The only difference in a cloud based infrastructure is if you have a lot of boxes,you gain a lot of efficiencies. This will lead into the next question I saw that was surrounding Level 1 compliance and the cloud. The bottom line is that whenever you walk into a Level 1 PCI compliance agreement the single, biggest factor in your amount of pain or pleasure you experience through the process is the quantity of the planning that is performed up front. It is sort of like the “measure twice, cut once mentality” in terms of if you get a real good handle on what you have today, where you need to go and plan it all out (especially in the cloud environment) you can make some absolutely great efficiencies as you release it in a cloud based environment.

At this point in the game we will go ahead at close the presentation. You can reach me by phone or email at: 248.388.4328 or agoslin@HighBitSecurity.com. I would be more than happy to hear from any of you surrounding questions on PCI compliance or Penetration Testing. Thank you very much for your time and thank you again to Online Tech for facilitating.

Back to Top

Webinars    |    Online

Get started now. Exceptional service awaits.