Building

Our Favorite Subject: [It’s all about] Risk

Some days ago my old friend Pete Herzog from ISECOM posted a blog entry titled “Hackers May Be Giants with Sharp Teeth” here which – along with some quite insightful reflections on the way kids perceive “bad people” – contains his usual rant on (the uselessness of) risk assessment.
Given that this debate (whether taking a risk-based infosec approach is a wise thing or not) is a constant element of our – Pete’s and mine – long lasting relationship I somehow feel enticed to respond 😉

Pete writes about a 9-yr-old girl who – when asked about “bad people” – stated that those “look like everybody else” and, referring to risk assessment, he concludes “that you can’t predict the threat realibly and therefore you can’t determine it.”
I fully agree here. I mean, if you _could_ predict the threat realibly why perform risk assessment at all? Taking decisions would simply be following a path of math then. Unfortunately most infosec practitioners do neither dispose of a crystal ball – at least not a dependable one – nor of the future prediction capabilities this entity seems to have …
So… as long as we can’t “determine reliably” we have to use … risk assessments. “Risk” deals with uncertainty. Otherwise it would be called “matter of fact” 😉
Here’s how the “official vocabulary of risk management” (ISO Guide 73:2009) defines risk: “effect of uncertainty on objectives”.
Note that central term “uncertainty”? That’s what risk is about. And that’s, again, what risk assessments deal with. Deal with uncertainty. In situations where – despite that uncertainty – well-informed decisions have to be taken. Which is a quite common situation in an ISO’s professional life 😉
Effective risk assessment helps answering questions in scenarios characterized by some degree of uncertainty. Questions like “In which areas do we have to improve in the next 12 months?” in (risk assessment) inventory mode or “Regarding some technology change in our organization, which are the main risks in this context and how do they change?” in governance mode. [See this presentation for an initial discussion of these terms/RA modes].
So asking for “reliable threat prediction/determination” from risk assessments is just not the right anticipation. In contrast, structured RA can certainly be regarded as the best way to “take the right decisions in complex environments and thereby get the optimal [increase of] security posture, while being limited by time/resource/political constraints and, at the same time, facing some uncertainty”.

Btw: the definition from ISO 73:2009 – that is used by recently published ISO 31000 (Risk management — Principles and guidelines) too – nicely shows the transformation the term “risk” has undergone in the last decade. From “risk = combination of probability and consequence of an event [threat]” in ISO 73:2002 through ISO 27005:2008’s inclusion of a “vulnerability element” (called “ease of exploitation” or “level of vulnerability” in the appendix) to the one in ISO 73:2009 cited above (which, for the first time, does not only focus on negative outcomes of events, but considers positive outcomes as well. which in turn reflects the concept of “risk & reward” increasingly used in some advanced/innovative infosec circles and to be discussed in this blog at another occasion).
Most (mature) approaches used amongst infosec professionals currently follow the “risk = likelihood * vulnerability * impact” line. We, at ERNW, use this one as well.

Which brings me to the next inaccuracy in Pete’s blog entry. He writes: “Threats are not the same for everyone nor do they actually effect us all the same. So why do we put up with risk assessments?”.

Indeed (most) threats _are_ the same for everyone. Malware is around, hardware fails from time to time and humans make errors. Point is all this does _not_ affect everyone “the same way” (those with the right controls will not get hit hardly by malware, those with server clusters will survive failing hardware more easily, those with evolved change control processes might have a better posture when it comes to consequences from human error). And all this is reflected by the – context-specific – “vulnerability factor” in risk assessments (and, for that matter, sometimes by the “impact factor” as well). So while threats might be the same, the _associated risks_ might/will not be the same.
which, again, is the exact reason for performing risk assessments ;-))
If they _were_ the same one just would have to look up some table distributed by $SOME_INDUSTRY_ASSOCIATION.

So, overall, I’m not sure that I can follow Pete’s line of arguments here. Maybe we should have a panel discussion on this at next year’s Troopers 😉

have a good one everybody,

thanks

Enno

Continue reading
Building

News from Old Friends, Edition 2010/06/09

This is the first post of a – potential – series of rants on ubiquitous pieces of crap (security-wise), bothering pretty much every ISO I know.
I’m talking about “common desktop applications” and today’s topic is going to be the beloved Adobe Flash Player. Some of you who had the opportunity (or imposition 😉 to listen to one my talks covering “modern enterprise security space” (e.g. this one) might remember me saying sth like “If a fairy godmother turned up and asked me for three things to get rid of in order to enhance overall corporate information security in a sustainable way, my answers would be…” and then giving Adobe Flash as the first mention. (before you ask: amongst the other candidates are Apple Quicktime, Windows GDI and “Javascript in Acrobat Reader”).

And, yes, I can already hear all the yelling “But we absolutely need Flash on our corporate desktops.”. Maybe that’s really really the case. Maybe not. I’ve fought that fight in many environments, and usually lost it. Kind-of been there, done that. I’d just like to point out that – from a security point of view – this is a risky thing.
On a personal level I still do not get why Flash is needed. I can certainly be regarded as a “typical executive user”, being online most parts of the day and performing all sorts of (what I think) “typical actions” like travel booking, online financial services etc. All this can be done with my 64-bit browser that just has no associated Flash player. Seems my mileage as for “corporate browser use” still varies from the one in many of those – “we absolutely need Flash on our corporate desktops” – organizations…
And even if your company’s marketing dept is powerful enough to ask for large scale deployment of that fancy technology (some of you certainly know the “We have our own Youtube channel” argument) I still have to understand why it’s needed on the desktops in the engineering or R+D departments. But oh well…

Still, all this ranting is a bit outside the intended scope of this post. Actually the trigger for the post was this advisory titled “Security Advisory for Flash Player, Adobe Reader and Acrobat” and released by Adobe some days ago.
Here’s a little quote from the summary:

“A critical vulnerability exists in the current versions of Flash Player […] for Windows, Macintosh, Linux and Solaris operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat v9.x for Windows, Macintosh and UNIX operating systems. This vulnerability […] could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild via limited, targeted attacks against Adobe Reader v9 on Windows.”

Oops, sorry, in fact the quote above was from this advisory, initially released on july 22, 2009.
The current one (from 06/04/2010) goes like this (as for the summary):

“A critical vulnerability exists in Adobe Flash Player 10.0.45.2 and earlier versions for Windows, Macintosh, Linux and Solaris operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat 9.x for Windows, Macintosh and UNIX operating systems. This vulnerability (CVE-2010-1297) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild against both Adobe Flash Player, and Adobe Reader and Acrobat.”

Note the difference?
There’s practically none: same products affected, same component to blame, same workaround [deactivating authplay.dll], same “Adobe’s quality assurance element” [discovery of the stuff being exploited in the wild] responsible for public statement.
In short: SSDD.

Mitigation Approaches

Given I try to be a responsible citizen [and, for that matter, responsible security practitioner too ;-)] I’d like to discuss potential approaches as for the efficient mitigation of the risk of being attacked “actively in the wild” due to (not only) this vulnerability.
At ERNW, for many years we’ve been using sth we called “The small catechism of IT security” which was essentially a set of simple fundamental rules as for securing complex systems. This piece included, amongst others, these ones:

Minimal Machine.
Least Privilege.
Patching.

Following these lines some approaches come to mind and I’ll discuss some of those.

a) Do not run Flash at all. Yes, we had this discussion already. And, no: I do not live in a ivory tower. And I mainly consult to very large organizations.
Sure, this might be one of the fights you (as an ISO) just can’t win. But, heck, I still dare to post this on our very personal and ranty blog: Running Flash on corporate desktops is simply asking for trouble. Asking for trouble loudly. Very loudly.

It should be noted that, according to this, removing Adobe Flash (e.g. in the way described here) will not remove the instances of Flash Player that is installed with Adobe Reader 9 or other Adobe products.

There is always a lot of trade-offs in managing complex IT environments. There are business requirements – and, as we security folks know: business pretty much always wins (and this is fully ok, as security is not the most important thing in corporate life) -, there’s “cost considerations”, all sorts of politics and in the end of the day there’s our mission of getting the best possible security stance given all these considerations and trade-offs. Running vulnerable software to provide some business functions (while at the same time inducing the risk of getting owned) obviously is such a trade-off, and it’s a common one.

As for Flash one should just be aware that – in most environments – there’s only little business value of running it, but – in all environments – there’s quite some associated risk.

b) Do not run Flash embedded in PDFs (by deactivating authplay.dll as described in the advisories).

I think this is – security-wise – a very feasible approach (following that good ole security principle called “minimal machine”). Only problem might be that the stuff gets re-deployed/re-enabled next time you patch Adobe Reader. So operational processes might have to be adjusted to ensure it does not re-appear.
And, of course, this is an ugly one (deleting a dll), which might not be “aligned with your sw management and deployment processes” 😉
This document mentions that deleting another dll as well avoids the crashes when invoking a file with SWF code in it. Haven’t tested this though.

Btw: this is a preventative control. Whereas patching is a reactive one. Most probably I don’t have to tell any reader of this blog that preventative controls tend to have a better cost-impact ratio than reactive ones, do I? 😉

c) Patching. Hmm, unfortunately there is no patch as of today. And the stuff is “exploited in the wild” (Adobe, thank you! for letting us know, once more. What about just adding a checkbox somewhere in “Preferences” that allows to disable playing embedded SWF stuff at all?).
Furthermore patch cycles for Adobe products are quite long in most environments (due to the number of integration aspects and side effects).

So, dear reader who’s still sympathetic to patching (as for Adobe stuff): do not pass go, do not collect $200, but maybe re-read the last sentences of the two former points.

d) Use of an alternate PDF reader, like Foxit Reader. Looking at this I’m not sure if this is really better (security-wise) and most probably it’s not an option for most corporate environments anyway (for reasons outside the security realm).

e) Security measures/approaches from the “Least privilege” space like “running Adobe stuff on a low integrity level” (on Windows systems disposing of integrity levels, that are Win Vista or Windows 7). While this can certainly help and can be regarded as a nice preventative control, it has the big disadvantage that taking the route of “least privilege” usually has, that is added complexity and high operational cost… (which is, btw, why it practically never works out to a satisfactory degree).

f) Gateway-based controls. In a number of environments there will be quite some praying that “our malicious content protection saves us”. This may happen. or not. Taking the “detective/reactive way” (which is what most anti-malware controls do) has well-known weaknesses…
Sanitizing Flash (like Blitzableiter does) could be a much better approach. Hopefully technologies like this will gain some deployment in the near future.

And hopefully in the upcoming world of HTML5 we won’t see that high risk software piece called Flash player anymore (alas, experience tells there will be other similarly awful stuff. but that’s another story…)

have a great day,

Enno

Continue reading