Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection program success depends more on prudent management decisions than on the selection of technical safeguards. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.
When I was in school I remember that some teacher pointed out the fundamental questions: who, what where, when, how, and why. These were the questions to be answered whenever we wanted to understand a situation. These were the questions we asked when we wanted to make a decision with a proper basis. These were the answers we demanded in order to do our job well.
Well, this weekend I was thinking through what we do to make access decisions in information protection and it occurred to me that we don't really ever ask one of these questions - the 'why' question. So I thought I would ask why it is that we don't ask why it is.
This article is my answer to that question.
We ask who all the time. That is the basis for most decisions today - identification and authentication. The identification is about who you are, and the authentication is about proving it.
Authentication is typically described as being associated with something you are, something you have, or something you know. I add something you can do to the mix, but this is probably a combination of the other things. The level of certainty we can apply depends on the technologies we use to reach that level of assurance, and assurance is generally inversely related to convenience and privacy.
Networks tend to weaken trust in who we are because of the increased number of intervening systems involved in the trust relationship. But perhaps more importantly, who we are is associated with your history of behavior, our title and position, and similar social issues that associated back to trust in some obscure way that we don't understand at a detailed level but operate with at a different level all the time.
What is asked a lot in computer systems. What are you asking to do or to access is typically associated with who you are for the decision to grant or deny that access or action. Who and what - subject and object - form the basis for much of our protection framework. Who wants to do what? If they are authorized, let it happen - otherwise stop it, report it, respond to it, and so forth.
One of the big problems with what is that there are so many whats that some who has to specify what what who can do what with for all whats and whos. For convenience, we can make groups of whos and whats so we can control which whats which whos can do what with for all groups of whos and whats. Any way you slice it that's a lot of stuff to do.
Groups of whos are associated with roles while groups of whats are associated with groups or ACLs, leading to ACLS or groups that are associated with roles, but in the end they are still just whos and whats. Controls for roles and groups are the same sorts of subject/object controls that have always existed for whos and whats.
Where is an under-used part of the process, but wheres have been around for a long time. The problem with networks is that wheres are getting harder to get at. Where can be somewhere else and look like it is where you want it to be because whos can use intermediate wheres to get to where they are going. Forged wheres are also common in the Internet.
If you can't tell where, there are some where things that can be told. For example, some wheres have characteristics that are remotely discernible. Things about where like time to respond and similar behavioral characteristics are good indicators but not as certain as we generally like in our authorization processes. Still we trust a lot of wheres based on the presence of whats that they contain - such as certificates and similar randomly generated coherent data.
Where goes both ways. If you are somewhere and you want to get to another where it's important that the where is where it should be, because otherwise the what is not what it should be. The trust in where is quite a scare because wheres all depend on whats except when we use something like location-based security which has whats that we need to depend on as well.
When has also been long used and is also under-used today. When used to be time of day, but with globalization, when changes with where, so we need where and when together to know of either. When is pretty good in the Internet - or at least it can be - typically within a millisecond of an atomic clock.
Network Time Protocol give an excellent when no matter where you are, but lying about the time is trivial in most systems today. I once said I would not use a computer that wouldn't give me the time of day, but now I seem to want more - like the time of day where I am and where it is - which often differ.
Which time we use for when is an important issues. And then there is relative time which depends on when what was before and when what else will be after. So whens and whats combine with wheres to make valid sequences of events. But trying to specify these valid sequences and differentiate then from invalid ones is even more complicated than limiting who and what can happen because the set of all possible whats and whens and their relations may be too complex to put into verbiage, and it is certainly beyond the realm of what my management skills bring to bear.
How is a relative newcomer to the process. Recent innovations have added how in the form of what to the controls on systems. In particular, the how is usually the what associated with a program combined with the who associated with the user, the what being dealt with, and the what that is being done to it. In combination these whos and whats provide insight as to how and if we can limit the whats of a program then the how is indeed controllable, unless the where is different in which case we don't know what is underway.
If this seems a bit complicated, don't worry, you will likely never have to manage it because the how is typically controlled by a who that knows how and specifies it to a mechanism that is out of your control. The typical mechanism is an execution or similar wrapper that limits what what can be run by who combined with an access control mechanism that controls what the what can do what to.
The person who implements the what controls the how by controlling the controls associated with linking whos and whats, while the person who controls the overall system controls which whos are allowed to do the what.
The big question that has not been asked very well so far is why. Why is particularly interesting because it is the predominant method used by people and yet it has never been used by computers, presumably either because nobody has thought of it or because we just don't know how to explain why to computers.
When you ask me if you can do something I usually ask why you ask and try to figure out if you can do what you want to do. If you can do it and the why is good enough then you will probably be allowed to do it. Sometimes why implies other questions like who, what, where, when, and how, and that's my point.
We have done a lot of things directed at these other things but the real issue we need to address and aren't yet addressing is why. Why is this you may ask? And well you should. By asking you are already no longer doing this, and thus it probably doesn't matter. The change has already come.
In this piece of work I have tried hard to use only the words that anyone can understand and yet in the end it looks like the entire thing is hard to understand. Which is to say that simple things can produce enormous confusion. And yet there is one thing I would like you to take away from this paper in addition to a new respect for how complicated simple things can be.
If you can read any of the paragraphs in this article without any confusion, you have probably been working too hard. But if you put this into your word processor and ask it to evaluate what it says, you will probably find that the word processor wants to change it to say something completely different. This likely could not have been written with the word processor that will be used to edit it and as a result, don't count on the result being what you think it is. Seek out the original to make sure.
A final note to the editors - to be left in the article of course. Don't bother to try to fix my grammar - because seemingly trivial syntactic changes can result in major semantic differences. If you find some of the items here confusing and impossible to uniquely parse, ask yourself why I did it that way and leave them alone - unless you check with me first.
About The Author:
Fred Cohen is helping clients meet their information protection needs at Fred Cohen & Associates and Security Posture and doing research and education as a Research Professor in the University of New Haven's Forensic Sciences Program. He can be reached by sending email to fred at all.net or visiting http://all.net/