I had a thought on the way home from work this evening.

I’ve seen and heard several stories of late, both on the radio and in print, about the collapsing value of fuel-inefficient vehicles in the resale and trade-in markets, driven by the high cost of gasoline depressing sales.

Obviously, data points like Ford’s disastrous 20% decline in sales supports this premise. But what’s either thus far missing or undetected is the fraud–if a significant number of people now own vehicles that they cannot afford to drive, I would expect to see a steady growth in insurance fraud related to stolen or damaged vehicles.

Until I see evidence of that trend developing, I’m going to take that as evidence that people aren’t really ready to change their SUV-driving ways.

Also, it occurred to me that this could be quite beneficial to those people who actually need a truck or SUV to do their job, since a “work truck” just needs to be mechanically sound, rather than a status symbol. As such, while their demand is inelastic, the supply side will be flooded, reducing the TCO of their vehicle by some potentially-significant offset against the price of gas–if they can save $10,000-15,000 on the cost of a vehicle, that’s a lot of incremental gas bill.

Just thinkin’…

I was pleased to see that The Open Group is adopting a Risk Taxonomy based on work by the fine folks at Risk Management Insight:

With a goal of getting IT professionals to use standard terminology and eliminate ambiguity in expressing important risk-management concepts, the Open Group is finalizing a 50-page compendium of “risk-management and analysis taxonomy.”

The Open Group Security Forum’s risk taxonomy of about 100 expressions will not only address seemingly simple words such as threat, vulnerability and risk, but less common terms such as control strength.

The taxonomy study, which is expected to be publicly available around August, will be based on intellectual property contributed by Open Group member Risk Management Insight.

Congratulations to Alex, Jack, and everyone who’s been working hard on this specific effort for at least a couple of years.

I guess now I won’t get to write definitions posts any more. Oh, well. A small price to pay for a lingua franca of risk.

Jerome left me an interesting comment on what’s probably my most popular post ever, “Security versus Risk Management.”

Information Security was here before the term Information Risk Management. I still want to know what are the baselines, the metrics, and the guiding standards for Information Risk Management. IRM points to directly the security standards and baselines like ISO 27001.

If it sounds like a duck, quacks like a duck its Security. I believe IRM is a marketing scheme for non-security professional to dictate security controls through business models. Security does use risk management principles to identify threats and should we use counter measures (security) to protect this specific asset and then the security control is introduced and if the control will not be accepted by the company then the risk exception process should be initiated by security. This is the two places in the security model that risk review should be conducted.

Unfortunately, I think he’s confusing Compliance with Risk Management and giving more credit than is due to “Security.”.

While I’m sure some of you will extend and correct me, I’ll define Compliance as “the act of ensuring adherence to a defined set of standards and processes,” for the purposes of this post. Wikipedia has this to say:

In general, compliance means conforming to a specification or policy, standard or law that has been clearly defined.

Thus, Compliance is a mechanism for helping ensure an acceptable level of risk across the controlled entity, usually a company or organization. When done well, compliance is measured against a set of policies, procedures and standards which effectively define the organization’s acceptable level of risk. How that plays out in reality is often quite different, a failure that Jerome identifies.

Just as Security all-to-often ignores appropriateness of a solution to the scale of the problem, focusing on eliminating the risk rather than reducing it to an acceptable level, so Compliance emphasizes following rules without questioning if the rules are really appropriate to the size of the problem or effective at actually reducing the risk to the desired level.

Defining the desired/acceptable/tolerable level (generally used interchangably, but exact definitions of each term are out-of-scope here) of risk is the part of the exercise that is generally not performed, instead deferring to some third party’s published standards (e.g. ISO 27002, CObIT, NIST, etc.) combined with any applicable laws or regulations. This is an attitude I’ve never really understood. Sure, it may be cost-efficient on the front-end, but unless you don’t actually have the option of defining your risk tolerance (i.e. you’re in a regulated environment), then you’re missing out on a huge opportunity for competitive advantage since published standards are generally one-size-fits-all, which is just another way of saying, “fits everyone poorly.”

The stark contrast between the ideal (management determines an acceptable level risk) and the reality (security operations people make arbitrary decisions that effectively define IT Risk tolerance) is something that Alex Hutton has reminded me of in the past.

Sure, a published standard can provide a good baseline or taxonomy of items to be assessed, but should not be taken as gospel for all information, processes and systems across the board, nor should adopting a standard be confused with Risk Management.

Risk Management, as I attempt to practice it, is the act of ensuring that:
1) The scale and scope of the problem are understood;
2) The problem is actually worth having (i.e. should not simply be avoided) or just documented and tracked as an exception (i.e. accepted);
3) The scale and cost of the solution are appropriate; and
4) The proposed management approach actually produces an acceptable level of residual risk for an appropriate level of cost and effort.

The devil, of course, is in the details of how you get to #4.

Risk Management is, first and foremost, about determining how to respond to the risk: Mitigation, Acceptance, Transfer, or Avoidance. Automatically assuming that the solution to a problem or threat is to develop countermeasures (mitigation) is something of a giveaway that someone is not really managing risk.

There has been a flurry of news stories of late about how high gas prices have people turning to scooters. You’re expected to listen to the “high gas prices drive scooter demand” angle, but the whole thing falls apart if you actually work the numbers. I like to think of this as “Metrics Judo”–turning someone’s own facts and figures back on them to get to the core of the argument.

As my old boss used to advise, “Before you get into any discussion of the issues, always make sure everyone agrees on the facts.”

For example, this morning I heard this story on NPR while driving to work. I was going to ride my scooter, but they’re predicting severe thunderstorms for the afternoon commute, which is no fun at all on two wheels, so I took my wife’s car. She’s not terribly pleased, but that’s life sometimes. If I had a public transit option, I’d take it in a second.

Getting back on topic, this story has a stronger safety component than most stories of its ilk–it actually stresses that scooters are dangerous, for a change, something that I have harped on in the past.

That part I liked.

But what I didn’t like was that the facts don’t actually support the story. First, the shop owner in SanFran said that his sales are up from ~6 scooters/month to his full shipment of 40/month. But he says he’s “thinking of” offering a promotion of “free gas all summer,” which he figures would cost him only $40/scooter. He also says that a scooter along with “all the safety gear” is only $3,000.**

If he’s selling out his inventory every month, why would he spend $1,600/month on a promotion? He’s supply-constrained, so the promo can’t increase revenue. The owner of a successful small business has to know that, or he won’t be a business owner for long. So, ignore everything but the cost per scooter–$40 or less than 10 gallons of gas per-scooter for the summer.

Then, we take that $40 cost over the course of the summer, compare it to the $3k-6k that people are spending for a scooter to save somewhere between $40 and $275* over the course of a “summer” (which I’ll define as May-Sept, or 5 months), depending on how heavily you want to weight the model in the scooter’s favor. That means that the average annual savings is between $100 and $700/year. This obviously doesn’t add up to the cost of the scooter, and it didn’t take anything but paying attention and some arithmetic to know that.

The only way that a scooter makes any sense at all is to do what I did–get rid of the car and buy the scooter instead. I did that and have been money ahead for years. The fact that I live in a highly-congested urban area where a scooter provides a tactical advantage in maneuvering through gridlock traffic and parking when I get to my destination is just gravy.

Now, turn this back to IT and/or Risk Management. How many times have we all been presented with data by some vendor which, with a little analysis, can easily be pulled apart and used to produce either the real value (rather than the one the marketing people want us to focus on) or, getting algebraic for a moment, allowed us to solve for the “real” data which, if we have to jump through these sorts of hoops, probably isn’t going to say what the vendor wants us to hear?

* Assume 60 mpg*10 gallons = 600 miles on a scooter, 30mpg*20 gallons = 600 miles in a car, so net fuel reduction of 10 gallons @ $4/gallon. Or, for a more fully loaded value, use $0.53/mile, the standard deduction for operating a vehicle, and now you’re looking at a cost avoidance of, at most, $278 ($318 - $40 for gas on the scooter, but no operating costs, so it’s still apples-to-oranges).

** He’s selling cheaper scooters than I ride. My scooter was $2,800, my helmet was about $250 on sale, I have two jackets, which were each about $200, my boots were over a $100 (leather, steel shank & toe, hard vibram soles), gloves another $50. A pair of armored trousers would be another $120 or so, which I’ll probably buy sooner than later now that I’m riding to work on a regular basis. Yes, I’m a bit of a safety nerd–I got of easily on learning that lesson the hard way.

Pete Lindstrom was kind enough to ping me asking what my take on Coverity’s latest static analysis report has produced. And, like a moth to a flame, I was unable to resist the urge to spit out a few thoughts on the topic.

Anyway, I took a quick skim through the new report and my short form answer is that I still think that it’s data which will be used as FUD. Is it a metric? Yes, but it’s an operational metric and does not pass the “So what?” test of a business or technology leader, since from their perspective, a package is either “good enough” or it’s not. Once the decision of “good enough” is made, it only becomes relevant again if the residual risk after countermeasures and other controls is in place significantly exceeds the sum of the replacement cost plus the expected residual risk of the replacement solution. Unless there’s a massive security latent security issue in the code, that’s a balance which will rarely be exceeded. And since, in general, “doing nothing is free,” that makes migration due to something as ethereal (in most people’s minds) as security pretty much impossible.

As to the study itself, its applicability is best understood if by thinking of it as a Risk Assessment where the scope is limited to a small-but-significant set of self-selected open-source projects. Anything else is apples to bananas. I can use it to look at trends in static analysis-detectable vulnerabilities over time to identify which of the participating projects are improving or degrading in expected security defects that Coverity can identify, but even that’s not a given. If you read the sidebar on page 10, it essentially acknowledges what was stated on page 9, which is that 52% of code errors are either null-pointer dereferences (segfaults) or memory leaks. Tom Ptacek would be a much better person than I to to analyze this data, however, since it’s what he does all day every day.

So as I see it, takeaways from the report are:
- you can’t use this to compare open-source to closed-source, since no closed source data exists
- You can’t use this as representative of open-source code in general, since it’s a self-selecting population of projects with a strong commitment to secure coding to begin with
- Most people still won’t understand what this report actually tells them

- You can use this to trend the improvement(decline) of code quality (not necessarily security) of an individually tracked project (which they note on about page 22)
- You can use this to identify specific open source projects that take security & quality especially seriously
- My pet peeve that people always provide mean but almost never median statistical data is alive and well in this report