Angry Bear points me to the beginning of what promises to be an excellent series of posts about Bad Thinking Habits.

His list of Bad Thinking Habits he promises to analyze includes:,

*Choice of percentages vs. dollars. [See my confession below.]

*All-or-nothing thinking. [Stay tuned.]

*Confusing hindsight with foresight, or hindsight with insight.

*Being a slave to habits.

*Filtering out unwanted conclusions.

*Staying married to earlier positions. (Being born to a belief; being a victim of history or family.)

*Focusing too much on arbitrary time segments (years, months, weeks) when time is continuous.

*Failing to account for diminishing marginal utility.

*Overgeneralization.

*Overly strong or weak time preference.

*Changing value of time vs. money

*Splitting the difference when inappropriate.

Coming from a respected economist (and former Dallas Federal Reserve Bank President & CEO), this can’t be too bad, even if I don’t necessarily agree with his economic positions.

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

He doesn’t call them by name, but Cory Doctorow nails the human inability to deal with Black Swans, the Very-High-Impact, Very-Low-Likelihood event perfectly.

The single most pernicious threat to liberty today is humanity’s natural
tendency to misunderstand the statistics of rare events. We’re just not wired to have good intuition about things that happen with extreme infrequency.

I’ll prove it. If we were good at understanding statistics, then here’s what would happen when you flew to Las Vegas. You’d step out of McCarran airport, stare down the Strip at all those glittering, palatial casinos and say to yourself, “Holy crap – think of all the suckers who must have lost everything to finance this place!” Instead, our foolish minds are filled with thoughts like, “Man, look at all the money in this town – I’m going to win big!” And another casino is built.

He spoke about two miles from my house on his book tour a week ago, but I was unable to make it. *sigh*

As an FYI, I’ll be at SecureWorld in Chicago (really, it’s out in the ‘burbs in Rosemont) Wednesday and Thursday. I’ll be on Glenn Kapetansky’s panel on Virtualization Wednesday afternoon (”Desktop Virtualization as a Security Mechanism (Did We Stuff Glue in Our USB Ports Too Soon?)”) and roaming around various and sundry other presentations, keynotes, etc. the rest of the time.

Should be a good time.

I can’t properly attribute this, since my wife sent it to me as an email, but I still wanted to share:

Last night my sister and I were sitting in the den and I said to her, ‘I never want to live in a vegetative state, dependent on some machine and fluids from a bottle to keep me alive. That would be no quality of life at all, if that ever happens, just pull the plug.’ So she got up, unplugged the computer, and threw out my wine.

She’s such a bitch.

Happy Friday, everyone!

Mike Rothman is skeptical that there will be a “security industry”, and I don’t disagree with him.

I think there will be 0 security professionals in 2012. That’s right, ZERO. I think there will be network folks that specialize in security, and also some data center folks and even more application folks that are security specialists. OK, these are word games and a bit of semantics, but I think it’s an important point. If anyone thinks their only job is going to be security in 4 years, I suspect they’ll end up as a petroleum product sooner rather than later. OK, maybe not 2012, but I’m with most of the big mouth security pundits in saying security as a business will be going away within a reasonable long term planning horizon (7-10 years).

Of course, this leads me to wonder who, exactly they think is going to do security work. And by “security work,” I don’t mean running Anti-Virus or pleading with sysadmins to patch their boxes. That’s Console Jockey work and it will go the way of all other Run jobs–overseas and down to helpdesk pay levels. When I talk about Security Work, I mean the job of determining the appropriate level of risk for the organization, then defining the mix of controls and tools across people, process and technology to actually achieve it.

Senior Executives don’t know. They just want to know that they’re not having to explain incidents to the press and that I’m still pushing back on every task because my budget is stretched (their measure of whether or not I’m “appropriately funded”).

IT doesn’t know either. If anything, I’m seeing the competence trend running in the other direction in terms of what it’s reasonable to expect an “IT Person” to know about the technology they’re responsible for. More and more, it’s getting harder to even find anyone who actually does the work of touching the technology. I can find Project Managers, Relationship Managers, Program Managers, Application Managers, Support Managers, and every other kind of manager under the sun. What I can’t find are SysAdmins, DBA’s, Developers, or Engineers, and I find this disturbing.

For example, in a recent discussion of what should be the required fields in our application inventory tool, the question came up as to whether or not the data center where the production environment resides should be required. The answer was, “no,” because apparently that’s too much for a system owner or application support person to know–what building their app’s servers sit in. I wish this were an anomaly, but I’ve seen a steady increase in incidents like these, and not just at my current company, either.

And what tech talent do see, I increasingly wouldn’t bring back from the phone screen if I were the hiring manager. I’ve seen Web developers who didn’t know the difference between the corporate LAN and the Internet from a network visibility/connectivity perspective. I’ve seen support leads who didn’t know how to connect to the application they supported. I’ve seen DBA’s who didn’t know what an index was! These people don’t even understand fundamental aspects of their own core competency and we think they’re going to absorb a volume of knowledge and skills that most specialists can even seem to master?

So who’s going to do this work? The applications aren’t going to secure themselves. This is a simple fact, and even if the application can somehow be declared “secure” (which is to say, “secure enough”) in a vacuum, as soon as it starts interacting with users and other applications, all bets are off. Once again, someone has to decide how much security is enough for those interactions, either by declaring a standard or doing a risk assessment and determining what’s acceptable and what’s not.

While there might not be “Network Security” or “IT Security” as we know it today, I firmly believe that there are still going to be Information Risk and Information Protection specialists at all levels of the organization. Just because we’re going to either evolve beyond the world of Console Jockeys or get a job with Rothman at Dairy Queen doesn’t mean that Security Professionals are going away–quite the opposite, they’re going to have to actually become professionals.

So is all hope lost? Not necessarily. Clay Shirky had some really interesting observations on social surplus which apply here as well. Social Surplus is time that a society no longer needs to spend on some activity. For example, people worked fewer hours in the second half of the 20th century, leaving time that had to be filled. In response, the United States came up with things it sitcoms and yardwork.

So if you take Wikipedia as a kind of unit, all of Wikipedia, the whole project–every page, every edit, every talk page, every line of code, in every language that Wikipedia exists in–that represents something like the cumulation of 100 million hours of human thought. I worked this out with Martin Wattenberg at IBM; it’s a back-of-the-envelope calculation, but it’s the right order of magnitude, about 100 million hours of thought.

And television watching? Two hundred billion hours, in the U.S. alone, every year. Put another way, now that we have a unit, that’s 2,000 Wikipedia projects a year spent watching television. Or put still another way, in the U.S., we spend 100 million hours every weekend, just watching the ads. This is a pretty big surplus. People asking, “Where do they find the time?” when they’re looking at things like Wikipedia don’t understand how tiny that entire project is, as a carve-out of this asset that’s finally being dragged into what Tim calls an architecture of participation.

Now, the interesting thing about a surplus like that is that society doesn’t know what to do with it at first–hence the gin, hence the sitcoms.

(if you want to know where the gin comes in, go read the essay–it’s well worth the time)

But consider that if we switch the scale & topics from “The TV Watching of Population of the United States” to “the use & maintenance of IT,” and then swap Wikipedia with “IT Security,” then other than the scale of it, the same opportunity is out there, if we can figure out how to drive it.

But is it possible to create a Social Surplus within (Enterprise) IT that would be devoted to both improved excellence and ensuring security, rather than just chopped off as cost reduction?