Microsoft DotNet Framework 4.0 STIG SCAP Benchmark
V002.002R2 2020-12-11       U_MS_DotNet_Framework_4-0_V2R2_STIG_SCAP_1-2_Benchmark.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: [email protected]
Vuln Rule Version CCI Severity Title Description
SV-225223r615940_rule APPNET0031 CCI-000185 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.
SV-225230r615940_rule APPNET0062 CCI-002450 MEDIUM The .NET CLR must be configured to use FIPS approved encryption modules. FIPS encryption is configured via .NET configuration files. There are numerous configuration files that affect different aspects of .Net behavior. The .NET config files are described below. Machine Configuration Files: The machine configuration file, Machine.config, contains settings that apply to an entire computer. This file is located in the %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config directory for 32 bit .NET 4 installations and %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config for 64 bit systems. Machine.config contains configuration settings for machine-wide assembly binding, built-in remoting channels, and ASP.NET. Application Configuration Files: Application configuration files contain settings specific to an application. If checking these files, a .NET review of a specific .NET application is most likely being conducted. These files contain configuration settings that the Common Language Runtime reads (such as assembly binding policy, remoting objects, and so on), and settings that the application can read. The name and location of the application configuration file depends on the application's host, which can be one of the following: Executable–hosted application configuration files. The configuration file for an application hosted by the executable host is in the same directory as the application. The name of the configuration file is the name of the application with a .config extension. For example, an application called myApp.exe can be associated with a configuration file called myApp.exe.config. Internet Explorer-hosted application configuration files. If an application hosted in Internet Explorer has a configuration file, the location of this file is specified in a tag with the following syntax. In this tag, "location" represents a URL that point to the configuration file. This sets the application base. The configuration file must be located on the same web site as the application. .NET 4.0 allows the CLR runtime to be configured to ignore FIPS encryption requirements. If the CLR is not configured to use FIPS encryption modules, insecure encryption modules might be employed which could introduce an application confidentiality or integrity issue.
SV-225235r615940_rule APPNET0067 CCI-000130 MEDIUM Event tracing for Windows (ETW) for Common Language Runtime events must be enabled. Event tracing captures information about applications utilizing the .NET CLR and the .NET CLR itself. This includes security oriented information, such as Strong Name and Authenticode verification. Beginning with Windows Vista, ETW is enabled by default however, the .Net CLR and .Net applications can be configured to not utilize Event Tracing. If ETW event tracing is disabled, critical events that occurred within the runtime will not be captured in event logs.
SV-225238r615940_rule APPNET0075 CCI-001762 MEDIUM Disable TLS RC4 cipher in .Net Use of the RC4 cipher in TLS could allow an attacker to perform man-in-the-middle attacks and recover plaintext from encrypted sessions. Applications that target .Net version 4.x running on multiple Windows versions could be vulnerable to these types of attacks. The registry settings in this requirement will prevent .Net applications that target the 4.x framework from selecting and utilizing the Schannel.dll RC4 cipher for TLS connections. Applications that use TLS when connecting to remote systems will perform a handshake and negotiate the TLS version and cipher that is to be used between the client and the server. This is standard protocol for all TLS connections. If the server and client are not configured to use the same TLS version and cipher, the TLS connection may fail. Applications should be tested with these registry settings prior to production implementation of the fix in order to avoid application outages.