These came across the SIRA mailing list. They were so good, I had to share:
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.
The Blog Inspired By The Book
These came across the SIRA mailing list. They were so good, I had to share:
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.
“To have physical possession of the data, you also have to own and maintain the data storage hardware and software.”
“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.”
“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 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.”
“Customization and integration of cloud services are neither intrinsically better nor inherently worse than the capabilities of an on-premise stack.”
Interesting interactive data app from the Wall Street Journal about your privacy online and what various websites track/know about you.
Full disclosure, our site uses Mint for traffic analytics.
Cisco has their security report up – find it here. My favorite part? ”The Artichoke of Attack”
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.
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.
Hi,
I’m very interested right now in finding the quality of risk analysis as it relates to operational security. If you’re a risk analyst, a security executive, or operational security analyst, would you mind taking a one question survey? It’s on SurveyMonkey, here: http://www.surveymonkey.com/s/GCSXZ2Q”
adapted from the t-shirt seen in the anton corbijn work here.
With all apologies to both
Paul Morely and Katherine Hamnett.
And that’s about all I have to say on the subject.
In comments to my “Why I Don’t Like CRISC” article, Oliver writes:
CobIT allows to segregate what is called IT in analysable parts. Different Risk models apply to those parts. e.g. Information Security, Architecture, Project management. In certain areas the risk models are more mature (Infosec / Project Management) and in certain they are not (software distribution). That is for the risk modelling (sic) part.
For risk identification and KRIs (note to readers: I’m assuming Oliver means Key Risk Indicator – a useful but loaded phrase itself), an internal control framework which is based on cobit allows an adequate and comprehensive net of indicators for risk assessment based on operational performance.
If you think that “some things can’t be measured” will prove your thesis, you don’t know Risk Management at all.
There is no mathematical voodoo to model a risk exposure which is 100% correct.
You have to keep the purpose in mind and also use professional judgment based on your experience (which CRISC by the way tries to attestate)
You fight against an attestation which takes into full consideration your own challenge.
(…I’d argue that IRM shouldn’t be part of an MIS course load, rather it’s own tract with heavier influences from probability theory, history of science, complexity theory, economics, and epidemiology than, say, Engineering, Computer Science or MIS.)
IRM is not (just one) “process”. Now obviously certain risk management standards (document a simple) process. In my opinion, most risk management standards are nothing BUT a re-iteration of a Plan/Do/Check/Act process. And just to be clear, I have no problems if you want to go get certified in FAIR or OCTAVE or Blahdity-Blah – I’m all for that. That shows that you’ve studied a document and can regurgitate the contents of that document, presumably on demand, and within the specific subjective perspective of those who taught you.And similarly if ISACA wants to “certify” that someone can take their RiskIT document and be a domain expert at it, groovy. Just don’t call that person “Certified in Risk and Information Systems Control™” because they’re not. They’re “Certified in our expanded P/D/C/A cycle that is yet another myopic way to list a bajillion risk scenarios in a manner you can’t possibly address before the Sun exhausts it’s supply of helium.” “TM”
When opining on security in “the cloud” we, as an industry, speak very much in terms of real and imagined threat actions. And that’s a good thing: trying to anticipate security issues is a natural, prudent task. In Lori McVittie’s blog article, “Risk is not a Synonym for “Lack of Security”, she brings up an example of one of these imagined cloud security issues, a “jailbreak” of the hypervisor.
And that made me think a bit because essentially, we want to discuss, we want to know, “what will happen not if, but when vulnerabilities in the hypervisor, or cloud api, or some new technology bit of cloud computing actually are discovered and/or begin to be exploited?”
Now in baseball, sabermetricians (those who do big-time baseball analysis) break the game down into three true outcomes – walk, homerun, strikeout. They are called the three true outcomes because they supposedly are the only events that do not involve the defensive team (other than the pitcher and catcher). A player like Mark McGwire, Adam Dunn, or if you’re old-school, Rob Deer are described as three true outcome players because their statistics over-represent those outcomes vs. other probable in-play events (like a double or reach via error or what have you). Rumor has it that Verizon’s Wade “swing for the fences” Baker was a three true outcome player in college.
In Vulnerability research and discovery, I see three true outcomes, as well. Obviously the reality isn’t that an outcome is always one of the three, just as in baseball there are plenty of Ichiro Suzuki or David Eckstein-type players whose play does not lend itself to a propensity towards the three true baseball outcomes. But for the purposes of discussing cloud risk, I see that any new category of vulnerability can be said to be:
1.) Fundamentally unfixable (RFID, for example). If this level of vulnerability is discovered, cloud computing might devolve back into just hosting or SaaS circa 2001 until something is re-engineered.
2.) Addressed but continues to linger due to some fundamental architecture problem that, for reasons of backwards compatibility, cannot be significantly “fixed”, but rather involves patches over and over again on a constant basis.
3.) Addressed and re-engineered so that the probability of similar, future events is dramatically reduced.
Now about a year ago, I said that for the CISO, the move to the cloud was the act of gracefully giving up control. The good news is that in terms of which of the three we see in the future, the CISO really has no ability to affect which outcome will exist. But how cloud security issues are addressed long-term, via technology, information disclosure (actually the entropy of information disclosure), and contract language (how technology and entropy are addressed as part of the SLA) – these are the aspects of control the CISO must seek to impact. Impact that is both contractual and on her part, procedural – expecting one of the three outcomes to eventually happen.
The technology and information disclosure aspects of that contract with the cloud provider, well, they simply must focus on the ability to detect and respond quickly. Chances are your cloud farm won’t be among the first compromised when an eventual exploit occurs. But, especially if the value of what you’ve moved to the cloud has significance to the broader threat community, that doesn’t mean (as Lori says) you simply accept the risk. Developing contingency plans based on the three true outcomes can help assure that the CISO can at least cope with the cloud transition.
What You’ve Said