Re: SCADA

Chris Blask wrote:
> This quote just sums up the whole problem with the segment:


It sure does!!!

There was a guy - I don't know who it was, unfortunately, who was
going around in about 2000AD with what he called "The Security Stack."
I wish I could remember who it was because it was a brilliant way
of reasoning about this kind of stuff!!!! If you know - tell us.

Briefly, the idea of the security stack is that there are different
places we can reason about applying security, and each has
different implications. By presenting them as a stack of options,
you can lead a fruitful discussion of the relative merits of
doing a particular thing in one place or another. The stack is:
- Policy (meat layer)
- Practices (meat layer)
- Applications
- Proxies
- IP Filtering
- IP Stack Termination
- Physical

Obviously, physical is the "cut the wire" approach many of us
believed to be in effect in SCADA systems. See also:
http://www.ranum.com/security/computer_security/papers/a1-firewall/index.html
And, as we've seen the Physical layer security approach is not
very good because it's often breached at the direction of
management.

IP Stack Termination is IP filtering in the stack; i.e.: endpoint
node firewall. If the firewall or filtering technology used is
good, it can be excellent. This is usually used for restricting
administrative access to authorized IP addresses. For any
networks where the connectivity is well-understood this can be
and incredibly powerful tool. Combine it with error/fail logging
to a central location and some artificial ignorance and you have
a first class intrusion detection capability.

IP Filtering is the same thing but implemented in a core
device like a switch. All things being equal, it's very
similar to stack termination except that it fails massively
if you're penetrated behind the filtering device, or the
filtering device is not configured to filter all traffic.
In practice this takes much less work than stack termination
and in general it's more prone to failure.

Proxies attempt to apply data and command layer controls
(that's layer 7 on an ISO model) on traffic directed toward
applications behind them. Because they are layer 7 specific
they need to be combined with lower-layer controls as well.
Proxies are particularly attractive when an application's
implementation properties are unknown and are out of the
user's control. (I.e.: "trust us" from the vendor) Combined
with a positive security workflow and artificial ignorance
logging, these double as an excellent intrusion detection
system. (For the sake of discussion let's consider the
pseudo layer-7 IPS as having some data/command layer
capabilities and treat them as proxies)

Application layer security is when the applications
themselves are expected to be designed to withstand
attack. This is a technique that often repays great
benefits and synergizes well with IP stack termination.
Application logging is intrusion detection.

Practices are meat layer solutions when you define
processes and procedures, document them, publish them,
and expect everyone to follow them. Generally, practices
are only considered to be an effective approach in
relatively small organizations or on restricted networks.

Policies are meat layer recommendations, published and
expected to be followed. There is considerable debate
among practitioners as to whether policies are effective
at all. "Your mileage may vary" and almost certainly
the size and culture of the organization will have a lot
to do with it.

So - you can work a case study like, say, securing a web
application. Do we want our main effort to be at the
application layer, or is it an application we have no
control over and we need to think in terms of a proxy?
Are there additional controls we might want to put in
place in case it fails, and where? Etc.

Anyhow... It's a useful model. That doesn't mean
anyone uses it except a few of us old purists. :)

mjr.
-- 
Marcus J. Ranum		CSO, Tenable Network Security, Inc.
			http://www.tenablesecurity.com