Compliance vs. Security

I think what Corman is getting at is that creating regulatory threats is distracting organizations from focusing on and managing risk from REAL threats.  Creating something like PCI-DSS has the (possibly) unintended consequence of sending the message, “If you don’t think hackers are a threat, fine, WE’LL be the threat, and we’ll fine your ass.”

Managing to the wrong threat means you’re managing to the wrong risks, and that’s how security can suffer.

I kind of agree with Corman, or perhaps read something different into it. Unfortunately from the “vendor” side, PCI at times can seem to stifle security innovation and what seems like a better solution for both compliance and security. There is so much money ( for now ) luring good idea’s into sub optimal solutions around a standard that its hard not to get caught up in the fervor. For now i suppose that Compliance initiatives are helping educate companies about security-as-a-by-product but i kinda look forward to 2014 ( random date ) when things have moved on to a whole new set of challenges.

@shrdlu - And I think that left to their own devices, companies would treat security and compliance with equal contempt. It’s an issue of perspective. Compliance is a distraction. I have no argument with that statement. But recognize that business leaders view compliance as an economic impediment, and security professionals look at compliance as an impediment to optimal security. To imply the removal of the compliance distraction would cause companies to embrace risk management and go after REAL threats is, in my opinion, folly. The perspective is one of a security practitioner, not a business leader. Until companies have had to embrace the economic necessity of security, they are not looking to be secure, and will not view the advantage of a risk based model over generic compliance guidelines.

@erik - Do I do code review, hire pen testers or buy a WAF? The vendors are telling me _their solution_ is the best,  are will provide better security and cost less in the long run. Which do I choose?

Where I think compliance hurts us is specifying adoption of a technology as if security was a ‘one-size-fits-all’ problem. Any one of these technologies is the right choice, depending upon the situation. Another example is with PCI: even though it has accommodations for risk management in the use of compensating controls, the effort to document, explain and defend these optional methods becomes quite a bit of work.Innovation takes a hit when companies don’t push the vendors to do more and do it better. I have been on the vendor side for a very, very long time. Believe me, if I _know_ companies will buy a certain products because it solves a business problem, I’m going to build it. Innovation has a way of popping up when there is money to be made.

-Adrian

Wow. Hard to know where to start here. There is a lot to like and appreciate about Corman’s positions. Security innovation has clearly suffered because organizations are feeding the compliance beast. Yes, there is some overlap - but it’s more being lucky than good when a compliance mandate actually improves security.

The reality is BOTH security and compliance do not add value to an organization. I’ve heard the “enabling” hogwash for years and still don’t believe it. That means organizations will spend the least amount possible to achieve a certain level of “risk” mitigation - whether it’s to address security threats or compliance mandates. That is not going to change.

What Josh is really doing is challenging all of us to break out of this death spiral, where we are beholden to the compliance gods and that means we cannot actually protect much of anything. Compliance is and will remain years behind the real threats.

How we fill that gap is what the next 5 years of security is all about. Josh hasn’t pulled the curtain back on his ideas about that (yet), but that’s really the issue.

At least from where I sit…

Mike.
http://blog.securityincite.com
http://blog.eiqnetworks.com

PCI is the Devil…HIPAA told me so…
To begin with, I happen to agree with Josh’s assessment of the challenge presented by regulations and standards today.  In fact, I really wish that they would call PCI DSS something other than a standard as standards imply there are alternate methods to operate from aside from this one yet this is the leading ideological premise to date.  There is no other way to operate with respect to PCI DSS v1.2 largely because it is a “family affair” amongst the big credit card corporations.  In a recent post, I talk about PCI at length http://cassandrasecurity.com/?p=589
Regulatory compliance has its place.  Governance has its place.  I know Josh and know that he’s not suggesting anything to the contrary however, being that they have their place it’s intellectually dishonest to suggest that they should supersede (never mind dangerous from a risk posture perspective), innovative solutions which need to be explored and adopted so that enterprises might steel themselves for next generation threats.  For example, PCI DSS is broken down in the following manner:
The core of the PCI DSS is a group of principles and accompanying requirements, around which the specific elements of the DSS are organized:
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security
When it was first written (I worked with the gent responsible for its first draft back when he was on an engagement being asked to revamp the CISP for this purpose), it was written as a guideline not an end game.  It is (if you take the time to look), a composition of certain aspects of the ISO:17799 and CoBIT standards.  Its evolution is natural however what is unnatural is the length of time required to achieve it, the costs associated with attempting to achieve (product, consulting, managed service, internal time of staff, postponement of other pressing matters due to meeting the deadline etc.), and the unnatural impact is having on the way organizations do business. 
I love the comparison to no child left behind because it is appropriate and truthful.  In the fervor to ensure no child is left behind academically, and in short not promoted, a whole host of other issues followed which upon initial conception, was likely not considered but should have been…we in the security business call this risk management.  As most businesses have limited budgets from which to work, it also becomes a question of economics meeting preparedness should they be called upon to meet compliance.  Posture counts for a lot if the organizations’ in question is no good.  Should this be the case you can expect costs to rise and so too the efforts not to mention, the likelihood that other initiatives regardless of their importance to ensuring confidentiality, integrity and availability of the organizations critical assets.  Then come the fines.  I think that this is one of the greatest sins of the PCI DSS counsel.  Their fines and the processes by which they are allocated….not to mention that meeting the criteria for accreditation is rather loosely defined by the guidance of the standard, the experience of the assessors and the ability of the organization to demonstrate controls (manual or programmable) in addition to internal or externally driven controls.  Never mind the generation of artifacts.  Imagine had the brain trust behind HIPAA been able to quickly and effectively (as opposed to not so quickly or effectively), define and impose their standards upon those who would need to comply.  Remember the role of the Chief Privacy Officer?  I do.  You do not hear much about them anymore…I wonder why.  I shudder at the thought of an effective HIPAA not because the idea was bad but rather because of the way in which bureaucrats tend to abuse this type of standard or legislation thusly turning them into revenue generating / profit centers.  In addition, that brings us right back to PCI (nice segue huh?), PCI has become amongst other things, a vehicle by which vendors can scare precious budgetary dollars out of enterprises.  It is not speculation or conjecture, it is information gathered from firsthand experience.  Additionally, PCI compliance (or any compliance for that matter), does not meet or equate to a secure posture unless ‘compliance’ is the result of being assessed / audit against a customized, risk centric tailored to fit security program and framework. 
Many vendors and some questionable third parties have run amuck convincing people otherwise however that is both irresponsible and intellectually dishonest especially when considering the world in which we live and the threats we in research see day in and day out.  Josh’s point is completely valid; if organizations sacrifice innovation for compliance they will end up paying more later on in spades.  Just ask the folks at Hannaford, Heartland and Choicepoint (parts I and deux).  Equally concerning is the manner in which these vendors and certain third parties have attempted to convince these organizations that security doesn’t matter because failure to comply is far worse and offers potentially worse ramifications (perhaps but that is debatable). 
I am often asked about my stance on PCI and other regulatory acts.  My standard reply is this: they are a fine place from which to establish gaps for those who have no baseline from which to work, however they are not substitutes for well-planned, designed and implemented risk based security programs and / or frameworks.  In one of my past lives we built a lot of security programs and frameworks (still do but I digress), and at that time, just like now, I would have said the same thing.  The reason is clear: if you spend on building something that ultimately enables the entirety of the business (not a subset as do many PCI based initiatives), you will no doubt walk away with a mature framework from which you can address any and all regulatory or compliance act via the generation of artifacts (as a vehicle for control demonstration). 
Josh’s point is that businesses have been made to feel this way.  They have been led to believe that they have no choice but to spend every nickel of their budget, exhaust their resources and as a result fundamentally increase the risks presented to the business by virtue of what the PCI DSS standard does not address nor can address due to the limitations present today in most conventional security technologies. 
When in reality there are better, more effective ways to address the fundamental areas of concern cited within the PCI DSS 1.2 without sacrificing everything in the process.  Does security come at a price?  Yes it does.  However, provided organizations are experiencing organic growth with a healthy amount of tactical and strategic planning savings can be realized over time which will well surpass the costs incurred to address the need.