4 ms·

Real security is almost all technical and implementation. There's a very significant danger to security that policies be some kind of front line of defense, or

Real security is almost all technical and implementation. There's a very significant danger to security that policies be some kind of front line of defense, or be implemented over sound engineering practices. In almost every work environment, I've seen the policies working directly against security: if not by contradicting it, ignoring the details where the real security decisions live, or by striking the wrong balances between prescriptiveness and generality - then by out-prioritizing security decision making. (I've worked at mostly 100,000+ person companies). It's much better to have technical security controls >80-90% of the actual security. It's just expensive and harder to teach/learn/implement. That said, there's some real security gained by policy. It comes from: - Ability to communicate expectations ("adopt technical solution X") - Ability to exercise legitimized (instanciated/codified) authority Most of the rest of the value of policy comes in as business enablement value (policies are easier to communicate to auditors than security control implementations are). Policy can also be a useful placeholder for real security in the sense it will satisfy many external parties who might otherwise reprioritize/randomize security investments.

bdhess 8y ago
Policy is not a substitute for reasonable technical controls. But it’s also not a concern that can be wished away by saying “well we just do our security the real way, in code.” Any security control implementation enforces some conceptual policy, even if that policy isn’t documented elsewhere. In some places that’s fine; in others with more robust needs, that’s insufficient. Part of what auditors audit is that policy implementations (whether in code or in human practice) match the specification. As an example, I’m glad that browser vendors require CAs to document their policies for issuing certificates. Let’s Encrypt does a great job of making much of this process automatic, but there’s still pieces that must be done by humans, and there’s still written policies in place for all of their operations. At some point in any security process, human judgment comes into play. Striking the wrong balance between technical controls and allowing for human judgment can also lead to absurd outcomes, like this recent article/discussion[0]. [0] https://news.ycombinator.com/item?id=17350645 https://news.ycombinator.com/item?id=17350645
- notveryrational 8y ago
  Absolutely. If your system is doing "all the right security stuff" and then nobody knows about it - sure, you're secure - but nobody knows that or how you are secure. And that's a very significant problem both to a bureaucracy and to its customers. It's also an issue in terms of maintaining those controls over time between changes to staff and business direction. There's a whole "secondary market" (within an organization) for security assurance, and it tends to be much more measurable than security posture. Policies and summaries of those policies go a long way toward feeding that "assurance feeling" secondary market without draining resources from ongoing investments actual posture. Essentially the way it works is that you develop security controls toward an ideal end state/direction and describe your direction as your policy. Any gaps auditors or your company find then become fuel for making actual changes to the underlying security posture at a technical level. The danger of not having your policy really be disguised summaries of your actual implementation is that the various security staff become free to debate over fictional security and can convince themselves that if they mandate some changes on paper to the policy (with there being nothing technical associated whatsoever) that this has or should have some kind of real affect. It's more dangerous still if the internal security assurance program uses its own policies or some measure of "adherence to the policies" to then measure security. What happens is that the compliance operation becomes authoritarian about adherence to policies that don't exist outside of (otherwise non-discoverable) mandate, and the company and its auditors are able to "measure" their posture by their policies and convince themselves they are secure. The worst version of this is where its done on purpose for fraud.

bdhess 8y ago

Policy is not a substitute for reasonable technical controls. But it’s also not a concern that can be wished away by saying “well we just do our security the real way, in code.” Any security control implementation enforces some conceptual policy, even if that policy isn’t documented elsewhere. In some places that’s fine; in others with more robust needs, that’s insufficient. Part of what auditors audit is that policy implementations (whether in code or in human practice) match the specification. As an example, I’m glad that browser vendors require CAs to document their policies for issuing certificates. Let’s Encrypt does a great job of making much of this process automatic, but there’s still pieces that must be done by humans, and there’s still written policies in place for all of their operations. At some point in any security process, human judgment comes into play. Striking the wrong balance between technical controls and allowing for human judgment can also lead to absurd outcomes, like this recent article/discussion[0]. [0] https://news.ycombinator.com/item?id=17350645 https://news.ycombinator.com/item?id=17350645

notveryrational 8y ago
Absolutely. If your system is doing "all the right security stuff" and then nobody knows about it - sure, you're secure - but nobody knows that or how you are secure. And that's a very significant problem both to a bureaucracy and to its customers. It's also an issue in terms of maintaining those controls over time between changes to staff and business direction. There's a whole "secondary market" (within an organization) for security assurance, and it tends to be much more measurable than security posture. Policies and summaries of those policies go a long way toward feeding that "assurance feeling" secondary market without draining resources from ongoing investments actual posture. Essentially the way it works is that you develop security controls toward an ideal end state/direction and describe your direction as your policy. Any gaps auditors or your company find then become fuel for making actual changes to the underlying security posture at a technical level. The danger of not having your policy really be disguised summaries of your actual implementation is that the various security staff become free to debate over fictional security and can convince themselves that if they mandate some changes on paper to the policy (with there being nothing technical associated whatsoever) that this has or should have some kind of real affect. It's more dangerous still if the internal security assurance program uses its own policies or some measure of "adherence to the policies" to then measure security. What happens is that the compliance operation becomes authoritarian about adherence to policies that don't exist outside of (otherwise non-discoverable) mandate, and the company and its auditors are able to "measure" their posture by their policies and convince themselves they are secure. The worst version of this is where its done on purpose for fraud.