From many of the comments I read, the reason is often regulation.
The regulation requires controls, there are usually lots of ways of implementing those controls.
However more often than not the people buying these piles of goop are more interested in the cheapest/fastest/neatest way of satisfying those controls, actual security be damned.
So when vendor comes a long and says "our product meets those controls! all you need to do is tell the auditor you use product $X and you are done!" well that is an awfully compelling argument when those are your priorities.
Of course every security minded person dies a little inside but that is just how the world works for now, no-one has been sufficiently punished for these bad decisions yet but it will happen. Not a question of if, just when.
The lobbying does matter though as they lobby for increasingly useless controls that are harder and harder to satisfy with actual security (read least privilege design, capabilities, sandboxing, etc) and audit logging and become increasingly about "how big is your ruleset in your SIEM or equivalent and does it contain a specific rule that we can show auditor for control $Y" (yay Splunk/SumoLogic lobbyists) etc.
Not to mention stuff like pushing for TLS MITM boxes (self-compromising all your outgoing encrypted sessions is beyond insane) etc. The modern "security" industry is an embarrassment sigh.
Seems like the only way third-parties could do it 'effectively' is with kernel-level access, though I am absolutely not an expert in this field (light years from it).
https://www.cyber.gov.au/resources-business-and-government/e...
Having been an end-user going through the adoption of one of these third-party application control and auditing systems, I won't say which, or for whom, I can definitely state it was painful. Said system broke quite a few business-as-usual processes, despite a months long 'learning phase' and often required 'super user' intervention. Occasionally this is still the case now, because almost no software vendor (commercial or open-source) digitally signs all their files capable of executing instructions (either natively or via an interpreter). That said, the third-party app control package stops everything it doesn't recognise or has an exception for. I don't know how far it embeds itself into the system though.
It seems like vendors like CrowdStrike swoop in on the 'easy to be compliant' gimmick.
One wonders how many are aware of Microsoft's own products in this space? App Locker comes to mind.
Defender is direct Microsoft product offering in this space.
https://ia801200.us.archive.org/1/items/SyScanArchiveInfocon...
It incudes glaringly obvious advice like designing your code around the principle of least privilege or sandboxing code that handles untrusted input.
Unfortunately, not much has changed since then.
It's such a PITA and CISO live by not doing anything risky that few teams can get away with it.
If lots of people wanted to reduce their attack surface by about 90% or more they would already be unplugging their LAN cable (or equivalent wifi logoff) except when they have a strong need to be online to accomplish something that is not (or never was) possible to handle otherwise.
If that's not enough, then escalate until no-one without a desperate need to be online is ever connected, and then only during the most desperate times, if necessary.
Depends on how much isolation from questionable incoming code (whatever you did not specifically request) that you prefer to have how much of the time.
Ideally, all incoming code or downloads should be directed to safe storage and never executed until after the user has had a chance to deliberately scan it offline as many ways as they would like before attempting a test deployment.
Things just used to be a lot more ideal more of the time. So many kinds of business-as-usual once raked in the bucks without any online connection, have little or nothing more to show for it afterward, and now threats are eclipsing the benefits if any.
>the cheapest/fastest/neatest way of satisfying those controls, actual security be damned.
Cheapest, across-the-board is auto-patching when online, since so many systems are expected to be online whether it's good for them or not.
I thought it was plain to see it was moving in this direction consistently since the arrival of Windows Update.
That's the one big thing that initiated the possibility of mindless on-line patching replacing the previous deliberate, focused approach.
Every year since then fewer people even try to make software that is good enough to release under the original paradigm where it had full value, back when the need for patching would only occur on the rare occasion of true unforeseen bizarreness that could only be discovered after full release.
There's always been a real advantage when everything is more ideally suited to the task to begin with, and stays the same for years in a row except for when you really want it to change and know exactly what those changes are going to do in detail.
The need or preference for routine patching or updating is a dead giveaway for software that's probably not worth money to begin with.
lobbied by the same security company
Probably more likely with tech when regulators are more tech-illiterate than the situation requires.
All kinds of other regulations can be misguided for other reasons too, lobbyists' jobs are primarily there to do the misguiding.