full-disclosure - Re: Risk measurements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <15206.1266028352@localhost>
Date: Fri, 12 Feb 2010 21:32:32 -0500
From: Valdis.Kletnieks@...edu
To: Christian Sciberras <uuf6429@...il.com>
Cc: "McGhee, Eddie" <Eddie.McGhee@....com>,
	craig.wright@...ormation-defense.com,
	full-disclosure <full-disclosure@...ts.grok.org.uk>,
	security-basics@...urityfocus.com,
	"Thor \(Hammer of God\)" <Thor@...merofgod.com>
Subject: Re: Risk measurements

On Fri, 12 Feb 2010 16:54:48 +0100, Christian Sciberras said:

> And who do you know what the bugs are? Risk modeling cannot solve this
> kind of issue. Vulnerabilities aren't intentional.
> It isn't intentional that I could piggyback a particular process and
> get kernel access. Since vulnerabilities are based on exceptions, how
> do you know that this kind of exception occurs?
> Again, mathematics lose ground here.

Actually, it turns out that you can do most of this without having a *clue*
what the bugs are.  It's counter-intuitive, but true.

Let's say we have a server that handles SSN data, and has a trust relationship
with another server that handles Visa cards.  Neither of those servers have
any connection to the server in R&D that has product design data.

Now we can say with a high degree of certainty that if that server gets
whacked, we have a high probability of SSN exposure, potential exposure of Visa
card numbers, and essentially zero R&D exposure. Dig a bit further - the server
runs Apache, OpenSSH, and PHP.  OpenSSH is firewalled to only a section of the
corporate network.  We have a pretty good handle on how often Apache, OpenSSH
and PHP get whacked (advisories per year is a pretty good place to start).  We
can now model things like "how likely an Apache hole will end up with us
leaking Visa cards", "how likely an OpenSSH 0-day will pwn our R&D", and so on.

I don't need to be able to predict the next bug.  I only need to be able to
predict "*BSD and OpenSSH have a good track record, so they'll probably keep
being reasonably trustable".  I also don't need to be able to guess *what*
the next bug in phpnuke will be - I feel pretty safe in predicting that if
the bozos in Advertising insist on installing it on an outward-facing server,
we'll have an incident within the year.

>> -"Unfortunately, you'll need to do some risk modeling to figure out
>> what "reasonable bounds" is for each piece of information."
> Wait, so I need to do risk modeling to quantify the risks of
> information/results of a risk assesment on software? Sounds like
> beauroucracy to me (pun intended).

No, you made it too complicated. Lose the second "of a risk assessment".
"You need to do risk modelling to quantify the risks of information/sofware."

> I see the reason behind risk management, but I don't see it being
> usefull except in policy-making.

That's because most of its value *is* in policy-making and related decisions
for implementing the policy.  "We're in good shape on this system, Payroll
needs some defense-in-depth, and we need to either buy bullets for those bozos
in Advertising or KY". That's risk management in one sentence. ;)

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/