Handbook of Information Security Management
(Publisher: CRC Press LLC)
Author(s): Hal Tipton and Micki Krause, Consulting Editors
ISBN: 0849399475
Publication Date: 01/01/98

Previous | Table of Contents | Next

Strongly Typed Data Objects

Strongly typed data objects assist in achieving the orderly and intended treatment of data while resisting any other use. The strongly typed data object is a special case in which both the type and the type manager are known to the environment. The environment provides protection to ensure that the type manager and its rules cannot be bypassed. The IBM AS/400 implements strongly typed objects. Currently, approximately three dozen object types have been defined.

Encapsulated Data Objects

The term “data object” is occasionally used in a more restricted sense. An encapsulated data object is a package containing data, its description, and a description of its manipulation. Because of the encapsulation, or data hiding, it is not possible to perform an arbitrary operation on these objects. For example, it is not possible to create an arbitrary copy of an encapsulated data object. The object must create the copy of itself and will do so only if that is consistent with its own rules. Because the capsule is a proper part of the object, a copy of the object is a separate object.

A local area network file server is both an instance and a paradigm for a data object: it is a capsule containing data, a description of the data, and the procedures for manipulating that data. Although, as with file servers, the capsule may be physical, the most general mechanism for achieving encapsulation is encryption.

Secure Data Objects

A secure data object is a special type of encapsulated data object. The rules about who is permitted what access to the data are included within the capsule. These rules are enforced in whatever environment is trusted to open the capsule. The capsule can be implemented in hardware or software (i.e., in secret codes). At the expense of performance or price, it can be made sufficiently strong for any application and environment.

The secure data object is the most general abstraction for enforcing information system security. It is independent of the media, the data, and the environment. The rules for using and changing the data move with the secure data object. It can be implemented so as to be independent of system or platform type. It may be used to implement seamless system-to-system access control in which the object is created in one system and its access rules move with it to other systems. Any system that can open the capsule may be relied on to enforce the access rules.

SUMMARY

This chapter surveys the field of computer science from a security, audit, and control perspective. It should be apparent from this discussion that most components and design decisions about a computer system will have some impact on the security, auditability, and control of the system and its applications.

Many of the requirements for security, audit, and control stem from the economics of computers and those steps that are taken to compensate for those economics. For example, in many computer environments, hardware or data is shared among a network of users. Hardware and data sharing expose the system to certain vulnerabilities, however, and mechanisms must therefore be in place to control the sharing. This chapter examines a generic set of vulnerabilities that are inherent in many computer systems.

In addition, this chapter reviews the control mechanisms, their origins, and their use. The emphasis is on primitive mechanisms and abstractions (e.g., storage). Because these primitive mechanisms have such broad influence, understanding them is essential to understanding how computers work and how they are secured. The discussion of these mechanisms is intended to provide a generalized and abstract view, a view that is broader than and independent of the existing implementations of those mechanisms. It is essential that security professionals be able to recognize, compare, and apply these mechanisms wherever they are found and without regard to specific implementations.

Previous | Table of Contents | Next