I was once talking with an FCC agent about the status of some boards we were importing, and he told me about how Michael Dell would blatantly violate FCC regs with their computers, fight it for a while, then pay the fine out of "Federal Regulatory Account" -- he just happily violated the law and paid the fines enough to have a specific bank acct for that. He was not amused.
I'm pretty sure that it would require a demonstrably real threat of jail all the way up the management chain -- that might focus their minds a bit
I did mention that possibility - but to emphasize, it'd have to eb effectively death-penalty for the corporation - just wipe them out.
I'm still not sure that would be sufficient, because there are soooo many examples of horrible managers/executives just torching $$millions and failing up. If any of those executives ever got another job much above the level of sandwich-maker, it would provide no deterrent.
It really looks like at many levels, network and data security needs to be treated as a national security level problem, and any decision to fail to implement state-of-the-art level protections treated as a deliberate compromising of NatSec akin to leaving classified material or CUI (confidential unclassified info) on the sidewalk; not sure what the applicable law is, but that level of negligence is at least the start of serious trouble.
I guess there is some merit to the zero trust security model, since it should urge you to secure every bit of software that you run, without necessarily setting up bastion hosts/DMZs or other types of "server-based ACLs" like that: https://en.wikipedia.org/wiki/Zero_trust_security_model (since i've seen the fact that you have a "perimeter" get used as an excuse to get lazy about security aside from it)
Yet, i've found that it's just too risky, given how brittle most of our software, including its security functionality, actually is. Just the other day i had even the simple blog software that i use (Grav) fail enforcing its admin login functionality, something that seems incredibly simple on the surface and should be bulletproof, yet somehow wasn't: https://blog.kronis.dev/everything%20is%20broken/grav-securi...
Thus, personally i've found that what's worthy of consideration is taking a bit from both approaches. For example, running everything in containers with overlay networks (not even dedicated service meshes necessarily, even the way how Docker Swarm does it is pretty good: https://docs.docker.com/network/network-tutorial-overlay/) that can expose your apps/web servers on every node where necessary, yet keep your DBs constrained to running inside of the overlay network and thus remain inaccessible from the outside.
If and when you need to connect them, maybe run a container with SSH and WireGuard/OpenVPN that let's you forward ports and thus get access to the overlay network, or alternatively just use orchestrator functionality (for example, Kubernetes allows this, albeit i dislike its complexity otherwise) for this.
Not something I would usually test for, but lesson learned. Thank his noodliness we don't have ssh exposed anywhere outside our network.