4 ms·

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 re

by 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.

by bdhess 8y ago

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.