More On PCI Scoping

Everyone that is going through the PCI compliance process tries to get systems, processes, whatever, out of scope.  And while getting things out of scope is a good thing, it does not mean that they do not need to be assessed.  And this is one of the most contentious points of a PCI compliance assessment.

One of the biggest misconceptions about the PCI compliance assessment process is that, just because an organization says that something is out of scope, does not mean that it does not have to be examined.  The PCI compliance assessment process is all about trust, but verify.  So, when an organization says that a particular element is out of scope, it is up to their QSA to confirm that the item is, in fact, out of scope.

Take for example network segmentation that is used to delineate an organization’s cardholder data environment (CDE).  A QSA is required to confirm that the network segmentation implemented does in fact keep the CDE logically or physically separated from the rest of an organization.  That confirmation process will likely review firewall rules, access control lists and other controls on the network to prove that the CDE is segregated.  And going through these items can sometimes result in a lot of QSA effort, particularly as network complexity increases.

Another area where the out of scope effort can be messy is in the area of applications and whether they process, store or transmit cardholder data.  Proving that an application does not store cardholder data is typically fairly straight forward.  The QSA just examines the data schemas for files and databases looking for fields named credit card number or any 16 character fields.  A QSA will also typically run queries against the database looking for 16 digit numbers that start with known BINs.  I have been involved in a number of assessments where we have found cardholder data being stored in text and comment fields through our queries.  Determining whether an application is processing or transmitting cardholder data is more complicated and problematic.  It can take a quite a lot of effort to determine using an organization’s Quality Assurance or Testing facilities, but it can be accomplished.

The biggest clarification for v2.0 of the PCI DSS is that it is the responsibility of the organization being assessed to prove that their CDE is in fact accurate.  This had always been the implicit case, but with v2.0 of the PCI DSS, the PCI SSC has explicitly stated this fact.  Page 11 of the PCI DSS states:

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.”

As a result, the organization being assessed should provide proof to their QSA that they have taken an examination of all of their processes, automated and manual, and have determined what is in-scope and out of scope.  The results of this self examination are used by the QSA to confirm that the CDE definition, as documented by the organization, is accurate.

This clarification has resulted in a lot of questions.  The primary of which is along the lines of, “How am I supposed to prove that I have assessed my entire environment and made sure the CDE is the only place where cardholder data exists?”  While the implications of this question are obvious for the Wal*Mart’s and Best Buy’s of the world, even small and midsized merchants can have difficulties meeting this requirement.  And I can assure you that even the “big boys” with their data loss prevention and other solutions are not hyped on scanning every server and workstation they have for cardholder data (CHD).

For determining whether or not CHD is present in flat files on computers, there are a number of open source (i.e., “free”) solutions.  While I discuss a lot of tools and share my experiences, this is not an endorsement of any particular tool.

At the simplest are the following tools.

• ccsrch – (http://ccsrch.sourceforge.net/) – If this is not the original credit card search utility, it should be.  ccsrch identifies unencrypted and numerically contiguous primary account numbers (PAN) and credit card track data on Windows or UNIX operating systems.  One of the biggest shortcomings of ccsrch is that it will not run over a network, so scanning multiple computers is a chore.  The other big shortcoming of ccsrch is that unless the data is in clear text in the file, ccsrch will not identify it.  As a result, file formats such as PDF, Word and Excel could contain CHD and may not necessarily be recognized.  It has been my experience that ccsrch tosses back a high number of false positive results due to its file format limitations and therefore recognizing data that is not a PAN as a PAN.
• Find_SSNs – (http://security.vt.edu/resources_and_information/find_ssns.html) – While the file name seems to imply it only searches for social security numbers, it also searches for PANs and will do so for a variety of file formats such as Word, Excel, PDFs, etc.  Find_SSNs runs on a variety of Windows and UNIX platforms, but as with ccsrch, it does not run over a network; it must be run machine by machine.  Find_SSNs seems to have a very low false positive rate.
• SENF – (https://senf.security.utexas.edu/) – Sensitive Number Finder (SENF) is a Java application developed at the University of Texas.  If a computer runs Java, it will run SENF so it is relatively platform independent and supports many file formats similar to Find_SSNs.  That said, as with the previous tools, SENF will not run over a network, it must run on each individual machine.  I have found SENF to have a much lower false positive rate than ccsrch, but not as low as either Find_SSNs or Spider.
• Spider – (http://www2.cit.cornell.edu/security/tools/) – This used to be my favorite utility for finding PANs.  Spider will scan multiple computers over a network, albeit slowly and the fact that it has a propensity for crashing when run over the network.  However, it also seems to have a low false positive rate that is comparable to Find_SSNs.

I still use Spider and Find_SSNs for scanning log and debug files for PANs as I have yet to find anything as simple, fast and reasonably accurate when dealing with flat text files.  And yes, I use both as checks against each other for further reducing the false positive rate.  It amazes me, as well as my clients, the amount of incidental and occasional CHD that we find in log and debug files due to mis-configuration of applications and vendors who forget to turn off debugging mode after researching problems.

But I am sure a lot of you are saying, “Flat files?  Who stores anything in flat files these days?”  And that is the biggest issue with the aforementioned open source solutions; none of them will scan a database from a table schema perspective.  If the database data store does coincidentally store clear text PANs as legible text, the aforementioned utilities will find it but that is pretty rare due to data compression, indexing and other issues with some database management systems.  As such, if you wanted to stay with open source, you had to be willing to use their code as a base and adapt it to scanning a particular database and table schemas unless you were willing to go to a commercial solution.  That is until OpenDLP (http://code.google.com/p/opendlp/).

OpenDLP is my personal open source favorite now for a number of reasons.  First, it uses Regular Expressions (RegEx) so you can use it to look not only for PANs, but a whole host of other information as long as it conforms to something that can be described programmatically such as social security numbers, driver’s license numbers, account numbers, etc.  Secondly, it will also scan Microsoft SQL Server and MySQL databases.  And finally, it will scan reliably over the network without an agent on Windows (over SMB) and UNIX systems (over SSH using sshfs).

At least I have gotten fewer client complaints over OpenDLP than I have for Spider for network scanning.  That said, OpenDLP can still tie up a server or workstation while it scans it remotely and it will really tie up a server running SQL Server or MySQL.  As such, you really need to plan ahead for scanning so that it is done overnight, after backups, etc.  And do not expect to scan everything all at once unless you have only a few systems to scan.  It can take a week or more for even small organizations.

But what if you have Oracle, DB/2, Sybase or some other database management system?  Unless you are willing to take the OpenDLP source code and modify it for your particular data base management system, I am afraid you are only left with commercial solutions such as Application Security Inc.’s .DbProtect, Identity Finder DLP, ControlCase Data Discovery or Symantec Data Loss Prevention.  Not that these solutions handle every database management system, but they do handle more than one database vendor and some handle most of them.

You should now have some ideas of how to scope your CDE so that you are prepared for your next PCI assessment.

How Many People Does It Take?

There are a lot of jokes that start with the phrase, “How many people does it take …”  But this post is no joke.  I have been taking some heat over my comment that you do not need to know who is attacking you, you only need to focus on what you need to protect.  As such, I felt the need to further explain myself.

The first complaint I get is that it is important for security professionals to know the tactics used by the attacker.

So my first question to all of you is, “How many people does it take to analyze attack vectors?”

We have forensic security organizations such as Verizon, Trustwave and Security Metrics that analyze attacks.  We have security companies such as IBM/ISS, Symantec, Kaspersky and McAfee that analyze attacks.  We have hardware/software vendors such as Checkpoint, Microsoft, Cisco and Palo Alto that analyze attacks.  I would venture to say there are hundreds of reliable sources for the analysis of attacks.  And yet, I am taken to task that you need to have your own analysis of attacks.  These hundreds of other sources just are not enough for you to rely on?  Really?  If you are doing the correct analysis of your vulnerability scanning and penetration testing reports, your attack vector risks should be known and you should have either patched or developed mitigations for those risks.

And while they might be put together in a slightly different sequence, DDoS is still DDoS and a SQL Injection is still a SQL Injection.  The bottom line is that the library of exploits available to an attacker is essentially finite.  This is proven out by the statistics that the forensic firms publish year after year.  As such, you should be able to monitor for all of these attacks fairly easily because they are all known quantities.  Yes, there is the rare Zero-Day that turns up every so often.  But, even those can be picked up if you have things configured and implemented properly.  If you think about it, unless an attacker is someone that can develop their own exploit code (and 99% do not), they are limited to whatever exploits are available in the public domain of exploits and that is a known quantity.  Take an inventory of what is available in Metasploit or Core Impact at any fixed point in time and you will see what I mean.

Then there is the group that argues that if you do not do analysis of the attacker, you cannot understand why you are being attacked.

So my second question is, “How many people does it take to give you an idea of why you are being attacked?”

This is pretty straight forward to figure out without some extensive and intensive analysis.  In 99% of cases, you are being attacked for one or more of the following reasons.

• Your organization has sensitive information such as credit card numbers, bank account numbers, intellectual property or customer information that the attackers want.
• Your organization has produced a product or service that has been perceived to be a safety hazard, overpriced or other detriment to society.
• Your organization or an employee has publicly taken a stance on some issue(s) that has irritated some group(s) of people.
• Your organization has donated money, time, products or services to an organization viewed by some group(s) of people as questionable.

Read the reports published by the forensic firms.  Read the news reports in the media.  If you distill down that information, the reasons for attacks break down into these four basic reasons.  Yet, security professionals continue to worry about the motivations of the attacker.  If you think your attack is unique, you are wasting your time.  The likelihood of your attack not being covered by these four primary reasons is slim to none.

I think these complaints just come down to the fact that doing the actual grunt work of security is just not very sexy work.  There is no doubt about that fact.  Ensuring the security of networks 24x7x365 is very, very monotonous work.  And it is that very monotony that is one of the primary reasons why organizations get breached.  People get bored with the monotony and they start to cut corners on procedures because, in their view, nothing is going on and, therefore, nothing will go on.  Only rotation of people and tasks will address the monotony, but that only works for so long.

This is why security professionals turn to automated tools to minimize reliance on people to flag potential anomalies.  Without tools, people get bored very quickly searching for the “needle in the haystack” through all of the data produced by all of the devices on your network.  However, even with all of the necessary tools, correlation of information still requires people to bring all of the anomalies recognized by the tools together and determine if all of these anomalies warrant further investigation.

Even with the necessary tools, you are not out of the woods.  One of the more common problems that we encounter is that organizations have not completely implemented those tools.  How many of you invested in the cool intrusion prevention system and still run it in notification mode?  Even then, those organizations that do completely implement the tools, do not always keep up on the “care and feeding” of the tools to ensure that the tools recognize the anomalies.  The tools are current and up to date, but anomalies are not recognized because the tools are not properly configured and tuned to the organization’s current network configuration.  Networks are not the static environments that a lot of people think they are.  As a result, either the number of false positives is so high that personnel ignore the voluminous number of alerts generated or anomalies are just never identified by the tools.

It is not until someone finally recognizes an anomaly for a breach that it finally gets interesting.  Then things become very interesting in a hurry.  Unfortunately, the statistics from the forensic firms point to the fact that, if an anomaly does get recognized, it is often many months to years down the road from the original compromise.

And that is where security professionals need to get better.  If you look at how long it took TJX to recognize their breach (years) versus how long it took Global Payments (months, but still counting), we are headed in the right direction.  But when it takes attackers only minutes, hours or even days to get your information, months still does not cut it.  We need to get to days or, better yet, minutes.  That is the challenge security professionals face and that is where we need to focus our efforts.

The PCI DSS is a good foundation, but the requirements of the PCI DSS are not going to get us to our goal.  We must go beyond the PCI DSS to get to our goal and that is a message that the PCI SSC and the card brands have consistently delivered.  The PCI DSS is only a security baseline, the ante into the game.  If you really want to be the best, you need to take your security game beyond the PCI DSS.

So let us start using the PCI DSS properly.  If your organization can execute the requirements of the PCI DSS 24x7x365 at almost 100% compliance, then you are ready to take things to the next level.  If you cannot achieve almost 100% compliance, then you need to work with your organization to get to that level.  Breaches and data loss are never going to go away, but if all organizations followed this approach, the number of breaches and amount of data lost would significantly drop.

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.

When Will The PCI SSC And Card Brands Stop The Mobile Payment Insanity?

This week PayPal introduced Here, their mobile payment processing application for Apple iOS and Android devices.  The good news is that PayPal Here at least appears to encrypt cardholder data, but that appears to be the extent of the good news.

If you pay attention to the latest Suzie’s Lemonade Verizon Wireless advertisement, you will see Intuit’s GoPayment solution on a tablet computer processing a payment.  In another bit of good news, the Intuit GoPayment solution is also encrypted.

But what is most disconcerting is that this is just another in a string of mobile payment processing solutions to be introduced with no way of knowing whether or not the security claims are accurate or can even be trusted.  This is because the PCI Security Standards Council halted last year the certification of any of these mobile payment processing solutions through the PIN Transaction Security (PTS) and Payment Application Data Security Standard (PA-DSS).  Do not get me wrong, the Council was in a tough spot and did not have a plan as to how to deal with these solutions, so the called a halt while they went back and reassessed things.

However the marketplace is not waiting.  So while the marketplace continues to deliver solutions, the merchant is left to their own devices to know whether any of these mobile payment processing solutions can be trusted.  And what I am fearful of is that small merchants, who are the marketing target of these solutions, will be put out of business should the device somehow be compromised or they lose a device.

So what are the questions surrounding the PayPal Here?

First, what is the encryption algorithm that is used?  I am guessing that they are using DUKPT, as that is common with these sorts of devices, but it is something that should be explicitly identified in their FAQ.  What PayPal currently says is, “… the PayPal Here card reader is encrypted and is backed by over a dozen years of experience of providing buyers and sellers the highest levels of security.”  If they are using DUKPT, can the key be changed?  Most of the mobile solutions I have seen do not allow for the key change under DUKPT which could be a problem.

Then there is the fact that you can manually enter a cardholder’s information through the iOS/Android application.  Given the fact that these systems are notorious for having keyboard loggers of industrial strength that means that any manual input will be recorded in the device.  I am guessing that would include cardholder name, PAN and expiration date.  However, if PayPal Here collects the CVV/CVC/CID value in manual entry that would be an extremely bad thing as the device will retain that until it overwrites it months later.  Again, there is no documentation to determine what is allowed to be manually entered, so we cannot assess how much risk this might introduce.

But the scariest feature of the PayPal Here is unrelated to credit cards; it is the remote capture of checks.  PayPal Here allows the merchant to scan a check and then submit it to their financial institution.  Again, given the data retention of these devices, I can only guess that the check images processed through the PayPal Here application will remain on the device until the space is needed which could be months.  The problem with all of this is that if people think credit card security was questionable, check processing security is nonexistent.  As a result, anyone with a modicum of knowledge could use the check information on one of these devices to drain every bank account stored.

Let us hope that the PCI Security Standards Council and the card brands quickly get back to certifying these applications so that merchants are not using insecure payment solutions.

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.