<3 Policy

Security Policies

Let us praise, slay, and bury security policies together.

A security policy is perhaps the best way to deal with the security monster. It concerns itself with business and organizational issues, and is designed to assist the organization succeed in spite of human nature.

I sometimes not-so-glibly say that a security policy is simply an expression of your desire. What do you want to see within your organization happen?

But ultimately a security policy is an information and resource filter.

It covers both the strategy and tactics of the implementation and design of your organization’s security posture.

And let me tell you (if I have to!), this is a lot of work. At least a book’s length of material covering everything about security in your organization. No one person could write it alone, and it needs to capture the business, spirit, and the culture of your organization… and when anything changes, it needs to change alongside of it as well. Exceptions alone could fill up a book. All of this is particularly tricky when dealing with rapidly moving technology and when companies merge or integrate with other organizations.

A reasonable way to measure security is simply how well a computer adheres to its security policies; assuming the policies are sound and up-to-date and a user, network, or computer complies with them you may meaningfully call them secure. It doesn’t mean that nothing bad could happen, it simply means that it’s doing what you want, and there is, at times, a large gulf between the two.

And while it is a little fascicle, you could claim that your security level is simply:

Security = (Policy – Non-Compliance) / 100

Audits, are, of course, vehicles to measure  compliance. And while there is a surfeit of

Not all computers, users, and resources are created equal, of course, and a policy must reflect the different roles that everyone plays within the organization. IT administrators are granted access to key resources where sales personnel are not, for instance. Servers providing key resources are usually locked down more than a sales person’s laptop. And so on.

When a device undergoes some fundamental or structural change in its role or usage its policy must change along with it as well.

And, of course, to create the right filters there are a number of steps that must be taken. In 1989 Fites et al wrote in “Control and Security of Computer Information Systems” that one should:

1. Identify what you are trying to protect.
2. Determine what you are trying to protect it from.
3. Determine how likely the threats are.
4. Implement measures which will protect your assets in a cost-effective manner.
5. Review the process continuously and make improvements each time a weakness is found.

These certainly sound common-sensical and might well be the overall strategy or battle plan to attack the security policy problem.

However, as Donald Knuth wrote in his Turing award acceptance speech that “science is knowledge which we understand so well that we can teach it to a computer; and if we don’t fully understand something, it is an art to deal with it.” He also was an advocate of something he called Literate Programming, where he talked of curling up by the fire on a cold winter eve and sitting down to read a program like one would read a book. It’d be delightful to think the same of a security policy, although I must confess the ones I typically see I’d prefer throwing into the first rather than curling up and warming my cockles* with.

We are a far ways from teaching computers how to deal with policies.

Perhaps I’m asking too much, or assuming too much difficulty. There are certainly a plethora of policy books, reference materials, and computer products with pre-canned policies, eager to get your hard earned dollars. Surely they’re not all selling snake oil?

Charles Cresson Woods is (was?) a well-known security policy pusher. On the web site that sells his book and CD (for $800), it said:

Struggling with information security policies? Relax. We’ve created the most complete set of leading practices available – so you don’t have to. Over 1350 policies ready for you to customize. Why reinvent the wheel when we have been perfecting it for years?

I would ask you a favor. If a salesperson, vendor, or security guru comes to you claiming that they can write the book on your security policies and practices, that they know your situation better than you… throw them out. Study such things, beg, borrow, or steal (just kidding) security policies and implementation ideas from your friends. But you need to do this yourself, as you are – like it or not – the expert.

A security policy is more than a book – it’s a blueprint, a foundation, a philosophy, a veritable virtual bible on which not only all your users must abide by, but from which all of your business units, processes, dealings with customers and 3rd parties… everything springs from. Allowing an outsider to set the tone of your organization’s fundamental business philosophy – for that’s what it is – would be tragic.

Writing a policy is something akin to being a prophet; you are translating the will of the higher powers to the ignorant masses. Embrace this.

Meta policies

One of the less talked about but more important aspects of policies are the statements that define the basic posture that should consistently permeate your policy documents. These are not so much individual mandates for particular areas as broad or global statements that should color all aspects of every security function throughout your organization(!) This is one of the most important components of your policy to widely disseminate.

First and foremost – what is your security posture? While you can slice and dice it a million ways, the basic question of whether you think that an allow all or deny all posture is more appropriate (and in which areas) is something that is surprisingly absent from the most people’s security policy lexicon. Not only does this bubble down to how to configure, say, firewalls, but when in-house developers are writing applications this should influence their overall design and architecture.

For instance, simply because the commodity traders on the floor can’t be interrupted in their business (or, at least, think they shouldn’t be) doesn’t mean that they shouldn’t adhere to transparent security terms and conditions. And because you allow such fluidity to the traders it doesn’t mean that their actions and computers shouldn’t be closely examined – indeed, the reverse is true. And most definitively it doesn’t mean that security controls should be removed.

It’s just these kinds of issues that should be emblazoned, in bold type, throughout your policy documents. What risks are you willing to take? How high do you want people to jump (and if it’s too high, you might consider a different vocation)? But really, how secure is enough? Is it CYA, industry standard, best practices, keep-out-of-newspapers, keep-your-job, or…?  I’m not here to preach – that’s your job. But security should never sacrifice clarity.

Policies as literature

Indeed, security policies could be considered their own art form, for at their best they’re an absolutely unique mix of highly technical writing alongside and mixed in with fluid prose.

Is it a stretch to say that writing a security policy is art? I don’t think so. Indeed, I would claim that there is a specific kind of art it closely resembles – or, rather, should resemble, and that is literature.

This starts to get at one of the more unusual aspects of polices – their layered construction. Layers – or abstractions, if you’d like – permeate the design, literature, and production of computers. Whether the 7 layers of the OSI networking model (applications to physical) or the virtual abstraction layers on computers that transport physical bits to physical screens, going from the physical media to bits, bytes, files, the running kernel, applications, etc. that lead us back to the physical world of peripherals and screens… to the political and business models within your organization, layers and abstractions abound.

Security policies have to deal with all these layers, and are ideally constructed in layers themselves, the higher layers designed for humans and the lower levels for computers.

By this I mean the highest layer of a policy should lay out the overall security strategy as well as laying out the basic defensive postures (more on that in a bit.) The lowest layers could be configuration files, pointers to programs, etc., and are what computers either directly consume or run to give you various functionalities.

[hypertext is well-suited for this. Look at knuth, other notes, etc.]

Come on, you might say. Sure, this is writing that should be read by people, but literature? Well, let’s consider some of the defining components of literature.

• Technically well written. Even (especially?) the oddball stuff (James Joyce and E. E. Cummings come to mind) are written by people with a real mastery of the language used.

• It can remind you of the best parts in life or show you those you never knew existed.

• Leaves a lasting impression.

• It teaches.

• It is a joy to read.

I claim that there is nothing about literature that you wouldn’t want to imbue into a security policy. Indeed, your audience is nearly identical as well – here is a group of well-educated people who love to read. And since it’s obvious that most people don’t understand security – here you get to entertain, teach, leave a lasting impression, and as a bonus you even get paid significantly more than other writers!

I think the long history of dry, dull, poorly written and unkempt security policies arises from where they come from. In the beginning it was mostly governmental employees and extraordinarily technical people who deeply understood computers. Neither set has a legacy of producing deathless prose. Furthermore I believe that this is a significant part of the problem with our ignorant user base – we treat them as second class citizens who waste our time doing idiotic things and further slap them in the face with poorly written policies that are probably ill-designed and out of date the minute they were written.

This is not easy stuff. Unique challenges are ahead, like putting a high-level look at biz issues and tech that transcends changes below.

It also means that, fundamentally, there must be different ways of expressing different notions and ideas. It requires teamwork, cooperation, and a steely eyed gaze to the future. And it takes a lot of different heads to put the thing together; surely when John Donne wrote “no woman is an island” he was expounding on security policies.

Plus, whenever a new medium of expression appears there is a burst of activity as people explore the possibilities. Here is your chance to be a pioneer as well as a good person.

Beauty & Quality

To be clear, I’m not simply talking about a literate and functional approach to writing policy. I’m actually referring, quite literally, to creating a beautiful, aesthetic piece of work that can be appreciated as real art; to use the framework of security policies and procedures as an art form. I believe that when a policy is constructed it can combine some of the wonderful elements of improvisational jazz along with literature and technology to product something that transcends function and provides a beautiful form as well.

There are books on style in language (e.g. The Elements of Style by Strunk & White), programming (e.g. Elements of Programming Style by Plauger & Kernighan), but nothing to my knowledge on style and elegance in writing security policies.

Certainly when critiquing art, or when attempting to recognizing quality great care should be taken. Zen and the Art of Motorcycle Maintenance is a remarkable, and remarkably odd book that makes some moves in this direction. On the surface it’s a tale of a father, son, and a motorcycle journey, but at the heart of it it takes the question of quality dead on, and, in doing so, of course, dooms itself to failure. At one point he says “quality is what you like”, and I think that security policies are the same. Unique, individual, and monumental in importance.

Many people seem to feel that if you follow certain rules and procedures; if you follow the rules of the game, then a quality piece of work will ensure. I think the important thing is the expression itself; if you are happy with the means and medium you’ve chosen and put perspiration and inspiration into it, the end result should be more than satisfactory. Anyone who has read a stultifyingly boring policy would at least appreciate the care and effort that you could put into it. And to those naysayers who believe that engineers or security mavens can’t create art, I’d point to Wallace Stevens, an executive for Hartford Accident and Indemnity, who created some of the greatest poems in the 20th century.

I couldn’t bear having a talk about art without some in it; here’s an extraordinary poem written by an extraordinary man, Wallace Stevens, who was an insurance executive by day, and exquisite writer by night.

October, 1921

The Snow Man

One must have a mind of winter
To regard the frost and the boughs
Of the pine-trees crusted with snow;

And have been cold a long time
To behold the junipers shagged with ice,
The spruces rough in the distant glitter

Of the January sun; and not to think
Of any misery in the sound of the wind,
In the sound of a few leaves,

Which is the sound of the land
Full of the same wind
That is blowing in the same bare place

For the listener, who listens in the snow,
And, nothing himself, beholds
Nothing that is not there and the nothing that is.

I’ve never read any of Wallace’s corporate writing, but I would think that he could all teach us a thing or two on how to communicate and coin a phrase both within and without the business world.  “One must have a mind of winter” – that’s simply transcendent.

I feel obliged to note that I’m not crying out for a resurgence… umm… perhaps there is no “re” in there… in poetry within security policies. As Christopher Alexander writes in A Pattern Language:

The difference between prose and poetry is not that different languages are used, but that the same language is used differently. In an ordinary English sentence, each word has one meaning, and the sentence too, has one simple meaning. In a poem, the meaning is far more dense. Each word carries several meanings; and the sentence as a whole carries an enormous density of interlocking meanings, which together illuminate the whole.

Dynamism today

I should note that any policy or strategy that doesn’t take the dynamic nature of computing and organizations today into account is going to be inherently flawed.

I’ll even go farther. I think questions like “how many computers are on the network” or “who is using the network”, or “are we secure” (ironic, that one, here, eh?), if asked in a traditional form, are nonsensical for any but absolutely trivial organizations. Not only do people not know how many computers they have, they certainly don’t know how many are on the network at any given time… and how do you account for a someone plugged into a conference room, or a contractor, or the cell phone user checking her email? M&A’s, reorganizations, the ebb and flow of employees, contractors, and third party folks create a living, breathing entity that one has to account for in the written policy, or you’re dead.

Doing a job well

Writing a good policy is hard. Creating something that will last, something that is meaningful, that transcends the medium, is very difficult.

I’ve always loved the word and the writing form of essay, which (as I understand it) comes from the French word essai, and as popularized by another brilliant writer, Michel Montaigne; it means something akin to effort, or trial. An essay has something of yourself imbued in it, and attempts to go beyond the norm, to create a sort of fusion of yourself and the topic at hand in an attempt to create something better than both.

There are reasons to try to rise above; pride, but not arrogance, in ones work. Making the world a better place when you’re gone. Making a name for yourself. Laying the foundations for others. But perhaps the best is teaching – giving back to the world after you’ve taken for a lifetime.

I recently went to Italy, and was struck by the Roman Coliseum – what an astonishing piece of work. Nearly 2000 years old, we’re still building stadiums in the same way, just not as well or with such permanence. Would you rather build Riverfront or the Coliseum? Perhaps if we approached security policies with this mindset we’d all benefit.

We need more. More training, schooling, writing about policies and not simply boilerplates for more of the same. We also need new labels for policy professionals. Policy architect, designer, specialists, engineers… I like the sound of a policy engineer!

No matter what, as security folks let’s hold our heads high, rise above, and usher in a new age, a golden age, of security policies.

 

* According to wikipedia.com, a cockle “is a small, edible, saltwater clam, a mollusc in the family Cardiidae.”
No one seems to really know where the phrase warming one’s cockles came from, although some theorize that they’re sort of heart shaped, like this fine specimen of cockletude.

 

 

 

References

[Fites 1989] M. Fites, P. Kratz, and A. Brebner, “Control and Security of Computer Information Systems”, Computer Science Press, 1989.

[IAB-RFC2196, 1997] Internet Activities Board, “Site Security Handbook”, RFC 2196, IAB, September 1997.

[Bernstein, 1998] Peter L Bernstein, “Against the Gods, The Remarkable Story of Risk”, 1998.

[Knuth, 1974] Donald E. Knuth, “Computer Programming as an Art”, Communications of the ACM, December 1974.

[Denning, 1992] Peter J. Denning, “What is Software Quality?”, Communications of the ACM, Jan 1992.

[Alexander, 1977] Christopher Alexander, et al, “A Pattern Language”, Oxford University Press, 1977.

Wallace Stevens, the Snowman:

Original text: Harmonium (New York: Alfred A. Knopf, [September 7], 1923): 24. York University Library Special Collections 734
First publication date: October 1921 
Publication date note: Poetry 19 (October 1921)