13
Feb
13

What If?

Here is a thought provoking question that was posed to me recently by a former accomplice in the PCI world.

What if PCI DSS assessments were only required until a merchant proved they were PCI compliant or if a merchant had been breached?

The premise behind this idea is simple.  There are going to be merchants that get information security and there are those merchants that are never going to get information security no matter the carrots or sticks employed.  Not that merchants that get information security cannot be breached, but the likelihood is significantly lower than merchants that do not get information security.

Merchants would go through the PCI DSS assessment process, clean up their act and ensure they are compliant and then they would only have to go back through the process if they were breached.  As a best practice, merchants could chose to periodically assess themselves after significant changes to their cardholder data environments to make sure no new security issues had been created or at annual intervals of say three to five years.

In the event that a merchant were breached, the PCI assessment process would be required annually for the next three years or until all of the card brands involved agreed to drop the reporting requirement, whichever comes first.  For Level 1 merchants, they would go through the Report On Compliance (ROC) process performed by a QSA or an ISA.  For all other merchant levels, they could use the appropriate self-assessment questionnaire (SAQ) but that SAQ would have to be reviewed and signed off by a QSA.

For high risk organizations that process, store or transmit large volumes of cardholder data such as processors or service providers that do transaction reporting, statement rendering or other similar services, they would still have to go through the ROC or SAQ D as they do today based on the levels defined by the card brands.

For service providers such as managed security service providers (MSSP) or cloud service providers (CSP), they would be required to go through an annual SAQ D, at a minimum, or a ROC, if they desired, for all services that are required to be PCI compliant.  The ROC would have to be prepared by a QSA or ISA and the SAQ D would have to be reviewed and signed off by a QSA.

As with merchants, if a service provider suffers a breach, all bets are off and they must do a ROC by a QSA or ISA for the next three years or until the card brands tell you to stop.

Visa and MasterCard currently maintain lists of PCI compliant service providers.  Service providers pay to be listed on those lists and the qualifications to get on those lists would also not change.

Regardless of whether an organization is a merchant or service provider, the quarterly external and internal vulnerability scanning and annual external and internal penetration testing requirements would remain the same.  Merchants would be required to file their results with the merchants’ acquiring bank or processor(s).  For service providers, their scanning and penetration testing results would be filed with the relevant card brands.  The scanning and penetration testing just help to keep everyone honest in their efforts to maintain their security.

I have to say, it sounds like a rational process to me if you accept the original premise that organizations will either do what it takes to be secure or will not.  Thoughts?

Advertisements

0 Responses to “What If?”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


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

February 2013
M T W T F S S
« Jan   Mar »
 123
45678910
11121314151617
18192021222324
25262728  

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

Join 1,854 other followers


%d bloggers like this: