3 ms·

In my experience, security policies often start short, readable, digestible, and actionable. Over time this changes as more and more people / groups add to them

In my experience, security policies often start short, readable, digestible, and actionable. Over time this changes as more and more people / groups add to them or edit them for specific purposes - engineering, privacy, HR.... New hires come in and make changes. Policies just evolve. To me, the worst culprit is audits. During an audit, there's this tendency to continually add to policies to bring them in line with the framework you're being audited against, or to bring them in line with what your auditor interprets as required by the framework. We used to host our policies on Github and you could clearly track our audit season by the revision frequency. In a week with an auditor, we'd have 10 or 50 or 100 revisions to policies. Over time, what you end up with is a Frankenstein set of documents that are not short, readable, digestible, or actionable. But they helped you pass your audits. This is not how it should be done but this is the reality I've seen. At my last company, we wrote and open sourced policies that many people used to pass audits - https://github.com/globerhofer/HIPAA-policies https://github.com/globerhofer/HIPAA-policies. I don't know if much of the policies were relevant to sec ops for those companies but the purpose a lot of the time was the audit.

faeriechangling 4y ago
I really get mad at peoples bias towards adding more “to be safe”. More security policies, more restrictions, more alerts, more process, more everything. The very fact that many audits apparently exist to ensure you have a shit security policy by bloating it with nonsense and crap is ridiculous. It’s all insanity. A classic example is password reset policies, a rule that makes security worse by burdening its users in ways that predictably and reliably make them use the lazy way to do things. In general you get good security by investing in it and hiring careful people, not by writing a list of 10000 rules and exclaiming “if only you followed rule 7354!” when something happens. Security policies seem to be designed like horoscopes, designed to address any possible variation of a security incident that might happen, rather than truly pointing you towards what’s important.
- NoPicklez 4y ago
  Security audits don't exist to ensure you have a shit security policy... I think it goes without saying that's untrue. If a particular standard or framework you need to meet requires these things there's unfortunately not much your auditor can do. As such, your problem is with the standard or framework you're aligning with not so much the auditor. If a security standard requires you to have a reset policy, then you should have free reign to design that how you see fit in the context of your organisation and its compensating controls.

faeriechangling 4y ago

I really get mad at peoples bias towards adding more “to be safe”. More security policies, more restrictions, more alerts, more process, more everything. The very fact that many audits apparently exist to ensure you have a shit security policy by bloating it with nonsense and crap is ridiculous. It’s all insanity. A classic example is password reset policies, a rule that makes security worse by burdening its users in ways that predictably and reliably make them use the lazy way to do things. In general you get good security by investing in it and hiring careful people, not by writing a list of 10000 rules and exclaiming “if only you followed rule 7354!” when something happens. Security policies seem to be designed like horoscopes, designed to address any possible variation of a security incident that might happen, rather than truly pointing you towards what’s important.

NoPicklez 4y ago
Security audits don't exist to ensure you have a shit security policy... I think it goes without saying that's untrue. If a particular standard or framework you need to meet requires these things there's unfortunately not much your auditor can do. As such, your problem is with the standard or framework you're aligning with not so much the auditor. If a security standard requires you to have a reset policy, then you should have free reign to design that how you see fit in the context of your organisation and its compensating controls.