FAU_GEN.1-NIAP-0407:1 -- Audit data generation
FAU_GEN.2-NIAP-0410:1 -- User identity association
FAU_SAR.1 -- Audit review
FAU_SAR.2 -- Restricted audit review
FAU_SAR.3 -- Selectable audit review
FAU_SEL.1-NIAP-0407 -- Selective audit
FAU_STG.1-NIAP-0429 -- Protected audit trail storage
FAU_STG-NIAP-0429-1 -- Self-configurable prevention of audit data loss
FCS_CRM_FPS_(EXP).1 -- FIPS compliant cryptographic module
FDP_ACC.1 -- Subset access control
FDP_ACF.1-NIAP-0407 -- Security attribute based access control
FDP_RIP.2 -- Full residual information protection
FIA_AFL.1 -- Authentication failure handling
FIA_ATD.1 -- User attribute definition
FIA_UAU.2 -- User authentication before any action
FIA_UAU.7 -- Protected authentication feedback
FIA_UID.2 -- User identification before any action
FIA_USB.1 -- User-subject binding
FMT_MOF.1 -- Management of security function behavior
FMT_MSA.1 -- Management of security attributes
FMT_MSA.3 -- Static attribute initialization
FMT_MTD.1 -- Management of TOE Security Data
FMT_SMF.1 -- Specification of management functions
FMT_SMR.2 – Restrictions on security roles
FPT_RVM.1 -- Non-bypassability of the TSP
FPT_SEP.1 – TSF domain separation
FPT_SEP_ENV_(EXP).1 – Support for TSF domain separation
FPT_STM.1 -- Reliable time stamps.
FPT_TST_SOF_(EXP).1 -- TSF testing for Software only TOEs
FTA_SSL.1 -- TSF-initiated session locking
FTA_SSL.2 -- User-initiated locking
FTA_TAB.1 -- Default TOE access banner
Windows and Linux operating systems will provide audit data generation functionality. Operating system will generate audit records for the required audit events.
Required audit events:
Start-up and shutdown of the audit functions;
All auditable events listed in the table below
Requirement |
Auditable Events |
Additional Audit Record Contents |
FAU_SAR.1 |
Opening
the audit trail |
The
identity of the Audit Administrator performing the function |
FAU_SAR.2 |
Unsuccessful
attempts to read information from the audit records |
The
identity of the administrator performing the function |
FAU_SEL.1-NIAP-0407 |
All
modifications to the audit configuration that occur while the audit
collection functions are operating |
The
identity of the Security Administrator performing the function |
FDP_ACF.1-NIAP-0407 |
All
requests to perform an operation on an object covered by the SFP |
Object
identity |
FIA_AFL.1 |
Reaching of the threshold for the unsuccessful
authentication attempts |
|
FIA_UAU.2 |
All use of authentication mechanism |
|
FIA_UID.2 |
All use of identification mechanism |
User
identity |
FIA_USB.1 |
Success and failure of binding of user security
attributes to a subject (e.g. success and failure to create a subject). |
|
FMT_SMR.1 |
Modifications
to the group of users that are part of a role |
|
FPT_STM.1 |
Change
to the time |
|
Windows and Linux operating systems will record at least the following information within each audit record:
TOE does not use the audit records generated by the operating system to support TOE security objectives.
Windows and Linux operating systems will provide means to associate each auditable event with the identity of the user that caused the event.
TOE does not use the association of each auditable event with the identity of the user that caused the event to support TOE security objectives.
Windows and Linux operating systems will provide the ability to perform searches and sorting of audit data based on date, time, user identity.
TOE does not use the ability to search and sort audit records to support TOE security objectives.
TOE does not use the ability to include or exclude auditable events to support TOE security objectives.
Windows and Linux operating systems will protect the stored audit records from unauthorized deletion.
Windows and Linux operating systems will prevent modification to the audit records in the audit trail.
TOE does not use the protection of the stored audit records to support TOE security objectives.
When the
audit trail becomes full Windows and Linux operating systems
will provide the authorized administrator
capability to prevent the loss auditable events.
TOE does not use the prevention of audit data loss to support TOE security objectives.
Windows and Linux operating systems will enforce the PKI credential management SFP on Subjects: User, Objects: cryptographic key, public key certificate, trust anchors, PKIF.dll/libPKIF.so, PKIFCMS.dll/ libPKIFCMS.so , Operations: Import, export, and delete public key certificate to enforce PKI Credential Management.
TOE does not use subset access control to support TOE security objectives.
Windows and Linux operating systems will enforce the PKI credential management SFP (based on security attributes) on subjects: all subjects; list of objects: cryptographic keys and public key certificate; list of subjects and object attributes: identity of the subject and the set of roles that the subject is authorized to assume object attributes PKIF.dll/libPKIF.so, PKIFCMS.dll/ libPKIFCMS.so access rights to enforce PKI Credential Management.
Windows and Linux operating systems will enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed:
Windows and Linux operating systems will explicitly authorize access of subjects to objects based on the following additional rule:
TOE does not use security attribute based access control to support TOE security objectives.
Windows and Linux operating systems will ensure that any previous information content of a resource is made unavailable.
TOE does not use residual information protection to support TOE security objectives.
Windows and Linux operating systems will provide authentication failure handling. Windows and Linux operating system will detect when 5 unsuccessful login attempts occur. When 5 unsuccessful login attempts has been made the operating system will lockout the account and prevent all entities requesting authentication other than the administrator from performing activities that require authentication until an action is taken by the administrator.
PKIF users in their administrative capacity will configure the number of unsuccessful login attempts.
TOE does not use the results of operating system authentication failure handling to support TOE security objectives. Unauthenticated users are prevented from accessing the TOE.
TOE does not use operating system user or role to support TOE security objectives. Once the user is authenticated operating system uses the role and user attributes to enforce the required security functional requirements without the involvement of the TOE.
Windows and Linux operating systems will restrict the actions a user might perform before verifying the identity of the user. Operating system will authenticate all users. This will insure that only authenticated users conduct IT Environment mediated actions. The only action that is allowed to be performed by unauthenticated user is system shutdown.
TOE does not rely on the operating system to restrict the
actions that unauthenticated users might perform to support TOE security
objectives. Unauthenticated users are prevented from accessing the TOE.
Windows and Linux operating systems will safeguard authentication information. During authentication operating system will only display a dialog box with no authentication information. Operating system ensures that while authentication is in progress the only feedback provided to the unauthenticated user is a dialog box indicating the failure of their login attempt.
TOE does not rely on the operating system to prevent the display of authentication information to unauthenticated users in support of TOE security objectives. Unauthenticated users are prevented from accessing the TOE.
TOE does not rely on the operating systems to restrict the actions that unidentified users might perform to support TOE security objectives. Unidentified users are prevented from accessing the TOE.
Windows and Linux operating systems will associate all user security attributes with subjects acting on the behalf of that user.
TOE does not rely on the User-subject binding to support TOE security objectives.
Windows and Linux operating systems will restrict the capability to disable, enable, modify audit functions to the administrator.
TOE does not use operating system capability to restrict the behavior of the audit functions to support TOE security objectives.
Windows and Linux operating systems will permit only authorized users to change the security attributes. Operating system will enforce access control to restrict user’s ability to modify, query, delete the security attributes (user role, key identifier, association between private key and public key certificate). This will ensure that only authorized users, i.e., those with the appropriate role, are permitted to change specified security attributes.
TOE does not use operating system user or role to support TOE security objectives. Once the user is authenticated operating system uses the role and user attributes to enforce the required security functional requirements without the involvement of the TOE.
Windows and Linux operating systems will provide valid default security attributes when an object is initialized. Operating system will provide specific default values for security attributes that are used to enforce the PKI credential management SFP. Operating system will allow users to specify alternative initial values to override the default values when an object or information is created.
TOE does not rely on operating system static attribute initialization to support TOE security objectives. Operating system will provide valid default security attributes when initializing an object and determine which users may specify alternative initial values without the involvement of the TOE.
TOE does not rely on operating protection of trust anchors, I&A data, or login configuration to support TOE security objectives. Once the user is authenticated operating system uses the role and user attributes to restrict access.
PKIFv2 depends on Windows and Linux operating systems to perform security management functions:
TOE does not use the results of operating system security management functions to support TOE security objectives.
TOE does not use operating system user or role to support TOE security objectives. Once the user is authenticated operating system uses the role and user attributes to enforce the required security functional requirements without the involvement of the TOE.
TOE does not rely on operating system non-bypassability enforcement to support TOE security objectives. Operating system will ensure that TOE Security Policy enforcement functions are not bypassed without the involvement of the TOE.
TOE assumes that the operating system enforces domain separation for the protection of I&A and private key data managed by the IT environment, but this enforcement is invisible to the TOE and is not used to support TOE security objectives.