[Fwd: Question]

[Behm, Jeff]

On Wednesday, April 15, 2009 2:59 PM, Chris Blask said:

>Daniel E. Hassler <hassler@...>

>> 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."
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Bill McGee (bam)]

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
Security Solutions Manager
Cisco Systems, Inc.

 -----Original Message-----
From:   Chris Blask [wobblingmoon@...]
Sent:   Wednesday, April 15, 2009 01:38 PM Pacific Standard Time
To:     hassler@...; Firewall Wizards Security Mailing List
Subject:        Re: [fw-wiz] SCADA


Daniel E. Hassler <hassler@...>


> 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."

...

:~)


     
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Daniel E. Hassler]

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@...>
>
>
>  
>> 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."
>
> ...
>
> :~)
>
>
>      
>
>
>  

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Brian Loe-2]

On Wed, Apr 15, 2009 at 4:11 PM, Bill McGee (bam) <bam@...> 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..
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Chris Blask-2]

"Behm, Jeff" <jbehm@...>

> And to that one should respond:
> "...because they haven't been connected up to the rest of the network."


That would be, unfortunately, too easy.  In fact, some of the control system networks I have looked at have been not only connected to other networks with inadequately secure methods but also often enough have had modems plugged into them... and have been nonetheless still been reliable from the standpoint of doing what they were built to do.


     
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Chris Blask-2]

Daniel E. Hassler <hassler@...> wrote:

> Yeah I know - I wanted to retract my comment shortly after sending it. What good does it do to beat a dead horse?


Insert evil grin here.

> 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.

That there is the never-ending struggle.  The questions that are at the root of all the bickering are always: "What is 'It'?" and; "How do we make sure 'they' come and get it?"  These are damn fine questions.

-chris


     
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Marcus J. Ranum]

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
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Marcus J. Ranum]

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@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Daniel E. Hassler]

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.

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Marcus J. Ranum]

Brian Loe wrote:
> The question is, do you connect
> your SCADA network to your corporate network and therefore the
> Internet. The answer was and is, IMO, NO!!!

#ifdef PURIST
Brian's response here is perfect and nuanced. You'll
notice that he implicitly introduces transitive trust
as a given in "and therefore..."
#endif

> 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.

#define PURIST BrianLoe

       
I'll teach you the secret magic handshake later. :) In the
meantime you can remain in a state of default denial. :)

The one thing we have going for us in internet security
is that we can disconnect our targets from the background. I.e.: we
can create folds in the space in which we operate, then
control the attachment points. That is an ability for
which most practical military thinkers would have traded
their left... well, a whole lot.

That we security practitioners can define our terrain, yet
_refuse_ to take advantage of it, is one of the tragedies
of the day.


mjr.
--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
                        http://www.tenablesecurity.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Daniel E. Hassler]

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.
>
>

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Paul D. Robertson]

On Wed, 15 Apr 2009, Marcus J. Ranum wrote:

> 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

1.  I'm not sure "no more" fits in the definition- for instance a system
that's designed to send company email can also send personal email- how
does that make the system less reliable?

2.  An "insecure" system _can_ host hostile activity, but that doesn't
mean it does.

> That's not exactly true. A system that does exactly what it
> is supposed to - no more, no less - is achievable. It's not

I'm not sure it's achievable.  General purpose systems are too flexible to
be completely locked down.  I can use my "Shift" key to play the Monty
Python theme, certainly not a design goal...

> 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.

I'd already typed the GP computer comment, so I'm leaving it in.

> 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.

If I had one beer for every time I've heard that, you'd be out of beer!  
Again! :)

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@...       which may have no basis whatsoever in fact."
           Moderator: Firewall-Wizards mailing list
           Art: http://PaulDRobertson.imagekind.com/

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Marcus J. Ranum]

Paul D. Robertson (noble foil) wrote:
> 1.  I'm not sure "no more" fits in the definition- for instance a system
> that's designed to send company email can also send personal email- how
> does that make the system less reliable?

If its purpose is only to send company email, it is flawed if it
sends personal email. Indeed, it then becomes a "spam source" instead
of a "corporate resource." If it is loosely specified it may later
be determined that the company email server is flawed or that the
specification is.


> 2.  An "insecure" system _can_ host hostile activity, but that doesn't
> mean it does.


It eventually will.


> If I had one beer for every time I've heard that, you'd be out of beer!  
> Again! :)


:) Bask in your victories, Obi-wan!
mjr.

--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
                        http://www.tenablesecurity.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Paul D. Robertson]

On Wed, 15 Apr 2009, Marcus J. Ranum wrote:

> Paul D. Robertson (noble foil) wrote:
> > 1.  I'm not sure "no more" fits in the definition- for instance a system
> > that's designed to send company email can also send personal email- how
> > does that make the system less reliable?
>
> If its purpose is only to send company email, it is flawed if it
> sends personal email. Indeed, it then becomes a "spam source" instead
> of a "corporate resource." If it is loosely specified it may later
> be determined that the company email server is flawed or that the
> specification is.

Personal email isn't "spam."  Just like the ability o play solitaire on a
file server doesn't necesarily make the file server any less reliable (the
Admin, certainly- the box not so much.)

> > 2.  An "insecure" system _can_ host hostile activity, but that doesn't
> > mean it does.
>
>
> It eventually will.

We can talk about the likelihood, but it's not a certainty- that's a large
part of why we're in the pickle we're in today.  If it was a certainty,
then we wouldn't have to prove insecurity and pen testers would have to
get real jobs.

> > If I had one beer for every time I've heard that, you'd be out of beer!  
> > Again! :)
>
>
> :) Bask in your victories, Obi-wan!

Always!

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@...       which may have no basis whatsoever in fact."
           Moderator: Firewall-Wizards mailing list
           Art: http://PaulDRobertson.imagekind.com/

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Brian Loe-2]

On Wed, Apr 15, 2009 at 8:27 PM, Daniel E. Hassler
<hassler@...> wrote:

> 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

That's what gets us in trouble, IMO. We start looking for a device
that's going to do our job. Simply stated, just leave the SCADA
network where it belongs - by itself - and you'll be fine. Mess with
that architecture, as Marcus said, and you're CREATING the problem.

There are ways to provide for business reporting needs - but the SCADA
network is still mostly left alone. It does NOT involve remote access,
however.
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Brian Loe-2]

On Wed, Apr 15, 2009 at 9:41 PM, Marcus J. Ranum <mjr@...> wrote:
>
> That we security practitioners can define our terrain, yet
> _refuse_ to take advantage of it, is one of the tragedies
> of the day.
>

Wow, I'm blushing - and I await my initiation and secret handshake.
Perhaps over a pint after a photo shoot? :)

At any rate, I believe this last paragraph should be engraved in
wooden plaques and that those wooden plaques should be installed in
data centers the world over!
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Brian Loe-2]

On Wed, Apr 15, 2009 at 11:00 PM, Paul D. Robertson <paul@...> wrote:

> 1.  I'm not sure "no more" fits in the definition- for instance a system
> that's designed to send company email can also send personal email- how
> does that make the system less reliable?
>

It propably - or probably should - violates the company's appropriate
use policy. It may also induce a non-business reply, or forwards,
which may introduce spam and viruses.


>> That's not exactly true. A system that does exactly what it
>> is supposed to - no more, no less - is achievable. It's not
>
> I'm not sure it's achievable.  General purpose systems are too flexible to
> be completely locked down.  I can use my "Shift" key to play the Monty
> Python theme, certainly not a design goal...

You don't put general purpose systems on a SCADA network. They don't
do email - nor do they have an email client installed. The are there
to do one thing, run the SCADA application. Everything else has been
removed or disabled.

One could argue that you don't put general purpose systems on the
corporate network either. You put accounting systems in the accounting
department and HR systems in the HR department.
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Paul D. Robertson]

On Thu, 16 Apr 2009, Brian Loe wrote:

> On Wed, Apr 15, 2009 at 11:00 PM, Paul D. Robertson <paul@...> wrote:
>
> > 1.  I'm not sure "no more" fits in the definition- for instance a system
> > that's designed to send company email can also send personal email- how
> > does that make the system less reliable?
> >
>
> It propably - or probably should - violates the company's appropriate
> use policy. It may also induce a non-business reply, or forwards,
> which may introduce spam and viruses.

That doesn't necessarily affect its reliability, and I don't know that
many places which don't allow some level of personal email these days.

> >> That's not exactly true. A system that does exactly what it
> >> is supposed to - no more, no less - is achievable. It's not
> >
> > I'm not sure it's achievable.  General purpose systems are too flexible to
> > be completely locked down.  I can use my "Shift" key to play the Monty
> > Python theme, certainly not a design goal...
>
> You don't put general purpose systems on a SCADA network. They don't
> do email - nor do they have an email client installed. The are there
> to do one thing, run the SCADA application. Everything else has been
> removed or disabled.

Windows systems are general-purpose, PCs are general-purpose computing
systems.  One of my customer's labs has lots of SCADA systems, most of
them are Windows and some of them have email clients on them- because
often the data has to come off the instrument and be used somewhere,
another customer has process management systems that are Windows-based,
and there's more on there than just the process programs for the
production lines (though not much more- they're not a research environment
like the first one- but the vendors don't always remove everything.)

Not every SCADA device is PLC-based, more's the pity.  Some folks have
environments where the SCADA devices need to be able to talk to the
business network to dump raw data into business-side systems that analyze
and report on the data- and sometimes those folks don't look at security
when they do their architecture because (a) the connection was a
per-project thing that never got architected, (b) the only place with
space was the regular network, or (c) nothing's ever happened.

I know someone who shut down a large hub for a major shipping vendor with
NMAP a few years ago- because it was all inter-connected.  You're thinking
best practice, and well there's a huge wall between current and best
practice.

> One could argue that you don't put general purpose systems on the
> corporate network either. You put accounting systems in the accounting
> department and HR systems in the HR department.

Show me a computer that is only physically capable of running an
accounting applicaion.  Pretty-much every computer these days is a
general-purpose computer running a general purpose OS.  Heck, the banks
*require* Active-X enabled Web browsers for doing check deposits these
days- accounting isn't what it used to be.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul@...       which may have no basis whatsoever in fact."
           Moderator: Firewall-Wizards mailing list
           Art: http://PaulDRobertson.imagekind.com/

_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Chris Blask]

Brian Loe <knobdy@...> wrote:


> You don't put general purpose systems on a SCADA network. They don't
do email - nor do they have an email client installed. They are there
to do one thing, run the SCADA application. Everything else has been
removed or disabled.


Not sure I follow you, here, since I think you know differently.   There is windows embedded directly into many SCADA devices, and there is nothing removed from it at all over a standard Windows install.  Metasploit works wonderfully against them.

This quote just sums up the whole problem with the segment:

--------------------
http://www.engineeringtalk.com/news/roc/roc254.html

"Manufacturers in increasingly regulated industries such as pharmaceuticals, personal care, food and beverages will appreciate the improved security features available when running RSView SE 3.0 under Windows 2000."Windows 2000 Authentication is a system-wide user group list, and users set up on this list can be added to RSView SE.
"This takes advantage of the high level of security provided by Windows 2000 and avoids the need to duplicate user accounts.
"For some critical operations, such as changing set points or downloading recipes, RSView SE requires operators to re-enter their user name and password, and can also require a second authorising "signature" before the changes take effect."
--------------------



     
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

[Marcus J. Ranum]

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
_______________________________________________
firewall-wizards mailing list
firewall-wizards@...
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards