PCI DSS

Guidance to Remain PCI Compliant After Making Changes to Your IT Infrastructure

One of the most avoidable PCI 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. By nature, we won’t accept failure, we immediately fight back and declare that it wasn’t a significant change performed, so the term needs to be defined.

What is a significant change in PCI?

A good definition is found in the PCI SSC penetration testing guidance found on the PCI website. Significant change is: “…infrastructure or application upgrade or modification—or new system component installation,” and “If the change could impact the security of the network or allow access to cardholder data, it may be considered significant by the entity.” That said, what constitutes a significant change is really up to you. In the guidance, its stated: “What is deemed “significant” is highly dependent on an entity’s risk-assessment process and on the configuration of a given environment. Because of this variability, a significant change is not prescribed by PCI DSS.” In other words, it’s up to you. I advise my clients to adhere to the security rule.

If the change could potentially impact the security of the cardholder data environment in any way, it should be considered significant.

That includes software upgrades, network changes, device swap outs, and some ‘out of the blue’ changes I’ll discuss later.

So, what do you need to plan to do after the big change? Here’s a list:

1. Perform a scope assessment. The key here is to make sure your in-scope and out of scope environment hasn’t changed. Pay special attention to your segmentation because changes in networks and devices can possibly change your segmentation controls and the scope of your environment.
2. Update your high level, detailed, and dataflow diagrams as appropriate. 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. 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. 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. This is specifically to address requirement 6.4.6, which states, “Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.”  I call this the “Catch all” requirement because it covers all things PCI when you make a significant change. It was added in version 3.2 of the PCI DSS in reaction to changes exposing cardholder data to potential breach.
6. Run internal and external vulnerability scans. Requirement 11.2 is explicit that vulnerability scans have to be run after a significant change. I typically want to see them run immediately, but the PCI DSS doesn’t specify when to run the scans. Don’t delay on this one. It and the one below are the two biggest pitfalls I find in assessments that fail, so it has to be done or you’ll be non-compliant and end up with a failing assessment.
7. Likewise, to vulnerability scanning, run internal and external penetration tests. Requirements 11.3.1 and 11.3.2 explicitly say, “…and after any significant infrastructure or application upgrade or modification.” Similar to 11.2, I want to see these scheduled as quickly as possible. Again, the PCI DSS doesn’t specify when they have to be done. My argument for immediate scanning is risk based. If you’ve introduced a vulnerability into your environment through the change you performed, you run the risk of a threat agent taking advantage of it and impacting your hard fought for protection of cardholder data.
8. Last, perform a risk assessment to cover requirement 12.2. A key note here is that requirement broadens the definition of significant change to include what I call the “out of the blue” changes, “…acquisition, merger, relocation, etc.” As eluded to in the previous bullet, the risks associated with significant changes need to be assessed and addressed. At a minimum, the PCI DSS is looking for two things:
   • Identification of critical assets, threats and vulnerabilities
   • A formal, documented analysis of risk

Here are two examples of significant changes:

1. Say 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 rulebase 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.
2. Another example is you change your content delivery vendor for your webpage – Have you changed any system or configurations on your equipment? The answer is probably no, you just gave your DNS name to the new vendor. So, is it a significant change? Yes, it is, but do you have to perform all the steps above? Probably not all of them, but at the least you need to do the risk assessment. If the risk assessment shows that the vendor you migrated away from was PCI compliant, and the vendor you migrated to is not PCI compliant, you have an introduced risk by the change that needs to be identified and addressed.

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 put a section in the PCI DSS called “Best Practices for Implementing PCI DSS into Business-as-Usual Processes.” 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.

_____________________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

_____________________

Drew Cathey has been a member of the SecureTrust team for five years and has been in IT for 35 years. Coming from a background in telecommunications IT operations, he has held positions in engineering, project management and IT security. Drew holds degrees in biology, engineering and an MBA in Information Technology management along with PMP, CISSP, CISA and QSA certifications. He resides in St. Petersburg, FL with his two children and enjoys running, bicycling and tennis.