Зарубежные нормативные документы и критерии на английском / CCPART2V21

Annex H

(informative)

Security management (FMT)

1007

This class specifies the management of several aspects of the TSF: security

attributes, TSF data and functions in the TSF. The different management roles and

their interaction, such as separation of capability, can also be specified

1008

In an environment where the TOE is made up of multiple physically separated parts

that form a distributed system, the timing issues with respect to propagation of

security attributes, TSF data, and function modification become very complex,

especially if the information is required to be replicated across the parts of the TOE.

This should be considered when selecting components such as

August 1999

Version 2.1

Page 273 of 354

.

Security management

FMT_MOF Management of functions in TSF

1

1

FMT_MSA Management of security attributes

2

3

1

FMT_MTD Management of TSF data

2

3

FMT_REV Revocation

1

FMT_SAE Security attribute expiration

1

FMT_SMR Security management roles

1

2

3

Page 274 of 354

2.1

August 1999

Management of functions in TSF (FMT_MOF)

H - Security management (FMT)

H.1

Management of functions in TSF (FMT_MOF)

1009

The TSF management functions enable authorised users to set up and control the

secure operation of the TOE. These administrative functions typically fall into a

number of different categories:

1010

Note that these functions need to be present in a TOE based on the families included

in the PP or ST. It is the responsibility of the PP/ST author to ensure that adequate

functions will be provided to manage the system in a secure fashion.

1011

The TSF might contain functions that can be controlled by an administrator. For

example, the auditing functions could be switched off, the time synchronisation

could be switchable, and/or the authentication mechanism could be modifiable.

FMT_MOF.1 Management of security functions behaviour

1012

This component allows identified roles to manage the security functions of the TSF.

This might entail obtaining the current status of a security function, disabling or

August 1999

Version 2.1

Page 275 of 354

H - Security management (FMT)

Management of functions in TSF (FMT_MOF)

Operations

Selection:

1013

In FMT_MOF.1.1 the PP/ST author should select whether the role can

determine the behaviour of, disable, enable, and/or modify the

behaviour of the security functions.

Assignment:

1014

In FMT_MOF.1.1 the PP/ST author should specify the functions that

can be modified by the identified roles. Examples include auditing and

time determination.

1015

In FMT_MOF.1.1 the PP/ST author should specify the roles that are

allowed to modify the functions in the TSF. The possible roles are

specified in FMT_SMR.1.

Page 276 of 354

Version 2.1

August 1999

Management of security attributes (FMT_MSA)

H - Security management (FMT)

H.2

Management of security attributes (FMT_MSA)

1016

This family defines the requirements on the management of security attributes.

1017

Users, subjects and objects have associated security attributes that will affect the

behaviour of the TSF. Examples of such security attributes are the groups to which

a user belongs, the roles he/she might assume, the priority of a process (subject),

and the rights belonging to a role or a user. These security attributes might need to

be managed by the user, a subject or a specific authorised user (a user with explicitly

given rights for this management).

1018

It is noted that the right to assign rights to users is itself a security attribute and/or

potentially subject to management by FMT_MSA.1.

1019

FMT_MSA.2 can be used to ensure that any accepted combination of security

attributes is within a secure state. The definition of what “secure” means is left to

the TOE guidance and the TSP model. If the developer provided a clear definition

of the secure values and the reason why they should be considered secure, the

dependency from FMT_MSA.2 to ADV_SPM.1 can be argued away.

1020

In some instances subjects, objects or user accounts are created. If no explicit values

for the related security attributes are given, default values need to be used.

FMT_MSA.1 can be used to specify that these default values can be managed.

FMT_MSA.1 Management of security attributes

1021

This component allows users acting in certain roles to manage identified security

attributes. The users are assigned to a role within the component FMT_SMR.1.

1022

The default value of a parameter is the value the parameter takes when it is

instantiated without specifically assigned values. An initial value is provided during

the instantiation (creation) of a parameter, and overrides the default value.

Operations

Assignment:

1023

In FMT_MSA.1.1, the PP/ST author should list the access control SFP

or the information flow control SFP for which the security attributes

are applicable.

Selection:

1024

In FMT_MSA.1.1 the PP/ST author should specify the operations that

can be applied to the identified security attributes. The PP/ST author

can specify that the role can modify the default value (change_default),

query, modify the security attribute, delete the security attributes

entirely or define their own operation.

August 1999

Version 2.1

Page 277 of 354

H - Security management (FMT)

Management of security attributes (FMT_MSA)

Assignment:

1025

In FMT_MSA.1.1, if selected, the PP/ST author should specify which

other operations the role could perform. An example of such an

operation could be ‘create’.

1026

In FMT_MSA.1.1 the PP/ST author should specify the security

attributes that can be operated on by the identified roles. It is possible

for the PP/ST author to specify that the default value such as default

access-rights can be managed. Examples of these security attributes are

user-clearance, priority of service level, access control list, default

access rights.

1027

In FMT_MSA.1.1 the PP/ST author should specify the roles that are

allowed to operate on the security attributes. The possible roles are

specified in FMT_SMR.1.

1028

This component contains requirements on the values that can be assigned to

security attributes. The assigned values should be such that the TOE will remain in

a secure state.

1029

The definition of what ‘secure’ means is not answered in this component but is left

to the development of the TOE (specifically ADV_SPM.1 Informal TOE security

User application notes

1030

This component requires that the TSF provide default values for relevant object

security attributes, which can be overridden by an initial value. It may still be

possible for a new object to have different security attributes at creation, if a

mechanism exists to specify the permissions at time of creation.

Operations

Assignment:

1031

In FMT_MSA.3.1,the PP/ST author should list the access control SFP

or the information flow control SFP for which the security attributes

are applicable.

Selection:

1032

In FMT_MSA.3.1, the PP/ST author should select whether the default

property of the access control attribute will be restrictive, permissive,

or another property. In case of another property, the PP/ST author

should refine this to a specific property.

Page 278 of 354

Version 2.1

August 1999

Management of security attributes (FMT_MSA)

H - Security management (FMT)

Assignment:

1033

In FMT_MSA.3.2 the PP/ST author should specify the roles that are

allowed to modify the values of the security attributes. The possible

roles are specified in FMT_SMR.1.

August 1999

Version 2.1

Page 279 of 354

H - Security management (FMT)

Management of TSF data (FMT_MTD)

H.3

Management of TSF data (FMT_MTD)

1034

This component imposes requirements on the management of TSF data. Examples

of TSF data are the current time and the audit trail. So, for example, this family

allows the specification of whom can read, delete or create the audit trail.

FMT_MTD.1 Management of TSF data

1035

This component allows users with a certain role to manage values of TSF data. The

users are assigned to a role within the component FMT_SMR.1.

1036

The default value of a parameter is the values the parameter takes when it is

instantiated without specifically assigned values. An initial value is provided during

the instantiation (creation) of a parameter and overrides the default value.

Operations

Selection:

1037

In FMT_MTD.1.1 the PP/ST author should specify the operations that

can be applied to the identified TSF data. The PP/ST author can specify

that the role can modify the default value (change_default), clear, query

or modify the TSF data, or delete the TSF data entirely. If so desired

the PP/ST author could specify any type of operation. To clarify “clear

TSF data” means that the content of the TSF data is removed, but that

the entity itself remains in the system.

Assignment:

1038

In FMT_MTD.1.1, if selected, the PP/ST author should specify which

other operations the role could perform. An example could be ‘create’.

1039

In FMT_MTD.1.1 the PP/ST author should specify the TSF data that

can be operated on by the identified roles. It is possible for the PP/ST

author to specify that the default value can be managed.

1040

In FMT_MTD.1.1 the PP/ST author should specify the roles that are

allowed to operate on the TSF data. The possible roles are specified in

FMT_SMR.1.

FMT_MTD.2 Management of limits on TSF data

1041

This component specifies limits on TSF data, and actions to be taken if these limits

are exceeded. This component, for example, will allow limits on the size of the audit

trail to be defined, and specification of the actions to be taken when these limits are

exceeded.

Page 280 of 354

Version 2.1

August 1999

Management of TSF data (FMT_MTD)

H - Security management (FMT)

Operations

Assignment:

1042

In FMT_MTD.2.1 the PP/ST author should specify the TSF data that

can have limits, and the value of those limits. An example of such TSF

data is the number of users logged-in.

1043

In FMT_MTD.2.1 the PP/ST author should specify the roles that are

allowed to modify the limits on the TSF data and the actions to be taken.

The possible roles are specified in FMT_SMR.1.

1044

In FMT_MTD.2.2 the PP/ST author should specify the actions to be

taken if the specified limit on the specified TSF data is exceeded. An

example of such TSF action is that the authorised user is informed and

an audit record is generated.

FMT_MTD.3 Secure TSF data

1045

This component covers requirements on the values that can be assigned to TSF data.

The assigned values should be such that the TOE will remain in a secure state.

1046

The definition of what ‘secure’ means is not answered in this component but is left

to the development of the TOE (specifically ADV_SPM.1 Informal TOE security

policy model) and the resulting information in the guidance. If the developer

August 1999

Version 2.1

Page 281 of 354

H - Security management (FMT)

Revocation (FMT_REV)

H.4

Revocation (FMT_REV)

1047

This family addresses revocation of security attributes for a variety of entities

within a TOE.

FMT_REV.1 Revocation

1048

This component specifies requirements on the revocation of rights. It requires the

specification of the revocation rules. Examples are:

Operations

Selection:

1049

In FMT_REV.1.1, the PP/ST author should specify whether the ability

to revoke security attributes from users, subjects, objects, or any other

resources shall be provided by the TSF. If the last option is chosen, then

the PP/ST author should use the refinement operation to define the

resources.

Assignment:

1050

In FMT_REV.1.1 the PP/ST author should specify the roles that are

allowed to modify the functions in the TSF. The possible roles are

specified in FMT_SMR.1.

1051

In FMT_REV.1.2, the PP/ST author should specify the revocation

rules. Examples of these rules could include: “prior to the next

operation on the associated resource”, or “for all new subject

creations”.

Page 282 of 354

Version 2.1

August 1999