Petroski on Engineering

As I was reading the (very enjoyable) “To Engineer is Human,” I was struck by this quote, in which Petroski first quotes Victorian-era engineer Robert Stephenson, and then comments:

…he hoped that all the casualties and accidents, which had occurred during their progress, would be noticed in revising the Paper; for nothing was so instructive to the younger Members of the Profession, as records of accidents in large works, and of the means employed in repairing the damage. A faithful account of those accidents, and of the means by which the consequences were met, was really more valuable than a description of the most successful works. The older Engineers derived their most useful store of experience from the observations of those casualties which had occurred to their own and to other works, and it was most important that they should be faithfully recorded in the archives of the Institution.

Today Robert Stephenson would likely express the same hope, mutatis mutandis, about the failure of computer programs and the measures that have been taken to protect them.

Now, Petroski is talking about failures of computers in engineering, rather than the engineering of computers. But I think there’s little doubt that he’d say that the same applies to the engineering of computers. Both the chapter “The limits of design” and the new afterword are worth reading with an eye to what they can teach us about information security and disclosure. Actually, the entire book is worth reading, but the analogies are strongest there.

Measurement Theory & Risk Posts You Should Read

These came across the SIRA mailing list. They were so good, I had to share:

https://eight2late.wordpress.com/2009/07/01/cox%E2%80%99s-risk-matrix-theorem-and-its-implications-for-project-risk-management/

http://eight2late.wordpress.com/2009/12/18/visualising-content-and-context-using-issue-maps-an-example-based-on-a-discussion-of-coxs-risk-matrix-theorem/

http://eight2late.wordpress.com/2009/10/06/on-the-limitations-of-scoring-methods-for-risk-analysis/

Thanks to Kevin Riggins for finding them and pointing them out.

Dating and InfoSec

So if you don’t follow the folks over at OKCupid, you are missing out on some hot data. In case you’re not aware of it, OKCupid is:

the best dating site on earth. Compiling our observations and statistics from the hundreds of millions of user interactions we’ve logged, we use this outlet to explore the data side of the online dating world.

And in their latest post, they explore what brand of camera makes you look good. You should go read “Don’y be ugly by accident.” I’ll wait.

You’re back? Ok. So here, let me lay this out for you. These folks are applying science, not to dating, but to online dating profiles. They’re not slinging some best practice shtick, or re-writing profiles at $50 a pop, they’re telling you exactly what photos work and which ones don’t. How are they doing this? Data. Experiment. Analysis.

I don’t want to understate the importance of finding a good partner, but I will say how sad it is that they have all this data on this highly intimate activity, and we have 2,000 entries in DatalossDB.

Making it up so you don’t have to

If you don’t have time to develop a data-driven, business focused security strategy, we sympathize. It’s a lot of hard work. So here to help you is “What the fuck is my information security ‘strategy?’ “:

infosecstrategy.png

Thanks, N!

New low in pie charts

It’s not just a 3d pie chart with lighting effects and reflection. Those are common. This one has been squished. It’s wider than it is tall.

CenzicPieChart.png

While I’m looking closely, isn’t “input validation” a superset of “buffer errors” “code injection” and “command injection?”

You can get the “Application Security Trends report for Q1-Q2 2010” from Cenzic. I’ve been generally impressed by the founders and other work I’ve seen for a long time, and I look forward to beautiful and effective data presentation in their future reports.

Illogical Cloud Positivism

Last we learned, Peter Coffee was Director of Platform Research for salesforce.com.  He also blogs on their corporate weblog, CloudBlog, a blog that promises “Insights on the Future of Cloud Computing”.
He has a post up from last week that called “Private Clouds, Flat Earths, and Unicorns” within which he tries to “bust some myths” about Cloud Security. Now most of the time, corporate blogs are almost always light on content, but at least most of the time they are banal, emasculated vagaries that can neither be too stupid nor particularly insightful.  Well, not this one.
This blog post is so dangerously filled with complete and utter cowpie that I could not but respond here – it is fundamentally contrary to the concerns James Arlen and I wrote for the IRM chapter of the CSA document.
It is a completely Cloud-tarded article.
WHAT?  A SAAS PROVIDER RAILING AGAINST PRIVATE CLOUDS?!?!  I CAN’T BELIEVE IT!!!
First, Peter makes the assertion that when IT managers are surveyed and state a strong preference for “private clouds” and that this is a desire, not their choice, and subsequently ridicules IT managers for having that desire.  His claim is that:
“To have physical possession of the data, you also have to own and maintain the data storage hardware and software.”
This is a dangerous assertion for a cloud provider to make.  The semantic game he’s playing here is around the word “possession”.  I’ll agree that it is impossible to have physical possession without ownership of the infrastructure.  Fine.  But this is NOT what security and responsibility (both ethical and legal responsibility) in cloud computing is about.  Cloud Risk Management is not about possession, it is about custodianship.  If I put credit card numbers in your (his) cloud, I am still, in the eyes of class action lawsuits at least, it’s custodian.  Looking at all forms of loss associated with a data breach, there is no pure, 100% transfer of risk.  And *this* is the problem IT managers face.
COFFEE’S NAIVE IMPACT MODELING
A desire for security (more below) operations stems solely from the fact that risk is not completely transferred.  What do I mean?  If my bank puts my banking data in Salesforce.com and there’s a breach, yes – I’m going to be mad at Salesforce.  But I’m going to pull my money (and it’s earning potential) out of my bank because some Cloudtard over there decided that this was a good idea.
In other words (use ISO 27005, FAIR, VERIS, whatever) Primary Loss Factors are only half the impact model.  And maybe the Cloud Provider owns some of that loss, maybe they don’t.  Secondary Factors are still borne solely by those that use the cloud provider.
BEING GOOD AT OPSEC IS A CRITICAL COMPONENT IN RISK MANAGEMENT
“If you have operational control of the infrastructure you have to employ and supervise a “team of experts” who spend most of their time waiting to respond to critical but rare events.”
One has to but wonder how often Peter talks to his own OpSec guys.  I imagine (sincerely  hope) that the CIRT team at Salesforce absolutely cringed when they read this.  Indeed, my sympathies go out to you,  Your Supreme Galactic Director Of Platform just called you a mostly useless operating expense, and you may have a little internal selling to do.
That aside, anyone who has heard me speak for the last year knows the stress I put on understanding your OpSec capabilities as a component of managing risk.  I won’t rehash those presentations (they’re online – use The Google) but both understanding the Cloud Providers capabilities and your ability to interact with them – that is the crux of managing risk in the cloud.
ILLOGICAL CLOUD POSITIVISM
“Security in cloud services can be constructed, maintained and operated at levels that are far beyond what’s cost-effective for almost any individual company or organization.”
The irony of this quote, of course, is that his linked supporting evidence is SalesForce’s statement of ISO 27001 compliance.  ’nuff said.
But in regards to the actual argument, the answer is: “maybe”.  If InfoSec is the study of the collision of multiple complex systems, and the cloud provider has a much more complex system to manage than you do on your own, the answer must be “maybe”.  To support such a statement we must identify models that are informative about cost to secure per $.  I haven’t seen much research around this, and certainly Coffee doesn’t link to any.
COMPLIANCE ISN’T A “ROLES” AUDIT
“The discipline and clarity of service invocations in true cloud environments can greatly aid the control of access, and the auditability of actions, that are dauntingly expensive and complex to achieve in traditional IT settings.”
I honestly have no idea what this means.  I take it that he’s saying that proof of access control and audit evidence is easier to gain just by casually tossing an email in the direction of your SaaS buddy.  But in terms of regulatory compliance (PCI DSS, HIPAA, OTHER ALPHABET SOUP) my experience is vastly different.
HEY, TECHNOLOGY IS TECHNOLOGY, RIGHT?
“Customization and integration of cloud services are neither intrinsically better nor inherently worse than the capabilities of an on-premise stack.”
This, of course, viewed in the context of the top two points Coffee makes, for the purposes of risk management, are statements with contradictory implications.  Let me some up what Peter says to me when I read this article:
“The cloud is easy to use. The cloud is easier to secure.  The cloud is friendly to auditors.” and   “The cloud is neither better nor worse than securing data on site.”
I’M STILL OK WITH THE CLOUD
With my years of SMB F.I. audit/PenTest experience, I don’t disagree that cloud computing may make sense from a risk management standpoint.  I’ve been appalled at times about the one guy in the middle of nowhere Midwest whose in charge of $200 million in credit union/pension fund assets.  The other thing to remember is that in fact, in many ways these SMB FI folks have been offloading financial machinations to partners for years – they are already “cloud users” by some informal lose definition.  But it’s an awfully cavalier attitude Mr. Coffee takes here with us making these assertions, esp. with no real supporting evidence.  Welcome to the NewSchool, Peter Coffee.  In God We Trust, everyone else brings data.

What They Know (From the WSJ)

Interesting interactive data app from the Wall Street Journal about your privacy online and what various websites track/know about you.

http://blogs.wsj.com/wtk/

Full disclosure, our site uses Mint for traffic analytics.

Cisco’s Artichoke of Attack

Cisco has their security report up – find it here.  My favorite part?  ”The Artichoke of Attack”

Society of Information Risk Analysts Webex/Meeting Tomorrow

Hey, just so you all know, SOIRA is having our lunch (or breakfast) Al-Desko Webex.  This month we have the pleasure of watching Chris Hayes show how to use quantitative risk analysis for real, pragmatic business purposes.  It’s going to be seriously useful.

Join SOIRA here:  http://groups.google.com/group/InfoRiskSociety?hl=en for the invite.

Survey Results

First, thanks to everyone who took the unscientific, perhaps poorly worded survey. I appreciate you taking time to help out.  I especially appreciate the feedback from the person who took the time to write in:

“Learn the proper definition of “Control Systems” as in, Distributed Control Systems or Industrial Control systems. These are the places that need real security, not some bullshit enterprise network.”

You, sir or madam, are chock full of rock and roll.  Thanks for cheering me up.

Next, the results were:

Daily = 6
a few times a month = 2
a few times a quarter  = 1
less than a few times a quarter  = 10
never  = 43

and the chart looks something like this:

UPDATE:  Jeff Lowder asked me to clarify this a bit.  I’ll start by re-iterating that this was a not really a proper survey, but akin to asking a handful of friends (the survey existence was announced here, on twitter, to a couple of security – centric mailing lists).  As such, don’t get all bent out of shape about it.

I was interested in the question – “how often does GRC analysis impact actual OpSec?” and decided that a frequency of interaction would be a pretty good bellwether.  The question (and results with proper caveats) were part of the presentation Allison Miller and I gave at Black Hat.  More on that presentation in a while, btw.