Post by IanD<snip>
Post by David FrobleWell, one could step back a few more paces, and think on whether
attempting to use any password scheme is a reasonable way forward. One
of the first questions to be asked is whether it's a good task for an
OS to control access? Just cause it's always been done that way is not
a good reason.
We're going to be using passwords for the foreseeable future.
Increasingly with 2FA. Because there isn't an alternative.
Post by IanD+1 as to the reason to challenge what we have always done
Always challenge assumptions. Sometimes they're still necessary and
appropriate. Sometimes not.
Doing the same thing usually gives you the same outcome. That might
not be the best outcome, particularly in changing conditions.
Post by IanDI used to think VMS was really secure but of late, I have started
looking more into security. After doing some good security courses of
late to better my knowledge in this field (Edx / MIT course-wear /
Moocs) and I'm of the opinion that VMS is nowhere near as secure as
what the general belief out there is of it. I've had my cage rattled
about VMS security, and that's a good thing
Get yourself onto the security flaw feeds, and start getting a feel for
where the problems are, and how fast the flaws become known, too.
Post by IanDWhen you look at how systems become compromised, you can see VMS has
some real needs on it's plate around modernising security and it's
security management tools (or lack of).
Start looking at how some of the newer systems are being managed, too.
The ones I work with are vastly easier to deal with than OpenVMS, and
do more. That's starting with a base of knowledge around how OpenVMS
works, too.
Post by IanDHumans are still the number one break-point in security holes being
exploited, the whole VMS security is so dispersed and piecemeal in it's
management, that it opens itself up to attack through people mistakes /
misconfiguration. This alone is the biggest need for VMS on the
security front IMO
This extends well beyond security. We're not going to get more staff,
more experienced staff, better staff. Not easily, nor cheaply. Most
likely, we're going to get what we have, or less. As end-users, we
can't use systems that require more effort. As product producers,
shifting management and development costs onto the end-users is
increasingly intractable, too. Go try setting up clustering some
time. It's an utter train-wreck. Works great once it's all
configured, but getting to the working configuration is just insanely
manual. Sure, if the end-users are willing to wade through the manuals
— and know where the ~24 shared files are documented — clustering is a
fine solution.
But once you have that clustering configured and working, you still
have security problems and double-secret "best practices" — rather
than, you know, just installing and working and being simple and
secure. Just working. Like we'd all prefer. Like OpenVMS used to
do and to be, back when it was a good and cheap and simple alternative
to then-current servers. What many of us remember. Instead, we're
now dealing with configuring and managing and securing management VLANs
and protecting the clustering traffic against rogue printers and
writing our own DCL procedures to correctly secure our keys and encrypt
our backups and the rest of the "you didn't _know_ that?" steps
increasingly involved. This because we're dealing with badly
down-revision iLOs and down-revision SSL and SSH and the rest.
Just getting an OpenVMS system patched to current is a slog, compared
with other systems. What's that tell you?
As a developer, go try to write a secure network-accessed distributed
app on OpenVMS, using cluster features. Go ahead. Try it. I'll
wait. Get 2FA and maybe Kerberos working while you're at it, given
you're going to have to go write your own 2FA or acquire and integrate
some third-party support for that, and sort out how to deal with
delegation.
This whole area needs to be massively simpler to install, configure,
manage, troubleshoot, develop for....
Post by IanDPushing security in a distributed model (letting applications do it)
only increases the surface area for an attack. Having it all in one
place is bad news if your security comes unraveling though.The trend
seems to be to try and fortify centrally but also have additional
external check measures to notify / shutdown / halt the process when
something looks amiss
Massively.
Post by IanDPost by David FrobleNo, I have no suggestions. Not something I think about.
In some situations, perhaps access might be better implemented in the application.
Two factor authentication / biometrics / etc are just some areas.
Integrated management tools is highly needed to stop silly mistakes
being made
2FA is about the best that's available, preferably not via SMS.
Post by IanDVMS doesn't have an audit checker included with it. If we are looking
for ways to add value, then this would be a good include for customers.
Buy VMS, get a built-in audit checker for free
For an OS as-pounding to be the ants-pants of secure OS's, then a
verification tool should be included, not a bolt / add on (I once
worked briefly with one of the people who wrote 'Security Toolkit',
which they ended up selling to DEC way way back).
There are some simpler things too. Being able to white listing / black
list commands and there qualifiers for a process / user would also help
with security.
Command auditing doesn't do what you want. It's useful as part of
DFIR, but it's not going to be a reliable access control mechanism.
If you're not going to actually solve the problem with whatever you're
doing, then aren't you really just adding more complexity?
Post by IanDRemoving commands from users is not integrated into the UAF
See previous comment.
Post by IanDand if anything, it should be the reverse anyhow, you start with
nothing and authorize commands upwards.It's way too granular simply
removing the verb if you want to limit commands, I would like the
ability to in some cases allow the verb but disallow the qualifier(s)
or certain qualifiers
If you want to disable access, you need to work within the
security-relevant accessors and objects involved, and commands are not
those. That is, ACLs and ownership and identifiers and related, and
files and queues and sections and such. Within what the OpenVMS access
control system is designed to mediate. There's a big diagram in the
OpenVMS security manual. That diagram and the whole OpenVMS model
really needs to be extended out to deal with LDAP and Kerberos, but it
covers local authentication well.
Post by IanDAdd decent auditing like capturing commands used as well. Auditing is
also part of good security. (yes, I know you can get these out of sda
but they are not automatically captured and they vanish when the
process exits).
Logging everything is great if you want to drown yourself in data, and
quite possibly meaningless data.
Post by IanDYou cannot easily or thoroughly put together how someone has walked
through your system with the current tools, not without turning on
auditing to a level that will impact the machine performance. Good
auditing is almost as important as good lock-down
Across all systems, too. Integrated with app failures, too, as
crashes can be an indication of probes. But most folks are not
working with systems that are directly accessed via the command line
for the end-users, with general DCL access increasingly reserved for
developers, administrators, and other trusted folks. And only when
they really need that, if we look forward.
Post by IanDWork pattern matching is another area, sort of akin to banking / credit
card companies and how they monitor out of character spending. Google
has done some nice work on account monitoring with their location
scanning and device monitoring. I know that for VMS that might prove
too difficult to get right since we don't have access to the same types
of data but work pattern matching might be something to start to gather
for analysis later on?VMS at the moment wouldn't report an anomaly if
the same account logged in from two different locations at the same
time, for example
Heuristics. Distributed logging and correlation. Etc. But that's
so far out ahead of what OpenVMS currently provides, that'll most
likely only ever be available a third-party add-on for the foreseeable
future.
Post by IanDSecurity on VMS certainly needs a huge revamp. It really has sat still
for the past decade or so while the world moved on. In some
environments that might be ok if a fully closed shop but who knows how
long that closed shop will remain closed to a world that wants to
integrate
Existing and isolated and task-dedicated servers and shops are a nice
base where they even still exist, but they're not the future.
Post by IanDPost by David FrobleBut, if looking at the issue, why not consider all options, whatever they are.
And, if other method(s) are adopted, then just don't worry about the
VMS password. With the option of not allowing it's use.
Again, it ain't the password that was being discussed in this thread,
it's the password hash.
Post by IanDIf VMS wants to differentiate itself then it's going to have to offer
more than what the others do in ways that add value. Security adds
value IMO
Security isn't a huge selling point for most folks, unfortunately.
It's a nice-to-have, but just as soon as it gets in the way, or gets
too expensive, security tends to either get ignored or otherwise worked
around, or somebody has to mandate the security requirements (e.g. PCI,
financial regulations, etc) and that approach is also certainly
problematic. In many ways, security is similar to insurance. You
want to have enough. Too little or too much is a problem. Each site
invariably ends up making those calculations, too. It'd be really
nice to differentiate on easy-to-use and fully-integrated or other
such, but I'm working with other platforms that already have that.
Post by IanDWillingness to look at security is a start, rather than just believing
VMS is secure and as you have said, also challenging assumptions makes
for a good start
That's not going to happen easily. I'm sure the folks at VSI are
learning a whole lot about this, and rate of change across the whole
area is not slowing down.
Post by IanDx86-VMS is probably around 12 months away :-) so frame-working ideas on
how to bolster it' security needs to be happening now, not after it
jois the rest of the planet on x86
I'd be surprised if there was particular new work going on here. Some
incremental work such as 2L1, certainly. Integrating fixes for the
password hash or adopting and integrating LDAP and Kerberos will be
more effort and more disruptive, and there's a constituency that
strongly prefers compatibility over change. That work also pushes out
the port, and you can be certain VSI wants to get the x86-64 port out
the door just as soon as it's stable and supportable and salable.
Post by IanDWhen VMS appears in the cloud, it's going to expose itself to a whole
new audience, some who will want to take an axe to it to see if they
can break it
Just as soon as you connect to the network, and have some reason —
credit card data, sensitive information, vulnerabilities that can be
leveraged into a DDoS against others, whatever — you're targeted. No
cloud needed.
Post by IanDPerhaps it's time for an overall VMS security thread of it's own?
I've been discussing this topic for years here in comp.os.vms, and have
delivered multiple presentations on the topic at boot camp. Others
have posted and presented, too. But then some of us actually have to
use OpenVMS security, and get it connected to other servers. That's
increasingly an adventure, particularly for anyone that's used other
platforms and then has to try the same on OpenVMS. The "cool and
unhackable" mantra quickly runs afoul of the "why can't modern SSH
connect to my OpenVMS system?" or "why aren't my network connections
encrypted?" or "why am I being told to fall back to TCP 80 and disable
TCP 443 when the rest of the world is moving to 443?", and goes rapidly
downhill from there.
VSI is working diligently on the port and on updating the capabilities,
and they've already done some work on security and networking. This
however is a massive effort. VSI needs to get to stable positive and
preferably increasing revenues first, and then they can start looking
at addressing security or whatever other areas will bring them the
revenues they need to build their staff and build their installed base
and — once they get far enough along — start adding wholly new partners
and new apps.
--
Pure Personal Opinion | HoffmanLabs LLC