PCI compliance & certification for data centers and managed services providers can become an incredibly complex, subjective, and challenging proposition, thus it’s important to distill and clarify critical issues for ensuring an efficient, yet comprehensive process. With data centers and managed service providers offering a wide array of services to customers, the all-important topic of “what are my PCI requirements” surfaces very quickly. And to be fair, it’s a question that many providers seem to struggle with, so let’s clear the air and discuss important scope considerations and other relevant factors regarding PCI compliance & certification for data centers and managed services providers. Also, pcipolicyportal.com provides a data center/managed services provider policy and compliance toolkits available for instant download today. Visit pcipolicyportal.com to learn more about the very best documentation found anywhere on the Internet.
Who’s Environment Is It?
It’s important to note that data centers and managed service providers need to start by understanding it’s their environment – first and foremost – as this lays the foundation for overall scope considerations, regardless of what clients do or do not do in terms of storing, processing, and transmitting cardholder data. With that said, each of the twelve (12) PCI DSS requirements should be comprehensively examined for determining if there’s applicability to one’s business, either through service offerings to clients, or with standard initiatives already in place at the facility.
Let’s start by assessing each of the twelve (12) PCI DSS requirements and their overall applicability to data centers and managed services providers. Note that the term “managed services”, for purposes of this white paper, encompasses the following: Any organization offering managed network, O/S, and application level services whereby they are responsible for many of the core practices, such as provisioning, hardening & system deployment, patch management, maintenance, and other essential duties. As for “data centers” and/or “co-location” entities, these are facilities offering the well-known “ping, power and pipe” core services, and nothing more.
Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data. Data centers offering traditional “ping, power, and pipe” services would generally be excluded from such a requirement, but managed services providers offering network services would have full accountability for configuring ports and protocols, deploying firewalls and other essential network devices. It also means that managed services providers need to have documented policies and procedures in place for making changes to network devices, such as who is allowed to conduct such activities, what’s the process, along with other important information. Remember something very important about PCI compliance – early on you can clearly see the mandates for information security policies and procedures.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. Ensuring the safety and security of system components – and the data being stored, processed, and transmitted on such systems requires implementing comprehensive provisioning and hardening measures. Specifically, removing vendor default settings, disabling insecure services, limiting access rights – and much more – is a strict mandate – and a best practice – for PCI DSS compliance. Traditional data centers would largely be excluded from such requirements, with the possible exception of having to appropriately provision and harden any border or edge devices, possibly routers.
As for managed service providers, any type of managed O/S and managed applications would require compliance with Requirement 2, no question about it. And once again, much like Requirement 1, and many other “Requirements” within the PCI DSS framework, policies, procedures – and other essential documentation – are paramount. In fact, essentially every one of the twelve (12) PCI DSS “Requirements” call for some type of documentation. Visit pcipolicyportal.com and download the industry’s very best set of PCI policies today.
Requirement 3: Protect Stored Cardholder Data. Protecting cardholder data means just that – ensuring the safety and security of the full Primary Account Number (PAN), along with any other attributable information. Remember, that “cardholder data” is the following: At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction.
Requirement 3 focus heavily on the actual systems (i.e., databases) where cardholder data is stored. This means ensuring adequate protection is in place, such as using file or column level encryption of the Primary Account Number (PAN) and other sensitive cardholder data as needed. Remember, that the PAN is the actual 15 or 16 digit credit card number, and it must be protected at all times. As for data centers offering traditional co-location services, this requirement is largely out of scope, yet managed services providers offering managed O/S and managed application would consider requirement 3 to clearly be in-scope – IF they are managing the database or providing services to such databases storing cardholder data. Furthermore, if true managed application functions are being performed, there’s the issue of encryption and key management for data at rest, which can be an incredibly complex and challenging mandate for managed services providers.
Again, you can clearly see a line being drawn in the sand separating roles and responsibilities between data centers offering traditional co-location, and those providing managed services, and it will continue to be seen throughout the remaining PCI DSS requirements.
Requirement 4: Encrypt Transmission of Cardholder Data across open, pubic networks. From co-location facilities to managed services providers, everybody essentially has a hand in making sure the PCI DSS Requirement 4 mandates are met. And to be fair, they’re rather straightforward and require using – along with common sense – best practices found in the information security industry. Specifically, you’ll need to be using a secure protocol (i.e., TLS) for ensuring the safety and security of data traversing across open, public networks. Note also that as of 2015, SSL is NOT considered “strong cryptography” anymore, so it’s time to flip the switch to TLS.
There are a number of high-quality white papers that have been written specifically on this topic, so doing a simple Google search is your best avenue at this point for gaining more information. Additionally, the Payment Card Industry Security Standards Council (PCI SSC) offers excellent information on this topic.
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs. Requirement 5 is a relatively straightforward mandate, either you’re using anti-virus or you’re not. For co-location services, the data center really has no mandate for Requirement 5, while managed services offerings are quite different, however. Additionally, one of the biggest questions surrounding the anti-virus is its use on UNIX/Linux system – or rather – it’s non-use.
Statements such as “I don’t need anti-virus on Linux” systems and “anti-virus is only for Microsoft” are common themes held by a large number of information security professionals. Even with that said – and there is validity to such statements – a best practice is to put anti-virus solutions on ALL in-scope servers within one’s cardholder data environment. There have been – and are still – a number of viable solutions for anti-virus for UNIX/Linux systems that work quite well. The PCI DSS Council has also “softened” it’s hard and fast rule on anti-virus, provided other “layered defense” initiatives are in place.
Requirement 6: Develop and maintain secure systems and applications. Requirement 6 is one of the more comprehensive and time-consuming “requirements” with the current PCI DSS framework, and for good reason. From security and patch management initiatives to numerous mandates for software development, this requirement alone can cause immense challenges. Additionally, both service offerings – traditional co-location and managed services – often have quite a bit of work to accomplish with Requirement 6, especially when it comes to the all-important topic of security and patch management. Patching is an often loathed process, and one that many companies fail miserably on, but it’s a mandate for PCI compliance, and also a best practice every business should be undertaking.
From a scope perspective, both co-location providers and managed services providers should be striving to implement the following security & patch management best practices for all applicable environments:
The policies, procedures and related processes undertaken for effectively identifying, acquiring, testing, distributing, installing, and monitoring security patches for all relevant system resources throughout an organization, including, but not limited to, all network devices, operating systems, applications, and other in-scope systems.
Interestingly, security and patch management is without question one of the most critical aspects of any type of security best practice, yet it’s also one that seems to fail miserably, lacking cohesive and comprehensive implementation. As for the PCI DSS standards, they’re very clear – and rigid – on what must be in place for patching system components. So where is the line drawn regarding patch management between traditional data center co-location services and managed services offering? It really is drawn when data centers take command of managing the OS and the applications – a clear distinction of services now being offered above and beyond that of simply co-location.
Requirement 7: Restrict access to cardholder data by business need to know. Requirement 7 is all about access control – who can access what systems, for what reason, and are they given the least amount of access to perform their daily roles and responsibilities. While the concept of Requirement 7 is relatively straightforward, the biggest issue do deal with is scope. It means ensuring you have a strong understanding of what system components are actually within the cardholder data environment, and what directory services are used for accessing such systems.
Additionally, the concept of Role Based Access Control (RBAC) must also be in place, an information security best practice defined as the following:
Once users have successfully identified and authenticated themselves, they are then authorized to perform certain functions and operations within those system resources based on specific roles afforded to them.
Again, the great divide is traditional co-location vs. managed services, whereby co-location entities would only have marginal requirements for complying with Requirement 7 (there are a few, for sure), while managed services would have to comply with ALL of Requirement 7. Talk to a PCI DSS expert for ensuring you truly understand the merits of Requirement 7.
Requirement 8: Identify and authenticate access to system components. Requirement 8 is largely about the types of identifiers (i.e., usernames) and authentication methods (i.e., passwords, passphrases, pin codes, etc.) used by individuals accessing the cardholder data environment. Once again, depending on the services provided (co-lo vs. managed services), scope can be marginal or rather widespread. Regardless of the scope, it is important to note that Requirement 8 is largely about the formalized processes and practices around provisioning users onto systems deemed in-scope within the cardholder data environment.
Requirement 7 essentially dovetails into Requirement 8 as the broader domain for bother requirements is about access to system components that store, process, and/or transmit cardholder data. And once again, information security and operational specific policies and procedures – and other supporting documentation – are essential for meeting PCI DSS compliance for these two (2) respective areas.
Requirement 9: Restrict physical access to cardholder data. is without question one of the most attainable “requirements” for PCI DSS compliance – after all – data centers come complete with a battery of physical security and environmental security controls. From access points to mantraps, closed circuit video surveillance, and numerous other monitoring devices, adhering to the Requirement 9 PCI DSS mandates is often quite achievable. What makes matters challenging is often the guidance and requirements set forth by the PCI-QSA one is using, if in fact a business is utilizing the services of a Qualified Security Assessor. While the PCI DSS mandates are rather prescriptive, the interpretation of one QSA could be completely different from another QSA, and the same can be said for all of the twelve (12) PCI DSS requirements.
Requirement 10: Track and monitor all access to network resources and cardholder data
For any organization seeking to become PCI DSS compliant, logging mechanisms and the ability to track user activities are absolutely essential for preventing, detecting, or minimizing the impact of a data compromise. Thus, the actual presence of logs in all environments allows for comprehensive tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
As with many of the previous PCI DSS requirements, if you’re offering just traditional co-location services, then the responsibility of audit logs and audit trails shifts to the client’s and their production environment within their rack or cage. However, if its managed services being offered, the responsibilities shift back to the data center, depending on what degree of managed services are actually being offered. Again and again, it all comes down to scope and the services being provided to clients.
Requirement 11: Regularly test security systems and processes
Two of the biggest components of PCI DSS compliance are encompassed within Requirement 11 – undertaking quarterly external AND internal vulnerability scans, along with performing an annual penetration test – or when significant changes are made to a production environment. Both service offerings – co-location and managed services – should be performing pen testing and vulnerability scanning – because it’s mandates for PCI compliance, but it’s also a best practice.
Requirement 12: Maintain a policy that addresses information security for all personnel
Requirement 12 is without question the most comprehensive – and demanding – mandate when it comes to PCI documentation. We’re talking about usage policy documents, incident response plan measures, security awareness training, and more. These are security 101 best practices that need to be in place in today’s cybersecurity world. Here’s a list of policies, procedures, and other initiatives mandated by Requirement 12 of the PCI DSS standards:
Annual Risk Assessment Process
Usage Policies and Procedures
Information Security Responsibility Policy and Procedures
Formal Security Awareness Program
Management of Service Providers Policy and Procedures
Incident Response Plan
Documentation is king when it comes to PCI DSS compliance, as you can easily see the volume of policies and procedures needed and it’s why pcipolicyportal.com was founded – to provide the very best PCI policies and procedures to businesses all throughout the globe.
Additionally, take note of the following items regarding PCI compliance & certification for data centers and managed service providers, courtesy of pcipolicyportal.com:
Provisioning and Hardening: Requirement 2 of the PCI DSS standards places a major emphasis on securing system components by removing default settings, along with unnecessary and insecure services. The goal is to harden systems as much as possible, leaving no window for access to any unauthorized parties. It means that data centers and managed service providers need to develop documented provisioning and hardening forms and checklists for the following:
Network devices (firewalls, routers, switches, load balancers, etc.)
Servers – both physical and/or logical – and the underlying operating system and applications residing on such servers. This would include all production servers, web servers, DNS – any type of server deemed in-scope for the actual cardholder data environment.
Saying a system is hardened is one thing, proving it by having in place best practice configuration standards – those that are actually used – is another. Don’t forget that auditors will often inspect system settings to ensure such hardening procedures have been put in place.
Policies and Procedures: Data centers – along with many other types of businesses – are often very surprised at the amount of documentation necessary for becoming compliant with the Payment Card Industry Data Security Standards (PCI DSS). From Requirement 1 all the way through Requirement 12, there’s dozens of mandates for information security and operational specific policies, procedures, forms, checklists, and other supporting documentation. While many of today’s present – and emerging – regulatory compliance mandates are seen as very technical – and they can be – don’t lose sight of the importance of documentation. Policies and procedures are so incredibly important – yet they’re also very time-consuming in terms of development – so turn to the PCI DSS experts today at pcipolicyportal.com for the very best documentation found anywhere today.
Customer Requirements: PCI DSS compliance is not 100% on your shoulders, your client’s are also responsible for a possible large number of the actual “Requirements”, so keep this in mind. Furthermore, don’t let your customers pass the buck on to you – which is common – when it comes to THEIR PCI DSS compliance reporting mandates. The proverbial “oh, my data center is PCI compliant, so I don’t need to be” phrase it completely false, but it’s used quite often. Your customers that use your services – from traditional rack and co-location spaces to managed services – must each to through their OWN PCI DSS certification annually – no exceptions. Sure, they can leverage YOUR PCI compliance reporting, for purposes of Requirement 9, at a minimum, but they must still produce their own annual compliance report.
Security Awareness Training: What’s fundamentally important when it comes to securing one’s information security landscape – and particularly, the cardholder data environment – is having knowledgeable and disciplined employees in place, those that can identify and react to security issues. The very best way of training employees in regards to emerging security threats, issues, and challenges is comprehensive security awareness training. We’re not talking about a boiler point PowerPoint template, we’re talking about detailed training for your employees, educational material that’s specific to your environment.
Compliance is a Moving Target: Regulatory compliance is never a one-time activity – not at all – it requires constant commitment and dedication for ensuring all mandated policies, procedures, and applicable processes are in place. It can be a challenge – no question about it – but its’ why you’ll need to appoint an individual the mandate of ensuring compliance is upheld.
Talk to the Experts today at pcipolicyportal.com
Looking for the very best solutions and services when it comes to Payment Card Industry Data Security Standards (PCI DSS) compliance, then turn to the experts at pcipolicyportal.com, the global leader in PCI DSS policy compliance. We also offer the very best documents when it comes to risk assessments, security awareness training, along with expert consulting services. Contact us today at pci@pcipolicyportal.com or call us at 424-274-1952.
