Microsoft Dot Net Framework 4.0 STIG

V1R1 2013-03-06       U_Microsoft_DotNet_Framework4_V1R1_Benchmark-xccdf.xml
Applicable to systems and applications utilizing the Microsoft .Net version 4.0 framework.
Vuln Rule Version CCI Severity Title Description
SV-7438r2_rule APPNET0031 MEDIUM Digital signatures assigned to strongly named assemblies must be verified. A strong name consists of the assembly's identity, simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. Strong names serve to identify the author of the code. If digital signatures used to sign strong name assemblies are not verified, any self signed code can be impersonated. This can lead to a loss of system integrity. System AdministratorDCSL-1
SV-7444r2_rule APPNET0046 MEDIUM Windows systems must be configured to prevent application use of Test Root certificates. Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. A root certificate is a public key certificate or self signed certificate that identifies the Root Certificate Authority. Digital certificates are verified by using a chain of trust. The trust anchor for digital certificates is the Root Certificate Authority (CA). A CA may generate a Test Root Certificate that is used for testing purposes. Configuring production Windows systems to allow applications to use Test Root Certificates in order to ascertain trust can create an integrity risk.Systems that are compliant with this STIG requirement, may experience operational issues when attempting to run or install signed applications and device drivers that have been signed with a test root certificate. This is due to the production system being configured to require that certificates marked as being for test purposes only are not used. System AdministratorDCSL-1
SV-7445r2_rule APPNET0047 MEDIUM Windows must check for expired application certificates Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will not check for expired certificates creating an integrity risk which could result in malware running on the system. APPNET0047_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications or drivers. This is due to the system being configured to require certificate validation prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the certificate when installing on an isolated network or system, the installer must manually validate the certificate of the signed application prior to installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA, then ensuring and documenting that no certificate notifications or issues were encountered. System AdministratorDCSL-1
SV-41559r1_rule APPNET0049 MEDIUM Windows must be configured to check for revoked application certificates. Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will not check for revoked certificates creating an integrity risk that could result in malware being run on the system. APPNET0049_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications. This is due to the system being configured to require certificate validation checks prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the certificate when installing on an isolated network or system, the installer must manually validate the certificate of the signed application prior to installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA, then ensuring and documenting that no certificate notifications or issues were encountered. System AdministratorDCSL-1
SV-7448r2_rule APPNET0050 MEDIUM Windows must be configured to block application execution if certificate server status is unavailable. Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. Certificate validation tests include certificate revocation checks to determine if the certificate has been revoked by the certificate authority. In order for Authenticode to test the certificate for revocation, the authoritative revocation server must be available. If the revocation server is not available, the certificate status is unknown and the software must be prevented from running until the certificate can be validated. By default, Windows will allow application software to run if the certificate revocation server is offline and not available. This creates an integrity risk of malware being introduced into the system. APPNET0050_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications or drivers. This is due to the system being configured to require certificate server status validation prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the certificate server availability status when installing on an isolated network or system, the installer must manually validate certificate server availability prior to application installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA server, then ensuring and documenting that no certificate notifications or issues were encountered. System AdministratorDCSL-1
SV-7449r3_rule APPNET0051 MEDIUM Windows must be configured to check the time stamp servers certificate for revocation. Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. As part of the overall signing process, a trusted time stamp server also digitally signs the assembly. The time stamp server's signature confirms the developer's certificate was valid at the time the developer signed the assembly. If the system is not configured properly, Authenticode will not check for revocation of the time stamp server’s certificate. Not checking for certificate revocation creates a risk that could lead to a loss of system integrity. APPNET0051_MITSystems that are compliant with this STIG requirement and have restricted or no network access, may experience operational issues when attempting to run or install signed applications or drivers. This is due to the system being configured to require certificate validation prior to running the application, yet not having the means to communicate with the CA in order to validate the certificate. To address this issue, the DAA may accept the risk of reconfiguring the system back to factory default settings (23c00) for the time required to install the signed application. To mitigate the risk of not automatically validating the time stamp certificate when installing on an isolated network or system, the installer must manually validate the certificate of the signed application prior to installation. One way this can be accomplished is by using the Signtool.exe utility found in the Windows SDK. Signtool.exe provides the capability to manually validate the application signing certificate. See usage documentation for instructions on use. Another validation method is to install the application on a .NET STIG compliant system in a test environment that provides an available network path to the signing CA, then ensuring and documenting that no certificate notifications or issues were encountered.System AdministratorDCSL-1
SV-41412r1_rule APPNET0068 MEDIUM Windows must be configured to invalidate PKCS #7 version 1 signed objects Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will not invalidate older PKCS #7 version 1 signed objects creating a risk which could affect the integrity of the system. System AdministratorDCSL-1
SV-41581r1_rule APPNET0069 MEDIUM Software publishing state table must be configured to only trust items in the users trust database. Microsoft Windows operating systems provide a feature called Authenticode. Authenticode technology and its underlying code signing mechanisms serve to provide a mechanism to identify software publishers and ensure that software applications have not been tampered with. Authenticode technology relies on digital certificates and is based on Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and Secure Hash Algorithm (SHA) and MD5 hash algorithms. .Net application developers sign their application code with their public key and Authenticode technology performs certificate validation tasks prior to allowing the application to run. If the system is not configured properly, Authenticode will allow only downloads from publishers that are contained in users personal trust database creating an availability risk.System AdministratorDCSL-1