Lispian Random meanderings on whatever catches my fancy

Bemoaning the State of Information Security

I’ve been in the field of computer security for nearly 25 years and the same old stuff still bugs me. The constant desire to foist security requirements on the end-user is unbelievable, and unwarranted. Security is, at best, an esoteric field and one that most end-users are not sufficiently well versed in to be able to make logical decisions. Add to that the constant drone by security “experts” that much of the problems lie in lack of process and procedures, or user unwillingness to follow these same processes and procedures, is simply more proof that the problem lies elsewhere.

The problem with security is that it’s a pain in the ass. My security pedigree allows me to state that. I wrote the Canadian Criteria (CTCPEC). I was one of six authors, and the only non-US author, on the US Federal Criteria which was to replace the Orange Book and Rainbow Series. I co-authored the Common Criteria, and was one of the lone voices of dissent when it took on the form everyone is currently familiar with. As a senior IT security researcher with the Canadian government I set up the first virus centre to study the propagation of malware and worked closely with law enforcement and companies like Semantec. I helped design and deploy one of the first firewalls (we called it a trusted guard) back in 1987. I worked with Nortel to ensure Entrust became a viable entity. And I wrote numerous papers and sponsored countless security research and development efforts. I’m not putting this here to toot my own horn but to impress upon those reading this note that I know of what I speak. Security is worse today than it was ten or twenty years ago. More and more of the onus is on the end-user to do security tasks. The mechanisms in place are awkward and unnatural — Vista anyone? — especially when one considers how the vast majority utilize computers. This results in errors, omissions, and just poor practices. And the fault for all this lies squarely at the feet of the security architects and designers, and to a lesser extent the programmers, of security products. I’m sure there’s enough blame to go around to corporations unwilling to expend the capital to “Do it right”, as Mike Holmes would say, but that’s another issue. Professionally, designers and architects should take it upon themselves to ensure their products are done right as it will benefit their firms’ bottom lines when they don’t expend capital trying to deal with security flaws that could have easily been eliminated earlier on with a bit of thought.

A simple case in point: Secure e-mail. Why is it such a pain to use? Why must someone perform a multi-step process in order to ship a secure e-mail from one individual to another? Why can’t the system figure this all out for itself? There are tons of reasons offered, all of them wrong. You should just push the “Send” button and off the e-mail should go. Regardless of destination it should be adequately secured. The user shouldn’t have to do extra steps, be asked to “authenticate” again, or anything else. It should just go. Same holds for trusted documents. Why does the end-user have to do a song-and-dance? Make some logical assumptions and have the user change those if he or she feels the assumptions are wrong. Instead, it’s a constant barrage of questions which distract from the actually useful work the person is attempting to accomplish!

Now I can hear the PKI fanatics going on and on about non-repudiation and other nonsense. Let me explain something about the way computers work for you guys: non-repudiation doesn’t work with the current PKI systems. Last time I checked the computer has no way of knowing it’s me at the keyboard. I could have given my credentials, etc. to my secretary to ship out the e-mails! Oh, but I hear you scream, that’s a violoation of the “policy”. No, it’s not. What it is is how most of us do business. When a Major sends an e-mail to a General at the Pentagon, do you think the General reads his e-mail? Nope, he has a lieutenant read it for him and only point out those messages that are important. Does this break the standard PKI model? You betcha! Do I care? No. Does the General? Hell no! So why is the method of sending and receiving an e-mail designed to be so intrusive and difficult? Because some puritan believed this is how it should work and that we would all do it thusly. And, besides, it’s just easier to code. Wouldn’t want to inconvenience that poor programmer. He’s got to get back to his first-person shooter or WoW session.

The point is that the person who should be inconvenienced is the poor programmer and not the poor end-user. The end-user is the person that should be getting their job done, not worrying about security minutia. Alan Cooper, in The Inmates are Running the Asylum covers this topic most excellently, and I’ll cover this book in another post.

And what about this authenticating to the Certificate Authority? What bone-head thought that up? Let me get this straight: I can log into Windows NT/2k/XP/Vista/7, Linux, Mac OS X, what-have-you and access all of my files. But, if I should want to (God-forbid) read my e-mail or send any of those files to someone within my organization then I have to go through this special authentication that is somehow going to make things all the more secure. Pardon? How exactly? If I’m the recipient of a document I’ll stow it on my hard disk. Next time I want to get it, guess what, I just get it. No extra authentication, nothing. Now the purists will say that I should have to re-authenticate. To that I ask: why? What will it do other than aggravate me? Remember, I’m very security aware. I’ve coded security systems, designed them, architected huge networks and systems, wrote the countless criteria we evaluate all these secure systems to, etc. What will I gain through intrusive security? Nothing. If you want to protect the information, have the underlying file system authenticate that I’m still a valid user. If I’m not, lock the files away. But doing this in an obtrusive way is silly. So long as I’m in the same role, in the same organization security should just get out of my way. It should just work. Anything else ends up an aggravation!

For example, if I have files on the server, on my desktop, out in the cloud, wherever that I want to access then I should be shown them if and only if I can access them. If I’m in the same position then the policies the systems operate under should allow me to access them with no odd interventions on my part. If, however, I’ve changed positions, left the firm, whatever, then I should expect that I can no longer access some of that data. This isn’t rocket science, this is common sense. And it’s how most of us think. When we sell our house, we don’t expect to be able to get back in. Life doesn’t work that way. But while we’re in the house, how we get in is the same all the time. It doesn’t change from the user’s perspective, it just shouldn’t. Otherwise you screw with the flow.

In fact, security should only make itself aware when you do something wrong. Otherwise you should just be able to get your job done. If I want to send a message to myself at home, I just do it. The system can encrypt it authomagically for me. It isn’t hard to do. If I send it to someone else, auto-encrypt it for that person. Just always do the encrypted e-mail thing! Similarly in other cases, just add the security automatically. Don’t ask me, just strip it away before I see it if I’ve authenticated to the network. Make the security work for me as a user, not against me. Assume I’ll forget to do stuff so just always do it. Processing power is cheap. Networks are fast. There are no viable reasons not to; and no, WoW doesn’t qualify.

Another stupid security application is”digital signatures”. Now many of you are thinking how can I find anything wrong with digital signatures? Easy, they sign the wrong thing! Think about it, do we typically sign the envelope of the message or the actual contents! Obviously, you sign the actual contents which is usually sent as an attached document. Signing a document normally requires a separate step in real life and having a digital equivalent wouldn’t be weird at all! Think about it, when you print out a letter you physically sign it. Why not have a similar requirement for digital documents — i.e., a place you go to have it signed, or, more aptly, notarized. Then you drop that “notarized/signed” document into your e-mail envelope and mail it. Then that whole thing gets automatically encrypted and sent. If you don’t need to sign it, no need to go through the extra step. How many signed regular letters/documents does one send in a day? I for one don’t send many at all. And, if you want to notarize/sign everything you can automate that. But, in real life when you sign something that means you’ve actually read it and agree with what’s in it. If you automatically sign everything, then a virus or worm can send signed documents off to all your buddies. Not something you want with your name on it. In short, before we, as IT security experts, decide something is good, we should figure out what benefit it offers. The cost should not outweigh the benefit.

So what do I want? I want to log into my network and then have all the security just work. Security should be transparent. If I want some additional functionality I should request it because I know I need it, not have idiocies foisted upon me because some security geek thinkgs it’s a good idea. Otherwise, if I have to do some special steps to get my job done then, trust me, I won’t. Why? I’m lazy. It requires me to defocus from my actual work. I hate doing that and so I won’t. If I won’t, why should anyone else. Let’s put the security onus on the designers, architects, and programmers. Let’s give the poor end-user a break! Let’s make security as transparent as possible, part of the fabric itself. It shouldn’t be “in your face”. Yes, that makes it hard. But so what. Anything worth doing is probably hard, and why should making security that facilitates work flow be any different.

Comments are closed.

September 2010
« Aug   Oct »