Gregory's Server
@calamari I have a whole theory about how the development processes that SOC2, Fedramp, etc. all but mandate in order to survive an audit freeze the design of covered systems, often prematurely, and actively impede the evolved practices that might otherwise have improved their quality and reliability.
|
9 comments
 @donaldball @calamari "If you don't buy XYZ you'll surely fail your audit" is repeated across the industry as a truism but barely ever put to the test. @muvlon @donaldball @calamari "it tixs a box". As long as it easier to deploy a software which tix a box as to discuss with your auditor each and every year why you insist do do it by yourself we will see incidents like this today 🤷   The same lazy and incompetent mindset that means 90% of industry is on windows*. * Hampering the development of "effectively read-only stateless clients", for example. @muvlon @donaldball @calamari exactly. you can work with the regulatory entities & auditors, but you have to know what you do. This is far more about the companies doing the implementations than the compliance frameworks themselves. Companies will do the bare minimum to pass audit and then completely ignore the ongoing audits, assessments, and improvement cycles demanded by the compliance framework. With SOC2 you can get away with some of this, less so in FedRamp, and even less so in ISO but companies don't want to spend money to mitigate risks - all they want is tech magic they can ignore. @gaysteve @donaldball @calamari this sounds like the most accurate description to me. I’ve been through the SOC process a few times, I can see how companies want to take some mostly reasonable norms on what they’re supposed to audit and try to abstract it to a software package. I have always found the anti-malware norms both reasonable in principle and vexing in implementation myself. This is where invasive endpoint software shows up. @gaysteve @donaldball @calamari |
@donaldball @calamari I don't know SOC2 that well but I do work on critical infrastructure that is certified (with 0 findings!) to a similar German standard despite not using any of these scary products.
Yes you need to explain to your auditor how you intend to meet your security objectives despite not having bought the proprietary appliance that claims to magically make you do that. But you'll manage.