CC audit families allow PP/ST authors the ability to define requirements for monitoring user activities and, in some cases, detecting real, potential, or imminent violations of the TSP. The TOE's security audit functions are defined to help monitor security-relevant events, and act as a deterrent against security violations. The requirements of the audit families refer to functions that include audit data protection, record format, and event selection, as well as analysis tools, violation alarms, and real-time analysis. The audit trail should be presented in human-readable format either directly (e.g. storing the audit trail in human-readable format) or indirectly (e.g. using audit reduction tools), or both.
While developing the security audit requirements, the PP/ST author should take note of the inter-relationships among the audit families and components. The potential exists to specify a set of audit requirements that comply with the family/ component dependencies lists, while at the same time resulting in a deficient audit function (e.g. an audit function that requires all security relevant events to be audited but without the selectivity to control them on any reasonable basis such as individual user or object).
Audit requirements in a distributed environment:
The implementation of audit requirements for networks and other large systems may differ significantly from those needed for stand-alone systems. Larger, more complex and active systems require more thought concerning which audit data to collect and how this should be managed, due to lowered feasibility of interpreting (or even storing) what gets collected. The traditional notion of a time-sorted list or "trail" of audited events may not be applicable in a global asynchronous network with arbitrarily many events occurring at once.
Also, different hosts and servers on a distributed TOE may have differing naming policies and values. Symbolic names presentation for audit review may require a net-wide convention to avoid redundancies and "name clashes."
A multi-object audit repository, portions of which are accessible by a potentially wide variety of authorised users, may be required if audit repositories are to serve a useful function in distributed systems.
Finally, misuse of authority by authorised users should be addressed by systematically avoiding local storage of audit data pertaining to administrator actions.
Figure C.1 shows the decomposition of this class into its constituent components.
Figure C.1 - Security audit class decomposition
The Security audit automatic response family describes requirements for the handling of audit events. The requirement could include requirements for alarms or TSF action (automatic response). For example, the TSF could include the generation of real time alarms, termination of the offending process, disabling of a service, or disconnection or invalidation of a user account.
Application Notes
An audit event is defined to be an "potential security violation" if so indicated by the FAU_SAA components..
User application notes
An action should be taken for follow up action in the event of an alarm. This action can be to inform the authorised user, to present the authorised user with a set of possible containment actions, or to take corrective actions. The timing of the actions should be carefully considered by the PP/ST author.
Operations
Assignment:
In FAU_ARP.1.1 the PP/ST author should specify the actions to be taken in case of a potential security violation. An example of such a list is: "inform the authorised user, disable the subject that created the potential security violation." It can also specify that the action to be taken can be specified by an authorised user.
The Security audit data generation family includes requirements to specify the audit events that should be generated by the TSF for security-relevant events.
This family is presented in a manner that avoids a dependency on all components requiring audit support. Each component has an audit section developed in which the events to be audited for that functional area are listed. When the PP/ST author assembles the PP/ST, the items in the audit area are used to complete the variable in this component. Thus, the specification of what could be audited for a functional area is localised in that functional area.
The list of auditable events is entirely dependent on the other functional families within the PP/ST. Each family definition should therefore include a list of its family-specific auditable events. Each auditable event in the list of auditable events specified in the functional family should correspond to one of the levels of audit event generation specified in this family (i.e. minimal, basic, detailed). This provides the PP/ST author with information necessary to ensure that all appropriate auditable events are specified in the PP/ST. The following example shows how auditable events are to be specified in appropriate functional families:
"The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
a) Minimal: Successful use of the user security attribute administration functions;
b) Basic: All attempted uses of the user security attribute administration functions;
c) Basic: Identification of which user security attributes have been modified;
d) Detailed: With the exception of specific sensitive attribute data items (e.g. passwords, cryptographic keys), the new values of the attributes should be captured."
For each functional component that is chosen, the auditable events that are indicated in that component, at and below the level indicated in FAU_GEN should be auditable. If, for example, in the previous example `Basic' would be selected in FAU_GEN, the auditable events mentioned in a), b) and c) should be auditable.
Observe that the categorisation of auditable events is hierarchical. For example, when Basic Audit Generation is desired, all auditable events identified as being either Minimal or Basic, should also 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.
A PP/ST author may decide to include other auditable events beyond those required for a given audit level. For example, the PP/ST may claim only minimal audit capabilities while including most of the basic capabilities because the few excluded capabilities conflict with other PP/ST constraints (e.g. because they require the collection of unavailable data).
Application Notes
The functionality that creates the auditable event should be specified in the PP or ST as a functional requirement.
The following are examples of the types of the events that should be defined as auditable within each PP/ST functional component:
a) Introduction of objects within the TSC into a subject's address space;
b) Deletion of objects;
c) Distribution or revocation of access rights or capabilities;
d) Changes to subject or object security attributes;
e) Policy checks performed by the TSF as a result of a request by a subject;
f) The use of access rights to bypass a policy check;
g) Use of Identification and Authentication functions;
h) Actions taken by an operator, and/or authorised user (e.g. suppression of a TSF protection mechanism as human-readable labels);
i) Import/export of data from/to removable media (e.g. printed output, tapes, diskettes).
FAU_GEN.1 Audit data generation
User application notes
This component defines requirements to identify the auditable events for which audit records should be generated, and the information to be provided in the audit records.
FAU_GEN.1 by itself might be used when the TSP does not require that individual user identities be associated with audit events. This could be appropriate when the PP/ST also contains privacy requirements. If the user identity must be incorporated FAU_GEN.2 could be used in addition.
Evaluator application notes
There is a dependency on FPT_STM. If correctness of time is not an issue for this TOE, elimination of this dependency could be justified.
Operations
Selection:
For FAU_GEN.1.1b, the PP/ST author should select the level of auditable events called out in the audit section of other functional components included in the PP/ST. This level could be 'minimum', 'basic', 'detailed' or 'not specified'. If 'not specified' is selected, the PP/ ST author should fill in all desired auditable events in FAU_GEN.1.1c, and this part of the element (item b) can be removed entirely.
Assignment:
For FAU_GEN.1.1c, the PP/ST author should assign a list of other specifically defined auditable events to be included in the list of auditable events. These events could be auditable events of a functional requirement that are of higher audit level than requested in FAU_GEN.1.1b, as well as the events generated through the use of a specified Application Programming Interface (API).
For FAU_GEN.1.2b, the PP/ST author should assign, for each auditable events included in the PP/ST, a list of other audit relevant information to be included in audit event records.
FAU_GEN.2 User identity association
User application notes
This component addresses the requirement of accountability of auditable events at the level of individual user identity. This component should be used in addition to FAU_GEN.1 Audit data generation.
There is a potential conflict between the audit and privacy requirements. For audit purposes it may be desirable to know who performed an action. The user may want to keep his/her actions to himself/herself and not be identified by other persons (e.g. a site with job offers). Or it might be required in the Organisational Security Policy that the identity of the users must be protected. In those cases the objectives for audit and privacy might contradict each other. Therefore if this requirement is selected and privacy is important, inclusion of the component user pseudonimity might be considered. Requirements on determining the real user name based on its pseudonym are specified in the privacy class.
This family defines requirements for automated means that analyse system activity and audit data looking for possible or real security violations. This analysis may work in support of intrusion detection, or automatic response to an imminent security violation.
The action to be performed by the TSF on detection of a possible imminent or potential violation is defined in FAU_ARP Security audit automatic response components.
Application Notes
For real-time analysis, audit data could be transformed into a useful format for automated treatment, but into a different useful format for delivery to authorised users for review.
FAU_SAA.1 Potential violation analysis
User application notes
This component is used to specify the set of auditable events whose occurrence or accumulated occurrence held to indicate a potential violation of the TSP, and any rules to be used to perform the violation analysis.
Operations
Assignment:
For FAU_SAA.1.2.a, the PP/ST author should identify the subset of defined auditable events whose occurrence or accumulated occurrence need to be detected as an indication of a potential violation of the TSP.
Assignment:
In FAU_SAA.1.2.b, the PP/ST author should specify any other rules that the TSF should use in its analysis of the audit trail. Those rules could include specific requirements to express the needs for the events to occur in a certain period of time (e.g. period of the day, duration).
FAU_SAA.2 Profile based anomaly detection
A profile is a structure that characterises the behaviour of users and/or subjects; it represents how the users/subjects interact with the TSF in a variety of ways. Patterns of usage are established with respect to the various types of activity the users/subjects engage in (e.g. patterns in exceptions raised, patterns in resource utilisation (when, which, how), patterns in actions performed). The ways in which the various types of activity are recorded in the profile (e.g. resource measures, event counters, timers) are referred to as profile metrics.
Each profile represents the expected patterns of usage performed by members of the profile target group. This pattern may be based on past use (historical patterns) or on normal use for users of similar target groups (expected behaviour). A profile target group refers to one or more users who interact with the TSF. The activity of each member of the profile group is used by the analysis tool in establishing the usage patterns represented in the profile. The following are some examples of profile target groups:
a) Single user account: one profile per user;
b) Group ID or Group Account: one profile for all users who possess the same group ID or operate using the same group account;
c) Operating Role: one profile for all users sharing a given operating role;
d) System: one profile for all users of a system.
Each member of a profile target group is assigned an individual suspicion rating that represents how closely that member's new activity corresponds to the established patterns of usage represented in the group profile.
The sophistication of the anomaly detection tool will largely be determined by the number of target profile groups required by the PP/ST and the complexity of the required profile metrics.
This component is used to specify the set of auditable events whose occurrence or accumulated occurrence indicates a potential violation of the TSP, and any rules to be used to perform the violation analysis. This set of events or rules could be modified by the authorised user, through addition, modification or deletion of events or rules.
The PP/ST author should enumerate specifically what activity should be monitored and/or analysed by the TSF. The PP/ST author should also identify specifically what information pertaining to the activity is necessary to construct the usage profiles.
FAU_SAA.2 requires that the TSF maintain profiles of system usage. The word maintain implies that the anomaly detector is actively updating the usage profile based on new activity performed by the profile target members. It is important here that the metrics for representing user activity are defined by the PP/ST author. For example, there may be a thousand different actions an individual may be capable of performing, but the anomaly detector may choose to monitor a subset of that activity. Anomalous activity gets integrated into the profile just like non-anomalous activity (assuming the tool is monitoring those actions). Things that may have appeared anomalous four months ago, might over time become the norm (and vice-versa) as the user's work duties change. The TSF wouldn't be able to capture this notion if it filtered out anomalous activity from the profile updating algorithms.
Administrative notification should be provided such that the authorised user understands the significance of the suspicion rating.
The PP/ST author should define how to interpret suspicion ratings and the conditions under which anomalous activity is indicated to the FAU_ARP mechanism.
Operations
Assignment:
For FAU_SAA.2.1, the PP/ST author should specify the profile target group. A single PP/ST may include multiple profile target groups.
For FAU_SAA.2.3, the PP/ST author should specify conditions under which anomalous activity is reported by the TSF. Conditions may include the suspicion rating reaching a certain value, or be based on the type of anomalous activity observed.
FAU_SAA.3 Simple attack heuristics
User application notes
In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is imminent. However, there do exist some system events that are so significant that they are always worthy of independent review. Example of such events include the deletion of a key TSF security data file (e.g. the password file) or activity such as a remote user attempting to gain administrative privilege. These events are referred to as signature events in that their occurrence in isolation from the rest of the system activity are indicative of intrusive activity.
The complexity of a given tool will depend greatly on the assignments defined by the PP/ST author in identifying the base set of signature events.
The PP/ST author should enumerate specifically what events should be monitored by the TSF in order to perform the analysis. The PP/ST author should identify specifically what information pertaining to the event is necessary to determine if the event maps to a signature event.
Administrative notification should be provided such that the authorised user understands the significance of the event and the appropriate possible responses.
An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole input for monitoring system activity. This was done in recognition of the existence of previously developed intrusion detection tools that do not perform their analyses of system activity solely through the use of audit data (examples of other input data include network datagrams, resource/accounting data, or combinations of various system data).
The elements of FAU_SAA.3 do not require that the TSF implementing the immediate attack heuristics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion detection component that operates independently of the system whose system activity is being analysed.
Operations
Assignment:
For FAU_SAA.3.1, the PP/ST author should identify a base subset of system events whose occurrence, in isolation from all other system activity, may indicate a violation of the TSP. These include events that by themselves indicate a clear violation to the TSP, or whose occurrence is so significant that they warrant actions.
In FAU_SAA.3.2, the PP/ST author should specify the information used to determine system activity. This information is the input data used by the analysis tool to determine the system activity that has occurred on the TOE. This data may include audit data, combinations of audit data with other system data, or may consist of data other than the audit data. The PP/ST author should define precisely what system events and event attributes are being monitored within the input data.
FAU_SAA.4 Complex attack heuristics
User application notes
In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is imminent. However, there do exist some system events that are so significant they are always worthy of independent review. Example of such events include the deletion of a key TSF security data file (e.g. the password file) or activity such as a remote user attempting to gain administrative privilege. These events are referred to as signature events in that their occurrence in isolation from the rest of the system activity are indicative of intrusive activity. Event sequences are an ordered set of signature events that might indicate intrusive activity.
The complexity of a given tool will depend greatly on the assignments defined by the PP/ST author in identifying the base set of signature events and event sequences.
The PP/ST author should define a base set of signature events and event sequences to be represented by the TSF. Additional signature events and event sequences may be defined by the system developer.
The PP/ST author should enumerate specifically what events should be monitored by the TSF in order to perform the analysis. The PP/ST author should identify specifically what information pertaining to the event is necessary to determine if the event maps to a signature event.
Administrative notification should be provided such that the authorised user understands the significance of the event and the appropriate possible responses.
An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole input for monitoring system activity. This was done in recognition of the existence of previously developed intrusion detection tools that do not perform their analyses of system activity solely through the use of audit data (examples of other input data include network datagrams, resource/accounting data, or combinations of various system data). Levelling, therefore, requires the PP/ST author to specify the type of input data used to monitor system activity.
The elements of FAU_SAA.4 do not require that the TSF implementing the complex attack heuristics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion detection component that operates independently of the system whose system activity is being analysed.
Operations
Assignment:
For FAU_SAA.4.1, the PP/ST author should identify a base set of list of sequences of system events whose occurrence are representative of known penetration scenarios. These event sequences represent known penetration scenarios. Each event represented in the sequence should map to a monitored system event, such that as the system events are performed, they are bound (mapped) to the known penetration event sequences.
For FAU_SAA.4.1, the PP/ST author should identify a base subset of system events whose occurrence, in isolation from all other system activity, may indicate a violation of the TSP. These include events that by themselves indicate a clear violation to the TSP, or whose occurrence is so significant they warrant action.
In FAU_SAA.4.2, the PP/ST author should specify the information used to determine system activity. This information is the input data used by the analysis tool to determine the system activity that has occurred on the TOE. This data may include audit data, combinations of audit data with other system data, or may consist of data other than the audit data. The PP/ST author should define precisely what system events and event attributes are being monitored within the input data.
The Security audit review family defines requirements related to review of the audit information.
These functions should allow pre-storage or post-storage audit selection that includes, for example, the ability to selectively review:
- the actions of one or more users (e.g. identification, authentication, TOE entry, and access control actions);
- the actions performed on a specific object or TOE resource;
- all of a specified set of audited exceptions; or
- actions associated with a specific TSP attribute.
Application Notes
The distinction between audit reviews is based on functionality. Audit review (only) encompasses the ability to view audit data. Selectable review is more sophisticated, and requires the ability to perform searches based on a single criterion or multiple criteria with logical (i.e. and/or) relations, sort audit data, filter audit data, before audit data are reviewed.
User application notes
This component is used to specify that users and/or authorised users can read the audit records. These audit records will be provided in a manner appropriate to the user. There are different types of users (human users, machine users) that might have different needs.
The content of the audit records that can be viewed can be specified.
Operations
Assignment:
In FAU_SAR.1.1 the PP/ST author should specify the authorised users that can use this capability. If appropriate the PP/ST author may include security roles (see FMT_SMR.1 Security roles).
In FAU_SAR.1.1 the PP/ST author should specify the type of information the specified user is permitted to obtain from the audit records. Examples are "all", "subject identity", "all information belonging to audit records referencing this user".
FAU_SAR.2 Restricted audit review
User application notes
This component specifies that any users not identified in FAU_SAR.1 will not be able to read the audit records.
FAU_SAR.3 Selectable audit review
User application notes
This component is used to specify that it should be possible to perform selection of the audit data to be reviewed. If based on multiple criteria, those criteria should be related together with logical (i.e. `and' or `or') relations, and the tools should provide the ability to manipulate audit data (e.g. sort, filter).
Operations
Selection:
For FAU_SAR.3.1 the PP/ST author should select whether searches, sorting and/or ordering can be performed by the TSF.
Assignment:
For FAU_SAR.3.1, the PP/ST author should assign the criteria, possibly with logical relations, to be used to select the audit data for review. The logical relations are intended to specify whether the operation can be on an individual attribute or a collection of attributes. An example of this assignment could be: "application, user account and/or location". In this case the operation could be specified using any combination of the three attributes: application, user account and location.
The Security audit event selection family provides requirements related to the capabilities of identifying which of the possible auditable events are to be audited. The auditable events are defined in the FAU_GEN Security audit data generation family, but those events should be defined as being selectable in this component to be audited.
Application Notes
This family ensures that it is possible to keep the audit trail from becoming so large that it becomes useless, by defining the appropriate granularity of the selected security audit events.
User application notes
This component defines the criteria used for the selection of events to be audited. Those criteria could permit inclusion or exclusion of events from the set of auditable events, based on user attributes, subject attributes, objects attributes, or event types.
The existence of individual user identities is not assumed for this component. This allows for TOEs such as routers that may not support the notion of users.
For a distributed environment, the host identity could be used as a selection criteria for events to be audited.
The management function FMT_MTD.1 Management of TSF data will handle the rights of authorised users to query or modify the selections.
Operations
Selection:
For FAU_SEL.1.1a, the PP/ST author should select whether the security attributes upon which audit selectivity is based, is related to object identity, user identity, subject identity, host identity, or event type.
Assignment:
For FAU_SEL.1.1b, the PP/ST author should specify any additional attributes upon which audit selectivity is based.
The Security audit event storage family describes requirements for storing audit data for later use, including requirements controlling the loss of audit information due to system failure, attack and/or exhaustion of storage space.
FAU_STG.1 Protected audit trail storage
User application notes
In a distributed environment, as the location of the audit trail is in the TSC, but not necessarily co-located with the function generating the audit data, the PP/ST author could request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail.
The TSF will protect the audit trail from unauthorised deletion and modification. It is noted that in some systems the auditor (role) might not be authorised to delete the audit records for a certain period of time.
Operations
Selection:
In FAU_STG.1.2, the PP/ST author should specify whether the TSF shall prevent or only be able to detect modifications of the audit trail.
FAU_STG.2 Guarantees of audit data availability
User application notes
This component allows the PP/ST author to specify to which metrics the audit trail should conform.
In a distributed environment, as the location of the audit trail is in the TSC, but not necessarily co-located with the function generating the audit data, the PP/ST author could request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail.
Operations
Selection:
In FAU_STG.2.2, the PP/ST author should specify whether the TSF shall prevent or only be able to detect modifications of the audit trail.
In FAU_STG.2.3, the PP/ST author should specify the condition under which the TSF shall still be able to maintain a defined amount of audit data. This condition can be any one of the following: audit storage exhaustion, failure, attack.
Assignment:
In FAU_STG.2.3, the PP/ST author should specify the metric that the TSF must ensure with respect to the audit trail. This metric limits the data loss by enumerating the number of records that must be kept, or the time that records are guaranteed to be maintained. An example of the metric could be "100,000" indicating that 100,000 audit records can be stored.
FAU_STG.3 Action in case of possible audit data loss
User application notes
This component requires that actions will be taken when the audit trail exceeds certain pre-defined limits.
Operations
Assignment:
In FAU_STG.3.1, the PP/ST author should indicate the pre-defined limit. If the management functions indicate that this number might be changed by the authorised user, this value is the default value. The PP/ ST author might choose to let the authorised user define this limit. In that case the assignment can be for example "an authorised user set limit".
In FAU_STG.3.1, the PP/ST author should specify actions that should be taken in case of imminent audit storage failure indicated by exceeding the threshold. Actions might include informing an authorised user.
FAU_STG.4 Prevention of audit data loss
User application notes
This component specifies the behaviour of the TOE if the audit trail is full: either audit records are ignored, or the TOE is frozen such that no auditable events can take place. The requirement also states that no matter how the requirement is instantiated, the authorised user with specific rights to this effect, can continue to generate auditable events (actions). The reason is that otherwise the authorised user could not even reset the system. Consideration should be given to the choice of the action to be taken by the TSF in the case of audit storage exhaustion, as ignoring events, which provides better availability of the TOE, will also permit actions to be performed without being recorded and without the user being accountable.
Operations
Selection:
In FAU_STG.4.1, the PP/ST author should select whether the TSF shall ignore auditable actions, or whether it should prevent auditable actions from happening, or whether the oldest audit records should be overwritten when the TSF can no longer store audit records.
Assignment:
In FAU_STG.4.1, the PP/ST author should specify other actions that should be taken in case of audit storage failure, such as informing the authorised user.