Three Reasons Why America's Security Model is Broken -- Counterpoint

Last Friday  CSO Online published and article by Craig Shumard entitled 3 Reasons Why America's Security is Broken.  In this article, Shumard -- the former CISO of CIGNA who survived the early days of HIPAA and HITECH legislations -- offers a three-pronged approach to fixing security in the US:  (a)  More detailed/prescriptive rules and regulations; (b) fixing the basics; and (c) more transparency regarding security implementations to our customers.  As security professionals, I think it's worth taking a look at each of these proposed remediation strategies in some detail.

1.  The regulatory environment.  Regulatory prescriptiveness in any arena is a matter of balance.  If you are too prescriptive you run the risk of imposing needless costs as well as hamstringing the ability to innovate and/or embrace new technologies.  Let's take, for instance, the use of antivirus software.  It seems to make sense to be prescriptive about the use of anti-virus, yes...until you realize that the percentage of malware attacks that AV systems (or many signature-based technologies these days) are capable of stopping is small and getting smaller.  Change the signature ever so slightly and the malware has a heightened opportunity of slipping through.  In the past, I and several colleagues have made the argument that heightened levels of access and permissioning further down the OSI stack combined with improved malware technologies can achieve a higher percentage of success than AV suites...yet the more-prescriptive regulations out there all mandate the use of antivirus software.

This problem is, of course, exacerbated by the pace of change for regulation and law.  By the time most regulations and laws get passed, technology has already begun the march into new territories which regulations do not address completely.  Imagine if, for instance, the PCI-DSS prescribed a specific algorithm and bit-length for encryption.  As technology advances and processing speeds change, meeting the prescribed standard actually might place the complying entity in a state of weakened security.

Of course, setting a prescriptive minimum requirement for security controls can eliminate this potential risk...but again, unless the minimum can move at a pace that keeps up with technological change then you still end up with the potential for prescribed weakness in controls.

I would argue that the thing that needs to be fixed in this area isn't the lack of specificity in regulations;  rather, it is the cessation of equating of compliance with security.  A secure framework meets all compliance standards...but a compliance framework will never meet all security needs. Attempting to prescribe security via regulation is a gesture in futility;  despite our legislators' belief that this is possible, as professionals we need to break the security = compliance equation.

2.  Fixing the basics.  I absolutely support Mr. Shumard's position here. To quote an earlier posting of mine, I truly wonder what the various data breach reports would look like if we:

• Enforced heightened password complexity
• Patched vigorously and rapidly (to include addressing aggregate risk via patching low-level vulnerabilities with regularity)
• Cleaned up roles and access to systems, ensuring a least privilege model; and
• Managed(and monitored) super user accounts and privileges aggressively throughout the environment.

Even more scary to contemplate is the impact of such basic blocking and tackling on the security industry and its never-ending race toward new tools.

3.  Transparency.  Again, I agree with Mr. Shumard's basic premise in this instance.  Creating a model of transparency re: what we are doing from a security perspective will help us more than hurt us by forcing those who are doing less than what is deemed prudent to leave the shadows.  The problem -- one which Mr. Shumard spends far too little time on -- is the determination of what is deemed "prudent."

When I build programs, I often tell folks that I can build them Fort Knox but Fort Knox mightn't be the proper solution for their business model.  The trick (or, if you prefer, the "art" portion of our professional "science") is determining what the right balance is for the environment and what that does to the overall risk calculus of the business.  Once again, the hindrance in this area is staring us in the mirror.

Two well trained, well educated security professionals with similar backgrounds and perspectives can walk into an organization and evaluate its security/risk postures and reach different conclusions.  On a 10-point scale, one professional will rate the organization as a 7 and another will rate it as an 8.  As the Mr. Shumard points out, we need to get to a state where we have some type of common best practices/risk-versus-control-implementation knowledge base that we can look towards as we implement programs.  Continuing the example above, if such a knowledge base existed we could agree as a profession that the evaluated organization is currently at a 7 on a 10-point scale...at which point, the discussion becomes one of whether a 7 is sufficient and appropriate for the assets being protected.

This is the hard and non-sexy work of our profession; it turns more of our "art" into "science" and that scares many folks in our field.  Until we complete this work, though, meaningful transparency isn't achievable...and sooner or later our constituents are going to become less enamored with security professionals continually stating that "it's complicated" or "it depends" versus explaining what we're doing and why we're doing it.

Conclusions.  Where Mr. Shumard states three reasons that our security model is broken, I offer three actions necessary for remediation:

• Fix the basics.  It's past time we did so.
• Stop looking toward regulation as the only expression of security value.  As a profession we made an egregious error in hanging our hats onto fledgling regulations at the turn of the century.  In doing so, we placed the power of determining appropriate security in the hands of those for whom legal sufficiency is a perfectly acceptable standard.  We don't need more prescriptive regulation; we need to express security value in terms not tied to regulation.
• Create a standard.  It's time to spend serious cycles on driving down the art of security and focusing on the science.  Only by creating some level of professional normalization (forgive the double entendre :) ) can we avoid going the way of the VP of Telephony within our organizations.

For for thought!