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.

Advertisement

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.

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.