PD-0167: Corrections to the General Purpose OS PP (GPOSPP), Version 1.0

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.

Effective Date:	2011-05-19
Last Modified	2011-05-20

Issue

Four additional issues have been identified with the U.S. Government Protection Profile for General-Purpose Operating Systems in a Networked Environment:

In FAU_GEN.1, there is an inconsistency between the requirements for minimal level of audit and Table 5.2. Specifically, the Protection Profile specifies the minimum level of audit and also specifies specific auditable events in Table 5.2. However, there are cases where Table 5.2 requires fewer events to be audited than required by the minimum level of audit. For example, in the case of FCS_CKM.1 for example the minimum level of audit requires the ability to audit "Success and failure of the activity", while Table 5.2 only requires the ability to audit the failure of the activity. It is unclear what is actually required to be audited in such a case.
FAU_SAR.1: The Protection Profile requires the TOE to provide a tool that is part of the TSF that provides audit records in a manner suitable for the authorized administrator to interpret the information. FAU_SAR.1 as defined in part 2 of the CC, only requires that there is possible methodology provided by the TSF to extract the audit records from the TSF protected audit trail in a way such that the target user is able to interpret the information. Since, in the CC terminology, another IT system is also a "user", a function within the TSF that allows extracting the audit records in some non human-readable form (e. g. in their binary representation) is acceptable as long as it is possible to interpret this data correctly on another system. In fielded systems, audit records are often exported 'as is' and the documentation provides the detailed information on the structure of the audit records; allowing them to be imported into a database with a record structure that completely matches the audit records; allowing the use of the database functions to search, and sort the audit records; and correlate them with audit records from other systems.

Additionally, the Protection Profile seems to require a function within the TSF that transforms the audit records into human readable format for review directly by an administrator. In today's operating environments this is not the way audit records are usually handled. The ability to export audit records such that they can be analyzed, consolidated, searched, and used to produce a useful report would not satisfy the SFR as stated in the Protection Profile. On the other hand, it is unlikely that a function that allows an administrator to view the audit records in ASCII format (which would satisfy the SFR in the Protection Profile) would be considered a "total solution" in practice.
FAU_SEL.1: The Protection Profile requires in FAU_SEL.1 the ability to include or exclude auditable events based on the 'host identity'. The term 'host' is not explained in the Protection Profile. CC part 2 uses this term for distributed TOE's, where the different parts of the TOE are labeled 'hosts'. It is unclear if the 'host identity' is unnecessary when the TOE is not distributed (since there is only one).
FIA_UAU.1 seems to allow also for non-password-based user authentication and does not, as a minimum, require password-based authentication. However, FIA_SOS.1 seems to address only passwords. It is unclear how these fit together. Is password-based authentication a mandatory authentication method? What about secrets, used for authentication, that are not passwords (e. g. private keys associated with a public key certificate)? What about a TOE that allows for password-based authentication, but restricts valid passwords to those that have at least one digit and one special character (thereby violating the requirement that password may consist of any combination of letters, numbers, and symbols)? Further, as stated in the Protection Profile, a TOE that allows a password that consists of 16 instances of the letter 'a' would be compliant, while a TOE that requires passwords to satisfy complex password rules that exclude specific trivial passwords would not.

Resolution

Each of these issues is resolved as follows:

In FAU_GEN.1.1, item e is refined as follows:

e) For other security relevant functions that are not included in this PP and SFRs not listed in Table 5.2, all auditable events for the minimal level of audit.
FAU_SAR.1 is refined as follows:

FAU_SAR.1.1 The TSF shall provide authorized administrators with the capability to read all audit information from the audit records.

Application Note: For a distributed system, the authorized administrator should be able to read all audit information within the TOE.

FAU_SAR.1.2 Refinement: The TSF shall provide the audit records in a manner suitable for the authorized administrator or a remote IT system to interpret the information. Audit records provided directly to the authorized administrator need to be in human readable form.

Application Note: There needs to be a method to review the audit records. This can either be done locally on the TOE or by a remote trusted IT system. In the first case, the TOE needs to supply a function that allows the authorized administrator to convert the audit records into human readable form. In the second case there needs to be a function that exports the audit records in a form that allows a remote trusted IT system to import those audit records and transform them to a human readable form. This implies that the format of the exported audit records is described with their syntax and semantics, allowing the development of a program on the remote trusted IT system that is able to completely and correctly process the audit records for display and analysis.
The following application note is added to FAU_SAR.1:

Application Note: Note that the 'host identity' is only required in the case where the TSF is distributed and therefore has more than one 'host'.
FIA_UAU.1.2 is refined as follows (new refinements are underlined):

FIA_UAU.1.2 Refinement: The TSF shall require each user to be successfully authenticated using a password-based authentication mechanism and [Assignment: other authentication mechanisms, "no other authentication mechanism"] (i.e., an exact match between the internal representation of the user's entered data and the stored TSF authentication data) before allowing any other TSF-mediated actions on behalf of that user.

Application Note: FIA_UAU.1.2 is designed for human users. If there is authentication for non-human-users, FIA_UAU.1 should be iterated and refined as appropriate.

FIA_SOS.1 is replaced with the following:

FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the following:

a) For password-based authentication, the following rules apply:

1. Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and special characters (that include: "!", "@", "#", "$", "%", "^", "&", "*", "(", and ")");

2. Minimum password length shall settable by the Security Administrator, and support passwords of 16 characters or greater;

3. Password composition rules specifying the types and numbers of required characters that comprise the password shall be settable by the Security Administrator.

Application Note: The intent of this caveat is that the Security Administrator is able to specify, for example, that passwords contain at least 1 upper case letter, 1 lower case letter, 1 numeric character, and 1 special character, and the TOE enforces this restriction. "Types" refers to all of the types listed in item 1 in this element.

4. Passwords shall have a maximum lifetime, configurable by the Security Administrator.

5. New passwords must contain a minimum of an administrator-specified number of character changes from the previous password.

6. Passwords must not be reused within the last administrator-settable number of passwords used by that user.

7. The default password configuration values must be congruent with the password configuration defined in the DOD 8500.2 IAIA-1 control or the NIST 800-53 IA-5(1) control, as completed by CNSSI 1253, that is current as of the start of the validation (i.e., [Assignment: Date]).

B) For non-password-based authentication, the following rules apply:

1. The probability that a secret can be obtained by an attacker during the lifetime of the secret is less than 2^-20.

Support

For items 1 through 3, the corrections are clarifications to capture the original intent. For item 4, the intent is that human users always have the password option, but other options are permitted. The original password rules were specified incorrectly, and so a modification of the rules based on that in the Network Device protection profile was used. The default value is based on the fact that this is a US Government Protection Profile; thus US Government Standards provide a reasonable default out-of-the-box stance.

Modification History:

2011-05-19:: PD Created. April 2011 Agenda Item 3.c.

References:

GPOSPP v0.7

Related NIs:

None

Related CCIMB-INTERPs:

None

Source OD: 0296