Mailbag: Use of the words ‘Policy’ and ‘Rules’, Part 2

As long as I keep hearing from you on the topic of defining “policy,” “rules,” “policy-based management” and “rule-based management” I’ll keep presenting your views. Today we’ll hear from two more correspondents.

First, Azi Cohen, CEO of Eurekify (http://www.eurekify.com) weighs in. Note that Eurekify’s catch phrase is “Enabling true role-based management.” In contrast (although in a different context) to what I quoted reader Jeff Davis as saying in the last issue, Cohen notes that policies are sometimes easier to formulate and modify than rules.

Jeff Davis, a director of product architecture at Safestone and our correspondent last issue, laid out a scheme where policies are paper-based and purposely difficult to change (the phrase “engraved in paper” comes to mind). Further, rules enforcing the policies are fairly easy to modify to meet the needs of an organization’s various sub-entities (divisions, departments, groups, etc.).

Cohen, though, brings up a counter-example. He notes: “In many identity management implementations we find out that while it is easy to set the de-facto policies (i.e. group X of employees that share the same access rights to group of resources Y) it is very difficult to set the deployment rule associated with the groups.”

This is especially prevalent, according to Cohen, in the fluid corporation – one that is involved in mergers, acquisitions, divestitures and reorganizations (that covers just about all of you, doesn’t it?). While the access rules for a particular group are easy to write initially, as others are added to or removed from the group, their attributes – the basis of the rules enforced – differ, sometimes markedly, from what the original deployment guidelines indicated.

Consul Risk Management Chief Technologist Kris Lovejoy evidently took the weekend off to pen a novelette for me. She started writing about “policies” but evidently, the document took on a life of its own to encompass “Information Security.” I’ll be referring back to this document periodically but for right now, we’ll look at what Lovejoy has to say about “policy.” It is interesting that the word “rule” doesn’t occur in her discussion at all.

She says: “According to Webster’s, a ‘Policy’ is ‘definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions’. Within the realm of information security, a policy sets the course: defining how confidentiality, integrity, and availability of information and technology assets can be achieved and maintained (example, Acceptable Use Policy).

“Again, according to Webster’s, a ‘Standard’ is something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality. Within the realm of Information Security, a standard is typically collections of system-specific or procedural-specific requirements that must be met by everyone (example: Windows 2000 Hardening Requirements).

“A ‘guideline’ is typically a collection of system specific or procedural specific ‘suggestions’ for best practice. They are not requirements to be met, but are strongly recommended (a.k.a., an optional standard).

“Generally, security policies refer to standards and guidelines existing within an organization. Of course, the ISO17799 Standard requires implementation of a policy – but who wants to split hairs?”

Policies, rules, standards, procedures, groups, roles – where does it end? Maybe, just maybe, in the next issue. Stay tuned!