Is Security Broken? And How I Propose To Fix It

Dennis Fisher has a blog post entitled ‘The Security Game Needs To Change’ out on ThreatPost.  The premise of this post is that the practice of securing networks and applications is broken.  Then we have the CEO of RSA, Art Caviello, saying that security models are inadequate.

While I think Mr. Fischer and Mr. Caviello are correct in stating that security is broken, I think they have missed the point as to why it is broken and how to fix it.  Mr. Fisher quotes Jeff Jones of Microsoft’s Trustworthy Computing Initiative for his suggested solution.  Mr. Jones states, “What we really need is to get more smart people thinking about the problems we haven’t solved yet.”  Really?  Anyone remember the episode of ‘The Big Bang Theory’ where the guys try to help Penny build the multimedia system from IKEA?  Talk about available brain power.  Yet rather than assist Penny with the assembly of the unit, they go off on a tangent developing an over engineered and sophisticated solution for a non-existent problem.

That is where I believe information security is at today.  We seem to be like Don Quixote, off on tangents such as understanding the motivations of the enemy, anticipating the next attack and other windmill tilting.  We keep trying to adapt military approaches to a problem being conducted in a very non-military way.  In a true war, organizations would be investing in creating an offensive capability of cyber-armies to go into cyber-battle with the enemy.  And while there are discussions about organizations having offensive capabilities, security professionals are still in a defensive posture protecting the organization.

If we are going to fix security, then what we need is a serious paradigm shift.  If we will always be in a defensive posture, then the paradigm we should be using is the Fort Knox approach.  We focus on what information is important to our organization and go about the business of building a ‘Fort Knox’ to protect that information.  Once we begin focusing our efforts on protecting our organization’s critical information, we will find that the rest of our security tasks become much easier.  After all, Fort Knox is predicated on a defensive posture, not an offensive one.

I am sure a lot of you are asking, “So doing all of this will perfectly protect my information?”  Not even close.  As I consistently say, security is not perfect and never will be.  No matter how much we try, there will always be people involved somewhere in the process and people are fallible.  The concept is that if an incident does occur, you will recognize it quickly, stop it in its tracks and minimize its impact.  Will you lose information?  Hopefully not, but any information loss will not be significant because you recognized the problem almost immediately and dealt with it.

If you are frustrated with security, change your approach.  Until you do that, you will continue to have a broken security model.

A Reason Why The PCI Standards Get No Respect

Call it the “Rodney Dangerfield Effect.”  Conflicts of interest seem to pervade the PCI compliance process and it is something the PCI SSC and the card brands need to clear up before their precious standards get even more bloodied in the media.

I have run across another processor that dictates the use of a particular QSAC.  Now do not get me wrong, I am a capitalist and interested in making money just like the other guy.  But I have to say that I am not a shark like some of my competitors.  I know this post will sound like someone bemoaning sour grapes but, in my opinion, this situation just makes the whole PCI compliance process look like a worthless sham.

What prompts this post is a call with one of our clients that we have performed PCI assessments for years, even before the PCI SSC existed.  They are implementing a new point of sale (POS) terminal that requires them to use a different credit card transaction processor because their existing processor is not yet certified to process transactions from this new terminal.  Fair enough.

The new terminal is a test installation to see if the service should be expanded to all of our client’s locations.  Since the terminal will only generate a couple of thousand transactions in the coming year, the new processor has identified our client as a Level 4 merchant and is treating them accordingly.  In reviewing the processor’s contract, our client found that the contract dictates that they use a specific QSAC to “assist” them in filling out their PCI Self-Assessment Questionnaire (SAQ) A.  Knowing the SAQ A, our client cannot figure out what a QSAC would do to assist, but it is in the processor’s contract.

Our client’s first question was, “Since when does a processor have the right to force us to use a particular QSA?”  We explained that we have been told that while the PCI SSC and the card brands allow processors to have rules that go above and beyond the PCI SSC’s and card brand’s requirements.  While I understand that the processor is likely trying to ensure that their Level 4 merchants are not just checking the ‘Yes’ box on their SAQs, forcing the use of a particular QSAC seems a bit questionable.  Particularly when we have been told that some QSACs are giving processors payments for all of the customers they refer.

I have written about this issue before with processors charging fees to merchants for the filing of their SAQs.  There is also the scam of forcing merchants to use a specific PCI Approved Scanning Vendor (ASV) to scan the merchant’s networks even when the merchant does not have an ecommerce presence or outsources their ecommerce to a third party that already provides their ecommerce customers ASV reports.  This is just one more questionable requirement that processors demand that makes merchants and the media think PCI is a scam.

Their next question was, “Since you already do our ROC, can’t we just submit that to our new processor?”  You can do that, but you need the new processor’s approval as they do not have to accept our work.  What is the likelihood that the new processor will accept our client’s ROC?  No idea and I am anxious to hear what our client tells us in that regard.

The problem here is that the processor in question and the QSAC have numerous connections that give a distinct impression of conflicts of interest.  First, the QSAC in question runs the processor’s Level 4 merchant compliance program.  That program dictates that the QSAC perform some sort of assessment process in order for any of the processor’s Level 4 merchants to create and submit their SAQ.

The justification the processor gave our client was that the PCI SSC requires this action.  Last I checked, the PCI SSC and the card brands did not require a QSA to fill out an SAQ.  MasterCard has a deadline of June 30, 2012 for Level 2 merchants to have either an ISA fill out their SAQ or have a QSA conduct a PCI ROC.  Visa in Canada also requires that a QSA sign off on all SAQs.  But those are the only SAQ rules involving QSAs that I am aware.

Next, the QSAC and the processor have swapped various personnel over the years.  As a result, there is an appearance that the two are essentially one in the same given that the QSAC runs the processor’s compliance program and the processor dictates that their merchants use the QSAC for PCI assessments.  I know that people move between organizations in the same industry all the time, but the number of people that have gone between these two would seem to be higher than expected.

I guess since I am an employee of a public accounting firm in the United States, I have greater sensitivity to conflicts of interest than most.  The American Institute of Certified Public Accountants (AICPA) has very specific rules in regards to conflicts of interest.  We have an entire department dedicated to ensuring that we avoid conflicts of interest.  As a result, we regularly look at the services provided to our clients and ensure that we are not in conflict or even give an appearance of a conflict of interest.

Now I am not suggesting that the PCI SSC and card brands go to the levels that the AICPA requires.  But let us face it, it is the Wild West out there and some of the QSACs do not care what conflicts they may have and how it might hurt the PCI compliance processes.  The PCI SSC only requires its assessors document the services they provide to the organizations they assess in their assessment reports.  While that offers a certain amount of transparency, when you read some of these ROCs, it becomes painfully obvious that some QSACs are assessing their own security services.  In some cases, the organization being assessed has outsourced almost everything related to their PCI compliance to the QSAC doing their assessment.  What do you think the likelihood is that those services will be assessed as not compliant if there are compliance issues?  One would assume it will be very unlikely.

But it can get even worse.  A certain QSAC operates one of the card brand’s merchant PCI compliance program.  Merchants submit their Attestations of Compliance (AOC) and Reports On Compliance (ROC) to this card brand through the QSAC which manages the process.  Does this QSAC inform their clients that accept this card brand’s cards of this fact?  Not that I have ever been told by any prospects.  Does the QSAC list the management of the card brand’s merchant program on their ROCs?  Not that I have seen and I have seen a number of their ROCs for merchants that accept the card brand’s cards and I have never seen the program listed.  Does the QSAC submit their ROCs to the program that they manage?  They must as the ROCs I have seen are from merchants that accept the card brand’s cards.  Is this a conflict of interest?  One would think, but this is how things operate today.

The bottom line is that in this age of openness and transparency, it is these sorts of relationships and actions that give a very bad impression to the outside world.  The PCI SSC and the card brands need to enhance their rules for QSACs that define conflicts of interest.  Until this is done, the PCI standards will continue to be ridiculed and viewed as pointless.

Is It ‘WHO’ Or ‘WHAT’ That Is Important?

There is a very active discussion going on in security circles about understanding adversaries and how that impacts security strategy.  I have taken a contrarian position in this argument and have stated that, in the scheme of things, I do not believe that you need to waste time understanding your enemy.  What I think matters most is what needs to be secured and how it needs to be secured.  This post is to discuss my rationale for this approach and relies on my prior post regarding the Fort Knox approach to security.

Sun Tzu famously said it was important to, “Keep your friends close and your enemies closer.”  The biggest difference with cyber-attacks is that the enemy are true mercenaries in that they come together because of an interest in a target, an interest in achieving their own particular goal, such as proving they are the best hacker or social engineer, or just because.  As a result, when your enemies can number in the hundreds or even thousands and have their own potentially unique motives for why they are attacking, it is near to impossible to do an analysis of the enemy, such as Sun Tzu suggests, that provides you with any sort of significant defensive advantage.

But what about advanced persistent threat (APT) attacks?  There is usually a common actor in APT, either a competitor, organized crime or a government.  However these sponsors usually hire the technical “muscle” for the actual attack.  The backer of the APT attack provides these mercenaries with a list of information they wish to be retrieved from the target organization(s).  So while APT can provide you with a traditional enemy, that enemy is obscured by the mercenaries actually conducting the attack.  Again, an analysis of the enemy provides limited to no advantage in your defense because you only see the mercenaries, not the sponsor.

But I think the biggest nail in the coffin for enemy analysis is related to attack strategies.  When reports from Verizon, Trustwave and other forensic examination firms consistently report that the same basic attack strategies are successful, it does not matter who the enemy is and why they are attacking when anyone from a neophyte to expert can break into your systems because of the same stupid mistakes or human errors.  By the time you have the enemy analysis done, your organization’s information is long gone.

In my opinion, ‘WHAT’ is more important in that organizations understand ‘WHAT’ information they need to protect and then go about appropriately protecting it.  If that sounds familiar, it should because that was the basis of my Fort Knox post.  If you think about it, a Fort Knox strategy does not worry about ‘WHO’ is trying to get the gold, it is all about protecting the gold regardless of ‘WHO’.

The bottom line is that in a cyber-attack, ‘WHO’ is attacking you is irrelevant.  You do not need to waste your time figuring out ‘WHO’ the attacker is and what are their motives.  It is all about your information that they wish to obtain.  So stop wasting time on enemy analysis and start properly protecting your organization’s critical, sensitive information.  I think you will find that the Fort Knox strategy will make your security efforts much more easy to implement and maintain.

UPDATE: In a brief moment of clarity on my part, I realized after making this post that the Fort Knox security approach is just another way of looking at the ‘Zero Trust’ security model that was proposed by John Kindervag of Forrester a while back.  See my earlier posts on the Zero Trust security approach for more information.

Zero Trust Security – The Cultural Discussion

Zero Trust Security – The Technical Discussion

Another Year, Another QSA Re-Certification

It is that time of the year when I have to go through the PCI SSC’s Qualified Security Assessor (QSA) re-certification process.

To add to the re-certification process this year, I have been sick for the last two months with a cold that turned into a nasty case of bronchitis along with laryngitis that then caused a severe case of sinusitis.  I just could not catch a break this Spring.  The good news is that I am finally on the mend and should be back to normal in another couple of weeks.

However, even illness does not get you out of the QSA re-certification process.  So, I put it off as long as I could and took the examination this morning.

As I expected, there was not a lot of new material in this year’s QSA update.  The biggest focus of this year’s training seemed to be:

• The interrelationship of the various PCI standards;
• Roles and responsibilities of QSAs, ASVs, merchants, service providers, acquirers, PCI SSC and the card brands;
• Scoping of the cardholder data environment and cardholder data discovery; and
• The integration of the PA-DSS with the PCI DSS.

Other than that, it was for the most part a reinforcement of the changes in the PCI DSS v2.0 to make sure that QSAs really understand the standard.

There is an interesting section on what not to write in the In Place column.  The unfortunate aspect about this section of the training was that the examples that were presented were straight out of ROCs that the PCI SSC QA program had reviewed.  Some of those responses were very difficult to read they were so bad.

There is also a discussion on network segmentation.  Unfortunately, the examples were very simple.  I wish our clients had such simplified networks.  However, because this discussion is in this year’s presentation materials indicates there are apparently still a lot of QSAs that do not understand the concept of network segmentation and what constitutes good segmentation from poor segmentation.

As I am finishing this post, I have been told I passed the QSA re-certification examination.  So I am a QSA for another year.

The Fort Knox Approach To Security

Which is easier to protect: (1) the entire United States of America or (2) Fort Knox?

I am sure you all answered Fort Knox.  Fort Knox was built to protect the stocks of gold held by the United States government.  Its security is focused on and all about how to protect the gold in its vaults.  Nothing more, nothing less, it is all about the gold.

But, if you answered Fort Knox, then why are you treating information security as an effort to protect the entire United States?  Take a look at your information security program and how it has been implemented.  Most of you are protecting everything with equal rigor.  Yet, does everything need to be protected with the same thoroughness?  Probably not and that is what makes information security such a difficult occupation.  We neglect to delineate what needs the most protection and what does not need as much or any protection.

From an information perspective, have you ever asked yourself what is your organization’s “gold?”  I have met very, very few information security professionals that can answer that seemingly very simple question.  Why?  Because for some strange reason, information security professionals never seem to analyze just what it is that they need to protect.  Yes, I see a lot of risk analyses, but that just identifies the risks to the entire organization, not the information that is at risk.

Analysis of an organization’s information and what is important seems to be driven these days by the regulation “du jour” be that PCI, HIPAA, GLBA or ISO.  A complete, regulatory independent analysis of what information is important and needs protection just never seems to be performed.  Since an analysis is not performed, organizations end up protecting the United States, not Fort Knox and the task becomes a nightmare.

So what should you be doing?  First, you need to develop an information classification standard to define your analysis.  This does not need to be some sort of NSA or CIA type of standard with many different levels.  Typically, three or four levels are all this standard needs.  Examples of information classification levels include:

• Unrestricted information is defined as information that is public knowledge or readily available to the public.  Unrestricted information may be disclosed in the normal course of conversation or other methods of communication without regard to whom the communication occurs.  Information that is considered unrestricted includes, but is not limited to, publicly available sales and marketing materials and other information regarding products and services offered, facilities open to the general public, general electronic mail addresses and general telephone numbers for voice or facsimile communication.  Internet Web sites available to all Internet users should contain only unrestricted information.
• Business need to know information is defined as information that is not readily available to the public, but can be disclosed in the normal course of conducting business once personnel have qualified that such information needs to be disclosed in order to continue transacting business.  Before releasing such information, personnel should ask themselves if the request is reasonable based on the business be conducted.  Examples of information that is considered business need to know includes, but is not limited to, employee names and direct telephone numbers, direct facsimile telephone numbers, employee electronic mail addresses, operational (i.e., non-public) facility addresses and telephone numbers, and other general or generic operational information about the organization.  Internet Web sites that require users or customers to logon can contain business need to know information.
• Confidential information is information that cannot be disclosed outside of the organization without prior written approval of management.  Confidential information includes, but is not limited to, processing volumes, service pricing, equipment configurations, vendor information (names, addresses and telephone numbers), application software used, and types and numbers of computer equipment, and other similar business and technical information.  Confidential information is never published on any Internet Web site unless written approval is obtained from Senior Management authorizing such publication.  Confidential information shall only be transmitted electronically outside of the organization if it is encrypted according to the encryption standard.  Access to confidential information requires authentication to the systems that store the confidential information whether internally or remotely.  Confidential information that is to be released to a third party requires a Non-Disclosure Agreement (NDA) being executed between the parties.
• Restricted information is information that cannot be disclosed outside of a department or work group without prior written senior management approval.  Restricted information includes, but is not limited to, customer information (names, contacts, addresses, telephone numbers, electronic mail addresses, credit card numbers, etc.), employee information (name, home address, telephone number, years of service, etc.), proprietary information (Board of Director meeting minutes, executive correspondence, financial statements, payroll information, internal cost structures, etc.) and customer proprietary information (accounts and balances, financial statements, partnership agreements, contracts, etc.).  Restricted information can never be posted on any Internet Web site.  Access to restricted information requires authentication to the systems that store restricted information and two-factor authentication if the information is available remotely.  Restricted information shall only be transmitted electronically outside of the organization if it is encrypted according to the encryption standard.  Restricted information that is to be released to a third party requires a Non-Disclosure Agreement (NDA) being executed between the parties.

Once you define what it is that you are protecting and classify it, it becomes a lot easier to develop ways of protecting it.  But the key thing to remember is that you may have more than just one Fort Knox in your environment.  You may have a PCI Fort Knox, a SOX Fort Knox and a HIPAA Fort Knox.  You may be lucky enough to leverage infrastructure and combine PCI with HIPAA, but there are no guarantees.

The one wrench in the works is that a lot of organizations use packaged solutions that make segregating the information they contain difficult, if not impossible.  So, getting your various classifications into your Fort Knox may be tricky or may require that you treat the whole system under the highest level classification.  Vendors are getting more sensitive to this situation and recent versions of their software can sometimes allow for higher security and segregation for certain data elements or whole applications.

However, until you get out and create classifications and do your analysis, you are just blindly protecting assets and probably doing a lot of work for no reason.

The Global Payments Breach

We are very early on in this breach from a publicity sense as this is breaking news.  A big thank you to Brian Krebs for bringing this breach out into the sunlight.  However, there are a couple of things that are known that are troubling.

The first troubling statement is Visa and MasterCard stating that,

“the breached credit card processor was compromised between Jan. 21, 2012 and Feb. 25, 2012.”

There are two ways you can interpret this statement; (1) they do not know when the breach actually occurred other than this data range, or (2) for 36 days the attackers were in Global Payments and Global Payments had no idea they had been breached.

Regardless of interpretation, the bottom line is that no one really knows the timeframe of the breach.  That implies that Global Payments’ logging, monitoring and review processes were not performing to PCI DSS requirements.  Had they been working per PCI DSS requirements, I could understand a couple of days of not being able to know if you were breached as Global Payments would have been researching the information.

However, if it is option (2), it really is sad when statistics get confirmed.  This means that for 36 days, Global Payments was unaware that it had been breached.  If you look at my post regarding the latest Verizon Data Breach Report, Verizon states that most breaches are not detected quickly, if at all.

My favorite quote thus far though is from Visa.

“Visa also supports advanced security layers such as encryption, tokenization and dynamic authentication through EMV chip technology to further protect sensitive account information and minimize the impact of data compromises.”

Hello!  This was a processor that was breached Visa.  All of that security mumbo-jumbo you just pushed out there is meaningless once a transaction is at a processor.  The processor has to be able to read the information otherwise they would not be a processor.  This quote is nothing but a whole lot of spin.  It would have been better to have shut up than tried to put spin on this incident.

But the bigger issue that I think the card brands are just figuring out is that when you start shrinking the scope of where cardholder data (CHD) is stored in the systems, you just make those entities that do store CHD a bigger target.  I wrote about this phenomenon twice when I discussed point-to-point encryption (P2PE) and what would happen once merchants stopped storing CHD.  Where we are ultimately headed is with large merchants, service providers, processors, issuers, financial institutions and the card brands left with CHD.  The bottom line is that these organizations that are left storing CHD will have to be on their security “A Game” 24/7/365 in order to avoid being breached.  In addition, the PCI DSS will not be enough; they will have to be practicing security well above what the PCI DSS requires.

And finally, one piece of speculation.  Avivah Litan of Gartner is reporting:

“One interesting twist again sheds light on the fact that knowledge based authentication should not be relied upon.  I heard (and this may not be factual) that the crime was perpetrated by a Central American gang that broke into the company’s system by answering the application’s knowledge based authentication questions correctly.  Looks like the hackers took over an administrative account that was not protected sufficiently.”

I would love to meet the security “rocket scientist” that thought knowledge-based authentication (KVA) was a good idea, particularly for people with the keys to the kingdom.  Want to bet they are a former employee of a KVA solution provider?

All of the recent high profile hacks of public figure email accounts and smartphones were done through KVA using information from LinkedIn, Facebook and the like and you thought it was robust enough for your administrator accounts?  If this proves to be true, I guess we know the answer to that question and we will likely know one update to the PCI DSS.

It will be interesting to see how this breach unfolds in the coming weeks.

UPDATE: Monday, April 2, 2012

News outlets are reporting the fact that Visa has removed Global Payments from Visa’s Global Registry of Service Providers.  This is standard operating procedure for Visa, however, some of the news outlets are writing their stories to appear that Visa has severed their relationship with Global Payments and nothing could be further from the truth.  Unless the forensic examination points to some glaring error such as what was found at Heartland years ago, Visa will only remove Global Payments from the registry.

Now that Global Payments is removed from the registry, they will have to go through the PCI DSS assessment process and re-file their compliance with Visa to be added back to the registry.  It is likely that this will take a bit of time as it is my understanding that the forensic examination is not yet complete.  Until that examination is complete, it will be difficult for Global Payments to address any shortcomings in their operations that they need to correct to be PCI compliant.

The forensic examination could come back with findings that Global Payments was PCI compliant at the time of the breach.  I know a lot of you are questioning how that could be.  Remember, the PCI DSS is only a baseline for security practices, not a “be all to end all” list of security practices.  As a result, Global Payments could have been PCI compliant only to find that certain security measures needed to be at a level higher than what the PCI DSS requires.  This is how changes to the PCI DSS occur.  Attackers up their game and the PCI SSC institutes changes to the PCI DSS to address those changes of the attackers.

UPDATE: Friday, May 4, 2012

News outlets this week are reporting that the Global Payments breach may have started as early as June 2011.  Originally the breach was reported to only be 30 days in duration.  Since the breach was announced, the date the breach began has been slipping further and further back from January 2012, to December 2011 and now to June 2011.  Given the history of this breach, it is likely to slip again.  The only consistent news in all of this is that the number of breached accounts continues to be reported at under 1.5 million.  However, I am concerned that if the date of the initial breach slips again, we may find that the number of accounts may also start to rise.

The other troubling thing, as the date of the breach continues to slide backwards, is the fact that this starts to imply that Global Payments was not as diligent in their monitoring as we thought.  When the breach was initially announced, I took some flack over my implying that fact as there was only a 30 day window of breached data.  However, now that we are hearing that the breach could have been going on for more than six months, I think it is safe to say that monitoring was likely not as good as it should have been.  This would also seem to imply that they likelihood that Global Systems was PCI compliant is probably low.

UPDATE: Friday, May 18, 2012

Talk about a train wreck.  Krebs On Security is reporting that the Global Payments breach started back in January 2011.  Yes, you read that right, 2011, a full year earlier than thought.  It gets better.  Brian Krebs is stating that he has spoken to one of the persons involved in the breach and has some very interesting information about the breach posted as well.  The tally now is around 7M cards have been compromised.  I have been at a client all week and they have a minimum of 100 pre-paid cards that have been affected and they suspect there will be more.

Financial Institutions – Your Time Is Coming

I have been getting a lot of inquiries lately about whether or not financial institutions are required to comply with the PCI standards.  It fascinates me how certain groups seem to think that the rules apply to everyone else but their own.  Page five of the PCI DSS states:

“PCI DSS applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data.”

I do not see any exclusion for financial institutions in that definition and the use of the term ‘all’ seems pretty inclusive to me.

A few years back we started to get panicked phone calls from financial institutions that were being pressured by the various ATM networks to prove that the financial institution’s ATM network was PCI compliant.  While most financial institutions in the United States outsource the management and networking for their ATMs to a third party, a small number of financial institutions still switch their own ATM networks.  And it was those financial institutions that switched their own ATMs that were the target of the PCI compliance initiatives of the ATM networks.  Some of those financial institutions did PCI Report On Compliance (ROC) for their ATM networks.  Some financial institutions outsourced their ATM networks.

Most financial institutions in the United States and Europe outsource their credit card processing and issuance to third parties or wholly owned subsidiaries.  As a result, the financial institution itself is typically not involved in the PCI compliance regarding the credit cards issued under their name.

Unfortunately, the same cannot be said about debit cards.  While the issuance of debit cards is typically done by a third party, in order for the debit card to work, the financial institution must store the debit card primary account number (PAN) in their banking system so that the debit card can be linked to the customer’s account.  As a result, the financial institution is storing cardholder data in their computer system(s) which means they must be PCI compliant.  And that cardholder data must securely traverse the financial institution’s network.

Another area that catches financial institutions is statement preparation.  While a lot of financial institutions outsource this as well, some have purchased software that accomplishes the combining of statement information from a variety of sources.  Unfortunately, the firms that process their credit and debit card transactions put the full PAN on their statements.  As a result, the statement prep software creates PDFs and other documents with the full PAN without the financial institution necessarily being aware of that fact.

What adds insult to injury to this situation is that most financial institutions purchase their software applications from third party development firms.  As a result, the financial institutions are at the mercy of these third parties to ensure that cardholder data is processed, stored and transmitted per the PCI standards.  To make matters even worse, with all of the regulatory changes going on in the financial institution industry over the past five years, these software firms have been focused on those regulatory changes and not PCI compliance.

The only piece of good news in all of this for financial institutions is that the card brands have not been pushing the issue of PCI compliance.  The unofficial reason that financial institutions have not been pushed on PCI compliance to this point is that, in the scheme of things, they have not been where the breaches have occurred.

With merchants and service providers finally getting their acts together on PCI compliance, the focus is going to shift to the other entities named in that earlier definition.  How soon financial institutions will start to be asked to document their PCI compliance is anyone’s guess.  But I have to bet it will start occurring over the next two to three years.  We are already hearing rumblings from some fairly large financial institutions that want to get PCI gap analyses done so that they can get started on remediation and stay ahead of the curve.

So, if you are one of those financial institutions with their head in the sand, you have been warned.  It is not a question of ‘IF’ you will need to be PCI compliant; it is a question of ‘WHEN’.  And knowing how quickly some of you move, it might behoove you to get started on your PCI compliance efforts now.

PCI DSS Compliance Certificates

In this month’s PCI SSC QSA Newsletter, the FAQ of the Month is about so called ‘PCI DSS Compliance Certificates’.  I started to hear about these a couple of years ago, but it got really big last year when I started running into processors and acquiring banks demanding them.  I had a particularly troubling conversation with a processor who demanded that we produce one for one of our clients.  When offered the PCI DSS Attestation Of Compliance (AOC), this processor acted as though we were trying to put something over on them.  When I asked him where I was supposed to get such a certificate when it does not exist on the PCI SSC Web site, he accused me of not being a QSA because all QSAs know what the certificate looks like and where to get it.

As a result, a lot of QSAs must have submitted a question regarding these certificates like I did.  Here is the PCI SSC’s response.

“In addition to the official PCI SSC reporting forms and templates, some QSA or ASV companies provide certificates, letters or other documentation as confirmation that an organization is PCI DSS compliant. The PCI SSC does not prevent QSAs or ASVs from producing this type of documentation, as it is considered an additional service which the assessor company may elect to provide and is therefore outside of the purview of the Council.  However, in accordance with the ethical requirements for QSA and ASV companies, any such certificates, letters and other documentation must be accurate and not be in any way misleading.  Additionally, these certificates, letters and other documentation should be clearly identified as supplemental materials provided by the QSA or ASV; they should not be presented as documents endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands.

The PCI SSC website contains reporting templates and forms which have been approved by all payment brands, including ROC templates, Attestations of Compliance, Self-Assessment Questionnaires, and Attestations of Scan Compliance for ASV scans. Compliance validation and reporting requirements are determined by the individual payment card brands and, irrespective of whether an organization is performing a self-assessment or has an onsite review completed by a QSA company, acceptance of a validation method outside of those listed on the Council website is ultimately up to the entity accepting the validation (that is, the acquiring bank or payment card brand). In many cases, certificates, letters or other documentation issued by QSA or ASV companies outside of the official PCI SSC templates may not be accepted by acquiring banks or payment card brands. ASVs and QSAs should encourage their clients to check with their acquirer or the payment brands directly to determine their compliance reporting requirements, including whether the submission of such certificates is acceptable.”

So all of you processors and acquiring banks that seem to think the only acceptable proof of PCI compliance is some mystical PCI DSS Compliance Certificate, stop demanding them.  They do not exist and never have existed.  The document you need for proof of PCI compliance is the Attestation Of Compliance (AOC), period.  All self-assessment questionnaires (SAQ) contain the AOC and there is a separate AOC form for those submitting a Report On Compliance (ROC).

And all of you QSAs and ASVs out there differentiating yourselves because you produce these nice, but essentially worthless, certificates, stop misinforming merchants, processors and acquiring banks by implying that QSAs and ASVs not producing such a certificate are somehow doing something wrong or worse, dishonest.

Now that the PCI SSC has clarified this situation, hopefully, this marketing ploy will stop.

2012 Database Threats

I attended a Webinar recently put on by Application Security Inc. regarding the threats to databases for the coming year.  If you did not attend it, you missed a good session.  But the most disturbing thing brought up was their top 10 list database vulnerabilities and misconfigurations.  Their top 10 list is:

1. Default or weak passwords
2. SQL injection
3. Excessive user and group privileges
4. Unnecessary DBMS features enabled
5. Broken configuration management
6. Buffer overflows
7. Privilege escalation
8. Denial of Service
9. Unpatched RDBMS
10. Unencrypted data

If you look at my post a while back on the 2011 Verizon Business Services’ reasons for why organizations were breached, there is a great correlation between Verizon’s report and what Application Security Inc. is saying.

Their first point about weak or default passwords is very clear and should not need to be discussed.  In this day and age, we should all be ashamed that this is even on the list, let alone the first item on the list.  The bottom line here is that, if you use default or weak passwords, you deserve to be breached.

They brought up and interesting point about SQL injection attacks that a lot of organizations do miss or underestimate and that is the internal SQL injection.  Most organizations are so focused on the external threat that they forget about the threat from the inside.  Worse yet, most security professionals and DBAs are unaware of the threat SQL injection poses even without the Web.  Since most of today’s attacks are perpetrated once past the perimeter, the protection from the inside attack is very relevant and very important.  Because once an attacker is on the inside, it is relatively trivial to use SQL injection or other techniques to obtain data.  More and more organizations are beginning to understand the insider threat and are firewalling all of their database servers away from the general user community as well as minimizing the number of users that have direct SQL access to those servers.

Excessive privileges cannot always be addressed at the DBMS level.  In today’s packaged software world, a lot of the rights are managed and maintained at the application level and that security matrix is maintained in a database table.  The granularity that can be granted is usually where things go awry because the application’s security system only provides an “all or nothing” approach.  Application vendors are getting better with this because of SOX, HIPAA, PCI and the like.  However, organizations typically need to be on the most current releases to have access to such enhanced security granularity.  Unfortunately, there are very few organizations that can afford the most current release or can implement the most current release due to their extensive modifications.  The simplest way to address this issue is the periodic reviews of database privileges and minimizing those users that have excessive privileges.  In the longer term, I expect we’ll see the return of the data dictionary with the addition of user rights and roles that will manage this problem.

Unnecessary features enabled are a vendor and DBA issue.  In some cases, vendors make changing features impossible or near to impossible once the RDBMS is installed.  In some cases, there are physical reasons as to why a feature must be enabled at installation.  However, there are also instances where features could be enabled or even disabled at anytime, but because the vendor only wanted to do that at installation, that is the only time you can deal with the feature.  This results in a lot of DBAs installing the RDBMS with every feature/function available, whether it is needed or not, just in case they might need it later on.  Do not get me wrong as I understand the drivers for this practice.  In today’s “I needed it yesterday” world, it is tough to be responsive when something will require an entire re-install of the RDBMS and migration of existing data in order to get something done.  It is time for IT people as a whole to start explaining to non-IT people that there are just some tasks that take time to do properly no matter how quickly anyone needs them completed.  Our infrastructure has become susceptible to attack in large part because of this rapid response desire.  If we intend to make things secure, we need to stop and think things through before creating even larger issues.

The pervious issue feeds directly into the next; broken configuration management.  Configuration management is broken because the vendors make it virtually impossible not to break it.  And even when configuration and changing configuration is easy and manageable, DBAs are not always as structured as other IT operational disciplines.  As a result, whether talking about the configuration of the RBDMS or the client that loads on the workstation, configurations are too broad because of the “just in case” factor.  I know it is a pain to only enable what needs to be enabled and then six months later have to reinstall everything just for a particular feature, but that is the correct way to do things if you intend to be secure.

Buffer overflows, privilege escalations and denial of service are all common vulnerabilities that organizations will have differing levels of success in mitigating.  I will tackle the easiest to address first, privilege escalation.  If there is any area where security can always be addressed it is with privilege escalation.  The reason privilege escalation exists is because someone, usually a developer, created the issue because they decided to allow users to perform a task that the user should not be allowed to perform.  Because if they were allowed to perform the function, then they would not need their privileges escalated to perform it.  The easiest thing to do is to disable those functions that require privilege escalation.  However, in some cases, that approach will create operational issues that will be unacceptable.  In those cases, monitor the daylights out of things so that you can be sure that the privilege escalation did not result in a different outcome.

In a lot of cases, there can be little done to address a denial of service (DoS) attack short of blocking the offender(s).  Denial of service does not compromise information; it just makes the information stored in the database unavailable.  And for most organizations, that is an important distinction.  If no information has been or can be compromised, then DoS is an annoyance and should be treated as such.  However, some DoS attacks can be used to defeat security measures in the RDBMS by causing the RDBMS to fallback to a basic operational state.  It is in these situations that one has to be careful because information can be lost.  The easy fix is to put a firewall in front of the database and enable DoS attack protections.

Buffer overflows are the most insidious attacks because, in some cases, there is little that can be done to stop them.  A lot of security professionals make the success of buffer overflow attacks sound like they are all the result of sloppy coding practices.  And while there is some truth to that view, the amount of which depends on the skills of your programmers, the success of buffer overflow attacks is also the result of embedding too much flexibility into our applications and leveraging the capabilities of the RDBMS.  In today’s world of open constructs such as SQL and RegEx, we have effectively made everyone a potential database programmer all in the sake of expediency.  Yes, customer service is highly improved, but at what cost?  Web application firewalls can minimize buffer overflows by “learning” how your SQL calls are typically structured, but they are not a complete answer nor do they completely remove the risks.  The way to fix the problem is to reduce functionality and make applications more complicated and difficult to use.  For most organizations that is not an option.  As a result, we must minimize the risks but be willing to accept the risks that remain as a result of our desire for ease of use and flexibility.  Minimizing the risk may mean implementing that Web application firewall internally as well as externally.

While I was glad to see that unpatched RDBMS software low on the top 10 list, I was very disappointed that it was still in the top 10.  One would think with all of the discussions about the importance of patching software, this would not occur in the top 10.  I understand the issues of compatibility and testing that make patching difficult, but really?  Maybe you need to invest in more than one or two instances of the RDBMS.  This is the cost of doing business the correct way.  If you are not doing things the correct way, then do not complain when you have a breach.  So while you saved yourself money on licensing costs on the front end, you likely paid for that cost savings a hundredfold on the back end.

I also understand the issues and fears with encryption.  For a lot of people, encryption is this mystical science that only certain “geeks” practice and practice well.  For others, the problem with encryption is the perceived loss of ready access to their data.  As time goes on, I would say that unencrypted data will rise to the top of the top 10 list.  Why?  Because the information age is all about the control of information.  The more information you control and can use to your advantage, the more power and control.  If your information can be readily obtained through public sources or the lax security surrounding your information systems, then you have little, if any, power or control.  The next 10 years will likely be spent by most organizations figuring out what information is critical to their business model and implementing the necessary protections around that information.  Critical information will be protected like the gold at Fort Know because, to that organization, that is their “gold” and it must be protected accordingly.  And that protection will likely involve encryption for some or all of it.

I know that people have a lot on their plates these days.  However, if you are a security person or a DBA, you need to leverage these surveys to your advantage and address the top 10 issues.  If more companies did this, the less data that would be breached.

Why The Push For EMV Adoption In The United States?

Have you noticed all of the press lately regarding the Europay, MasterCard and Visa (EMV) card coming out of Visa?  It has been very hard to miss.  As a result, I started wondering about the purpose of this full court press for EMV.

Before getting into my post, I need to be clear that EMV only refers to the chip in the EMV card.  In the past I have gotten a lot of feedback from Visa when I referred to EMV as “chip and PIN” even though the world almost universally refers to EMV as “chip and PIN.”

With that disclaimer, since last August, Visa USA has been making a concerted effort to get merchants to adopt EMV.  Just a week or so ago, there was another push by Visa USA to entice merchants to support EMV.  So what is the driver behind this push?  That is the $64,000 question and the more you talk to processors and merchants, the more confusing it gets.

Merchants are just as puzzled as I am regarding Visa USA’s EMV push.  In the case of a number of large merchants I have spoken with, they do not get it as they refreshed their card terminals and POS equipment over the last three years and there is no way they are going to swap all of that new gear for EMV-capable equipment.  These merchants are not even looking at contactless terminals.  Such an equipment swap this soon would not be cost effective.

But merchants question what EMV would do for them.  EMV was developed in response to the fall of the Iron Curtain when fraud ran rampant in Europe.  Credit cards were being cloned at an obscene rate and card present fraud was huge.  When EMV was fully implemented, card present fraud in Europe went to levels close to or a little lower than in the United States and EMV card present fraud has remained around those rates since.  Given where card present fraud rates are currently in the United States, introducing EMV would have a limited effect on card present fraud and that would not be enough to offset the costs of implementing EMV or contactless terminals.

So if it is not card present fraud, it must be card not present fraud that Visa USA wants to address right?  Card not present fraud, particularly on eCommerce Web sites is running almost out of control.  I would like to say that this increasing fraud rate that is the reason for Visa USA’s push.  However, EMV does nothing to address the rapidly rising rates of card not present fraud.  The reason is that in order for EMV to address card not present fraud, there would have to be some sort of interface written that would produce codes, single use transaction numbers or similar that could be used by the consumer online.  But no such solution exists, so card not present fraud cannot be the driver either.

Back in August Visa USA announced that merchants using EMV or contactless could avoid filing a PCI Report On Compliance (ROC) with Visa USA, so that must be the reason for the push.  At this year’s PCI Community Meeting in Phoenix, Arizona, PCI SSC General Manager Bob Russo made it very clear that regardless of what Visa USA was saying about filing a ROC; all merchants were still required to prove that they are in compliance with the PCI DSS.  Other card brands also reinforced this statement by reaffirming that they still required the merchant’s ROC and/or AOC as proof of compliance.  As a result, merchants save themselves very little by not having to file a ROC/AOC with only Visa USA.

What about EMV being more secure?  While that is typically true for small and mid-sized merchants, large merchants that switch their own credit card transactions would still likely have card data in their switch systems if not elsewhere in their computer systems.  So claims by some, including at times Visa USA, that PCI compliance is easier with EMV are not totally true.  Large merchants in Europe will back this up.

So after 15 years of EMV, what is Visa USA trying to prove with this push of EMV?  Apparently only Visa USA can tell us because, for the rest of us, there are no business cases we can construct to justify the switch to EMV.  Obviously, Visa USA knows something that the rest of us do not.  Or do they?  I have consistently said that without any card not present fraud solution; EMV is just a solution looking for a problem.

But wait, maybe there is something here that we have been missing.  Is it possible that Google Wallet and similar current and future applications make Visa USA feel threatened?  There may be some factual basis in that statement.

At the PCI Community Meeting last fall, I spoke with a number of processors that seemed to have an idea of why Visa USA was finally pushing EMV.  These processors indicated that the EMV push was being driven by Visa USA to get EMV into the United States market before Google Wallet and similar applications could take the advantages of EMV away.  After all, the United States is the largest credit card transaction market in the world and if EMV was not in the United States, there is no driver to get worldwide adoption pushed.

When I quizzed these processors about the supposed “advantages” of EMV, they said that was the real problem.  With the advent of smartphones and applications such as Google Wallet, EMV has no advantages.  As a result, merchants and banks have no incentive to implement EMV with these new technologies just on the horizon.

When I went back and talked to a couple of key merchants, they all said that they are waiting out the technology race to see what wins from a smartphone perspective.  If Google Wallet and the contactless approach win, then that is where they will head.  However, a lot of merchants are betting on one-time use transaction codes displayed as bar codes to win out as they do not typically require any technology changes at their POS.  American Express went down the one-time use transaction code (15 digit number that appears like a credit card number) around five years ago, but only had limited success with it for online transactions.  However, maybe the time has come for another try.

In the end, it is the consensus of merchants and processors that Visa USA has missed the window for EMV in the United States.  Most organizations believe that if Visa USA wanted EMV in the United States, they should have pushed it long ago.

UPDATE:  American Banker and PaymentsSource are holding a Webinar entitled “The End Of The MagStripe?” on Tuesday, March 6, 2012, at 3PM EST.  Unfortunately, it is not free, it costs $99.  This Webinar purports to answer some of the questions I have posed here as well as some other interesting insights into Visa and MasterCard’s thoughts on EMV.