| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: B3CB706A6ADDE1748C32DB756BC478CBF6005E4B ~~~~~ HKLM:\SOFTWARE\Microsoft\StrongName\Verification exists but no values were found within. Comments |
|||||
Check Text
Use regedit to review the Windows registry key HKLM\Software\Microsoft\StrongName\Verification. There should be no assemblies or hash values listed under this registry key. If the StrongName\Verification key does not exist, this is not a finding. If there are assemblies or hash values listed in this key, each value represents a distinct application assembly that does not have the application strong name verified. If any assemblies are listed as omitting strong name verification in a production environment, this is a finding. If any assemblies are listed as omitting strong name verification in a development or test environment and the IAO has not provided documented approvals, this is a finding.
Fix Text
Use regedit to remove the values stored in Windows registry key HKLM\Software\Microsoft\StrongName\Verification. There should be no assemblies or hash values listed under this registry key. All assemblies must require strong name verification in a production environment. Strong name assemblies that do not require verification in a development or test environment must have documented approvals from the IAO.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 76CBF5A7C87686EA51FA77410808A92FDB3A947F ~~~~~ All user profiles have State configured to 0x00023c00 Comments |
|||||
Check Text
If the system or application being reviewed is SIPR based, this finding is NA. This check must be performed for each user on the system. Use regedit to locate "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State". If the State value for any user is not set to the hexadecimal value of 0x23C00, this is a finding.
Fix Text
This fix must be performed for each user on the system. Using regedit, change the hexadecimal value of the "HKEY_USER\[UNIQUE USER SID VALUE]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State" registry key to 0x23C00.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT APPLICABLE on 03/05/2026 ResultHash: 0E4360D1A69538A55E456743C4260C8FCE83E079 ~~~~~ Installed .NET version is '4.8'. This check only applies to .NET version 4.0 specifically so this requirement is NA. Comments |
|||||
Check Text
The infrastructure to enable Code Access Security (CAS) exists only in .NET Framework 2.x-4.x. This requirement is Not Applicable (NA) for .NET Framework greater than 4.x. (Note: The infrastructure is deprecated and is not receiving servicing or security fixes.) Caspol.exe is a Microsoft tool used for working with .Net policy. Use caspol.exe to list the code groups and any publisher membership conditions. The location of the caspol utility is dependent upon the system architecture of the system running .Net. For 32 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319. For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Example: cd %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319 To check code groups for the machine, run the following command: caspol.exe -m -lg Sample Results: Microsoft (R) .NET Framework CasPol 4.0.30319.1 Copyright (c) Microsoft Corporation. All rights reserved. Policy change prompt is ON Level = Machine Code Groups: 1. All code: Nothing 1.1. Zone - MyComputer: FullTrust (LevelFinal) 1.1.1. StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust 1.1.2. StrongName - 00000000000000000400000000000000: FullTrust 1.2. Zone - Intranet: LocalIntranet 1.2.1. All code: Same site Web 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' 1.3. Zone - Internet: Internet 1.3.1. All code: Same site Web 1.4. Zone - Untrusted: Nothing 1.5. (First Match) Zone - Trusted: Internet 1.5.1. All code: Same site Web 1.6. Publisher - 30818902818100E47B359ACC061D70C237B572FA276C9854CFABD469DFB74E77D026630BEE2A0C2F8170A823AE69FDEB65704D7FD446DEFEF1F6BA12B6ACBDB1BFA7B9B595AB9A40636467CFF7C73F198B53A9A7CF177F6E7896EBC591DD3003C5992A266C0AD9FBEE4E2A056BE7F7ED154D806F7965F83B0AED616C192C6416CFCB46FC2F5CFD0203010001: FullTrust Success Section 1.6 above indicates the presence of a publisher's key that meets the Publisher's Membership Condition and is also given full trust. If the Publisher Membership Condition is used on a nondefault Code Group and the use of that publisher's certificate is not documented and approved by the ISSO, this is a finding.
Fix Text
Trust must be established when utilizing Publishers Membership Condition. All publisher's certificates must have documented approvals from the ISSO.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT APPLICABLE on 03/05/2026 ResultHash: 0E4360D1A69538A55E456743C4260C8FCE83E079 ~~~~~ Installed .NET version is '4.8'. This check only applies to .NET version 4.0 specifically so this requirement is NA. Comments |
|||||
Check Text
If the application is a COTS product, this requirement is Not Applicable (NA). The infrastructure to enable Code Access Security (CAS) exists only in .NET Framework 2.x-4.x. The requirement is Not Applicable (NA) for .NET Framework greater than 4.x. (Note: The infrastructure is deprecated and is not receiving servicing or security fixes.) Caspol.exe is a Microsoft tool used for working with .Net policy. Use caspol.exe to list the code groups and any publisher membership conditions. The location of the caspol utility is dependent upon the system architecture of the system running .Net. For 32 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319. For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Example: cd %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319 To check code groups, run the following command: caspol.exe -all -lg Sample response: Microsoft (R) .NET Framework CasPol 4.0.30319.1 Security is ON Execution checking is ON Policy change prompt is ON Level = Machine Code Groups: 1. All code: Nothing 1.1. Zone - MyComputer: FullTrust (LevelFinal) 1.1.1. StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust 1.1.2. StrongName - 00000000000000000400000000000000: FullTrust 1.2. Zone - Intranet: LocalIntranet 1.2.1. All code: Same site Web 1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery' 1.3. Zone - Internet: Internet 1.3.1. All code: Same site Web 1.4. Zone - Untrusted: Nothing 1.5. (First Match) Zone - Trusted: Internet 1.5.1. All code: Same site Web 1.6. Publisher - 30818902818100E47B359ACC061D70C237B572FA276C9854CFABD469DFB74E77D026630BEE2A0C2F8170A823AE69FDEB65704D7FD446DEFEF1F6BA12B6ACBDB1BFA7B9B595AB9A40636467CFF7C73F198B53A9A7CF177F6E7896EBC591DD3003C5992A266C0AD9FBEE4E2A056BE7F7ED154D806F7965F83B0AED616C192C6416CFCB46FC2F5CFD0203010001: FullTrust Success An assembly will satisfy the StrongNameMembershipCondition if its metadata contains the strongly identifying data associated with the specified strong name. At the least, this means it has been digitally signed with the private key associated with the public key recorded in the policy. The presence of the encryption key values in the StrongName field indicates the use of StrongNameMembershipCondition. If a Strong Name Membership Condition is assigned to a non-default Code Group the private key must be adequately protected by the software developer or the entity responsible for signing the assemblies. Ask the Systems Programmer how the private keys are protected. Private keys are simply values stored as strings of data. Keys can be stored in files on the file system or in a centralized data repository. Adequate protection methods include, but are not limited to: - utilizing centralized key management; - using strict file permissions to limit access; and - tying strong pass phrases to the key. If the private key used to sign the assembly is not adequately protected, this is a finding.
Fix Text
Ask the Systems Programmer how the private keys used to sign the assembly are protected. Private keys are simply values stored as strings of data. Keys can be stored in files on the file system or in a centralized data repository. Adequate protection methods include, but are not limited to: - utilizing centralized key management; - using strict file permissions to limit access; and - tying strong pass phrases to the key. The private key(s) used to sign the assembly must be protected. Utilize centralized key management or strict file permissions along with strong pass phrases and/or other well-established industry practices for managing and controlling access to private keys.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT APPLICABLE on 03/05/2026 ResultHash: 0E4360D1A69538A55E456743C4260C8FCE83E079 ~~~~~ Installed .NET version is '4.8'. This check only applies to .NET version 4.0 specifically so this requirement is NA. Comments |
|||||
Check Text
The infrastructure to enable Code Access Security (CAS) exists only in .NET Framework 2.x-4.x. The requirement is Not Applicable (NA) for .NET Framework greater than 4.x. (Note: The infrastructure is deprecated and is not receiving servicing or security fixes.) Ask the System Administrator if all CAS policy and policy configuration files are included in the system backup. If they are not, this is a finding. Ask the System Administrator if the policy and configuration files are backed up prior to migration, deployment, and reconfiguration. If they are not, this is a finding. Ask the System Administrator for documentation that shows CAS Policy configuration files are backed up as part of a disaster recovery plan. If they have no documentation proving the files are backed up, this is a finding.
Fix Text
All CAS policy and policy configuration files must be included in the system backup. All CAS policy and policy configuration files must be backed up prior to migration, deployment, and reconfiguration. CAS policy configuration files must be included in disaster recovery plan documentation.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT APPLICABLE on 03/05/2026 ResultHash: 5484AA1F334AF98C429F840221EEC8B7ADB0A2EE ~~~~~ No machine.config or *.exe.config files found using .NET remoting with HTTP channel so this requirement is NA. Comments |
|||||
Check Text
If .NET remoting with HTTP channel is not used, this check is Not Applicable. Review the machine.config file and the [application name].exe.config file. For 32-bit systems, the "machine.config" file is contained in the following folder: %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config For 64-bit systems, the "machine.config" file is contained in the following folder: %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config. Microsoft specifies locating the [application].config file in the same folder as the application executable (.exe) file. However, the developer does have the capability to specify a different location when the application is compiled. Therefore, if the file is not found in the application home folder, a search of the system is required. If the [application name].exe.config file is not found on the system, then only a check of the machine.config file is required. Sample machine/application config file: <application name=“remoteserver”> <service> <activated type=“sample.my.object, myobjects”/> </service> <channels> <channel ref=“http server” port=“80”/> </channels> </application> <serverProviders> <provider ref="wsdl" /> <formatter ref="soap" typeFilterLevel="Low" /> <formatter ref="binary" typeFilterLevel="Low" /> </serverProviders> Microsoft provides three "channels" that are used for remoting connectivity. They are the HTTP, TCP, and IPC channels. The channel that is used is specified via the <channels> element in the config file. HTTP channel example: <channel ref=“http server” port=“80”/> The HTTP channel only supports encryption and message integrity when the remote object is hosted in Internet Information Services (IIS) using TLS. The above example shows the well-known TLS port of 443 is not being used. If the HTTP remoting channel is not configured to protect the channel by using TLS encryption, this is a finding.
Fix Text
If .NET remoting with HTTP channel is not used, this fix is Not Applicable. Ensure encryption and message integrity are used for HTTP remoting channels. The HTTP channel only supports encryption and message integrity when the remote object is hosted in Internet Information Services (IIS) using TLS. HTTP channels are protected via TLS (HTTPS). <channels> <channel ref=“http server” port=“443”/> </channels> Change the channel ref parameter to utilize a TLS port and leverage TLS on the remote IIS server.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 69B5FA47DB52CEE6EE623CD1C66B970ACFE69DFB ~~~~~ Operating system: --------------------------------- Name: Microsoft Windows Server 2022 Standard [21H2] Version: 10.0.20348 Enabled .NET Windows features: --------------------------------- NET-Framework-45-Core Library files: --------------------------------- File Path: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll Version: 4.8.4795.0 File Path: C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll Version: 4.8.4795.0 Ref - https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework Ref - https://support.microsoft.com/en-us/topic/clarification-on-the-support-life-cycle-for-the-net-framework-3-5-the-net-framework-3-0-and-the-net-framework-2-0-28621c7b-226c-7682-27f5-2e2a42db39c3 Comments |
|||||
Check Text
Determine which versions of the .NET Framework are installed by opening the directory %systemroot%\Microsoft.NET. The folder named "%systemroot%\Microsoft.NET\Framework" contains .NET files for 32 bit systems. The folder named "%systemroot%\Microsoft.NET\Framework64" contains .NET files for 64 bit systems. 64 bit systems will have both the 32 bit and the 64 bit folders. 32 bit systems do not have a Framework64 folder. Within each of the folders are the individual folder names that contain the corresponding versions of the .NET Framework: v4.0.30319 v3.5 v3.0 v2.0.50727 v1.1.4322 v1.0.3705 Search for all the Mscorlib.dll files in the %systemroot%\Microsoft.NET\Framework folder and the %systemroot%\Microsoft.NET\Framework64 folder if the folder exists. Click on each of the files, view properties, and click the version tab to determine the version installed. If there is no Mscorlib.dll, there is no installed version of .Net Framework in that directory. More specific information on determining versions of .Net Framework installed can be found at the following link. http://support.microsoft.com/kb/318785 Verify extended support is available for the installed versions of .Net Framework. Verify the .Net Framework support dates with Microsoft Product Lifecycle Search link. http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=.NET+Framework Beginning with .NET 3.5 SP1, the .NET Framework is considered a Component of the Windows OS. Components follow the Support Lifecycle policy of their parent product or platform. .NET Framework 3.5 cannot function without the .NET Framework 2.0 and the .NET Framework 3.0, because there is no common language runtime (CLR) in the .NET Framework 3.5 layer. Therefore, when the .NET Framework 3.5 product is installed, the .NET Framework 2.0 and the .NET Framework 3.0 SP products are also installed. Installation of .NET 2.0 and 3.0 SP products as part of .NET Framework 3.5 is Not a Finding. (https://support.microsoft.com/en-us/topic/clarification-on-the-support-life-cycle-for-the-net-framework-3-5-the-net-framework-3-0-and-the-net-framework-2-0-28621c7b-226c-7682-27f5-2e2a42db39c3) If any versions of the .Net Framework are installed and support is no longer available, this is a finding.
Fix Text
Remove unsupported versions of the .NET Framework and upgrade legacy applications that utilize unsupported versions of the .NET framework.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 665ECD2BE03F9086D5C3B003C3B3238D2C474D25 ~~~~~ No machine.config or *.exe.config files found with 'enforceFIPSPolicy enabled=false'. Comments |
|||||
Check Text
Examine the .NET CLR configuration files from the vulnerability discussion to find the runtime element and then the "enforceFIPSPolicy" element. Example: <configuration> <runtime> <enforceFIPSPolicy enabled="true|false" /> </runtime> </configuration> By default, the .NET "enforceFIPSPolicy" element is set to "true". If the "enforceFIPSPolicy" element does not exist within the "runtime" element of the CLR configuration, this is not a finding. If the "enforceFIPSPolicy" element exists and is set to "false", and the IAO has not accepted the risk and documented the risk acceptance, this is a finding.
Fix Text
Examine the .NET CLR configuration files to find the runtime element and then the "enforceFIPSPolicy" element. Example: <configuration> <runtime> <enforceFIPSPolicy enabled="true|false" /> </runtime> </configuration> Delete the "enforceFIPSPolicy" runtime element, change the setting to "true" or there must be documented IAO approvals for the FIPS setting.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: E28F7B07BF034968DDD074235F2D4C0EFC0E8F76 ~~~~~ Registry Path: HKLM:\SOFTWARE\Microsoft\.NETFramework Value Name: AllowStrongNameBypass Value: 0x00000000 (0) Type: REG_DWORD Registry Path: HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework Value Name: AllowStrongNameBypass Value: 0x00000000 (0) Type: REG_DWORD Comments |
|||||
Check Text
If there is documented ISSO risk acceptance for development systems, this is not a finding. For 32 bit production systems: Use regedit to examine the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework” key. On 64-bit production systems: Use regedit to examine both the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework” and “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework” keys. If the "AllowStrongNameBypass" value does not exist, or if the “DWORD” value is set to “1”, this is a finding. Documentation must include a complete list of installed .Net applications, application versions, and acknowledgement that ISSO trusts each installed application. If application versions installed on the system do not match approval documentation, this is a finding.
Fix Text
For 32 bit production systems: Set “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AllowStrongNameBypass" to a “DWORD” value of “0”. On 64-bit production systems: Set “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\ AllowStrongNameBypass” and “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\ AllowStrongNameBypass” to a “DWORD” value of “0”. Or, obtain documented ISSO risk acceptance for each .Net application installed on the system. Approval documentation will include complete list of all installed .Net applications, application versions, and acknowledgement of ISSO trust of each installed application.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 6CC95A95DACFD9A95160D8D82AE7400D383C1A8D ~~~~~ No *.exe.config files found with 'loadFromRemoteSources enabled=true'. Comments |
|||||
Check Text
Open Windows explorer and search for *.exe.config. Search each config file found for the "loadFromRemoteSources" element. If the loadFromRemoteSources element is enabled ("loadFromRemoteSources enabled = true"), and the remotely loaded application is not run in a sandboxed environment, or if OS based software controls, such as AppLocker or Software Security Policies, are not utilized, this is a finding.
Fix Text
.Net application code loaded from a remote source must be run in a controlled environment. A controlled environment consists of a sandbox, such as running in an Internet Explorer host environment or employing OS based software access controls, such as AppLocker or Software Security Policies, when application design permits. Obtain documented IAO approvals for all remotely loaded code.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 337EA4CB8826346C79B61FFD2C48107B8F2246C3 ~~~~~ No machine.config or *.exe.config files found with 'etwEnable enabled=false'. Comments |
|||||
Check Text
Open Windows explorer and search for all .NET config files including application config files (*.exe.config) NOTE: Beginning with Windows Vista and Windows Server 2008, ETW Tracing is enabled by default and the "etwEnable" setting is not required in order for Event Tracing to be enabled. An etwEnable setting of "true" IS required in earlier versions of Windows as ETW is disabled by default. Examine the configuration settings for <etwEnable enabled="false" />. If the "etwEnable" element is set to "true", this is not a finding. If the "etwEnable" element is set to "false" and documented approvals by the IAO are not provided, this is a finding.
Fix Text
Open Windows explorer and search for all .NET config files including application config files (*.exe.config). Examine the configuration settings for <etwEnable enabled="false" />. Enable ETW Tracing by setting the etwEnable flag to "true" or obtain documented IAO approvals.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 4E9D9F9778F6BF1402126A5E6E14400D9AF77B9C ~~~~~ No applications found requiring .NET 4.0 specifically. Comments |
|||||
Check Text
This requirement does not apply to the "caspol.exe" assembly or other assemblies provided with the Windows OS or the Windows Secure Host Baseline (SHB). Ask the system administrator to provide documentation that identifies: - Each .Net 4.0 application run on the system. - The .Net runtime host that invokes the application. - The security measures employed to control application access to system resources or user access to application. For additional insight run: tasklist /fi "modules eq mscoree.dll" If all .Net applications, runtime hosts and security protections have been documented or if there are no .Net 4.0 applications existing on the system, this is not a finding. If there is no documentation that identifies the existence of .NET 4.0 applications or the lack thereof, this is a finding. If the runtime hosts have not been identified, this is a finding. If the security protections have not been identified, this is a finding.
Fix Text
Document the existence of all .Net 4.0 applications that are not provided by the host Windows OS or the Windows Secure Host Baseline (SHB). Document the corresponding runtime hosts that are used to invoke the applications. Document the applications security control requirements (restricting application access to resources or user access to the application).
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT APPLICABLE on 03/05/2026 ResultHash: 499D611575281956E8E80B6EFACA64CD0F81EBAD ~~~~~ No machine.config or *.exe.config files found using .NET remoting with TCP channel so this requirement is NA. Comments |
|||||
Check Text
If .NET remoting with TCP channel is not used, this check is Not Applicable. Check the machine.config and the [application executable name].exe.config configuration files. For 32-bit systems, the "machine.config" file is contained in the following folder. %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config For 64-bit systems, the "machine.config" file is contained in the following folder. %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config. Microsoft specifies locating the application config file in the same folder as the application executable (.exe) file. However, the developer does have the capability to specify a different location when the application is compiled. Therefore, if the config file is not found in the application home folder, a search of the system is required. If the [application name].exe.config file is not found on the system, then only a check of the machine.config file is required. Sample machine/application config file: <application name=“remoteserver”> <service> <activated type=“sample.my.object, myobjects”/> </service> <channels> <channel ref=“tcp server” port=“6134”/> </channels> </application> <serverProviders> <provider ref="wsdl" /> <formatter ref="soap" typeFilterLevel="Full" /> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> Microsoft provides three "channels" that are used for remoting connectivity. They are the HTTP, TCP, and IPC channels. The channel that is used is specified via the <channels> element in the config file. TCP channel example: <channel ref=“tcp” port=“6134” secure="true"/> The TCP channel provides encryption and message integrity when the "secure" flag is set to "true" as shown in the above example. If the "secure" flag is not set to "true" for the TCP channel, this is a finding.
Fix Text
If .NET remoting with TCP channel is not used, this fix is Not Applicable. Ensure encryption and message integrity are used for TCP remoting channels. TCP remoting connections are protected via the secure=true configuration parameter. <channels> <channel ref="tcp" secure="true" /> </channels> Include the secure="true" flag in the channel ref parameter of the machine.config and [application name].exe.config file if the [application name].exe.config file exists on the system.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: 23C37571322EA7216F197978D4B3FF97743E9C71 ~~~~~ .NET Framework 4 version is 4.6 or later. Registry Path: HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 Value Name: SystemDefaultTlsVersions Value: 0x00000001 (1) Type: REG_DWORD Registry Path: HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 Value Name: SystemDefaultTlsVersions Value: 0x00000001 (1) Type: REG_DWORD Comments |
|||||
Check Text
In older Windows systems (Windows Server 2012 or earlier), TLS 1.2 must be enabled systemwide by setting "SchUseStrongCrypto". SystemDefaultTlsVersions is a configuration switch in .NET Framework (starting from 4.6) that allows the application to use the default TLS version supported by the underlying Windows operating system instead of hardcoding a specific TLS version (like TLS 1.2). Check Registry: Use regedit to review the following Windows registry keys: For 32-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ For 64 bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\ 1. If the "SchUseStrongCrypto" value name does not exist, or is not a REG_DWORD type set to "1", this is a finding. 2. For .NET Framework >4.6, use the default TLS version supported by the underlying Windows operating system. If the "SystemDefaultTlsVersions" value name does not exist, or is not a REG_DWORD type set to "1", this is a finding. Note: The SchUseStrongCrypto setting allows .NET to use TLS 1.1 and TLS 1.2. The SystemDefaultTlsVersions setting allows .NET to use the OS configuration.
Fix Text
1. SchUseStrongCrypto enabled: Use regedit to access the following registry key. For 32-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ For 64-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\ Modify or create the following Windows registry value: SchUseStrongCrypto. Set SchUseStrongCrypto to a REG_DWORD value of "1". 2. SystemDefaultTlsVersions enabled (.NET Framework >4.6): For 64-bit Windows, create a .reg file with the following content and apply it: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 3. Restart the system for changes to take effect.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT APPLICABLE on 03/05/2026 ResultHash: 0E4360D1A69538A55E456743C4260C8FCE83E079 ~~~~~ Installed .NET version is '4.8'. This check only applies to .NET version 4.0 specifically so this requirement is NA. Comments |
|||||
Check Text
The infrastructure to enable Code Access Security (CAS) exists only in .NET Framework 2.x - 4.x. The requirement is Not Applicable (NA) for .NET Framework > 4.x. (Note: The infrastructure is deprecated and is not receiving servicing or security fixes.) Open Windows explorer and search for all *.exe.config files. This requirement does not apply to the caspol.exe assembly or other assemblies provided with the Windows OS or the Windows Secure Host Baseline (SHB). To find relevant files, run the FINDSTR command from an elevated (admin) command prompt: FINDSTR /i /s "NetFx40_LegacySecurityPolicy" c:\*.exe.config This command will search all ."exe.config" files on the c: drive partition for the "LegacySecurityPolicy" setting. Repeat the command for each drive partition on the system. If the .NET application configuration file uses the legacy policy element, and .NET STIG guidance that covers these legacy versions has not been applied, this is a finding.
Fix Text
The infrastructure to enable CAS exists only in .NET Framework 2.x - 4.x. The requirement is Not Applicable (NA) for .NET Framework > 4.x. (Note: The infrastructure is deprecated and is not receiving servicing or security fixes.) Apply the .NET Framework Security Checklist for .Net versions 1 through 3.5 when using the NetFx40_LegacySecurityPolicy setting.
| Hostname | IP Address | Status | Assigned To | Last Scan | Actions |
|---|---|---|---|---|---|
| SCHR-P3-DP-001 | 164.231.170.44 | 2026-03-12 | |||
Finding DetailsEvaluate-STIG 1.2601.0 (Scan-NETFramework4_Checks) found this to be NOT A FINDING on 03/05/2026 ResultHash: D494EFC0B5BFFA0F47A4414E95B31461DB797F2D ~~~~~ No machine.config or *.exe.config files found with 'defaultProxy enabled=false' or with 'bypasslist', 'module', or 'proxy' elements. Comments |
|||||
Check Text
Open Windows explorer and search for all "*.exe.config" and "machine.config" files. The referenced file is in the WinSxS directory (original source component file used when the Windows component was installed). If the files under WinSxS are read-only and cannot be modified, this is not a finding. Search each file for the "defaultProxy" element. <defaultProxy enabled="true|false" useDefaultCredentials="true|false" <bypasslist> … </bypasslist> <proxy> … </proxy> <module> … </module> /> If the "defaultProxy" setting "enabled=false" or if the "bypasslist", "module", or "proxy" child elements have configuration entries and there are no documented approvals from the authorizing official (AO), this is a finding. If the "defaultProxy" element is empty or if "useSystemDefault =True” then the framework is using default browser settings, this is not a finding.
Fix Text
Open Windows explorer and search for all "*.exe.config" and "machine.config" files. Search each file for the "defaultProxy" element. Clear the values contained in the "defaultProxy" element, and the "bypasslist", "module", and "proxy" child elements. The IAO must provide documented approvals of any non-default proxy servers.