Financial Cryptography

The Goal of Security

Jeroen van Gelderen once made the remark that FreeBSD has a security goal, but OpenBSD has *the* security goal.

Coming from a goals oriented background - more about that later - I immediately understood and thought no more of it. Now I want to find out more, and ... it seems this is not a formal position of the open source operating systems, but more an informal shared understanding. Hence Jeroen's remark was even more perceptive, and I have no easy guidelines to copy from.

The Goal of Security is quite significant. As part of this both OSs have security officers. A security officer is often someone with quite significant power; to coordinate patches, but he or she can also hold back releases and effect inclusion or exclusion of packages. (Now, that might not sound all that significant in normal project management terms, but in the Internet world of open source, where rough consensus rules and most of the work is done by people who are unpaid, it's a big deal. It's recognition that when it comes to security, rough consensus might not be the only way to do things. And it's about the only override to that rough and ready world.)

As well as the security officer, there are also policy statements on how exploits are handled, and disclosure methods. Generally, in a Security Goal oriented project, anyone can report a security bug, and there are often easy ways to do it. If one has ever tried to report a bug through formal channels, one knows that having informal methods to report a bug is worth a lot.

There are also security subprojects within, such as code audits, module rewrites, and cross-divisional re-alignments. The importance of the security term underscores to all the disparate subprojects that this particular one might be directing requirements their way. This is another big change in the Open Source world - the database people don't listen to the GUI people, and the networks stack people don't listen to the email people ... but they all listen to the security people in a Security Goal project.

Expressing a goal is then an extraordinarily useful thing. It brings torturous mail list arguments back to a ground context. It identifies what we are all striving to achieve, and if we can't demonstrate how our argument moves towards the goal, then we aren't helping.

Yet, goals are almost a dirty word. It was great management speak back in the 80s and 90s, along with various other "must do" things like vision statements. They came, and they went, I haven't heard of anyone talking about a goal for years. One could say this means they didn't work, but I'd say that's unfair - goals are just hard to understand until you've lived them.

Rather than debug the failure of management-speak, let's go back to where they came from: the military, which is where I get my goal-oriented perspective from. There, for fighting soldiers, they are called objectives, and these things are taught to soldiers anywhere from corporal and above. Why the military? I guess because in the heat of the battle, it's easy to forget why you are there, and stressing something solid and basic has real value when the bullets are whizzing overhead.

The military has its own set of verbs. Soldiers redefine "to capture, to destroy, to kill..." so they can stress the objectively measurable event using their own language. When orders are given to troops, the mission - another word for today's goal - is the most important statement, and the leader reads it out twice. The leader reads the mission out twice! After the plans, soldiers are asked, "what's the mission?"

If they didn't do these things, soldiers would go out and do the wrong thing. Trust me on this, it's hard enough to direct soldiers with the help of solid goals, it is impossible without, and many a military campaign has founded through poor goals. Which leads us to their definition of the objective:

The objective is the one thing that if you have achieved it, you have done what you should have, and if you have not done it, then anything else that you might have done was in vain.

It's a tricky thing to define, and I'm going to skip that for now. But at some point, it settles into the mind, and one can be quite incisive. As long as the objective is set it is possible to measure any proposal against it, and thus we ground everything in the reality of our goal.

But to do this, the goal has to be stated. It has to be taught to soldiers who didn't finish grade school but can be taught to fire a rifle, and equally, it has to be stressed to people in complex projects built from opposing perspectives. When people from the crypto, legal, governance, computer science, finance, accounting, retail, charity, economics, government and who knows what other disciplines crowd into one contentious applications sphere such as the Internet, it feels to me like I didn't finish grade school, and the bullets are whizzing overhead.

But I know how to fire a rifle. I know how to do my bit, so ... what's the goal? What on this hellish earth is going to convince me to lift my head up and risk those bullets?

When it comes to security, I think it suffices for an OpenBSD-like project to state that Security is the Goal. Or, in the case of a more general purposes OS like FreeBSD, Security is a Goal, and others also are Goals, that we deliberately and explicitly need to juggle - with the important caveat that Security is the only Goal that can override the others.

It needs to be stated and it needs to be shared. Also needed are what we call Limitations on the Goal. These are important secondary statements that qualify the Goal. By way of example, here are some good ones:

As delivered out of the box. This means that we are concentrating on a deliverable that is secure on install; not one that needs tightening up by an expert, and even more importantly, we may even choose to make it harder for certain things where we can make it more secure 'out of the box'.

For the average user. Which means my Mom. Not the security expert, not the Internet techie, and not the corporate IT department.

Before you cry foul at those limitations, ponder them for a bit. I picked those because they happen to be the unstated Limitations on an unstated security goal for a particular project (Mozilla). Your project might reverse those limitations or pick others. But also note how they had a defining quality that locked your mind into a conflict.

When you feel that you are in conflict with the goal, and its limitations, that's when the goal is doing its job. Face the conflict - either bring your thoughts into alignment with the goal, or ask why the goal is as it is!

To summarise this long rant, I'd encourage anyone who has an interest in a security project to start thinking about explicitly setting the goal or goals. Making that work means stating it, initially. But it is in the follow through that the reward is found:

• state your limitations
• appoint your security officer or security director
• design the exploit procedure
• work out the disclosure policy
• get used to thinking in terms of "how does this help us meet the goal?"
• start the background projects needed to meet the goal in the future
• develop an open understanding of where you fall short of the goal!

And above all, share and document this process. When you've done this, you'll be able to establish the credibility of the project and the people in a very simple, objective and measurable statement:

Our Goal is Security.

Posted by iang at February 18, 2005 12:44 PM | TrackBack