[SCADASEC] Fwd: [Full-disclosure] CORE-2008-0129 - WonderwareSuiteLink Denial of Service vulnerability
southworthrg at bigpond.com
southworthrg at bigpond.com
Wed May 7 21:45:47 CDT 2008
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