[SCADASEC] Make vendors liable for exploits

Sun Mar 16 16:16:07 CST 2008

Joe,

As I've said before, you and I have met.

We've spent literally hours talking on the phone.

I cannot endanger myself by operating under my real name.

And as I have had to say before -- please show me the same respect
that I show you by spelling your name correctly.

WRT Larry and his constant retreading of the same tired story -- you
and I have specifically discussed the issue of standards (in our
discussion the NERC CIP standards) being so weakly written as to make
mere compliance a criminally negligent act.

Your much vaunted DHS is perfectly aware of how to map "Myrcurial the
Security/SCADA Researcher" with my given name.  That you are unable to
map the same is simply the result of your inability to perceive that
others may not have the freedom necessary to operate under a given
name, but rather must use an alias.

Hell, a google search will turn up a normalized english language name
for me in about 7 or 8 screens.  At the very least - there is exactly
one "Myrcurial" in this world -- there's a few majillion Joe Weiss'.

I have not slandered anyone - here or elsewhere.  I may choose to call
it how I see it -- in stark contrast and failing to use grey as a
colour -- but there is nothing I've said that is any more or less true
for being said from a pseudonym vs. a real name. They may very well be
good people, but they are good people operating with the best of
possible intentions from completely the wrong basis. Being good and
smart is not the same as being effective and useful.

Perhaps you should look into the use of pseudonyms as protective
colouring in political interaction -- a bit of a history exercise.
I'm sure you're perfectly well aware of what happens to people who
fail to study history.

And honestly -- would you really be that much happier if I posted as
"Bob McGruff" -- you'd still not be impressed with what I'm saying --
my words would have the same effect on you regardless of what the
byline was.  Your inability to verify and validate my identity here
comes down to a very simple solution... if you're serious about
finding out who I am and what my *very* legitimate credentials are...
how about you email me and ask.

Others have.

Join the club - it's not as elitist as you seem to believe.

~Myrcurial

On 3/16/08, Joe Weiss <joe.weiss at realtimeacs.com> wrote:
> This response makes it imperative the rules change not only for this
>  listserver, but also any attempt to start a SCADAGard. If Mycurial or
>  others such as Dogten cannot identify themselves, do NOT let them on!
>  Bob, I also implore you not to count votes on creating a SCADAGard (in
>  either direction) from anyone that can't use a real name. This is not a
>  hacker site and it is not a traditional IT site with all of the aliases.
>  Mercurial denigrates good people and good work in a very derogatory
>  manner. Why can't he identify himself?????? I don't have a problem if he
>  doesn't think the NIST standards aren't adequate and he thinks he could
>  create a better one. I have a problem that feels he has to use an alias
>  to slander people. This isn't the first time he has done it either.
>  Enough!!!!!!!
>  Joe
>
>  Joe Weiss PE, CISM
>  Applied Control Solutions, LLC
>  Cupertino, CA
>  (408) 253-7934
>  (408) 253-7974 Fax
>  (408) 832-5396 Cell
>
> joe.weiss at realtimeacs.com
>
>
>
>
>  -----Original Message-----
>  From: scadasec-bounces at news.infracritical.com
>
> [mailto:scadasec-bounces at news.infracritical.com] On Behalf Of Myrcurial
>  Sent: Sunday, March 16, 2008 12:25 PM
>  To: scadasec at news.infracritical.com
>  Subject: Re: [SCADASEC] Make vendors liable for exploits
>
>
> Larry,
>
>  That's called a bullshit excuse for a standard.
>
>  It's not proscriptive.
>
>  I could create a security plan that says the following:
>
>  "Test and evaluate effective ability of system to withstand 'hold-up'
>  event with uneducated illiterate thug as perpetrator. Passing grade
>  considered for any system which does not hand bag of cash to
>  perpetrator."
>
>  There... I passed.
>
>  The plan does not have to be relevant to the system in either its
>  'ready to ship' or 'ready to install' or 'ready for operations' state.
>  It completely ignores configuration level details -- the code may be
>  fine, but it can be installed or configured in such a way as to make
>  the security value essentially useless.
>
>  But above and beyond that structural issue is this: The plan does not
>  set a minimum requirement which can be construed as a pass. In fact,
>  it does not require that the system pass the test at all. **NOTE**
>  See USA "No Child Left Behind" for details on widespread
>  implementation and failure of this piece of system design.
>
>  By pointing at this standard and saying "Lookie here, we're all good"
>  -- you are part of the problem - not part of the solution.
>
>  Sometimes you have to do the job.  Sometimes you have to do the job
>  well.  In any SCADA using industry, failure to do the job well is
>  better known as "criminal negligence".
>
>  Are you prepared to wear an orange jumpsuit?
>
>  ~M
>
>
>  On 3/16/08, ljknews <ljknews at mac.com> wrote:
>  > At 11:30 AM -0400 3/16/08, Jake Brodsky wrote:
>  >
>  >  > The remainder of this issue boils down to how a SCADA system is
>  >  > validated and whether there is any obligation on behalf of the
>  >  > integrator, or an ongoing obligation on behalf of an asset owner to
>  >  > ensure proper operation.  There is another question of what
>  constitutes
>  >  > a reliable and robust operation.  Security is only the latest issue
>  in
>  >  > this mess.  Metrics such as MTBF and MTTR are only the tip of the
>  >  > iceberg of this analysis.
>  >  >
>  >  > It would be nice if standards could be created for this sort of
>  thing,
>  >  > but I wouldn't know where to start, and I've been working this
>  stuff for
>  >  > decades.
>  >  >
>  >  > The obvious issue is that somehow we need to incorporate software
>  >  > validation in this too.  Suggestions?
>  >
>  >
>  > >From NIST SP 800-53, released February 2005:
>  >
>  >  > SA-11 DEVELOPER SECURITY TESTING
>  >  >
>  >  > Control: The information system developer creates a
>  >  > security test and evaluation plan, implements the plan,
>  >  > and documents the results. Developmental security test
>  >  > results may be used in support of the security certification
>  >  > and accreditation process for the delivered information system.
>  >  >
>  >
>  >  > Supplemental Guidance: Developmental security test results
>  >  > should only be used when no security relevant modifications
>  >  > of the information system have been made subsequent to
>  >  > developer testing and after selective verification of
>  >  > developer test results.
>  >
>  > --
>  >  Larry Kilgallen
>  >
>  >
>  >  _______________________________________________
>  >  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
>
>  _______________________________________________
>  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
>