Define ‘policy,’ Part 2

As we try to come up with a good definition for the term “policy,” I’d like to relate the thoughts of an expert on the issue.

Dan Beckett is a senior consultant with the Burton Group. He was previously the director of Dewpoint’s Security and Access Management Practice, and currently serves as adjunct professor at Michigan State University, where he authored the curriculum for and teaches a senior-level security architecture course for the university’s department of telecommunications.

Beckett – who has a degree in English in addition to his 17 years in the security, access and identity management fields – responded with a lengthy but thought-provoking answer to the question of defining “policy.” What follows are Dan’s words (his personal opinion, and not necessarily that of either the Burton Group or Michigan State).

* * *

In my opinion, the problem of clearly defining what we (IT pros) mean when we speak is largely a taxonomic issue, which has been exacerbated by the desire of software vendors to be buzzword-compliant. Let’s explore the taxonomy of ‘policy’ a little further, particularly as it applies to information security.

The American Heritage Dictionary of the English Language, Fourth Edition (AHD4th) defines policy as ‘A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous.’ Roget’s New Millennium Thesaurus, First Edition lists the following words as synonyms of policy (interestingly, there are no antonyms listed): action, administration, approach, arrangement, behavior, channels, code, course, custom, design, guideline, line, management, method, order, organization, plan, polity, practice, procedure, program, protocol, red tape, rule, scheme, stratagem, strategy, tenet, the book, the numbers, theory.

So, taxonomically speaking, ‘policy management protocol’ is actually thrice redundant. But for now, let’s bookmark these definitions and synonyms, and we’ll come back to them in a moment.

As I started thinking about the questions posed in your column, I immediately went back to the curriculum for a security architecture course I teach at Michigan State University. In the class, I postulate that the Security Lifecycle consists of seven critical steps that must be executed in a continuously iterating cycle: Plan, Policy, Procedure, Enforce, Manage, Detect, Assess.

Based on this commonly accepted definition of the Security Lifecycle, I think it is instructive to note that ‘Plan – Policy – Procedure – Enforce’ denotes a cascading relationship from least specific (Plan) to most specific (Enforce). Hence, I believe that ‘Policy’ is far too general of a term, and has historically (and erroneously) been used to denote the concept of ‘enforcement’ by software vendors. This probably all began when firewall vendors began describing ‘rules’ as ‘policies,’ and using those terms interchangeably, which brings me to my next point.

I don’t believe it is possible (nor is it desirable) to codify policies into executable code; accordingly, your proposed Protocol (in the technological sense of the word), should not reference ‘policy’ at all, because ‘policy’ is the wrong word for what we need; ‘enforce’ is what we’re really after. The taxonomic problem for defining a slick acronym is that ‘enforce’ is a verb, and what we need in our acronym is a noun. AMD4th defines enforce as ‘To compel observance of or obedience to’ – as in, enforce a law or rule. I think the proper word to use, then, is ‘rule,’ and more specifically for our context, ‘business rule.’

AMD4th defines rule as ‘An authoritative, prescribed direction for conduct, especially one of the regulations governing procedure in a legislative body or a regulation observed by the players in a game, sport, or contest.’ Note that this definition reinforces the idea that a rule is more specific than a procedure. The use of ‘prescribed’ in the definition of ‘rule’ is instructive as well. ‘Prescription’ is defined as ‘A formula directing the preparation of something.’ Prescriptions, formulas, or rules, are necessarily very specific, whereas policies are more general in nature (as in your example of the dress code policy). In our context, the ‘game’ or ‘contest’ is business. Therefore, ‘business rules’ are what we are really talking about.

Unfortunately, many identity management purists have the attitude that somehow identity management is different from the rest of the application development world, that it serves some higher purpose because of its security ramifications and universality. These purists tend to reject common application development taxonomy, such as ‘business rules,’ as if we need to develop an entirely new taxonomy to describe the uniqueness of identity management concepts. This attitude is misguided.

Identity management is really just an overall part of an enterprise’s application fabric; in fact, I’ve often argued that without applications, it’s like electricity without the light bulb. Identity management should be subject to the same taxonomies and practices that have been long established in application development communities. The enforcement of what we have traditionally called a ‘security policy’ within a security appliance, identity management application, or other related IT security infrastructure, is really nothing more than a ‘business rule’ that can be easily described, understood, and codified; up to this point, we simply haven’t had a standardized way of describing or codifying them.

So I suggest that we establish the ‘Business Rule Protocol’ (pronounced ‘bûrp’), and the ‘Extensible Business Rule Markup Language’ (pronounced ‘ex-bûr-mûl’). BRP would be used to describe interactions (both human and programmatic), and should sit on top of today’s communication protocols (HTTP/S, SOAP, etc.). XBRML would be used by developers to define the business rules, and to share those business rules across a loosely coupled, services-oriented architecture.

* * *

Well, as you can see, Dan pulls no punches and, in effect, is challenging the identity management community to change the way we talk, if not also the way we think. Can we do that? Can we “BuRP”? Send me your thoughts.