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.