Enterprise-Wide Security Architecture and Solutions Presentation Guide

2.3.1 System Integrity, Assurance and Trust

Figure 16. System Integrity, Assurance and Trust

Key Points

System integrity and assurance are the “cornerstone” for security in an

operating system.

Presentation Script

System Integrity:

While there are specific IBM definitions of system integrity

that differ for each system, in general terms, system integrity is the ability of an

operating system to prevent the circumvention or bypassing of its security

mechanisms. System integrity has been an important characteristic of IBM′s

MVS operating system since 1973 and of IBM′s VM operating system since 1983.

In 1990, IBM announced support for system integrity in OS/400.

System integrity adds strength to the base systems on which security facilities

are built. This strength can then be maintained by ensuring that

installation-added extensions (such as exits or other authorized programs)

support system integrity by implementing security controls (such as protection of

system libraries) that support integrity. In a system with system integrity,

application programs that run unauthorized should not be able to breach system

integrity.

32 Security P-Guide

System integrity is a basic component of the IBM Security Architecture. It is

IBM′s intent, as part of this strategy and architecture, to ensure that its products

provide a level of system integrity that supports the effectiveness of the other

architectural components.

Assurance:

Assurance in the context of formal government agency evaluation of

trusted systems, refers to specific criteria for assessing the effectiveness and

correctness of the vendor defined security functions.

In the context of this architecture document, security assurance for information

systems, encompasses a variety of areas, including physical security,

administrative security, system and application software security, and personnel

security. In principle, security assurance must be obtained in all of these areas.

However, from the point of view of this architecture, only administrative and

system/application software security measures that require system support will

be addressed.

Assurance is concerned with proving the ability of a (distributed) system to

provide for the following:

1. Establishing the identity of a distributed system component (such as

workstation, host, and so forth) that acts on behalf of users, clients, and

servers

2. Controlling the origin, type, integrity, and placement of system and

application software; not just that of hardware components

3. Identifying system services that are meant to support security policies, and:

•

Determining whether the specified security properties of these services

are indeed implemented and are effective

•

Protecting these services from unauthorized circumvention and

tampering by other non-security related services and applications

Properties of Trust:

The following statements define those conditions that must

exist for the term “trusted” to be of value when used in describing a system or

its attributes.

•

Trusted systems

A system is said to be trusted if assurance evidence exists which shows that:

− The security services and mechanisms are isolated from, and are

uncircumventable by, ordinary users and application programs.

− The security services effectively support the security policies and counter

the security threats or risks they are designed to address.

− The system is identified, content-controlled, and physically secure.

− The administrative personnel running the system have the required skills

to run the system in a secure manner, and have placed the interests of

the organization above their own.

•

Trusted functions, programs, processes or services

A function, program, process, or service is said to be trusted if assurance

evidence exists which shows that it effectively behaves in accordance with

its specifications. This may include evidence which shows that (1) the

security policy is sound; for example, the policy model is internally

consistent; and (2) the security function, program, process or service has

Chapter 2. IBM Security Strategy and Architecture 33

been specified, designed, implemented, verified, tested, and documented in

a cohesive and consistent manner.

•

Trusted privileged role

An authority is said to be trusted if all users allowed to run in that privileged

role have the skills and interests specified for that role and run only trusted

functions, programs, processes or services.

The relationship between trust and assurance implies that trust dependencies

exist among system components. These dependencies need to be identified in

providing a total solution, and indicate the need for trust analysis.

34 Security P-Guide