That's a perfectly valid paragraph. In a decent environment, outbound internet access should be restricted to only the hosts / networks / ports that require it. Especially for server environments. Many servers running the backdoored Orion probably tried to beacon but failed for that reason. (And I'd assume the backdoor would probably first verify outbound internet access so that the failed beacon doesn't generate a firewall/ACL deny event that a security team might detect.)
Plus, the article is written to condense technical information into something that's as layman-friendly as possible. The specific malicious update has to be downloaded, and also installed, and also running on a server which can reach out to anything on the internet. Their point is that there are only going to be so many servers that both use this software and meet those conditions, and that's in part why the backdoor took so long to identify. This is maybe a little obvious to people with infosec knowledge, but definitely not obvious to their target audience.
The article timing is interesting, but I don't think a coincidence is that unlikely. If you read the whole article, it covers enough that I could see it taking months to make.
I don't think coordination with the government is that unlikely, either, or perhaps just a pragmatic editorial decision ("everyone knows sanctions are likely going to be placed sometime in the next few months, and maybe we should wait until then so we can include those details in the story"). Both of those scenarios are more likely than a coincidence, probably - but, either way, I think your post seems overly cynical in general.
I whitelist my networks (by port and host name, At least until TLS 1.3 removes the visible SNI) and my top denies list is very interesting. They have access to bits and pieces of the internet (especially PyPi damn you runtime downloads) and all connections to an allowed port will succeed (they will just be closed after the SNI or IP check fails).
Nonetheless the article was correct the hack did not need bizarre or rare circumstances to take effect.
Not exactly sure what they meant, but maybe just that it's often hard to install a single Python package if the machine can't reach PyPI. If you download a tarball or wheel of some Python package on a different computer and transfer it to the isolated computer, there's a pretty good chance the package is going to have at least one third-party sub-dependency, in which case trying to install it with pip or setup.py will cause it to try to install more packages from PyPI.
Docker's a decent way to address this, since you install the dependencies when building the image rather than when running the container, so you can build the image elsewhere or through CI and run the container on any server without having to allow access to package management repo servers.
Plus, the article is written to condense technical information into something that's as layman-friendly as possible. The specific malicious update has to be downloaded, and also installed, and also running on a server which can reach out to anything on the internet. Their point is that there are only going to be so many servers that both use this software and meet those conditions, and that's in part why the backdoor took so long to identify. This is maybe a little obvious to people with infosec knowledge, but definitely not obvious to their target audience.
The article timing is interesting, but I don't think a coincidence is that unlikely. If you read the whole article, it covers enough that I could see it taking months to make.
I don't think coordination with the government is that unlikely, either, or perhaps just a pragmatic editorial decision ("everyone knows sanctions are likely going to be placed sometime in the next few months, and maybe we should wait until then so we can include those details in the story"). Both of those scenarios are more likely than a coincidence, probably - but, either way, I think your post seems overly cynical in general.