>
To gain access to the M.T.A. and other systems, the hackers took advantage of vulnerabilities in Pulse Connect Secure, a widely used connectivity tool that offers workers remote access to their employers’ networks. [...] The hackers took advantage of a so-called “zero day,” or a previously unknown coding flaw in software for which a patch does not exist.The Pulse VPN has a history of security issues (see e.g. https://arstechnica.com/information-technology/2020/01/unpat...) - so much so that the second and third Google autocomplete results are "pulse vpn vulnerability" and "pulse vpn hack". One practically enforceable at scale rule is to pay attention to whether your vendors have a bad security track record and also be meaningfully prepared to switch (switching VPNs is no fun, but it's doable).
Another one is to ask your vendors what they're doing about their security track record and whether they are taking systematic measures to make zero days less frequent and not just fixing individual bugs. "Stop using memory-unsafe languages" is one of my favorite answers to that, but there are a lot of others: "use sanitizers," "test your code with fuzzers," "use open-source components for the privileged portions," "get frequent third-party audits," etc. are all potential answers too. Some work better than others; any of them is better than not having an answer.
> “The M.T.A.’s existing multilayered security systems worked as designed, preventing spread of the attack,” said Rafail Portnoy, the M.T.A.’s chief technology officer. [...] there was “no employee or customer information breached, no data loss and no changes to our vital systems.”
The other really good answer here is to not have an all-or-nothing architecture for your network, and it sounds like the MTA is doing that already. Don't wire the train-switching network to the email-checking network just because you can. This is much harder to practically enforce at scale in an environment that wasn't designed for it, but it's a great rule to enforce in new systems. Any time you build something that would be worse to get taken over by hackers/ransomware/whatever than the rest of your company's computerized systems, build it separately and make limited interfaces for people to interact with it.
The move to put everything in the cloud really ought to make this easier: you can make a new cloud account for new systems and use bastion hosts etc. for developer access to them, instead of throwing it in your existing account.