I wanted to just point out two interesting articles that go well together.
First, Rich over at Securosis talks about security possibilities and probabilities. The gist is that some security vulnerabilities are possible, but may not be very probable at all. This argument could delve into the practicality of security in regards to budget and time. Just because an attack is possible, doesn’t mean you *have* to fix it if it is so extreme, specific, and not likely to ever happen. (It is unfortunate that Rich used Mac malware as an example, as that is a pretty passionately inflaming topic…then again, maybe the original topic was Mac malware and it turned into this blog post…I don’t know, but it shouldn’tdectract from the point above.) One other analogy I have heard was a government official taking a tour of a data center and remarking about how a spy could crawl over cage walls or under the raised floor. He was serious. Yes, it might be possible, but hopefully other factors mitigate it, depending on how much value you place on what is being protected.
Second, Chris at the Veracode blog talks about the wall that sometimes (often!) appears where developers want exploit proof rather than fixing presented possible bugs. Do you spend the time to prove an exploit and then fix it, or just fix it? What if it really is esoteric?
I guess my point in highlighting these two other posts is to illustrate the dance that security has to perform, between actually fixing issues and valuing those issues against other factors. Rich and Chris are both making risk decisions, but their audience may not agree with those valuations. Very rarely do we seem to be able to agree on such valuations in this industry. That’s not a knock; it’s simply a fact of life if you ask me.
This leads into one of my few arguments against an audit model like accounting has. Those work because accounting only has a finite number of ways to do things. IT has an infinite number of ways to solve its problems. Of course, that causes even more consternation and argument…