Security is a confidence building exercise

Yesterday I was at a community event in Canberra, well, actually, it was in the middle of nowhere in New South Wales, but that's beside the point. One of the issues that came up there was how to sell security to senior management. Having struggled with this for a while I listened attentively as Peter Watson, Microsoft's Chief Security Advisor for Australia, explained his way of doing it. He uses the argument that security is what enables you to receive business value from the other IT investments you make.

Far be it from me to disagree with Peter, but it struck me that this argument could probably be taken a bit further. Isn't security really about building confidence in your IT? Obviously, security for the sake of security is something only those of us who work on security for a living could love. But what value does it provide to the rest of the world? I think it may be in the confidence it gives us in our infrastructure.

One way to think about it is with an analogy. Have you ever had a really bad car? One that could not be reliably trusted to actually get you to the destination you seeked, and certainly not back? Were you really looking forward to get into it? Of course not. You tried to avoid it at all costs. If you replaced it with a new car you finally got your confidence back and started making trips again.

IT is like that car, and security is the enabler that gives us confidence in it. Ideally you do not want to have to think about it, or have to notice that it is there, or worry about whether it is or not. You still have to have whatever it is that makes the car run reliably though. If you look at the four "pillars" of Microsoft's trustworthy computing initiative a recognition of this seems to actually be there, although obscurely stated: the real objective is to have reliable systems where our information stays private. Security is what enables that to happen. It is what we do to gain confidence in the reliability of our systems. It is what allows us to trust that those systems will be there, will function, and will do what we need them to do. Ideally, security would not get in the way in the process, and that gets us to the fundamental tradeoff I have talked about so often.

Do you agree? Having had the luxury to do security for the sake of security for so many years I am struggling a bit with how to sell it to people whose job it is to run our systems. If you have a great way to do that I'd like to hear about it.