[Info-vax] Security Challenges

[IanD]

On Friday, November 25, 2016 at 12:35:05 AM UTC+11, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> > Of David Froble via Info-vax
> > Sent: 24-Nov-16 4:22 AM
> > To: info-vax at rbnsn.com
> > Cc: David Froble <davef at tsoft-inc.com>
> > Subject: Re: [Info-vax] Variable declarations, was: Re: improving
> > EDT
> > 
> > Kerry Main wrote:
> > >> -----Original Message-----
> > >> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On
> > Behalf Of Paul
> > >> Sture via Info-vax
> > >> Sent: 23-Nov-16 5:49 PM
> > >> To: info-vax at rbnsn.com
> > >> Cc: Paul Sture <nospam at sture.ch>
> > >> Subject: Re: [Info-vax] Variable declarations, was: Re:
> > improving EDT
> > >>
> > >> On 2016-11-23, Kerry Main <kemain.nospam at gmail.com>
> > wrote:
> > >>> Based on this conversation, this is a timely article from earlier
> > >>> today:
> > >>>
> > >>> How to Protect the Encryption Keys to Your Kingdom
> > >>> http://bit.ly/2g3fxw4
> > >>>
> > >>> "Tatu Ylönen, CEO and founder of SSH Communications
> > >> Security, was
> > >>> clearly frustrated as we talked over lunch. “Why can’t I get
> > >> through
> > >>> to them,” he asked, almost rhetorically. Ylönen was
> > expressing
> > >> a level
> > >>> of dismay common in the security industry.
> > >>> Getting senior management to invest in security can be a
> > >> daunting
> > >>> task."
> > >>>
> > >>> Original will wrap:
> > >>> http://www.eweek.com/security/how-to-protect-the-
> > >> encryption-keys-
> > >>> to-your-kingdom.html
> > >> Heheh. I stumbled across a video by Tatu on this subject just
> > last
> > >> week.
> > >>
> > >> A much more detailed account of the ssh key management
> > problem can be
> > >> found here on Tatu Ylönen's company website:
> > >>
> > >> <https://www.ssh.com/iam/ssh-key-management/>
> > >>
> > >> --- start quote ---
> > >> We have worked with many companies, including several
> > global
> > >> top-10 banks, leading retailers, and other large Fortune 500
> > >> companies. Based on our findings, most organizations:
> > >>
> > >>     Have extremely large numbers of SSH keys - even several
> > million -
> > >>     and their use is grossly underestimated Have no provisioning
> > and
> > >>     termination processes in place for key based access Have no
> > >> records
> > >>     of who provisioned each key and for what purpose Allow
> > their
> > >> system
> > >>     administrators to self-provision permanent key-based
> > access -
> > >>     without policies, processes, or oversight.
> > >>
> > >> In the case of one representative customer, we went through
> > a quarter
> > >> of their IT environment as part of a major SSH key
> > management
> > >> project. They had five million daily logins using SSH, most of
> > them
> > >> using SSH keys for automation. We analyzed 500 business
> > applications,
> > >> 15000 servers, and found three million SSH keys that granted
> > access
> > >> to live production servers. Of those, 90% were no longer used.
> > Root
> > >> access was granted by 10% of the keys.
> > >> --- end quote ---
> > >>
> > >
> > > Which then begs the question .. "is SSH and associated key
> > management a truly supportable security solution to a large scale
> > problem?"
> > >
> > > Support complexity and the ability to handle it is a critical
> > consideration when deploying any new solution.
> > >
> > > Given the scenario described, one could argue that this is
> > actually a very insecure solution because it provides a false sense
> > of security.
> > 
> > Well, yes, most of today's "security" is a false sense of security.
> > 
> > When someone says "we're using SSL" the assumption is that
> > everything is Ok.
> > But is it?  Last I read, TLS V1.2 is the only version that hasn't had
> > problems.
> > 
> > Now I'm sure that just about everyone wants a "solution" that
> > they just use.  As the above shows, a solution is only as good as
> > the usage of the solution.  Like it or not, it comes down to capable
> > people closely managing whatever security.
> > 
> 
> [snip]
> 
> To emphasize your point which I think might be summarized via the old saying "security is only as good as its weakest link", some unfortunate news today involving HPE and the US Navy:
> 
> http://on.mktw.net/2ghpupc
> "The personal data of more than 130,000 sailors in a re-enlistment approval database was stolen from a contractor’s laptop, the Navy disclosed Wednesday."
> 
> Original will wrap:
> http://www.marketwatch.com/story/hewlett-packard-enterprise-breach-leaks-info-of-navy-enlistees-2016-11-23
> 
> Likely more press to follow ..
> 
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

Do you notice that these articles often are light on the details as to what OS was used

Seamless security cost money. Bio-metrics I dislike immensely yet in some places it's mandatory or you don't get access (DC's for example)

If the security measures get in the way of you doing your job it will be abandoned and/or circumvented and/or watered down until it doesn't get in the way

I've seen a lot of horrible stuff happen with ssh keys, mostly done by people who have not had proper training or read well documented articles / procedures on it (I liken the VMS stuff around ssh to be poorly documented too)

I've seen people copy both private and public keys to others in an effort just to get things working - much like novice VMS folk hand out all number of privileges when they want to just make something work rather than find the correct solution

I spent weeks looking looking reading reading sites on how to set up ssh keys on VMS. The unix stuff helped a bit but that's often ssh1 related. The VMS stuff was horrible, often lacking examples and never going into what could be wrong if it doesn't work!

There was one site that helped (can't remember the name, it wasn't hoffman labs which has a good article on putty and shh keys) that was VMS specific and takes you through the various forms of ssh on VMS but it has it's holes too

>From directory permissions, to key files, to bugs, to you name it, can all break and/or make setting up ssh a pain in the arse and when it's this hard, it's little wonder people get it wrong and effectively open up their systems for attack. 
I'm sure in my learning I made some bad security mistakes too!