SFR enhancement proposals
SFR ad hoc subcommittee, P2600 WG
v1.2; 1/29/08

COMMENT #8 – FAU_GEN.1 and FAU_SAR.1

Problem: The relationship between audit requirement and recommendation tables and these SFRs is not clear.

Proposal: Clarify the relationship between the SFR and the audit requirement and recommendation tables:

Current

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:

¾  Start-up and shutdown of the audit functions;

¾  All auditable events for the [selection, choose one of: minimum, basic, detailed, not specified] level of audit; and

¾  [events listed in Table 15—PRT Audit data requirements”; assignment: other specifically defined auditable events].

PP APPLICATION NOTE— Table 16—PRT Audit data recommendations” lists additional auditable events that are recommended for consideration in FAU_GEN.1.1

FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:

¾  Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and

¾  For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [additional information listed in Table 15—PRT Audit data requirements”; assignment: other audit relevant information].

PP APPLICATION NOTE— Table 16—PRT Audit data recommendations” lists additional audit information that is recommended for consideration in FAU_GEN.1.2

FAU_SAR.1 Audit review

Hierarchical to: No other components.

Dependencies: FAU_GEN.1 Audit data generation

FAU_SAR.1.1 The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records.

FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information.

Proposed

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:

¾  Start-up and shutdown of the audit functions;

¾  All auditable events for the [selection, choose one of: minimum, basic, detailed, not specified] level of audit; and

¾  [assignment: all Auditable Events as each is defined for its Audit Level (if specified) for the Relevant SFR in “Table 15—PRT Audit data requirements”; [assignment: other specifically defined auditable events]].

PP APPLICATION NOTE— If the ST author specifies one of the CC-defined audit levels. (minimum, basic, or detailed), then there may be some redundancy among the CC-defined audit requirements and Table 15.

PP APPLICATION NOTE— “Table 16—PRT Audit data recommendations” lists additional auditable events that are recommended for consideration in addition to those that are required by FAU_GEN.1.1.

FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:

¾  Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and

¾  For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment: all Auditable Events as each is defined for its Audit Level (if specified) for the Relevant SFR and all Additional Information (if specified) in “Table 15—PRT Audit data requirements”; [assignment: other audit relevant information]].

PP APPLICATION NOTE— “Table 16—PRT Audit data recommendations” lists additional audit information that is recommended for consideration in addition to those that are required by FAU_GEN.1.2

FAU_SAR.1 Audit review

Hierarchical to: No other components.

Dependencies: FAU_GEN.1 Audit data generation

FAU_SAR.1.1 The TSF shall provide [assignment: authorised users] with the capability to read [assignment: all information generated in audit records as specified in FAU_GEN.2; list of audit information] from the audit records.

FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information.

Comment #9 – FAU_STG.1

Problem: “detect” option does not fulfill the O.AUDIT.LOGGED objective.

Proposal: complete the SFR by selecting only “prevent”.

Current

FAU_STG.1 Protected audit trail storage

Hierarchical to: No other components.

Dependencies: FAU_GEN.1 Audit data generation

FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.

FAU_STG.1.2 The TSF shall be able to [selection, choose one of: prevent, detect] unauthorised modifications to the stored audit records in the audit trail.

Proposed

FAU_STG.1 Protected audit trail storage

Hierarchical to: No other components.

Dependencies: FAU_GEN.1 Audit data generation

FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.

FAU_STG.1.2 The TSF shall be able to prevent unauthorised modifications to the stored audit records in the audit trail.

Comment #10 – FAU_STG.4

Problem: “ignore audited events” option does not fulfill the O.AUDIT.LOGGED objective.

Proposal: remove that option from the selection list.

Current

FAU_STG.4 Prevention of audit data loss

Hierarchical to: FAU_STG.3 Action in case of possible audit data loss

Dependencies: FAU_STG.1 Protected audit trail storage

FAU_STG.4.1 The TSF shall [selection, choose one of: “ignore audited events”, “prevent audited events, except those taken by the authorised user with special rights”, “overwrite the oldest stored audit records”] and [assignment: other actions to be taken in case of audit storage failure] if the audit trail is full.

Proposed

FAU_STG.4 Prevention of audit data loss

Hierarchical to: FAU_STG.3 Action in case of possible audit data loss

Dependencies: FAU_STG.1 Protected audit trail storage

FAU_STG.4.1 The TSF shall [selection, choose one of: “prevent audited events, except those taken by the authorised user with special rights”, “overwrite the oldest stored audit records”] and [assignment: other actions to be taken in case of audit storage failure] if the audit trail is full.

Comment #11 – FCS_CKM.1, FCS_CKM.4, and FCS_COP.1

Problem: Cryptographic standards are not specified

Proposal: add an application note to FCS_COP.1 that recommends ISO/IEC 18033-3:2005, but leave it up to the ST author so that national or other cryptographic standards can be specified. We don’t plan to make recommendations or specifications for FCS_CKM.1 or FCS_CKM.4 because these will vary according to product architecture.

Current

FCS_COP.1 Cryptographic operation

Hierarchical to: No other components.

Dependencies: [FDP_ITC.1 Import of user data without security attributes, or

FDP_ITC.2 Import of user data with security attributes, or

FCS_CKM.1 Cryptographic key generation]

FCS_CKM.4 Cryptographic key destruction

FCS_COP.1.1 The TSF shall perform encryption of D.DOC(+OTHERTOE).REST in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].

Proposed

FCS_COP.1 Cryptographic operation

Hierarchical to: No other components.

Dependencies: [FDP_ITC.1 Import of user data without security attributes, or

FDP_ITC.2 Import of user data with security attributes, or

FCS_CKM.1 Cryptographic key generation]

FCS_CKM.4 Cryptographic key destruction

FCS_COP.1.1 The TSF shall perform encryption of D.DOC(+OTHERTOE).REST in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].

PP APPLICATION NOTE— The ST author should consider specifying a relevant, internationally-recognized cryptographic standard such as ISO/IEC 18033-3:2005, or a national cryptographic standard that is appropriate for the intended market for their product, and then select appropriate algorithms and key sizes from that standard.

Comment #12 – FDP_ACC.1, FDP_ACF.1, FDP_IFC.1, FDP_IFF.1, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FTP_TRP.1

Problem: these SFRs are related to the TOE’s access control SFP and/or information flow control SFP, but from the current SFPs, it is not clear how the SFP should be implemented in each SFR. FIA SFRs do not (and probably should not) reference the I&A-related items in the access control SFPs because they are written in terms of actions that can be performed before identification and authorization (and, I&A rules probably should not appear in an access control SFP anyway).

Proposal: Remove I&A-related items from the access control SFPs. Expand and clarify all SFPs. Reference the SFPs (with matching nomenclature) in the SFRs. This will still require the ST author to complete the SFRs, but will give them enough guidance to do so.

Current (partial example of SFPs and some SFRs from PRT and SMI)

PRT Access Control SFP

Entity / Access control rule(s) /
U.ORIGINATOR / S.PRT requires identification and authentication.
S.PRT authorizes U.ORIGINATOR to bind with S.PRT to create a job and perform subsequent PRT job operations if granted permission to do so by U.ADMINISTRATOR.
U.DELEGATE / S.PRT requires identification and authentication.
S.PRT authorizes U.DELEGATE to bind with S.PRT to perform PRT job operations if granted permission to do so by U.ORIGINATOR or U.ADMINISTRATOR.
U.ADMINISTRATOR / S.PRT requires identification and authentication.
S.PRT authorizes U.ADMINISTRATOR to bind with S.PRT to perform PRT management operations if previously granted permission to do so by U.ADMINISTRATOR.
D.DOC.OUTPUT / S.PRT may delete or release to a Hardcopy Output Handler on behalf of U.ORIGINATOR or U.ADMINISTRATOR, and on behalf of U.DELEGATE if granted permission to do so by U.ORIGINATOR or U.ADMINISTRATOR.
D.FUNC.REST / S.PRT may read on behalf of any authorized User.
S.PRT may write on behalf of U.ADMINISTRATOR.
S.PRT may write on behalf of U.ORIGINATOR if data was created on behalf of U.ORIGINATOR.
S.PRT may write on behalf of U.DELEGATE if granted permission to do so by U.ADMINISTRATOR.
S.PRT may write on behalf of U.DELEGATE if granted permission to do so by U.ORIGINATOR and if data was created on behalf of U.ORIGINATOR.
D.PROT.REST / S.PRT may read on behalf of any authorized User.
S.PRT may write on behalf of U.ADMINISTRATOR.
S.PRT may write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.
D.CONF.REST / S.PRT may read or write on behalf of U.ADMINISTRATOR.
S.PRT may read or write on behalf of U.ORIGINATOR if data was created for U.ORIGINATOR.

SMI Information Flow Control SFP

Entity / Information flow control rule(s) /
D.DOC(+OTHERTOE)
.TRANSIT / S.SMI employs a trusted path for communication for this data between the Subject of another TOE and U.REMOTE.
D.FUNC(+OTHERTOE)
.TRANSIT / S.SMI employs a trusted path for communication for this data between the Subject of another TOE and U.REMOTE.
D.PROT(+OTHERTOE)
.TRANSIT / S.SMI employs a trusted path for communication for this data between the Subject of another TOE and U.REMOTE.
D.PROT.TRANSIT / S.SMI employs a trusted path for communication for this data
D.CONF(+OTHERTOE)
.TRANSIT / S.SMI employs a trusted path for communication for this data between the Subject of another TOE and U.REMOTE.
D.CONF.TRANSIT / S.SMI employs a trusted path for communication for this data
Shared-medium interfaces / S.SMI mediates the flow of information between shared-medium interfaces and the Subject of another TOE.
S.SMI mediates the flow of information between shared-medium interfaces and other interfaces on behalf of the Subject of another TOE.

FDP_ACC.1 Subset access control

Hierarchical to: No other components.

Dependencies: FDP_ACF.1 Security attribute based access control

FDP_ACC.1.1 The TSF shall enforce the PRT Access Control SFP on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP].

FDP_ACF.1 Security attribute based access control

Hierarchical to: No other components.

Dependencies: FDP_ACC.1 Subset access control

FMT_MSA.3 Static attribute initialisation

FDP_ACF.1.1 The TSF shall enforce the PRT Access Control SFP to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes].

FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects].

FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects].

FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].

FDP_IFC.1 Subset information flow control

Hierarchical to: No other components.

Dependencies: FDP_IFF.1 Simple security attributes

FDP_IFC.1.1 The TSF shall enforce the SMI Information Flow Control SFP on [assignment: list of subjects, information, and operations that cause controlled information to flow to and from controlled subjects covered by the SFP].

FDP_IFF.1 Simple security attributes

Hierarchical to: No other components.

Dependencies: FDP_IFC.1 Subset information flow control

FMT_MSA.3 Static attribute initialisation

FDP_IFF.1.1 The TSF shall enforce the SMI Information Flow Control SFP based on the following types of subject and information security attributes: [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes].

FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: for each operation, the security attribute-based relationship that must hold between subject and information security attributes].

FDP_IFF.1.3 The TSF shall enforce the [assignment: additional information flow control SFP rules].

FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows].

FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows].

FIA_UAU.1 Timing of authentication

Hierarchical to: No other components.

Dependencies: FIA_UID.1 Timing of identification

FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is authenticated.

FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.

FMT_MSA.1 Management of security attributes

Hierarchical to: No other components.

Dependencies: [FDP_ACC.1 Subset access control, or

FDP_IFC.1 Subset information flow control]

FMT_SMR.1 Security roles

FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1 The TSF shall enforce the PRT Access Control SFP to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].