We get a lot of requests to sponsor this blog. We got several this week. Not just the spammy “Please link with us,” or “Host our content and make BIG $$$” stuff. And not the PR junk that says “We are absolutely positive your readers would just love to hear what XYZ product manager thinks about data breaches,” or “We just released 7.2.2.4 version of our product, where we changed the order of the tabs in our web interface!” Yeah, we get fascinating stuff like that too. Daily. But that’s not what I am talking about. I am talking about really nice, personalized notes from vendors and others interested in supporting the Securosis site. They like what we do, they like that we are trying to shake things up a bit, and they like the fact that we are honest in our opinions. So they write really nice notes, and they ask if they can give us money to support what we do.

To which we rather brusquely say, “No”.

We don’t actually enjoy doing that. In fact, that would be easy money, and we like as much easy money as we can get. More easy money is always better than less. But we do not accept either advertising on the site or sponsorship because, frankly, we can’t. We just cannot have the freedom to do what we do, or promote security in the way we think best, if we accept payments from vendors for the blog. It’s like the classic trade-off in running your own business: sacrifice of security for the freedom to do things your own way. We don’t say “No,” to satisfy some sadistic desire on our part to be harsh. We do it because we want the independence to write what we want, the way we want.

Security is such a freakin’ red-headed stepchild that we have to push pretty hard to get companies, vendors, and end users to do the right thing. We are sometimes quite emphatic to knock someone off the rhythm of that PowerPoint presentation they have delivered a hundred times, somehow without ever critically examining its content or message. If we don’t they will keep yakking on and on about how they address “Advanced Persistant Threats.” Sometimes we spotlight the lack of critical reasoning on a customer’s part to expose the fact that they are driven by politics without a real plan for securing their environment. We do accept sponsorship of events and white papers, but only after the content has gone through community review and everyone has had a chance to contribute. Many vendors and a handful of end-users who talk with us on the phone know we can be pretty harsh at times, and they still ask if they economically support our research. And we still say, “No”. But we appreciate the interest, and we thank you all for for participating in our work.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

  • Rich: Code Re-engineering. This applies to so much more than code. I’ve been on everything from mountain rescues to woodworking projects where the hardest decision is to stop patching and nuke it from orbit. We are not mentally comfortable throwing away hours, days, or years of work; and the ability to step back, analyze, and start over is rare in any society.
  • Mike Rothman: Code Re-engineering. Adrian shows his development kung fu. He should get pissed off more often.
  • David Mortman: Gaming the Tetragon.
  • Adrian Lane: The Secerno Technology. Just because you need to understand what this is now that Oracle has their hands on it.

Other Securosis Posts

Favorite Outside Posts

Project Quant Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Jack, in response to FireStarter: The Only Value/Loss Metric That Matters.

All of the concerns that have been raised about estimating impact are legitimate. Part of the problem with many approaches to-date, however, is that they’ve concentrated on asset value and not clearly differentiated that from asset liability. Another challenge is that we tend to do a poor job of categorizing how loss materializes.

What I’ve had success with in FAIR is to carve loss into two components–Primary and Secondary. Primary loss occurs directly as a result of an event (e.g., productivity loss due to an application being down, investigation costs, replacement costs, etc.), while Secondary loss occurs as a consequence of stakeholder reactions to the event (e.g., fines/judgments, reputation effects, the costs associated with managing both of those, etc.). I also sub-categorize losses as materializing in one or more of six forms (productivity, response, replacement, competitive advantage, fines/judgments, and reputation).

With the clarity provided by differentiating between the Primary and Secondary loss components, and the six forms of loss, I find it much easier to get good estimates from the business subject matter experts (e.g., Legal, Marketing, Operations, etc.). To make effective use of these estimates we use them as input to PERT distribution functions, which then become part of a Monte Carlo analysis.

Despite what some people might think, this is actually a very straightforward process, and simple spreadsheet tools remove the vast majority of the complexity. Besides results that stand up to scrutiny, another advantage is that a lot of the data you get from the business SME’s is reusable from analysis to analysis, which streamlines the process considerably.

Share: