From 2415b9e22790b47b5454bee348c6517d69c9155e Mon Sep 17 00:00:00 2001 From: Brian Wilhite Date: Wed, 20 Nov 2019 17:02:36 -0500 Subject: [PATCH] added support for .net 4.0 V1R9 (#536) --- CHANGELOG.md | 1 + ..._Framework_4-0_STIG_V1R9_Manual-xccdf.log} | 0 ..._Framework_4-0_STIG_V1R9_Manual-xccdf.xml} | 209 ++++++++---------- ... => DotNetFramework-4-1.9.org.default.xml} | 2 +- ...rk-4-1.7.xml => DotNetFramework-4-1.9.xml} | 158 ++++++------- 5 files changed, 173 insertions(+), 197 deletions(-) rename StigData/Archive/DotNet/{U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.log => U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.log} (100%) rename StigData/Archive/DotNet/{U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.xml => U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.xml} (77%) rename StigData/Processed/{DotNetFramework-4-1.7.org.default.xml => DotNetFramework-4-1.9.org.default.xml} (84%) rename StigData/Processed/{DotNetFramework-4-1.7.xml => DotNetFramework-4-1.9.xml} (94%) diff --git a/CHANGELOG.md b/CHANGELOG.md index 521b7f801..eee5182aa 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,6 +5,7 @@ * Fixed [#427](https://github.com/microsoft/PowerStig/issues/427): Windows 10 Rule V-63373 fails to apply settings to system drive * Fixed [#514](https://github.com/microsoft/PowerStig/issues/514): Feature request: additional support for servicerule properties * Fixed [#521](https://github.com/microsoft/PowerStig/issues/521): Organizational setting warning should include Stig name +* Update PowerSTIG to successfully parse Microsoft .Net Framework STIG 4.0 STIG - Ver 1, Rel 9: [535](https://github.com/microsoft/PowerStig/issues/535) * Update PowerSTIG to successfully parse MS Internet Explorer 11 STIG - Ver 1, Rel 18: [#538](https://github.com/microsoft/PowerStig/issues/538) * Update PowerSTIG to successfully parse Mozilla Firefox STIG - Ver 4, Rel 27: [#540](https://github.com/microsoft/PowerStig/issues/540) * Update PowerSTIG to successfully parse Microsoft Windows 10 STIG - Ver 1, Rel 19: [533](https://github.com/microsoft/PowerStig/issues/533) diff --git a/StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.log b/StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.log similarity index 100% rename from StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.log rename to StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.log diff --git a/StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.xml b/StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.xml similarity index 77% rename from StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.xml rename to StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.xml index d8d2761d2..ead0a9693 100644 --- a/StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R7_Manual-xccdf.xml +++ b/StigData/Archive/DotNet/U_MS_DotNet_Framework_4-0_STIG_V1R9_Manual-xccdf.xml @@ -1,15 +1,15 @@ -acceptedMicrosoft DotNet Framework 4.0 STIGApplicable to systems and applications utilizing the Microsoft .Net version 4.0 framework. +acceptedMicrosoft DotNet Framework 4.0 STIGApplicable to systems and applications utilizing the Microsoft .Net version 4.0 framework. -DISASTIG.DOD.MILRelease: 7 Benchmark Date: 26 Apr 20191I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>APPNET0031 No Strong Name Verification<GroupDescription></GroupDescription>APPNET0031Digital signatures assigned to strongly named assemblies must be verified.<VulnDiscussion>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. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Use 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. +DISASTIG.DOD.MILRelease: 9 Benchmark Date: 25 Oct 20191I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>APPNET0031 No Strong Name Verification<GroupDescription></GroupDescription>APPNET0031Digital signatures assigned to strongly named assemblies must be verified.<VulnDiscussion>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. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Use 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. -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. +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 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. @@ -33,20 +33,20 @@ The hexadecimal value of 0x23C00 will implement the following certificate enforc 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. 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. +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". +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. APPNET0048 Publisher Membership Condition<GroupDescription></GroupDescription>APPNET0048Developer certificates used with the .NET Publisher Membership Condition must be approved by the IAO.<VulnDiscussion>A .Net assembly will satisfy the Publisher Membership Condition if it is signed with a software publisher’s Authenticode X.509v3 digital certificate that can be verified by the Windows operating system as having a chain of trust that leads to a trusted root certificate stored in the user’s certificate store. The Publisher Membership Condition can be used to identify an organization, developer, vendor, or other entity as the ultimate source of the assembly, even if the code itself was obtained from a third party, such as a mirror site. Access to system resources, such as file systems or printers, may then be granted to the assembly based on the trust relationship with the identified entity. Certificates used to sign assemblies so the Publisher Member Condition may be applied must originate from a trusted source. Using a certificate that is not from a trusted source could potentially violate system integrity and confidentiality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Trust must be established when utilizing Publishers Membership Condition. All publishers' certificates must have documented approvals from the IAO.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. +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. + +For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Example: @@ -81,12 +81,12 @@ Code Groups: 1.6. Publisher - 30818902818100E47B359ACC061D70C237B572FA276C9854CFABD469DFB74E77D026630BEE2A0C2F8170A823AE69FDEB65704D7FD446DEFEF1F6BA12B6ACBDB1BFA7B9B595AB9A40636467CFF7C73F198B53A9A7CF177F6E7896EBC591DD3003C5992A266C0AD9FBEE4E2A056BE7F7ED154D806F7965F83B0AED616C192C6416CFCB46FC2F5CFD0203010001: FullTrust Success -Section 1.6 above indicates the presence of a publishers key that meets the Publishers Membership Condition and is also given full trust. +Section 1.6 above indicates the presence of a publishers key that meets the Publishers Membership Condition and is also given full trust. If the Publisher Membership Condition is used on a non-default Code Group and the use of that publisher's certificate is not documented and approved by the IAO, this is a finding. -APPNET0052 Strong Name Membership Condition<GroupDescription></GroupDescription>APPNET0052Encryption keys used for the .NET Strong Name Membership Condition must be protected.<VulnDiscussion>The Strong Name Membership condition requires that member assemblies be defined with Strong Names. 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. If assemblies do not have a strong name assigned, the assembly cannot be unique and the author of the code cannot be uniquely identified. In order to create the strong name, the developer must use a cryptographic key pair to sign the assembly. If the developer does not protect the key, the key can be stolen and used to sign any application, including malware applications. This could adversely affect application integrity and confidentiality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Systems Programmer</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Ask the Systems Programmer how the private keys used to sign the assembly are protected. +APPNET0052 Strong Name Membership Condition<GroupDescription></GroupDescription>APPNET0052Encryption keys used for the .NET Strong Name Membership Condition must be protected.<VulnDiscussion>The Strong Name Membership condition requires that member assemblies be defined with Strong Names. 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. If assemblies do not have a strong name assigned, the assembly cannot be unique and the author of the code cannot be uniquely identified. In order to create the strong name, the developer must use a cryptographic key pair to sign the assembly. If the developer does not protect the key, the key can be stolen and used to sign any application, including malware applications. This could adversely affect application integrity and confidentiality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Systems Programmer</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Ask 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. +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: @@ -98,11 +98,11 @@ The private key(s) used to sign the assembly must be protected. Utilize central 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. +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. + +For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Example: @@ -140,13 +140,13 @@ Success An assembly will satisfy the StrongName Membership Condition 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 StrongName Membership Condition. +The presence of the encryption key values in the StrongName field indicates the use of StrongName Membership Condition. -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. +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. +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. +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: @@ -154,7 +154,7 @@ Adequate protection methods include, but are not limited to: - 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.APPNET0055 CAS and Policy Config File Backups<GroupDescription></GroupDescription>APPNET0055CAS and policy configuration files must be backed up.<VulnDiscussion>A successful disaster recovery plan requires that CAS policy and CAS policy configuration files are identified and included in systems disaster backup and recovery events. Documentation regarding the location of system and application specific CAS policy configuration files and the frequency in which backups occur is required. If these files are not identified and the information is not documented, there is the potential that critical application configuration files may not be included in disaster recovery events which could lead to an availability risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>CODB-1, CODB-2</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030All CAS policy and policy configuration files must be included in the system backup. +If the private key used to sign the assembly is not adequately protected, this is a finding.APPNET0055 CAS and Policy Config File Backups<GroupDescription></GroupDescription>APPNET0055CAS and policy configuration files must be backed up.<VulnDiscussion>A successful disaster recovery plan requires that CAS policy and CAS policy configuration files are identified and included in systems disaster backup and recovery events. Documentation regarding the location of system and application specific CAS policy configuration files and the frequency in which backups occur is required. If these files are not identified and the information is not documented, there is the potential that critical application configuration files may not be included in disaster recovery events which could lead to an availability risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>CODB-1, CODB-2</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030All 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. @@ -166,9 +166,9 @@ Ask the System Administrator for documentation that shows CAS Policy configurati .NET remoting provides the capability to build widely distributed applications. The application components may reside all on one computer or they may be spread out across the enclave. .NET client applications can make remoting calls to use objects in other processes on the same computer or on any other computer that is reachable over the network. .NET remoting can also be used to communicate with other application domains within the same process. Remoting is achieved via the exposure of endpoints that can be used to establish remote connectivity. -Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. +Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. -Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. +Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. Microsoft provides 3 different "channels" that are used for remoting. They are HTTP, TCP and IPC. @@ -177,14 +177,14 @@ Any unauthorized use of a remoting application provides unauthorized access with 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> +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.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 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. @@ -192,33 +192,33 @@ Microsoft specifies locating the [application].config file in the same folder as 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 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> + <formatter ref="soap" typeFilterLevel="Low" /> + <formatter ref="binary" typeFilterLevel="Low" /> +</serverProviders> -Microsoft provides 3 "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. +Microsoft provides 3 "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”/> +<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. +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. -APPNET0061 Unsupported .Net Framework Versions<GroupDescription></GroupDescription>APPNET0061.Net Framework versions installed on the system must be supported.<VulnDiscussion>Unsupported software introduces risks and violates DoD policy. Applications utilizing unsupported versions of .NET introduce substantial risk to the host, network, and the enclave by virtue of the fact they leverage an architecture that is no longer updated by the vendor. This introduces potential application integrity, availability, or confidentiality issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>COMS-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Remove unsupported versions of the .NET Framework and upgrade legacy applications that utilize unsupported versions of the .NET framework.Determine which versions of the .NET Framework are installed by opening the directory %systemroot%\Microsoft.NET. +APPNET0061 Unsupported .Net Framework Versions<GroupDescription></GroupDescription>APPNET0061.Net Framework versions installed on the system must be supported.<VulnDiscussion>Unsupported software introduces risks and violates DoD policy. Applications utilizing unsupported versions of .NET introduce substantial risk to the host, network, and the enclave by virtue of the fact they leverage an architecture that is no longer updated by the vendor. This introduces potential application integrity, availability, or confidentiality issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Remove unsupported versions of the .NET Framework and upgrade legacy applications that utilize unsupported versions of the .NET framework.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 while 32 bit systems do not have a Framework64 folder. @@ -241,61 +241,36 @@ Verify the .Net Framework support dates with Microsoft Product Lifecycle Search 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. - -If any versions of the .Net Framework are installed and support is no longer available, this is a finding. -APPNET0061.Net Framework versions installed on the system must be supported.<VulnDiscussion>Unsupported software introduces risks and violates DoD policy. Applications utilizing unsupported versions of .NET introduce substantial risk to the host, network, and the enclave by virtue of the fact they leverage an architecture that is no longer updated by the vendor. This introduces potential application integrity, availability, or confidentiality issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>COMS-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Remove unsupported versions of the .NET Framework and upgrade legacy applications that utilize unsupported versions of the .NET framework.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 while 32 bit systems do not have a Framework64 folder. -Within each of the aforementioned 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 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. - If any versions of the .Net Framework are installed and support is no longer available, this is a finding. APPNET0062 Administering FIPS Policy<GroupDescription></GroupDescription>APPNET0062The .NET CLR must be configured to use FIPS approved encryption modules.<VulnDiscussion>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. +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: +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. +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. +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. +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 <link> tag with the following syntax. <link rel="ConfigurationFileName" href="location"> -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. +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. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Web Administrator</Responsibility><IAControls>DCNR-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Examine the .NET CLR configuration files to find the runtime element and then the "enforceFIPSPolicy" element. Example: -<configuration> - <runtime> +<configuration> + <runtime> <enforceFIPSPolicy enabled="true|false" /> </runtime> </configuration> @@ -304,8 +279,8 @@ Delete the "enforceFIPSPolicy" runtime element, change the setting to "true" or Examine the .NET CLR configuration files from the vulnerability discussion to find the runtime element and then the "enforceFIPSPolicy" element. Example: -<configuration> - <runtime> +<configuration> + <runtime> <enforceFIPSPolicy enabled="true|false" /> </runtime> </configuration> @@ -314,11 +289,11 @@ 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. +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. -APPNET0063 Validation of Strong Names<GroupDescription></GroupDescription>APPNET0063.NET must be configured to validate strong names on full-trust assemblies.<VulnDiscussion>The "bypassTrustedAppStrongNames" setting specifies whether the bypass feature that avoids validating strong names for full-trust assemblies is enabled. By default the bypass feature is enabled in .Net 4, therefore strong names are not validated for correctness when the assembly/program is loaded. Not validating strong names provides a faster application load time but at the expense of performing certificate validation. +APPNET0063 Validation of Strong Names<GroupDescription></GroupDescription>APPNET0063.NET must be configured to validate strong names on full-trust assemblies.<VulnDiscussion>The "bypassTrustedAppStrongNames" setting specifies whether the bypass feature that avoids validating strong names for full-trust assemblies is enabled. By default the bypass feature is enabled in .Net 4, therefore strong names are not validated for correctness when the assembly/program is loaded. Not validating strong names provides a faster application load time but at the expense of performing certificate validation. -Full trust assemblies are .Net applications launched from the local host. Strong names are digital signatures tied to .Net applications/assemblies. .Net 4 considers applications installed locally to be fully trusted by default and grants these applications full permissions to access host resources. +Full trust assemblies are .Net applications launched from the local host. Strong names are digital signatures tied to .Net applications/assemblies. .Net 4 considers applications installed locally to be fully trusted by default and grants these applications full permissions to access host resources. The bypass feature applies to any assembly signed with a strong name and having the following characteristics: @@ -330,16 +305,16 @@ The bypass feature applies to any assembly signed with a strong name and having Not delay-signed. -Not validating the certificates used to sign strong name assemblies will provide a faster application load time, but falsely assumes that signatures used to sign the application are to be implicitly trusted. Not validating strong name certificates introduces an integrity risk to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030For 32 bit production systems: +Not validating the certificates used to sign strong name assemblies will provide a faster application load time, but falsely assumes that signatures used to sign the application are to be implicitly trusted. Not validating strong name certificates introduces an integrity risk to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030For 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. +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. 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. +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. @@ -350,13 +325,13 @@ If application versions installed on the system do not match approval documentat APPNET0064 Legacy Security Policy<GroupDescription></GroupDescription>APPNET0064.Net applications that invoke NetFx40_LegacySecurityPolicy must apply previous versions of .NET STIG guidance.<VulnDiscussion>CAS policy is .NET runtime version-specific. In .NET Framework version 4, CAS policy is disabled by default however; it can be re-enabled by using the NetFx40_LegacySecurityPolicy setting on a per application basis. Caspol.exe is provided by Microsoft to set security policy on .Net applications prior to version 4.0. 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). -When invoking the NetFx40_LegacySecurityPolicy setting in .NET 4, earlier versions of the .NET Framework CAS policy will become active therefore previous .NET STIG guidance that applies to the reactivated versions must also be applied. +When invoking the NetFx40_LegacySecurityPolicy setting in .NET 4, earlier versions of the .NET Framework CAS policy will become active therefore previous .NET STIG guidance that applies to the reactivated versions must also be applied. -Failure to apply applicable versions of STIG guidance can result in the loss of system confidentiality, integrity or availability. +Failure to apply applicable versions of STIG guidance can result in the loss of system confidentiality, integrity or availability. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Apply the .NET Framework Security Checklist for .Net versions 1 through 3.5 when utilizing the NetFx40_LegacySecurityPolicy setting.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, you can run the FINDSTR command from an elevated (admin) command prompt: -FINDSTR /i /s "NetFx40_LegacySecurityPolicy" c:\*.exe.config +To find relevant files, you can 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. @@ -378,15 +353,15 @@ The appropriate level of trust must be established prior to enabling the loading <loadFromRemoteSources enabled="false" "*" /> </runtime> </configuration> -</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Systems Programmer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>DCFA-1, DCSL-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030.Net application code loaded from a remote source must be run in a controlled environment. +</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Systems Programmer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>DCFA-1, DCSL-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030.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. +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.Open Windows explorer and search for *.exe.config. Search each config file found for the "loadFromRemoteSources" element. -If the loadFromRemoteSources element is enabled +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. APPNET0066 .Net Default Proxy Settings<GroupDescription></GroupDescription>APPNET0066.NET default proxy settings must be reviewed and approved.<VulnDiscussion>The .Net framework can be configured to utilize a different proxy or altogether bypass the default proxy settings in the client's browser. This may lead to the framework using a proxy that is not approved for use. If the proxy is malicious, this could lead to a loss of application integrity and confidentiality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Systems Programmer</Responsibility><IAControls>DCFA-1, DCSL-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Open Windows explorer and search for all "*.exe.config" and "machine.config" files. @@ -410,15 +385,15 @@ If the "defaultProxy" setting "enabled=false" or if the "bypasslist", "module", If the "defaultProxy" element is empty then the framework is using default browser settings, this is not a finding. -APPNET0070 Software protections and controls<GroupDescription></GroupDescription>APPNET0070Software utilizing .Net 4.0 must be identified and relevant access controls configured.<VulnDiscussion>With the advent of .Net 4.0, the .Net framework no longer directly configures or enforces security policy for .Net applications. This task is now relegated to the operating system layer and the security protections built-in to .Net application "runtime hosts" that run on the O.S. +APPNET0070 Software protections and controls<GroupDescription></GroupDescription>APPNET0070Software utilizing .Net 4.0 must be identified and relevant access controls configured.<VulnDiscussion>With the advent of .Net 4.0, the .Net framework no longer directly configures or enforces security policy for .Net applications. This task is now relegated to the operating system layer and the security protections built-in to .Net application "runtime hosts" that run on the O.S. Examples of these .Net "runtime hosts" include; Internet Explorer, Windows Shell, ASP.NET, Database Engines or any other "runtime hosts" that utilize .Net and load the .Net CLR. -Security protections include utilizing runtime host security controls such as sandboxing to restrict or control application behavior as designed or required. +Security protections include utilizing runtime host security controls such as sandboxing to restrict or control application behavior as designed or required. To compensate for these design changes, Windows provides native solutions such as Software Security Policies (SSP) and Application Locker (AL) which are technologies that can be implemented via Group Policy (GPO). SSP, AL and similar third party solutions serve to restrict execution of applications, scripts and libraries based upon cryptographic hash, security zones, path and certificate values that are associated with the application files. Additionally, application developers will utilize "sandboxing" techniques within their code in order to isolate 3rd party code libraries from critical system resources. -In order to assign protections to .Net 4.0 applications, the applications must first be identified and the appropriate hosting security mechanisms configured to accomplish that task. +In order to assign protections to .Net 4.0 applications, the applications must first be identified and the appropriate hosting security mechanisms configured to accomplish that task. .Net STIG guidance cannot be applied if .Net applications are not identified and documented. The lack of an application inventory introduces confidentiality, availability and integrity vulnerabilities to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Document the existence of all .Net 4.0 applications that are not provided by the host Windows OS or the Windows Secure Host Baseline (SHB). @@ -429,7 +404,7 @@ Document the applications security control requirements (restricting application Ask the system administrator to provide documentation that identifies: - Each .Net 4.0 application they run on the system. -- The .Net runtime host that invokes the application. +- The .Net runtime host that invokes the application. - The security measures employed to control application access to system resources or user access to application. 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. @@ -440,19 +415,19 @@ If the runtime hosts have not been identified, this is a finding. If the security protections have not been identified, this is a finding. -APPNET0067 .NET Event Tracing for Windows.<GroupDescription></GroupDescription>APPNET0067Event tracing for Windows (ETW) for Common Language Runtime events must be enabled.<VulnDiscussion>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. +APPNET0067 .NET Event Tracing for Windows.<GroupDescription></GroupDescription>APPNET0067Event tracing for Windows (ETW) for Common Language Runtime events must be enabled.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>DCSL-1</IAControls>DPMS Target Framework 4.0DISADPMS TargetFramework 4.02030Open Windows explorer and search for all .NET config files including application config files (*.exe.config). -Examine the configuration settings for +Examine the configuration settings for <etwEnable enabled="false" />. Enable ETW Tracing by setting the etwEnable flag to "true" or obtain documented IAO approvals.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. +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 +Examine the configuration settings for <etwEnable enabled="false" />. If the "etwEnable" element is set to "true", this is not a finding. @@ -462,9 +437,9 @@ If the "etwEnable" element is set to "false" and documented approvals by the IAO .NET remoting provides the capability to build widely distributed applications. The application components may reside all on one computer or they may be spread out across the enclave. .NET client applications can make remoting calls to use objects in other processes on the same computer or on any other computer that is reachable over the network. .NET remoting can also be used to communicate with other application domains within the same process. Remoting is achieved via the exposure of endpoints that can be used to establish remote connectivity. -Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. +Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. -Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. +Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. Microsoft provides 3 different "channels" that are used for remoting. They are HTTP, TCP and IPC. @@ -476,9 +451,9 @@ TCP remoting connections are protected via the secure=true configuration paramet </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. -Check the machine.config and the [application executable name].exe.config configuration files. +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 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. @@ -486,25 +461,25 @@ Microsoft specifies locating the application config file in the same folder as t 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 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> + <formatter ref="soap" typeFilterLevel="Full" /> + <formatter ref="binary" typeFilterLevel="Full" /> +</serverProviders> -Microsoft provides 3 "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. +Microsoft provides 3 "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"/> +<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. diff --git a/StigData/Processed/DotNetFramework-4-1.7.org.default.xml b/StigData/Processed/DotNetFramework-4-1.9.org.default.xml similarity index 84% rename from StigData/Processed/DotNetFramework-4-1.7.org.default.xml rename to StigData/Processed/DotNetFramework-4-1.9.org.default.xml index b0666d92f..ea3a9bf53 100644 --- a/StigData/Processed/DotNetFramework-4-1.7.org.default.xml +++ b/StigData/Processed/DotNetFramework-4-1.9.org.default.xml @@ -5,4 +5,4 @@ Each setting in this file is linked by STIG ID and the valid range is in an associated comment. --> - + diff --git a/StigData/Processed/DotNetFramework-4-1.7.xml b/StigData/Processed/DotNetFramework-4-1.9.xml similarity index 94% rename from StigData/Processed/DotNetFramework-4-1.7.xml rename to StigData/Processed/DotNetFramework-4-1.9.xml index 7d9df7ecd..a9c4e3ff7 100644 --- a/StigData/Processed/DotNetFramework-4-1.7.xml +++ b/StigData/Processed/DotNetFramework-4-1.9.xml @@ -1,16 +1,16 @@ - + - <VulnDiscussion>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. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> + <VulnDiscussion>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. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls> False False - 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. + 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 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. @@ -53,9 +53,9 @@ The hexadecimal value of 0x23C00 will implement the following certificate enforc 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. +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". +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. @@ -70,11 +70,11 @@ Certificates used to sign assemblies so the Publisher Member Condition may be ap 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. +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. + +For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Example: @@ -109,7 +109,7 @@ Code Groups: 1.6. Publisher - 30818902818100E47B359ACC061D70C237B572FA276C9854CFABD469DFB74E77D026630BEE2A0C2F8170A823AE69FDEB65704D7FD446DEFEF1F6BA12B6ACBDB1BFA7B9B595AB9A40636467CFF7C73F198B53A9A7CF177F6E7896EBC591DD3003C5992A266C0AD9FBEE4E2A056BE7F7ED154D806F7965F83B0AED616C192C6416CFCB46FC2F5CFD0203010001: FullTrust Success -Section 1.6 above indicates the presence of a publishers key that meets the Publishers Membership Condition and is also given full trust. +Section 1.6 above indicates the presence of a publishers key that meets the Publishers Membership Condition and is also given full trust. If the Publisher Membership Condition is used on a non-default Code Group and the use of that publisher's certificate is not documented and approved by the IAO, this is a finding. @@ -124,11 +124,11 @@ If the Publisher Membership Condition is used on a non-default Code Group and th 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. +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. + +For 64 bit systems, caspol.exe is located at %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319. Example: @@ -166,13 +166,13 @@ Success An assembly will satisfy the StrongName Membership Condition 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 StrongName Membership Condition. +The presence of the encryption key values in the StrongName field indicates the use of StrongName Membership Condition. -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. +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. +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. +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: @@ -187,9 +187,9 @@ If the private key used to sign the assembly is not adequately protected, this i .NET remoting provides the capability to build widely distributed applications. The application components may reside all on one computer or they may be spread out across the enclave. .NET client applications can make remoting calls to use objects in other processes on the same computer or on any other computer that is reachable over the network. .NET remoting can also be used to communicate with other application domains within the same process. Remoting is achieved via the exposure of endpoints that can be used to establish remote connectivity. -Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. +Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. -Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. +Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. Microsoft provides 3 different "channels" that are used for remoting. They are HTTP, TCP and IPC. @@ -201,7 +201,7 @@ Any unauthorized use of a remoting application provides unauthorized access with 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 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. @@ -209,36 +209,36 @@ Microsoft specifies locating the [application].config file in the same folder as 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 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> + <formatter ref="soap" typeFilterLevel="Low" /> + <formatter ref="binary" typeFilterLevel="Low" /> +</serverProviders> -Microsoft provides 3 "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. +Microsoft provides 3 "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”/> +<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. +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. - <VulnDiscussion>Unsupported software introduces risks and violates DoD policy. Applications utilizing unsupported versions of .NET introduce substantial risk to the host, network, and the enclave by virtue of the fact they leverage an architecture that is no longer updated by the vendor. This introduces potential application integrity, availability, or confidentiality issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>COMS-1</IAControls> + <VulnDiscussion>Unsupported software introduces risks and violates DoD policy. Applications utilizing unsupported versions of .NET introduce substantial risk to the host, network, and the enclave by virtue of the fact they leverage an architecture that is no longer updated by the vendor. This introduces potential application integrity, availability, or confidentiality issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False @@ -266,32 +266,32 @@ Verify the .Net Framework support dates with Microsoft Product Lifecycle Search 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. - + If any versions of the .Net Framework are installed and support is no longer available, this is a finding. <VulnDiscussion>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. +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: +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. +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. +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. +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 <link> tag with the following syntax. <link rel="ConfigurationFileName" href="location"> -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. +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. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Web Administrator</Responsibility><IAControls>DCNR-1</IAControls> @@ -303,8 +303,8 @@ In this tag, "location" represents a URL that point to the configuration file. T Examine the .NET CLR configuration files from the vulnerability discussion to find the runtime element and then the "enforceFIPSPolicy" element. Example: -<configuration> - <runtime> +<configuration> + <runtime> <enforceFIPSPolicy enabled="true|false" /> </runtime> </configuration> @@ -313,16 +313,16 @@ 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. +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. <VulnDiscussion>CAS policy is .NET runtime version-specific. In .NET Framework version 4, CAS policy is disabled by default however; it can be re-enabled by using the NetFx40_LegacySecurityPolicy setting on a per application basis. Caspol.exe is provided by Microsoft to set security policy on .Net applications prior to version 4.0. 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). -When invoking the NetFx40_LegacySecurityPolicy setting in .NET 4, earlier versions of the .NET Framework CAS policy will become active therefore previous .NET STIG guidance that applies to the reactivated versions must also be applied. +When invoking the NetFx40_LegacySecurityPolicy setting in .NET 4, earlier versions of the .NET Framework CAS policy will become active therefore previous .NET STIG guidance that applies to the reactivated versions must also be applied. -Failure to apply applicable versions of STIG guidance can result in the loss of system confidentiality, integrity or availability. +Failure to apply applicable versions of STIG guidance can result in the loss of system confidentiality, integrity or availability. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls> False @@ -330,8 +330,8 @@ Failure to apply applicable versions of STIG guidance can result in the loss of 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, you can run the FINDSTR command from an elevated (admin) command prompt: -FINDSTR /i /s "NetFx40_LegacySecurityPolicy" c:\*.exe.config +To find relevant files, you can 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. @@ -365,7 +365,7 @@ The appropriate level of trust must be established prior to enabling the loading Search each config file found for the "loadFromRemoteSources" element. -If the loadFromRemoteSources element is enabled +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. @@ -394,15 +394,15 @@ If the "defaultProxy" element is empty then the framework is using default brows - <VulnDiscussion>With the advent of .Net 4.0, the .Net framework no longer directly configures or enforces security policy for .Net applications. This task is now relegated to the operating system layer and the security protections built-in to .Net application "runtime hosts" that run on the O.S. + <VulnDiscussion>With the advent of .Net 4.0, the .Net framework no longer directly configures or enforces security policy for .Net applications. This task is now relegated to the operating system layer and the security protections built-in to .Net application "runtime hosts" that run on the O.S. Examples of these .Net "runtime hosts" include; Internet Explorer, Windows Shell, ASP.NET, Database Engines or any other "runtime hosts" that utilize .Net and load the .Net CLR. -Security protections include utilizing runtime host security controls such as sandboxing to restrict or control application behavior as designed or required. +Security protections include utilizing runtime host security controls such as sandboxing to restrict or control application behavior as designed or required. To compensate for these design changes, Windows provides native solutions such as Software Security Policies (SSP) and Application Locker (AL) which are technologies that can be implemented via Group Policy (GPO). SSP, AL and similar third party solutions serve to restrict execution of applications, scripts and libraries based upon cryptographic hash, security zones, path and certificate values that are associated with the application files. Additionally, application developers will utilize "sandboxing" techniques within their code in order to isolate 3rd party code libraries from critical system resources. -In order to assign protections to .Net 4.0 applications, the applications must first be identified and the appropriate hosting security mechanisms configured to accomplish that task. +In order to assign protections to .Net 4.0 applications, the applications must first be identified and the appropriate hosting security mechanisms configured to accomplish that task. .Net STIG guidance cannot be applied if .Net applications are not identified and documented. The lack of an application inventory introduces confidentiality, availability and integrity vulnerabilities to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls></IAControls> @@ -414,7 +414,7 @@ In order to assign protections to .Net 4.0 applications, the applications must f Ask the system administrator to provide documentation that identifies: - Each .Net 4.0 application they run on the system. -- The .Net runtime host that invokes the application. +- The .Net runtime host that invokes the application. - The security measures employed to control application access to system resources or user access to application. 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. @@ -428,7 +428,7 @@ If the security protections have not been identified, this is a finding. - <VulnDiscussion>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. + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>DCSL-1</IAControls> @@ -438,9 +438,9 @@ Beginning with Windows Vista, ETW is enabled by default however, the .Net CLR an 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. +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 +Examine the configuration settings for <etwEnable enabled="false" />. If the "etwEnable" element is set to "true", this is not a finding. @@ -453,9 +453,9 @@ If the "etwEnable" element is set to "false" and documented approvals by the IAO .NET remoting provides the capability to build widely distributed applications. The application components may reside all on one computer or they may be spread out across the enclave. .NET client applications can make remoting calls to use objects in other processes on the same computer or on any other computer that is reachable over the network. .NET remoting can also be used to communicate with other application domains within the same process. Remoting is achieved via the exposure of endpoints that can be used to establish remote connectivity. -Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. +Normally when application code attempts to access a protected resource, a stack walk is performed to ensure that all stack frames have permission to access the resource. However, with .Net 4.0, when a call is made on a remote object, this stack walk is not performed across the remoting boundary. The .Net remoting infrastructure requires FullTrust permission to execute on either the client or the server. -Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. +Due to the fact that FullTrust permission is required, Remoting endpoints should be authenticated and encrypted in order to protect the system and the data. Microsoft provides 3 different "channels" that are used for remoting. They are HTTP, TCP and IPC. @@ -465,9 +465,9 @@ Any unauthorized use of a remoting application provides unauthorized access with False -Check the machine.config and the [application executable name].exe.config configuration files. +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 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. @@ -475,25 +475,25 @@ Microsoft specifies locating the application config file in the same folder as t 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 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> + <formatter ref="soap" typeFilterLevel="Full" /> + <formatter ref="binary" typeFilterLevel="Full" /> +</serverProviders> -Microsoft provides 3 "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. +Microsoft provides 3 "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"/> +<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. @@ -504,9 +504,9 @@ If the secure flag is not set to "true" for the TCP channel, this is a finding. - <VulnDiscussion>The "bypassTrustedAppStrongNames" setting specifies whether the bypass feature that avoids validating strong names for full-trust assemblies is enabled. By default the bypass feature is enabled in .Net 4, therefore strong names are not validated for correctness when the assembly/program is loaded. Not validating strong names provides a faster application load time but at the expense of performing certificate validation. + <VulnDiscussion>The "bypassTrustedAppStrongNames" setting specifies whether the bypass feature that avoids validating strong names for full-trust assemblies is enabled. By default the bypass feature is enabled in .Net 4, therefore strong names are not validated for correctness when the assembly/program is loaded. Not validating strong names provides a faster application load time but at the expense of performing certificate validation. -Full trust assemblies are .Net applications launched from the local host. Strong names are digital signatures tied to .Net applications/assemblies. .Net 4 considers applications installed locally to be fully trusted by default and grants these applications full permissions to access host resources. +Full trust assemblies are .Net applications launched from the local host. Strong names are digital signatures tied to .Net applications/assemblies. .Net 4 considers applications installed locally to be fully trusted by default and grants these applications full permissions to access host resources. The bypass feature applies to any assembly signed with a strong name and having the following characteristics: @@ -526,8 +526,8 @@ Not validating the certificates used to sign strong name assemblies will provide False 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. +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.