Loading ...
I found this on Slashdot. It points to an article here.
Here is Torvalds on security:
“Schedulers can be objectively tested. There’s this thing called ‘performance’, that can generally be quantified on a load basis.
“Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is ‘hard science’. The other one is ‘people wanking around with their opinions’.”
I partially agree and partially disagree.
First, my disagreements:
- Information Security has known testing methodologies.
- Information Security has metrics that can be applied to help understand risk.
- Our field has standards as well as generally accepted principles and practices.
My agreements:
- How often security metrics are used in the SDLC is questionable.
- While there are generally accepted security coding and design principles, not all software designs can be incorporated under these developed rubrics.
- New and creative exploits are always being developed.
- Sometimes judging the difference in risk, based on the potential vulnerability and perceived threats, is more subjective than objective based on the conditions under which these adverse circumstances may happen.
2 Comments
I think that I agree with Linus a bit more than you. In your disagreements:
1) Information Security has known testing methods.
Which are basically broken down into compliance testing, where the linkage to security is indirect at best and insignificant at worst (FISMA); and pen testing, which directly measures results, but we’re a few years away from getting quantitave metrics from results.
2) Information Security has metrics that can be applied to help understand risk.
Problem is, Linus talked about quantification. Yes todays metrics help to understand risk, but today it requires a priest of Delphi to understand it. Linus (and I, and my CIO, and a lot of people) would like meaningful, reliable numbers. The only reliable metric that I know of is ‘what has been an organization’s history with computer related incidents, and what is that organizations’s environment?’ Obviously the ‘reliable’ part is all bound up in how good that they are watching (assuming that they are telling you the truth!) The US Army has had some real problems with the Red Army, but they are being actively hacked by a pretty large, well organized, state-sponsored group. The VA has had some problems, but they operate in a low to moderate threat environment. I can make conclusions based on this data. But, I which I had some numbers that were worth more than the FISMA report card.
3)Our field has standards as well as generally accepted principles and pratices.
which your agreement #3 largely negates. Standards and accepted practices are obviously the foundation, the bedrock to build a security program on. However, a successful program is one where the people and procedures respond to changes in the environment. If all your systems are up to standards and fully patched, but when a zero day exploit surfaces, your are unable to match it, you are vulnerable. Only thing that you got from the effort at standards and pratices is you know (maybe) that you got hit.
Frankly, if all it took was standards and pratices, I wouldn’t find computer security very interesting.
P.S. Thanks for an interesting blog.
Dave Funk
Hi Dave,
While there are certainly ways to quantify metrics (see here and here), you’re correct that this is generally a problem in today’s environments.
Regarding zero days and standards/practices: one hopes that one has enough layers in place to prevent most zero day attacks: IPS / Firewall / DMZ / *EndPoint* Security would do a very good job of reducing many _generic_ zero day attacks. (Note that while endpoint security is important here and could prevent many 0-day attacks against workstations, this would not be true of of other assets, such as web apps.)
Thanks for reading and for a thoughtful reply.