09
Dec
14

Significant Change And Periodic

UPDATED: Changed comments on requirement 10.6.2 to reflect the correct interpretation of that requirement.

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 want to define them to mean as it is 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 OSes.
  • 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.  But 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 and 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 specific 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 anti-virus 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 anti-virus solution.
  • 5.2 Ensure that all anti-virus mechanisms are maintained as follows: Are kept current, Perform periodic scans, Generate audit logs which are retained 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 to not 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 by 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 for the following: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 to report 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. 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.
  • 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 allows systems to be ranked using an organization’s risk assessment to drive how often log data from systems have to be reviewed.  While systems that directly process, store or transmitcardholder data (CHD) must have their log data reviewed at least daily, other systems that are in-scope can have their log data reviewed less often based on the risk they present to the CDE systems.  Based on assessing the risk to these “connected to” systems, you might be able to justify weekly or even monthly review of log data. I doubt this will have a significant impact because most organizations have implemented internal or outsourced system information and event management (SIEM) solutions and are monitoring all in-scope systems in near real time.  But for those few organizations that are struggling with log reviews without a SIEM, this will afford them a bit of breathing space.
  • 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 anti-virus solution (hard to believe) or I am not talking to thepeople 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 at least testing their incident response plan on 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.

Hopefully we are now all on the same page with these terms.

Advertisements

8 Responses to “Significant Change And Periodic”


  1. 1 Neon
    April 20, 2015 at 12:48 AM

    Hi Guru,

    For sftp account used for automated transfers, can we use public key instead of password? or public key together with the password?

    In the second case do we need to change the password every 90 days?

    • April 20, 2015 at 3:45 AM

      I am assuming when you use the term “public key” you are referring to public key infrastructure (PKI) where there is a public/private key pair as with PGP.

      Using PGP in an automated file transfer situation, your computer system would encrypt the file to be transferred with your organization’s key as well as the key of the organization that needs the information in the file. Both keys in this example require a passphrase to decrypt the file. A properly strong passphrase only needs to be changed when the organization believes the passphrase may have been compromised such as when an employee changes positions or leaves the organization.

      If you are thinking of using an encrypted archive such as with a Zip File, the passphrase or password will need to observe the password change and complexity rules.

      • 3 Neon
        April 21, 2015 at 1:11 AM

        I am referring to the authentication via digital signature generated from private key of user and verified by sftp server using public key. Initially, the private key is generated from the sftp server and passed to the user to use during authentication.
        With this digital signature authentication + password, do password and private key is required to be changed every 90 days for PCI compliance?

      • April 21, 2015 at 5:43 AM

        The digital signature passphrase needs to change whenever the owner believes that the passphrase might have been compromised. The password needs to be complex and change every 90 days or more often.

      • 5 Neon
        April 21, 2015 at 7:34 PM

        Hi Guru,

        Thank you! If I use only authentication via digital signature without password, do I need to change the pass-phrase every 90 days? OR only when the owner think the pass-phrase is compromised?

        Thanks,

        Neon.

      • April 22, 2015 at 5:40 AM

        If the digital signature requires a true passphrase (i.e., a sentence more than 15 characters long) instead of a password (less than 16 characters), then I would go with changing only when believed to be compromised. However, some digital signature solutions will take a complex password as well as a passphrase. If more of a password is used, I would suggest having it changed every 90 days.

  2. 7 Kris
    January 3, 2015 at 3:28 PM

    Nice article however do not agree that all application changes are significant changes (by default). Especially in ecommerce type of the environment where presentation logic is separated from business logic. In my opinion significant change is change that impacts the security of the cardholder data (as operated by application). And QSA should make a judgement and be pragmatic and do not ask client to do pen tests after the logo or css changes – believe me or not saw such QSAs many times. So if there is a SOA based architecture and are changes on views layers (in MVC – Model View Controller logic) then I would accept this as a minor change and do not ask client for pen tests… On the other hand I know it’s very difficult to judge and requires from QSA good understanding of the modules and application architecture to point the right components/modules/services in scope of the assessment.

    Your thoughts PCI Guru ? Thanks for good article…

    • January 4, 2015 at 4:51 PM

      I didn’t say that all application changes were significant, just those that affect the payment process. However, that is where things can get sticky. In your example of a logo change, I have actually encountered such a change creating a problem because the wrong version of code was used and introduced or re-introduced vulnerabilities into the application.

      As a former developer, my frustration comes from the total lack of understanding most developers have of how their applications actually operate. “It just works”, is the typical refrain. As a result, in the majority of instances, the application developer could not tell you the ports/services their application requires to operate properly to save their life. And while everyone gives “lip service” to secure coding techniques, in actual practice, the majority of developers write poorly secured code because they crib most of it from Github or other sources that they think they can trust and are secure because it’s used by everyone else. And heaven forbid you should ask them what they did to review that code from wherever to make sure it was secure and actually did what they thought it did. “Why would anyone put bad code in [name your code source]?” Yes indeed, why would anyone do such a thing?

      It still amazes me how many developers still do not separate business logic from presentation logic even though that has been supposedly a secure coding “best practice” for at least a decade. And just because it is separate, does not mean or even imply that it is secure.

      As you point out, every situation is different and must be individually evaluated.

      However, my logic regarding changes to payment processing still stands. If you made a change to the payment process, that is a significant change.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

December 2014
M T W T F S S
« Nov   Jan »
1234567
891011121314
15161718192021
22232425262728
293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,846 other followers


%d bloggers like this: