Commercially Available Comprehensive Access Controls
Articles and Tips: tip
Senior Research Engineer
Security Development Manager
01 Dec 1998
If most people be-lieve that information can be secure on a network by discretionary means, or Discretionary Access Controls (DAC), there would be little to drive vendors toward producing solutions which would, in fact, provide security for the customers. Further muddying the waters is the perception held by many in the commercial arena that there is no difference between management and security. Today's commercially available access controls range from various file access permissions (such as read, write, modify, and delete) which can be found on just about any workstation, to servers which allow the utilization of Roles with Directory Services (like NDS), and even mainframe systems offer various management packages. Yet, in the broad sense, these controls are all too limiting and too difficult to administer.
Recognizing what is and what is not access control is a good place to start hacking away at the confusion surrounding security issues. Despite the attitude of most people involved in these areas, access control is not merely an assignment one makes when setting up a network. Discerning the difference between management and security is key to solving this access control complexity problem. For the purposes of security you must assume a hostile, motivated opponent--someone who wants very badly to gain access to your proprietary data. For management purposes, you assume effective unambiguous communication with someone who accepts your controls (but without turning your back on the possibility that even trusted persons can subvert your system). In management the activities are around applications; they may be activity specific, but harmony is expected. From the security perspective, someone is acting as opponent.
Furthermore—in the management scenario—network end-users are constantly producing information and data which they may variously store on their workstations or network servers. Yet, for security purposes, how do network administrators control and comprehend the totality of the end-users multiplied by the number of access controls? It is a question some people are starting to ask, especially with the possibilities presented with "open" networks.
From a management perspective, how do the existing heterogenous platforms and workstations allow for any cross boundary controls, as in the Internet? And, from a security perspective, what do those cross boundary communications mean? How does one control the information to keep certain sensitive information from getting into the pond and onto the other person's boat? While today's access controls allow network administrators to control the access of other users to the files stored on their network, how do those controls attribute to another's network?
The Internet Questions
Clearly, the safe administration of sensitive information from large organizations has become problematic with the connectivity of the Internet. How to administer so that companies can have assurance of information protection is the question. How to keep the sensitive, "mission critical" information—the information stored in electronic systems—from exposure to competitors across the "open" environment. The problem is that there are no readily available commercial solutions that provide reliable data security and data confidentiality. In fact, there is a certain amount of industry denial that problems really exists. Even organizations that do understand the exposure of their sensitive information have no commercial way of providing a secure environment for it.
Actually, there are and have been solutions for some time. On the solutions side of the equation, there are, in addition to the commercially available discretionary access controls (DAC), a group of non-discretionary access controls. They are called mandatory access controls (MAC) and they work to control the access of network administrators. They cannot be over-ridden, nor can they be applied to every subject on every machine.
What these non-discretionary controls represent is the difference between policy and mechanisms. From the point of access controls, then, these are the two things to discuss:
Who you will control in the environment (the subject)
What you will control through the environments (the objects)
Basic to our current technology mix of machines, programs, and computing are the people. Access controls are about people. There is the idea of controlling access via a program—where you put controls in the program instead of on the user. Yet, a program does not have the properties of a person; it is a mechanism. A program may have access to the collection of things in the domain, but a program does not contain any value other than the initial value of creation of the program. So you are back to the objects without the subject.
With objects in the domain, the program can get to them. The program acts on behalf of some user (the subject). So, in a domain the program is the surrogate for the user, and you need a mechanism for controlling what the surrogate can go and do. For instance, in a transactions environment, the program can "send the money," but how do you link that to the end-user who sent the money? Execution of the program must be with the rights and with the access controls of the user. Yet, some feel that the discretionary controls they have on their network systems are sufficient, and for a LAN, perhaps they are.
What of comprehensive access controls? Comprehensive access controls for a distinct environment could be like the controls for a LAN. However, a LAN is not a distributed network or Internet. Once you introduce "openness" to what is supposed to be an unambiguous communication, you immediately bump into the variations in policy which other systems maintain. Unfortunately or fortunately (depending on your perspective) the company's information security policy does not care if your system is mainframe or networked, 100 servers or 100 workstations; the policy should be the same. Clearly, access controls are about users. Comprehensive access controls are defined as controls one can use regardless of platform—mainframe, workstation, or network. As their name implies, these controls are comprehensive. Unfortunately, compared to the need, today's controls are too limiting.
What this means is that every box has its own set of controls. You can see this reflected in the working environment we now have. There have been efforts like IBM's Distributed Computing Environment (DCE) that allow for access controls for environment, but their different environments are in a uniform mechanism (and they accept any certificate as legitimate). In comparison to the Black Forest Group's 15-point Security Requirements document, IBM's configuration can be seen as similar to having a benevolent monopoly. Then the notion of a uniform mechanism would be something you actually could dream about. Unfortun-ately, monopolies are not considered benevolent and retrofitting systems to all be DCE compliant is more work than the Y2K problem.
Without an altruistic monopoly, one needs real access controls. As noted above, access controls can happen in two ways, discretionary and non-discretionary. By definition, there can be no other. It is clear that non-discretionary controls need to be both global (across systems) and persistent (available in the future). This means they have to go where the information goes.
In dealing with non-discretionary controls at the top level, there needs to be a common set of protocols, similar to the IP standard, which has standards-defined security fields. In discretionary controls, policies are based on individual users. This means that in comprehensive controls access, the directives are user-based. Directives allow the authentication of identity to be shared across multiple entities, which is one of today's major problems as well as on of its greatest needs. It is not that any one must agree up-front on the identity of the end-user, but that there must be a way to share a unique ID for each with a personal identifier. Take this away and you have a monopoly.
By doing it this way for a particular universe of discourse, you can use a shared identity (across systems) for at least one role. This does not subscribe to an idea of the single persona, as a user has multiple personae in the real universe, and the individual persona may have multiple roles.
The point for comprehensive controls is the very issue of comprehensive as it exists in the distributed network environment. Clearly, this can be difficult to manage and it can be limiting. However, one needs a safe administration, and that requires that one have some of the trusted elements mentioned in the previous points in this series of articles, as well as a trusted directory. Some will like the idea of certificates, which can help. However, let's not forget that easy administration is not obtained by a certificate for each and every action, while a trusted directory can significantly ease administration.
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.