[Info-vax] New VSI Roadmap (yipee!)

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Mon Mar 2 09:17:55 EST 2015


On 2015-03-02 04:47:45 +0000, Kerry Main said:

> Course, some might argue Sony had a security group, but that is likely an
> example of poor security implementation, monitoring and mgmt. i.e. 
> noone monitoring or alarming when a highly priv'ed acct transfers a 
> largeamount of data OUT of the company????

Sony?  Which time?   Sony reportedly had no firewalls and down-revision 
software when PSN network was breached back in ~2011.  
<http://www.eweek.com/c/a/Security/Sony-Networks-Lacked-Firewall-Ran-Obsolete-Software-Testimony-103450> 
   There are reports that Sony had few (no?) folks actually maintaining 
and monitoring security for this most recent breach 
<http://arstechnica.com/security/2014/12/unprecedented-cyberattack-no-excuse-for-sony-breach-pros-say/> 
<http://mashable.com/2014/12/08/sony-hack-unprecedented-undetectable/>, 
and reports that Sony had an earlier and substantial breach that went 
unreported 
<http://www.forbes.com/sites/thomasbrewster/2014/12/15/sony-pictures-germany-hacked-in-january/>. 


If you've got some spare time and some data left in your monthly 
allowances and some interest in the Sony breach, there are some related 
comments and opinions here 
<https://www.youtube.com/watch?v=vb-02HFShnk>, as well.

So yes, it does seem quite possible that there are mid- and large-sized 
companies that have definite problems implementing and monitoring 
security and security policies.

In some cases, there are some very skilled folks that are spending a 
whole lot of time and effort in securing a network, and — despite their 
best efforts — failing.  There've been reports that US Federal and US 
DoD Military networks are generally now assumed to be breached 
continuously; that the firewalls are rather less of a panacea and a 
security perimeter, and rather more of a general demarcation point for 
who gets to fix the gear when it fails.

Now if you want to look at OpenVMS in these environments, there'll 
necessarily be discussions around the general lack of cryptographic 
transport support common services (e.g. clients of the TCP/IP Services 
mail server still don't have SSL/TLS support), the lack of 
authentication for various operations (e.g. sysman), the lack of 
network monitoring, the lack of a programmable network firewall 
(firewalls are very far from a panacea, but still a useful tool for 
maintaining and monitoring network access, and for detecting unexpected 
traffic), exposed credentials (telnet, ftp and DECnet are all still 
around and enabling these protocols is still offered by default), the 
lack of support for an encrypted boot device (those NUC boxes recently 
discussed are really quite small and very easily portable, and a few 
larger OpenVMS servers have unexpectedly up and walked out doorways), 
no DNSSEC for those folks that subscribe to that as being a benefit, 
and a variety of other security-relevant issues and deficiencies.  This 
all ties back to why I'm not a huge fan of openly exposing OpenVMS 
servers to the wilds <http://labs.hoffmanlabs.com/node/621>.

OpenVMS is a good platform, and existing environments can use it 
successfully, and can use it securely.    But if you're a target and 
particularly one worth the effort in cash or lulz, you need to know 
where your configuration has weaknesses and exposures throughout your 
network, and that includes understanding your OpenVMS servers.  Beyond 
what I've mentioned here and elsewhere about OpenVMS security, your own 
application security is a central issue.  That ties into scans for 
strlen, strcpy, strcat and other C routines, unencrypted network 
transports, use of insecure protocols such as ftp or SSLv3 or lower and 
sometimes TLSv1.0 and lower, not coordinating server access and 
credentials via Active Directory or Open Directory (so that you can 
centrally disable specific accounts), down-revision on patches, and any 
local privileged image and any local privileged processes need reviews. 
 These and other issues are those that a local security review and a 
local security organization and security tests — Kerry's core point — 
should detect, and should work to resolve.

This is not an easy problem, and all vendors and all operating systems 
have issues, and all vendors have had and will have vulnerabilities and 
security patches.   The need to quickly learn of, to acquire and verify 
and install patches is only going to accelerate, too.

> In a nutshell, that is what US Govt and Snowden affair was all about  ..

Insider attacks are a whole 'nother issue, and a whole 'nother bag of hurt.



-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list