Other than the myriad of problems with passwords that NIST has killed in competent circles, what are some other "useless controls"?
Just because this is my favorite soapbox - anyone that has to deal with passwords should go read NIST SP800-63B:
https://pages.nist.gov/800-63-3/sp800-63b.html
I was kind of shocked by just how gosh-darned reasonable it is when it came out a couple of years ago. It's my absolute favorite thing to cite during audits.
"Are you requiring password resets every 90 days?"
"No. We follow the federal government's NIST SP800-63B guidelines which explicitly states that passwords should not be arbitrarily reset."
I've been pleasantly surprised that I haven't really had an auditor push back so far. I'm sure I eventually will, but it's been incredibly effective ammunition so far.
Did it used to be and was since retracted? I suppose it may be a local or state-based 'implementation augmentation'.
I've trawled just now through the signals directorate site and can find plenty of references to passwords, but nothing specifically covering this.
We also had scans report GPL licenses in our dependencies, which for us was a total non-issue, but security dug in, not because of legal risk, but compliance with the scans.
It's a shame, your story isn't unique at all.
Like, IT sec does not trust employees. This burns absurd amount of money day in, day out, due to broadly applied security policies that interfere with work.
Like, there's a lot of talk about how almost no one has any business having local admin rights on their work machine. You let people have it, and then someone will quickly install a malicious Outlook extension or some shit. Limits are applied, real-time scans are introduced too, and surely this inconveniences almost everyone, but maybe it's the right tradeoff for most of the org's moderately paid office workers.
But then, it's a global policy, so it also hits all the org's absurdly-highly paid tech workers, and hits them much worse than everyone else. Since IT (or people giving them orders) doesn't trust anyone, you now have all those devs eating the productivity loss, or worse, playing cat-and-mouse with corporate IT by inventing clever workarounds, some of which could actually compromise company security.
In places I've seen, by my guesstimate that lack of trust and ability to issue and monitor exceptions to security policies[0] could easily cost as much as doubling the salary of all affected tech teams.
As much as big orgs crave legibility, they sure love to inflict illegible costs on themselves (don't get me started about the general trend of phasing out specialist jobs and distributing workload equally on everyone...).
--
[0] - Real exceptions, as in "sure whatev, have local admin (you're still surveilled anyway)", instead of "spend 5 minutes filling this form, on a page that's down half the time, to get temporary local admin for couple hours; no, that still doesn't mean you can add folders to exclusion list for real-time scanner".
The same employer also mandated a multi-hour ethics guidelines course yearly that was 90% oriented towards corporate salespeople, and once demanded everyone take what I believe was a 16 hour training set on their particular cloud computing offerings. That one just have cost them millions in wasted hours.
Isn't it just a burden on the security team & the organization at a whole if nothing else? If every team gets to exempt themselves from a ban just because they use the thing responsibly, then suddenly the answer to the question of "are we at risk of X which relies on banned thing Y" can become a massive investigation you have to re-do after every event, rather than a simple "no".
I don't know the details of your situation obviously, maybe there's something silly about it, but it doesn't seem silly to me. More generally, "you can only make an exemption-free rule if 100% of its violations are dangerous" is not how the world works.
Compliance assessments at least the assessments I have worked with, take a risk based approach and allow for risk based decisions/exemptions.
If you have a vulnerability management process which takes what the scanning solution says at face value and therefore your process assumes ALL vulnerabilities are to be patched, then you're setting yourself up for failure.
Password resets are definitely one, and I still have to tell prospects and customers that I can't both comply with NIST 800-63 and periodically rotate my passwords, every single day. Other ones I often counter include other aggressive login requirements, WAFs, database isolation, weird single tenancy or multitenancy asks, or for anti-virus to be in places that they don't need to be.
So it ends up on the network, unprotected.
Edge case and your answer, in spirit - public-facing server, can't have a HW firewall in-line, can't do ACLs for some reason, can't have EDR on it.... at least put on a Linux host-level FW and hope for the best.
Do you mean "why does Linux allow firewalling based on the source host"? Linux has a flexible routing policy system that can be used to implement useful controls, host is just one of the available fields, it's not meant to be used for trusting on a per-host basis.