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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.