A theme I've seen surface lately is this notion that "good enough isn't good enough." My response to this is quite simple: if what you're doing isn't commercially reasonable and legally defensible, then your notion of "good enough" is itself flawed. At the end of the day, businesses should be aiming for "good enough" insomuch as that means doing as much as is reasonable and appropriate without wasting resources.
I would submit that anybody who argues against aiming for "good enough" simply doesn't understand how business operates, nor do they truly understand risk management. Infosec is not some zero-sum game where we can magically defeat all threats, eliminate all vulnerabilities, and go home "winners." Rather, it's a journey, not a destination. Every day we have to account for new threats and new vulnerabilities. However, we should not be focusing exclusively or obsessively on them. Instead, we should be focusing on the business and what it values and has of value.
A few things to consider:
Checklists are a means, not an end
I've written about this topic in the past. The problem is all too readily seen in the public sector, as well as in organizations that let themselves be driven by regulations (noted in this piece about who's risk your org might be managing).
The short version is this: If your security program amounts to blindly following checklists and so-called "best practices," then I'm sorry to say that your practices are neither commercially reasonable, nor are they legally defensible. A lack of coherent, cogent intelligence must be applied through a documented trail of decision-making. Or, if nothing else, a rational, reasonable explanation must be readily producible for why practices are or aren't in place.
A checklist can be a powerful tool when used properly. In particular, specific "high risk" activities (as determined by your organization - examples may include server builds and administering access management and key management) should absolutely have well-refined checklists surrounding them. If you need to re-key your data repositories due to routine key rotation requirements, then you had better have a detailed checklist for how to do that correctly. Checklists can be particularly helpful for tasks not performed on a daily (or even weekly) basis.
However, again, note that a checklist is just one tool designed to reduce errors, especially within high risk practices. They are not the basis of a program, but rather the outcome of intelligent consideration and reflection.
Traditional (zero-sum-based) approaches and thinking must die
Sadly, much of the traditional mindset in infosec relies on so-called "best practices," which in turn are merely devolved checklists. This outmoded thinking is premised on a fatal flaw: that enough vulnerabilities or threats can be eliminated so as to suitably protect the business from information/IT risk factors. Of course, nothing could be further from the truth, and for a few reasons.
One place where we've seen this failure is in the antiquated risk management approach that many still use, which basically boils down to:
"Risk = Threats x Vulnerabilities x Impact"
While this notion overall seems credible, and can be useful for elementary discussions, it does not in any way lead to a coherent, comprehensive strategy for managing various risk factors in the enterprise.
Instead, consider the high-level risk management process described by ISO/IEC 31000:20009, as shown below.
While every decision need not formally pass through this process, it does provide a good high-level map for how to approach decisions. Most often, I find that the "context" piece is missing or severely under-defined. The traditional mindset would have us rush straight to risk treatment, based on those good (bad) ol' "best practice" statements, regardless of what is good or useful for the business.
An example... does perimeter-oriented defense make much sense today? Traditional "best practice" statements would indicate that we need to have a hardened perimeter, but in reality, it's not necessarily cost-effective or worthwhile. If you have a large mobile and/or teleworker population, then a traditional security architecture likely won't do you much good. Yet, the firewall market sure does seem robust!
This failed mindset must go the way of the dinosaur... instead, we must move to an agile, integrated approach that leverages a mature GRC program to provide intelligence, reporting, and risk management support. It's not necessary (or appropriate) to have large security teams that duplicate duties in the standard IT organization.
Moreover, the shift must be made to resiliency and survivability. If you're still stuck in a zero-sum "beat everything" mindset, then stop it, now, please. You cannot defeat all attacks. You cannot patch all vulnerabilities. There are too many unknowns in our complex systems to fully enumerate threats and vulnerabilities. As such, it is imperative that we move to a different strategy wherein our success is measured by how well we detect, limit, and recover from incidents. Additionally, we need to measure the quality of our decisions, well beyond simple "cost vs. benefit" calculations. Impact certainly can, and should, be expressed in dollars, but that's a final calculation, not an initial one. The first question any security person should ponder when proposing new measures is "how will this impact our ability to conduct business?" If the impact is very high (negative), and yet the benefit cannot be clearly articulated, then management should push back and ask for better justification. Key questions should include:
* "Will this change make us more resilient?"
* "Will this change negatively affect our revenue stream(s)?"
* "What is the current estimated impact and the ongoing cost of doing nothing?"
* "Will this change be easy to adopt, or does it make things harder?"
* "Do we know where the 'good enough' mark is, so that we don't waste resources?"
Changes must make business sense, must be (relatively) easy to adopt, and - wherever possible - be automatable.
Human risk management is vital
One key area that has not been addressed by traditional security programs, and which is often even overlooked in the resiliency/survivability circles, is that of managing human risk. In this case, I'm not talking about "personnel security" concerns, as described in ISO 27001/27002. Certainly, those factors come into play (e.g., background checks), but what I'm more talking about here is the inherent risk factors present due to have humans in the loop. Lost laptops, accidental data exposures and leaks, insecure mobile devices permitted under BYOD policies, susceptibility to phishing/spearphishing attacks, simply configuration errors, and so on.
The simple truth is that humans tend to add a lot of risk to everything we do. We are inherently fallible, and that can be quite problematic. To a degree, we can control for human risk factors (e.g., use of checklists in critical operations!:). However, there will always be human risk factors impacting what we do. Does your risk management program account for this reality?
Undoubtedly, the average business has not yet reached a "good enough" status in dealing with human risk factors. The fact that BYOD policies rapidly spread like wildfire over the past 2 years alone provides ample evidence that we're not there yet. If nothing else, risk management calculations must take into consideration the human element when weighing options and decisions.
In the end...
I would be ecstatic if the average busy achieved "good enough" security measures that could be argued as "commercially reasonable" and "legally defensible." It is, in fact, a laudable goal, not to mention a smart objective to pursue. We should not be doing more than is necessary or appropriate; to do so is fiscally irresponsible. Besides, there are limited resources to work with, which means that if we're overspending in one area, then another area that could use those resources is losing out. Business is about striking a good balance, and "good enough" security practices are a key part of that equation.
That said, what most organizations are doing today is not "good enough," even if people think it is. Even better, what was "good enough" last year may not be "good enough" this year. The standard of care is ever-changing and continually evolving and improving. Incidentally, this is a good thing! It also provides the basis of most concerns around "commercially reasonable security" (a topic for a different day).
Ask not what regulations prescribe for you to do; ask what is commercially reasonable to do in light of regulations and the state of the art.
