PD-0134: Medium Robustness Traffic Filtering PP: Administrator accounts

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

The Medium Robustness Traffic Filtering PP defines three administrator roles, but doesn't seem to use them as defined.

The requirements of FAU_SEL.1.1-NIAP-0407, FMT_MOF.1.1(3), FAU_SAA.1.2-NIAP-0407, and FAU_ARP_ACK_EXP.1.1 all refer to Security Administrator (or simply "Administrator").

Given the description of the audit administrator in section 6.2 and the two-person control implied by the threat T.ROGUE_ADMIN, it seems that these should all instead refer to the "Audit Administrator".

Resolution

Section 2.6 ("Audit") of the Medium Robustness Traffic Filtering PP is changed to the following (changes, other than breaking into paragraphs, are shown as additions and deletions):

Section 5.1.1 "Security Audit (FAU)" describes the TOE's generation of auditable events, audit records, alarms and audit management. Table 3 in the FAU_GEN.1-NIAP-0410 requirement lists the minimum set of auditable events that must be available to the Security Administrator for configuration on the TOE. Each auditable event must generate an audit record. Table 3 also provides a minimum list of attributes that must be included in each audit record. The ST author may include additional auditable events and audit record attributes. If the ST author includes any additional functional requirements not specified by this PP, they must consider any security relevant events associated with those requirements and include them in the TOE's list of auditable events and records.

In addition to generating auditable events, the TOE must monitor their occurrences and provide a Security Administrator configurable threshold for determining a potential security violation. Once the TOE has detected a potential security violation, an alarm is generated and a message is displayed at the TOE's local console as well as each active remote administrator console (all administrative roles included). Additionally, the Security Administrator can configure the TOE to generate an audible alarm to indicate a potential security violation. If an administrator console is not active, the TOE stores the message for display when the console becomes active (e.g. when the administrator establishes a remote session to the TOE). The message must contain the potential security violation and all audit records associated with the potential security violation. The message will be displayed at the various consoles until administrator acknowledgement of the message has occurred.

As mentioned in the "Administrative" section above, the Audit Administrator's role is restricted to viewing the contents of the audit records, as well as backing-up and deleting audit data, and managing audit data storage and the deletion of the audit trail. The TOE does provide the Audit Administrator with a sorting and searching capability to improve audit analysis.

The Security Administrator configures auditable events, backs-up and deletes audit data, and manages audit data storage. The TOE provides the Security Administrator with a configurable audit trail threshold to track the storage capacity of the audit trail. As soon as the threshold is met, the TOE generates an alarm and displays a message in the same fashion as described above, including the option of the audible alarm. In addition to displaying the message, the Security Administrator may configure the TOE to prevent all auditable events except for those performed by the Security and Audit Administrators or overwrite the oldest audit records in the audit trail.

In the table in Section 6.1, the rational for mapping T.ADMIN_ROGUE to O.ADMIN_ROLE is changed to:

O.ADMIN_ROLE (FMT_SMR.2) mitigates this threat to a limited degree by limiting the functions available to an administrator. This is somewhat different than the part this objective plays in countering T.ADMIN_ERROR, in that this presumes that separate individuals will be assigned separate roles. If the Audit Cryptographic Administrator's intentions become malicious they would not be able to render the TOE unable to enforce its information flow policies. On the other hand, if the Security Administrator becomes malicious they could affect the information flow policy, but the Audit Administrator may be able to detect those actions.

Support

The PP author has been consulted and acknowledges that the wording does not convey the intent.

The confusion lies in the description of the Audit Administrator: the duties, privileges, and responsibilities of this role are far less than one would typically associate with an "administrator": it is a very basic operator role whose duties consist of little more than ensuring that there is sufficient storage space for audit records and looking at the audit records that are generated, as is summed up in Section 2.2 (Administration): "The Audit Administrator is responsible for the regular review of the TOE's audit data".

The wording of the PP does not clearly convey its intent in several places:

• Section 2.6 erroneously allocates backing up and deleting audit data, and managing audit data storage to the role of Security Administrator, when, in fact, it is the province of the Audit Administrator.

• The threat T.ADMIN_ROGUE was not intended to imply that the audit administrator is to act as a check on the actions of the security administrator. It was intended more as a separation of powers between the security administrator and the cryptographic administrator. This is why it is mapped only to FMT_SMR.

• The alarm requirements were intended to allow both SAs and audit administrators to be able to react to the alarms.

Modification History:

2007-05-22

Clarified the reference to "Table 6.1" to refer to the table in Section 6.1 [May 2007 ODRB Agenda Item 4.c.i]

2007-04-05

PD Created [February 2007 ODRB Agenda Item 3.a.iii; March 2007 ODRB Agenda Item 2.a.iii]

References:

• Traffic-Filter Firewall Protection Profile (PP) for Medium Robustness Environments

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0257