As promised, I finished my PCI usefulness post. It can be found on the Shift4 4titude site:
As the title suggests, it is not a glowing review of PCI, or more specifically PCS DSS compliance. Anyway, I don't want to give away too much here. Enjoy.
Showing posts with label compliance. Show all posts
Showing posts with label compliance. Show all posts
Thursday, May 24, 2012
Monday, October 17, 2011
Is PCI Even Legal?
Back in September 2008 I put myself on PCI SSC's dung list as well as a separate entry on Bob Russo's personal ignore list with my post "PCI SSC Show Their True Colors -- Regulate for Profit". Recently I found an interesting post on Magtek's website: Fraud Mythology in the Payment World. It details a speech by Magtek CEO Mimi Hart where she rips into PCI, calling it "one of the more dangerous 'false gods' in payments." Now finally I have company on the dung lists! I have one small criticism about her speech though, every false GOD is dangerous so "dangerous" in that sentence is redundant. ;-)
Within the speech, Mimi Hart states "PCI has rapidly become a self-perpetuating, self-aggrandizing, profit-motivated authority", this got me thinking, is PCI even legal? Antitrust laws prevent the card brands from getting together in a room to set rates or make common rules for members, merchants, and customers. But before I go further, let me give a brief history lesson...
In the early days, prior to cardholder data security (pre-9/11/2001), the card brands, for the most part, relied on trust that cardholder data was being securely stored and properly used by merchants and applications. Sure, there was fine print in merchant agreements and various unpublished rules stating that merchants must do this or don't do that, but for the most part, there was no mechanism to enforce these hidden rules and fine print. After 9/11, the government decided payments needed better security and told the card brands to get it under control or they would step in.
Each of the card brands rapidly scrambled to create their own set of security mandates for merchants and vendors to follow. Visa had CISP, MasterCard had SDP, American Express had DSOP, Discover had DISC, and JCB had "security standards" (hmm, very creative!). While there were many common and compatible requirements, there were many that were unique to each, and worse, there were a few mandates that contradicted or deviated from mandates of other brands. In all this turmoil, PCI SSC was formed to unite all the security mandates and create one ring to control them all.
Ok, back to my question -- Is PCI legal?
Per the PCI SSC website: "The Council's five founding global payment brands -- American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. -- have agreed to incorporate the PCI DSS as the technical requirements of each of their data security compliance programs." Then a little further down on the same page, "All five payment brands share equally in the Council's governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organization."
I'm not a lawyer but to me this seems to imply that while PCI SSC is a separate organization, it is controlled by a round table of the five card brands. And because this is a "for profit" organization, this seems to have antitrust implications that may threaten PCI SSC's legal legitimacy.
PCI SSC was created as a way for the card brands to conspire to create a common set of security mandates without breaking antitrust laws. The problem is, PCI SSC is setup as a "for profit" limited liability corporation controlled by the card brands. If this was setup as a non-profit organization (as I assumed it was because of the .org domain name - silly me, another future rant) and a true standards committee like ANSI or ISO, I feel there would not be an issue. But as a "for profit" organization under the direct control of the card brands, there seems to be an issue here.
My recommendation: restructure as a non-profit organization, make the books public, and become a real open standards board eliminating the antitrust concerns.
If any antitrust attorney happens to read this, I would love to get your take on this question. Until next time...
P.S. For another take on the same speech, see the post in StorefrontBacktalk: Federal Reserve Listens to Security Vendor CEO Rip into PCI
P.S.S. Mimi, welcome to the list!
Within the speech, Mimi Hart states "PCI has rapidly become a self-perpetuating, self-aggrandizing, profit-motivated authority", this got me thinking, is PCI even legal? Antitrust laws prevent the card brands from getting together in a room to set rates or make common rules for members, merchants, and customers. But before I go further, let me give a brief history lesson...
In the early days, prior to cardholder data security (pre-9/11/2001), the card brands, for the most part, relied on trust that cardholder data was being securely stored and properly used by merchants and applications. Sure, there was fine print in merchant agreements and various unpublished rules stating that merchants must do this or don't do that, but for the most part, there was no mechanism to enforce these hidden rules and fine print. After 9/11, the government decided payments needed better security and told the card brands to get it under control or they would step in.
Each of the card brands rapidly scrambled to create their own set of security mandates for merchants and vendors to follow. Visa had CISP, MasterCard had SDP, American Express had DSOP, Discover had DISC, and JCB had "security standards" (hmm, very creative!). While there were many common and compatible requirements, there were many that were unique to each, and worse, there were a few mandates that contradicted or deviated from mandates of other brands. In all this turmoil, PCI SSC was formed to unite all the security mandates and create one ring to control them all.
Ok, back to my question -- Is PCI legal?
Per the PCI SSC website: "The Council's five founding global payment brands -- American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. -- have agreed to incorporate the PCI DSS as the technical requirements of each of their data security compliance programs." Then a little further down on the same page, "All five payment brands share equally in the Council's governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organization."
I'm not a lawyer but to me this seems to imply that while PCI SSC is a separate organization, it is controlled by a round table of the five card brands. And because this is a "for profit" organization, this seems to have antitrust implications that may threaten PCI SSC's legal legitimacy.
PCI SSC was created as a way for the card brands to conspire to create a common set of security mandates without breaking antitrust laws. The problem is, PCI SSC is setup as a "for profit" limited liability corporation controlled by the card brands. If this was setup as a non-profit organization (as I assumed it was because of the .org domain name - silly me, another future rant) and a true standards committee like ANSI or ISO, I feel there would not be an issue. But as a "for profit" organization under the direct control of the card brands, there seems to be an issue here.
My recommendation: restructure as a non-profit organization, make the books public, and become a real open standards board eliminating the antitrust concerns.
If any antitrust attorney happens to read this, I would love to get your take on this question. Until next time...
P.S. For another take on the same speech, see the post in StorefrontBacktalk: Federal Reserve Listens to Security Vendor CEO Rip into PCI
P.S.S. Mimi, welcome to the list!
Wednesday, August 24, 2011
Tokenization, the Newest Horse - err, Camel - in the Stable
As the old saying goes, "a camel is a horse designed by a committee." This saying perfectly describes the recently published PCI DSS Tokenization Guidelines from the PCI SSC. While the original intent of the document was a noble one, the final version fell way short.
The problem with having multiple blogs is to post onto multiple blogs. To avoid content duplication, please go here to read my post: http://blog.shift4.com/2011/08/tokenization-the-newest-horse-err-camel-in-the-stable.html
The problem with having multiple blogs is to post onto multiple blogs. To avoid content duplication, please go here to read my post: http://blog.shift4.com/2011/08/tokenization-the-newest-horse-err-camel-in-the-stable.html
Wednesday, May 4, 2011
Some Recent PCI Results
I just read a report on a PCI survey quoting some PCI statistics: PCI DSS compliance generates results. According to a recent survey performed by Imperva and the Ponemon Institute, businesses tend to perceive PCI compliance as something that does not have a positive impact on their security systems. However, the survey's results indicate companies that maintain PCI-compliant systems are significantly more secure than their non-compliant counterparts.
While I think PCI is a good thing because in a round about way it forces merchants to recognize security, I question statistics like this -- particularly the first number quoted: "...64 percent of PCI compliant respondents did not experience a data breach involving credit card data during the past two years."
In the past Visa has stated "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." Based on this statement I question whether or not the 36 percent of the PCI compliant respondents that were breached were "PCI compliant?" A catch-22. The report should have said 100% of PCI compliant respondents were not breached vs. some percentage of the non-compliant respondents were breached.
Nit-picky I know, but as my blog byline states, random thoughts.
While I think PCI is a good thing because in a round about way it forces merchants to recognize security, I question statistics like this -- particularly the first number quoted: "...64 percent of PCI compliant respondents did not experience a data breach involving credit card data during the past two years."
In the past Visa has stated "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." Based on this statement I question whether or not the 36 percent of the PCI compliant respondents that were breached were "PCI compliant?" A catch-22. The report should have said 100% of PCI compliant respondents were not breached vs. some percentage of the non-compliant respondents were breached.
Nit-picky I know, but as my blog byline states, random thoughts.
Wednesday, February 9, 2011
Forced Password Changes - good or bad?
For years now there has been a debate in the security community as to whether or not users should be forced to change password at regular intervals and if so, how often. On one side there is the argument that changing passwords frequently makes it harder for hackers to acquire a users password and limits the exposure if a hacker were to acquire a user's password. On the other side you have the argument that forcing users to change password increases the chances for forgotten passwords and more dangerous, the chance that users will write down passwords on paper or post-it notes stuck to their monitor or under their keyboard.
I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.
A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:
The 2005 OWASP best practice included the following:
The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:
But, these notes appear to have limitations, in the case of PCI DSS:
So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.
I welcome your thoughts.
I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.
A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:
“PCI DSS 8.5.9 Change user passwords at least every 90 days.
- 8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.
- 8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”
The 2005 OWASP best practice included the following:
“Passwords are trivially broken and are unsuitable for high value systems. Therefore, ...
This tells me that in 2005 the OWASP people were leaning to the side of the first argument. Now, the latest 2010 OWASP states:- Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.”
“Password Guidelines...
While “frequently” is somewhat vague, I interpret this as OWASP is leaning toward the latter argument now.- Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely...”
The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:
“However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.”
But, these notes appear to have limitations, in the case of PCI DSS:
“The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published...”
and in PA-DSS:
“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”
and in PA-DSS:
“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”
So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.
I welcome your thoughts.
Wednesday, November 10, 2010
Is Disco making a comeback?
I certainly hope not. But there are a few in the payments and POS industries attempting to bring back those glory days of the 80's, when Disco the dance and disco (as in abruptly disconnected) dialup terminals were all the rage. Since my blog primarily focuses on payments and POS related tidbits, I'll leave the return of Disco, as in the dance, to social bloggers.
Let's take a quick tour in history: I remember the 80's, the days when Tranz-330 was stat-of-the-art. The Tranz-380 was the future and bankers and ISOs were giddy -- the sky was the limit, no merchant was too big. (Yes, there were other terminal manufactures at the time, but my experience is in the US marketplace and Tranz represented probably about 80% of the marketplace, quite possibly more.) Then along comes the dreaded 90's, when POS integration corrupts this terminal Utopia. Then the turn of the century when hackers start corrupting the reputation of the POS integration market. To fix this, Visa launches CISP, MasterCard launches SDP, AMEX and Discover launch their programs (sorry, I'm drawing a blank on their acronyms). A few years later, along comes PCI to combine all these programs into a single program and now you're up to date (albeit Cleft Notes of a Reader's Digest version of the payments history).
Of late I have seen POS vendors and ISO's recommending to merchants to abandon integration and install dial-up terminals -- back to the 80's. Some assume that this route removes the merchant from the burdens of PCI compliance. This could not be farther from the truth. All merchants must comply with PCI DSS if they process, transmit or store credit card data -- via terminal or otherwise. My guess is that this misassumption stems from some PCI wording that excludes stand-alone terminals from specific portions of PCI. But it never excluded the merchant from PCI.
Some argue that these devices are not susceptible to viruses, keyboard loggers, Trojans, or other malware -- I argue they are. Malware requires a CPU, an operating system, and communication ports and stand-alone CC terminals have all these requirements. So far the only thing saving these devices from the headlines is the lack of a deviant programmer with nothing better to do from writing some malware.
Enough on malware, the scariest vulnerability with this retro alternative is that most (all that I'm aware of) dial-up modem traffic from these devices to the processor is unencrypted. Insert a sniffer in the mix or update a phone number in the terminal, and the hacker has free flowing unencrypted payment information. To me, a properly secured network transmitting encrypted card information to the processor is less vulnerable to hackers than a dial-up device transmitting unencrypted card information to the same processor (and I totally ignored the other cons of returning to the 80's and using a non-integrated solution).
Let's take a quick tour in history: I remember the 80's, the days when Tranz-330 was stat-of-the-art. The Tranz-380 was the future and bankers and ISOs were giddy -- the sky was the limit, no merchant was too big. (Yes, there were other terminal manufactures at the time, but my experience is in the US marketplace and Tranz represented probably about 80% of the marketplace, quite possibly more.) Then along comes the dreaded 90's, when POS integration corrupts this terminal Utopia. Then the turn of the century when hackers start corrupting the reputation of the POS integration market. To fix this, Visa launches CISP, MasterCard launches SDP, AMEX and Discover launch their programs (sorry, I'm drawing a blank on their acronyms). A few years later, along comes PCI to combine all these programs into a single program and now you're up to date (albeit Cleft Notes of a Reader's Digest version of the payments history).
Of late I have seen POS vendors and ISO's recommending to merchants to abandon integration and install dial-up terminals -- back to the 80's. Some assume that this route removes the merchant from the burdens of PCI compliance. This could not be farther from the truth. All merchants must comply with PCI DSS if they process, transmit or store credit card data -- via terminal or otherwise. My guess is that this misassumption stems from some PCI wording that excludes stand-alone terminals from specific portions of PCI. But it never excluded the merchant from PCI.
Some argue that these devices are not susceptible to viruses, keyboard loggers, Trojans, or other malware -- I argue they are. Malware requires a CPU, an operating system, and communication ports and stand-alone CC terminals have all these requirements. So far the only thing saving these devices from the headlines is the lack of a deviant programmer with nothing better to do from writing some malware.
Enough on malware, the scariest vulnerability with this retro alternative is that most (all that I'm aware of) dial-up modem traffic from these devices to the processor is unencrypted. Insert a sniffer in the mix or update a phone number in the terminal, and the hacker has free flowing unencrypted payment information. To me, a properly secured network transmitting encrypted card information to the processor is less vulnerable to hackers than a dial-up device transmitting unencrypted card information to the same processor (and I totally ignored the other cons of returning to the 80's and using a non-integrated solution).
Thursday, July 29, 2010
Au Contraire - Latest Gotcha from PCI SSC
Several month back many forums and blogs were discussing the (at that time) up and coming July 2010 sunset of Windows 2000. Many of these discussions included other already sunsetted operating systems. There were some heated debates over whether or not proper lock-down and compensating controls could keep a merchant compliant. Most of these discussions were settled by a posting in the PCI SCC FAQs:
Fast forward to today. Now, for many merchants and vendors, comes the first Windows 2000 post sunset scan from a prominent ASV - FAIL. Reason given: One or more scanned servers determined to be running Windows 2000. Upon referring this prominent ASV to the above FAQ on the PCI DSS site, they refer to the Technical and Operational Requirements for Approved Scanning Vendors (ASVs) on the same PCI DSS site:
The FAQ that many merchants and vendors use takes a risk assessment perspective whereas the Operating Requirements for ASVs takes a MUCH harsher authoritarian perspective -- "FAILED!" It's no wonder there is still so much confusion about PCI even after years educating the masses about PCI; people are still just as confused and pulling their hair out. I sure hope PCI SSC irons this one out quick.
An interesting side note is the wording of the Operating Requirements for ASVs: "Obsolete software may expose the infrastructure to a security-related vulnerability," yet PCI has deemed it non-compliant -- so is it vulnerable or not? If not, why is it not compliant? But this is straining at gnats -- the bigger issue is assuring people that obsolete O/Ss are not necessarily out-of-compliance while telling ASVs that obsolete O/Ss must be deemed out-of-compliance.
If you read any of my previous posts, I always harp on lowering your risk profile by eliminating card holder data from your environment. This emphasizes my belief that if you suffer a breach of card holder data, you will be found out-of-compliance no matter how compliant you thought you were. Using this as an example, if you were using Windows 2000 (post sunset) in your payment environment and your PCI assessment was based on the PCI SSC FAQ, the ASV document would deem you out-of-compliance.
Fast forward to today. Now, for many merchants and vendors, comes the first Windows 2000 post sunset scan from a prominent ASV - FAIL. Reason given: One or more scanned servers determined to be running Windows 2000. Upon referring this prominent ASV to the above FAQ on the PCI DSS site, they refer to the Technical and Operational Requirements for Approved Scanning Vendors (ASVs) on the same PCI DSS site:
The FAQ that many merchants and vendors use takes a risk assessment perspective whereas the Operating Requirements for ASVs takes a MUCH harsher authoritarian perspective -- "FAILED!" It's no wonder there is still so much confusion about PCI even after years educating the masses about PCI; people are still just as confused and pulling their hair out. I sure hope PCI SSC irons this one out quick.
An interesting side note is the wording of the Operating Requirements for ASVs: "Obsolete software may expose the infrastructure to a security-related vulnerability," yet PCI has deemed it non-compliant -- so is it vulnerable or not? If not, why is it not compliant? But this is straining at gnats -- the bigger issue is assuring people that obsolete O/Ss are not necessarily out-of-compliance while telling ASVs that obsolete O/Ss must be deemed out-of-compliance.
If you read any of my previous posts, I always harp on lowering your risk profile by eliminating card holder data from your environment. This emphasizes my belief that if you suffer a breach of card holder data, you will be found out-of-compliance no matter how compliant you thought you were. Using this as an example, if you were using Windows 2000 (post sunset) in your payment environment and your PCI assessment was based on the PCI SSC FAQ, the ASV document would deem you out-of-compliance.
Thursday, December 10, 2009
Heartland Lawsuit Dismissed - Secure Enough
A lawsuit initiated by shareholders against Heartland Payment Systems was dismissed on Monday. The judge ruled that the plaintiffs didn't prove their case that Heartland lied about their security measures that were in place. The story can be found on the StorefrontBacktalk blog "Heartland Lawsuit Dismissed, 'Insufficient Evidence' Of Weak Security."
There is a very interesting quote by the judge on the third page of this article: "The fact that a company has suffered a security breach does not demonstrate that the company did not ‘place significant emphasis on maintaining a high level of security.’ It is equally plausible that Heartland did place a high emphasis on security but that the Company’s security systems were nonetheless overcome..." Juxtapose this statement to comments from Adrian Phillips, Visa International’s Deputy Chief Enterprise Risk Officer and Regional Head of Risk for North America: "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." I go further in stating that when push comes to shove, in one way or another, all breaches will be found to be compliance failures. Not because companies are ignoring PCI, but because the fact that PCI is so all-encompassing that it's impossible to be in compliance 100% of the time. Hackers are like terrorist in the fact that hackers only need to be successful one time whereas merchants need to be secure 100% of the time.
The reason I found this interesting is that it appears that the judge in this case is distinguishing between security and compliance, and rightfully so. I think "best effort" is what is missing with PCI, at least in terms of compliance. There should be some "best effort" allowances otherwise some unscrupulous stakeholders in the industry will view PCI as nothing more than a revenue generation scheme upon a breach (a breach, cool, free money!). Unfortunately, I think there are some in the industry already treating breaches this way.
Now that there is precedence separating security from compliance, will this change the landscape? Or will it just change the wording of the plaintiff's complaints; instead of "did not do all they could to be secure," you might see "did not do all they could to be compliant."
There is a very interesting quote by the judge on the third page of this article: "The fact that a company has suffered a security breach does not demonstrate that the company did not ‘place significant emphasis on maintaining a high level of security.’ It is equally plausible that Heartland did place a high emphasis on security but that the Company’s security systems were nonetheless overcome..." Juxtapose this statement to comments from Adrian Phillips, Visa International’s Deputy Chief Enterprise Risk Officer and Regional Head of Risk for North America: "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." I go further in stating that when push comes to shove, in one way or another, all breaches will be found to be compliance failures. Not because companies are ignoring PCI, but because the fact that PCI is so all-encompassing that it's impossible to be in compliance 100% of the time. Hackers are like terrorist in the fact that hackers only need to be successful one time whereas merchants need to be secure 100% of the time.
The reason I found this interesting is that it appears that the judge in this case is distinguishing between security and compliance, and rightfully so. I think "best effort" is what is missing with PCI, at least in terms of compliance. There should be some "best effort" allowances otherwise some unscrupulous stakeholders in the industry will view PCI as nothing more than a revenue generation scheme upon a breach (a breach, cool, free money!). Unfortunately, I think there are some in the industry already treating breaches this way.
Now that there is precedence separating security from compliance, will this change the landscape? Or will it just change the wording of the plaintiff's complaints; instead of "did not do all they could to be secure," you might see "did not do all they could to be compliant."
Friday, October 5, 2007
PCI: Compliance vs. Security
Last week Shift4 Corporation hosted the 2007 Real Security Summit. There were many sessions on various topics given by speakers with a wide range of expertise. Most of the information given was anywhere from interesting to scary, and all was useful. The range of topics included security, privacy, liability and compliance -- most everything you must know if you do anything with payment or privacy information. The two of the scariest topics were the link between credit card fraud and terrorist funding and the full liability to a merchant in the event of a data breach.
While all the information I would consider valuable, one quote by Heather Mark, stands out in my mind dealing with how many merchants and vendors deal with PCI: "Teaching to the Test." I’ve known what this phrase meant ever since my high school days but have never thought of it in terms of PCI. For anyone who has never heard the term, this is when an instructor does not teach the fundamentals and concepts of a subject but instead focuses on the answers to the test. This is a side-effect of the "No Child Left Behind" program -- many teachers are teaching to the test instead of teaching the subject at hand. Teaching to the test is depriving our kids from a rich education just like teaching to the test will deprive our industry from the overall goal of PCI -- security. Both programs, No Child Left Behind and PCI, are good programs with good intentions but they fail from the same problem, what I call "the compliance factor." If you are only looking at PCI as checkboxes required for compliance, then you are missing the point of PCI.
I’ve always addressed this topic as Security through compliance vs. Compliance through security. Some might think these two terms net the same end result but in reality they do not. Think of compliance as the very minimum that must be met to be considered "secure enough." With Security through compliance, the minimal was done to make the application or data center secure. With Compliance through security, your application or data center is already secure, you allocate resources to security and privacy, you have trained your personal on security and compliance is almost a side-effect of this security.
Sure, go through the PCI requirements and make sure you have every checkbox checked but then go further. Look at your data requirements. The easiest and best way to keep sensitive data out of the hands of hackers is to not store it. Encryption will fulfill some of the PCI checkboxes but if you don’t absolutely need the data, not storing it is a more secure alternative. There are people out there that want your data. What would happen to your company’s reputation in the event of a data breach? Again, think beyond checkboxes.
Yes, privacy and security can be difficult and an ever changing target but I urge everyone to look at this as more than checkboxes. Be vigilant.
Until next time…
While all the information I would consider valuable, one quote by Heather Mark, stands out in my mind dealing with how many merchants and vendors deal with PCI: "Teaching to the Test." I’ve known what this phrase meant ever since my high school days but have never thought of it in terms of PCI. For anyone who has never heard the term, this is when an instructor does not teach the fundamentals and concepts of a subject but instead focuses on the answers to the test. This is a side-effect of the "No Child Left Behind" program -- many teachers are teaching to the test instead of teaching the subject at hand. Teaching to the test is depriving our kids from a rich education just like teaching to the test will deprive our industry from the overall goal of PCI -- security. Both programs, No Child Left Behind and PCI, are good programs with good intentions but they fail from the same problem, what I call "the compliance factor." If you are only looking at PCI as checkboxes required for compliance, then you are missing the point of PCI.
I’ve always addressed this topic as Security through compliance vs. Compliance through security. Some might think these two terms net the same end result but in reality they do not. Think of compliance as the very minimum that must be met to be considered "secure enough." With Security through compliance, the minimal was done to make the application or data center secure. With Compliance through security, your application or data center is already secure, you allocate resources to security and privacy, you have trained your personal on security and compliance is almost a side-effect of this security.
Sure, go through the PCI requirements and make sure you have every checkbox checked but then go further. Look at your data requirements. The easiest and best way to keep sensitive data out of the hands of hackers is to not store it. Encryption will fulfill some of the PCI checkboxes but if you don’t absolutely need the data, not storing it is a more secure alternative. There are people out there that want your data. What would happen to your company’s reputation in the event of a data breach? Again, think beyond checkboxes.
Yes, privacy and security can be difficult and an ever changing target but I urge everyone to look at this as more than checkboxes. Be vigilant.
Until next time…
Subscribe to:
Posts (Atom)