Re: SCADA
"Marcus J. Ranum" <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.wizards |
|---|---|
| Message-ID | <[email protected]> |
Bill McGee (bam) wrote: > And what, exactly, is 'reliable'? The only reasonable definition I can > think of is one that hasn't been broken into 'YET'. A reliable system is one that does what it is designed to do, no less. And certainly no more. An "insecure" system is one that does quite a bit more than it was designed to do - namely it hosts hostile activity. When discussing "normal" system reliability, we can talk about mean time between failure, etc. When security is also part of the system's reliability, getting hacked is just a form of human-induced failure. Security failures are a subset of reliability failures. I think a lot of businesses instinctively understand this, because they sometimes favor regular uptime over security related downtime. I.e.: rebooting for a patch is not acceptable downtime so they don't patch. (Of course, if "not rebooting" was one of the system design criteria, it would have been a good idea to use an operating system that doesn't need to be rebooted very often, or to put it someplace where it doesn't need to be patched and rebooted at all) > Like has been said > before, unless you disassemble your machine, embed it into a cement and > glass matrix, and dump it in the ocean, there is no such thing as > 'secure' - and even then... That's not exactly true. A system that does exactly what it is supposed to - no more, no less - is achievable. It's not impossible. It just takes discipline and attention to detail, as well as a set of requirements that are actually accomplishable. Where we get into problems is when the requirements are not anything that can actually be accomplished. As Tom Ptacek once pointed out, in a fit of brilliance, the problem is that we have general-purpose computers that are designed to be programmable to do anything; and we want to restrict what they can do. We approach the problem with contradictory objectives and then are shocked when we fail to accomplish one of them. (And, surprisingly, reliability is usually the one we fail to accomplish because we are being rewarded for "making it work" not "making it always work") > Everything else involves degrees of risk > balanced with the need to actually conduct business. If I had a dollar - just one dollar - for every time I've heard that, I'd be retired and I wouldn't care if the power grid I rely on melts down. But just because lots of people say it doesn't make it true. Yes, there are degrees of risk and yes, there is the notion that we're weighing those risks and balancing them - but the preponderance of evidence is that the parameters we use as inputs are just fudge-factors, that the value of the targets at risk are wild-ass guesses, and that the likelihoods of attacks are unknown. Even more significantly, the presumed business benefits are _by_definition_ unknown because they haven't been realized, yet. That's not just a debater's point, it's a very real issue: how can you weigh a benefit when you can't predict the future? I fully understand how someone can say that they are trying to make a balanced risk assessment, but I've _never_seen_it_done_. Because it's a GIGO situation. Every risk assessment I've ever seen has either multiplication or division someplace in the formula, and that means that a single unknown turns the risk projection into a graph with an asymptote, not a single numeric value. (Or, if you represent it as a statistic, the error-bars are infinities at both ends) Cue standard response "but some metric is better than nothing at all!!!" in 5... 4... 3.... > In spite of what some of the purists on this list might imply, security > is a trade-off, and every naive administrator believes his/her network > to be 'secure' until it isn't. Calling us "purists" doesn't make us wrong. :) Actually, most of the "purists" on this list are folks who were on the cutting edge of the disaster 15 years ago and were saying (as I did, then) "we can fix it with a firewall, and a good access control policy." I don't think you realize that many of us (including me) used to sing exactly the same song you're singing right now. In fact, some of us sung it pretty darned tunefully. > The rest of us manage risk and try our > best to reduce the cost of risk to a level below the value of the > business being conducted. On what do you base your risk calculations? How do you defend their accuracy? How do you defend the accuracy of the projected business benefits you're trading off against? How do you measure the risk-reduction properties of defensive techniques? How do you scale-forward the change in "riskiness" of various attack methodologies over time? If you can answer any one of those questions with anything more solid than wild-ass guesses then you're going to be the first official saint in information security. Conversely, if you're intellectually honest and admit that all you're able to do is best guesses, then you're a cargo cultist and the only difference between we "purists" and you is that we know you are. > Our job as security professionals is to help > organizations reduce that risk as much as possible. Anyone selling > anything else is hawking snake oil. Considering that risk management, as a doctrine, is the closest thing security has to snake oil (followed closely by "stateful inspection"), I find that to be a somewhat puzzling statement. mjr. -- Marcus J. Ranum CSO, Tenable Network Security, Inc. http://www.tenablesecurity.com