[SCADASEC] Fwd: [Full-disclosure] CORE-2008-0129 - WonderwareSuiteLink Denial of Service vulnerability
wboyes at putman.net
wboyes at putman.net
Wed May 7 22:17:51 CDT 2008
We are in complete agreement, Ron.
It isn't that there weren't real Y2K issues-- there were, and whole hordes
of dedicated men and women worked for several years to ensure they didn't
bite us too hard.
But from the "catbird seat" at the top of corporations, they just were
transparent, because what they did worked-- and the doomsday scenarios
never played out. Now the C-level believes that they got horked into
spending "unnecessary" money by their IT chiefs.
And while this may be arrant nonsense, it is believed arrant nonsense. And
the people who believe it are the checkbook holders.
And I agree that Invensys is one of the most proactive vendors with regard
to security issues. Invensys was at the very first meetings we had when we
put together the idea that became the ISCI compliance institute...and
they've been right there ever since, putting their money where their mouth
is...along with many other major automation system vendors, like Honeywell,
ABB, Emerson, and others...whether they've joined the ISCI or not.
Everyone needs to recognize both the severity of the problem, and their
role in handling it.
Walt
----------------------------------------------
Walt Boyes
Editor in Chief
CONTROL magazine
ControlGlobal.com
555 W. Pierce Road, Ste. 301
Itasca, IL 60143
630.467.1301 x 368
wboyes at putman.net
Read my blog, Sound Off, at www.controlglobal.com
<southworthrg at big
pond.com>
To
05/07/2008 09:45 scadasec at news.infracritical.com
PM cc
wboyes at putman.net
Subject
Re: [SCADASEC] Fwd:
[Full-disclosure] CORE-2008-0129 -
WonderwareSuiteLink Denial of
Service vulnerability
Hi Walt,
I think the need for awareness to be raised to the decision makers and
managers of our control systems is somthing that needs to be promoted - you
allready know my sentiment on FUD so I won't digress.
I think responsable disclosure especially in our industry is a very
important thing to get it right for all affected.
With Y2K I think the concern was valid but the approach and the over
reaction of a number of organisations and the eventual degree of self
assessment to mitigate the risks of organisations was an issue. Many middle
manages saw Y2K as a grab for money to obtain new technology and this may
have left many with a bad taste.
Had more public info from product vendors have been available a lot of
rework and consultancy fees could have been avoided.
I did however see first had a number of communications and data tracking
products that had some serious Y2K issues and were fairly publicly known
and these were resolved (until 2048)
Invensys are at least one of many companies that is being proactive Walt I
can only hope other organisations can be as transparent as they have been
in dealing with these problems.
Ron Southworth
---- wboyes at putman.net wrote:
> Unfortunately, Kevin, you are both right and not correct. (sigh) I wish
> this was easier to understand, or maybe easier for me to explain.
>
> You are right that the asset owner has an obligation to find out about
bugs
> and vulnerabilities-- AND THEN DO SOMETHING TO FIX THEM.
>
> But here's where you can be right, and be "dead right," as it were.
>
> The plant management that needs to do something isn't going to be
stampeded
> by fear by their IT consultants, or even by IT savvy plant operations
> personnel. They've been had by the IT folks (in THEIR view, NOT mine) for
> twenty years now, and the biggest one of all was Y2K. Vulnerability after
> vulnerability was disclosed, and wonder of wonders, the world didn't come
> to an end.
>
> Exposing vulnerabilities is only part of the process, and exposing
> vulnerabilities _in order to make plant business leaders do something_ is
> ultimately futile.
>
> ----------------------------------------------
> Walt Boyes
> Editor in Chief
> CONTROL magazine
> ControlGlobal.com
> 555 W. Pierce Road, Ste. 301
> Itasca, IL 60143
> 630.467.1301 x 368
> wboyes at putman.net
> Read my blog, Sound Off, at www.controlglobal.com
>
>
>
> "Kevin Finisterre
> (lists)"
> <kf_lists at digital
To
> munition.com> scadasec at news.infracritical.com
> Sent by:
cc
> scadasec-bounces@
> news.infracritica
Subject
> l.com Re: [SCADASEC] Fwd:
> [Full-disclosure] CORE-2008-0129 -
> WonderwareSuiteLink Denial of
> 05/06/2008 11:09 Service vulnerability
> AM
>
>
> Please respond to
> scadasec at news.inf
> racritical.com
>
>
>
>
>
>
>
> On May 6, 2008, at 11:35 AM, Brodsky, Jake wrote:
> >
> > So Core Security publishes this as if it's just another IT bug. It's
> > not. This is going to kill someone some day.
>
> Sure it is... you can implement any software in a manor that someone's
> life can depend on it,
> your industries products aren't special just because everyone is so
> touchy about them. If this bug
> kills someday thats because someone was not diligent in patching a
> known problem. More importantly
> if someone dies from this the cause is that the original vendor was
> not diligent enough to think about
> secure coding and QA testing before putting a product out into the
> market. As users of the products you
> too are at fault for just blindly expecting that your vendors products
> are rock solid and flawless. CORE is
> simply the messenger... don't shoot them... shoot the vendor... shoot
> the people that fail to fix the issue
> after its been disclosed. Shoot yourself in the foot once for not
> doing your own due diligence on the
> products you use.
>
> > And it's not just us asset owners, it's the engineering consultants
> > too.
> > How many of THEM will know to look for this?
>
> Well now that there is some visibility level with the bug... I would
> go out on a limb here and say
> a heck of a lot more of THEM than there would be had this bug been
> privately held from public
> eye.
>
> > I admit, we have a severe education problem here. But even if there
> > were enough smarts in the field to patch this stuff in a timely
> > fashion,
> > we still have logistics of testing, deployment scheduling, and so
> > forth.
>
> Great... so get started... no you are armed with the information to
> get this testing underway...
>
> >
> > This is why you can't "just publish" the bugs.
>
> This is EXACTLY why you publish bugs... to get folks out of their
> comfort zone and to strongly
> encourage them to stop leaving things the way they are simply because
> they work or because its
> the easiest thing to do.
>
> >
> > If you're an asset owner, set your industrial network defense level to
> > Orange (no laptops on the ICS networks, no new software, halt
> > development) until you can verify the need for this patch.
>
> If you are an asset owner get some sort of processes in place to
> handle patches in a timely
> manor for ALL of your products , not just the ones that have the most
> public exposure. Don't just
> sit back and whimper because someone releases a bug. If you have to go
> into freak out mode every
> time a patch comes out ... there is a problem.
>
> Maybe the power industry has a different line of thinking but in my
> mind if a part of your infrastructure
> is so sensitive that if you breath on it wrong it breaks, now is a
> good time to start looking at making it a
> bit more robust and resistant to outside influences.
>
> Proactive vs. Reactive...
>
> -KF
>
>
> >
> > Jake Brodsky
> >
> >
>
> _______________________________________________
> To unsubscribe from this mailing list, please visit:
> http://news.infracritical.com/mailman/listinfo/scadasec
>
> To review our privacy statement, please visit:
> http://www.infracritical.com/privacy.html
>
> scadasec at news.infracritical.com
> http://news.infracritical.com/mailman/listinfo/scadasec
>
>
>
> _______________________________________________
> To unsubscribe from this mailing list, please visit:
> http://news.infracritical.com/mailman/listinfo/scadasec
>
> To review our privacy statement, please visit:
> http://www.infracritical.com/privacy.html
>
> scadasec at news.infracritical.com
> http://news.infracritical.com/mailman/listinfo/scadasec
More information about the scadasec
mailing list