[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