4 ms·

The regulation doesn't mandate these systems. The regulation requires controls, there are usually lots of ways of implementing those controls. However more of

by 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.
- stackskipton 2y ago
  I've done it, it's just drawing up documentation on why controls are satisfied another way and getting auditors to sign off on it. It's such a PITA and CISO live by not doing anything risky that few teams can get away with it.
est 2y ago
> The regulation requires controls lobbied by the same security company
misswaterfairy 2y ago
Essential Eight 'maturity levels' are vague in this regard, though seems to mandate it (at least 'application control'), at varying levels. 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/essential-cyber-security/essential-eight/essential-eight-maturity-model 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.
- stackskipton 2y ago
  >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.
deleted 2y ago
[deleted]

by jpgvm 2y ago

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.
stackskipton 2y ago
I've done it, it's just drawing up documentation on why controls are satisfied another way and getting auditors to sign off on it. It's such a PITA and CISO live by not doing anything risky that few teams can get away with it.

est 2y ago

> The regulation requires controls lobbied by the same security company

misswaterfairy 2y ago

Essential Eight 'maturity levels' are vague in this regard, though seems to mandate it (at least 'application control'), at varying levels. 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/essential-cyber-security/essential-eight/essential-eight-maturity-model 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.

stackskipton 2y ago
>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.

deleted 2y ago

[deleted]