Book a discovery call

  • What Makes a Change Significant?

    What Makes a Change Significant?

    One of the most frequent questions we get is what the term “Significant Change” means for PCI. In this article we try to demystify this term a little and help you understand the various ways that the term is used in PCI DSS.

    What is Significant Change?

    The PCI SSC says that a significant change varies depending on your environment and your organisation (What is a “significant change” for PCI DSS Requirements 11.2 and 11.3?).

    They help by providing some examples of things that are considered as the minimums for significant change, which are:

    • Changes affecting access to cardholder data
    • Changes affecting the security of the cardholder data environment

    And examples of the above may include, but are not limited to:

    • Network upgrades
    • Additions or updates to firewalls or routing devices
    • Upgrades to servers

    Even with these examples of significant changes, the key thing to keep in mind is that you and your organisation need to have a clear definition of what constitutes a significant change so that changes can be identified and analysed to determine if they meet the criteria for a significant change. If you don’t have a documented common understanding of what represents a significant change in your environment, there may be a significant risk that someone else in your organisation doesn’t identify a change as significant and some of the PCI requirements that apply could be missed.

    What Does This Actually Mean?

    What this actually means for your environment is not as straight forward. There are five key requirements in the PCI Report on Compliance (RoC) and Self-Assessment Questionnaires (SAQs) that relate to significant changes, one part of the AoC that relates to significant changes, and two additional requirements in the Supplemental Report on Compliance / Designated Entities Supplemental Validation (S-RoC / DESV) that relate to significant changes.

    • Requirement 6.4.6: 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.
    • Requirement 11.2.3: Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.
    • Requirement 11.3.1: Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
    • Requirement 11.3.2: Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment)
    • Requirement 12.2: Implement a risk-assessment process that:
      • Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)
      • Identifies critical assets, threats, and vulnerabilities, and
      • Results in a formal, documented analysis of risk.
    • Requirement A3.2.1 (DESV): Document and confirm the accuracy of PCI DSS scope at least quarterly and upon significant changes to the in-scope environment.
    • Requirement A3.2.5 (DESV): Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder data environment or processes.
    • Part 3a (AoC): If my environment changes, I recognise that I must reassess my environment and implement any additional PCI DSS requirements that apply.

    What you will need to do to meet each of these requirements varies from performing an out of cycle vulnerability scan through to performing a full re-assessment of your environment.

    Documenting Significant Changes

    The starting point for understanding what it means for your environment though is Requirement 6.4.6 which focuses on ensuring that you have a process to identify significant changes and that your change management process includes documenting the supporting evidence for the steps you have taken in relation to a significant change.

    The guidance in Requirement 6.4.6 states:

    A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:

    • Network diagram is updated to reflect changes.
    • Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.
    • Systems are protected with required controls – e.g. file integrity monitoring (FIM), antivirus, patching, audit logging.
    • Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data-retention policies and procedures.
    • New systems are included in the quarterly vulnerability scanning processes.

    These examples are not meant to be exhaustive, but should provide a starting point for how you can review your changes to first understand if they are significant and next to understand what additional steps you need to take for them.

    We recommend storing all the associated evidence with the significant change to make it easier for your team to locate the evidence when requested by the QSA.

    We also recommend considering how you can template certain types of significant changes so that everyone involved in the change understands what further steps need to be taken. But to do this, you need to understand what kinds of events will be considered significant changes for your organisation.

    Common Challenges

    The most common thing that we come across is that people do not want to consider a change as significant or do not have a clear definition of a significant change. The result is that staff don’t understand what PCI considers as a baseline significant change, and tasks may not be completed. For example:

    • Vulnerability scans may be missed or not occur as part of the change
    • Penetration testing may not be completed or may be booked significantly after the change has occurred.
    • PCI controls may not be applied and not discovered until the PCI assessment
    • Firewall rules for decommissioned servers may not be removed.
    • Documents may not be updated and network diagrams may be missing new systems or showing systems that were removed.
    • Change documentation may not show all the detail required for Requirement 6.4.6.

    We’ve repeated it a lot in this article, but the best way to avoid these challenges is to remove the stigma of a significant change by:

    • breaking down what is required for types of significant changes, and
    • making sure that the definition of a significant change is clear to the staff who are working with these changes on a daily basis.

    Make sure that key staff are involved in the discussion of what a significant change is so that you have something that works within your organisation and develop processes that minimise the challenge of identifying what steps to take if you have a significant change.

    A change might be significant, but if you’ve set up your processes well, a significant change can become just another part of your business as usual (BAU) activities.

    Thinking of Making a Change?

    If you’re thinking of making a significant change to your environment, Confide can help review it and make sure that it won’t negatively affect your PCI DSS compliance. Contact us to find out more.

    zuno

  • What’s My PCI Scope?

    What’s My PCI Scope?

    The word “scope” gets used a lot when you’re talking about PCI DSS. But it is also often misunderstood. This article provides some basic information about scope and how to start understanding what is in-scope for PCI DSS.

    Who is Responsible for Scoping?

    Both you and your QSA need to be able to understand the scope of your environment.

    As a merchant or service provider, you are responsible for:

    • Defining your scope
    • Documenting your scope
    • Reviewing your scope for accuracy

    Your QSA is responsible for validating the scope that you have defined.

    That makes it even more important to make sure that when we talk about scope, everyone has the same understanding.

    In-Scope or Out-of-Scope?

    One of the biggest mistakes the people make is considering that only those systems that store, process, or transmit cardholder data are the only things that is in-scope for PCI DSS. Collectively, this set of systems is referred to as the Cardholder Data Environment, or CDE. But there will always be other systems that come into scope for PCI DSS. We recommend reading the PCI SSC’s Guidance for Scoping and Segmentation, but we will summarise some of the key points here.

    In-Scope

    For a system to be in-scope for PCI DSS, it only needs to meet any one of the criteria in the bullet points below.

    The CDE consists of any systems that:

    • Store cardholder data
    • Process cardholder data
    • Transmit cardholder dat
    • Is in the same VLAN as a system that stores, processes, or transmits cardholder data.

    Other systems that are in-scope for PCI include:

    • Systems that are directly connected to the CDE
    • Systems that are indirectly connected to the CDE
    • Systems that impact the configuration of systems in the CDE
    • Systems that perform security services
    • Systems that support PCI DSS requirements
    • Systems that provide segmentation.

    Out-of-Scope

    For a system to be out of scope, it needs to meet all of the criteria from the bullet points below.

    • Not part of the CDE
    • Not in the same network segment as the CDE
    • Cannot connect directly to the CDE
    • Cannot connect indirectly to the CDE
    • Does not meet any of the CDE or in-scope criteria

    Overall, for a system to be out of scope for PCI, it should not be able to connect in any way to the systems that are. It is possible to have shared security services. But you need to make sure that it does not grant any unintended indirect access to the CDE.

    How Do You Scope?

    We recommend that you start by asking yourself some key questions about your systems and data flows. To start, make sure you have all your key documents and people in a room. This means things like your network diagrams, cardholder data flow diagrams, and people who understand the networks, systems, and applications.

    Then you can start asking questions to understand more of your scope, such as:

    • Are all the payment channels included in the cardholder data flow diagrams? Do we have any other channels where we get cardholder data or export it?
    • Where is credit card data stored, processed, or transmitted? If you don’t store, process, or directly transmit cardholder data, how do your customers transact and how do you protect the transaction process?
    • Have you identified each system that performs a function as part of a PCI requirement?
    • Are all of the systems you’ve identified so far on the network diagrams?
    • Have you looked at the firewalls to identify any connections to the CDE?
    • Have you looked at your system inventory to identify what else sits in your CDE?

    Once you start answering these basic questions you get a better idea of what might be in-scope for PCI DSS and how you can remove things from scope. While this level of detail may seem like a lot of work, it will help you develop a clear picture of what your environment looks like and help ensure that you are applying the relevant PCI controls to avoid scope creep and surprises during your assessment.

    Need Help?

    If you need help with scoping, Confide can assist with scope reviews regardless of your size or transaction processes. Contact us to find out how we can help define, document, and in some cases reduce your scope.

    zuno

  • My Service Provider Isn’t Compliant, Now What?

    My Service Provider Isn’t Compliant, Now What?

    Currently, there is no requirement to use a PCI compliant service provider (although the card brands and banks may require you to do so). If you are outsourcing some of your compliance responsibilities to a third-party, you need to understand what this means for your own PCI DSS compliance.

    If you use a service provider for something that is in-scope for your compliance, they need to be able to demonstrate that they are providing that service in a compliant manner. This can be done either by:

    • Having the service provider provide their current Attestation of Compliance (AoC) (and Responsibility Matrix if they have one) which covers the service they are providing OR
    • Including them within the scope of your assessment either at your cost or an agreed shared cost.

    If your Service Provider can provide you with an AoC, you need to make sure that you keep a copy of that for your records and for your QSA to review. And make sure that if you’re expecting them to be responsible for a requirement that it is covered within the scope of their AoC. Finally, make sure the Service Provider provides you with an updated AoC annually.

    But since our focus is on Service Providers who cannot provide an AoC, let’s look at how that will affect the scope of your assessment.

    What Does it Mean to Include Someone in the Scope of Our Assessment?

    Put simply, this means that your QSA would expect to be able to review the way that the third-party provides the services to you to ensure that they are meeting your compliance requirements.

    This means that your QSA will need to conduct interviews with them, review their system configurations, review their processes, and review their documentation depending on what services they are providing.

    What it does not mean is that everything done by the service provider comes into scope. Only the processes and services they provide to you as well as some potential supporting services will be in-scope.

    One common example of a service provider without an AoC that we see is data centres and physical hosting. While more data centres are doing PCI compliance (we do strongly recommend checking this as part of your due diligence when signing a contract with them) it provides an easy example of how including someone in your own compliance review works.

    If a data centre is included in your assessment and they do not have an AoC, your QSA would visit the data centre, observe visitor logs and CCTV footage, look at access logs (for your racks), physically check to make sure the racks are locked, observe visitor processes, and interview staff about these processes and supporting processes.

    While this is just one example, the high-level processes are the same. Your QSA needs to verify that the service is being provided in a way to ensure you can become (or remain) PCI DSS compliant.

    Other Considerations

    One of the most important things to consider is making sure that your Service Provider is aware of the need for them to provide a compliant service. Review the services you are using and make sure that each Service Provider:

    • Is aware of their PCI requirements AND
    • Has acknowledged their PCI requirements

    Where possible there may be a contractual obligation for the Service Provider to be PCI DSS compliant. Most importantly, doubly ensure that you have a right to audit built in to your contracts so that you’re not leaving things to chance if they aren’t PCI compliant or they fall out of compliance.

    Now What?

    With a basic understanding of your Service Providers, the next step is to build a responsibility matrix so that you understand which Service Providers are responsible for which PCI DSS requirements. You can find more information on the PCI SSC Third-Party Security Assurance and Shared Responsibilities document on page 43, or Confide can assist you in understanding your service providers and how they affect your PCI compliance.

    Need More Help?

    If you need more help to understand how your Service Providers could affect your PCI compliance, contact us to find out how Confide can help.

    zuno

  • Service Provider or Merchant?

    Service Provider or Merchant?

    If you’re reading this, you’ve probably been told that you need to be PCI compliant, either by your bank or by your customer. Even if you don’t directly accept credit or debit cards, PCI DSS may still apply to you if you have the ability to affect the security of someone else’s cardholder data environment.

    This means if you’re a managed service provider, a data centre, a web hosting provider, or you develop software or applications for one of your customers, PCI DSS might apply to you.

    What’s the Difference Between a Service Provider and a Merchant?

    Let’s start with the definitions from the PCI Security Standards Council.

    Merchant

    “A merchant is any entity that accepts payments for goods and services.”

    Service Provider

    “A service provider is any entity that is not a payment brand, that is directly involved in the storage, processing, or transmission of cardholder data on behalf of another entity. Service providers also include companies that provide services that control or could impact the security of cardholder data (for example, managed firewalls, hosting providers, etc.).”

    Can You Be a Service Provider and a Merchant?

    Absolutely! In the definition of a merchant, it specifically states that an entity “that accepts payment cards as payment for goods and/or services can also be a service provider if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers”. So as a hosting provider, you may take credit card payments for your services (making you a merchant), but you are also a service provider for the web hosting services that you provide to your customers who use your services to take payments on their website.

    Reporting Requirements

    Your transaction level is part of what determines your reporting requirements. Your reporting requirements might also be driven by your bank’s request, the card brands’ request, or your customers’ request. Once you store, process, or transmit more than 300,000 transactions annually, you are required to complete a full report on compliance or RoC which requires a full independent assessment by a QSA. This is much lower than the threshold for a merchant which requires more than 6 million transactions before a RoC is generally required.

    Self-Assessing

    If you are able to self-assess, service providers must use SAQ D for Service Providers. Having to use this form does not mean that all requirements are immediately applicable to you. But you will need to review them all to understand which ones are. Sometimes your stakeholders might require an independent assessment to help give them and other interested parties a level of confidence in your organisation’s security practices. As a service provider you cannot use any of the other SAQ forms.

    Additional PCI Requirements

    Finally, as a service provider you are also expected to comply with some additional requirements. There are approximately 17 additional requirements specific to service providers in PCI DSS v3.2.1. You may also have to comply with Appendix A1 or A2. Once again, you might not have to comply with all of the requirements specific to service providers, and it may only be a sub-set of these requirements depending on the services that you provide.

    After Reading All That, Do I Really Have to be Compliant?

    In New Zealand, all of the main acquiring banks have a requirement as part of the merchant agreements that merchants must be PCI compliant.

    Merchants are not currently required to use PCI compliant service providers. However, your bank or the card brands may mandate that you only use compliant service providers.

    If you are a service provider and you are not compliant as such, your customer will need to include you within the scope of their own assessment. This means that an assessor will need to interview your staff, review system configurations, and review documentation to ensure that the customer’s services are being provided in a complaint manner.

    If you have several customers who have PCI DSS requirements, you may find that it is more cost effective to undertake an assessment as a service provider. The result is that rather than being included in each of your customers’ assessments, you would only need to provide a copy of your Attestation of Compliance to your customers annually once your PCI assessment is completed.

    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.

    zuno

  • What Do I Need to Scan to be Compliant?

    What Do I Need to Scan to be Compliant?


    The Payment Card Industry Data Security Standard (PCI DSS) requires several types of scanning to be completed. This article provides an overview of the types of scanning, frequency for scans, and what it typically applies to in the environment. The table below provides a summary of this.

    Scan TypePCI RequirementRequired FrequencyRecommended Frequency
    Cardholder Data ScanningValidation of Scope – Card scanning is one optionNot requiredQuarterly to validate scope
    Web Application ScanningReq. 6.6After any changeDaily
    Rogue Wireless ScanningReq. 11.1QuarterlyQuarterly
    Internal Vulnerability ScanningReq. 11.2.1QuarterlyMonthly
    External Vulnerability ScanningReq. 11.2.2QuarterlyMonthly

    Validate Scope with Cardholder Data Scanning

    PCI DSS does not require you to specifically complete scanning for cardholder data unless you are completing an S-RoC (Supplemental Report on Compliance) / DESV (Designated Entities Supplemental Validation). However, customers often use cardholder data scanning to validate the scope of their assessment or to validate that they can use a particular self-assessment questionnaire (SAQ) which requires you to attest that you are not storing any cardholder data.

    When scanning for cardholder data, it is just as important to scan where you think there may be cardholder data as where you would not expect there to be cardholder data. We quite often find cardholder data including recycle bins, application log files, database tables in the wrong field, and even PowerPoint presentations!

    Protect Your Web Application

    PCI provides two options for how you can protect your web application in Requirement 6.6. The two options are:

    • Manual or automated application vulnerability security assessment tools or methods at least annually and after any changes OR
    • Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications to continually check all traffic.

    The important thing to note in Requirement 6.6 is that it specifically states that the manual or automated security assessments are not the same as the vulnerability scans performed for Requirement 11.2.

    Many of the companies that provide vulnerability scanning offer separate tools focusing on web application vulnerability scans. And these services can be added on fairly easily. Once you find a service that can check for common web application vulnerability (e.g. OWASP-type vulnerabilities), it’s a matter of scheduling your scans and creating a process for fixing vulnerabilities that are identified.

    The biggest challenge in Requirement 6.6 is that it requires testing after any change. Depending on your release cycle, this may be several times a day, once a month, or even less frequently. The important thing is to ensure that changes to your web application are aligned with scheduling scans. We recommend aligning the scans with your release to UAT or pre-production and then running the scans again after the release to production.

    To round out the process, ensure that there is a process to get information from the web application vulnerability scans to your developers so that they can fix any issues before the change is pushed to production.

    Web application scans need to be run against any external-facing web application.

    Wireless Networks

    Much like Requirement 6.6, Requirement 11.1 offers two ways that you can approach identifying any rogue wireless networks or devices in your network:

    • Wireless scanning
    • Automated monitoring (for example, wireless IDS/IPS, NAC, etc.)

    These scans need to be carried out even if you do not have any in-scope wireless networks in your environment and needs to be carried out across all of your in-scope locations (including offices and data centres). Some data centres provide rogue wireless scanning as part of their Attestation of Compliance (AoC), but make sure that Requirement 11.1 is included in the scope of the services or you will need to ensure there is a process to complete this scanning yourself.

    As part of the scanning process, the goal is to understand what “normal” looks like. So getting a baseline understanding and working from there to identify things that change  and identifying criteria to understand what is suspicious will help you streamline your manual processes.

    Internal and External Vulnerability Scanning

    PCI requires that internal (Req. 11.2.1) and external (Req. 11.2.2) vulnerability scanning are carried out at least quarterly and after significant changes.

    Your external vulnerability scanning must be carried out using an Approved Scanning Vendor. Make sure that you check that your vendor is on the list of ASVs on the PCI website.

    Internal vulnerability scanning does not have to be carried out by an ASV, but many of the ASVs offer both internal and external scanning tools which can make the process easier than running multiple tools.

    Scans and Re-Scans

    The first thing you should do is make sure that you are scanning everything that needs to be scanned.

    For external scanning, this means scanning any external interface that has the ability to affect the security of your in-scope environment. This means that aside from scanning the IP address for your payment page (or redirect page, etc.), you should may also need to be including things such as:

    • VPN connections
    • Externally accessible management services
    • VoIP services
    • Mail servers
    • etc.

    We often see that supporting services get missed in external vulnerability scans.

    For internal vulnerability scans, you need to ensure that they cover all of your in-scope environment including the CDE, your management zones, and potentially even workstations that are in-scope.

    It’s not enough to just scan your environment once per quarter though. You need to make sure that you achieve a passing scan each quarter. You also need to be able to show that you are running (and passing) internal and external vulnerability scans after any significant changes.

    What is a Passing Scan?

    The PCI SSC has two FAQs that are useful to read:

    For external scans, make sure that there is a process to get an attested scan each time you run the scan (at least quarterly). We recommend that scans are run monthly in case vulnerabilities are identified that need to be fixed. This gives you the longest possible timeframe to fix the vulnerabilities and still get a passing scan with in the quarter (90 days).

    For internal vulnerability scans, the scanning process does not include an attestation process. So you need to make sure that as part of the scans, all the “High” and “Critical” vulnerabilities are addressed as well as vulnerabilities that do not result in an automatic failure. There may also be other vulnerabilities that you as an organisation want to address but that do not fall into either of these categories.

    With internal vulnerability scans, the process of managing “false positives” is managed internally and you need to ensure that any false positives are recorded and actioned so that when your QSA reviews the results, they understand the findings (especially if there are vulnerabilities present which result in a failed internal vulnerability scan).

    PCI does understand though that sometimes it may take multiple vulnerability scans to get a passing scan. Therefore, they set out clear guidance in FAQ 1152 for what is needed to meet the quarterly scan requirement:

    • Scans of all in-scope systems were performed for each quarterly period, and all in-scope systems are covered by the entity’s scan-remediate-rescan processes.
    • Rescans were performed as necessary, and show that vulnerabilities identified in the initial quarterly scans have been remediated, for all affected systems, as part of the quarterly process.
    • The entity has processes in place to remediate currently identified vulnerabilities.
    • Repeated failing scans are not the result of poor remediation practices resulting in previously identified vulnerabilities not being properly addressed.

    The last bullet point is probably one of the most important ones. A vulnerability should not be present on your scans quarter after quarter showing the same failing vulnerability on the same server as this would in most cases indicate a poor remediation processes.

    What Happens if I Miss a Quarterly Scan?

    The biggest question is always: what happens if a scan is missed or the requirements for a passing scan are not met? If your QSA is not able to get evidence of four passing scans in the last year, they will not be able to mark this requirement as in-place. In the worst case scenario, this could mean that you could be non-compliant for several quarters while the requirement for passing scans is met.

    This is why it is important to ensure that you:

    • Schedule and automatically run scans more frequently than quarterly.
    • Regularly review the findings of these scans
    • Have a clear remediation process in place
    • Regularly perform re-scans until the failing vulnerabilities are fixed.

    Remember, always scan-remediate-rescan!

    Need Help With Scanning?

    Read more about Confide’s Managed Vulnerability Scanning Services and Card Scanning as a Service. Contact us to find out how we can help you.

    zuno

  • Automated Pen-testing and PCI DSS: A QSA Perspective

    Automated Pen-testing and PCI DSS: A QSA Perspective

    Automated penetration testing (pen-testing) is an up-and-coming approach that aims to address the issues businesses face with more traditional approaches to pen-testing, which relies almost completely on the skill and experience of pen-testers and the budget and timeframes applied to the pen-testing engagement.

    Caveat

    The author of this article has not evaluated or reviewed an automated pen-testing solution as part of research or during a PCI DSS assessment. All information regarding automated pen-testing solutions has been sourced from vendor-provided documentation publicly accessible on the Internet. The article does not endorse nor provide a formal opinion as to whether an automated pen-testing solution meets applicable PCI DSS requirements but merely provides discussion points regarding compliance based on the documentation available to the author. The author is not a qualified pen-tester but is an active QSA.

    What is Automated Penetration Testing

    Automated pen-testing is an approach where systems and devices are continuously scanned to detect vulnerabilities within the business. The service automatically attempts to exploit the vulnerabilities using pen-testing tools and techniques without the need for a human pen-tester. Automated pen-testing tools appear to have been built on years of automated vulnerability scanning, making the leap to attempting to exploit the vulnerabilities that have been found. The benefits of automated pen-testing systems are readily apparent and attractive to any business requiring pen-testing as part of their compliance obligations such as PCI DSS.

    Benefits of Automated Penetration Testing

    The benefits include:

    1. Continuous pen-testing of systems. Instead of the traditional point-in-time pen-tests undertaken annually or as part of a significant change to the information technology environment, automated pen-testing can be ongoing. A significant and exploitable vulnerability could be introduced into the environment at any time via patching, upgrading systems, or updates to custom-code. If a pen-test is only undertaken annually then there is risk that a vulnerability could be available for a significant period of time before its detected and exploited.
    2. Improved speed and coverage. Using computer-based automation dramatically increases the speed, coverage and type of pen-testing techniques that can be used. Where human pen-testers may only be able to focus on a small sample-set of systems and devices per engagement, automated tools can run multiple streams of tasks on the entire environment and do not rely on a single person’s skill set.
    3. Quick updates. Depending on the automated pen-testing vendor, the automated pen-testing system could be updated with the latest vulnerability data, attack vectors and exploit techniques hours/days after the detection and identification of the vulnerability is known the security community. However, with the traditional pen-testing engagement, it may take longer for pen-testers to develop the tools to exploit new vulnerabilities.

    Why Automated Penetration Testing Might Not Be a Silver Bullet

    Although automated pen-testing systems would be a very attractive proposition for a business over engaging human pen-testers, consideration of compliance requirements must be factored into the procurement process.

    For PCI DSS, Requirement 11.3 and its sub-requirements address pen-testing. An extract of Requirement 11.3 is provided below.

    11.3 Implement a methodology for penetration testing that includes the following:

      • Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
      • Includes coverage for the entire CDE perimeter and critical systems
      • Includes testing from both inside and outside the network
      • Includes testing to validate any segmentation and scope-reduction controls
      • Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
      • Defines network-layer penetration tests to include components that support network functions as well as operating systems
      • Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
      • Specifies retention of penetration testing results and remediation activities results

    Based on the publicly accessible information available for automated pen-testing tools reviewed at the time of this article’s published date, further research is required in the automated pen-testing tool’s ability to meet the requirement’s objective for application layer pen-testing (PCI DSS requirement 6.5).

    The objective of requirement 6.5 is to provide a minimum level of testing custom applications for security vulnerabilities. Requirement 6.5.1 through to requirement 6.5.10 cover the following vulnerabilities:

    1. 6.5.1 – Injection flaws such as SQL injection and command injection.
    2. 6.5.2 – Buffer overflows.
    3. 6.5.3 – Insecure cryptographic storage which addresses the use of insecure cryptographic ciphers, keys and algorithms.
    4. 6.5.4 – Insecure communications
    5. 6.5.5 – Improper error handling such as dumping out a stack trace to the end-user or providing too much information about the error to the end-user.
    6. 6.5.6 – Ensures that an organisation’s policy and procedures are updated and robust enough to identify all “high-risk” vulnerabilities.
    7. 6.5.7 – Cross-site scripting (XSS).
    8. 6.5.8 – Improper access control such as directory traversal and restricting access to functions.
    9. 6.5.9 – Cross-site request forgery (CSRF)
    10. 6.5.10 – Broken authentication and session management such as incorporating sensitive session variables in the session cookie.

    In regards to off-the-shelf software, the requirements above all sound doable for the automated pen-testing tool since there is an abundance of vulnerability sources publicly available for off-the-shelf applications such as web servers, blogs, office applications, CMS and CRM systems etc.

    However, consider an application that has been developed solely for an organisation. The automated pen-testing tool may identify a SQL injection vulnerability in the login page, but could the tool be smart enough to exploit this vulnerability to attempt further exploration within the application in order to identify and exploit more vulnerabilities? The SQL injection vulnerability on the login page may be identified and patched however, what other vulnerabilities still exist that were not identified via automated pen-testing?

    For example, if a skilled human pen-tester identified the SQL injection vulnerability within the login page the pen-tester could use a known users account name and bypass the login process using SQL injection technique, then locate the user’s current password and log into the server via SSH. Upon finding that the MySQL server root account has no password, the pen-tester logs into mySQL server as root and searches the database for valuable information. Further, based on the mySQL version the pen-tester uses a well-known function within the mySQL sever to gain root privileges to the server. As this example shows, the human pen-tester has gone from identifying a SQL injection vulnerability in a web-based login page to “owning” the entire server.

    It could be suggested that the whole example scenario above would be removed once the SQL injection vulnerability was located but there are many more ways to get a user’s password. The lax security for SSH access and mySQL running as root with no password on the root account stills remains to be exploited another way.

    Automated Pen-Testing & Application Layer Testing

    NIST Special Publication 800-115 “Technical Guide to Information Security Testing and Assessment” provides guidance on “application security testing”.

    Application security testing and examination help an organization determine whether its custom application software—for example, Web applications—contains vulnerabilities that can be exploited, and whether the software behaves and interacts securely with its users, other applications (such as databases), and its execution environment. Application security can be assessed in a number of ways, ranging from source code review to penetration testing of the implemented application.

    Custom application software provides challenges to pen-testers in that the application or components of the application are not known outside of the business and any third-party developers and testers engaged to develop and test the application. Whereas vulnerabilities detected within operating systems and off-the-shelf applications are shared publicly, and in doing so allow effective tools to exploit the vulnerabilities to be crafted and released, custom code applications almost always require a reasonable amount of time researching the functions provided by the application, testing possible attack vectors and applying a unique path of attack that may result in further vulnerabilities being detected.

    The cost of black-box pen-testing of custom applications is a constant discussion point with a business due to the pen-testers effectively testing “blind” which consumes more time and resources with a reasonable risk that not all vulnerabilities will be detected. In many cases white-box testing is more effective at detecting vulnerabilities in custom code since the source code is often provided to the pen-testers to locate vulnerabilities not easily detected at the applications interfaces.

    A good example of the lengths pen-testers have to go to when pen-testing custom applications is the following video of a pen-tester attempting to detect and exploit a vulnerability in a war-game application “Learning object serialization vulnerabilities – Natas 26 Walkthrough – Overthewire.org”

    [fusion_youtube id=”https://youtu.be/ILfPqpdTm0k” alignment=”center” autoplay=”false” api_params=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” css_id=”” /]

    When reflecting on the uniqueness of custom code applications where consideration such as software methodologies used, coding languages used, information disclosure within comments, logic path flows and manipulation of application-level data are researched and tested resulting in a custom attack vector that has been hand-crafted, it is difficult for the author to see how an automated pen-testing tool could obtain the same or better result than a human pen-tester. The automated pen-testing tool may allow for such attack vectors to be scripted and therefore automated. However, there is always the discussion point around who would be qualified and experienced enough in pen-testing to script the attack? The developers of the application or the in-house testers could be a possibility but it would be rare that a developer or application tester would also be skilled in pen-testing.

    Another possibility that the use of automated pen-testing tools could meet PCI DSS version 3.2.1 pen-testing requirements is a combination of automated pen-testing and human pen-testing. The automated pen-testing tool could be used frequently to detect and exploit attack vectors that can be scripted and repeated without requiring changes such as detecting unencrypted user account credentials, weak password policy, insecure protocols, daemons and services and exploiting known vulnerabilities in off-the-shelf applications. The benefit to the business would be reduced costs for pen-testing as less engagement of human pen-testers would be needed, faster detection of vulnerabilities and consistent testing and reporting. However, as shown in above, the automated pen-testing tool could identify a SQL injection vulnerability in a login page for example, but a skilled human pen-tester would use that exploit to explore the environment and more than likely identify more vulnerabilities. So, would the QSA consider the automated pen-testing tool a very sophisticated vulnerability scanner only?

    Pen-testing or Vulnerability Scanning

    For the QSA further guidance is provided in The Information Supplement: Penetration Testing Guidance version 1.1 which provides the following guidance in section 4.2.2 Network Layer. The author has highlighted in bold the most relevant part of the extract.

    Since most protocols are well defined and have standard modes of interaction, network-layer testing is more suitable for automated testing. This makes automation the first logical step in a network-layer test. Because of such standardization, tools may be used to quickly identify a service, the version of the software, test for common mis-configurations, and even identify vulnerabilities. Automated tests can be performed much faster than could be expected of a human. However, simply running an automated tool does not satisfy the penetration testing requirement. Automated tools cannot interpret vulnerabilities, misconfigurations, or even the services exposed to assess the true risk to the environment. The automated tool only serves as a baseline indication of the potential attack surface of the environment. The penetration tester must interpret the results of any automated tools and determine whether additional testing is needed.

    This version of the supplement was written in 2017 so consideration of automated pen-testing tools may not have been incorporated. However, section 2.1 “How does a penetration test differ from a vulnerability scan?” provides further guidance on what PCI DSS considers as implementing pen-testing. You can also read more about this in Confide’s PCI Basics article: Penetration Testing and Vulnerability Scanning, What’s the Difference? In fact, the guidance infers frequently through the document that pen-testing is a human executed process.

    Until further understanding of how automated pen-testing tools support the ability to apply complex and intelligent pen-testing techniques, and the PCI Security Standards Council provides guidance on the use of automated pen-testing tools, further discussion between your QSA or acquiring bank may be needed.

    zuno

  • Secure Your Terminals

    Secure Your Terminals

    Merchants with EFTPOS terminals have a set of requirements specific to card-present transaction security. That’s because card-skimming can happen anywhere, and it even happens in New Zealand! In this article, we want to help you understand how to protect the devices that your customers interact with to pay you.

    Know Your Devices

    PCI requires that you keep an inventory of all your devices that includes:

    • Manufacturer, make, and model
    • Physical location
    • Unique identifier (such as the serial number)

    This basic information helps you understand what should be in your environment and provides you with the foundation to be able to know when there is something that doesn’t belong.

    Secure Your Devices

    Once you know what devices are in your store(s), the next thing to do is to take steps to secure the devices. This can be done through physical security controls or monitoring. Some examples of ways you can secure your devices include:

    • Making sure it is difficult to swap or remove cables by enclosing them away from customers.
    • Physically or logically locking down any network ports that the device plugs into.
    • Monitoring for tampering via CCTV (be careful that you aren’t accidentally collecting card numbers or PINs on your video)
    • Regularly checking devices for tampering.

    Teach Your Staff

    Your sales staff are the most important part of making sure that terminals are secured. But they can’t do this unless they understand how to tell if terminals have been tampered with. A terminal can be replaced faster than you think!

    To understand if your devices have been tampered with, you need to understand what the device is expected to look like in its original state. This is where knowing about the types of devices you have becomes useful.

    For each type of device, document what the expected “good state” of the device should be and what steps need to be checked by the person doing the regular inspections of the device. Examples of things that people should check for may include:

    • Does it match the expected make, model, and serial number or other unique identifier?
    • Is anything loose?
    • Had anything been added that wasn’t there last time?
    • Are there any unexpected scratches or marks that might be indicative of tampering?

    It only takes seconds for someone to replace a device, but if your staff know what to look for and what to be aware of, this will help keep your devices secure.

    Regular training is important for everyone, especially people who interact with customers on a daily basis since they’re the most likely to come into contact with cardholder data.

    Understand how often staff change or leave roles to understand how often you need to do the training. Common things that training should cover include:

    • How to check devices.
    • What to do if someone wants to access the device (e.g. they ask to repair or replace it).
    • What kinds of suspicious behaviour to look for.
    • How to report anything that could be suspicious and who to report it to.
    • What to do with lost cards to keep them secure.

    How Often Should You Check Your Devices?

    This depends a lot on where they are. For example, if your devices are unattended, you might want to check them more frequently. However, if your devices are attended, you might want to make sure that your staff do a quick check at the start of any shift and a more detailed check at a lower frequency. Whatever you decide is right for your business, make it easy for staff to know what to look for and record what they have seen!

    More Information

    The PCI SSC publishes lots of resources for small businesses and retailers. Some of these documents include:

    Need More Help?

    If you’re a merchant doing PCI, Confide can help regardless of your transaction level. Contact us to find out more.

    zuno

  • PCI By the Numbers 2019

    PCI By the Numbers 2019

    Every year, Verizon publishes a report on PCI DSS and the key findings from the year. 2019 was no different.

    One of the most interesting findings of this report is how few organisations have a programme in place to measure the maturity of the PCI compliance program. Approximately 60% of organisations that were surveyed did not have a program to apply capability and maturity models to measure their PCI security program’s maturity.

    Other interesting numbers include:

    • Only 36.7% of organisations were actively maintaining PCI DSS programmes in 2018, a 20% decline from 2016.
    • Only 18% of organisations measure their PCI DSS controls more frequently than what PCI DSS requires.
    • No organisations were fully compliant at the time of a cardholder data breach. The biggest issues were with:
      • Requirement 3: Protection of cardholder data at rest
      • Requirement 8: Identification and authentication
      • Requirement 10: Logging and monitoring
      • Requirement 11: Security testing
      • Requirement 12: Security policy, governance, and service provider management
    • Approximately 35% of organisations suffered a compromise that involved a mobile device. Most of these compromises were major.

    One positive note to take away from this report is that organisations in the APAC region were regularly outperforming their global counterparts. However, the same findings were there, just in slightly lower numbers.

    Confide can help you understand gaps in your security process and to help measure the maturity of your PCI compliance programs. Contact us for more information.

    zuno

  • What is PCI DSS?

    What is PCI DSS?

    Overview

    The Payment Card Industry Data Security Standard (PCI DSS) is a set of twelve high-level requirements which all merchants and service providers who take card payments or who manage systems that are involved in transactions are required to follow.

    PCI DSS has high-level requirements and detailed testing requirements that need to be carried out in order to show compliance with the standard. This document covers the high-level requirements.

    The Twelve PCI DSS Requirements

    Requirement 1: As part of Requirement 1, you need to ensure that all of your firewalls are maintained and that they are configured to only allow the traffic which is required to sensitive parts of your network.

    Requirement 2: Requirement 2 focuses on how you ensure that your servers, firewalls, and other devices that are used in your environment are configured securely.

    Requirement 3: The focus in Requirement 3 is on protecting cardholder data. Cardholder data needs to be protected during all parts of the transaction process. This means that when it’s stored, it needs to be protected. Finding out locations of clear-text cardholder data through tools such as card-scanning can help you find cardholder data that you do not need and help you define your cardholder data environment.

    Requirement 4: Requirement 4 focuses on protecting cardholder data when it is being transmitted over the internet. This means that cardholder data needs to be protected when it’s sent from the customer, when it’s sent to the payment gateway, and if you’re using a cloud service, you should protect your internal data too since it might be going over out of your control without your knowledge.

    Requirement 5: Requirement 5 is all about anti-virus software and making sure it is configured securely. While not all systems can support anti-virus, we recommend installing it wherever it is supported.

    Requirement 6: Requirement 6 covers two areas: vulnerability management and secure development.

    Vulnerability management in Requirement 6 is about ensuring that you are regularly identifying threats to your systems, installing patches, and that all changes to systems are documented.

    Secure development in Requirement 6 is about ensuring that you follow good development practices, such as having a separation of duties, ensuring there are separate environments, and making sure that all code is developed securely and tested.

    Requirement 7: This requirement is all about managing the users who have access to your systems and making sure that people only have the minimum level of access they need to do their job.

    Requirement 8: Requirement 8 is about making sure that users are authenticating securely. This means enforcing strong passwords and using multi-factor authentication. It also looks at how people access your databases where cardholder data is stored.

    Requirement 9: Physical security is covered Requirement 9. This means making sure that any paper with cardholder data is stored securely and that anyone visiting sensitive areas is identified and approved for access. This requirement also covers the security of your data centres.

    Requirement 10: Requirement 10 focuses on the security logs and monitoring of your systems. Making sure that you have logs and are regularly reviewing them is vital to being able to proactively identify security incidents.

    Requirement 11: Requirement 11 focuses on more security testing, including doing regular scans to identify vulnerabilities and getting your systems tested by an organisation that specialises in penetration testing.

    Requirement 12: Finally, Requirement 12 covers the policy and governance side of PCI DSS. Along with policies it includes user education and service provider management to make sure that third parties aren’t affecting your PCI DSS and security.

    zuno