TD0480: NIT Technical Decision for Granularity of audit events
The NIT agrees that the current text shall be updated to enhance clarity about the described issue. Therefore the following paragraphs shall be added as a general description to the evaluation activities for FAU_GEN.1 in ND SD.
The main reasons for collecting audit information are to detect and identify error conditions, security violations, etc. on the one hand and to provide sufficient information to the Security Administrator to resolve the issue on the other hand. The audit information to be collected according to FAU_GEN.1 and the failure conditions identified in tables 2, 4 and 5 need to enable the Security Administrator at least to detect and identify the problem and provide at least basic information to resolve the issue. And for this level of detail also the other FAU requirements apply – in particular the need for local and remote storage of audit information according to FAU_STG_EXT.1.
The level of detail that needs to be provided to the Security Administrator to actually resolve an issue usually depends on the complexity of the underlying use case. It is expected that a product provides additional levels of auditing to support resolution of error conditions, security violations, etc. beyond the level required by FAU_GEN.1 but it should also be clear that a high level of granularity cannot be maintained on most systems by default due to the high number of audit events that would be generated in such a configuration. It is expected that the TOE will be capable of auditing sufficient information to meet the requirements of FAU_GEN.1. This may include audits that are generated only when configured if the TOE configuration can be modified without taking the TOE out of production.
The issue described above explicitly refers to the use of X.509 certificates. In case a certificate-based authentication fails, an error message telling the Security Administrator that ‘something is wrong with the certificate’ shall not be considered as sufficient information about the ‘reason for failure’ as a basic information to resolve the issue. The log message shall inform the Security Administrator at least about the type of error (Example types of error would be: ‘Trust issue’ with the certificate, e.g. due to failed path validation; use of an ‘expired certificate’; absence of basicConstraints extension; CA flag not set for a certificate presented as a CA; signature validation failure for any certificate in the certificate path; failure to establish revocation status; revoked certificate). The NIT recommends for audit information related to the use of X.509 certificates that it uniquely identifies the certificate that couldn’t be successfully verified. For example, identification of a certificate could include Key Subject and Key ID, where key subject is an identifier contained in the CN or SAN and where Key ID is a certificate's serial number and issuer name or subject key identifier (SKI) and authority key identifier (AKI).
In general when using open source libraries like OpenSSL, passing on error messages from such libraries to the user is regarded as good practice.
For further information, please see the NIT interpretation at: https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/NITDecisionRFI201839.pdf