deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-16 07:17:24 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

added new topic

Browse Source
This commit is contained in:
Justin Hall 2019-03-15 14:53:04 -07:00
parent 6dbe62ed49
commit 6e95083c74
2 changed files with 77 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
windows/security/threat-protection/why-were-not-recommending-fips-mode-anymore.md
View File

@ -1,74 +0,0 @@
---
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](http://support.microsoft.com/kb/811833).
## 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](http://technet.microsoft.com/library/cc750357.aspx)
- ["System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting effects in Windows XP and in later versions of Windows](http://support.microsoft.com/kb/811833)

77
windows/security/threat-protection/windows-security-baselines/sticking-with-well-known-and-proven-solutions.md Normal file
View File

@ -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.