Раздел: Документация

0 ... 3 4 5 6 7 8 9 ... 117

2 Security functional components

2.1 Overview

This clause defines the content and presentation ofthe functional requirements of ISO/IEC 15408, and provides guidance on the organisation of the requirements for new components to be included in an ST. The functional requirements are expressed in classes, families, and components.

2.1.1 Class structure

Figure 2.1 illustrates the functional class structure in diagrammatic form. Each functional class includes a class name, class introduction, and one or more functional families.

Functional Class

A

Key

B

C

ED

VA contains B plus a number of C

Class Name

Class Introduction

г	J-1
	Functional Families

Figure 2.1 - Functional class structure

2.1.1.1 Class name

The class name subclause provides information necessary to identify and categorise a functional class. Every functional class has a unique name. The categorical information consists of a short name of three characters. The shortname of the class is used in the specification of the short names of the families of that class.

2.1.1.2 Class introduction

The class introduction expresses the common intent or approach of those families to satisfy security objectives. The definition of functional classes does not reflect any formal taxonomy in the specification of the requirements.

---

The class introduction provides a figure describing the families in this class and the hierarchy of the components in each family, as explained in 2.2.

2.1.2 Family structure

Figure 2.2 illustrates the functional family structure in diagrammatic form.

Functional Family		Family name
		Family behaviour Component levelling Management Audit -, Components J

Figure 2.2 - Functional family structure

2.1.2.1Family name

The family name subclause provides categorical and descriptive information necessary to identify and categorise a functional family. Every functional family has a unique name. The categorical information consists of a short name of seven characters, with the first three identical to the short name of the class followed by an underscore and the short name of the family as follows XXX YYY. The unique short form of the family name provides the principal reference name for the components.

2.1.2.2Family behaviour

The family behaviour is the narrative description of the functional family stating its security objective and a general description of the functional requirements. These are described in greater detail below:

a)The security objectives of the family address a security problem that may be solved with the help of a TOE that incorporates a component of this family;

b)The description of the functional requirements summarises all the requirements that are included in the component(s). The description is aimed at authors of PPs, STs and functional packages who wish to assess whether the family is relevant to their specific requirements.

---

2.1.2.3Component levelling

Functional families contain one or more components, any one of which can be selected for inclusion in PPs, STs and functional packages. The goal of this section is to provide information to users in selecting an appropriate functional component once the family has been identified as being a necessary or useful part of their security requirements.

This section of the functional family description describes the components available, and their rationale. The exact details of the components are contained within each component.

The relationships between components within a functional family may or may not be hierarchical. A component is hierarchical to another if it offers more security.

As explained in 2.2 the descriptions of the families provide a graphical overview of the hierarchy of the components in a family.

2.1.2.4Management

The management requirements contain information for the PP/ST authors to consider as management activities for a given component. The management requirements are detailed in components of the management class (FMT).

A PP/ST author may select the indicated management requirements or may include other management requirements not listed. As such the information should be considered informative.

2.1.2.5Audit

The audit requirements contain auditable events for the PP/ST authors to select, if requirements from the class FAU, Security audit, are included in the PP/ST. These requirements include security relevant events in terms of the various levels of detail supported by the components of the FAUGEN Security audit data generation family. For example, an audit note might include actions that are in terms of: Minimal - successful use of the security mechanism; Basic - any use of the security mechanism as well as relevant information regarding the security attributes involved; Detailed - any configuration changes made to the mechanism, including the actual configuration values before and after the change.

It should be observed that the categorisation of auditable events is hierarchical. For example, when Basic Audit Generation is desired, all auditable events identified as being both Minimal and Basic should be included in the PP/ST through the use of the appropriate assignment operation, except when the higher level event simply provides more detail than the lower level event. When Detailed Audit Generation is desired, all identified auditable events (Minimal, Basic and Detailed) should

be included in the PP/ST.

In the class FAU the rules governing the audit are explained in more detail. 2.1.3 Component structure

Figure 2.3 illustrates the functional component structure.

0 ... 3 4 5 6 7 8 9 ... 117