[Info-vax] DECnet challenge

[Stephen Hoffman]

On 2019-03-01 20:18:21 +0000, Mark Berryman said:

> They have been configured by a network engineering staff who knows what 
> they are doing.

Now try that same network configuration again with what passes for 
networking in many of the organizations running OpenVMS and DECnet.

Which is very far from perfect security.  Even with a good team.

Worse, with the sorts of folks that have unfortunately chosen to 
believe some of the worst of the marketing codswallop around.

It's always been (theoretically) possible to lock down and isolate 
servers and server networking.  That was the foundation of the NCSC 
Orange Book security decades ago.

Keeping all that locked down and isolated... gets interesting.  
Mistakes, compromised staff, compromised servers and devices, and 
compromised apps.  And with ever-changing requirements for 
communications and cross-connections.

Pragmatically, we're way past trying for perfection.  Or we should be.  
Which is what this talented-management approach seeks.  Or the 
only-use-highly-skilled developers approach that has been suggested for 
system and network and app deployments.

Assuming we're not going to be perfect leads to discussions of 
mechanisms to increase difficulty.  Which can include sandboxes, ASLR & 
KASLR, W^X, etc.  And encrypted and authenticated connections.

Failures in complex systems are seldom single events.  They're a chain 
of mistakes.  As are exploits.

Unauthenticated connections and cleartext credentials is really hard to 
scale.  Tell me that you'd trust this cleartext configuration to 
maintain security over months and years, across staff churn and 
consultants, across malware-infested printers, and across software and 
firmware upgrades, the telnet and ftp usage for reasons, across patch 
rollouts for printers and switches and servers and MRI scanners and 
embedded warehouse control systems that can take days or weeks or 
months or years, and across the "fun" that is side-channels of other 
co-resident guests peeking into your clients and into your servers.

Ponder explaining this series of decisions to an auditor or a 
regulator, and particularly post-breach.

Fix your unauthenticated and unencrypted links.   Though if your 
management is willing to make the trade-offs around continuing to use 
cleartext links, maybe get that in writing.  Even if you may well still 
be left holding the blame. And expect to have to fix it anyway.


==


Related Reading:

http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf
https://arxiv.org/abs/1902.05178
https://medium.com/@daniel.p.woods/on-infrastructure-at-scale-a-cascading-failure-of-distributed-systems-7cff2a3cd2df 



==


ps: As for your question, I'd likely start with side channels on the 
servers and extracting keys, and with attempting to mess with the IP 
network (ARP, iBGP, WAP, DHCP) via an infested printer or infested 
client.  I'd also consider tossing DECnet routing messages from rogue 
DECnet hosts (IV is tougher here than V, if the switches are paying 
attention), or from existing DECnet or IP hosts that have 
"mysteriously" become routers for DECnet traffic.  And I'd be more 
interested in watching the DECnet and SCS traffic than necessarily 
spoofing a DECnet proxy through obtaining a privileged network position 
via routing or mirroring or finding bugs, as the cleartext or 
poorly-hashed creds visible via DECnet and SCS and telnet and FTP are 
going to be useful for furthering access.  Am I certain to get into the 
DECnet network?  No.  Can a good team block these paths?  Sure.  But 
I'm still not inclined to prefer to run unencrypted and unauthenticated 
and cleartext network traffic.


-- 
Pure Personal Opinion | HoffmanLabs LLC