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 (Daniel E. Hassler)
2. Re: SCADA (Behm, Jeff)
3. Re: SCADA (Brian Loe)
4. Re: SCADA (Daniel E. Hassler)
5. Re: SCADA (Daniel E. Hassler)
6. Re: SCADA (Marcus J. Ranum)
7. Re: SCADA (Marcus J. Ranum)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Apr 2009 14:12:43 -0700
From: "Daniel E. Hassler" <hassler@speakeasy.net>
Subject: Re: [fw-wiz] SCADA
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49E64DCB.3030607@speakeasy.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Yeah I know - I wanted to retract my comment shortly after sending it.
What good does it do to beat a dead horse?
Next question - Why do we spend so much time complaining about the sad
state we are in when we have a pretty good idea how they should be done?
Maybe, If we build it they will come.
Chris Blask wrote:
> Daniel E. Hassler <hassler@speakeasy.net>
>
>
>
>> I agree with your observations but how can an insecure system be
>>
> considered reliable?
>
>
> That there is a damn fine question, but when you ask it of the folks running these systems the answer is: "It has been reliable so far."
>
> ...
>
> :~)
>
>
>
>
>
>
------------------------------
Message: 2
Date: Wed, 15 Apr 2009 15:42:46 -0500
From: "Behm, Jeff" <jbehm@burnsmcd.com>
Subject: Re: [fw-wiz] SCADA
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<1217D5F18AEF15499BF1047D8F407D56097BB4@kcm-exch-001.burnsmcd.com>
Content-Type: text/plain; charset="us-ascii"
On Wednesday, April 15, 2009 2:59 PM, Chris Blask said:
>Daniel E. Hassler <hassler@speakeasy.net>
>> I agree with your observations but how can an insecure system be
>>considered reliable?
>That there is a damn fine question, but when you ask it of the folks
> running these systems the answer is: "It has been reliable so far."
And to that one should respond:
"...because they haven't been connected up to the rest of the network."
------------------------------
Message: 3
Date: Wed, 15 Apr 2009 16:49:06 -0500
From: Brian Loe <knobdy@gmail.com>
Subject: Re: [fw-wiz] SCADA
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<3c4611bc0904151449n5dd56cddr467e0bf4d4c483a9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Apr 15, 2009 at 4:11 PM, Bill McGee (bam) <bam@cisco.com> wrote:
> And what, exactly, is 'reliable'? The only reasonable definition I can think
> of is one that hasn't been broken into 'YET'. 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... Everything else involves degrees of risk balanced with the need
> to actually conduct business.
>
> 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. 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. Our job as security professionals is to help organizations reduce
> that risk as much as possible. Anyone selling anything else is hawking snake
> oil.
>
>
>
> Bill McGee
Seems we've gotten off on a tangent. The question is, do you connect
your SCADA network to your corporate network and therefore the
Internet. The answer was and is, IMO, NO!!!
I really DON'T have to update the Windows 95 boxes running on the
SCADA network. They are currently as secure as they ever will be. The
ability for someone or something to attack them has been mitigated as
much as can be for them to still do the job they are assigned.
And that's a fine point: "the job they are assigned" - not the job
they are assigned, and allow the lazy plant manager to monitor things
from his house in the morning; and allow engineering to not have to
cross the street to update a view or PLC and etc., etc..
------------------------------
Message: 4
Date: Wed, 15 Apr 2009 18:27:04 -0700
From: "Daniel E. Hassler" <hassler@speakeasy.net>
Subject: Re: [fw-wiz] SCADA
To: mjr@ranum.com
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49E68968.2000508@speakeasy.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
OK - I expected this. As I stated I was/am not trolling. Heck - check
the email headers - This noise is coming from Thunderbird on a WinXP Pro
system. I don't expect this system is secure even with two different
firewalls and an AV software product installed. Marcus - I've really
enjoy your works/writings/postings and sincerely did not mean any
offense. I've read over and over about SCADA security issues but find
practically nothing on the market to effectively address them. We can
write a lot on the Firewall Wizards list about the woes of mixing
today's connected business needs with yesterdays isolation is a form of
security. My basic question is why aren't those who have a clue creating
solutions to meet the business needs? This is where I think our time is
better spent (and the.the $$$ are). If I can rephrase my original
question it would be more like: "I think we can do better, If we build
it will they come?"
Thanks,
Dan Hassler
Marcus J. Ranum wrote:
> Daniel E. Hassler wrote:
>> Forgive my ignorance but why is SCADA even allowed to run on a
>> Windows host?
>
> Windows is just fine!!
>
> Production Systems 101:
> Step 1: Set it up
> Step 2: Make it work
> Step 3: Leave it alone
> If it breaks, figure out what went wrong
> fix it, then go to step #3
>
> There's nothing wrong with Windows at Steps #1 and #2. The
> problem comes along in #3 - "leave it alone" does not include
> "make it internet-accessible so that every hacker who can send
> it a packet is able to mess with it" or "patch it every tuesday"
> If all you wanted to do with a Windows system was have it
> sit there and monitor a serial port connected to a widgiframus
> and beep if the value sent over the port goes to high - Windows
> is great for that. If you want it to sit there and be connected
> to the Internet and ALSO monitor the serial port connected to
> the widgiframus - then it's maybe not so good.
>
> The problem in a nutshell is that systems were implmented in a
> way that was OK for one objective (monitor the serial port on
> the widgiframus) and it was automatically assumed that the
> system was therefore OK for another objective (resist hackers
> on the Internet) Perhaps it is, perhaps it isn't!! Where we
> all get stuck is when managers or whoever skip the part where
> they are supposed to ask that question.
>
> I know this is a ridiculous example but it's kind of like
> concluding that, because a condom was successful (so far!)
> at preventing one from getting STDs that it'd also make a
> decent parachute.
>
> There are a few of us grognards who like to point out - rightly,
> I think, that there are huge swaths of the Internet that
> have this problem: things worked fine for a simple job, but
> they're not good enough to do the big job. But they're being
> pressed into service because, well, they are. And it's resulting
> in a situation where we move farther and farther from the
> design and safety properties that we originally established.
>
> With SCADA systems I've seen this a couple of times, in the
> last 5 years. One organization had a perfectly reasonable
> backend system to control a very complex and expensive
> printing press system. It worked fine. The security
> "architecture" (such as it was) was "everything is on a
> private isolated LAN so security is not a problem." And
> that's a perfectly valid and reasonable design. It's easy
> to get right. But then the client decided to add a
> wireless access point. And, then they decided to let their
> customers hook the LAN to internal networks so that
> diagnostic service guys could remotely access the systems
> and check the printer's state over the Internet. Suddenly
> the design "everything is on a private isolated LAN so security
> is not a problem" no longer applied. I'm sure that all
> of the more seasoned veterans on this list have seen this
> scenario, with slightly different details.
>
> The point is that:
> Initially Windows was just fine
> Now it's not
> But it's still in place
>
> So, eventually something will go horribly wrong and everyone
> will run around going "OMG! How did this happen!?!" As I
> pointed out in my security disasters paper, the disaster
> happened when the security model of "isolated LAN" changed
> to "something other than isolated LAN" and the other
> underlying assumptions were not reviewed.
>
>
> mjr.
------------------------------
Message: 5
Date: Wed, 15 Apr 2009 20:14:02 -0700
From: "Daniel E. Hassler" <hassler@speakeasy.net>
Subject: Re: [fw-wiz] SCADA
To: mjr@ranum.com
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49E6A27A.1030104@speakeasy.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hum.. Are the solutions being marketed correctly considering the
alternatives? In effect you are saying customers are willing to face
problems similar to the banking system - OOPS! I hope we don't all
suffer the consequences.
Marcus J. Ranum wrote:
> Daniel E. Hassler wrote:
>> OK - I expected this. As I stated I was/am not trolling.
>
> I thought not, nor did I mock you.
>
> My basic question is why aren't those who have a clue creating
>> solutions to meet the business needs?
>
> We did - but they didn't make the business guys happy enough!
>
> mjr.
>
>
------------------------------
Message: 6
Date: Wed, 15 Apr 2009 18:58:29 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] SCADA
To: hassler@speakeasy.net, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: jmac448@aol.com
Message-ID: <49E674A5.3070300@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Daniel E. Hassler wrote:
> Forgive my ignorance but why is SCADA even allowed to run on a Windows
> host?
Windows is just fine!!
Production Systems 101:
Step 1: Set it up
Step 2: Make it work
Step 3: Leave it alone
If it breaks, figure out what went wrong
fix it, then go to step #3
There's nothing wrong with Windows at Steps #1 and #2. The
problem comes along in #3 - "leave it alone" does not include
"make it internet-accessible so that every hacker who can send
it a packet is able to mess with it" or "patch it every tuesday"
If all you wanted to do with a Windows system was have it
sit there and monitor a serial port connected to a widgiframus
and beep if the value sent over the port goes to high - Windows
is great for that. If you want it to sit there and be connected
to the Internet and ALSO monitor the serial port connected to
the widgiframus - then it's maybe not so good.
The problem in a nutshell is that systems were implmented in a
way that was OK for one objective (monitor the serial port on
the widgiframus) and it was automatically assumed that the
system was therefore OK for another objective (resist hackers
on the Internet) Perhaps it is, perhaps it isn't!! Where we
all get stuck is when managers or whoever skip the part where
they are supposed to ask that question.
I know this is a ridiculous example but it's kind of like
concluding that, because a condom was successful (so far!)
at preventing one from getting STDs that it'd also make a
decent parachute.
There are a few of us grognards who like to point out - rightly,
I think, that there are huge swaths of the Internet that
have this problem: things worked fine for a simple job, but
they're not good enough to do the big job. But they're being
pressed into service because, well, they are. And it's resulting
in a situation where we move farther and farther from the
design and safety properties that we originally established.
With SCADA systems I've seen this a couple of times, in the
last 5 years. One organization had a perfectly reasonable
backend system to control a very complex and expensive
printing press system. It worked fine. The security
"architecture" (such as it was) was "everything is on a
private isolated LAN so security is not a problem." And
that's a perfectly valid and reasonable design. It's easy
to get right. But then the client decided to add a
wireless access point. And, then they decided to let their
customers hook the LAN to internal networks so that
diagnostic service guys could remotely access the systems
and check the printer's state over the Internet. Suddenly
the design "everything is on a private isolated LAN so security
is not a problem" no longer applied. I'm sure that all
of the more seasoned veterans on this list have seen this
scenario, with slightly different details.
The point is that:
Initially Windows was just fine
Now it's not
But it's still in place
So, eventually something will go horribly wrong and everyone
will run around going "OMG! How did this happen!?!" As I
pointed out in my security disasters paper, the disaster
happened when the security model of "isolated LAN" changed
to "something other than isolated LAN" and the other
underlying assumptions were not reviewed.
mjr.
--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
http://www.tenablesecurity.com
------------------------------
Message: 7
Date: Wed, 15 Apr 2009 19:27:43 -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: <49E67B7F.2080105@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
------------------------------
_______________________________________________
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 22
************************************************
No comments:
Post a Comment