• CCWs, Custom Testing, and INFIs – Oh My!

    CCWs, Custom Testing, and INFIs – Oh My!

    In June 2023, the PCI Security Standards Council introduced a new document that you’ll need
    to know about called “Items Noted for Improvement” which is a worksheet and attestation form
    you’ll start seeing as part of your version 4 assessments. But when this was released we
    realised that this was a good opportunity to demystify the differences between:

    • Defined Testing (DT)
    • Customised Approach (CA)
    • Compensating Controls (CCWs)
    • Items Noted for Improvements (INFIs)

    Most assessments will include defined testing and INFIs. Some assessments will include
    compensating controls, and we expect that very few organisations will complete the work
    required to use the customised approach.

    In this post, we will go over some of the basic features of each of these items and help you
    understand how each can be used and when they should be used.

    Defined Testing

    When we talk about defined testing, we are talking about the requirements and testing
    procedures that are part of PCI DSS. These testing procedures have been defined by the PCI
    SSC for how they expect each of the requirements to be tested. This is your “classic” PCI DSS
    requirement.

    Defined tests can have a few different findings:

    • In Place
    • In Place with CCW
    • Not Applicable
    • Not in Place

    In the original release of PCI DSS v4.0, there was a new finding called “In Place
    with Remediation”. That’s no longer a finding, but it’s successor is the INFI.

    You’ll also see that there’s a reference to Compensating Controls.

    There’s no reference to the Customised Approach because this is a change in how the testing is done rather than how the results are reported.

    Customised Approach

    The Customised Approach is new to PCI DSS v4.0. This gives organisations the opportunity to
    approach the PCI DSS requirements in a different way by using the objective.

    But there are a few caveats to this that the PCI SSC calls out which are also the reasons why
    we don’t expect to see the Customised Approach used too often.

    • It can only be used if you are completing a Report on Compliance (RoC) – you cannot use
      it with a Self-Assessment Questionnaire (SAQ).
    • The controls that are implemented must meet or exceed the security provided by the
      requirement in the defined approach.
    • The amount of documentation and effort required to validate the customised approach will
      be greater than what’s required for the defined approach.
    • It is intended only for risk-mature entities with a “robust risk-management approach to
      security, including but not limited to, a dedicated risk-management department or an
      organisation-wide risk management approach”

    There are also some requirements that the Customised Approach cannot be used for.

    If you meet the criteria for considering using the Customised Approach, then you’ll need to complete:

    • Risk assessment annually for each customised approach used
    • Controls Matrix based on Appendix E1
    • Targeted risk analysis based on Appendix E2

    That long with evidence of the validation of the customised approach is provided to the QSA
    who in turn develops their own testing and validation procedures. And at the end of the day,
    there could be things that could derail the custom approach if your compliance-accepting entity
    (usually the acquiring bank or the card schemes) pushes back.

    Compensating Controls

    Compensating controls (CCWs) have been around for a long time. Compensating controls are meant to be used as a proactive way to meet a requirement when you cannot meet the requirement. But there are a few things that need to be in place to use a compensating control:

    • You must have a business or technical constraint for why you cannot meet the
      requirement (not wanting to is not a valid business or technical constraint)
    • You must go “above and beyond” the original PCI DSS requirement
    • You cannot use a control that is already applicable to the technology as a compensating
      control (for example, if the system already requires MFA, you can’t use MFA as a
      compensating control).

    The important thing to note is that compensating controls are meant to be proactive. It is not
    something that should be used as a reaction or remediation activity for a historical failure. A
    compensating control is a “proactive development of mitigating actions”.

    A Compensating Control can never be used with the Customised Approach.

    Items Noted for Improvement

    If you’ve ever had your QSA find something that needed to be fixed before they would sign off
    on the AoC, this is the sort of thing you’ll now see in an INFI. When PCI DSS v4.0r1 was rolled
    out in December 2022 it removed “In Place with Remediation” and the PCI SSC flagged that
    something new would be coming in 2023.

    That something new was released in June 2023 and is referred to as INFIs. An INFI is
    something that is noted as needing correction at the time of the assessment that the
    organisation then fixes.

    Examples of the types of things that would be included in INFIs include but are not limited to:

    • A few people who still need to complete their security awareness training
    • A policy/standard that is missing something that’s required for PCI DSS or that’s missing
      entirely
    • A network change that needs to be made because it was missed as part of a regular
      review process (for example, if the QSA is reviewing the firewall configuration and
      identifies a rule that is no longer needed or that increases the scope).

    There are two new pieces of documentation you’re likely to see during an assessment:

    • INFI Worksheet
    • INFI Worksheet Acknowledgement and Attestation

    The documents are required as part of any Report on Compliance and recommended as part of SAQs.

    INFI Worksheet

    The worksheet outlines any of the findings where a control hasn’t been fully met. What this actually means is that a finding can be identified by either the QSA or the “Assessed Entity” (this just means the organisation that is being assessed).

    The worksheet will only be completed if there are INFIs – if you’ve done everything to the letter for the last 12 months, you might never see this document!

    As part of the worksheet, in order for the requirement to be met, the organisation needs to:

    • Identify what caused the failure.
    • Describe the corrective action(s) taken to fix the issue so that it is now in place.
    • Describe the corrective action(s) taken by the entity to prevent the failure from
      reoccurring.

    The key thing to note is that this is not a “get out of jail free” card – it is possible that there may still be controls that could be considered as “Not in Place”.

    INFI Worksheet Acknowledgement & Attestation

    Regardless of whether any INFIs were identified during the assessment, you will receive an
    acknowledgement form that includes your sign-off and acknowledgement that:

    • The worksheet (as applicable) has been received,
    • That the cause(s) of the failures have been addressed, and
    • The corrective preventative actions have been implemented.

    We recommend that this document is signed by the same person who would sign the
    Attestation of Compliance.

    Can You Combine These?

    At this stage (July 2023), we know there are some reporting approaches that can be combined
    and others that cannot. We think that INFIs will span the breadth of testing procedures because
    there could be a control failure as part of a compensating control or the customised approach.
    But if this changes, we will update the information.

    Summary

    To summarise the information provided above, we’ve put some of the key information into the
    table below. You can use this to work out what might be right for you to use in your
    assessments.

    Need Help?

    If you need help developing your compensating controls or custom approaches or just
    validating your PCI DSS compliance, talk to us to see how we can help you. We can help
    demystify PCI DSS.

  • Version 4 SAQs are Out – What’s New

    Version 4 SAQs are Out – What’s New

    It’s finally happened – on April 1st NZ time, PCI DSS v4.0 was released, and then on April 28th
    we saw the Self-Assessment Questionaries released. In this post we cover at a high level
    what’s changed and what stays the same.

    What Stays the Same

    The good thing about the SAQs is that the actual SAQs types have stayed the same – so odds
    are good that if your payment channels haven’t changed, you’ll still be looking at the same
    report type. We still have all the same SAQ names that you’re used to hearing about and no
    new SAQ types have been added.

    But that’s about where the similarities end. Sure, there are plenty of requirements that stay the
    same, but we know those aren’t the things that people are interested in.

    SAQ D (Service Providers)

    The biggest changes that are coming are for service providers. We will be covering this in more
    detail in a separate post. Service providers in v4.0 will have a more in-depth reporting process
    – gone are the days of just tick boxes, and a summary of the reporting is now required.

    SAQ A

    For those of you who complete SAQ A, you can expect to see some changes to which
    requirements you have to comply with. Overall, a few more controls have been added that we
    have always considered as basic security controls. This includes ASV scanning (not previously
    required) and more monitoring of servers and code (new requirements for e-commerce
    merchants).

    SAQ A-EP

    SAQ A-EP sees more updates to requirements as well as new requirements being added.
    Things like phishing and more robust management of user accounts are featured in the updated
    SAQ A-EP. It also includes the same monitoring of servers and code mentioned in SAQ A. And
    one thing that people will need to be aware of is the new requirement around the integrity of the
    MFA system – start thinking now about whether your MFA provider has an attestation of
    compliance and if they don’t already have one for that service, hopefully they will have one
    before this requirement comes into force.

    SAQ B & B-IP

    We’ve combined these SAQs in this post because neither of them gains any of the
    requirements new to PCI DSS v4.0.

    SAQ P2PE

    SAQ P2PE loses a requirement in Version 4.0! The only thing new to add is a requirement
    around storage of SAD prior to authorization. This is the SAQ that stays the most the same out
    of all of them.

    SAQ C

    SAQ C picks up more requirements than some of the other SAQs. In version 4.0 it also includes
    antivirus updates, TLS management updates, anti-phishing updates, passwords are longer, and
    MFA will apply to all access to the CDE, not just admin access to the CDE. There is a much
    greater focus on authentication systems, including management of service accounts and the
    integrity of MFA systems. Automated log tools will now be required and certain “periodic”
    requirements will need to have a targeted risk assessment completed. Overall, SAQ C is one of
    the bigger changes to the SAQs.


    SAQ C-VT

    C-VT adds a few more requirements in version 4 – antivirus scanning gets expanded to include
    continual behavioural analysis, Anti-phishing gets added and password lengths increase in line
    with the other SAQs that include password length requirements.


    SAQ D Merchants

    Unlike SAQ D for Service Providers, SAQ D for Merchants stays the same in how reporting is
    handled. No additional sections have been added to the SAQ. All of the new requirements from
    v4.0 (excluding those that are specific to service providers) are included in SAQ D for
    merchants.


    Summary

    Overall, many of the updates are iterative with most SAQs only adding a handful of new
    requirements. The biggest change for the SAQ is with SAQ D (Service Provider) which takes an
    entirely new approach to how service providers completing a SAQ are required to report.

    We will go into more depth on these SAQs in the coming weeks, so look out for more
    information which will also be linked below:

    • SAQ D (Service Provider)
    • SAQ A (More Information Coming Soon)
    • SAQ A-EP (More Information Coming Soon)
    • SAQ B (More Information Coming Soon)
    • SAQ B-IP (More Information Coming Soon)
    • SAQ P2PE (More Information Coming Soon)
    • SAQ C (More Information Coming Soon)
    • SAQ C-VT (More Information Coming Soon)
    • SAQ D (Merchant) (More Information Coming Soon)

    Need More Information?

    If you’re wondering how PCI DSS version 4 will impact your existing PCI compliance, we can
    help you proactively develop a roadmap to move from version 3.2.1 to version 4.0. At Confide
    we love talking about PCI DSS and understanding how security and compliance can fit into the
    way that organisations do things. Contact us for more information.

  • Service Providers – What is Changing in PCI DSS v4.0?

    Service Providers – What is Changing in PCI DSS v4.0?

    Service providers have always had a slightly different focus in PCI DSS because as a service
    provider you have the ability to impact your customers’ PCI DSS compliance and overall
    security. Whether that’s through providing certain managed services like managed firewalls or
    data centres, your customers expect you to be able to demonstrate that certain requirements
    are met. The easiest way to do this is by completing your own PCI DSS compliance (rather than
    being included in multiple customer assessments).

    However, the way that service providers need to report is changing with PCI DSS version 4.0.
    The report type that needs to be completed is not changing for service providers (you still need
    to complete either SAQ D – Service Providers or a Report on Compliance (ROC)).

    In this post we will focus on SAQ D for service providers, but don’t worry, we will be publishing
    more information about the RoCs and service provider requirements separately.

    New Reporting Format

    The biggest change for service providers who are using SAQ D (Service Provider) is that there
    is a much greater level of reporting needed. In PCI DSS v3.2.1 SAQ D (Service Provider)
    looked the same as the other SAQs (just with a lot more requirements). But now, the SAQ is
    much more like a mini-RoC with each requirement needing an explanation of how the finding
    was reached.

    Along with each requirement having a summary of the findings, the SAQ also now requires:

    • Network diagrams
    • Information about any storage of account data
    • Information about any storage of sensitive authentication data (SAD)
    • Information about each of the system components included in the scope
    • Results of quarterly ASV scanning

    This is all information that you would see in a full RoC.

    Unlike the RoC, SAQ D (Service Provider) does not have any ability to do custom testing – so if
    you want to do custom testing you will have to complete a RoC with a QSA.

    What Do These Changes
    Actually Mean?

    Things are changing quite a bit in version 4.0 for service providers.

    • Expect to spend more time on the process – all of the testing processes need to be
      followed and reported on, expect to have to interview people and review systems.
    • Expect to need to have someone who understands PCI DSS so that the answers provided
      make sense (PCIP, ISA, QSA)
    • Expect to have to have cross-functional participation for completing the report – not
      everyone will have the expertise to assess the questions, and you’ll have to make sure
      that the roles involved understand why they need to be involved
    • If your report is not easy to understand or is not comprehensive, there may be more
      queries from your merchants who are relying on your compliance because they may not
      understand what you have explained
    • If your report is well written, easy to understand, and comprehensive, you stand a chance
      to benefit from fewer queries because their questions have already been answered

    Overall, SAQ D for Service Providers is adding some complexity, but will benefit merchants in
    the long run who will gain a far greater understanding of how their security is being managed.

    Are You a Service Provider?

    If you’re a service provider and you need help figuring out this new reporting format or what the
    new reporting means for you, Confide can help. We’ve worked with many service providers in
    NZ to help them achieve PCI DSS compliance. Contact us to find out how we can help you
    become PCI DSS compliant against PCI DSS v4.0.

  • Rapid Requirements: When You Miss a Requirement

    Rapid Requirements: When You Miss a Requirement

    Missed a Requirement?

    A new way that we see reporting changing in v4.0 is that it brings in a new process for when
    you miss a requirement and how it could still be considered as meeting your compliance
    requirements. It’s not a “get out of jail free” card, and it’s not an excuse to miss PCI
    requirements. But we all know that things happen. So make sure when planning for v4.0 you
    have a process for any PCI activities with a specified or periodic frequency that includes:

    • A prompt notification when a task is not performed at it’s defined frequency
    • A process to determine the events that led to missing the scheduled activity
    • Performing the activity as soon as possible after it is missed and then either gets back on
      schedule or creates a new schedule
    • You document all of these above points.

    But, if you don’t have these processes or the task was missed because of oversight, mismanagement, or because you didn’t have any monitoring that would let you meet the first bullet point, you’re unlikely to be able to demonstrate your compliance with the missed requirement until:

    • You document the process to make sure the task is performed on time
    • You re-establish your schedule
    • You provide evidence you’re back on schedule (e.g. you perform the task on schedule and
      provide evidence of this)

    Start looking at your processes now so you can figure out how to get notifications to keep your
    regularly scheduled tasks on time and minimise the risk of falling out of compliance

    Need Help?

    Regardless of whether you’re a merchant or a service provider, Confide can help you with your
    PCI compliance. Talk to us to see how we can help you.