Posts Tagged ‘PCI PED

22
Dec
10

The Harsh Reality Of Security

Chris Skinner has a blog entry that asks the question, “Why does the card securities council not care about card security?”  What concerns me is the title of the article as it again implies that the PCI standards do nothing to secure cardholder data.  As a result, I thought I would take a shot at answering this question.

Mr. Skinner points to a number of technologies that he feels the PCI SSC is ignoring as potential solutions to securing cardholder data.  These solutions include tokenization, end-to-end encryption (E2EE) and Chip & PIN (EMV).  I recently posted a blog entry on all of these technologies, so I will not go into all of these here.  The bottom line on all of these is that, individually, they do not solve the security problems we face.  However, used in conjunction, they will create a much more formidable barrier to breaches.  I can tell you that the Council is not ignoring these technologies; they are only doing proper research to ensure that whatever guidance they issue is not flawed resulting in a recall or wholesale rewriting of a standard.  Want to lose credibility?  Issue a standard that you have to later heavily modify or replace.  Do I have to remind everyone about Wired Equivalent Privacy (WEP)?

Then we have the dynamics of the card brands.  Just because Visa writes a whitepaper on some technology does not mean that the other four card brands have bought into Visa’s analysis.  Visa may be the 800 pound gorilla of the card brands, but as anyone in business knows, the 800 pound gorilla does not always get its way regardless of how boisterous or how much chest pounding it may do.  A prime example of this was in the late 1970s when IBM (then the 800 pound technology gorilla) tried to force System Network Architecture (SNA) down the International Organization for Standardization’s throat as the Open Systems Interconnect (OSI) model.  What happened was that the rest of the technology companies in the world banded together and created the OSI seven-layer model that we have today.  While it has a lot in common with SNA, it also has numerous differences.  The bottom line is that there are certain dynamics between the card brands that will preclude the Council from always following Visa’s lead, regardless of whether Visa’s analysis is right.

How about the cost of any change?  Merchants do not live on thick margins.  Most are lucky to retain 1% to 4% of total sales as their profit margin.  If you are Wal-Mart or Target, margins can be huge numerically, but still not enough to fund the kind of wholesale changes Mr. Skinner is suggesting.  Unfortunately, most merchants are nowhere near the size of Wal-Mart, so they need to be even more judicial with their expenditures.  As a result, any change that requires a significant investment is going to be tough for any merchant to swallow and will take time to get rolled out.  After all, we are in the midst of a recession, so there is even higher sensitivity to expenditures that do not enhance the bottom line.

But for a number of merchants, the cost is not so much theirs to bear as much as it is their merchant bank’s cost.  That is because a lot of merchant banks provide the entire cardholder processing environment to their merchants.  As a result, the bank will have to absorb the cost and possibly increase fees should new terminals or software be necessary.  Banks are not necessarily doing well either, so they too are avoiding any expenditures that are not going to positively influence the bottom line.  Since security is an intangible, banks are going to be very reluctant to spend on cardholder infrastructure that does not drive up revenue.  After all, in the United States and United Kingdom, the banks were bailed out by the government and are now being watched very closely by the various regulators and the regulators are holding the purse strings.  Unless the regulators come on board, there will be no expenditure on what they will consider a frivolous expense on new terminals or software.

All of these parties are intimately involved in the PCI Security Standards Council as stakeholders.  All of the card brands and a number of larger financial institutions are on the Council’s board and various work groups.  Given the economic environment and the predisposition of these parties, is it any wonder why the Council appears to not be moving forward?

Not to mention that the changes Mr. Skinner is suggesting do not eliminate the problem of security breaches, they just shift the risks.  Granted the risks get reduced, but by how much is anyone’s guess.  But in the end, there are still going to be risks.  As I always like to remind people, security is not perfect.  Yet that seems to be what the card brands and Council seem to want people to believe.  That if everyone followed the PCI standards, breaches would not occur and that is simply not true.  Breaches would still occur, they just would not necessarily occur every week releasing thousands or millions of accounts.  It would be more like a release every month of tens or hundreds of accounts.

I too would like to live in a perfect world.  But the real world is always far from perfect.  Decisions get made only when the wheel is so squeaky that it needs to be replaced.  We can rant and rave all we want, but we will only get action when we can either show (i) a measurable business benefit, such as an increase in profit or improved efficiency, or (ii) someone else is doing it and they now have a competitive advantage.  Unfortunately, I see neither of these conditions satisfied at this time nor any time in the near future.  As long as the status quo remains, no one is going to move.

In the end, the PCI SSC does care about security.  It is the politics that slow things down and those politics are not going to go away any time soon.  That is the harsh reality of business and security.

UPDATE: Forrester Research has published a great white paper titled ‘How To Market Security To Gain Influence And Secure Budget’ that explains how to avoid the common mistakes that most security people commit and, as a result, why security professionals do not get the resources that they need to get the job done.

26
Jul
10

Advice To Merchants

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while.  That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can.  That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.  According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems.  So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason.  If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else.  So, all merchants need to put POS solutions in place that do not store cardholder data.  You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data.  This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems.  These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks.  Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job.  These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing.  Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN.  A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur.  It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work.  However, this is where tokenization can earn its keep.  If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out.  Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place.  So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place.  I have had a few clients go down this road and PCI compliance is now a piece of cake.  Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.

18
Jul
10

An Open Letter To Acquiring Banks

Get with the program people!

The PCI standards have been around for almost four years now and you would think with all of the press that has been given the PCI standards that the key participants in the standards would be intimately knowledgeable with these standards.  However, the more and more I talk to acquiring banks, the more I am amazed that most acquiring banks still are not with the program.  It is time for all acquiring banks to get a clue about the PCI standards and their responsibilities regarding the PCI standards.

Acquiring banks have many responsibilities under the PCI standards.  The first of which is to understand and support the PCI standards.  However, it is painfully obvious from trying to work with acquiring banks that most are clueless about the PCI standards, let alone do they understand their responsibilities.  Card brands and the PCI SSC have focused on educating QSAs, merchants and service providers in the PCI standards to the detriment of educating acquiring banks.  I cannot tell you how many conversations I have had with acquiring banks where they have no idea of what their responsibilities are regarding the PCI standards let alone regarding knowledge of the PCI standards themselves.  What I dearly love are those acquiring banks that tell me that they have no responsibilities in regards to the PCI standards, that it is a merchant program.

This is not just a problem in the United States, this problem is worldwide.  This is a very big issue in Asia where acquiring banks seem to be totally clueless about the PCI standards.  It is a bit better in Europe, but because European acquiring banks have been brainwashed to believe that Chip and PIN gives them a security edge, the acquiring banks there are not aggressively promoting PCI compliance.  But at least the European acquiring banks seem to have a basic understanding of the PCI standards and some of their responsibilities.

Another responsibility of acquiring banks is to be the final arbiter between merchants or service providers and their QSAs.  According to the card brands, if a merchant or service provider is at loggerheads with their QSA over whether a PCI requirement has been met, the acquiring bank is supposed to be the final arbiter of that dispute.  Yet in the handful of instances where I have been involved in such disputes, the acquiring bank has provided limited or no assistance with the dispute.

An even bigger problem is with small merchants that are trying to decide which Self-Assessment Questionnaire (SAQ) to file.  Again, the card brands have stated that the decision regarding which SAQ to file is the responsibility of the acquiring bank and no one else.  Yet time and again, our small merchant clients contact my Firm because the acquiring bank has told them it is up to a QSA to determine the SAQ to file.

Then there is the acquiring banks’ responsibility to follow the PCI standards.  Yet time and again, I run into instances where the acquiring bank is transmitting cardholder data insecurely to or from the merchant or service provider.  The number of acquiring banks that use FTP or electronic mail for the transmittal of cardholder data is just staggering and after four years of the PCI standards existence is unacceptable.  Yet, when you bring this issue up, a lot of the acquiring banks will tell you that PCI standards are for merchants, not for them.  The other excuse I hear is that the acquiring bank is working on securing their transfer of cardholder data.  Again, after four years of the PCI standards, you are just now getting around to securing the transmission of cardholder data?  Unbelievable.

This year we started receiving calls from banks and credit unions that drive their own ATM networks that had been requested by their ATM network interconnection provider such as NYCE and Pulse to obtain a PCI Report On Compliance.  What a wakeup call.  In a number of cases, the institution was shocked that the PCI standards applied to them and questioned us extensively to confirm that they really had to go through the process.

As a QSA out in the field, these attitudes are just no longer acceptable.  The PCI program flounders in part because one of the key constituents is not on board.  It is time for the PCI SSC and the card brands to educate the acquiring banks and get them engaged.

03
Jul
10

Why The PCI Standards Exist

After another spate of articles and speeches about the PCI DSS and why it is worthless, I thought it might be a good idea to explain why the PCI standards came to exist.

In 1999, Visa USA began to work on what became the Customer Information Security Program or CISP.  The first official version of the CISP was issued in the summer of 2003 with Visa asking select merchants to comply with the CISP as soon as they could.  The original impetus for the CISP was a response to increasing chargebacks that were the result of the fraudulent use of credit card accounts.  An analysis of these chargebacks had started to paint a picture of merchant employees that were increasingly using their access to point of sale (POS) and accounting systems to obtain credit card numbers and then using those numbers to commit fraud.

As development on the CISP progressed, Visa USA also started to see increasing instances where an e-Commerce site had been compromised and the credit card information stored on the site had been taken by an attacker and then was fraudulently used.  The reason these compromises had resulted in cardholder data being exposed was that application developers had used the same software design models for e-Commerce as those that were used by traditional POS.  This resulted in cardholder data being stored in databases that faced the Internet.

A year or so after the start of Visa USA’s efforts, MasterCard International began development of the Site Data Protection (SDP) standard.  Unlike the CISP, the SDP focused specifically on the security of e-Commerce sites.  MasterCard had monitored the rising fraud rate related to the compromising of e-Commerce sites.  Like Visa USA’s analysis, MasterCard’s analysis of the problem pointed to the fact that most e-Commerce sites were storing cardholder data in databases that faced the Internet and were not very well protected from compromise.  As a result, MasterCard approached the problem with the SDP which specified a basic level of information and network security for e-Commerce Web sites.

As work progressed on the CISP and further statistics on security issues were gathered, Visa USA began to recognize that the on-line payment applications themselves were the biggest problem related to the compromising of cardholder data.  As a result, Visa USA developed the Payment Application Best Practices (PABP) standard.  The PABP was published in late 2004 with Visa USA encouraging software vendors to use it as a benchmark for securing their software.

It has been suggested that the PCI standards were only developed to minimize the losses to the card brands and banks and do nothing for merchants.  However, the PCI standards were meant to protect everyone in the transaction process.  When a breach occurs, the first thing people remember is the name of the card brand(s) involved, the second name is likely the merchant or service provider and the third name is the franchisee if that is the case.  The card brands, service providers and franchisers discovered that their reputations were highly at risk, even though it was typically the franchisee merchant that actually created the problem.  Regardless of who caused the breach, the card brands further discovered that what people really remembered from breaches were the card brands’ names and everything else was forgotten.  As a result, the card brands became determined to protect their brand names and reputations.

There was another recent suggestion that the PCI DSS was not needed because market forces would resolve the security issues inherent in the conducting of credit card transactions.  The first problem with that idea is that most merchants and service providers are unconvinced that they are responsible for securing cardholder data, even after they might have suffered a breach.  They believe that it is the card brands’ problem to secure cardholder data because the card brands are the ones that generate the cards.  Unfortunately, the security of cardholder data is mostly outside of the control of the card brands, therefore the merchants and service providers need to be responsible for securing cardholder data as well.  The second problem with that idea is that for every security “expert”, there are a corresponding number of security baselines.  No one agrees on security, because everyone’s view is from their own perspective and the threats that they see or perceive.  As a result, some organizations have very strong and strict security (e.g., banks for example), while others have only marginal security.  The problem with this approach is that security is only as good as the weakest link in the chain.  So those organizations that have weak security practices become targets against the entire process chain.  As a result, in our interconnected world, that puts those organizations with strong security at risk if they are partners to those organizations that have weak security.  As a result, the card brands recognized that a single standard baseline was needed just to provide a basis for a consistent foundation on which to build additional security.

So, that is how we got where we are today.  Hopefully with this perspective you can now understand why the standards exist and their use in providing basic, essential security for cardholder data.

11
Jun
10

PCI Feels Like Something Is Being Done To Me

The title of this post is from a quote from a research paper published by Forrester titled ‘PCI Unleashed’.  Some of the thoughts discussed by Forrester are so true; I thought I would share a few of them.  If you have an opportunity, this is a paper well worth its cost.

One of the key points of the Forrester paper is that PCI was the result of a failure in corporate governance.  Forrester correctly points out that had organizations focused on keeping cardholder data properly secured in the first place, the PCI DSS probably never would have existed.

I can confirm that corporate governance is a root cause from my own experiences.  We talk a lot to organizations that think PCI is someone else’s problem and that their organization is being singled out.  In a lot of these organizations, security has been given the short shrift and has been perpetually on the back burner.  In these organizations, senior management sees security, and IT as a whole, as a money pit that does nothing for the organization.  This is because senior management is ignorant to what IT and security brings to the table because they have hired security and IT leaders that are mice that are occasionally seen, but certainly never heard.

The card brands have never been shy about why they generated the PCI standards; it was to protect their brands.  After all, when a breach occurs, it is almost always reported by the media as, “X number of Visa/MasterCard/American Express/Discover credit cards were disclosed by ABC Company.”  The card brands are always called out first, followed by the company and, if the company is a franchise operation, sometimes the franchisee is named.  The problem is that the general public typically only remembers the card brand names, sometimes the company name, and usually never remembers the name of the franchisee.  Want proof of this, just look at how badly TJ Maxx, HomeGoods, Marshalls and the like suffered after their parent, TJX Companies, incurred one of the largest breaches in history two years ago – NOT!  In a public relations coup, TJX Companies got the media to use TJX as the name of the breached organization which protected the brand names of their actual retail outlets.  As a result, sales at their retail outlets were only slightly affected by the breach news.

Another point that Forrester brings up is that naysayers point to the fact that PCI compliant companies have been hacked, therefore the PCI standard must not be effective.  As I have argued time and again, PCI compliance is not a one time, annual thing.  Compliance requires consistent execution of all of the PCI DSS requirements in order to remain compliant.  Consistent execution is a struggle for even the most diligent organizations.  It requires constant commitment by employees and management to the importance of doing security right all of the time.  The problem is that we are all human and humans are fallible.  So lapses will occur in any organization.  This is why all security frameworks are built on the concept of overlapping controls so that should a control go out of compliance, the whole house of cards does not come down.  What differentiates a good organization from a bad organization is that a good organization does not have so many lapses at once that entire control structures fail.  If you read the reports from TrustWave and Verizon Business Services on breaches they have investigated, a significant portion of those breaches were the result of systemic failures of the control environment.

Related to the previous point is another good point made by Forrester that the PCI standards are just a baseline and that organizations must go beyond the PCI standards to be as secure as they can be.  The PCI DSS is just the ante to be in the game.  If you want to be certain, you need to go beyond what the PCI DSS requires.  Why?  Because new flaws are discovered in software or new techniques are developed that make prior security methods obsolete or no longer as effective.  As a result, your security systems must adapt or new security methods need to be developed to detect and circumvent these new threats.  The PCI standards may address these new threats in a future version, but it is your organization’s responsibility to deal with them first.  This is also why most security experts say that security is a journey, not a destination.

One point of contention I have with this report is that they state, “Companies that already have robust security policies, processes, and technology do not have difficulty with PCI.”  Having worked with a number of organizations that meet these criteria, I can attest that this is not necessarily the case.  A lot of them have very robust security policies, processes and technologies; however, the day-to-day consistent execution was haphazard at best.  Management believed that they were in pretty good shape for meeting the PCI standards.  As we pealed the onion on their security environment, it became obvious that all management was seeing was a facade of security.  Security people said all of the right things and their policies and procedures said all of the right things, but the actual execution was not even close to consistent.  As they like to say, “They talk the talk, but they do not walk the walk.”  As a result, these organizations have struggled to change ingrained cultural issues and “bad habits” that can be much tougher to deal with than implementing new policies or technologies.

Finally, the next time you hear someone say that they feel PCI standards are not fair or they are impossible to comply with, ask them if they think they can afford a breach?  The best tidbit offered by this Forrester report is their estimated cost per account of a breach.  Forrester estimates that a breach costs between $90 and $300 per account breached, excluding lawsuits and any remediation efforts.  A modest breach of say 100 accounts carries an estimated cost of $9,000 to $30,000, excluding:

  • Legal representation – you know that your organization will be sued or threatened to be sued over a breach and that will require your lawyers to go into action.  If you think lawyers are cheap, thing again, particularly when they are fighting a lot of battles;
  • Public relations – just as in politics, your organization will have to put the best face on such an incident.  If your organization does not, the media will provide that “face” without you and it likely will not be a “good face”;
  • Investigation – the card brands will require a forensic examination to be performed.  If you think lawyers are expensive, the costs related to a forensic examination will make you believe your lawyers are cheap;
  • Remediation – there will be changes required to better ensure security and some of those changes will likely have a cost associated with them.  Only the lucky get away with policy or procedural changes with a minimal cost; and
  • Loss of sales – your organization will lose customers over this lost of trust and future sales may also be affected if you did not adequately address the public relations aspect.

There are likely other events that will result from such an incident that will also cost your organization time and money.  The bottom line is that this is something your organization should avoid at all costs because, in my experience, most organizations do not survive such an incident.

28
May
10

Where Do I Find PCI Information?

This is a common question that comes up.  Where do you find all of the information on the PCI standards?

The first place to go looking is at the PCI Security Standards Council (SSC) Web site.  The PCI SSC Web site has a number of resources that you need to check out.  These include:

  • The PCI Data Security Standard (DSS), the Self-Assessment Questionnaires (SAQ), Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)
  • Frequently Asked Questions (FAQ)
  • Information Supplements
  • Locate a Qualified Security Assessor (QSA), Qualified Security Assessor Company (QSAC), Payment Application QSAC (PA-QSAC) or an Approved Scanning Vendor (ASV)
  • PCI training

The FAQ is where the PCI SSC posts all of the questions and answers about the PCI standards.  Questions can be asked by anyone accessing the Web site.  The answers come from representatives of the card brands with the PCI SSC staff collecting and publishing the card brands’ agreed to responses.  Answers to questions typically take four to six weeks to obtain an answer.  However, it is not unusual for answers to take quite a while.  For example, in the case of securing pre-authorization data, it has been almost four years and we are still waiting for a response which the PCI SSC has promised they will deliver in the coming year.

Information Supplements are white papers written by various authors (usually PCI SSC staff or the card brands) and approved by the PCI SSC and the card brands that discuss a PCI standard requirement in detail to further explain a requirement and explain how a merchant or service provider can meet the requirement.  Informational Supplements that have been published thus far include:

  • Skimming Prevention: Best Practices for Merchants
  • Wireless Guidelines
  • Requirement 6.6 (Application Code Reviews and Application Firewalls)
  • Requirement 11.3 (Penetration Testing)

The PCI SSC has indicated that more Information Supplements are going to be issued in the future instead of updates to the standards.

Locating a QSAC, PA-QSAC and ASV is provided by a PDF list for each type.  Individual QSAs can be looked up by their name so that you can confirm they are in fact QSAs.  The PCI SSC recently sent out a clarification in one of their newsletters to QSAs discussing the fact that once a QSA leaves their QSAC; they need to join another QSAC who applies to have them transferred by the PCI SSC to retain their QSA certification.  If they do not join another QSAC, they are no longer allowed to use the QSA designation.  So, it is important to confirm that the people and firms you are talking with are in fact QSAs and QSACs.

If a QSAC is listed as in remediation does not mean that the QSAC and their QSAs cannot continue to perform PCI assessments, this just means that the QSAC was found deficient in meeting the documentation and reporting standards of the PCI SSC.  Even though the PCI SSC issued a well written release on the meaning of remediation, a number of unscrupulous QSAs are telling prospects that because a QSAC is in remediation, it cannot perform PCI assessments.  This is patently false and any QSA that makes such a statement should be reported to the PCI SSC for telling such a falsehood.

Of course the most obvious thing provided by the PCI SSC’s Web site is the standards themselves.  Unfortunately, without the benefit of the PCI SSC’s training program, interpreting the various PCI standards can be difficult, if not impossible.  However, there are a number of independent resources for people to use to get interpretations of the PCI standards.  One that I have actively participated in is the Society of Payment Security Professionals (SPSP) Forum.  There is also the PCI Knowledge Base that has a large contingent of QSAs and other experts that can provide guidance regarding the PCI standards.  There are also forums provided through Yahoo and LinkedIn as well as other similar services, but I am not as well versed in the accuracy of the information provided through those venues so I cannot recommend them.

So the next time you are looking for information regarding PCI, here are some resources you can use.

08
Apr
09

PCI Compliance Is Not Enough

In my opinion, Representative Yvette Clarke (D-NY) last week proved President Abraham Lincoln’s statement, “Better to keep one’s mouth shut and keep people guessing, than to open it and remove all doubt.”

Representative Clarke stated, “I do want to dispel the myth once and for all that PCI compliance is enough to keep a company secure.  It is not, and the credit card companies acknowledge that.”  I do not know where Representative Clarke’s aides have been, but I have not seen anything from any of the card brands that would indicate that they have acknowledged that PCI compliance is not enough.  To the contrary, based on the quotes from the card brands that I have seen the card brands and in particular, Visa USA believes that PCI compliance is the ‘Holy Grail’ of security.

Do not get me wrong.  Are there ways that the PCI standards can be improved?  No doubt about it.  However, the sort of standard that Representative Clarke is suggesting in her statements would not be workable, let alone implementable.  Moreover, if Michael Jones, the CIO of Michael’s Stores, thinks that the current PCI standards are overly complex, the standards that Representative Clarke is suggesting would probably take him completely over the edge.

Representative Clarke went on further to point to Chip and PIN as a salvation for security.  Again, Representative Clarke must not have the ‘best and brightest’ on her staff or they would have seen from a Google search that there are significant security issues related to Chip and PIN.  So while Chip and PIN could be a better solution, it is not the perfect solution Representative Clarke seeks.

PCI compliance is enough IF (and that is a big ‘IF’) a company is consistently diligent in applying the PCI standards day in and day out.  It is not the standard that is the problem; it is the consistent application of the standard every day that is the problem.  Why?  Because humans are involved and humans are fallible.

Representative Clarke misses the fact that there is a human element involved in all security and it is that human element that typically is the biggest problem.  Whether it is the programmer writing the firewall or application software, the person that erroneously configures a security device or a human being that misses or mistakenly responds to a security alert, it is those sorts of human errors that result in breaches.  Therefore, unless Representative Clarke intends to outlaw human beings from the practice of information security, she better own up to the problem and admit that breaches will occur regardless of her outrage.  What proper security will do is reduce the number and frequency of breaches, but it will never eliminate them.

What Representative Clarke also misses is that there is no such thing as perfect security.  If there were, banks would not be robbed as often as they are robbed.  Even with all of the sophisticated security in a bank, they are still robbed and fairly often, I might add.  The only reason bank robbers eventually are caught is that they get sloppy – they are human after all!

At the end of the day, even if a company invests in all of the security appliances, policies, standards, procedures and techniques, there is still a risk (small as it may be) that they could be breached.  In addition, no matter how diligent an organization is, they all get sloppy at certain tasks over time creating even more risk.  It is that risk that the dedicated attackers use to breach systems.  Because a dedicated attacker will do whatever it takes to create a breach no matter what barriers are put in their way.




Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

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

October 2014
M T W T F S S
« Sep    
 12345
6789101112
13141516171819
20212223242526
2728293031  

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

Join 968 other followers


Follow

Get every new post delivered to your Inbox.

Join 968 other followers