> Couple that with all the security crap the DoD has to put on there (which probably spends half its time trying to grab resources from the other security software)

Corporate spyware is a huge impact to performance, particularly if you have an HDD. I can’t count how many times I’ve seen a computer start to lock up because some security software needs to absolutely abuse the disk.

I'm in security, and one thing I always try to stress is that if the security software is causing work stoppages, it should be treated with the same importance as an outage. Just as you wouldn't tolerate an internet connection that went down all the time. Outages from security measures are still outages.

> I'm in security, and one thing I always try to stress is that if the security software is causing work stoppages, it should be treated with the same importance as an outage. Just as you wouldn't tolerate an internet connection that went down all the time. Outages from security measures are still outages.

Outages/workstop are pretty binary. Otoh its hard to see how much time people spend just waiting for stuff to complete. At my last job, pulling down a copy of the test db for local use was taking 30-40 minutes. But because everything else was slow, it was only after I noticed it being a lot shorter for coworkers that I even bothered investigating what was causing it (version of mysql was old, made it a 5-10 minute process after fixing a config).

I’d love to get my hands on some of this crap, just to watch what all it’s actually doing. God knows I can’t afford that bloatware though.

I’ve got a hint that a lot of it is doing stuff that the OS might even consider malicious.

It's doing al sorts of interesting things. They subscribe to event feeds supplied by the operating system to keep track of security related events: modules that are loaded, processes that start, connections that open and close, users that log in and log off.

Then they also inject themselves into processes and 'hook' into operating system routines to check things the feeds to not provide: which files are being accessed, how often, what memory is allocated, what type of memory is allocated, which threads are running, where they are running and what they are doing, if there's mismatches between what the operating system told are the modules loaded, and what it can find in memory.

Most of this software can be configured so that the resource usage is relatively tame, but then on the next pentest the security people will notice all sorts of ways the products did not catch them (this is the usual case). And then things are tuned to max in short order :) And then you have security software running multiple rules and scans on each file any process opens. And processes open a lot of files, all the time.

And they're rarely tested with other competing software, and once they start both hooking on the same thing (and each other) you can get a death spiral.

Yea, certain routines in windows actually check if the OS is hooked. The PE loader implemented in ntdll verifies that NtOpenSection() (or NtOpenFile, not sure right now) has not been hooked. When I was looking into that it looked like it disabled concurrent module loading if detected a hook(so it became slower), probably as a bug fix for whatever software inserts itself in that place (Stuxnet did too!).

A “boon” is something that is helpful, not detrimental

Edited

> GPOs

I didn't know what this meant, so I looked it up on DuckDuckGo.

The first relevant result was from... a DoD website.

https://public.cyber.mil/stigs/gpo/

They're definitely not something special about the DoD. They're core parts of configuration and policy enforcement on Windows systems. Any organization managing Windows systems will use Group Policy Objects.

https://en.wikipedia.org/wiki/Group_Policy

that's just config management for the windows desktop and has been around for ages. They mostly just flip a corresponding registry key and are idempotent, so the impact is minimal aside from the first time policies are processed. The reason that DoD site appears in search is because their STIGs (security technical implementation guides) are a freely available best practice reference for any windows administrator to use.

You do not want to apply all of their reccomendations to any computer, but I will say that fully STIG'd computer will actually not take that long to boot up, aside from the first application of the policies. Login performance usually comes down to drive maps, printer maps, and startup programs.