8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Раздел: Документация

0 ... 93 94 95 96 97 98 99 ... 117

H.5 Security attribute expiration (FMT SAE)

This family addresses the capability to enforce time limits for the validity of security attributes. This family can be applied to specify expiration requirements for access control attributes, identification and authentication attributes, certificates (key certificates such as ANSI X509 for example), audit attributes, etc.

FMTSAE.1 Time-limited authorisation

Operations

Assignment:

For FMTSAE.1.1, the PP/ST author should provide the list of security attributes for which expiration is to be supported. An example of such an attribute might be a users security clearance.

In FMTSAE.1.1 the PP/ST author should specify the roles that are allowed to modify the security attributes in the TSF. The possible roles are specified in FMTSMR.1.

For FMTSAE.1.2, the PP/ST author should provide a list of actions to be taken for each security attribute when it expires. An example might be that the users security clearance, when it expires, is set to the lowest allowable clearance on the TOE. If immediate revocation is desired by the PP/ST, the action "immediate revocation" should be specified.


H.6 Security management roles (FMT SMR)

This family reduces the likelihood of damage resulting from users abusing their authority by taking actions outside their assigned functional responsibilities. It also addresses the threat that inadequate mechanisms have been provided to securely administer the TSF.

This family requires that information be maintained to identify whether a user is authorised to use a particular security-relevant administrative function.

Some management actions can be performed by users, others only by designated people within the organisation. This family allows the definition of different roles, such as owner, auditor, administrator, daily-management.

The roles as used in this family are security related roles. Each role can encompass an extensive set of capabilities (e.g. root in UNIX), or can be a single right (e.g. right to read a single object such as the helpfile). This family defines the roles. The capabilities of the role are defined in FIAMOF, FMTMSA and FMTMTD.

Some type of roles might be mutually exclusive. For example the daily-management might be able to define and activate users, but might not be able to remove users (which is reserved for the administrator (role)). This class will allow policies such as two-person control to be specified.

FMT SMR.1 Security roles

This component specifies the different roles that the TSF should recognise. Often the system distinguishes between the owner of an entity, an administrator and other users.

Operations

Assignment:

In FMTSMR.1.1 the PP/ST author should specify the roles that are recognised by the system. These are the roles that users could occupy with respect to security. Examples are: owner, auditor and administrator.

FMT SMR.2 Restrictions on security roles

This component specifies the different roles that the TSF should recognise, and conditions on how those roles could be managed. Often the system distinguishes between the owner of an entity, an administrator and other users.

The conditions on those roles specify the interrelationship between the different roles, as well as restrictions on when the role can be assumed by a user.


Operations

Assignment:

In FMTSMR.2.1 the PP/ST author should specify the roles that are recognised by the system. These are the roles that users could occupy with respect to security. Examples are: owner, auditor, administrator.

In FMTSMR.2.3 the PP/ST author should specify the conditions that govern role assignment. Examples of these conditions are: "an account cannot have both the auditor and administrator role" or "a user with the assistant role must also have the owner role".

FMTSMR.3 Assuming roles

This component specifies that an explicit request must be given to assume the specific role. Operations

Assignment:

In FMTSMR.3.1 the PP/ST author should specify the roles that require an explicit request to be assumed. Examples are: auditor and administrator.



0 ... 93 94 95 96 97 98 99 ... 117