Policy - 2

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?"

Furthermore, "Rules" enforcing the policies are fairly easy to modify to meet the needs
of an organization's various sub-entities (divisions, departments,
groups, etc.).

Defining "Policy"

One suggestion that came up repeatedly, resolves itself to: don't change anything. The argument is that there are so many different people with an ax to grind that consensus is
impossible. If we in identity management & IT business development side, try to seek a consensus definition, we won't succeed because no one else will accept our consensus. Thus we lose precision with no gain in understanding.

What we risk, of course, is that others will misunderstand what we mean, to our detriment. To avoid that we would need to define the term almost every time we use it, especially to those outside the identity management discipline - those who more and more are making the identity management decisions.

While the premise, getting everyone to agree on a definition, is most likely true, that is not surely the conclusion, concluding to that we stick to our own definitions, is the best answer. The IETF's RFC 3198, "Terminology for Policy-Based Management": This RFC was co-authored by John Strassner, formerly of Cisco, who almost single-handedly created what became known as Directory-Enabled Networking (DEN). More than a chapter was devoted to DEN's policy model. This all led to the need for a vocabulary, a terminology, a taxonomy for discussing policy. The RFC was the natural outcome of this need. One of the terms the RFC defines is, of course, "policy." This is what it says:

"Policy" can be defined from two perspectives:

- A definite goal, course or method of action to guide and
determine present and future decisions. 'Policies' are
implemented or executed within a particular context (such as
policies defined within a business unit).

- Policies as a set of rules to administer, manage, and control access to network resources [RFC3060].

Note that these two views are not contradictory since individual rules may be defined in support of business goals." The reference to "RFC3060" is to a document (also co-authored by Strassner) describing an object-oriented information model for representing policy information. John spent a long time at Cisco, and we can see that his thinking in terms of "policy" was heavily influenced by the security usage of that word he encountered at the network hardware company. Still, the second definition, "Policies as a set of rules," ties in neatly with another very good response.

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.In Dan's words:

" 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. AHD4th 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.'

AHD4th 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 'BRP'), 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. "

***************************************************************
sourced & adapted from the NETWORK WORLD NEWSLETTER
(IdentityManagement@nwfnews.com).

A few time paradoxes...

One stubborn problem with time travel is that it is riddled with several types of paradoxes.Can you understand the following...

There is the paradox of the man with no parents: What happens when you go back in time and kill your parents before you are born? If your parents died before you were born, then how could you have been born to kill them in the first place?

There is this another paradox of the man with no past. For example, let's say that a young inventor is trying futilely to build a time machine in his garage. Suddenly, an elderly man appears from nowhere and gives the youth the secret of building a time machine. The young man then becomes enormously rich playing the stock market, race tracks, and sporting events because he knows the future. Then, as an old man, he decides to make his final trip back to the past and give the secret of time travel to his youthful self. Where did the idea of the time machine come from?

There is also the paradox of the man who is his own mother. “Jane” is left at an orphanage as a foundling. When “Jane” is a teenager, she falls in love with a drifter, who abandons her but leaves her pregnant. Then disaster strikes. She almost dies giving birth to a baby girl, who is then mysteriously kidnapped. The doctors find that Jane is bleeding badly, but, oddly enough, has both sex organs. So, to save her life, the doctors convert “Jane” to “Jim.”. Then, “Jim” subsequently becomes a roaring drunk, until he meets a friendly bartender (actually a time traveler in disguise) who wisks “Jim” way back into the past. “Jim” meets a beautiful teenage girl, then accidentally gets her pregnant with a baby girl. Out of guilt, he kidnaps the baby girl and drops her off at the orphanage. Later, “Jim” joins the time travelers corps, leads a distinguished life, and has one last dream: to disguise himself as a bartender to meet a certain drunk named “Jim” in the past. So, who is “Jane’s” mother, father, brother, sister, grandfather, grandmother, and grandchild?

copied from... http://www.pbs.org/wnet/hawking/mysteries/html/kaku1-1.html

NDTV - Columns : North Block Spring

NDTV - Columns: "a fundamental fact of democracy. Public policy and economic decisions in any democracy are taken to drive home a political aim."

Networking.

The dream of an ubiquitous interconnected world...

To see the world in a grain of sand,
and heaven in a wild flower......
To hold infinity in the palm of your hand,
and eternity in an hour...