This class provides three families that support the availability of required resources such as processing capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of capabilities caused by failure of the TOE. The family Priority of Service ensures that the resources will be allocated to the more important or time-critical tasks, and cannot be monopolised by lower priority tasks. The family Resource Allocation provides limits on the use of available resources, therefore preventing users from monopolising the resources.
Figure K.1 - Resource utilisation class decomposition
This family provides requirements for the availability of capabilities even in the case of failures. Examples of such failures are power failure, hardware failure, or software error. In case of these errors, if so specified, the TOE will maintain the specified capabilities. The PP/ST author could specify, for example, that a TOE used in a nuclear plant will continue the operation of the shut-down procedure in the case of power-failure or communication-failure.
User notes
Because the TOE can only continue its correct operation if the TSP is enforced, there is a requirement that the system must remain in a secure state after a failure. This capability is provided by FPT_FLS.1 Failure with preservation of secure state .
The mechanisms to provide fault tolerance could be active or passive. In case of an active mechanism, specific functions are in place that are activated in case the error occurs. For example, a fire alarm is an active mechanism: the TSF will detect the fire and can take action such as switching operation to a backup. In a passive scheme, the architecture of the TOE is capable of handling the error. For example, the use of a majority voting scheme with multiple processors is a passive solution; failure of one processor will not disrupt the operation of the TOE (although it needs to be detected to allow correction).
For this family, it does not matter whether the failure has been initiated accidentally (such as flooding or unplugging the wrong device) or intentionally (such as monopolising).
FRU_FLT.1 Degraded fault tolerance
User application notes
This component is intended to specify which capabilities the TOE will still provide after a failure of the system. Since it would be difficult to describe all specific failures, categories of failures may be specified. Examples of general failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, software failure, or buffer overflow.
Operations
Assignment:
In FRU_FLT.1.1 the PP/ST author should specify the list of TOE capabilities the TOE will maintain during and after a specified failure.
In FRU_FLT.1.1 the PP/ST author should specify the list of type of failures against which the TOE has to be explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation.
FRU_FLT.2 Limited fault tolerance
User application notes
This component is intended to specify against what type of failures the TOE must be resistant. Since it would be difficult to describe all specific failures, categories of failures may be specified. Examples of general failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, software failure, or overflow of buffer.
Operations
Assignment:
In FRU_FLT.2.1 the PP/ST author should specify the list of type of failures against which the TOE has to be explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation.
The requirements of this family allow the TSF to control the use of resources within the TSC by users and subjects such that high priority activities within the TSC will always be accomplished without interference or delay due to low priority activities. In other words, time critical tasks will not be delayed by tasks that are less time critical.
This family could be applicable to several types of resources, for example, processing capacity, and communication channel capacity.
The Priority of Service mechanism might be passive or active. In a passive Priority of Service system, the system will select the task with the highest priority when given a choice between two waiting applications. While using passive Priority of Service mechanisms, when a low priority task is running, it cannot be interrupted by a high priority task.While using an active Priority of Service mechanisms, lower priority tasks might be interrupted by new high priority tasks.
User notes
The audit requirement states that all reasons for rejection should be audited. It is left to the developer to argue that an operation is not rejected but delayed.
FRU_PRS.1 Limited priority of service
User application notes
This component defines priorities for a subject, and the resources for which this priority will be used. If a subject attempts to take action on a resource controlled by the Priority of Service requirements, the access and/or time of access will be dependent on the subject's priority, the priority of the currently acting subject, and the priority of the subjects still in the queue.
Operations
Assignment:
For FRU_PRS.1.2, the PP/ST author should specify the list of controlled resources for which the TSF enforces priority of service (e.g. resources such as processes, disk space, memory, bandwidth).
FRU_PRS.2 Full priority of service
User application notes
This component defines priorities for a subject. All shareable resources in the TSC will be subjected to the Priority of Service mechanism. If a subject attempts to take action on a shareable TSC resource, the access and/or time of access will be dependent on the subject's priority, the priority of the currently acting subject, and the priority of the subjects still in the queue.
The requirements of this family allow the TSF to control the use of resources within the TSC by users and subjects such that unauthorised denial of service will not take place by means of monopolisation of resources by other users or subjects.
User notes
Resource allocation rules allow the creation of quotas or other means of defining limits on the amount of resource space or time that may be allocated on behalf of a specific user or subjects. These rules may, for example:
- Provide for object quotas that constrain the number and/or size of objects a specific user may allocate.
- Control the allocation/deallocation of preassigned resource units where these units are under the control of the TSF.
In general, these functions will be implemented through the use of attributes assigned to users and resources.
The objective of these components is to ensure a certain amount of fairness among the users (e.g. a single user should not allocate all the available space) and subjects. Since resource allocation often goes beyond the lifespan of a subject (i.e. files often exist longer than the applications that generated them), and multiple instantiations of subjects by the same user should not negatively affect other users too much, the components allow that the allocation limits are related to the users. In some situations the resources are allocated by a subject (e.g. main memory or CPU cycles). In those instances the components allow that the resource allocation be on the level of subjects.
This family imposes requirements on resource allocation, not on the use of the resource itself. The audit requirements therefore, as stated, also apply to the allocation of the resource, not to the use of the resource.
User application notes
This component provides requirements for quota mechanisms that apply to only a specified set of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user, possibly assigned to groups of users or subjects as applicable to the TOE.
Operations
Assignment:
In FRU_RSA.1.1, the PP/ST author should specify the list of controlled resources for which maximum resource allocation limits are required (e.g. processes, disk space, memory, bandwidth). If all resources in the TSC need to be included, the words "all TSC resources" can be specified.
Selection:
In FRU_RSA.1.1, the PP/ST author should select whether the maximum quotas apply to individual users, to a defined group of users, or subjects or any combination of these.
In FRU_RSA.1.1, the PP/ST author should select whether the maximum quotas are applicable to any given time (simultaneously), or over a specific time interval.
FRU_RSA.2 Minimum and maximum quotas
User application notes
This component provides requirements for quota mechanisms that apply to a specified set of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user, or possibly assigned to groups of users as applicable to the TOE.
Operations
Assignment:
In FRU_RSA.2.1, the PP/ST author should specify the controlled resources for which maximum and minimum resource allocation limits are required (e.g. processes, disk space, memory, bandwidth). If all resources in the TSC need to be included, the words "all TSC resources" can be specified.
Selection:
In FRU_RSA.2.1, the PP/ST author should select whether the maximum quotas apply to individual users, to a defined group of users, or subjects or any combination of these.
In FRU_RSA.2.1, the PP/ST author should select whether the maximum quotas are applicable to any given time (simultaneously), or over a specific time interval.
Assignment:
In FRU_RSA.2.2, the PP/ST author should specify the controlled resources for which a minimum allocation limit needs to be set (e.g. processes, disk space, memory, bandwidth). If all resources in the TSC need to be included the words "all TSC resources" can be specified.
Selection:
In FRU_RSA.2.2, the PP/ST author should select whether the minimum quotas apply to individual users, to a defined group of users, or subjects or any combination of these.
In FRU_RSA.2.2, the PP/ST author should select whether the minimum quotas are applicable to any given time (simultaneously), or over a specific time interval.