PD 0134: Medium Robustness Traffic Filtering PP: Administrator accounts

["Observation Decisions Review Board" <faigin@aero.org>]

The following PD was developed and issued at the March 2007 ODRB Meeting. Any 
comments on this PD will be considered at the next ODRB meeting:

PD 0134: Medium Robustness Traffic Filtering PP: Administrator accounts

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): 

[Note: For posting purposes, *additions* and /deletions/. Underlining
and strikeout will be put in the HTML version] 

    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 Table 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. 

RATIONALE

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.