Archive for the 'service provider' Category

31
Mar
20

Surprise! PCI Largely Ignores Disaster Recovery

As a lot of people are finding out when they rolled out work from home (WFH) for COVID-19, it turned out that compliance with the PCI DSS was not in place and in some cases, not even possible.  If the PCI Dream Team session last week is any example, I think a lot of QSAs got calls and emails from their clients asking what the Hell had happened?

What we are all experiencing is a shortcoming of the PCI DSS and a point that has been discussed off and on since it came into existence.  The problem is that the PCI DSS does not worry about business continuity (BCP) or disaster recovery (DR) unless there is cardholder data (CHD) or sensitive authentication data (SAD) involved which typically only occurs when that data exists at hot/warm recovery sites.  If the CHD/SAD is only there when recovery is occurring, then those locations are out of scope.

Unfortunately, the COVID-19 event is not your normal “disaster”.  With the invocation of WFH, production data centers and offices were still fully operational which is typically the concern of BCP/DR.  What changed was that the government enacted stay at home or shelter in place orders and the recovery site became an employee’s home, not your expected recovery location.  Worse, since WFH would not involve CHD/SAD until it was invoked, QSAs had no reason to assess any plans for such recovery because they were not in-scope until activated.

That said, a lot of QSAs (myself included) usually did have a discussion with clients that, while their BCP/DR plans were not in-scope, clients should occasionally assess those plans to make sure that, when invoked, the plan maintained PCI compliance.  Because when the BCP/DR was invoked, whatever was done had to be PCI compliant the moment it was used.

And there is the rub in all of this.  There is no grace period with PCI compliance because of the invocation of BCP/DR.  You are expected to be 100% PCI compliant regardless.

There are a number of lessons learned due to the COVID-19 disaster.

  • BCP/DR will need to be updated for pandemic incidents including WFH capabilities. According to the World Health Organization (WHO) and the Centers for Disease Control (CDC), pandemics are not going to go away, so the ability to continue operations remotely is going to have to be part of an organization’s recovery options.
  • WFH capabilities will have to be incorporated into normal production capabilities. This effort will need to address PCI compliance as well as HIPAA, CCPA, GDPR and any other relevant security and privacy programs your organization may have to comply with.  I have had a number of organizations enact such capabilities, policies and procedures for various parts of their operations over the years due to changing work requirements of their personnel as WFH offers a number of flexible advantages for retaining employees.
  • Implement virtual desktop infrastructure (VDI) to provide office as well as remote working capabilities. This can also potentially allow WFH to use an employee’s BYOD as long as they are not required to be PCI compliant.  Use of VDI allows the use of thin clients and Chromebooks to be used as workstations making security of those workstations a bit easier as well as reducing the cost.
  • Implement P2PE or end-to-end encryption (E2EE) solutions for the entry of CHD/SAD into applications. There are a number of USB and Bluetooth options available from the various point of interaction (POI) vendors such as Verifone and Ingenico as well as other third-party application vendors.
  • Softphones create a larger scope by bringing the workstation they connect to into full scope for PCI compliance. The number of requirements that need to be assessed can be reduced by using VDI and connecting the softphone to the VDI through the workstation.  Making such a connection though is not “plug and play”, so be prepared to have to work a lot with the VDI vendor to make that connection work.  But do not be surprised if it does not provide a reliable and/or clear connection, so make sure you are prepared to have to place the full workstation into scope to have an acceptable working solution.
  • If you are expecting to use The Cloud for your VDI or application, make sure that you conduct appropriate capacity planning so that you are not caught without the ability to expand that solution due to WFH. A lot of organizations have found with the COVID-19 event that their Cloud implementation did not scale as they thought it would.  It turned out that Cloud providers have capacity limitations just like in-house data centers.  While you are not using that capacity all of the time, you need to reserve it for those instances when you need it.  While not free, that excess capacity can be reserved for such events as COVID-19 so that when you need it, it is available.
23
Mar
20

Work From Home PCI Considerations

The PCI Guru got a question regarding PCI compliance for service providers in today’s emergency work from home (WFH) environment from a blog reader and it got The PCI Dream Team thinking about how does that work?  So, thanks to David Mundhenk of Herjavec Group, Art “Coop” Cooper of NuArx, Ben Rothke of Tapad and Jeff Hall of Online Business Systems for contributing to this list.

Ben & David wrote a piece on the topic last week, and the Dream Team has a webinar on Dealing with PCI DSS Compliance During the COVID-19 Crisis on March 25.

Thanks to the Coronavirus crisis, organizations are now scrambling to get their employees working from home.  This is presenting a whole new series of challenges to their compliance, technology and information security teams as these employees are now operating in a potentially less secure and definitely less private environment.

Home networks are going to be less controlled and secure.  Making matters worse is that most home networks today are Wi-Fi based, not wired, so data is flowing over untrusted networks because everyone in the house knows the Wi-Fi password (assuming there is one and it is not the default).

Bring Your Own Device (BYOD)

The biggest issue we are encountering is those organizations that need to rely on workstations owned by employees because they do not have company-owned and configured equipment to provide.  I have seen many a Tweet and LinkedIn post discussing the shortages of equipment for work from home and what options do they have.  The problem stems from most business continuity plans focusing on events that affect a business location or a community, not the entire country.  As a result, the idea of a pandemic forcing people to work from home was not thought of as a realistic threat.

As a result, bring your own device (BYOD) is the only answer in the near term to getting people working from home.  In discussions not only amongst the Dream Team but with other QSAs, there just do not seem to be any good answers for using BYOD and maintaining PCI compliance.  None of us can come up with ways to maintain compliance with BYOD because there are just too many factors involved from anti-virus (many varieties), limited or non-existent central monitoring and management, vulnerability scanning, penetration testing, patching, differing hardware, differing operating systems and a host of other issues that make it impossible to verify compliance let alone maintain compliance.

One potential option to reduce risk and gain better control with BYOD is using virtual desktop infrastructure (VDI) solutions such as Citrix Workspace, VMware Horizon or Windows Remote Desktop Services.  If you have that infrastructure in place, then we would recommend expanding it for WFH remote access.  If you do not have that infrastructure, you may be able to use Amazon Web Services (AWS), Microsoft Azure, Google Cloud or similar cloud environments to stand it up quickly.  That would allow you to reduce the risk of the BYOD being used but there still would be the risk of memory scraping and keyboard logging on the BYOD that must be managed.

That is not to say that you should not use BYOD as you need to keep your business running.  What it does mean is that you need to have a serious talk to your acquirer to determine how to handle this situation, what the risks are to your solution and then communicate the results of that discussion formally to your QSA.  You may even want to have your QSA on those calls with your acquirer to assist.  In these desperate times, I doubt that any bank is going to say you cannot stay in business as long as you can provide some controls and do your best to manage the risk.

We view BYOD though as a short term solution and that a longer-term solution needs to be developed as current estimates seem to indicate that the crisis will likely extend past the original estimate of four weeks.  That longer-term solution would involve acquiring the necessary hardware and software to implement a managed, secured and controlled environment that can be tested to ensure PCI compliance.

Company Provided Hardware and Software

For those companies that do have the equipment to send home with their employees, this is not a complete list, but a set of bullet points of ideas for how to address PCI compliance in our “new normal”.

  • The easiest topic is remote access. The PCI DSS explicitly calls out that a secure VPN (i.e., encrypted) with multi-factor authentication (MFA) for users to obtain access to the service provider network (8.3.2.a).  But where things can go sideways is complying with 8.3.1.a which requires MFA for non-console access to systems/devices in the cardholder data environment (CDE).  It goes awry because people think that the first MFA covers the MFA into the CDE and it does not.  The reason is that 8.3.1.a was designed to stop the phishing of Administrators to gain access to the cardholder data environment (CDE).  To stop that, you need additional MFA to access the CDE.  That does not mean a separate MFA solution (which would be ideal), but it does mean enforcing a delay in the single MFA so that the same MFA code cannot be used to access the internal network and then also the CDE.  A lot of organizations implement the delay in their remote logon script by invoking a timer delay that expires after the longest time a code can be active (usually 30 seconds).
  • A secure VPN is necessary to remove the home network from scope. Ideally, the VPN should be required to always be in use so that the workstation cannot get to the internet other than over the VPN.  For those that do allow the home network and internet to be accessible, you will need to ensure that the firewall on the workstation appropriately protects the workstation as well as implementing a host intrusion detection solution (HIDS).
  • VDI is also a solution because it allows for the use of thin-client and devices such as Chromebooks to be used to connect. Most VDI solutions also embed a secure remote connection via HTTPS or similar secure connectivity solutions.  If not then you will need to use a secure VPN as documented above.  However, even a thin client runs the risk of memory scraping and keyboard logging so you need to manage those risks.
  • Review all automated workflows to make sure that they are producing the necessary audit trails that will provide evidence for you PCI assessment of what is happening. Where this becomes problematic is when the workflows are developed only for PCI compliance and with the changes for remote operations, those workflows are not picking up new users, devices and other changes that were made to allow for remote work.
  • People that typically work together but now are remote will start using Microsoft Teams, Slack, Skype and other collaboration platforms to communicate and that may include sharing cardholder data (CHD) or sensitive authentication data (SAD) at times. You will need to train and quickly remediate situations if CHD/SAD enters these applications as well as periodically reminding these people that the use of these communication systems for transmitting SAD/CHD is not allowed.  If possible, enable data loss prevention (DLP) or similar capabilities to identify and then redact SAD/CHD in any of these communications.
  • If you are pushing out call center operations, remember that softphones will bring the workstation they connect into scope for PCI compliance because the workstation is now directly connected to the CDE which is, of course, the VoIP telephone system. That means an increase in scope and that those workstations need to be hardened, managed, logged and controlled for PCI compliance.  Call center operations may also require additional network segmentation to be put in place to ensure the size of your CDE does not exponentially grow.
  • While not entirely PCI related but needs to be noted are some other remote call center operation issues to consider that could make compliance with contractual obligations regarding privacy and confidentiality of data discussed or processed by the operator. You may need to supply operators with shredders, printers, additional monitors and other equipment to ensure privacy and productivity.  You may also have to instruct people to locate their work area to a bedroom or other room where a door can isolate the operator while they work so that family members do not come into contact with information or documents they should not view.
  • Ensure that you have ways to document changes happening, their review and approval. A lot of organizations have paper forms, Excel spreadsheets, email forms, etc. they use that sometimes can get lost in people’s inboxes, archives and folders or just lost, period.  You need to make sure that the change management system will work in the remote mode and that change evidence, reviews and approvals are maintained.
  • Logging should not be an issue unless your organization was not logging the VPN or other devices because they were not in scope for PCI compliance but now are in scope. So, you need to review your new workflows to ensure all devices and systems are logging to your SIEM or logging solution so that you comply with PCI requirement 10.
  • Encryption key management could become an issue particularly if your process does not support remote management. This can happen with some hardware security modules (HSM) and systems that require that the key custodians physically input their seed values into the device’s console.  So, going on-site may be required for encryption key changes and that may require formal approval from local authorities to occur.

These are the top of mind ideas that we were able to come up with for this discussion.  However, every environment is different so not everything discussed may be possible for your organization to use and maintain compliance.  We would recommend you work with a QSA to make sure that what you are attempting to do is not creating risks you are unwilling to accept or if you cannot manage appropriately.

We wish all of you the best of luck during this crisis.  We will get through this, but it will likely take some ingenuity in how that happens.

Also, be aware that the Council and the Card Brands are working on this topic as well and I expect more from them in the coming weeks.

Stay safe and healthy.

 

Other WFH resources:

CISA Coronavirus Guidance – https://www.cisa.gov/coronavirus

NIST Teleworking Guidance – https://csrc.nist.gov/publications/detail/sp/800-46/rev-2/final

SANS Work From Home Webcast – https://www.sans.org/webcasts/archive/2020

08
Dec
19

Are You A Level 2 Merchant? Beware The MasterCard Trap

I had a discussion with a prospective client and as things usually go you want to determine their merchant level.  As it turned out, they were confused about the differences between Level 3 and Level 4 and their bank was just as confused.  The merchant had a 2 to 1 advantage in Visa transactions (around 800K) over MasterCard and, in total, had more than one million transactions across all card brands.

When their bank couldn’t decide their merchant level, the bank referred them to Visa since the bank was affiliated with Visa.  Visa informed the merchant that they were considering them a Level 2 merchant because of the high volume of eCommerce transactions (80%+) and their total transaction count for all payment cards (around 1.3M).

With this information in hand I said, “Well, it looks like you’ll be doing a ROC.”

The CFO at the other end of the WebEx exclaimed, “Say what!  Why do we need to do a ROC?  The standard says we can do a self-assessment!”

Sadly, another merchant gets caught flatfooted by the card brand rules.  People think that the PCI DSS and other PCI standards are all they have to worry about for card payment compliance.  However, the card brands (i.e., Visa, MasterCard, American Express, Discover and JCB) also have their own security programs in addition to the PCI standards and those also need to be followed.  Think that is not the case?  That Merchant Agreement from the bank that someone in the merchant’s organization signed calls out that not only do PCI standards need to be followed but also the rules from the card brands the merchant has agreed to accept for payment (almost always Visa and MasterCard with one or more of the others) also need to be followed.

One of those “quirks” in the card brands’ programs that comes up is this one regarding Level 2 merchants and MasterCard.

The first thing everyone needs to remember is that if a merchant is at a certain merchant level for one card brand, they are at that merchant level for ALL the card brands.  The second thing to remember about merchant levels is that any of the card brands can set the merchant level for a merchant regardless of transaction volume.  I have had merchants end up as a Level 1 merchant with fewer than 30K transactions all because the dollar value per transaction was extremely high as with business to business (B2B) transactions.

With that information, a merchant now needs to go to the card brands’ Web sites for the brands you accept and review their rules.  If you go to the MasterCard Web site to the page titled ‘What merchants need to know about securing transactions’ and scroll down to the merchant level requirements for Level 2, you will see footnote 3 next to the requirement “Onsite Assessment at Merchant Discretion”.  That footnote states the following:

“Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

For an organization to get an employee trained as an ISA, you need an employee with backgrounds in compliance and technology.  Typically, this would be someone in the internal audit department that a lot of Level 2 organizations do not have or if they do have, the people do not have the time to take on PCI. Then there is the cost which is $3,100 USD plus travel expenses since most ISA training is not done locally unless you are lucky. And finally, there is the employee retention issue after such an investment.

In the end, most Level 2 organizations do not see the cost benefit of training one of their employees to be an ISA in order to do an SAQ.  As a result, that is why I get to my comment about Level 2 merchants doing a ROC.

Oh, and for the record, the PCI standards do not dictate which organizations can fill out a self-assessment questionnaire (SAQ) and which fill out a Report On Compliance (ROC).  The card brands dictate that based on merchant and service provider levels.  In this case, MasterCard has its own ideas in that regard when it came to Level 2 merchants.

21
May
19

An Inadvertent Service Provider

A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions.  QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.

The Situation

As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations.  These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses.  Of course, all of these third parties accept payment cards for their services and need a way to process those cards.  Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors.  Thus, bringing that network and everything attached to that network into scope for PCI compliance.

As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant.  The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope.  But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.

But it can and does get worse.  I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.

What Do You Do? Option 1 – Get Out Of Scope

There are some ways to get out of scope, but these can be complex and/or expensive.

The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP).  The problem with this is that an ISP will likely have to run wire into your facilities to make those connections.  That can be disruptive as well as expensive and complicated due to locations within existing buildings.  And what if each business wants their own ISP because of a contract relationship?  That will mean multiple ISPs tearing up your facilities.  Not necessarily the best situation.

The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties.  I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth.  However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.

But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.

What Do You Do? Option 2 – Reduce Scope

There are also a couple of ways to reduce scope.  But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.

The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet.  However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.

Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization.  While this seems simple, it usually never is simple.  Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope.  Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections.  Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic.  It ends up more trouble than it is worth.

The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties.  That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.

Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity.  Those just complicate your compliance and reporting efforts.  All I can say is, if you can stop offering those services, stop.  If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services.  That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.

Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.

There you have it on third parties and their payments on your network.

25
Feb
19

Network Segmentation Testing

As part of penetration testing, merchants and service providers are required to test that their network segmentation is properly implemented and functioning.  Sounds like a simple enough task, but you would be amazed at the bizarre and complicated discussions that QSAs encounter when segmentation testing comes up.

As a reminder, requirement 11.3.4 states:

“If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.”

For service providers, requirement 11.3.4.1 adds in the requirement of testing at least every six months or any changes to network segmentation, not just “significant changes”.

Regardless of whether you are a merchant or a service provider, how segmentation testing is performed is the same.

So why all of the issues?

First, the PCI DSS does us no favors with the “guidance” for requirement 11.3.4 which states:

“Penetration testing is an important tool to confirm that any segmentation in place to isolate the CDE from other networks is effective. The penetration testing should focus on the segmentation controls, both from outside the entity’s network and from inside the network but outside of the CDE, to confirm that they are not able to get through the segmentation controls to access the CDE. For example, network testing and/or scanning for open ports, to verify no connectivity between in-scope and out-of-scope networks.”

The first point of confusion typically relates to the phrase “penetration testing” as though segmentation testing somehow requires the use of a penetration testing tool such as Metasploit or similar to conduct the segmentation testing.  Nothing could be further from the truth.  But the terminology of “penetration testing” clouds the task.

The second point that seems to confuse is the last sentence that starts out with “For example …”.  People seem to miss that start of the sentence and take it that all they have to do is make sure that out of scope devices cannot get to the CDE and that is it.  While network segmentation testing is simple, it is not quite that simple.

What Is Segmentation Testing?

After going through the debunking of all of the mythology and rumors surrounding network segmentation testing, this is the first question asked.  I always take people back to what the purpose of network segmentation testing is – to prove network segmentation is implemented and is functioning as designed to keep the various networks logically separated.

When I say, “various networks”, I am referring to the network segments defined in the information supplement “Guidance for PCI DSS Scoping and Network Segmentation” issued in May 2017.  In that document, the following terminology is used.

  • CDE Systems – any systems/devices that directly process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD) or are directly connected to such systems/devices. These systems/devices are also sometimes referred to as Tier 1 or Category 1.
  • Connected To or Security Impacting Systems – are systems that provide services to the CDE or have connections to systems/devices in the CDE that could adversely affect the security of the systems/devices in the CDE. These systems/devices can also be referred to as “Shared Services”, Tier 2 or Category 2.
  • Out of Scope Systems – are systems that cannot connect to the CDE also referred to as Tier 3 or Category 3.

For PCI compliance, all CDE Systems (Category 1) and Connected To (Category 2) systems are always in scope.  However, for network segmentation testing, Category 3 systems/devices are also included because the testing must prove that Category 3 cannot get to Category 1 and vice versa.  That is typically were network segmentation testing goes wrong is that it only proves that Category 3 cannot get to Category 1 and then stops.  The guidance for requirement 11.3.4 provides some clarity in the second sentence which states:

“The penetration testing should focus on the segmentation controls, both from outside the entity’s network and from inside the network but outside of the CDE, to confirm that they are not able to get through the segmentation controls to access the CDE.”

The Council has advised that what they want is testing from inside and outside the CDE as well as from other network segments including the internet if applicable.  The idea is to further support the analysis and findings from a QSA’s review of the firewall rules from the requirements in 1.3.x of the PCI DSS.  The reason for this is that with some breaches and the advent of “next generation” firewalls and more sophisticated security technologies, the Council felt that assessed organizations and QSAs were not necessarily proving that network segmentation was truly in place and wanted some additional testing and confirmation.

How Do I Test?

First and foremost, timing of the testing is very important.  For merchants, it should be conducted as close to annually as possible,  For service providers, they are required to be conducted as close to every six months as possible.  But you also need to consider the concept of “significant change”.  If there have been significant changes that affected network segmentation, then the network segmentation testing must be done as soon as possible (the Council typically recommends a maximum of 30 days) after the significant change has been implemented.

While the tool used to conduct the test can be as simple as Nmap or the like, the testing itself can be complicated depending on how your network is segmented.  I have clients that have hundreds of segments that results in a very time-consuming amount of testing.  The key here is to be thorough, but not insanely thorough.

I have no problem with network segmentation testing including a review of firewall and ACL rules and using that information to test for example from a particular network segment into another because the rules are the same for all the network segments being tested to support a particular rule.  The key is to be able to justify why you picked one segment over another and not repeatedly test from only one segment for every test.  Provide the rules with an explanation of your justification for what you did.  This will allow the QSA to understand how you worked and why.

But Nmap is not the only tool that can be used.  There are a number of network management/modelling/monitoring tools such as FireMon, Tufin and RedSeal that can also be used to prove out network segmentation.  In fact, these tools can provide ways to perform the network segmentation testing that do not need to involve scanning the network and merely running reports against the databases created by these tools.

Regardless of the tool used, be careful.  I have seen too many reports where the tools did not go to the devices within the network segment and the results did not necessarily prove segmentation is in place and functioning because when matched up to the server configuration it showed other forms of communication.

Segmentation Testing Reporting Requirements

Once you have completed your network segmentation testing, you need to create a proper report of those results.  At a minimum, a network segmentation testing report should have the following sections.

  • A one to two page (at most) Executive Summary of the network segmentation test, the date the testing was started, the date when testing was completed, the results (i.e., pass or fail) and a summary of all findings and recommendations.
  • Document who conducted the test including a bit of background as to why they are considered capable of conducting the test by including any information security certifications they hold and other relevant information security experience.
  • Provide the reader a frame of reference for the testing performed. At a minimum, this should include a high-level diagram of the various segments (i.e., CDE, Connected To and Out of Scope) and an overview of the IP addressing within each of those segments.
  • Document and discuss any significant changes that occurred since the last network segmentation test and what was done to prove that significant changes did or did not occur since the last segmentation test. This is necessary to confirm to the QSA and other readers that you are not just following some predefined schedule (i.e., annually or semi-annually) but are also ensuring that significant changes also potentially drive segmentation testing as required in by the PCI DSS.
  • Document the methodology that was followed and the tools that were used to prove out network segmentation. What is needed in this section is specificity.  Document step by step, in enough detail that someone else could conduct the testing, what you did to prove network segmentation was in place and functioning as expected.
  • Document any findings and recommendations that result from the network segmentation testing particularly those findings that prove the network is not segmented as expected resulting in a failed test. If segmentation is not in place, then you will need to remediate those findings and retest to prove that the remediation was successful.  If retesting is required, you need to keep all reports so that you have a record of everything that has been tested.
21
Nov
18

Requirement 12.8.2

I got a comment a while back about contracts and PCI compliance.  The two requirements that are relevant in this discuss are 12.8.2 and 12.9.  Requirement 12.8.2 is for all organizations (merchants and service providers) that are being assessed under the PCI DSS.  Requirement 12.9 is only for service providers.

As usual, the clarifications surrounding these requirements were all provided verbally over the years at various PCI Community Meeting presentations and Q&A sessions.  But the overall gist of these requirements can be readily determined.  It just takes a little bit of effort and looking at more than just the PCI DSS.

Requirement 12.8.2 states:

“Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”

The Guidance provided for 12.8.2 states:

“The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.

In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.”

If things are still not clear enough, it helps to look at the ROC Reporting Template to get clarification.  The tests being conducted for a given requirement usually clear up any confusion regarding what is being expected.  There is only one test for 12.8.2 and it states:

“Describe how written agreements for each service provider were observed to include an acknowledgement by service providers that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer’s cardholder data environment on behalf of a customer.”

The first thing to notice in all of these discussions is that nothing in the PCI DSS states that any organization is required to work with a PCI compliant third party.  None of the requirements in 12.8 specify that an Attestation Of Compliance (AOC) be provided.  A lot of QSAs will argue that requirement 12.8.4 requires it, but if you read the test:

“Describe how it was observed that the entity maintains a program to monitor its service providers’ PCI DSS compliance status at least annually.”

There is nothing in that test that explicitly mandates that an AOC is required to monitor third parties.  Granted an AOC is the easiest way to monitor service provider compliance, but there is nothing explicitly calling it out in this test.

So where does this “requirement” originate?  It comes from the merchant agreements with the card brands, specifically Visa and MasterCard.  They require that their merchants only work with third parties that are PCI compliant and can prove that compliance with a Service Provider AOC.  This is why it is important to read and understand the brands’ merchant agreements and their own security programs.  There are a number of key “requirements” that come from those documents that are just as important as what is in the PCI DSS.  So, read them as well as all of the PCI documents.

Getting back to the PCI DSS, what the Council wants QSAs and ISAs to look for in contracts, master service agreements, addendums and any other legal documents that describe the parties’ legal relationship is some sort of acknowledgement between all parties that they will abide by the PCI DSS and ensure that sensitive authentication data (SAD) and cardholder data (CHD) is kept secure.

Where a lot of QSAs/ISAs go wrong is demanding that the words “PCI DSS”, “PCI standards” or other explicit acknowledgement of “PCI” something to appear somewhere in those documents.  The Council has stated a number of times that explicitly using “PCI DSS”, “PCI standards” or “PCI” anything is not required.  It would be great if such documents did, but a lot of legal documents do not because they either predate the PCI DSS or lawyers argue it is not necessary.  That is what led to the Note in both requirements.  The key is the last sentence which explicitly states:

“The acknowledgement does not have to include the exact wording provided in this requirement.”

It is this sentence that the Council always points to and states that this is why explicit statements of PCI or any other direct reference to PCI is not necessary nor required.  My advice is, when in doubt, ask your client’s legal counsel for their legal interpretation of the legal agreements and whether they fell it covers the PCI responsibilities of the parties involved.

That will lead you to the fact that a lot of legal agreements reference the PCI DSS and PCI standards indirectly through language that obligates the parties to follow and comply with “regulatory or other legal requirements”.  The reason this language works is because “other legal requirements” will drag in the card brand legal agreements for taking and processing card payments.  Every card brand has legal agreements for merchants and service providers that explicitly call out that the customer of the brand will maintain PCI compliance for all relevant PCI standards.

Where this discussion becomes problematic is with service providers that do not directly process, store or transmit SAD/CHD such as managed service providers and the like that can affect the security of payments.  That is because they are not directly under the card brands’ legal agreements, so their contracts while using the same “regulatory or other legal requirements” will not necessarily be referencing PCI compliance because they are indirectly involved.  It is in these cases that I rely on getting a PCI AOC from the service provider which then provides the additional assurance that the service provider understands that they need to be PCI compliant.

It is when I cannot obtain an AOC from a service provider that I then explain to my client that this service provider’s environment needs to be assessed as part of their assessment.  Either that or my client needs to find a new PCI compliant service provider.

What a QSA/ISA needs to be looking for in a service provider’s AOC is a couple of things (actually, there are a lot of things, but these are the most important).

First, you need to ensure that the services provided to your client have all been covered by the service provider’s assessment.  Section 2a of the AOC documents the services covered and not covered.  The most common problem found with section 2a is that one or more services used by an organization were not assessed.  If services were not assessed, then you need to notify the service provider and develop a plan of how to handle this situation.

The next thing to review is the locations that were part of the assessment.  It still amazes me the number of AOCs I review where a client’s data center or processing center was not part of the assessment.  It gets worse when you bring this to the attention of the service provider and they get put out or worse, they argue with you over the fact that they must review every facility where a service is conducted.  I am sorry, the PCI SCC and the card brands are the ones that make the rules, I am just the poor assessor that must enforce and live by them.

Finally, you need to review section 2g for all of the services assessed (if they were assessed from section 2a).  Section 2g are a matrix of the 12 PCI DSS sections that explains who is responsible for the various PCI DSS requirements.  From this matrix an organization is to construct their PCI program to fit the controls that they need to implement to be PCI compliant for this service.

There should be a section 2g for every individual service assessed, but in instances where PCI coverage is the same for different services (e.g., SaaS application hosting), you can combine services in section 2g.  However, this is where problems usually are found.  My favorite example of such a problem is the day I found data center co-location and call center services listed in the same matrix.  I am sorry, but those services have very little similarity particularly in PCI controls.  When you encounter this situation, it is usually indicative of a QSAC that does not understand how to deal with service providers and is cutting corners to get the ROC and AOC out the door.  In addition, it also likely indicates a service provider that is just “checking a box” for PCI compliance to placate customers.  But worse is when that service provider is listed on the Visa or MasterCard service provider lists (it is rare, but I have seen it) which then indicates that the brands are also not doing their due diligence in their review of the AOC.

Hopefully, you now better understand requirement 12.8.2.  In a future post I will discuss requirement 12.9.

09
Nov
18

Service Provider To A Service Provider

Another good question from our recent PCI Dream Team session.

“Are service providers to a service provider be required to provide report on compliance (ROC) to the service provider in a private cloud scenario?”

It depends.

The reason it depends is because the answer will depend on whether or not the service provider in question directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD).  While our session this time was on ‘The Cloud’, the cloud has nothing to do with the answer, so the answer will be the same regardless.

If you are unsure if you are a service provider, read this post.  If you are trying to construct a story that gets your out of scope as a service provider, read this post.

Reporting Requirements

Before we can talk about what a service provider needs to provide to a merchant or another service provider, we need to ensure that everyone understands the PCI reporting requirements.

For any service provider that directly processes, stores or transmits SAD or CHD, if the volume of Visa/MasterCard/Discover transactions is greater than or equal to 300,000, then the service provider must go through a PCI assessment that produces a Service Provider ROC and Attestation Of Compliance (AOC).

For service providers that directly process, store or transmit less than 300K transactions or does not directly process, store or transmit, then that service provider can self-assess using the Service Provider SAQ D and related AOC.

Another key point regarding reporting that needs to be made is that there are differences between the Merchant AOC and the Service Provider AOC.  It is very important that service providers use the Service Provider AOC and not the Merchant AOC.

I still get too many Merchant AOCs from service providers.  Most often this is because these service providers are also merchants and they mistakenly believe their merchant PCI assessment serves as their service provider PCI assessment.  Not so!  These service providers need two assessments.  One that covers their merchant payment processes (usually a very small assessment) and one that covers their service provider processes which is usually the larger of the two.

The first key AOC difference is that the Service Provider AOC has a section 2a that discusses what services were assessed in the assessment and what services were not assessed.  This is important to customers of service providers because it allows them to ensure that all of their services have been assessed in this AOC.  If they have not, then the customer knows to ask the service provider for additional AOCs that cover those services.

The other key AOC difference is section 2g which documents the requirements tested during the assessment for each service assessed from section 2a.  The PCI SSC requires that individual 2g sections be used if the services assessed have different requirements matrices.

Finally, section 2c is also very important to customers as it explains what locations were included in the assessment.  I cannot tell you the number of AOCs I have reviewed from large service providers only to find that the location used to service my client was not part of the service provider’s assessment.  As a result, the AOC has no use to my client in their assessment.

Who Needs What?

Under the PCI rules, a service provider is required to provide their Service Provider AOC to all merchants and other service providers to which they provide services.  Yet time and again as a QSA, I end up in fights with service providers who refuse to provide their AOC to my clients.

This requirement of providing an AOC is all about proper vendor management and ensuring there are no gaps in meeting controls responsibilities.  The Service Provider’s AOC has a matrix in section 2g for each service assessed that explains what requirements the service provider is responsible, what requirements are the customer’s responsibility and those requirements where there is shared responsibility.  Without that matrix, a customer has no way to understand their responsibilities in maintain PCI compliance between themselves and their service providers.

Please notice that nowhere have a I mentioned sending anyone the ROC, only the AOC.  As you will recall, the question involved the sending of the ROC to another service provider.  That is not to say that you cannot send your ROC, it is just not required by the PCI SSC.

As a QSA, I have encountered a few situations where section 2g is not clear enough and have asked a service provider for their ROC to ensure that my client properly sets up their controls to mesh with the service provider’s controls.  If the service provider was unwilling to provide their ROC or even the section needed, I hold a lot of conference calls to clarify the situation.

With that said, if you want your organization listed on either the Visa or MasterCard Global Service Provider lists, you will have to submit your ROC and AOC to those card brands (as well as some money) to get on those lists.  If you are a service provider and can use the Service Provider SAQ D and you want to get listed on either brand’s service provider list, you will have to go through the ROC assessment process.  Visa and MasterCard will only accept a ROC for listing on their sites.

Hopefully you now understand what is required and what is not.

08
Jul
18

Can I Use SSAE 18 SOC 2 Reports? Part 2

In the last post I discussed what the SOC reports are and what, in general, to look for in a SOC 2/3 report.  Now I want to take you through the more detailed analysis of the SOC reporting so that you can understand why it might not give you the result you desire and how to address that fact.

How Do I Analyze The SOC Report?

Based on the testing in the ‘Information Provided by Independent Service Auditor’ section, you are going to need to map that testing into the PCI ROC tests, if they even fit.  I typically use the Prioritized Approach spreadsheet to do this as it provides a way of documenting the requirements covered and a quick dashboard regarding what is covered.

As you reviewed the domains listed under the SOC 3 report, I am sure you thought; “What is not to like?  It looks like most of what I need for PCI is covered.”  But you would be wrong.  You will find after you map the controls from any SOC 2 report that covers all the TSP domains into the Prioritized Approach that the report will likely only cover around 20% to 25% of the PCI DSS requirements.  That is because the level of detail in the SOC tests are just not as detailed as they are in the PCI DSS.  As a result, SOC 2 reporting does not provide the kind of reliance you need to respond to all of the relevant PCI DSS requirements.

For example, while SOC will likely test that password controls are in place, you will be unable to ascertain if the organization enforces seven character or greater password lengths, password complexity, nor if they require passwords to be changed every 90 days or less.  Let alone if the special requirements for vendor password management are enforced.  It is these missing details that create the coverage problems with using the SOC reporting results.

The same can be said for change management.  When tested, the SOC report will likely call out a lot about change management, but not at the level of detail required in the PCI DSS for requirements under 6.4.  You will also find that coverage in requirements 1 and 2 regarding network and server configurations will be lacking in specificity to meet the PCI DSS testing.

Now as a QSA, you have a decision to make.  Can you accept only 20% to 25% of coverage of PCI DSS requirements as being PCI compliant?  I know I cannot.  I need much more to work with before I can get comfortable that a SOC report provides the necessary coverage for PCI compliance.

Now What?

You and your client have expended all this effort and are no closer to the result desired than when this process started.

So, what to do next?

Work with your service providers that provide you SOC reports to include testing that adds the PCI DSS details that are missing.  There will likely be a bit of push back from these service providers because adding testing to their SOC reports will cause the cost of their SOC reports to increase, sometimes significantly.  So be prepared for it.

What you need to do is to have their auditors add the necessary testing details to the description of controls and then have them test that they are in place.  Examples include:

  • Password length, complexity, change frequency and the procedures followed to perform a password reset.
  • Details surrounding privileged and general user management including provisioning, management approvals, users are implemented with least privilege and users are disabled or removed when terminated.
  • Changes tested for segregation of duties between developers and operations, segregation of test, QA and production environments, production data not used for testing, developers do not have unrestricted access to production, test data and accounts removed before applications are promoted to production, changes document impact, they are appropriately authorized, they have been tested, they have been vulnerability assessed and they document backout procedures.
  • If encryption is used to protect data, document the algorithms used, are key custodian agreements in place, are split key processes in place if performing manual key management, indicate if a hardware security module (HSM) is used and are keys changed when their crypto-periods expire or they are believed to be compromised.
  • Document the configuration standards that are followed by device classes such as firewalls, switches, servers and test that they have been implemented.
  • Document that anti-virus is implemented on systems commonly affected by viruses and malware, what the anti-virus solution is that is implemented, the anti-virus solution cannot be disabled and that the anti-virus solution is actively running on all systems it is installed.
  • Document that vulnerability scanning is performed, how often scanning is performed and that vulnerabilities are remediated.
  • Document that penetration testing is performed, how often penetration testing is performed and that findings are remediated.
  • Document that log data is collected from all devices, it is reviewed at least daily and that it contains a date/time stamp, device name, type of log entry and other relevant information.

There are a lot of other areas that could be added to the SOC report, but these are, in my opinion, the bare minimum that need to be added to make the SOC report more relevant for PCI.  I am trying to balance the amount of additional information needed versus the cost of providing it in the SOC report.

By adding all of this will it cover all of the gaps between SOC and PCI?  No.  But it should give your QSA significantly more comfort that the controls in place to meet PCI than what is currently being provided by CPAs.

26
Aug
17

PCI Compliance And Financial Institutions

I remember being at one of the early PCI Community Meetings and someone from the PCI SSC promised that the PCI DSS would be periodically updated to reflect changing business conditions as well as changing threats.  Here we are more than a decade later, and we have version 3.2 of the DSS, but it has been changed more for changes in threats and very little for business.

Their rationale was that they wanted to minimize the number of compensating control worksheets (CCW) that would be needed for the majority of organizations.  This was in response to v1 of the PCI DSS that required that data encryption keys change annually.  Most large merchants who were participating organizations (PO) complained that it was taking six months to a year or more to encrypt their transaction databases and files.  Requiring annual key changes would leave those databases and files at risk because they would always be in a state of perpetual decryption/encryption.  As a result, almost everyone had a CCW for that requirement.  So, the Council changed the requirement to require the changing of encryption keys when they were believed to be compromised or if one or more persons who know the keys leave the company or change roles.

The reason I bring this up is that I have been dealing with financial institutions and their PCI compliance issues for the last few years.  If there is anything more frustrating, it is trying to apply a standard written for merchants to organizations that are not merchants.  It seems like every time I turn around; a requirement needs a CCW, particularly when concerning requirement 3.4.

I am sure the Council will point to requirement 3.2 as their token change that took into account issuers.  But that does nothing for the other requirements that financial institutions struggle.  The biggest reason a lot of the PCI requirements are a struggle is that financial institutions are in the business of; surprise, surprise; processing, storing and transmitting cardholder data.  That IS their business.  3.2 was a great change for issuers, but a lot of the rest of the PCI DSS is a huge pain for a financial institution without a lot of CCWs and the blessings of the requisite card brand(s).

Let us look at a few requirements where CCWs are needed when assessing an FI.

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) – this can be very problematic for financial institutions.  The reason is that while they can encrypt or tokenize the data, they also need to decrypt/detokenize it as well.  In a lot of cases, they need to do those operations quickly and very often.  It is not that the FIs do not want to protect the information, it is just that they have some unique issues in meeting PCI requirements.

The best example of this situation is debit cards.  Debit cards must be tied to a demand deposit account (DDA) such as a checking or savings account.  That means somewhere there must be a mapping of the debit card into the core application system.  But to process transactions from the card networks when customers use their cards, the PAN must be decrypted/de-tokenized so that the payment can be approved or declined.  This decryption/de-tokenization process needs to meet a timing standard, so adding to the processing time is usually not an option.  As a result, it is not unusual to find that the PAN to DDA mapping file is not encrypted or tokenized.

6.4.3 Production data (live PANs) are not used for testing or development – when part of your business is all about processing, storing and transmitting sensitive authentication data (SAD) and/or cardholder data (CHD), using a few card brand test accounts like a merchant would use for testing is not going to work.  Particularly when you are testing with one of the card brands to certify your application.  In those instances, the FI and brands are going to demand the use of a large and varied set of PANs to ensure that systems are functioning properly.  The only way to do that is with live data from production.

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.  – requirement 3.2 addresses that issuers that have a business reason to retain sensitive authentication data (SAD) can retain it.  However, 3.2.1, 3.2.2 and 3.2.3 say that all of this data cannot be stored right after authorization. These requirements then go on to say the QSA must inspect incoming transaction data, log data, databases, etc.  Well, guess what?  The incoming transaction data always has SAD in it of some form because the FI has to authorize the transaction.  As I said earlier, databases can have it because of the speed required to authorize.  This is the FIs’ business, yet the standard does not recognize this fact.

The bottom line is that the PCI DSS does not reflect the realities of financial institutions.  As a result, FIs require numerous CCWs to meet the PCI DSS requirements.  As I stated at the beginning, the Council promised that they would address such issues to make CCWs the exception not the rule.  Well, here we are, and in the FI world CCWs are commonplace.  And as we move forward, it will be FIs that will be the focus of the standard, not merchants.  Merchants will very soon be out of the payment card data business altogether with the exception of their POI.  So, it only makes sense to adapt the PCI DSS to securing FIs.

We have separate PCI DSS and AOC documents for service providers.  Maybe we need separate such documents in addition to revised requirements for financial institutions?

Seems like a good discussion topic to bring up at the upcoming Community Meeting.

28
Apr
17

The Five Stages Of PCI

Had a meeting with a prospect recently that is bound and determined to avoid PCI compliance yet still will accept payment cards.

My response?  Good luck with that!

You would think after 15 years of PCI (and actually even longer) that people would understand that PCI compliance is a fact of life.  But I continue to find that PCI is no different than the five stages of grief.

Denial

This is where that prospect is now.  They cannot believe that there is no way to avoid PCI compliance.

For once and for all, if your organization accepts payment cards, you MUST comply with the PCI DSS.  Do not like that answer?  There is nothing as a QSA I can do to effect that fact.

However, for merchants there is a way out.  Do not accept payment cards for payment.  It is that simple.

That answer though immediately leads to the next stage.

Anger

I once had a prospect tell me very emphatically that PCI was unenforceable.  I asked them if they had read their Merchant Agreement with the bank that allowed them to accept payment cards for payments.  To my astonishment they said, “What the [expletive] does that have to do with anything?”

You can be angry all you want but PCI compliance is a legal, contractual requirement documented in the Merchant Agreement, Card Operating Rules and other documentation referenced in those documents.  Someone in your organization signed that Merchant Agreement – most likely your Chief Financial Officer (CFO), Controller, Treasurer or heaven forbid – the person that is blowing their cork.  That is the person you should share your anger with, not me.  As a QSA, I am just the messenger.

Anger is even worse with service providers.  Particularly those that provide services tangential to card processing such as those that provide network, firewall or server management services.  They had no idea that their customer(s) needed them to be PCI compliant because they never realized that their service(s) could affect the security of payments.  These folks get totally blindsided by PCI compliance and hence their anger.

I have found that anger over PCI can last a long, long time with some organizations and people.  I still have clients that are angry about it.  It may be less aggressively displayed, but you can tell that they are still angry.

Bargaining

A lot of organizations get stuck in this stage.  They are bound and determined to find that “silver bullet” that somehow magically gets them to PCI compliance with the minimum amount of effort (i.e., none).  They know it is out there and all they need to do is find it.

Because of this stage and the fact that organizations get stuck in it, there are any number of “snake oil” PCI compliance solutions that prey on those in the ‘Bargaining’ stage.  All of them have “The Solution” that will solve your organization’s PCI compliance problem.  They have a pitch for every day of the week and for every situation.  Just ask them.  But at the end of the day, all of these solutions just address one or two PCI compliance issues and do not result in that magical “silver bullet” that those in this stage continue to seek.

Another indicator of organizations stuck in this stage are that they go through compliance and IT leaders like a teenage girl goes through boyfriends.  You immediately know an organization is in the ‘Bargaining’ stage as a QSA because you are always dealing with someone new every year.

Another telltale of a ‘Bargaining’ stage organization is that they are constantly arguing with their QSA over what PCI DSS requirements they need to comply.  PCI is not anything at all like “Let’s Make A Deal”.  It gets even worse when they argue the PCI DSS like it is a legal document and you get discussions over the meaning of the word ‘is’.  At the end of the day, your QSA or acquiring bank cannot cut you a deal on what PCI DSS requirements your organization can ignore.

The bottom line is that the absolute least level of PCI compliance any organization can have are the requirements documented in SAQ A.  Period.  There is nothing less than those requirements.  And SAQ A requires that an organization totally outsource to a third party everything related to card processing.  And I do mean everything.  Nine times out of ten, complete outsourcing is unacceptable to organizations who demand control over their business processes and the “look and feel” of their operations.

Depression

Once an organization realizes that there are no “silver bullets”, depression quickly sets in.  With some clients you can see depression get deeper with every data breach announcement that hits the media.  All they can imagine is that their organization is next.

Then there is the fact that PCI compliance is going to cause changes and cost people, time and money to address compliance gaps.  This is where a good QSA can be of great help.  A good QSA can give you options to minimize those resources.  Good QSAs understand that most merchants do not exist on huge margins and that investments with an ROI of more than three years are very painful and difficult to justify.

Unfortunately, in a lot of cases, there are not a lot of options available and even good QSAs are not miracle workers.  This is particularly true when the organization has not invested in infrastructure and application software in a long time.  Worse is when they have invested (usually heavily) in one or more of those “silver bullets” from the ‘Bargaining’ stage and they assist in their compliance efforts only minimally.

Acceptance

I would like to tell you that I have a lot of clients in this stage, but I do not.  Although the number is growing slowly but surely.

But the good news is that if you can get your organization to this stage, there are benefits.

The biggest benefit in my view is that organizations in Acceptance “get” security and why it is a necessary “evil” in today’s ever more connected world.  Never mind the PCI component.

Those at this stage are great to deal with because they have taken steps to minimize their PCI scope and simplify their card processing as much as possible.  They have standardized processes.  They understand that PCI compliance improves their organization’s security.  And not just for the security of cardholder data but for the security of all sensitive information and the whole organization.  Their investments in PCI compliance have paid off (sometime in spades) as they simplified their operations and got rid of sensitive information that they have no longer deemed necessary to retain.

A lot of organizations in this stage have integrated some or all of the PCI DSS requirements into their everyday operations.  As a result, PCI compliance is a daily affair, not the once a year fire drill that it is for most organizations.

These organizations are not perfect by any sense of the word.  But they are a level or more above other organizations and that is all it takes.  Because information security is no different than those movies that show a herd of animals being chased by a lion or tiger.  To survive, you just have to make sure that you are not one of the weakest animals in the pack.  Or as a friend of mine has said for years, “My security program does not have to be the best, just better than yours.”




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2020
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,289 other followers