I’ve been a bit lax with the blog lately and for that I’m sorry.  The reason will be clear in a few weeks when I hope to be able to make an announcement.  For now though I’d like to just provide my apologies.

This post started out as my commentary on two recent articles that appeared in CSO Magazine concerning the data breach at Heartland Payment Systems (“Heartland CEO on Data Breach: QSAs Let Us Down” and “SQL Injection Attacks Lead to Heartland, Hannaford Breaches.”) 

Now what I do to write these posts is basically sit down and let it just flow out of me.  I then go back and do a little clean up as needed.  Sometimes the clean up needed is so much I just trash the post.  Other times I realize that a concept that came up late post is really what the post should have been about in the first place.  That is the case this time.  So I’ve basically thrown out three quarters of the pontificating (which you really didn’t want to hear anyway) and focused on the analogy that information security is much like professional cooking. As I put this together I glanced down at the word count and realized that this was growing to be much more than the simple post that I initially envisioned.  So what I’ll do is break it up into a few parts to try and get my point across.  Let me know if I was successful. 

How did I come up with this analogy?  Well it was mainly sparked by a comment made by Heartland CEO Robert Carr in the first article mentioned above.  That comment was:

“The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem. The QSAs in our shop didn’t even know this was a common attack vector being used against other companies. We learned that 300 other companies had been attacked by the same malware. I thought, ‘You’ve got to be kidding me.’ That people would know the exact attack vector and not tell major players in the industry is unthinkable to me. I still can’t reconcile that.”

In this first part I’m going to set up the analogy and then dive into it within the subsequent posts. 

While I’ve been critical of some of the statements that Mr. Carr has made in the past I basically think that he has done a great job in responding to the crisis his company is in.  True he may have been forced into this response by circumstances but I’m not going to look a gift horse in the mouth.  A CEO of a major corporation has finally come to realize the importance of information security in the daily operations of his company.  However you look at it that is a good thing.  That he has become proactive in advancing our cause is an even better thing. 

What concerns me though is Mr. Carr’s statement.  He may be doing the right thing but I don’t want him to do it for the wrong reason because in the end it won’t help us out, it may even hurt us. 

You see Mr. Carr’s statement smacks of “missing the forest for the trees.”  He seems to understand that he must do something but doesn’t really understand the real reason behind it.  So this is my effort to try and shed some light onto the subject.  Will Mr. Carr ever read this?  Who knows but that really isn’t important as long as this helps someone.  So if this makes sense and you want to use it go right ahead.  (Just give me credit in some way.)

Let me take a stab at reconciling the issue.  The QSAs didn’t necessarily fail.  They audited to a known and accepted standard.  PCI DSS didn’t even necessarily fail; it is what it is a standard.  What failed you was the commonly held assumption that compliance equals security. 

When push comes to shove, SQL injection has been around for a long time so the fact that systems are still regularly found to have input validation issues is surprising.  Since we can’t blame the QSAs should we blame the developers?  We could but again we’d be missing the forest for the trees.  These are but symptoms of the problem.  How do we get at the problem?  In trying to get a handle on this I’ll try my hand at a little analogy.  That being that Information Security is a lot like professional cooking.  I’ll illustrate this by first focusing on how recipes are a lot like standards (Part Two) and then I’ll move on to broaden the image by relating what we do in information security to working in a professional kitchen.

Tags: Compliance, CSO Magazine, Data Breach, developers, Heartland Payment Systems, information risk management, insider threat, PCI, PCI DSS, professional cooking, professional kitchen, QSA, recipes, risk management, Robert Carr, SQL Injection, standards

Business Week has published a pretty good article on the Lessons Learned from the Heartland Data Breach.  I think the title is a bit misleading though.  There aren’t really any lessons learned, at least as far as what we in the security industry would call lessons learned.  Now from a business point of view it does highlight the need to try and get out in front of a story.   

The original draft of this post had me summarizing the Business Week article with a bit of commentary here and there.  As I reread it I realized that I wasn’t really adding anything and what I really wanted to accomplish had very little to do with the timeline and a lot to do with disclosure.

All in all I can’t really fault Heartland on the public relations side of this security incident.  The only two items that don’t seem to jive for me is the claim that Robert Carr, the CEO at Heartland only found out about the breach at 10:30 PM the night of Monday January 12^th and the claim that they didn’t try to bury the disclosure in the middle of the media storm that was the Inauguration of President Obama. 

As the article pointed out, Heartland was informed by VISA in October 2008 that there appeared to be signs of a breach based upon card issuer’s reports.  Heartland took the information seriously enough to go out and hire two forensics companies to examine their systems.  Now I know that Heartland is a big company but when you add up the costs involved in having two different forensics companies come in for at least two months and couple that with the possible implications of a data breach of this magnitude I find it hard to believe that Robert Carr wasn’t at least aware of a critical potential problem before the phone call on January 12^th and if he truly wasn’t then he wasn’t doing his job. 

The second point is the accusation that Heartland tried to bury the story by making their public disclosure in the midst of the media storm surrounding the Inauguration.  Heartland claims that they couldn’t disclose the details until law enforcement were finished with their initial assessment and that they did so “as soon as was practicable.”  It is true that they couldn’t make any announcement in the midst of an investigation but don’t insult my intelligence by implying that the release date and time wasn’t by design. 

Now that I have that off of my chest let me move on.  It is easy to sit out here on the Net and snipe but let’s look at the situation objectively.  Heartland was compliant with industry standards and guidelines.  When they were notified of a possible breach they began an internal investigation.  This investigation most likely involved spending massive amounts of money in the retention of not one but two separate companies that specialize in digital forensics.  When they received official notification that a breach had occurred (Supposition would lead one to conclude that the final document was delivered and briefed to someone at Heartland most likely on January 12^th.) they informed the appropriate authorities.  After law enforcement concludes their initial assessment they make a public announcement and own up to the facts rather than trying to pass the blame on to anyone else.  They follow this up by personally contacting their customers, either in person or by phone.  Since then Carr has spearheaded an effort to encrypt card data at the point of collection as well as co-founding an organization to share security within the payments industry. 

I’m sorry but I can’t find anything to fault here and quite a bit to praise.  I predict that in the years to come the Heartland Incident will become a case study in how to respond to a security incident.  All too often companies try to play the blame game and dance around on the issues.  I think that had Heartland done this they would have taken a bigger hit and garnered a lot more media attention than they already have. 

Not that this has been painless for Heartland says that they lost a few hundred customers; their stock price lost 78% of its value and is currently trading at about 50% of what it was worth prior to the announcement.  They have spent something on the order of $12 million dollars in remediation and mitigation activity thus far.  Expect that number to go up.  TJX is reported to have spent $171 million.

Was Heartland negligent in some way?  Well that has yet to be seen but based upon the information we have thus far I’d venture to say that they weren’t.  Negligence is the failure to exercise the care toward others which a reasonable or prudent person would do in the circumstances, or taking action a reasonable person would not. If they were compliant with industry standards and guidelines coupled with responding appropriately when notified of a problem then I would say that would constitute exercising due care commensurate with a reasonable or prudent person’s actions. 

Now if Heartland isn’t to blame, who is?  There is the assertion that PCI is to blame.  Personally I’m not a fan of competing standards.  I just don’t see why we need so many different standards when we obviously are just repeating ourselves in varying levels of detail.  All that said I’m not so sure it is the fault of PCI or any other standard that Heartland could have applied.  What I believe the issue to be is in the application and measurement of standards and guidelines.  All too often we take an audit mentality when we talk about complying with standards and guidelines.  When we do this we distill everything down into some sort of checklist and then equate this with being secure.  You pass the audit you are secure; you fail the audit you are not secure.  The Heartland Incident is just another example of this being a false premise.

Now I don’t want to appear to be advocating the proverbial throwing the baby out with the bath water.  What we need to do is find some way to encourage and support companies to make informed risk based decisions about security.  We can utilize standards and guidelines as frameworks upon which to build sound security practices but we also need to find a way to support companies to make security decisions based upon acceptable risk and not compliance. 

But do you want to know what the kicker is to all of this?  It is that if we do this then we will eventually come across a company that does all the right things and still has a security breach.  That will be the moment of truth.  How do we react?  Do we support the company for doing the right things and making sound risk based decisions or do we slam them for non-compliance with an arbitrary set of standards and guidelines? 

If we slam them then we are right back to where we are now. Stuck in the quagmire of checklist/compliance driven security which we know doesn’t work.  If we support them and use the security breach as an opportunity to learn from the mistake in order to improve then we’ve turned the corner. 

I’m not saying that I have all the answers either.  There has to be some measure of incentivizing companies to incorporate security into their processes other than forcing compliance with a law or regulation.  I’m just not quite sure what that is.  I do know that what we are doing now isn’t working.

Tags: Compliance, Heartland, Heartland Payment Systems, PCI, Robert Carr

A discussion got started on Twitter two weeks ago about whether or not complying with standards and regulations such as PCI, HIPAA, FISMA, ISO 27001, etc worked when it comes to securing data.  A good friend of mine, Mike Smith of the Guerilla CISO Blog, offered the point of view that compliance works, it is just that we don’t have the right requirements.  It was my point of view that compliance doesn’t work and thus the point/counterpoint began.

 

Let me say that Mike and I are very good friends and we respect each other’s opinion and point of view.  That was good because we were able to focus on attacking each other’s arguments and the conversation didn’t degrade into the usual “you don’t get it and you should just listen to me because I’ve been doing this for x number of years and know what I’m talking about” that we regrettably so often see now a days.   Let me also say that Mike and I often like to play devil’s advocate in order to explore both sides of an argument.  I can say that what I’m about to relay, I honestly believe but I make no assertion with Mike’s point of view.  You’ll have to ask him if he holds that position or if he was playing devil’s advocate with me.  In the end it really doesn’t matter all that much. 

 

We took the discussion off Twitter and onto email because it is hard to develop and present arguments in the 140 character sound bites that are Twitter.   What I’m about to summarize is an email that I send laying out what I believe to be the salient points and my contention that compliance doesn’t work.  Once this is over please feel free to join the discussion – dissenting points of view are welcome. 

 

Point:

Compliance does work it is just that we haven’t done a good enough job in setting the requirements (the required elements of standards and regulations such as PCI, FISMA, ISO 27001, COBIT, etc).  Since these requirements are not directly translatable into buildable/testable requirements then they are not adequate and that is why compliance fails.  If our requirements were buildable and testable then achieving compliance would work. 

 

Counter Point:

Compliance doesn’t work because it is based on the assumption that achieving a given set of requirements will result in a secure system (or environment).  For example, installing a web application firewall or intrusion detection system will not necessarily help to secure your environment if they are not configured properly.  Standards and Regulations are often written to address the widest audience possible.  As a result many, if not all, of the requirements need to be tailored for each specific environment.   By refining the requirements you effectively reduce the applicable audience and by extension increase the number of variances that need to occur in order to widely apply the standard or regulation.  As a result you’ll still be struggling with the same issues just from a different direction.

 

In order for something to be considered a standard it must meet the balance between being applicable to a majority of its audience and be actionable.  If it is too broad then it can’t be a standard because it doesn’t provide value, if it is too narrow then it can’t be a standard because its audience is too small (i.e. it is not widely applicable).   So is it really a problem with standards?  I don’t think so. 

 

The main problem with the compliance mentality is that it has you striving to achieve a requirement which, while related to the goal, is not the actual goal of what you are trying to accomplish.  The goal that you are trying to secure information with a reasonable level of security controls.  A reasonable level of security involves much more than achieving a set of requirements within a standard.  It involves fully understanding the information lifecycle and choosing controls which correspond to how information is used and how critical it is to your organization.  By definition, standards don’t offer that. 

 

Now don’t get me wrong, I’m not advocating that we throw out standards such as PCI, FISMA, HIPAA, ISO, etc.  What I am saying is that we need to view them in the proper perspective and for what they are as opposed to what they have been portrayed as.  Standards and regulations can and do provide focus and some of the necessary elements to achieve a reasonable level of security but they do not make an organization secure in and of themselves. 

 

Is the answer to create more refined standards and regulations?  I don’t think so.  By doing so you would only make them less applicable.  What we do need to do is make sure that our approach to security not only incorporates the existing standards and regulations but goes beyond them is search of a reasonable level of security control.  (Whether a truly secure system is even possible is another topic that we can debate.)  Information Security is a journey, it isn’t a destination.  We need to foster an approach that values responsibility and reasonableness over blind compliance.  

 

Tags: Compliance, FISMA, Guerilla CISO, HIPAA, ISO 27001, Mike Smith, PCI, regulation, requirements, twitter

Okay, things have settled down a bit here and I have time to breath.  That means that I have to go back through all of those news articles and blog posts that I wanted to comment on but just didn’t have the time.  I do try to read a lot of news as it comes out as well as other blogs but just like everyone else there is only so much time in the day.  What I do try to do every day is scan the headlines and blog aggregator listings for articles that I can come back to.  In the past few weeks to such listings caught my attention enough to warrant me coming back to them.  The first was about how the healthcare industry was releasing their own “common security framework.” The second was an article by Matt Hines over at eWeek Security Watch entitled PCI Chiefs Defend Standard(s), Plans. 

Let’s start with the healthcare industry.  At the beginning of the month (March 2nd 2009) the Health Information Trust Alliance (HITRUST) announced the release of their Common Security Framework (CSF).  This framework is reported to be a control framework developed for the healthcare industry.  HITRUST (according to their press release of 12/5/2007) is “a private, independent company … created to establish a common security framework that will allow for more effective and secure access, storage and exchange of personal health information.”  Expanding further the press release indicates that “major organizations from across the healthcare and employer spectrum have united to participate in the development of the first ever common security framework for the protection of health information.” 

When I went on their website to find out more about the framework I found that I couldn’t access it unless I was willing to pay their $1,800 subscription fee.  They did have a sample of their Security Implementation Manual.  I looked this over and read the accompanying brochure and came to the conclusion that this was basically ISO 27002 rehashed with some cross references in there to other pertinent regulations.  In other words this is the healthcare industry’s answer to PCI. 

The second article about the PCI chief’s defending PCI DSS.  I’ll let you read the article but I’ll pull some selected quotes for effect (and I’ll try to retain their original context.)

“…it’s hard to argue with PCI Security Standards Council General Manager Bob Russo’s assertion that when it comes to improving electronic data security and related matters of individual privacy, “something is much better than nothing.””

“they (the PCI Council) firmly recognized the reality that no standard is perfect and that DSS as it exists is only a first step in a long evolutionary process.”

“No standard is ever going to completely stop what we’re seeing right now with cyber-crime, but the reaction we’ve seen to PCI after some of these incidents like Heartland has been absolutely unfair, because we don’t even know if they were compliant,” Russo said.

“You can sit there and look at it from one side and say, you have this standard but these incidents have still happened, and that proves something isn’t working,” Russo said. “But what you don’t know at the same time is, If we didn’t have DSS as it stands in place, how many more of these incidents might we have had?”

(I think that gives you the general gist of it – as least for the points that I’d like to address.)

I’m sitting here resisting the urge to respond to each of these quotes.  While I could I think it would derail the point that I really want to make.  That point is that everyone is missing the point – security is not about compliance.  Security is about making realistic risk-based decisions on how information is protected.  Standards and regulations are merely waypoints that must be crossed along the way.  Security is a journey and not a destination.  The problem that I see is that everyone wants to approach compliance as a task; once it is accomplished they move on to other things. 

Think about it this way.  Standards and regulations, like PCI, theHITRUST CSF, HIPAA, FISMA, etc., only get you to the minimal passing grade when it comes to security.  On the traditional U.S. A-F grading scale that grade would be a “C.”  If you aren’t compliant then you have either a “D” or an “F” (when I was on my way up they didn’t have “E”) If you move past compliance and onto really addressing risks then you can get a higher grade.  Here is the kicker – no one can get a perfect score.  Why – because there is no truly 100% secure system.  (If you want to argue that point then add a comment or send me an email.  We can argue in a separate post.)

No matter how well intentioned these industry-standards and government regulations are, they cannot force a real change in behavior if they are going to be treated as “something else we need to comply with before we can focus on business.”  Corporations need to realize that they are still vulnerable to data breaches and security incidents even after they achieve compliance.  The more they address risk the less they will be vulnerable and they, and the public, must come to grips with the fact that there will always be some level of risk. 

Are standards and regulations useful – I have to grudgingly say that yes they are but they will never be the panacea or silver bullet that is being sought.  They are useful as waypoints or mile-posts along the road of our journey but they are not, nor should they be our destination.  The only way to truly come as close as possible to a 100% secure system is to foster a risk aware culture within your environment.  And as that opens another can of worms, I’ll leave that to another day. 

Tags: Compliance, healthcare industry, HIPAA, PCI