by Josh More
Publisher: RJS Smart Security
Number of Pages: 24
Josh More over at RJS Smart Security obviously had some fun putting this together. Lean Security 101 is a neat little info-graphic that looks an awful lot like a comic book.
Percy the Protection Pangolin
I'll admit it; I had to look up what a Pangolin actually was (+1 for originality). The Pangolin is Josh's sidekick throughout the story.
The 80x5 Rule
The biggest insight I got out of this comic was the 80x5 Rule. So you've probably heard of the "Pareto Principle", commonly referred to as the 80/20 rule. Well the 80x5 rule builds on this idea using concepts from Lean.

The 80/20 rule is often quoted by business managers and executives as a rallying cry to take some action or get started with some new project by trying to justify quick returns with minimal effort. But hidden within this management standard is an implicit acknowledgment that getting a project to 100% perfection (meeting all of the requirements on time and within budget) becomes increasingly difficult. The law of diminishing returns takes over and additional effort is needed just to make incremental progress towards the goal.
When applied to Information Security, this concept is just as true. There is no silver bullet for protecting your digital assets, so no single project or technology or defense mechanism is ever going to be 100% effective at keeping your data safe.
The 80x5 rule is designed to help you get the most value from the least amount of effort, and while maximizing your defensive posture.

The 80x5 rule says that instead of spending all of your effort trying to implement a single defensive measure (that will never reach 100% effectiveness), it would be much more productive to add complementary layers of security. After you have spent the first 20% of your effort on that defensive measure (and reached 80% of the results), any further effort on that task could be considered waste (based on Lean). In terms of opportunity cost, if you took the remaining unspent effort (you still have 80% left at this point) and divide that into four more blocks, you could potentially get 80% results from each of another four projects. This is obviously a much better ROI than spending that remaining 80% and only obtaining at most 20% benefit from your current task.
Assuming each layer is 80% effective (based on the Pareto Principle), eight layers could give you up to 99.999% effective security. Yes, there can and will be various exceptions to this line of reasoning. But why spend all your effort on fixing things that should be considered "good enough" when there are other more productive security measures you could be working on (like building up your incident response team and testing your IR plan)? I see this as an important tool for helping to prioritize competing projects and assessing those final inches toward the goal line.
The book goes into more detail, but hopefully you get the idea. Go download a free copy for yourself, http://www.rjssmartsecurity.com/Lean-Security-101-Comic/, and give them a call about a free Lean Security Assessment.
I keep seeing tweets and blog posts and hearing talks at various cons that keep repeating statements such as:
"[insert unpopular framework/checklist here] has done nothing to improve cyber security, and in fact it has probably made security worse"
And I don't believe it!
I recently wrote about how the InfoSec echo chamber keeps dogging on "outdated best practices", and today I started wondering if these echo repeaters all work for Gartner? So I'm proposing that all framework/checklist bashing should use the hashtag #ChecklistIsDead from now on.
My point is that one of the biggest reasons InfoSec is failing is not because we are using a bad checklist. We are failing because we aren't actually following through with implementing *any* checklist consistently, whether it is the PCI DSS, FFIEC, FISMA, NIST, or the SANS Critical Security Controls. I don't really care which checklist you are being graded on (most of them can be cross-referenced with each other anyway, just different wording for the same basic goals), but if you can't make a list of your key business process, a list of your critical information assets, and updated diagrams for your network and data flow... then what makes you think that you are going to do any better with the newest #RiskManagement flavor of the week?
For example, I hear a lot of people complaining about the PCI DSS in one breath and then calling for the need to replace checklists with a risk based approach to security. That's all fine and good, but if companies can't comply with the intent of PCI DSS v2.0 Requirement 12.1.2 to perform a risk assessment [only] once per year, then how well are they going on their own without such a requirement?
Establish, publish, maintain, and disseminate a security policy that "12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)"
I have read some articles lately (here and here) that talk about how security policies and frameworks are too silo'd and need to span across functional boundaries. I'm sorry, but show me what framework or checklist specifically calls for its implementation to be contained within silos? These failed implementations are the direct result of bad decisions made at the highest levels of most companies who don't understand the threats and vulnerabilities facing their organizations. Yet these same decision makers are supposed to magically understand the risk derived from these same threats and vulnerabilities in order to invent a better #RiskManagement program that fixes their security failures?
All the while, taking time to actually implement the items on the existing checklists keeps slipping through the cracks or falling down the priority list (and just getting a QSA to submit your RoC to the cardbrands doesn't mean your company has actually implemented all of the requirements on the checklist).
There were several interesting items listed in a recent paper by James Lewis of the Center for Strategic & International Studies, Raising the Bar for Cybersecurity.
"In the last few years, in 2009 and 2010, Australia’s Defense Signals Directorate (DSD) and the U.S. National Security Agency (NSA) independently surveyed the techniques hackers used to successfully penetrate networks. NSA (in partnership with private experts) and DSD each came up with a list of measures that stop almost all attacks.
"DSD found that four risk reduction measures block most attacks. Agencies and companies implementing these measures saw risk fall by 85 percent and, in some cases, to zero."
<sarcasm>Too bad checklists are dead.</sarcasm>
Great comment in this week's SANS NewsBites (Vol. 15 Num. 029) from Alan Paller, director of research at the SANS Institute.
[Editor's Note (Paller): As organizations discover there is economic liability for lax cybersecurity, and lawyers smell blood in the water, the recognition will dawn on policymakers that their reliance on high level "guidance" was a really bad idea and made government cybersecurity a terrible model for protecting the critical infrastructure and businesses. This week the Australian Attorney General established a legal requirement that all agencies implement a small number of critical security controls. No company can pretend they don't know the basic controls they must implement. The U.S. government will do that, too, but, as Winston Churchill said so long ago, "Americans will always do the right thing - after exhausting all the alternatives." You can get a head start on doing the right thing if you can get to London on May 1-2 (http://www.sans.org/event/critical-security-controls-international-summit) or listen in on the briefing on April 18. (http://www.sans.org/info/128297]
I found this comment somewhat ironic, given the recent twitter conversation with @joshcorman:
Maybe "Best Practices" really aren't the absolute "Best" that we can do in every individual situation. And can they really be called "Practices", if they aren't actually practiced? (i.e. repeated performance or systematic exercise for the purpose of acquiring skill or proficiency). Having cursory familiarity with an established checklist of known good security measures such as the SANS Critical Security Controls, does not qualify as practicing or best. ;)
Also, check out Cindy's article about being Consumers of Security Intelligence here.