Merge branch 'security-blog-migration' into seccon-framework

windows/security/threat-protection/TOC.md

@@ -1019,9 +1019,16 @@
 ###### [Take ownership of files or other objects](security-policy-settings/take-ownership-of-files-or-other-objects.md)
 
 
-### [Windows security baselines](windows-security-baselines.md)
-#### [Security Compliance Toolkit](security-compliance-toolkit-10.md)
-#### [Get support](get-support-for-security-baselines.md)
+### [Windows security baselines](windows-security-baselines/windows-security-baselines.md)
+#### [Security Compliance Toolkit](windows-security-baselines/security-compliance-toolkit-10.md)
+#### [Get support](windows-security-baselines/get-support-for-security-baselines.md)
+####Windows Security Blog Posts
+##### [Sticking with Well-Known and Proven Solutions](windows-security-baselines/sticking-with-well-known-and-proven-solutions.md)
+##### [Why We’re Not Recommending "FIPS Mode" Anymore](windows-security-baselines/why-were-not-recommending-fips-mode-anymore.md)
+##### [Configuring Account Lockout](windows-security-baselines/configuring-account-lockout.md)
+##### [Blocking Remote Use of Local Accounts](windows-security-baselines/blocking-remote-use-of-local-accounts.md)
+##### [Dropping the “Untrusted Font Blocking” setting](windows-security-baselines/dropping-the-untrusted-font-blocking-setting.md)
+
 
 ### [MBSA removal and alternatives](mbsa-removal-and-guidance.md)
 

windows/security/threat-protection/windows-defender-application-control/applocker/requirements-to-use-applocker.md

@@ -12,7 +12,7 @@ manager: dansimp
 audience: ITPro
 ms.collection: M365-security-compliance
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 03/11/2019
 ---
 
 # Requirements to use AppLocker
@@ -31,14 +31,15 @@ To use AppLocker, you need:
 -   For Group Policy deployment, at least one device with the Group Policy Management Console (GPMC) or Remote Server Administration Tools (RSAT) installed to host the AppLocker rules.
 -   Devices running a supported operating system to enforce the AppLocker rules that you create.
 
->**Note:**  You can use Software Restriction Policies with AppLocker, but with some limitations. For more info, see [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md).
+>[!NOTE]
+>You can use Software Restriction Policies with AppLocker, but with some limitations. For more info, see [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md).
  
 ## Operating system requirements
 
-The following table show the on which operating systems AppLocker features are supported.
+The following table shows AppLocker features supported by different versions of Windows.
 
 | Version | Can be configured | Can be enforced | Available rules | Notes |
-| - | - | - | - | - |
+|---|---|---|---|---|
 | Windows 10| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| You can use the [AppLocker CSP](https://msdn.microsoft.com/library/windows/hardware/dn920019.aspx) to configure AppLocker policies on any edition of Windows 10 supported by Mobile Device Management (MDM). You can only manage AppLocker with Group Policy on devices running Windows 10 Enterprise, Windows 10 Education, and Windows Server 2016. |
 | Windows Server 2016<br/>Windows Server 2012 R2<br/>Windows Server 2012| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| |
 | Windows 8.1 Pro| Yes| No| N/A||
@@ -55,8 +56,7 @@ The following table show the on which operating systems AppLocker features are s
 | Windows 7 Enterprise| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
 | Windows 7 Professional| Yes| No| Executable<br/>Windows Installer<br/>Script<br/>DLL| No AppLocker rules are enforced.|
  
-
-AppLocker is not supported on versions of the Windows operating system not listed above. Software Restriction Policies can be used with those versions. However, the SRP Basic User feature is not supported on the above operating systems.
+Previous versions of Windows can use Software Restriction Policies.
 
 ## See also
 - [Administer AppLocker](administer-applocker.md)

windows/security/threat-protection/windows-security-baselines/blocking-remote-use-of-local-accounts.md

@@ -0,0 +1,74 @@
+---
+title: Blocking Remote Use of Local Accounts 
+description: Covers the issues and tradeoffs of enabling account lockout and how tightly to enforce it.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+author: aaronmar
+manager: dansimp
+audience: ITPro
+ms.collection: M365-security-compliance
+ms.topic: conceptual
+ms.date: 03/15/2019
+---
+
+# Blocking Remote Use of Local Accounts
+
+**Applies to**
+ -   Windows 10
+ -   Windows Server
+
+The use of local accounts for remote access in Active Directory environments is problematic for a number of reasons. 
+By far, the biggest problem is that when an administrative local account has the same user name and password on multiple machines, an attacker with administrative rights on one machine can easily obtain the account’s password hash from the local Security Accounts Manager (SAM) database and use it to gain administrative rights over the other machines using “pass the hash” techniques. 
+
+Our latest security guidance responds to these problems by taking advantage of new Windows features to block remote logons by local accounts. 
+Windows 8.1 and Windows Server 2012 R2 introduced two new security identifiers (SIDs), which are also defined on Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012 after installing [KB 2871997](http://support.microsoft.com/kb/2871997):
+
+- S-1-5-113: NT AUTHORITY\Local account
+- S-1-5-114: NT AUTHORITY\Local account and member of Administrators group
+
+The former SID is added to the user’s access token at the time of logon if the user account being authenticated is a local account. 
+The latter SID is also added to the token if the local account is a member of the BUILTIN\Administrators group. 
+These SIDs can grant or deny access to all local accounts or all administrative local accounts – for example, in User Rights Assignments to “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services”, as we recommend in our latest security guidance. 
+Prior to the definition of these SIDs, you would have had to explicitly name each local account to be restricted to achieve the same effect.
+
+In the initial release of the Windows 8.1 and Windows Server 2012 R2 guidance, we denied network and remote desktop logon to “Local account” (S-1-5-113) for all Windows client and server configurations, which blocks all remote access for all local accounts.
+
+We have since discovered that Failover Clustering relies on a non-administrative local account (CLIUSR) for cluster node management and that blocking its network logon access causes cluster services to fail. 
+Because the CLIUSR account is not a member of the Administrators group, replacing S-1-5-113 with S-1-5-114 in the “Deny access to this computer from the network” setting allows cluster services to work correctly while still providing protection against “pass the hash” types of attacks by denying network logon to administrative local accounts.
+
+While we could keep the guidance as it is and add a “special case” footnote for failover cluster scenarios, we will instead opt to simplify deployments and change the Windows Server 2012 R2 Member Server baseline as follows:
+
+Policy Path
+
+
+Computer Configuration\Windows Settings\Local Policies\User Rights Assignment
+
+
+Policy Name
+
+
+Deny access to this computer from the network
+
+
+Original Value
+
+
+Guests, Local account (*)
+
+
+New Value
+
+
+Guests, Local account and member of Administrators group (*)
+
+The guidance also recommends adding Domain Admins and Enterprise Admins to these restrictions except on domain controllers and dedicated admin workstations. 
+DA and EA are domain-specific and can’t be specified in generic GPO baselines.
+
+Note that this change applies only to the Member Server baseline and that the restriction on remote desktop logon is not being changed. 
+Organizations can still choose to deny network access to “Local account” for non-clustered servers.
+
+Note also that the restrictions on local accounts are intended for Active Directory domain-joined systems. 
+Non-joined, workgroup Windows computers cannot authenticate domain accounts, so if you apply restrictions against remote use of local accounts on these systems, you will be able to log on only at the console.

windows/security/threat-protection/windows-security-baselines/configuring-account-lockout.md

@@ -0,0 +1,100 @@
+---
+title: Configuring Account Lockout 
+description: Covers the issues and tradeoffs of enabling account lockout and how tightly to enforce it.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+author: aaronmar
+manager: dansimp
+audience: ITPro
+ms.collection: M365-security-compliance
+ms.topic: conceptual
+ms.date: 03/15/2019
+---
+
+# Configuring Account Lockout
+
+**Applies to**
+ -   Windows 10
+ -   Windows Server
+
+ We can recommend an ideal configuration for most of the settings in our security guidance. 
+ For example, the “Debug programs” privilege should be granted to Administrators and to no one else. 
+ For account lockout, however, there is no “one size fits all” setting, but there’s a lot of heated discussion whenever anyone tries to pick one. 
+ Ultimately, each organization must determine what best meets their own needs. 
+ This blog post tries to help by discussing the issues and tradeoffs of enabling account lockout and how tightly to enforce it. 
+ We had to pick _something_ for the baseline, so we discuss the settings we selected and why we changed them from what we had selected for other recent baselines. 
+ Again, though, this is one where you should take a close look at the threats and tradeoffs for your own environment before applying the settings we picked.
+
+## The Basics of Account Lockout
+
+The purpose of account lockout is to make it harder for password-guessing attacks to succeed. 
+If account lockout is not configured, an attacker can automate an attempt to log on with different user accounts, trying common passwords as well as every possible combination of eight or fewer characters in a very short amount of time, until one finally works. 
+When account lockout is configured, Windows locks the account after a certain number of failed logon attempts, and blocks further logon attempts even if the correct password is supplied.
+
+Windows account lockout can be configured with these three settings:
+
+- _Account lockout threshold_: the number of failed logon attempts that trigger account lockout. If set to 0, account lockout is disabled and accounts are never locked out.
+- _Account lockout duration_: the number of minutes that an account remains locked out before it’s automatically unlocked. If set to 0, the account remains locked out until an administrator explicitly unlocks it.
+- _Reset account lockout counter after_: the number of minutes after a failed logon attempt before the bad-logon counter is reset to 0. The counter is also reset after a successful logon.
+
+## Account Lockout Tradeoffs
+
+While account lockout can help prevent intrusion, it can also expose your organization to accidental lockouts as well as to denial of service attacks.
+
+Not every bad logon attempt reflects an attempt to gain unauthorized access. 
+Users sometimes forget their passwords. 
+Also, applications, particularly those that use saved passwords, are often unaware of a password change and continue to use the old password, sometimes automatically retrying the same password many times in a short amount of time. 
+This becomes increasingly true as users have more devices such as phones and tablets that log on to get email or other corpnet access. 
+If the account lockout threshold is set too low, you are likely to see a lot of accidental lockouts. 
+In addition to users not being able to perform their work, lockouts can lead to expensive helpdesk calls, especially when administrator intervention is required to unlock the account. 
+Finding the root cause of accidental lockouts can be time-consuming as well. 
+It’s therefore good to set a threshold that avoids accidental lockouts, while not setting the threshold so high that attackers are given too much opportunity to succeed. 
+Setting the lockout duration to a “reasonable” non-zero value can also reduce helpdesk calls. 
+The combination of threshold, lockout duration and reset settings determines how many guesses attackers get per day; ideally you slow them down to the point that it becomes impractical or at least not worthwhile for them to pursue this type of attack.
+
+At the same time, whenever account lockout is configured at all it is easy for an attacker to conduct a denial of service attack and deliberately lock out accounts. 
+It doesn’t matter whether you set the threshold to 5 or 50 – an automated attack can perform that many deliberately failed logon attempts on a large number of accounts very quickly and lock them out. 
+If the lockout duration is short, an attacker can still maintain a sustained attack, locking out accounts as soon as they become unlocked. 
+If the lockout duration is indefinite (0), then this can be a crippling attack.
+
+## Reducing or Eliminating the Need for Account Lockout
+
+If you employ other mitigations against password-guessing attacks, you can afford to set a higher lockout threshold or even disable account lockout altogether. 
+Some of these mitigations are:
+
+- Proactively monitor for failed logon events and have a robust response mechanism in place when password-guessing is detected.
+- Configure “Smart card required for interactive logon” (SCRIL), and do not manually set a password for the account after doing so. When SCRIL is configured, the account’s password hash is replaced with a random value, making a password logon effectively impossible. When SCRIL is configured, therefore, account lockout should be disabled to prevent denial of service.
+- Require long passwords. The entire set of eight-character passwords can be tested in a short amount of time. Windows policies allow you to set a minimum length of 14 characters, which is the setting we recommend. You can set a minimum password length greater than 14 characters by using [fine-grained password polices](https://docs.microsoft.com/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt). Passwords can be up to 256 characters
+
+## Baseline Selections
+
+As we said at the outset, there is no single account lockout configuration that works for all organizations. 
+Our recommendation regarding account lockout is to consider the tradeoffs and pick what’s right for your situation. 
+However, our security guidance includes GPOs and security templates that you can apply directly, and it’s not possible to set the account lockout threshold in them to “do the right thing”. So we have to pick something.
+
+The settings in our baselines are intended for large audiences. 
+We recognize that many organizations will apply these settings without reading the fine print or considering the nuances and tradeoffs. 
+We have to try to find the right balance between security and “break everything” that will work reasonably well for most organizations.
+
+As of Oct 15, 2015, we have selected a threshold of 10 bad attempts, a 15 minute lockout duration, and counter reset after 15 minutes. 
+That threshold value is a change from the Windows 8.1/Windows Server 2012 R2 beta guidance as well as from past baselines.
+
+The threshold we published with the Windows 7/Windows Server 2008 R2 guidance was 50 bad attempts. 
+With the 15 minute duration and 15 minute counter reset, that gave attackers up to 200 guesses per hour. 
+For Windows 8/Windows Server 2012, we had changed it to 5, after much discussion with the external security community, including the Center for Internet Security (CIS), the US National Security Agency (NSA), the US Defense Information Systems Agency (DISA) and others. The thinking at that point was that a typical user is unlikely to mistype their password five times unless they really don’t remember it, in which case they’ll probably need to call the helpdesk anyway. 
+We have increased that threshold to 10 because our support engineers have seen many accidental lockouts, particularly with the increase in devices per user. 
+Increasing the threshold to 10 should reduce the number of accidental lockouts, while at the same time not giving attackers 200 guesses per hour again.
+
+## Account Lockout Technical Errata
+
+The public documentation may not be clear about these points, and they are worth knowing:
+
+An attempted logon using either of an account’s two most recent previous passwords will not succeed, but will not increment the bad-logon counter either. 
+In other words, repeated use of a saved password will trigger account lockout only after the third password change.
+
+Failed attempts to unlock a workstation can cause account lockout even if the “Interactive logon: Require Domain Controller authentication to unlock workstation” security option is disabled. 
+Windows doesn’t need to contact a DC for an unlock if you enter the same password that you logged on with, but if you enter a different password, Windows has to contact a DC in case you had changed your password from another machine. 
+It’s actually easy to lock out an account on a locked workstation in seconds just by pressing Ctrl+Alt+Del and then holding down the Enter key.

windows/security/threat-protection/windows-security-baselines/dropping-the-untrusted-font-blocking-setting.md

@@ -0,0 +1,24 @@
+---
+title: Dropping the “Untrusted Font Blocking” setting
+description: Windows 10 includes additional mitigations that make this setting less important, and it breaks several legitimate scenarios unnecessarily.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+author: aaronmar
+manager: dansimp
+audience: ITPro
+ms.collection: M365-security-compliance
+ms.topic: conceptual
+ms.date: 03/15/2019
+---
+
+# Dropping the “Untrusted Font Blocking” setting
+
+**Applies to**
+ -   Windows 10
+ -   Windows Server
+
+ 
+

windows/security/threat-protection/windows-security-baselines/sticking-with-well-known-and-proven-solutions.md

@@ -0,0 +1,77 @@
+---
+title: Sticking with Well-Known and Proven Solutions 
+description: Using proven enterprise management technologies instead of creating and maintaining your own will increase flexibility and reduce costs.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+author: aaronmar
+manager: dansimp
+audience: ITPro
+ms.collection: M365-security-compliance
+ms.topic: conceptual
+ms.date: 03/15/2019
+---
+
+# Sticking with Well-Known and Proven Solutions
+
+**Applies to**
+ -   Windows 10
+ -   Windows Server
+
+I work with a lot of customers, and there are some problems I see over and over. 
+One problem that I've seen and been thinking about a lot lately is the way that a number of customers paint themselves into a corner through excessive customization of their environment. 
+Lately I've been making the case that they would be much better off by sticking with defaults or broadly known and well-tested configurations, and with proven enterprise solutions over home-grown tools. 
+
+First, let me make it clear that these situations generally haven't arisen from anyone's bad decisions. 
+They were reasonable choices and possibly the best options available when the decisions were first made. 
+However, desktop and application deployment, enterprise management and security guidance have evolved and matured rapidly over the past several years. 
+We know a lot today that we didn't ten years ago. 
+If your organization (like many others) is planning to migrate to Windows 10, this is a perfect opportunity to revisit those decisions. 
+I liken it to moving to a new house after living in the old one for ten years.  
+You can pack all your old dusty, broken and ill-fitting possessions into boxes, ship them to the new house, then unpack the boxes and figure out where to fit all the clutter. 
+Or you can take advantage of the opportunity to get rid of detritus and enjoy the new place.
+
+What kinds of customizations am I talking about? 
+They include but are certainly not limited to home-grown software for deploying applications and monitoring desktop configuration, enforcing non-standard file and folder locations or renaming those folders, enabling unnecessary and low-value security options, reverse-engineering and then depending on or even modifying undocumented registry data, and modifying the permissions of operating system files, folders and registry keys.
+
+These customizations usually turn out to be expensive. 
+They limit flexibility, increase the cost and complexity of managing the environment, and cause strange unexpected behaviors including patch failures. 
+Have you had any of these issues in your environment?
+
+- Every piece of software to be deployed needs custom and time-consuming repackaging that is unique to your environment.
+- Your custom management solutions don't work on Windows 10.
+- The apps you purchase don't work the way they should without additional customization.
+- Ramp-up time for new personnel takes longer than it should because they need to learn all the idiosyncrasies of your configuration.
+- Bugs occur that wouldn't occur in a default or industry-standard configuration, and it takes a long time for techs to diagnose because they don't know about the quirks or realize their impact.
+- You have home-grown tools or scripts that have an admin password embedded in them.  (This is always a bad security risk.  **Always.**)
+- Your security experts don't think they're doing their job unless they put their own personal stamp on your security configuration, as if they get paid by the tweak.
+- If the guy who manages your app deployment gets hit by a truck, you'll probably go out of business.
+- The guy who owns the custom code insists that all commercial alternatives suck and won't work in your environment.  (Perhaps you've had the sense that his ego and reality mutually agreed to separate a while ago.)
+
+Sometimes you need to write your own software, particularly for line-of-business (LOB) purposes. 
+But there is a vanishingly small need for any business to write or maintain its own desktop management or application deployment software. 
+Unlike proven enterprise solutions, home-grown software tends to take dependencies on platform-specific features such as hardcoded file paths or undocumented system behaviors and to use undocumented and unsupported interfaces and registry data, which makes it hard to move to a new platform or even a standard configuration of your existing platform. 
+They also tend not to meet the performance and scale characteristics or upgrade paths of proven products from a product group with robust testing and support organizations behind them.
+
+Consider the US Government Configuration Baseline (USGCB). 
+It includes a large set of security settings which is supposed to be mandated across the entire US Federal government. 
+If you apply them, you're applying the same settings that lots of other groups have tested and worked with.
+Setting-specific issues will generally be well-known. 
+Now consider the problem that one of my customers ran into just the other day. 
+Along with a whole raft of other non-standard security settings, their security organization had applied the IE security option, "Do not save encrypted pages to disk," which prevents content that arrived over a secure HTTPS channel from being written to disk. 
+On the face of it, doesn't that sound like a good idea? 
+Sure! 
+Enable that policy! 
+After the new policies had been in production for a while, all of a sudden people panicked. 
+It was payday, and the paystub web site was showing a blank page where it was supposed to display the user's paystub as a PDF document. 
+Naturally, fixing this high-visibility issue was immediately assigned as the top priority to a group of tech experts who had to set aside other high priority tasks. 
+Now, there are USGCB settings that are known to interfere with Adobe Acrobat Reader integration with Internet Explorer, and this is where I focused my attention. 
+That turned out to be a dead end. 
+A colleague of mine eventually took to disabling bunches of settings at a time to try to narrow down the issue, until he finally traced it to "Do not save encrypted pages to disk." 
+Because this setting is not mandated or used by the FDCC, USGCB, or any Department of Defense configurations, the symptom and root cause was not one with which we were familiar, nor would it be one that I would expect most other people would think to focus on if they had not run into the problem themselves. 
+Oh and guess what? 
+It turns out that years ago this setting was specifically excluded from the earliest revisions of the US Air Force Standard Desktop Configuration (the ancestor of the FDCC) because of problems just like this.
+
+Bottom line: if you stick with the Windows defaults wherever possible or industry-standard configurations such as the Microsoft Windows security guidance or the USGCB, and use proven enterprise management technologies instead of creating and maintaining your own, you will increase flexibility, reduce costs, and be better able to focus on your organization's real mission.

windows/security/threat-protection/windows-security-baselines/why-were-not-recommending-fips-mode-anymore.md

@@ -0,0 +1,78 @@
+---
+title: Why We’re Not Recommending "FIPS Mode" Anymore 
+description: This topic explains why Microsoft changed from recommending FIPS mode be enabled to Not Defined.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+ms.localizationpriority: medium
+author: aaronmar
+manager: dansimp
+audience: ITPro
+ms.collection: M365-security-compliance
+ms.topic: conceptual
+ms.date: 03/15/2019
+---
+
+# Why We’re Not Recommending “FIPS Mode” Anymore
+
+**Applies to**
+ -   Windows 10
+ -   Windows Server
+
+In [the latest review of the official Microsoft security baselines](https://blogs.technet.microsoft.com/b/secguide/archive/2014/04/07/security-baselines-for-windows-8-1-windows-server-2012-r2-and-internet-explorer-11.aspx) for all versions of Windows client and Windows Server, we decided to remove our earlier recommendation to enable “FIPS mode”, or more precisely, the security option called “System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.”  
+In our previous guidance we had recommended a setting of “Enabled”, primarily to align with US Federal government recommendations. 
+In our updated guidance, the recommendation is “Not Defined”, meaning that we leave the decision to customers. 
+Many people will correctly see this as a significant change, and it deserves explanation.
+
+The United States Federal Information Processing Standard (FIPS) 140 standard defines cryptographic algorithms approved for use by US Federal government computer systems for the protection of sensitive data. 
+An implementation of an approved cryptographic algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed National Institute of Standards and Technology (NIST) validation. 
+A particular implementation of an algorithm that has not been submitted cannot be considered FIPS-compliant even if it produces identical data as a validated implementation of the same algorithm. Note that the requirement to use approved and validated algorithms applies only to the protection of sensitive data. 
+Systems and applications are always free to use weak or non-validated cryptographic implementations for non-security purposes, such as in a hash table for indexing and lookup purposes.
+
+## What FIPS mode does
+Enabling FIPS mode makes Windows and its subsystems use only FIPS-validated cryptographic algorithms. 
+An example is Schannel, which is the system component that provides SSL and TLS to applications. 
+When FIPS mode is enabled, Schannel disallows SSL 2.0 and 3.0, protocols that fall short of the FIPS standards. 
+Applications such as web browsers that use Schannel then cannot connect to HTTPS web sites that don’t use at least TLS 1.0. 
+(Note that the same results can be achieved without FIPS mode by configuring Schannel according to [KB 245030](http://support.microsoft.com/kb/245030) and [this blog post](https://blogs.technet.microsoft.com/b/askds/archive/2011/05/04/speaking-in-ciphers-and-other-enigmatic-tongues.aspx).)
+
+Enabling FIPS mode also causes the .NET Framework to disallow the use of non-validated algorithms. 
+(More on this [later](#why-fips-mode-is-particularly-onerous).)
+
+A more complete listing of the effects of enabling FIPS mode can be found in [KB 811833](https://blogs.technet.microsoft.com/b/askds/archive/2011/05/04/speaking-in-ciphers-and-other-enigmatic-tongues.aspx).
+
+## What FIPS mode does not do
+Beyond the effects described above, FIPS mode is merely advisory to applications. 
+Applications that do not check or choose to ignore the registry setting associated with FIPS mode and that are not dependent on the subsystems described earlier will continue to work exactly as they had with FIPS mode disabled. 
+For example, a Win32 application−or third party disk encryption software−written in C++ that uses the very weak and non-FIPS-approved DES encryption algorithm exposed by the CryptoAPI will behave exactly the same whether FIPS mode is enabled.
+
+Further, FIPS mode does not and cannot ensure that applications even use encryption at all when appropriate. 
+There is nothing Windows can do to prevent an application from saving plaintext passwords or other sensitive data in unprotected files or registry values. 
+The bottom line here is that just because a software product works when FIPS mode is enabled does not mean that it adheres to government standards.
+
+## Why FIPS mode is particularly onerous
+Perhaps the biggest problems incurred by enabling FIPS mode involve applications that use the .NET Framework. 
+If FIPS mode is enabled, the .NET Framework disallows the use of all non-validated cryptographic classes. 
+The problem here is that the Framework offers multiple implementations of most algorithms, and not all of them have been submitted for validation, even though they are similar or identical to implementations that have been approved.
+
+For example, the .NET Framework currently provides three implementations of the SHA256 hashing algorithm: SHA256Cng, SHA256CryptoServiceProvider, and SHA256Managed. 
+The first two use “platform invoke” (a.k.a., “p/invoke”) to use Windows’ underlying implementations, which are FIPS-validated. 
+By contrast, SHA256Managed, like all the other crypto classes ending with “Managed”, is implemented strictly in .NET managed code and doesn’t use the underlying platform implementations. 
+Although it is an acceptably strong hashing algorithm for most uses, the Managed implementations have never been submitted to NIST for validation. 
+And so if an application tries to use this class and FIPS mode is enabled, the Framework will raise an exception and not allow the class to be used; this exception will almost always cause the application to fail, if not terminate immediately.
+
+Compounding the problem is that in most cases the Managed implementations of the various cryptographic algorithms have been available much longer than their Cng and CryptoServiceProvider counterparts, and on top of that, the Managed implementations tend to be significantly faster.
+
+Another significant problem with FIPS mode is that until very recently there was no NIST-approved way to derive an encryption key from a password. That blocked use of the Bitlocker Drive Encryption feature that stored a computer’s 48-character recovery password to Active Directory. Using the newer standard for password-based key derivation functions, this is no longer a problem beginning with Windows 8.1 and Windows Server 2012 R2, but it remains a problem for older versions of Windows.
+
+Finally, the .NET Framework’s enforcement of FIPS mode cannot tell whether any particular use of a cryptographic class is not for security purposes and thus not in violation of standards.
+
+## Is Microsoft contradicting government regulations?
+Government regulations may continue to mandate that FIPS mode be enabled on government computers running Windows. 
+Our updated recommendations do not contradict or conflict with government guidance: we’re not telling customers to turn it off−our recommendation is that it’s each customer’s decision to make. 
+Our updated guidance reflects our belief there is not a compelling reason for our customers that are not subject to government regulations to enable FIPS mode.
+ 
+References:
+- [FIPS 140 Evaluation](https://docs.microsoft.com/windows/security/threat-protection/fips-140-validation)
+- ["System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting effects in Windows XP and in later versions of Windows](https://support.microsoft.com/help/811833/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashi)