[Info-vax] App Hardening (was: Re: OpenVMS x64 Atom project)

[Stephen Hoffman]

On 2021-06-07 02:33:22 +0000, Dave Froble said:

> What, other than getting to run a program, could be done by the bad 
> guys on a VMS system?  I confess, I have not studied the issue at all.

Getting to run an app is pretty much game over.

> If the bad guys need to get access and run a program, would defenses 
> that check for valid programs running be successful?

That's akin to what's called whitelisting, and it's one approach. It's 
fairly common within Microsoft Windows configurations.

Latent flaws can still exist even in the approved apps, and the flaws 
can be subtle.

> So, yeah, if I can get access and run a process on VMS, much can be 
> done.  And possible defenses could be set up.  But if there are other 
> possibilities, one would need to know about them before considering 
> defenses.

There are a couple of discussions on this topic going on elsewhere.

I've been pondering creating a presentation on this topic as the 
OpenVMS doc here is grossly inadequate.

Identify your core data, and work to get rid of all of that that you 
can, and to protect what you must have and preserve.

Isolate apps with privileges into separate processes.

Avoid installed images with privileges, and avoid privileged shareable 
images, and review the internal details of those that you must have.

Subsystem identifiers are your friend.

Isolate parsers to separate and minimally-privileged processes; allow 
TMPMBX and/or NETMBX at most.

Implement telemetry in all production apps. Minimally, collect all app 
errors, all app crashes, and crash details, as well as 
use-of-privileges and manually-triggered app-critical functions and 
administrative functions.

Don't try to recover from unrecognized or unexpected errors. Log, exit, 
and restart.

Off-host logging; whether syslogd or otherwise. Logs are useful after a 
breach, but otherwise too much data to sift.

Automate scans of your configurations, including digital signatures.

PCSI kits for local app installs for faster recovery post-breach.

Find and rate-limit your sensitive APIs within your apps, as some of 
your own APIs can potentially be used to brute-force your own 
environment—akin to password brute-forcing.

Look for and constrain the directories and files and APIs that your 
user interface and your network interface apps can write to, and can 
read from.

CAPTIVE is just a start for hardening DCL procedures.

Encrypt your critical data while at rest (and OpenVMS is not good at 
this), and encrypt all of your network connections.

Backups and telemetry data and crash data cannot be writeable once 
written, and access credentials needed for writing and for reading kept 
separate.

All app-critical production functions must be scripted, outside of 
exceptional circumstances.

Collect baseline app and user and network activity data, and detect 
deviations from same. There are techniques for detecting these 
deviations, too.

Etc.



-- 
Pure Personal Opinion | HoffmanLabs LLC