Recently, Security Boulevard published a series of tips that were compiled from across the industry by Threatstack. This list contained many interesting ideas regarding practices for security monitoring, procedures and documentation, and working with third parties, along with more good advice about how to handle and limit payment card data. Schellman’s team of Qualified Security Assessors (QSAs) reviewed this list and offered some additional insight and commentary on the published information.
Tip #1: Learn about new PCI standards for new ways of building software.
In January 2019, the PCI Security Standards Council released the new PCI Software Security Framework and its component standards to increase focus on building secure software while improving the development process. These new standards complement the PCI DSS, although they are not replacements for it.
The actual, current PCI DSS version is 3.2.1, which was released in May 2018. The associated Report on Compliance (ROC) reporting template, version 3.2.1 revision 1.0, has been required for all ROCs issued after October 31, 2018. The draft of the next version of the PCI DSS is expected to be released for comments from stakeholders in late 2019, and again in early 2020, with the final version expected late next year. Once released, the new version of PCI DSS will run in parallel to 3.2.1 for likely at least a year before the old standard expires.
- Eric Sampson, Schellman & Co. Senior Manager
Tip #2: Perform scans as early as possible.
Vulnerability scanning required by PCI DSS v 3.2.1 includes quarterly internal vulnerability scans and external vulnerability scans conducted by an Approved Scanning Vendor (ASV). Although internal vulnerability scans can be conducted by a third-party service provider, many organizations find it more cost-effective to perform their own scans. Moreover, the most successful companies run vulnerability scans, both internal and external, much more frequently than quarterly. Organizations choosing to do the bare minimum of scanning once a quarter often have issues with passing—however, performing these scans on a more frequent, monthly basis very often proves more successful, as it provides the ability to identify vulnerabilities early and allows enough time to remediate and rescan. Failing to have a "passing" vulnerability scan every 90 days will result in non-compliance with the requirements for quarterly scans, likely resulting in the development of a compensating control, which—ironically—almost always calls for increasing the frequency of scanning. Forward thinking in running more frequent scans from the start avoids this, and fortunately, many ASV companies do allow an unlimited number of unattested external scans in each quarter—that, in turn, permits an organization to run as many scans as needed without increasing cost. It’s a win-win-WIN—if an organization manages their own internal scanning activities, they are able to run as many internal scans as needed without the costs of paying for additional scans, and thus can identify any vulnerabilities early and maintain compliance.
- Matt Crane, Schellman & Co. Senior Associate
Tip #3: Encrypt stored cardholder data.
Encrypting your data may be the single most important of all the requirements. The whole point of the PCI exercise is to protect cardholder data, but it’s not enough to just slap some crypto wrappers together and call it a day. Proper encryption methods will make sure your solution is robust and strong enough to keep your data truly safe. Some recommended approaches include:
- Storing the parent and child keys separately and securely.
- Implementing and only accepting strong ciphers in support of your transport certificates.
- Making sure your parent and child keys are at least equivalent strength. (Annex C of the PCI Point-to-Point Encryption Solution Requirements and Testing Procedures has a table of equivalent strengths between AES and RSA algorithms.)
- Regularly rotating and retiring keys. That includes doing an ad hoc rotation should a key custodian no longer have that status, or if they leave the company altogether.
- John Cartwright, Schellman & Co. Senior Associate
Tip #17: Use strong passwords.
Strong and complex passwords may seem like an obvious control, but there are still many organizations that are not addressing the issue adequately. Although PCI DSS requires a password to be a minimum of 7 characters and contain both alphabetic and numeric values, every organization should really consider establishing higher complexity settings.
Increasing complexity requirements to 12 or more characters with at least one special, numeric and alphabetic character each can drastically increase the intricacy of a password and decrease the likelihood of a successful brute force attack.
- Matt Crane, Schellman & Co. Senior Associate
Tip #49: Use data tokenization.
Anna Johansson, CEO of Johansson Consulting, said it well in an article for the Huffington Post: “data tokenization secures customers’ sensitive credit card information in a secure, web-based portal, rather than local servers. Not only does this keep customer data safer, it also reduces liability in the event of a data breach." While she’s correct that data tokenization can limit scope and liability, the entire process needs to be evaluated. Many are quick to eliminate or diminish scope based on tokenization, but thorough evaluations of data flows and tokenization processes are required. Here are some important areas to evaluate:
- Evaluate the tokenization provider—ask, are the tokens being provided by a third-party service provider (TPSP) or are they being created in-house? The major advantage of utilizing tokenization is the ability to de-scope cardholder data in storage and in-transit when a token is involved; however, there are some particulars to consider:
- If a third party is used, the entity should not have any direct system access to the real cardholder data without making requests to the third party.
- If a third party is not used, eliminating cardholder data is more troublesome. As with encryption, if access to the decryption keys are within the environment, you cannot de-scope the encrypted data. Though it is rare to call encrypted data out-of-scope, the council has made allowances to entities who store encrypted data with no access to the keys—the same can be said about tokens. If the tokenization process is in-house, there could be an opportunity to revert a token to the cardholder data by attacking the vault that stores and associates the card number with the token. In other words, it may be assumed if someone cracked the store of the token, they may be able to crack the location where the token can revert to cardholder data.
- Review the data flow processes. Just because tokenization is in use does not mean cardholder data does not transit the networks prior to requesting the token from the provider. If data enters the system even transiently, that environment remains in scope, as all systems touching cardholder data in transit are in-scope, along with those connected to and/or those that provide security functions to those systems/devices. Additionally, even with tokens, there are times where an entity may need to request the cardholder data back from the tokenization provider. In these scenarios, once again follow the flow for scoping systems.
- Evaluate all entities. If the data does not transit the entity’s network, and all cardholder data is transmitted between the end-user and the tokenization provider, gauge what methods are being utilized by the entity. There are differences on the use of redirects/iframes versus direct post (javascript/html). Consider:
- If you are a merchant and have the opportunity to do an SAQ, it is the difference between a very limited SAQ A (redirect/iframe) or SAQ A-EP (direct post). The council provides a few FAQs on why the difference on their site.
- Service Providers allowed to do an SAQ are always stuck with SAQ-D—and there’s no way around that.
- Overall scoping systems should be around the protection of the systems that serve up the code for the payment page(s), along with the systems that support those systems. The goal is to ensure someone cannot maliciously alter that code or the pages compromising the cardholder data.
- Do not just blindly accept the fact that your tokenization provider is performing tokenization of the data in a compliant manner. Tokenization processes are very important, and when selecting a provider, all organizations should:
- Validate the providers PCI DSS compliance.
- Understand the tokenization process. Just because a provider hands you back data that does not appear to be cardholder data does not mean that is always the case. Bad processes have existed where providers use the actual cardholder data and sometimes even sensitive authentication data (SAD) to create the token. If SAD is stored within the token after authorization, the entity is out of compliance – no matter the process. Furthermore, if the token is simply a hash of the cardholder data and/or SAD, and one stores any other data such as truncated primary account numbers (PANs), there could be the capability for one to utilize the pieces to crack the hash.
It’s important to remember that stating tokenization “reduces your liability in the event of a data breach” may not always be an accurate statement. In fact, the idea is very dependent on contract agreements one has in place with their service providers, their due diligence with selection of the TPSP, and whether or not those chosen providers are maintaining compliance. As always, if an entity engages a third party, the organization is still responsible for the data that service provider manages on their behalf.
- Kate Donofrio, Schellman & Co. Manager
Tip #6: Prepare adequately for QSA (Qualified Security Assessors) assessments.
When preparing for a PCI assessment, not only should you know where cardholder data may be stored, transmitted or processed within your environment, but you should properly identify the “who” within the environment as well. For the leadership team, knowing exactly who has access also helps with scoping in terms of identifying where cardholder is located and at what points during the business process is cardholder data hitting one particular location. Regarding the assessment process, knowing “who” within the environment also reduces the probability of “bottleneck” moments in the assessment process—moments that, when they occur, essentially slow down the entire assessment timeline.
- Glenise Moore, Schellman & Co. Senior Associate
Tip #11: Take care of your system and network vulnerabilities.
Maintaining the systems and networks within your organization’s cardholder data environment (CDE) is not only a requirement, it is essential to protecting cardholder data. Along with standard configuration guidelines, continuous monitoring and frequent vulnerability scanning are some of the best ways to secure an environment. Modern vulnerability scanning engines can be fine-tuned to identify much more than susceptible software definitions. Most vulnerability scanners can be configured to check for recent patches and logical access configurations—they’re also capable of performing brute force attacks on passwords too, as well as much more. Although vulnerability scanning is already a requirement of PCI requirement 11.2, organizations can take advantage of their pre-existing tools to increase security by not only increasing the frequency to which they run scans, but by also properly configuring the scanning equipment.
- Matt Crane, Schellman & Co. Senior Associate
Tip #9: Understand the scope of your environment.
The CDE includes every system within a network where cardholder data (CHD) is stored, processed, or transmitted, and this is where PCI DSS scope begins. The CDE also includes any other networks with routes into the CDE if the routes are not restricted to specific systems in the other network. For instance, systems are considered in-scope as “connected-to” systems if they reside outside the CDE but maintain connections into the CDE. PCI DSS requirements apply to the connected-to system; however, the network where the system resides may remain out-of-scope.
Overall, systems, processes, applications, and technologies are considered in-scope as “security-impacting” if they, despite not having a direct connection or route into the CDE, can otherwise impact the CDE’s security. Anything that indirectly connects to the CDE, can impact the configuration or security of the CDE, provides security services to the CDE, supports PCI DSS requirements, or provides segmentation between the CDE and out-of-scope environments is considered in-scope. People who have access to or manage these systems, as well as those who manage connected-to systems, are also included in-scope even if they do not have direct access to the CDE or interact with CHD. Therefore, everything from people, processes, applications, and technologies within the environment can be in-scope for PCI DSS.
Given this seemingly large span, in order to reduce scope in networks that do not store, process, or transmit CHD, explicit rules or routes must be used. For any out-of-scope system on the same network as a connected-to or security-impacting system, controls must be in place to prevent the out-of-scope systems from gaining access to the CDE via the in-scope systems. These controls are required to be validated annually.
Bottom line: to be as efficient as possible and properly identify scope, you should develop and maintain clear, thorough, and accurate network diagrams, as well as complete system and employee inventories.
- Brandon Royce, Schellman & Co. Senior Associate
Tip #7: Reduce the PCI scope of your environment.
The gist: if you don't need something, DON’T STORE IT. The PCI Security Standards Council (PCI SSC) is a major advocate for this approach, and so are most QSA companies. With that said, removing full PANs from an environment doesn't necessarily decrease the scope of the systems involved in a PCI DSS assessment if those systems still handle or transmit the PAN, even without retaining it. Though it will decrease the total number of applicable requirements, removing PANs from storage is unlikely to decrease the number of systems or networks in scope. Therefore, the most effective way to reduce the scope of a PCI assessment is to implement network segmentation to isolate the cardholder data environment from other unrelated systems.
- Matt Crane, Schellman & Co. Senior Associate
Tip #4: Use network segmentation.
As previously stated, proper segmentation of an organization's in-scope environment is one of the most efficient ways to decrease the complexity of a PCI DSS assessment and reduce scope creep. Without proper segmentation, an organization may need to include their entire corporate network in the scope of a PCI DSS assessment. Although they may want to apply similar controls across their organization, it can be counter-intuitive to apply all PCI requirements to varying departments such as marketing, finance or development. Validation of segmentation is something the QSA will do at the beginning of a PCI assessment, but it generally means there is no inbound or outbound traffic allowed between the card data environment and segmented environments.
- Matt Crane, Schellman & Co. Senior Associate
Tip #10: Carry out comprehensive penetration tests.
Service providers are required to perform semi-annual penetration testing on segmentation controls, and merchants must test annually. Testing is also required after any change to segmentation controls in order to verify that all out-of-scope networks cannot access any in-scope devices or networks—this particular testing should originate from within each out-of-scope network segment, or at least a usefully representative sample, and attempt to gain access to anything inside the scope boundary. The testing should be a true penetration test and should include penetration attempts against the systems providing segmentation controls—it should not be just a simple port scan.
Where many networks (subnets, VLANs) exist, sampling may be used; however, each type of segmentation control must be represented. Additionally, work with your assessor and penetration tester to determine what specific segmentation controls apply to your environment. For example, consider testing your remote access endpoints, or testing the ability of an attacker to move through a shared services IT environment (i.e., an environment that provides IT services to both in-scope and out-of-scope networks).
Where any access is discovered or where segmentation controls otherwise do not work as intended, retesting is required to verify both that the access was removed and that there is no new unintended access.
- Brandon Royce, Schellman & Co. Senior Associate
Tip #21: Understand the difference between vulnerability scanning and penetration testing.
Penetration tests (11.3 PCI Security Standards) are typically a combination of automated tools and skilled humans trying to break into systems. A scope (target) is defined, a timeframe is established and essentially a white hat or ethical hacker attempts to break into systems, traverse networks, and capture data. They look for weak passwords, poor configurations, unsecured systems, and other avenues of exploit to gain access. Pen tests should be performed at least annually, as well as after significant infrastructure change or an application upgrade.
On the other hand, vulnerability scans are fully automated and look for known vulnerabilities. EternalBlue, for example, is a known issue that opened the door for WannaCry ransomware back in 2017. As such, a vulnerability scan performed on a server today would look for the weakness that EternalBlue exploits, along with many other known threats. Post-scan, a report is typically produced and delivered with findings ranked by the CVSS (Common Vulnerability Scoring System) score, usually together with the suggested patch or fix for the vulnerability. PCI DSS states that that vulnerability scans should be performed at least quarterly or after significant change (Requirement 11.2).
With all that said, when considering either, think of vulnerability scans as means to test the patching posture of an organization, where penetration tests are more in-line with how the organization might stand up against a skilled hacker.
- Matt Howard, Schellman & Co. Senior Associate
Tip #45: Create remediation workflows.
Defining, documenting, and implementing vulnerability remediation policies and processes are imperative for obtaining and maintaining compliance in accordance with PCI DSS standards, and these processes for identifying and remediating vulnerabilities should always include risk rankings for the problems that are discovered. These risk rankings are helpful in prioritizing remediation efforts and prescribing specific timelines for such endeavors. For optimal use, the remediation workflow should encompass all vulnerabilities found during penetration testing, vulnerability scanning and assessments, and patching and change management, as well as vulnerabilities identified by vendors and outside security sources. The risk rankings and timelines for remediation must adhere to PCI DSS requirements 6.x, 11.2.x, and 11.3.x.
- Jarrod Rice, Schellman & Co. Senior Associate
Tip #25: Create a dedicated team to ensure ongoing PCI compliance.
Achieving PCI DSS compliance requires having a PCI charter for service providers (Requirement 12.4.1) and identifying the person(s) or job role(s) chiefly responsible for maintaining the PCI compliance program. On a quarterly basis, responsible individuals review compliance activities to ensure that required periodic activities are performed (Requirements 12.11 –12.11.1). This has the intent of connecting the organization’s senior management to the regular workings of the PCI DSS compliance effort rather than insulating them from it.
A successful PCI DSS compliance program has a dedicated team, often including personnel from information security, risk management, compliance, and governance, as well as support from executive management. Additional support from organizational departments such as information technology and systems administration, software engineering, and human resources is also key for operating a successful PCI DSS compliance program.
- Eric Sampson, Schellman & Co. Senior Manager
Tip #8: Pick payment providers that maintain the highest PCI compliance standards.
Though the PCI DSS standard itself doesn’t make use of levels, it’s worth noting that levels for merchants or service providers are defined by the payment card brands to identify what sort of validation an entity undergoes to prove its PCI DSS compliance. Most service providers should undergo a full assessment by a QSA and obtain a ROC and Attestation of Compliance (AOC). It’s this latter document, the AOC, that you should look for when selecting a service provider that offers any relevant service to your PCI DSS compliance, whether it’s payment processing, business process outsourcing, colocation, or the like. The third-party’s AOC should describe the scope of their completed assessment and give at least some sense of what requirements were covered. By extension, this should also provide some notion of what their assessment did not cover and consequently, what should be included in subsequent evaluations. Sometimes, organizations will also have a more detailed breakdown of the division of responsibilities available—consider asking for one from a potential service provider.
In short, don’t settle for a provider’s claims of “Level 1 compliance” or a listing on a payment brand website—get the AOC and review the details.
- Jacob Ansari, Schellman & Co. Senior Manager
Tip #13: Consult with QSAs and security professionals.
Consulting with a QSA or a security professional well-versed in PCI is typically the best way to receive accurate and concise answers to any questions. The PCI Standards and Security Council (SSC) does offer a lot free information in their FAQs and their supplemental guidance documents, but in almost all cases they recommend consulting with a QSA for more information, especially since most QSA companies are willing to provide answers to existing customer questions outside of a typical assessment lifecycle. Some organizations may opt instead for a security consultant who is not a QSA for their recommendations on securing an environment, but there are many nuances of PCI DSS that those consultants may not have the expertise to address. Moreover, actual QSA firms also get a preview on upcoming standard releases and can provide additional guidance or context to a new PCI requirement.
- Matt Crane, Schellman & Co. Senior Associate
Tip #24: Understand the continuity of the PCI compliance process.
PCI compliance isn’t just a project--it’s a way of life.
Companies that fully integrate compliance into their day-to-day security and business processes generally remove the regular burden of thinking “is this compliant?” during their daily duties. Frequent scans, vulnerability management and tracking, log-checking, patch management and system hardening—everything a company should be doing (and probably are) become part and parcel of compliance. Then, at that special time of year when the QSA arrives to conduct the annual assessment, it’s a matter of collecting evidence and documentation instead of mad dashes and delays.
- John Cartwright, Schellman & Co. Senior Associate
About the Author
More Content by Schellman Compliance
