Staying PCI Compliant After Infrastructure Changes

​One of the most avoidable Payment Card Industry Data Security Standard (PCI DSS) failures we see time and again is significant change follow-up. What happens is you make a change to your infrastructure, resume processing, and move on with the newly changed environment in the new configuration. Months later, your Qualified Security Assessor (QSA) walks in and asks, "Did you perform due diligence after the change?" Then the cold sweats start happening because you didn't. It becomes an instant failure and has tripped up many companies in the past. Most of us, by nature, won't accept failure; humans are excellent at finding excuses, declaring that the change was not significant, and that no additional testing was needed. As the definition of what constitutes a significant change is somewhat subjective, the term needs to be defined.

​What is a significant change in PCI DSS 4.0?

​With the release of PCI DSS 4.0, and the update to 4.0.1, the Payment Card Industry Security Standards Council (PCI SSC) has expanded the definition of significant change to provide clearer guidance. According to the standard, what constitutes a significant change is still highly dependent on an entity's risk-assessment process and the configuration of a given environment. However, PCI DSS 4.0.1 now explicitly states that, at a minimum, each of the following activities has potential impacts on the security of the cardholder data environment (CDE) and must be considered a significant change:

• ​New hardware, software, or networking equipment added to the CDE.
• ​Any replacement or major upgrades of hardware and software in the CDE.
• Any changes in the flow or storage of account data.
• Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.
• Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring.
• Any changes to third-party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.

​I always advise my clients to adhere to the security rule:

​If the change could potentially impact the security of cardholder data and/or sensitive authentication data in any way, it should be considered significant.

​What do you need to do after a significant change?

​Here's a list of actions to take, updated for PCI DSS 4.0:

1. ​Perform a scope assessment (Requirement 12.5.2). The key here is to make sure your in-scope and out-of-scope environment hasn't changed. Pay special attention to your segmentation controls; changes in networks and devices may impact your segmentation and thereby the scope of your environment. This is now an explicit requirement in PCI DSS 4.0.1.
2. ​Update your network and dataflow diagrams (Requirement 1.2.3 and 1.2.4). A natural progression of the scope assessment, the changes made to your environment will typically change your diagrams too.
3. ​Reflect the changes in your inventory (Requirement 12.5.1). Whether it be software or hardware changes, in most cases, the changes to your environment will necessitate a change in your inventory. Again, this is a progression out of your scope assessment because the inventory is a result of your scoping activities.
4. ​Make sure your change is accurately reflected in a change record (Requirement 6.5.1). This sounds like a no-brainer, but you'll need the change records later for PCI reporting, and you don't want to get caught without appropriate documentation of the change.
5. ​Review and assess if you've applied all appropriate PCI controls (Requirement 6.5.3). This requirement explicitly states, "Upon completion of a significant change, all relevant PCI DSS requirements are implemented on all new or changed systems and networks, and documentation is updated as applicable." I call this the "Catch all" requirement because it covers all things PCI when you make a significant change.
6. ​Run internal and external vulnerability scans (Requirements 11.3.1.3 and 11.3.2.1). PCI DSS 4.0.1 is explicit that vulnerability scans have to be run after a significant change. Note that PCI DSS now requires authenticated scanning for internal vulnerability scans. For external scans, vulnerabilities scored 4.0 or higher by the CVSS must be resolved. Typically, you should aim to run scans immediately, though the PCI DSS doesn't specify an exact timeframe. Don't delay on this one. Failure to run scans and perform penetration testing as detailed below are the two biggest pitfalls VikingCloud finds in assessments that fail.
7. Run internal and external penetration tests (Requirements 11.4.3 and 11.4.4). These requirements explicitly require penetration testing after any significant infrastructure or application upgrade s or changes. Similar to vulnerability scanning, you should schedule and execute these as quickly as possible. You need to consider the potential risk introduced by the change; If you've introduced a vulnerability into your environment through the change, you run the risk of a threat actor exploiting it and compromising cardholder data.
8. Perform a targeted risk assessment (Requirements 12.3.1). PCI DSS 4.0.1 places emphasis on performing a Targeted Risk Analysis (TRA) for specific controls, and requires that they be performed at least annually and as needed, for example, when a change occurs.
9. ​For service providers: Perform additional due diligence (Requirements 12.5.2.1 and 12.5.3). If you're a service provider, PCI DSS 4.0.1 requires you to perform scope confirmation at least every six months. Additionally, when a significant change occurs, you must perform a documented scope impact analysis and share it with executive management.

​Examples of significant changes:

• ​Example 1: You swap out all your firewalls from one brand to another – Firewalls provide your segmentation controls in many cases, and they are your main defensive boundary for the cardholder data environment. If you migrated from one brand to another and didn't get your rule base exactly as it was before, you could possibly introduce a tremendous amount of risk of exposure of the cardholder data. Perform due diligence and close any gaps you find in your analysis.
• Example 2: You change your content delivery vendor for your webpage – Have you changed any system or configurations on your equipment? The answer is probably no; however, you just gave your DNS name to a new vendor. So, is it a significant change? Yes, it is, but your analysis under 6.5.1 may conclude that the change impacts a limited set of requirements. Even if the change analysis shows that the vendor you migrated away from was PCI compliant, and the vendor you migrated to is PCI compliant, you may have introduced risk by the change that needs to be identified and addressed.

​Conclusion

​My goal is to raise awareness that you need to incorporate PCI planning into your change activities before the actual change(s) takes place. The PCI SSC takes this very seriously, which is why they have emphasized "Business-as-Usual" processes in PCI DSS 4.0.1. The standard now offers the option to use a customized approach that, while providing more flexibility, also requires more documentation and formal risk analyses.

​As you and your team review upcoming changes, keep PCI compliance in the forefront and make sure you're covered all the time – not just once per year before your annual assessment. The consequences of failing to address significant changes properly can be severe, including failed assessments, potential breaches, and reputational damage.

Click here to contact us for all your SMB Compliance, Merchant Risk Management, and Compliance Technology needs.