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

Recently I was asked to review an upcoming work by a friend of mine in which he touches on some of the legal aspects of digital forensics.  As I was reading the document it struck me how much of what we do has a legal driver.  Now really this is something that we all know but that we rarely give much notice to so the thought occurred to me that it would be beneficial to go back and review some of the legal implications of what we do. 

Thus starts a new series of posts entitled Legal Implications.  Right now I only have a few of the topics mapped out and trust me there is almost no end to the list of what we can discuss under this heading.  For the first post I’ll be dealing with setting the stage for this discussion with a talk about some of the types of information that we need to protect as well as some of the main risks to this information. 

We will then move on to assessing regulatory obligations before finishing with looking at possible third-party liability.  During this discussion we’ll touch on the Financial Services Modernization Act of 1999, better known as Gramm Leach Bliley or GLBA, and the Health Insurance Portability and Accountability Act, or HIPAA, as well as a few other U.S. Federal and State statutes.  Now my focus will primarily be on U.S. law but I may also briefly discuss some of the international laws as they come into play. 

Let me also say that while I come from a family of lawyers, I am not a lawyer and what I’ll be giving is a layman’s interpretation of the topics that I’ll be covering.  Nothing that I’m going to write should be construed as legal advice or in any way definitive.  While it is useful to have a familiarity with these topics, you should always consult a qualified legal professional whenever you deal with these issues. 

Setting the Stage

How much of the work that your company does can survive without computers?  If you were to shutdown every system within the company how much work could actually be accomplished? 

For better or worse our organizations are dependent upon information systems.  We communicate through them, we conduct business transactions through them, we do our accounting through them, we conduct and store research and development information on them.  You get the picture; just about everything we do is tied to information systems. 

We have been able to increase productivity and efficiency through the use of information systems so this on the whole has been a good thing but it also means that we are dependent upon them in order to function.   Our systems have become increasingly interconnected which increases their functionality as well as it increases the risk in operating them.  Awareness of these risks has lead to the enactment of various laws and regulations with regard to how sensitive information is treated and handled.  These laws can impact how we implement and interconnect our information systems not only within our own environments but also with our business partners and customers. 

What types of information do we need to be concerned with?  Well here is a brief list:

• Confidential Proprietary Information (trade secrets, customer lists, etc)
• The personal information of employees and customers
• Confidential information of a business partner

There are laws on the books which protect a company’s right to information as well as laws that dictate the responsibilities that a company has in protecting the sensitive information of others.  An interesting example of this is the 1985 case of Defiance Button Machine Company v. C&C Metal Products Corp[i].  In this case the court ruled that since Defiance did not properly protect their customer lists that they had lost their status as trade secrets and therefore forfeited their rights to them.  Is your company properly protecting its trade secrets?

If you are going to establish an appropriate information risk management program you need to know how your critical information enters your systems, how it is processed, everywhere it is stored, and how it exits your systems.  That way you can implement the appropriate and required security controls.  What kinds of controls are we talking about? 

• Physical Security Controls
  • Your typical “gates and guards”
• Technical Security Controls 
  • Logical security such as access control, user provisioning, network segmentation, etc
• Managerial Security Controls 
  • Appropriate policy and procedures with regard to security. These typically cover everything from employee hiring practices to disciplinary procedures to training and awareness.
• Operational Security Controls 
  • These involve how a business operates and how it accounts for its own unique risks and vulnerabilities.

Now that we have set the stage for our discussion we can move onto assessing regulatory obligations and the potential for third-party liability under civil law.  I’ll be dealing with these issues in upcoming posts. 

 

---

[i] DEFIANCE BUTTON MACHINE COMPANY, Plaintiff-Appellant, v. C & C METAL PRODUCTS CORP. and Defiance Button Machine Company, Inc., Defendants-Appellees., 759 F.2d 1053 (2d Cir. 1985)

Tags: confidential, GLBA, HIPAA, implications, law, legal, personal informaiton, personally identifiable information, PII, proprietary, trade secret