firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: SCADA (Marcus J. Ranum)
2. Re: SCADA (Marcus J. Ranum)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Apr 2009 13:29:05 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] SCADA
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49E778F1.7030305@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Paul D. Robertson wrote:
> Show me a computer that is only physically capable of running an
> accounting applicaion.
That's what things like exe-lockdown and software restriction
policies are for. I'm not saying they're easy to use (more's
the pity!) but we both know that restricting what can be run
where goes a hell of a long way toward blocking a lot of badness.
mjr.
--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
http://www.tenablesecurity.com
------------------------------
Message: 2
Date: Thu, 16 Apr 2009 14:05:06 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] SCADA
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49E78162.5070107@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 36, Issue 26
************************************************
No comments:
Post a Comment