Book a discovery call

  • Do Good Deeds and Take Donations Securely

    Do Good Deeds and Take Donations Securely

    If you’re a charity, you may never have thought that you might need PCI compliance and why it
    might matter to your donors.

    The Fred Hollows Foundation has worked hard to reach, and maintain on an annual basis, PCI
    compliance and has found clear benefits to their organisation, including:

    • Stronger foundation for the organisation’s overall cybersecurity
    • Improved staff attitudes to IT security

    While they initially found PCI to be a complex topic, working together with Confide they’ve
    developed a strong focus on compliance and security.

    Read more at ResellerNews: Fred Hollows NZ charts the complexities of payment card
    compliance.

    More Resources for Charities

    If you’re a charity, you may be interested in our other articles about how to secure your payment
    channels. Read more about the payment channels you use in the articles below.

    Secure
    Phone Donations

    Read
    More

    Secure
    Mail Donations

    Read
    More

    Secure
    Onlinr Donations

    Read
    More

    Are You a Charity that Needs to be PCI Compliant?

    If you’re a charity or non-profit, we offer special packages to help you secure your donors’
    information. Read more about our Charities Packages and talk to us to see how we can help you.

    Helena Kuwabara

  • Protecting Payments Over the Phone

    Protecting Payments Over the Phone

    It’s not uncommon to take payments by phone. Whether you’re a small business, a charity, or a
    large retailer; there may be situations where your customers need to make a payment over the
    phone. However, if you are taking payments by phone, there are a few things that you need to
    keep in mind to make sure that you take payments in a secure and PCI compliant manner.

    Understand Your Processes

    Even if you don’t need to have a cardholder data flow diagram as part of your PCI
    requirements, we recommend making sure that you keep diagrams for all of your card flows.
    This makes it easier for you to understand exactly where credit and debit card numbers may be
    in your processes and systems, and to understand any areas of risk that need to be protected.

    Protect the Call

    Once you’ve decided that you’re going to take payments over the phone, the first thing to do is
    to understand what this might mean for your PCI scope.

    If you’re using VoIP, it’s very likely that this system will be in-scope. That means that you need
    to make sure that all the phones and servers are managed a PCI compliant way. Now, you
    might not want to have to apply your PCI controls to every single phone system in the office.
    You could have two different VoIP systems, or you could take other steps to limit the scope.

    And if you’re using soft phones (software running on your computer), make sure you’re
    considering these too since they are also likely to affect your PCI scope.

    Even if you’re redirecting calls temporarily off to a cell phone, you should make sure that it is
    fully patched, has a passcode on it, and is configured to encrypt the data.

    Protect the Recordings

    It’s not unusual to have calls recorded for quality and training purposes.

    If You Don’t Need It, Don’t Store It

    One of the first things to keep in mind is whether you can prevent any call recordings that have
    credit card data in them from being stored. This could include:

    • Training staff to pause recordings when customers are providing their payment details
    • Having an automatic pause on call recording when your staff taking the payment
      information goes to the payment page.
    • Have a process to redirect your customer to a PCI compliant solution for them to enter
      their payment information via an IVR or similar (but if you do a redirect, make sure you’ve
      secured it).

    In general, these things don’t tend to be 100% fool proof, so always make sure you are doing
    spot checks to identify any accidentally stored cardholder data (and hopefully find ways to
    improve your processes).

    Limit Access & Encrypt Recordings

    As another layer of protection, you should always make sure that your recordings are protected.
    Use the built in features of the call recording program, or the features of your operating system /
    identity management system.

    Make sure to limit playback and downloads of calls. And if you can, configure the system to
    encrypt any storage of calls. This way, even if you do end up accidentally storing cardholder
    data, you have already taken steps to protect it.

    Protect the Payment

    Make sure that your staff are entering payments directly into a PCI compliant form (maybe even
    one hosted by a payment gateway) or into a validated Payment Application. Making sure that
    the transaction is secure at all times is vital.

    Train Your People

    Whether it’s one person or one hundred people who are taking payments over the phone, the
    most important step you can take is to make sure that people are trained to know understand
    not only how they can protect cardholder data, but also how they can be secure. Good people
    are the best first-line defence to protect your payments.

    Staff should be trained in both basic security and in how to protect payment information if they
    are dealing with it. For example, this might include:

    • Making sure that you don’t write card numbers down
    • If you do have to write them down, making sure they are securely disposed of immediately
    • Making sure that staff know that they should never type card numbers into parts of a form
      that aren’t meant for it (for example, a comments field or similar)

    In Summary…

    • Make sure you consider how you are protecting your VoIP systems and any soft phones.
      These will likely be part of your PCI compliance environment since you would transmit
      cardholder data across them.
    • Make sure you protect any call recordings.
      • Try not to store card data in call recordings
      • Do spot checks to make sure you aren’t storing cards
      • Use access controls and encryption to minimise any residual risk.
    • Only enter payments into a PCI compliant payment form or IVR.
    • Train your staff to make sure they understand how to take payments securely over the
      phone.

    Need Help?

    Confide can help you with your PCI compliance and making sure that you’re taking payments in
    a PCI compliant manner. Talk to us to see how we can help you.

    Helena Kuwabara

  • Why Should I Become a PCI Compliant Service Provider?

    Why Should I Become a PCI Compliant Service Provider?

    One of the most common misperceptions about PCI DSS is that only merchants who directly accept payments need to be PCI DSS compliant. In fact, if any of your customers require PCI compliance, you might also need to become PCI compliant or be included in your customers’ assessments.

    Any service provider that has the ability to affect the security of their customers cardholder data or that stores, processes, or transmits cardholder data on behalf of their customers needs to be able to show that the service is being provided in a PCI compliant manner. In this post, we focus on service provider’s validating their PCI compliance independent of their customers.

    Why should I become PCI compliant if I don’t take credit card payments?

    There are plenty of reasons to consider becoming PCI compliant. Some of them will be unique to your business, some of them are common reasons for most service providers. For example:

    • If you have multiple customers who need you to be PCI compliant, doing your own compliance once will save you time rather than being involved in multiple customer assessments.
    • There are only a small number of PCI compliant service providers in NZ, which means that if a customer is looking for a compliant service provider, you may be able to get more business.  You may also be able to charge more for this service – maybe just to recover any additional costs you have incurred or incur to provide PCI compliance or to differentiate the services being offered or provided.
    • You will be able to show your current and potential customers that you have a clear focus on security that has been independently assessed and validated against a global industry standard.
    • If you decide to list on the global service provider lists maintained by the card brands (e.g. Visa and MasterCard) you may also find customers in new markets that you hadn’t previously considered.

    And of course, there may be reasons outside your control that have led you to look at PCI compliance, such as:

    • Being required as part of your customer contracts.
    • Being required to be compliant and assess as a service provider by your acquiring bank.

    If any of those reasons resonate with you, then it’s time to start thinking about the next question: How do I become a PCI compliant service provider?

    Helena Kuwabara

  • Penetration Testing and Vulnerability Scanning, What’s the Difference?

    Penetration Testing and Vulnerability Scanning, What’s the Difference?

    Two of the terms that frequently get misused (and often are interchanged) are vulnerability scanning and penetration testing. These two items are different and meet different parts of the PCI requirement. In fact, these terms get confused so often that the PCI SSC even published information on the differences between them.

    In this article we break down the differences between vulnerability scanning and penetration testing.

    The PCI SSC published an information supplement on penetration testing in 2017. In it, they summarised the key differences between vulnerability scans and penetration tests which is summarised below.

    Vulnerability Scans

    Vulnerability scans are required to be performed at least quarterly. External vulnerabilities scans must be performed using an ASV. Internal vulnerability scans do not have to be performed by an ASV, but many ASVs offer these services.

    Vulnerability scans need to be carried out at least quarterly to meet PCI requirements, but we recommend monthly so that you have time to fix any findings and still get a passing scan during the quarter.

    Vulnerability scans are a primarily automated process. Although someone is required to schedule, configure, and run the scans the work behind the scenes is done by your vulnerability scanning vendor.

    Penetration Testing

    Penetration testing is a primarily manual process. Vulnerability scanning may be used as an initial step in the penetration testing process, but penetration generally depends on a person taking information about vulnerabilities and trying to exploit them to see how they can bypass security controls. The testing may chain together different types of attacks and different vulnerabilities to reach their goal over time.

    While vulnerability scanning primarily focuses on whether a vulnerability might exist, penetration testing goes one step further and tests to see if and how that vulnerability can be exploited.

    Need Help with Vulnerability Scanning?

    If you need help with your vulnerability scanning, Confide has experts who are qualified and certified in using vulnerability scanning tools. Read more about our Managed Vulnerability Scanning Service or contact us to find out more.

    zuno

  • Moving to the Cloud and Staying PCI Compliant

    Moving to the Cloud and Staying PCI Compliant

    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.

    zuno

  • Suddenly Working from Home?

    Suddenly Working from Home?

    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.

    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.

    zuno

  • What Are My Reporting Requirements?

    What Are My Reporting Requirements?

    Caveat: This isn’t a post about which Self-Assessment Questionnaire SAQ you should use. You can confirm that by speaking with your acquiring bank. Confide can assist in these conversations and give our opinion on what SAQ we believe is correct, but your acquiring bank will make the final decision.

    There are a lot of acronyms that get used in relation to payments: RoC, AoC, SAQ, P2PE, PTS, PA-DSS and of course PCI DSS.

    This article focuses on distinguishing some of the different types of reports that are used to demonstrate PCI compliance.

    What Determines What Report I Can Use?

    Short Answer: The bank.

    Longer Answer: The bank will review the number of transactions that you do each year and the payment channels that you support. They may also review whether they consider you as a service provider or whether you fit the definition of a payment aggregator or facilitator. Based on this, they may direct you to a QSA to review your payment channels and provide advice or they may already have an expectation around what reporting you need to provide.

    Transaction Volumes

    Let’s start with transaction volume, since that is one of the first things which will help determine whether you can self-assess or whether you need a full Report on Compliance (RoC). Merchants and service providers have different thresholds for the number of transactions which will require a particular report type.

    Merchant Transaction Volume

    [table id=1 /]

    Service Provider Transaction Volumes

    [table id=2 /]

    It is worth noting though that even if you do not meet the transaction volume for a Report on Compliance, the bank, the card brands, or even your customers might require it.

    Self-Assessment Questionnaires (SAQ)

    As of 2020, PCI has nine different SAQs that apply to different payment channels, methods of transactions, and type of entity (merchant or service provider). These are summarised below.

    [table id=3 /]

    Each SAQ has a set of criteria to use it. You have to be able to attest that you meet all of the criteria in order to use that particular SAQ. Every SAQ other than SAQ D requires you to attest that you do not store any cardholder data. One way to prove this is to use a data discovery tool to find unprotected credit cards.

    The only SAQ that service providers are allowed to use if they do not meet the threshold for a full Report on Compliance is SAQ D for Service Providers. If a service provider gives you an AoC using any other SAQ, they have not assessed as a service provider.

    Merchants are able to use any of the other eight SAQs depending on the payment channels. When there are multiple payment channels, the bank may ask you to submit SAQ D to cover all your payment channels or they may accept multiple SAQs. Every SAQ other than SAQ D requires to attest that the payment channel described is your only payment channel. Because of this, SAQ D is usually the most appropriate. You should always check with your bank if you have multiple payment channels.

    The self-assessment questionnaires (SAQs) are a shortened version of the full standard reduced to the minimum controls that must be in place for that payment channel. However, just because the other requirements are not included in the SAQ does not mean that they do not have to be met. A key takeaway from PCI is that every requirement must be met by at least one party. The SAQs themselves require you to attest that each of the service providers who are involved in your transaction processes are PCI compliant. If you cannot attest to this, you generally won’t be able to use the SAQ because there will be gaps in the requirements that have not been assessed.

    There is no difference between the requirements in the SAQs and the requirements in the RoC. Only the reporting format differs.

    You may be able to complete a SAQ yourself, or you may need assistance with it. Confide can help you understand the requirements and complete your SAQ regardless of your size. Sometimes you may be able to use a SAQ, but your stakeholders want some independence and assurance around the controls that they are signing off as complying with, and a QSA can provide that independent assurance through our SAQ assistance.

    Report on Compliance

    The Report on Compliance (RoC) template starts at 191 pages in v3.2.1 of the Standard. As mentioned before, the requirements themselves are the same. The main difference in the level of detail in the reporting. Each requirement in the RoC asks for verification of how the control was validated to be in place through a combination of interviews, configuration reviews, document reviews, and observations.

    A RoC usually takes much longer to complete than a SAQ because of the amount of detail it requires. Even if you only are required to complete a SAQ, we recommend reviewing the ROC Reporting Template available from the PCI website to understand what kinds of information you should be asking about when you review your SAQ.

    A RoC can only be completed by a QSA. Confide has extensive experience in completing RoCs in New Zealand, and if you need a RoC, contact us.

    Supplemental Report on Compliance / Designated Entities Supplemental Validation

    Appendix A3 sets out additional controls which may be required by a payment brand or an acquirer to provide additional validation and assurance that PCI DSS requirements and processes are maintained effectively and continuously. You only have to complete this appendix if it is requested by the payment brand(s) or banks.

    The S-RoC / DESV is an additional 20 controls that build on the existing reporting in the RoC.

    Attestation of Compliance

    Regardless of what reporting requirements you have, part of those requirements will also include your Attestation of Compliance (AoC). The AoC summarises the findings in your SAQ or RoC and has a set of statements that your executive is required to attest to. If you have worked with a QSA on it, your QSA will also sign the AoC.

    Need More Help?

    If you need more help with your compliance, Confide can assist you at all the stages from scoping and PCI gap analysis through to completing a full independent assessment. Contact us for more information.

    zuno

  • What’s My Risk?

    What’s My Risk?

    PCI DSS requires you to regularly understand and review the risks that are applicable to your environment. There area number of different ways that you can understand and document your risks, including OCTAVE, ISO 27005, and NIST SP 800-30. This article explains one way that you can approach understanding and documenting your risks, but you should make sure that the method you use fits your organisation and is useful.

    Risk assessments may need to be carried out at different levels because a business risk assessment is likely to be very different from a technical risk assessment. PCI risks cover both organisational and technical risks.

    When Do You Have to Do A Risk Assessment?

    Requirement 12.2 requires that you complete a risk assessment :

    • At least annually, and
    • Upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)

    Other examples of significant changes that might require a risk assessment could include significant changes to your architecture (for example, migrating to the cloud) or adding new payment channels.

    Risk assessments are just one part of significant changes.

    How Do You Perform a Risk Assessment?

    Step 1: Define Your Process

    Our example here uses a modified approach based on NIST SP 800-30. You might have a different process. This is just one example of how you might conduct a risk assessment and the steps you might follow. Remember, whatever process you follow, you need to have the process and the outcome documented for your organisation.

    1. Identify and document your critical assets, including people, technology and data.
    2. Identify and document threat sources, including both internal and external threats.
    3. Identify and document the vulnerabilities in your environment related to the people, processes, technology, and data.
    4. Determine and document the likelihood of the event occurring. This could be based on the frequency of the event occurring or based on the likelihood of it occurring during a set timeframe.
    5. Determine and document the impact if the risk occurs. This could be the financial impact, the impact to compliance, or another impact that applies to your organisational goals.
    6. Determine and document the controls that apply to each of the risks and how they can mitigate the risk.
    7. Determine and document the resulting residual risk after the controls have been applied.
    8. Assign the risk owners.

    Step 2: Conduct the Risk Assessment

    If you feel like you’re at a loss for how to start your risk assessment, NIST SP 800-30 provides a great starting point in Appendices  D through I for risks that should be considered. Do you have to consider all of the? Absolutely not! You should be focusing on the threats and vulnerabilities that apply to your environment and the risks that your organisation actually faces. Follow your process and start documenting the risks that apply to your business.

    There are a few specific risks that we would recommend considering as part of your risk assessment.

    Risk of Non-Compliance

    It seems obvious that there is a business risk if you are unable to demonstrate compliance with PCI DSS. In most cases, you have a contractual obligation to your bank to be PCI compliant. The result of non-compliance could include revoking your ability to process card transactions, extended remediation times and costs, and even fines imposed by the card brands. But understanding the results of non-compliance does not help address the root cause. Non-compliance could be caused by a lot of different things, including staff turnover, hardware or software going end of life or becoming non-supported, or missing standard BAU processes required by PCI, the non-compliance of service providers. While it’s useful to understand the result of non-compliance, addressing the potential causes is vital.

    Logging and Monitoring

    As part of the logging and monitoring requirements, you need to be considering how often you review logs that are not part of your daily log review. While some logs have to be reviewed daily, other logs can be reviewed less frequently. But these logs and the frequency of the reviews need to be considered as part of your risk assessment.

    Other Areas to Consider

    Other areas to consider for your PCI risk assessment might also include:

    • Review of cryptographic algorithms and ciphers used to protect cardholder data to ensure they are considered strong.
    • Review of insecure services and protocols used in the cardholder data environment.
    • How frequently to conduct device inspections for card-present / retail staff.

    Step 3: Assign Risk Owners

    If nobody is responsible for managing your risks, you add a new risk that nothing will happen to address them. To manage risk effectively, someone needs to take responsibility for each. Not every risk can be mitigated, but every risk needs to have an owner.

    Step 4: Track Your Risk Over Time

    If you want to effectively understand how your risks are changing and how effective you are at managing your risks, you need to track your risks over time. This gives you a better understanding of what risks are increasing and which are decreasing and helps allocate your resources better. For example, you might have a very low risk of systems being unsupported right after you purchase them, but the risk of them being unsupported increases over time.

    Need Help with Your Risk Assessment?

    If you need help conducting your risk assessment or need an independent view on what your risks might be, contact us and find out how Confide can help.

    zuno

  • That’s Not My Responsibility (or Why You Need a Responsibility Matrix)

    That’s Not My Responsibility (or Why You Need a Responsibility Matrix)

    One of the worst things you can hear during your PCI assessment (aside from maybe finding out about unprotected cardholder data) is your service provider saying “That’s not my responsibility”. Suddenly, you find yourself pushing your service provider to do things differently, facing unforeseen costs, and facing a potentially long remediation period.

    Having a responsibility matrix isn’t a silver bullet to avoiding this sort of thing happening, but it’s a good starting point and service providers are often a vital part of your PCI. So it’s important that both you and your service providers understand what their responsibilities are.

    One of the key things to understand from PCI DSS is that every requirement must be met by at least one party. SAQs only show some of the requirements because as part of the SAQ you are attesting that you meet all the requirements for having third parties that look after the requirements that have been excluded.

    In this article, we use the term responsibility matrix, but you may also hear it referred to as a RACI matrix or by another term. What’s important is that you understand how your PCI DSS requirements and service providers fit together.

    Why Does PCI Care?

    Regardless of what type of assessment you are doing, every self-assessment questionnaire (SAQ) and report on compliance (RoC) requires you to have a programme for managing your service providers. Specifically:

    Requirement 12.8.1: Maintain a list of service providers including a description of the service provided.

    Requirement 12.8.5: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

    PCI cares about service provider management because so many organisations use service providers, and so many of these service providers could affect the security of the cardholder data environment. Almost everyone has heard of the Target breach where credentials were stolen from a third-party service provider and used to attack the system, but in New Zealand, the government is cracking down on web hosting providers for government sites because of the risk, and third parties have been responsible for other recent data breaches in New Zealand. Service providers not only have access to your sensitive data, but many customers sensitive data making them a prime target. Even if it’s your service provider that is ultimately responsible for the breach, the reputation damage is usually not just limited to them. So it’s important to pick service providers who can demonstrate a commitment to security.

    Shared Versus Sole Responsibility

    PCI has over 250 individual requirements, so understanding who is responsible for each of them is vital. There are a few different ways that responsibilities can be separated:

    • Sole responsibility of your organisation (whether you are a merchant or service provider).
    • Sole responsibility of your service provider.
    • Shared responsibility between you and your service provider where you are individually responsible for different parts of the requirement.
    • Responsibility of both you and your service provider where you are both responsible for meeting the requirement.

    Sole Responsibility: An Example

    One example of a sole responsibility for you as a service provider might be your responsibility for creating a cryptographic architecture (Requirement 3.5.1) for the protection of your keys. Even if you are using a cloud service, the underlying architecture, design, and management of the keys as well as the documentation is your sole responsibility as the cloud service provider would not have any insight into how you have configured your cryptographic processes.

    An example of a sole responsibility for a cloud service provider may be ensuring that anti-spoofing is configured for network connections (Req. 1.3.3) and that there is no way for the customer to change or disable this.

    Shared Responsibility: An Example

    Consider the example of a hosting provider where there is a shared responsibility for change management. The customer is responsible for submitting the change and ensuring that it has appropriate approval within the organisation and documenting the impact, while the service provider is responsible for verifying that the change came from the expected organisation, that the change has been tested, and the change has been implemented. In this situation, both parties have responsibilities under the same requirement, but not for the same parts of the requirement.

    Responsibilities of Both Parties: An Example

    Regardless of the service you provide, there is almost always going to be a requirement to ensure that general security awareness training (Req. 12.6) is carried out. And in many cases, there will also be a responsibility by both parties to ensure that personnel are screened and background checks are carried out (Req. 12.7). Both the customer and the organisation would need to ensure that their personnel meet these requirements, and it is unlikely (though not impossible) that both organisations would need to carry these tasks out individually.

    How Do You Figure Out Who is Responsible?

    This part of the process can be very easy or potentially difficult.

    Check the Attestation of Compliance (AoC)

    If your service provider has an Attestation of Compliance (or AoC), check the AoC to verify what requirements have been excluded from their testing. They will usually tell you if something has been excluded from their service and if it is the sole responsibility of their customers.

    Sometimes things you might expect to be covered are not. We often see that data centres do not conduct rogue wireless scanning (Req. 11.1) on behalf of their customers. This means that in order to meet this requirement, the customer must have processes in place to check for rogue access points at least quarterly.

    If the service is not covered in the AoC, you will need to do more work.

    What if there Isn’t an Attestation of Compliance?

    If there isn’t an attestation of compliance, and your service provider is non-compliant, then you need to work with your service provider to understand:

    • Exactly what services they provide for you.
    • Which PCI requirements are the responsibilities of each party.

    In a perfect world, you would go through each of the requirements to understand which requirements (and sub-requirements) are the responsibilities of each party. But start at the high level of the 12 primary requirements. Understand which requirements might be applicable to each provider, and then within those start looking at the detail. It can be a long process, but once you have this documented your assessment will be smoother and you and your service providers will have a better understanding of who is responsible for what.

    What Next?

    Eventually you will need to get to a point in the process where you have documented who is responsible for each of the requirements (your responsibility matrix).

    The next step is to have a process for getting a written agreement with your service providers including their acknowledgement of their responsibilities. This might be as part of your contract, or it might be a separate acknowledgement on behalf of the customer. The form and wording of the agreement isn’t mandated as part of PCI, so it will depend on what is right for you and your service providers. The important thing is that they understand what they are agreeing to.

    It’s not necessarily a short or easy process, but it will pay off in the long run when you avoid running into situations where someone says “That’s not my responsibility!”

    Need More Help?

    Confide can help you map your service providers and understand how they affect the scope of your PCI DSS. Contact us for more information.

    zuno