3 ms·

From many of the comments I read, the reason is often regulation.

by Semaphor 2y ago

r0ks0n 2y ago
guess who's lobbying for that regulation
- fuzzfactor 2y ago
  Misguided regulations are more common than not, that's the real damaging kind. 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.
deleted 2y ago
[deleted]
jpgvm 2y ago
The regulation doesn't mandate these systems. 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.
- ykonstant 2y ago
  I am very interested in alternative ways of implementing controls to satisfy regulations; especially in ways that reduce, rather than increase, attack surface. I'd love if you could elaborate here, but links to documentation/technical articles are also welcome!
  - soraminazuki 2y ago
    The same suggestions have been made over and over. Here's one from a decade ago: https://ia801200.us.archive.org/1/items/SyScanArchiveInfocon/SyScan%202014%20Singapore/SyScan%202014%20presentations/SyScan2014_JoxeanKoret_BreakingAntivirusSoftware.pdf 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.
  - fuzzfactor 2y ago
    I'm not up-to-date on regulations (or many other things) but decreasing the attack surface in a way that could give a direct percentage improvement could get serious. 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.

From many of the comments I read, the reason is often regulation.

r0ks0n 2y ago

guess who's lobbying for that regulation

fuzzfactor 2y ago
Misguided regulations are more common than not, that's the real damaging kind. 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.

deleted 2y ago

[deleted]

jpgvm 2y ago

The regulation doesn't mandate these systems. 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.

ykonstant 2y ago
I am very interested in alternative ways of implementing controls to satisfy regulations; especially in ways that reduce, rather than increase, attack surface. I'd love if you could elaborate here, but links to documentation/technical articles are also welcome!
- soraminazuki 2y ago
  The same suggestions have been made over and over. Here's one from a decade ago: https://ia801200.us.archive.org/1/items/SyScanArchiveInfocon/SyScan%202014%20Singapore/SyScan%202014%20presentations/SyScan2014_JoxeanKoret_BreakingAntivirusSoftware.pdf 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.
- fuzzfactor 2y ago
  I'm not up-to-date on regulations (or many other things) but decreasing the attack surface in a way that could give a direct percentage improvement could get serious. 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.