We are seeing a lot of trends where organisations are moving to the cloud. If you haven’t moved to the cloud, you’ve probably been asked about it by at least one person in your organisation. The biggest players that we see in the cloud space are:

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud (GCP)

We’ve seen most people have moved to either AWS or Azure, but we are starting to see people make more use of GCP as well. In this article we will try to be be cloud-agnostic. Whatever cloud-service you decide to investigate and/or use will each have it’s own services, solutions, and approach to compliance. Our focus here is on how you approach a cloud migration with PCI in mind no matter what stage you are at.

Before You Migrate

Just like any significant change, you need to take steps to understand what your risk is. The only way that you can understand your risk fully is to start by performing due diligence and understanding exactly where the potential may be for certain risks.

Do Your Due Diligence

When we talk about due diligence for a potential cloud move, there are lots of things that need to be considered. Some of these include:

• What compliance does the cloud provider have? Do they meet regulatory and contractual regimes that you have to comply with in all the countries you operate in?
• What rights do you have as a customer over controlling your data?
• Who has access to your data?
• What happens to your data when you delete it?
• Does the cloud service offer native versions of the security controls you need or will you need to implement additional security controls?
• What obligations do they have to notify you of a breach or potential breach?
• How easy (or difficult) is it to move platforms?
• What items would be your responsibility and which would be the cloud providers?

The list above is not meant to be exhaustive. What it should do is make you start thinking about what your potential risks might be that are associated with bringing another service provider into the scope of your PCI environment. If you don’t do your due diligence, you may find yourself in a situation where your cloud provider is not compliant and suddenly there is a significant increase in costs, probably not budgeted. While that’s extremely unlikely with one of the big three cloud providers, they are not the only providers out there.

Understand Your Risks

Once you’ve done your due diligence, you’re in a much better place to be able to understand your risks. Incomplete due diligence can lead to an inaccurate or incomplete understanding of the risks leaving you with gaps that you may not know about until it is too late.

As part of any significant change, you need to be doing a risk assessment. Migrating from a physical infrastructure to the cloud is considered a significant change to your environment. So significant, that it is the kind of change that will, once ready, be required to be re-assessed. We will talk about that later.

While your risks will differ based on your organisation and even your cloud provider, some risks will be common regardless. When identifying risks, ensure that you are including not only technical risks, but people and process risks as well.

• Those logs that you previously sent to your SIEM, where do those go now, and are they still in a format that you can review? Or will you need a different tool?
• The documentation you have that relates very clearly to your old systems, what happens if it doesn’t get re-written? How and who will rewrite it?
• What happens if your cloud provider stops offering their services?
• What happens if your cloud provider no longer provides PCI compliant services?
• What happens if auto-scaling isn’t configured properly and you get a spike of traffic leading to a similarly enormous bill?
• What happens if that old bespoke piece of software you’re using can’t be deployed in the cloud?

Once again, the list isn’t meant to be exhaustive. But you should be looking at the ways that changing to the cloud could add not only what new risks you might add, but how the cloud migration might change your current risks. It may be that migrating to the cloud removes the risk of a data centre that was not PCI compliant and therefore had to be included in your scope. It may be that using a cloud service they offer a log pre-processing service which suddenly makes it much easier to understand when an event is a threat, improving your ability to detect incidents.

When reviewing a migration to the cloud, you should absolutely look at ways that it may also decrease existing risks in your current risk assessment though additional controls that may not have otherwise been available to you.

Draft Your Architecture

Once you’ve done your due diligence and understood the potential risks, you’re probably in a place to make a decision about the cloud-solution that you will use and you can finally get to the part you wanted to get to all along. Playing with the shiny new toys that cloud services offer so that you can figure out which of those things you want (and need) to include in your new architecture.

When considering what your architecture might look like, it’s a good idea to run it by a QSA earlier rather than later so any key items for compliance which may have been forgotten or left out can be identified, saving you time later. Confide can perform architecture reviews to help customers ensure that their cloud migrations will meet their PCI requirements.

Make sure that when you are drafting your architecture design documents, you consider services that may be available from your cloud provider which are PaaS or SaaS offerings which may be able to decrease your overall compliance burden (as long as they are within the scope of your cloud provider’s Attestation of Compliance or AoC).

For example, Azure offers a Bastion Service that lets you implement a jump host with multi-factor authentication for all direct server access. Once you’ve configured it, you can use it with Azure AD and enforce multi-factor authentication. As it is PaaS (Platform as a Service), you do not have any access to the underlying operating system.

Compare this to setting up your own bastion host, being responsible for the patching, for application updates, internal and external vulnerability scans, penetration testing, server build and configuration standards, hardening, potentially antivirus software and server logging to list the key ones. The list goes on because a bastion host is a critical security control within your environment, providing access and segmentation to your environment.

While of course you could migrate your environment like for like, and recreate everything that currently exists in your data centre, you may find that some of the managed services can make PCI compliance easier. So make sure to consider these when designing what your new environment will look like.

Ready to Migrate? What Do Do During Your Migration

So, you’ve decided to migrate, you’ve had your architecture reviewed by a QSA, but that doesn’t mean that everything is ready to go and you’ll immediately be PCI compliant.

Document Everything

As you start building and deploying your environment, make sure that you are documenting everything. A move to a cloud environment is a significant change (remember Requirement 6.4.6), so you’ll need to make sure that you are documenting as you go. As you deploy the environment, remember to consider things like:

• Do I need to run a vulnerability scan?
• Do I need to organise a penetration test?
• What documentation do I need to create or update?
• What PCI requirements do I need to implement as part of the deployment?

By recording each of these things as part of the change and keeping the evidence with it, you make it even easier to show your QSA how you made sure that each change

As you add (and remove) users and roles to the solution, make sure that you are documenting this as part of your changes. Make sure you document their privileges and understand who should have access once the system goes live. You may find that a different team of people needed access to build the solution and that the team is much different or smaller for maintaining it. So as part of your process, make sure that you’ve only got the right people with the right access.

Test Early, Test Often, Test When You’re Done

You’re always remembering to test things as you implement them, right? No, not just that they work, but that they are secure.

One of the things that you need to do for PCI is to make sure that you do vulnerability scans and penetration tests as part of your significant change. Not every change will require a penetration test, nor will every change require a vulnerability scan. But any time there is a change to networking, your first step should be to run a vulnerability scan (internal or external depending on what type of networking change). Do these scans as often as you need to, and re-scan until any vulnerabilities have been fixed. Keep the results with the change ticket.

You might decide to do penetration testing at different points in your deployment. Great! Just make sure that you book in a final penetration test once you’re ready to go live. You want to make sure that you’re testing the environment in as close a state as possible to what you will actually be using.

Double Check Your Solution

Before getting a QSA in to do the assessment of your new environment, we recommend doing some internal spot checks of your environment against key requirements to make sure you have addressed everything. This includes checking that your documentation has been updated and reflects the new environment, as well as making sure the environment is production ready. This will save you from too many surprises during the assessment.

If possible, build spot checks in early and include them as part of your key milestones. It’s much easier to check things piece by piece rather than all at once, but it’s better to do it once than not at all. It will also help you understand how you will need to explain your implementation of the solution when you are talking about it with your QSA.

Done and Deployed? What To Do After Your Migration

That’s it, you’re done, right? Not quite.

Document Your Decommissioning

Before your assessment, you will want to finalise your decommissioning of your old environment. If your old environment hasn’t been decommissioned, it will have to be included in your scope until it is.

Decommissioning, much like adding new systems is a significant change. You need to make sure they are removed from your security tools, make sure their firewall rules are removed, remove them from your inventory and your diagrams. There’s still a few things that need to be done and documented before you are ready for your assessment.

Review Your Documentation (One More Time!)

Make sure that all of your change tickets are easily identifiable and contain the information that they need to. Make sure that all of your diagrams have been updated to reflect your new environment. Basically, just do a once over to make sure you are in a place where you are ready to be re-assessed.

Schedule Your Re-Assessment

We know that figuring out exactly when you will be done is difficult. There are bumps along the way and nothing ever goes as planned. So figuring out when to schedule your re-assessment is key. Your systems should be production ready. This means that everything has been deployed, everything has been tested, and the only thing left to do is to make sure that it is PCI compliant.

If you assess too early, you run the risk of an extended assessment while we wait for your systems to be production ready. If you assess too late, you run the risk of a security breach due to an incorrectly configured security control. The important thing is to keep your QSA in the loop. Engage with them early, and take steps to keep them up to date as key milestones are achieved. This gives you the assurance you need that your QSA will be able to advise you on when you are ready for your assessment and you can worry less about not being able to fit into the schedule once you’re ready.

How Can Confide Help

Confide understands that a cloud migration is a process and PCI is just one part of it. We’re here for you throughout your PCI journey whatever part of it you’re at. Confide has staff who specialise in cloud security who can advise you and assess your environment. Contact us to find out how we can help you take advantage of cloud offerings.

New Zealand is starting a period where lots of people are going to be working from home because of COVID-19. For some of us, it’s temporary; for others it may be (or become) a normal way of working. With this massive shift in how we are having to work for a period of time, we at Confide thought it would be good to offer some advice on how to stay secure and still maintain the Payment Card Industry (PCI) Data Security Specification (DSS) compliance.

PCI DSS is probably the last thing on your mind. But let’s start with some things that you can do to keep yourself secure at home.

• Always remember to lock your computer. [Windows: Control-Alt-Delete   MacOS: Control-Command-Q] This isn’t because you think your family will do something with your data; it’s to make sure that someone doesn’t accidentally do something they shouldn’t, like delete something critical.
• Make sure that you enable multi-factor authentication anywhere it isn’t already enabled. And if it’s a cloud service managed by your company (GitHub, Jira, etc.) and you can’t enable it yourself because of how it’s configured, ask your IT team to enable it.
• Make sure you have a strong password on your home’s wireless network and that the software on your wireless devices (including your ISP’s router) is up to date (if you can update it). Make sure you update the admin password on it too.
• Make sure you continue to patch your computer and keep key things running like antivirus and firewalls. Just because you’re at home, doesn’t mean that your computer is more secure.
• Keep your laptop to work use only. This is for both helping you draw a line between your work and home life when you’re working from home and to keep your computer secure by not installing other things on it.
• Before you start using your own computer to work remotely, check with your organisation to find out about their BYOD policy and if you need to add things like antivirus software or firewalls before you connect to the network.
• If you’re using your own device, make sure it has a strong password!
• Encrypt your local hard drive and your backups (and make sure you keep doing your backups!)
• Consider what else is on your network. If you have the ability to set up a separate network for VLAN for your work, do that. Keep your IOT devices and cameras separate (and patched).

While not a security issue, also check the speed of your broadband connection. You might be on a cheaper plan with low speed e.g. fibre running at 100 Megabits, when you could be running at a higher speed e.g. One Gigabit or higher.   Check here: https://broadbandmap.nz/home If there are a couple of you working out of the same home, the increased speed will be very useful. Almost all ISPs in New Zealand have lifted their data caps until further notice.

So with some basics covered, we move on to steps that organisations can take to minimise risk with such a significant change in how people are working.

• You’re probably already using multi-factor authentication for your remote access since it’s been part of PCI DSS requirements for years, so this one shouldn’t be hard. What may be hard is making sure that all the new people who may have to have remote access are using multi-factor authentication. We know this may mean you need more licenses or you may have to ask staff to use their personal devices for authentication. But it’s important for your compliance to ensure that everyone has multi-factor authentication in place for remote access.
• Making systems available remotely can also offer some challenges. Say you normally lock down access to your internal systems by IP address so that only certain people can access it. Suddenly you’re having to allow for dozens, hundreds, or thousands more people requiring access. So however you decide to do things, whether that’s whitelisting a lot more IP addresses or removing IP address restrictions altogether, you need to make sure your changes are documented and go through proper change control.
• Sure, you’ve probably had to make some emergency changes because of how quickly the work from home mandate was put in place nationally. But make sure that these changes get documented as soon as possible. Don’t wait for weeks to complete the documentation.
• You may have to make some other significant changes. Maybe you need to add a new jump box to let more people access the environment, maybe you need to change some firewall rules to make access less restrictive. Make sure that you’re reviewing the impact of that significant change for PCI DSS. When things are back to normal, one of the things that we look for as Qualified Security Assessors (QSA) is evidence of how you have managed and documented your significant changes and how you’ve considered your risks.
• With all these potential changes going on, make sure you’re running vulnerability scans (internal and external). It should give you an idea if any of the changes are opening up new vulnerabilities in your environment. And if your change is particularly significant, make sure you’re reaching out to a penetration testing company who should be able to conduct testing remotely.
• Review your change control processes to make sure that you can still follow them even if people are working remotely. If your system is highly restricted, you may have to consider how you deal with this if the people who need it can’t access it remotely.
• If you are fully shutting down, treat this just like you might the Christmas black out or brown out period. Take the same steps and same precautions.
• Consider how you roll out some additional training for your staff remotely. Not only will this make it easier to ensure that you can train staff as and when needed (when they first join and annually thereafter), you might find that this opens up new opportunities for staff to complete their training when they have time rather than everyone attending a single session.
• Remember to make sure that people are still on call for monitoring for security breaches. If you rely on people generally being in the office to be able to respond to things, your response processes might need to change. You may need to create a more formal roster to make sure that someone is monitoring for incidents. You may need to make a more formal process for recording and responding to incidents so that people know who responded and what was done.
• Document everything. Document what you’ve done, how you’ve addressed the risk. We know that there will be things that you have to do to get things set up to keep operating in this situation.
• If your staff are using BYOD, make sure they have antivirus software installed! A few more licenses is better than the risk of malware infecting your environment.

We know that things are hard at the moment. But maybe you’ll find some new opportunities over the next few weeks to improve the way you do things and become more secure in the process.

There are other great articles out there on how to secure your organisation and your workers.

• PCI Guru: Work from Home Considerations
• NIST: Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• PCI SSC: Protecting Payments While Working Remotely

Stay safe and be kind everyone. PCI DSS compliance isn’t the end of the world and neither is the COVID-19 outbreak.

Confide is available to answer your questions about PCI DSS and how remote working could affect your compliance during the current situation and once things are back to normal.

In addition to being a Qualified Security Assessment Company (QSAC) under the PCI Security Standards Council, Confide is also an active corporate member of the New Zealand Internet Task Force (NZITF), whose mission is to improve Information Security standards in New Zealand.

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.

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.