• Love, love, love this piece :-) Remember the "robotic gun rampage" stories from last year? How does this sound: "The gun can track 360 degress, but there is a software-driven safety zone that makes sure rounds don't blow the rotors off. If the Osprey has to maneuver away from the target and the crew chief can't hold the gun on the bad guys manually, the system slaves the gun to the point of the last shot, slewing it as the plane moves." (watch the fun video there too)
  
• "Security idiot" meme lives on - go here. BTW, the post is a follow-up to this
• A fun follow-up to my post on compliance approaches titled Is PCI DSS "Too Prescriptive"?
• Finally, my fave post: "Increase Your Logging." I am sooooo happy that logging evangelism is spreading far and wide! A quote from the paper: ”Logs are interesting, logs are fun, logs should be done by EVERYONE…..get to logging!!!” (I promise that specific case was not my quote, even though I do say that very thing all the time!)
  

1. Great paper that complements the whole "SIEM is dead?" saga - "Most enterprises are looking for a product that will solve all of their problems in some sort of off-the-shelf miracle, and when they find out that the currently available tools can't do it, they either postpone their deployment or put them on the back burner. "
2. "The Mess: looking for someone to blame?" is an awesome piece on Internet security and its architecture - and so is Gunnar's follow-up ("If a tree falls in someone else's silo...")
3. Mike call to "Rise up against Mediocrity."  - "Dilbert makes the risk of the lowest common denominator approach abundantly clear."; in other words, you say 'best practices', I say 'mediocrity!' Mike also remind us, in vain, to do "Security FIRST!" (and compliance second)
4. A great piece from Burton: "On Response" - I think the world needs another 10-20 million reminders that PREVENTION FAILS. This is definitely a good one for those still in the "we'll just block the threat world" - "we will not win a continuing war of escalation" and "using response can be more cost effective than installing the latest and greatest preventative tool"
5. More on metrics, including the highly-awaited ISO27004.
6. Pretty dumb paper by a person confused by why PCI DSS exists (the guy needs to read this). PCI doesn't "fall short," it helps people who will otherwise not do anything and their systems will "power" those botnets of the future...
7. While we are on this subject: a really good coverage of PCI 1.2. changes, released Oct 1st. More PCI fun here. And more here ("PCI Compliance - dispelling some common myths"). And, more PCI myths. And more good ideas on PCI from Mike R. Sorry, can't stop thinking about PCI :-)  - also this is good.
8. Adrian on behavioral monitoring; mostly in DAM, but also elsewhere in security.
9. "Premature Chasm-Crossing"  - a must-read for all security vendors and especially their marketing (and  their easily-excitable PR teams...) - "Shouldn't vendors be spending more time fighting the problems that security managers are facing today, right this minute?" (Mike R also comments on that). A related - and  just as interesting point is made here: "Security is not a solution"
10. More on compliance and security checklists, good and bad: "I think this is a dangerous trend unless the "checklist" is all inclusive." (how can a checklist include ALL? :-))
11. "SANS Top 7 New IR/Forensic Trends In 2008"
12. Read "The three approaches to computer security!"  Why? Come on, it is from Joanna! :-)
13. A fun discussion about a hot new technology: network IDS. Is IDS absolutely indispensable to ALL companies? No. Can it be incredibly useful? You bet. End of discussion.
14. On an unrelated note, are lasers the future of warfare? Some say no.
15. Finally, some security humor from Gartner (!): "Get Rich Quick With Network Security"

Enjoy!

Previous security reading.

I’d love to have another blog even more specific - “Ok, that Assurance is Evidence Of What, Exactly?

Today he has a great article called:

What’s the matter with Risk Management?

And “in short, it’s everything.” It pretty much sums up why I had to grow to re-evaluate how our industry does risk, risk management, approaches controls & vulnerability and find a new way.   A couple of things jump out at me in reading Chris’ article:

1.)  Just because that Deming cycle sucks and is full of unknowns doesn’t mean “risk” doesn’t exist, nor that it isn’t of primary importance. Nor does it mean that in the absence of model & methodology, we won’t be “doing” risk analysis anyway - just in an ad hoc method and completely from “the gut”.

Our industry calls these unstructured risk analysis “Best Practices”, as it’s an easy and convenient way of sweeping the unknowns under the rug of bureaucracy and enforcing it via peer pressure.

2.)  What this “suckiness” does mean is that your model and methodology aren’t helping you. As Chris intimates, there is too much uncertainty in the inputs for his model (they are, in the language of Bayesians - too subjective to be useful priors).

Take for example how we might be approaching the “controls” part of our analysis.  Chris writes:

“2. What are the controls that we have to employ?
800-53, ISO 27001, PCI, etc.

Still kinda good, but we basically know that ISO is relatively voluntary and NIST supplies a control catalog and not policies. So here we have to take the control catalog, and mash our policies into it.”

I wouldn’t call this “kinda good” at all :)  These control catalogs only provide a hierarchy within which to look for evidence of  our ability to resist an attacker.  They are incapable of making any claim about the effectiveness of the controls when they are operated at 100% efficiency, or more importantly, what % efficiency our specific organization operates at.

Let’s use Chris Hayes’ Initech as our fictional example.

Initech has a control (a back door on a loading dock).  Now the locks on the door are 100% capable of locking the door.  This is different than saying that they are capable of frustrating all but the top 5% of lockpicking burgalars.  It is also diffferent than saying that in a sample of several “walk around audits” the doors are left open 20% of the time (they are not in compliance with policy 100% of the time).  Even worse, that 80% of the time the door is not propped open?  Yeah, tailgating is a known issue.

So we have several different variables here that we need to account for (and it’s just a door).  But the analogy stands that most “risk management” methodologies are “We have a door, yes/no?” And most GRC platforms, when asked for their “opinion” will simply say “door is needed” or, even worse, “a door policy is needed”.

3.)  Criticality and the Source of Value is all messed up in these Risk Management models.

Chris writes:

Someone wants me to tell them which boxes are more critical than others. This is mainly because of budgetary or operational reasons. To which I usually say “All of them, it is a system after all”.

This literally made me laugh out loud.  And this sort of “rate the firewall as Risk = 500 but rate the actual business application as Risk = 157″ thing is also endemic.  Now Chris is very smart here.  He correctly identifies that the value is tied to the business process the systems support, and not to a specific box.  Oh, we scan at the specific box level - but because of the nature of systemic failures - all the boxes in the process are inexorably interrelated.

One of the reasons I really like FAIR is that the losses are quantified (or qualified) based not on some amorphous value of the box or the process itself, but losses are linked to the actions that the threat will take. Take systems in a highly regulated industries as an example.  Usually the most probable losses aren’t due to system compromise per se, but in the disclosure the compromise causes (regulators are a threat source, after all).  But many “risk management” methodologies will say “online banking is worth $2 billion, the value of the systems is therefore $2 billion”.  And suddenly we’re telling executive management that there’s a 60% probability that they’ll lose $2 billion.

4.)  If the primary source of prior information for your “risk management” methodology is a vulnerability scanner - you’re doing it wrong.  Chris writes:

So we ran a scan and now we have a report. A snapshot in time to make all decisions. Where did these vulnerability ratings come from? Do I even know if my system is at risk? What if I spend my time on vulnerabilities that have no threat?

So first, my thoughts are that actual “vulnerability” must be a comparison of the force a threat can apply, and our ability to resist that force (this is a probability statement, btw).

Changing your thinking about vulnerability now helps us understand the problem in several new ways.  First, you can start to divorce yourself from the scanner.  After all, the scanner is simply providing you with current state information that is usually just relevant variance from policy. It doesn’t really tell you about real “weakness in a system” because the system is an interrelated mess of people, processes and IT assets.

5.)  Finally, most “risk management” approaches just *don’t* do a good job of helping us understand the how’s and why’s of managing risk. In the past, I’ve referred to these standards as really being “issue management” because they are at their heart, an act of discovery - a formal process around gathering prior information.  They are not, in and of themselves, capable of linking the issues discovered to the root cause.  And these root causes?  Yeah, they’re the things that create “risk”.  Not a threat, not a vulnerability, not the existence of an asset - the amount of risk that we have stems from our capability to manage it.

So Chris, I completely agree - but I wouldn’t give up yet.  There actually are a few of us who are focused on what you suggest:

Where to go from here: A fundamental revamp of how to deal with Risk. Where risk professionals focus on the treating the sickness and not the symptoms, and come up with some new success/actionable metrics.

Chris, there’s nothing I want to do more than that.

I used to react to this with "Are you stupid?! PCI being prescriptive is the best thing since sliced cake :-) Finally, there is some specific guidance for people to follow and be more secure!" BTW, in many cases end users who have to comply with PCI DSS still think it is "too fuzzy" and "not specific enough" (e.g. see "MUST-DO Logging for PCI"); and they basically ask for  "a compliance TODO list." (also see this and especially this on compliance checklists)

But every time it happens, I can't stop but think - why do people even utter such utter heresy? :-) And you know what?  I think I got it!

When people say "PCI is too prescriptive," they actually mean that it engenders "checklist mentality" and leads to following the letter of the mandate blindly, without thinking about WHY it was put in place (to protect cardholder data, share risk/responsibility, etc). For example, it says "use a firewall" and so they deploy a shiny firewall with a simple "ALLOW ALL<->ALL" rule (an obvious exaggeration - but you get the point!) Or they have a firewall with a default password unchanged... In addition, the proponents of "PCI is too prescriptive" tend to think that fuzzier guidance (and, especially, prescribing the desired end state AND not the tools to be installed) will lead to people actually thinking about the best way to do it.

So the choices are:

1. Mandate the tools (e.g. "must use a firewall") - and risk "checklist mentality", resulting in BOTH insecurity and "false sense" of security.
2. Mandate the results (e.g. "must be secure") -  and risk people saying "eh, but I dunno how" - and then not acting at all, again leading to insecurity.

Take your poison now?! Isn't compliance fun? What is the practical solution to this? I personally would take the pill #1 over pill #2 (and that is why I like PCI that much), but with some pause to think, for sure.  I think organizations with less mature security programs will benefit at least a bit from #1, while those with more mature programs might "enjoy" #2 more...

BTW, this post was originally called "Isn't Compliance Fun?!"  I had a few fierce debates with some friends and all of them  piled on me to convince me that "compliance is boring, while security is fun!" The above does illustrate that there are worthy and exciting intellectual challenges in the domain of regulatory compliance. It is not [only] a domain of minimalists (who just "want the auditor to go away") and mediocrity, as some think. What makes security fun - the people aspect, the ever-changing threat landscape, cool technology, high uncertainty, even risk - also apply to compliance ...

So, need a cool marketing slogan BUT hate "making compliance easy"?  Go for "Making Compliance Fun!" :-)

All posts on PCI - some are fun:-)