Re-branding security "policy"

In my experience the concept of "policy" is a hard one for many developers to get their heads around, they don't immediately grok what "policy" is or what its supposed to do and it conjures up eastern european cold war regimes. Unfortunately policy is a central concept throughout information security. 

I have been thinking that we need another way to express the same concept to developers. What developers really interact with are Policy Enforcement Points, Policy Decision Points, and Policies. 

The Policy Enforcement Point has two responsibilities, one structural and one behavioral. The structural responsibility is to mediate communication between the subjects and objects. The behavioral responsibility is to collect the message exchanges and send them to the Policy Decision Point. I propose the term "Container" for these responsibilities.

The Policy Decision Point owns the workflow that renders the Y/N/DK policy decision, it uses the information that the Container sends it and may pull in dynamic data or other programs to make the decision. Some of the workflow is static and some dynamic. In some cases its a simple workflow, in other cases lots of nested logic. I think "Rules" or "Strategy" can illustrate this.

So if we take these two concepts the developer implements a container that makes access control decisions based on security rules and/or strategy combinations/permutations.

The other reason I think a re-branding is necessary is that "policy" sounds like a passive thing, in the responsibilities above you can see that the act of enforcing policy is quite active and dynamic.

Not sure if this is any better, but it seems better than policy. What do you think?

Comments

[Rob Lewis]

Do you think that there needs to be a distinction between business operational rules and IT security rules/policies? John Pescatore said on his blog that the disconnect between the two was the biggest problem in IT security; one that he thought would never be overcome. One might consider that the business rules deal with behaviors and IT policies deal with the structural.