[Info-vax] Variable declarations, was: Re: improving EDT

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Bill Gunshannon via Info-vax
> Sent: 23-Nov-16 10:30 AM
> To: info-vax at rbnsn.com
> Cc: Bill Gunshannon <bill.gunshannon at gmail.com>
> Subject: Re: [Info-vax] Variable declarations, was: Re:
improving
> EDT
> 
> On 11/22/16 11:39 PM, David Froble wrote:
> > Bill Gunshannon wrote:
> >> On 11/22/16 4:04 PM, David Froble wrote:
> >>> Scott Dorsey wrote:
> >>>>  <johnwallace4 at yahoo.co.uk> wrote:
> >>>>> Quite a few people and organisations would say they
> cared about
> >>>>> security. They especially say this after they've been
> publically
> >>>>> breached.
> >>>>>
> >>>>> Fewer people and organisations actually consider (let
> alone invest
> >>>>> in) real security upfront.
> >>>>
> >>>> Indeed, and few of them even consider or invest in it
after
> the fact.
> >>>>
> >>>>> For certain specific applications, ARM's TrustZone seems
> to have
> >>>>> some applicability:
> >>>>> https://www.arm.com/products/security-on-
> arm/trustzone
> >>>>>
> >>>>> Intel have been trying to achieve something similar on=20
> specific
> >>>>> x86-based systems, with little visible effect to
> >>>>> date:
> >>>>> https://software.intel.com/en-us/sgx
> >>>>>
> https://en.wikipedia.org/wiki/Software_Guard_Extensions
> >>>>>
> >>>>> And back in the day, didn't Intel have a capability-based
> chip?
> >>>>> The ill-fated iAPX 432?
> >>>>> https://en.wikipedia.org/wiki/Intel_iAPX_432
> >>>>
> >>>> Yes, the iAPX 432 was a very slow machine but one with a
> lot of
> >>>> real security features.  Although it died a horrible death
of
> >>>> bloat, many of the useful features in the 432 appeared in
> the i960
> >>>> which was an ingenious and well thought-out architecture
> that Intel
> >>>> seemed to be totally unable to sell in spite of excellent
> >>>> performance and well-designed security.
> >>>>
> >>>>> If people actually wanted security, we wouldn't be
reading
> about
> >>>>> obvious exploit after obvious exploit on the latest
devices
> from
> >>>>> the Interweb of Trash. Or something.
> >>>>
> >>>> Precisely.
> >>>> --scott
> >>>
> >>> I've had two experiences that caused me to throw in the
> towel and do
> >>> whatever people wanted.
> >>>
> >>> 1) I mentioned to a customer that storing credit card data
and
> >>> checking account data with no protection on an IIS server
> wasn't a good idea.
> >>> The response: "why not, everyone does it".
> >>>
> >>> 2) While discussing security with another customer I was
told
> "my
> >>> boss doesn't care about security".
> >>
> >> For the first one I would explain the reason why.
> >
> > I did.  But, "everyone does it" seemed to be all they wanted
to
> know.
> 
> Sorry, you said they asked "why not".  To me that implied they
> wanted to know.
> 
> >
> >> For the second I would ask "his boss" if that was true.
> >> If yes, I would look for somewhere else to work.
> >
> > Bill, companies, consultants, and such work hard to acquire
> customers.
> > They do not throw them away, just because the customer is
> wrong.
> >
> > Rules of customers:
> >
> > 1) The customer is always right
> >
> > 2) When the customer is wrong, refer to rule #1
> >
> > Nuff said?
> >
> > I haven't worked as an employee since 1982 ...
> 
> 
> That's fine, until they start blaming the workers for the
breaches.
> Not gearing a lot about it over hear, but listening to German
radio
> pretty much everyday I hear a lot about the VW fiasco. Current
> trend is to blame the programmers who actually wrote the code.
> It doesn't seem to matter that they were employees doing what
> they were told to do.  Some of them will likely end out as the
> scapegoats. Once again, "I was just following orders" is not
going
> to work as a defense.  I certainly would not want to work for a
> place that is going to make me do things I don't agree with and
> then hold me responsible later.
> 

You are correct that all too often the blame is placed squarely
on the shoulders of those in Operations Support. 

That is why it is so critical for those in  Operations Support to
document those cases where for example, they asked for downtime
to apply critical security patches or asked for additional
critical App testing time and were denied.

Unfortunately, in the commodity OS world, due to the volume of
monthly security patches, many Operations shops have adopted a
"patch-n-pray" philosophy because there is no way the business
will give the OPS folks the corresponding amount of time to
re-test important applications.

> Of course, this is all academic as I seriously doubt anyone is
going
> to hire me for anything at this point in time.  Unless someone
> really gets in a bind with their COBOL.  :-)
> 
> bill
> 

A bit dated, but given the huge amount of Cobol code still
running many mission critical banking, insurance and similar
environments, likely still applies today:
http://www.eweek.com/c/a/Application-Development/Is-COBOL-the-18W
heeler-of-the-Web

http://www.theinquirer.net/inquirer/news/1432435/cobol-lease-life

Key point is to leverage and sell Cobol integration skills with
.Net, J2EE and other web integration technologies with the
philosophy of "upgrade and integrate", not "rip-and-replace".


Regards,

Kerry Main
Kerry dot main at starkgaming dot com