Either of the targets you mentioned are more the symptom than the root cause: management setting up bad incentives. If you have a charge management process which takes a month to approve updates, the problem is not the sysadmin. If years of skimping means that the operators are afraid to patch because they’ll be punished if it breaks things and they don’t have a robust testing process, the problem is not the sysadmin.
It's been a giant pain having spent years trying to get organizations to accept the need and learn to do this stuff reliably only to have the primary source of misery (Microsoft) repeatedly start biting them in the ass again for what should be best practices.
Meanwhile in the same timeframe most BSD and Linux releases have not only gotten their core software updates down to a science, they've also managed to build workflows that can include huge swathes of 3rd party open source and commercial software, which is so hilariously awful on windows that multiple companies build businesses around doing it.
Microsoft laid off all their QA staff in 2014, so it's hardly surprising. If anything, it's a wonder that it's not much, much worse than it is now.
This is a really tricky problem in government because the pay scales can be very hard to change. For example, the U.S. federal scale has hard caps - the GS scale max is currently $170k, which might not sound that bad but historically the higher-level positions were senior and relatively limited, so it’s not like you can just effortlessly bump all of your developer positions up to the highest grade without hitting budget caps and other people being upset that someone outside of IT needed 25 years of experience and managing a bunch of people to get to the same rank as you’re proposing to offer to non-entry level developers. That probably means you’re hiring people at lower levels which are more like entry level pay.
A few years back they actually had to try to have a chance of hiring good infosec people but that requires a lot of political wrangling even if everyone agrees that it’s a good idea. (I know someone who got tired of waiting - jumped to a well known tech company for a cool 200% raise)
https://www.opm.gov/policy-data-oversight/pay-leave/referenc...
What's worse?
a) Deploying a fix and (unlikely) some, perhaps all, related systems fail until they are fixed internally or
b) Not deploying a fix and have your servers owned by an adversary?
The state of infosec is still that bad and unfortunately most consumers can’t know of these problems let alone choose to opt out. Right now much of the cost of a breach is borne by the end users who didn’t choose the poor level of security the organization implemented, and I am increasingly of the opinion that it’s better to bring down your organization’s IT infrastructure than to suffer a catastrophic breach. Because if the pain if borne by the internal IT teams more than the end user (who again often has no knowledge or no choice), eventually the company will be forced to implement better processes.
As long as the real cost of a breach is paid for by end users, organizations have very little incentive to improve.
What the CISA memo does is change that dynamic: now most of the government has instructions to act and it’s thus personally riskier not to act promptly.
Every 3 months for at least the last 18 months, they've ended up with no updates/patching for a month. Friend informs compliance and risk manager, compliance and risk management scream at accounts payable to get the outsourcer paid in full to get this month's security update done, and the circle of life repeats.
... or who's sole purpose is to run software that only runs on Windows Server 2008 Service Pack 2 without any more recent updates. (And which also need to be on a network that allows untrusted access. Perhaps unsurprisingly, this was Huawei WiFi management software. I'm _so_ glad I'm no longer on the hook for anything to do with that project/client...)
See step 3a in the following link for a guide on how to set the registry key. https://support.microsoft.com/en-ca/help/4557222/how-to-mana...
An attacker would need to do initial intrusion first, and then discover the vulnerable server. This means there is a lot less pressure on getting these things patched immediately
That’s a bold (and incorrect) statement. What you meant to say is “hopefully (and in most but not all cases) these servers are not publicly facing”. Because I’ve worked with an alarmingly high number of organizations where their internal AD absolutely is public facing.