PCI DSS: Significant Change vs. Periodic

By Jeff Hall ·

No words or phrases in the PCI standards elicit more comments and questions than “significant change,” “periodic” and “periodically”.

So what do these mean?  Whatever you define them to mean. It’s up to each organization to come up with formal definitions. Those definitions should be based on your organization’s risk assessment.

Here are some suggestions as to appropriate definitions.

Significant Change

Significant changes are those changes that could impact or affect the security of your cardholder data environment (CDE).  Examples of significant changes are:

  • Changing devices such as firewalls, routers, switches and servers. Going from Cisco to Checkpoint firewalls for example is typically understood as a significant change. However, people always question this concept particularly when going from a Cisco ASA 5505 firewall to an ASA 5520 or moving a virtual machine from one cluster to another. The problem is that these moves can potentially introduce new vulnerabilities, network paths or even errors that would go unknown until the next vulnerability scan and penetration test. And your luck would be that those tests are months away, not just a few days.
  • Changes to payment applications. This should be obvious, but I cannot tell you how many people argue the point on changes to applications. Yet, application changes are possibly the biggest changes that can affect security. Not only should applications be vulnerability scanned and penetration tested before being put into production, but code review and/or automated code scanning should be performed as well. If any vulnerabilities are found, they must be corrected or mitigated before the application goes into production.
  • Upgrades or changes in operating systems. Upgrades and changes in operating systems should also be obvious as significant changes. However, I have run into network and system administrators that want to split hairs over the impact of OS changes. In my opinion, going from one version of an OS to another is just as significant as changing your OS.
  • Patching of operating systems or applications. While I do not think that patching necessarily results in a significant change, there are some patches such as updates to critical services such as .NET or the IP stack that should be considered significant. If you are properly working through requirement 6.1 (6.2 in PCI DSS v2) for patch management, you should take this into consideration and indicate if vulnerability scanning and penetration testing are required after any particular patch cycle because of the nature of any of the patches being applied.
  • Network changes. Any time you change the network you should consider that a significant change regardless of how “minor” the change might appear. Networks can be like puzzles, and the movement of devices or wires can result in unintended paths being opened as a result.

I have a lot of clients that have an indicator in their change management system or enter “Significant Change” in the change comments for flagging significant changes. That way they can try and coordinate significant changes with their scheduled vulnerability scanning and penetration testing. It does not always work out, but they are trying to make an attempt at minimizing the number of special scans and tests that are performed. Such an approach also has a side benefit when it comes time to do their PCI assessment as they can call up all significant changes and those can be tied to the vulnerability scans and penetration tests.

I would see this list as the bare minimum of significant changes. As I stated earlier, it is up to your organization to develop your own definition of what constitutes a significant change.

Periodic & Periodically

Branden Williams was on a Podcast shortly after the PCI DSS v3 was released and made a comment that he felt that the number of occurrences for the words “periodic” or “periodically” were higher in the new version of the PCI DSS than in the previous version.  That got me thinking so I went and checked it out.  Based on my analysis, these words occur a total of 20 times in the PCI DSS v3 with 17 of those occurrences in the requirements/tests. That is a 150% total increase over v2 and an increase of 113% in the requirements/tests.

First off, just to shatter some people’s perception of the word, “periodic” does not equate to “annual.” Yes, there may be instances where an activity can occur annually and still meet PCI DSS compliance. But that is likely a rare occurrence for all but the smallest organizations and is definitely not how the Council has defined it.

The Council uses the words “periodic” and “periodically” to reflect that an organization should be following the results of their risk assessment to determine how often or “periodically” they should perform a certain activity. For some organizations, that might happen to work out to be annually. But for most organizations it will work out to be something more often than annually.

So what requirements specify a periodic time period? Here are some of the more notable occurrences.

  • 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require antivirus software. Typically this would be done annually, but forensic analysis of breaches has indicated that it needs to be done more often, particularly with Linux and other Unix derivatives. Based on threats, semi-annual or even quarterly reviews may be needed for systems you believe to not warrant an antivirus solution.
     
  • 5.2 Ensure that all antivirus mechanisms are maintained as follows: Keep current, Perform periodic scans, Generate and retain audit logs per PCI DSS Requirement 10.7. Periodic scanning is always an issue with servers but, surprisingly, even more so with workstations. In my opinion, at a minimum, scans for viruses and malware should be done at least weekly. This might need to be done daily if the systems are particularly at risk such as in call centers where the workstations my go to the Internet to be able to access competitor sales offerings.
     
  • 8.2.4.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that: non-consumer user passwords are required to change periodically and non-consumer users are given guidance as to when, and under what circumstances, passwords must change. This requirement pairs with 8.6.2 which requires service providers with remote access to customers’ systems not to use the same credentials for each customer. A number of recent breaches have pointed out the issue such a practice can lead. Not only are different credentials needed, but the password for those credentials needs to change periodically, typically every 90 days. This will likely spur the sales of enterprise credential vaults and similar solutions in the service provider ranks. But it is not just service provider’s credentials, it is also their customers’ credentials. Service providers need to advise their customers to change their passwords periodically as well. And that should also be at 90 day intervals at a minimum.
     
  • 9.7 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories. For this requirement, the PCI DSS already provides a required timeframe of at least annually.
     
  • 9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements. Periodic here typically means quarterly or even monthly if you have the volume of media to be destroyed. The key though is to secure the media until it is destroyed.
     
  • 9.9 Examine documented policies and procedures to verify they include: Maintaining a list of devices, Periodically inspecting devices to look for tampering or substitution, Training personnel to be aware of suspicious behavior and Reporting tampering or substitution of devices. Here periodic means at least daily, if not more often. I have clients that examine their points of interaction (POI) at every management shift change which works out to three or four times a day. Given the POI is becoming the primary target of attacks, this will only become more important as time goes on given the current paradigm.
     
  • 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices) or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). Again, periodic means at least daily, if not more often.
     
  • 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment. This requirement will cause more heartburn for organizations once everyone is on the same page as the Council. Naysayers claim it cannot possibly mean what it says it means. Yet at the 2013 Community Meeting, the Council explained that yes, in fact, they did mean all systems and devices that are not in scope for PCI compliance. However, if you have been producing a risk assessment that does not cover your not in scope systems, you will not be able to comply with this requirement. Without that risk assessment, there will be no way to justify the frequency of how often you review log data for systems not in scope. If anything, this requirement will drive the expansion of a lot of system information and event management (SIEM) solutions as most were bought and sized only for systems that were in scope for PCI compliance.
     
  • 12.10.4 Verify through observation, review of policies and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained. It amazes me the number of organizations that claim to not have had an incident in the last year, even a virus or malware outbreak. Either they were totally dealt with by their antivirus solution (hard to believe), or I am not talking to the people that deal with these issues (probably more likely). As a result, testing (which can satisfy this training requirement) is only being done annually just like business continuity plan testing. Given the ever increasing amount of threats, this sort of training needs to be done more often than just annually. Organizations should be testing their incident response plan on at least a quarterly basis so that people keep their skills up as well we just exercising the plan and finding any gaps or processes that need adjustment.
jeff-hall

Jeff Hall

Principal Security Consultant

Jeff Hall is a principal consultant in Optiv’s advisory services practice on the Payment Card Industry (PCI) compliance team. Jeff’s role is to provide post-sales support and consulting to Optiv’s clients as well as providing support and mentoring to other Optiv team members. He has more than 30 years of experience in project management, information security, information security strategic planning, software evaluation, selection and implementation, voice and data networking, systems analysis and design, information system audit, systems programming, and data center operations.