Secure Data Management in Decentralized Systems

2 Security Policy (p. 4)

The security policy elaborates on each of the three generic objectives of security- secrecy, integrity, and availability-in the context of a particular system. Thus, com- puter security policies are used like requirements, they are the starting point in the development of any system that has security features. The security policy of a system is the basis for the choice of its protection mechanisms and the techniques used to assure its enforcement of the security policy.

Existing security policies tend to focus only on the secrecy requirement of se- curity. Thus, these policies deal with defining what is authorized or, more simply, arriving at a satisfactory definition of the secrecy component. The choice of a security policy with reasonable consequences is nontrivial and a separate topic in its own right. In fact, security policies are investigated through formal mathematical models. These models have shown, among other things, that the consequences of arbitrary but relatively simple security policies are undecidable and that avoiding this undecidability is nontrivial [5,7,8]. To read more about the formal security models, see [3].

All security policies are stated in terms of objects and subjects. This is because in reasoning about security policies, we must be careful about the distinction between users and the processes that act on behalf of the users. Users are human beings that are recognized by the system as users with an unique identity. This is achieved via identification and authentication mechanisms, the familiar example is a user identi- fier and password.

All system resources are abstractly lumped together as objects and, thus, all ac- tivities within a system can be viewed as sequences of operations on objects. In the relational database context, an object may be a relation, a tuple within a relation, or an attribute value within a tuple. More generally, anything that holds data may be an object, such as memory, directories, interprocess messages, network packets, I10 devices, or physical media.

A subject is an abstraction of the active entities that perform computation in the system. Thus, only subjects can access or manipulate objects. In most cases, within the system a subject is usually a process, job, or task, operating on behalf of some user, although at a higher level of abstraction users may be viewed as subjects. A user can have several subjects running in the system on his or her behalf at the same time, but each subject is associated with only a single user. This requirement is important to ensure the accountability of actions in a system.

Although the subject-object paradigm makes a clear distinction between subjects and objects (subjects are active entities, while objects are passive entities), an entity could be both a subject and an object. The only requirement is that if an entity be- haves like a subject (respectively, object), it must abide by rules of the model that apply to subjects (respectively, objects).

Basic Security Concepts 5

The reason a distinction must be made between users and subjects is that while users are trusted not to deliberately leak information (they do not require a computer system to do so), subjects initiated by the users cannot be trusted to always abide by the security policy.