by Ben Tomhave | March 20, 2014 | Comments Off on Incomplete Thought: The Unbearable “Bear Escape” Analogy
“You don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.”
The problem with this analogy is that we’re not running from a single bear. It’s more like a drone army of bears, which are able to select multiple targets at once (pun intended). As such, there’s really no way to escape “the bear” because there’s no such thing. And don’t get me started on trying to escape the pandas…
So… if we’re not trying to simply be slightly better than the next guy, what approach should we be taking? What standard should we seek to measure against?
Overall, I’ve been advocating for years, as part of a risk-based approach, that the focus should be on determining negligence (or, protecting against such claims). Unfortunately, evolving a standard of reasonable care takes a lot of time. It’s been suggested in some circles (particularly on The Hill) that the NIST CSF may fill that void (for better or worse). One challenge here, however, is that the courts are charged with determining “what’s reasonable,” and so in many ways we’ll be challenged in evolving this standard (that is, it’ll take a while).
At any rate, I believe that there is an opportunity for constructing a framework (or, perhaps rubric would be a better outcome) by which people can start determining whether or not they’ve met a reasonable standard of care. Of course, one might also point out the myriad other standards in place that could serve a similar capacity. I don’t think CSF is remotely sufficient in its current incarnation, but that may improve over time.
It is probably worthwhile here to reinforce the point that “bad things will happen” and that it’s not so much a matter of “stop all the bad things,” but rather “manage all the bad things as best as possible” (at least after having exercised a degree of sound basic security hygiene). Anyone who’s familiar with my pre-Gartner writings will recognize the topics of resilience and survivability as key foci for risk management programs (and implicit in my thoughts and comments here).
But, how do you get to that point of a healthy, robust risk management program? Where do you start? How do you prioritize your work?
Here’s the priority stack I’ve been using lately:
- Exercise good basic security hygiene
- Do the things required of you by an external authority (aka “things that will get you fined/punished”)
- Do the things you want to do based on sound risk management decisions
What this stack should tell you is two key things. First, a reasonable standard has to consider a basic set of security practices applied across the board. It would probably be comprised of policies, awareness programs, and foundational practices like patch mgmt, VA/SCA, appsec testing (for custom coding projects), basic hardening, basic logging/monitoring/response, etc. Second, from the perspective of considering a negligence claim (bearing in mind that IANAL!), I think looking at high-level practices will be key, rather than delving into specific technical details.
For instance: Did a breach occur because a system wasn’t up to full patch level? If so, is a reasonable patch mgmt program in place? If so, why wasn’t this patch applied? What does the supporting risk assessment show about why this particular patch was not applied?
Lather, rinse, repeat.
Obviously, more could be said… but, hopefully this stub gets you started thinking about how the business may need to protect itself from legal claims in the future, and how an evolved standard for “reasonable care” (as determined in court) may impact security practices and expectations for security performance.
Read Complimentary Relevant Research
Top Strategic Predictions for 2019 and Beyond: Practicality Exists Within Instability
Technology-based change is happening continuously, and most organizations struggle to see the change in advance. Continuous change can...
View Relevant Webinars
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.