diff --git a/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md b/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md index 6ffb57b6a7..f6f7140989 100644 --- a/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md +++ b/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md @@ -2,87 +2,84 @@ title: Access Credential Manager as a trusted caller (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Access Credential Manager as a trusted caller security policy setting. ms.assetid: a51820d2-ca5b-47dd-8e9b-d7008603db88 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Access Credential Manager as a trusted caller + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Access Credential Manager as a trusted caller** security policy setting. + ## Reference + The **Access Credential Manager as a trusted caller** policy setting is used by Credential Manager during backup and restore. No accounts should have this privilege because it is assigned only to the Winlogon service. Saved credentials of users may be compromised if this privilege is given to other entities. + Constant: SeTrustedCredManAccessPrivilege + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + - Do not modify this policy setting from the default. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment + ### Default values -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default domain policy

Not defined

Default domain controller policy

Not defined

Stand-alone server default settings

Not defined

Domain controller effective default settings

Not defined

Member server effective default settings

Not defined

Client computer effective default settings

Not defined

+ +| Server type or GPO | Default value | +| - | - | +| Default domain policy | Not defined | +| Default domain controller policy | Not defined | +| Stand-alone server default settings | Not defined | +| Domain controller effective default settings | Not defined | +| Member server effective default settings | Not defined | +| Client computer effective default settings | Not defined |   ## Policy management + This section describes features, tools, and guidance to help you manage this policy. + A restart of the computer is not required for this policy setting to be effective. + Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. + ### Group Policy + Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: 1. Local policy settings 2. Site policy settings 3. Domain policy settings 4. OU policy settings + When a local setting is greyed out, it indicates that a GPO currently controls that setting. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + If an account is given this user right, the user of the account may create an application that calls into Credential Manager and is returned the credentials for another user. + ### Countermeasure + Do not define the **Access Credential Manager as a trusted caller** policy setting for any accounts besides Credential Manager. + ### Potential impact + None. Not defined is the default configuration. + ## Related topics [User Rights Assignment](user-rights-assignment.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/access-this-computer-from-the-network.md b/windows/keep-secure/access-this-computer-from-the-network.md index 97bf2e64a9..00a88b6ba8 100644 --- a/windows/keep-secure/access-this-computer-from-the-network.md +++ b/windows/keep-secure/access-this-computer-from-the-network.md @@ -2,96 +2,99 @@ title: Access this computer from the network (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Access this computer from the network security policy setting. ms.assetid: f6767bc2-83d1-45f1-847c-54f5362db022 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Access this computer from the network + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Access this computer from the network** security policy setting. + ## Reference + The **Access this computer from the network** policy setting determines which users can connect to the device from the network. This capability is required by a number of network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+). + Users, devices, and service accounts gain or lose the **Access this computer from network** user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers. By default, user accounts and machine accounts are granted the **Access this computer from network** user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO). + Constant: SeNetworkLogonRight + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + - On desktop devices or member servers, grant this right only to users and administrators. - On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators. - This setting includes the **Everyone** group to ensure backward compatibility. Upon Windows upgrade, after you have verified that all users and groups are correctly migrated, you should remove the **Everyone** group and use the **Authenticated Users** group instead. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment + ### Default values + The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default domain policy

Not defined

Default domain controller policy

Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access

Stand-alone server default settings

Everyone, Administrators, Users, Backup Operators

Domain controller effective default settings

Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access

Member server effective default settings

Everyone, Administrators, Users, Backup Operators

Client computer effective default settings

Everyone, Administrators, Users, Backup Operators

+ +|Server type of GPO | Default value | +| - | - | +| Default domain policy | Not defined | +| Default domain controller policy | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access | +| Stand-alone server default settings |Everyone, Administrators, Users, Backup Operators | +| Domain controller effective default settings | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access | +| Member server effective default settings | Everyone, Administrators, Users, Backup Operators | +| Client computer effective default settings |Everyone, Administrators, Users, Backup Operators |   ## Policy management + When modifying this user right, the following actions might cause users and services to experience network access issues: + - Removing the Enterprise Domain Controllers security group - Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network - Removing all user and machine accounts + A restart of the device is not required for this policy setting to be effective. + Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. + ### Group Policy + Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: + 1. Local policy settings 2. Site policy settings 3. Domain policy settings 4. OU policy settings + When a local setting is greyed out, it indicates that a GPO currently controls that setting. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the **Access this computer from the network** user right is required for users to connect to shared printers and folders. If this user right is assigned to the **Everyone** group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 do not include the **Everyone** group. However, if a device is upgraded and the original device includes the **Everyone** group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device. + ### Countermeasure -Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared from servers in the domain if members of the **Domain Users** group are included in the local **Users** group. -**Note**   -If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement. + +Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared +from servers in the domain if members of the **Domain Users** group are included in the local **Users** group. + +> **Note** If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement.   ### Potential impact + If you remove the **Access this computer from the network** user right on domain controllers for all users, no one can log on to the domain or use network resources. If you remove this user right on member servers, users cannot connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to additional accounts that are required by those components. It is important to verify that authorized users are assigned this user right for the devices that they need to access the network. + ## Related topics [User Rights Assignment](user-rights-assignment.md)   diff --git a/windows/keep-secure/account-lockout-duration.md b/windows/keep-secure/account-lockout-duration.md index 924f405c5b..9b8fd5a9f4 100644 --- a/windows/keep-secure/account-lockout-duration.md +++ b/windows/keep-secure/account-lockout-duration.md @@ -2,76 +2,69 @@ title: Account lockout duration (Windows 10) description: Describes the best practices, location, values, and security considerations for the Account lockout duration security policy setting. ms.assetid: a4167bf4-27c3-4a9b-8ef0-04e3c6ec3aa4 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Account lockout duration + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting. + ## Reference + The **Account lockout duration** policy setting determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md). This policy setting is dependent on the **Account lockout threshold** policy setting that is defined, and it must be greater than or equal to the value specified for the [Reset account lockout counter after](reset-account-lockout-counter-after.md) policy setting. + ### Possible values + - A user-defined number of minutes from 0 through 99,999 - Not defined + If [Account lockout threshold](account-lockout-threshold.md) is configured, after the specified number of failed attempts, the account will be locked out. If th **Account lockout duration** is set to 0, the account will remain locked until an administrator unlocks it manually. + It is advisable to set **Account lockout duration** to approximately 30 minutes. To specify that the account will never be locked out, set the value to 0. To configure the value for this policy setting so that it never automatically unlocks the account might seem like a good idea; however, doing so can increase the number of requests that your organization’s Help Desk receives to unlock accounts that were locked by mistake. + ### Location + **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** + ### Default values + The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or Group Policy Object (GPO)Default value

Default domain policy

Not defined

Default domain controller policy

Not defined

Stand-alone server default settings

Not applicable

Domain controller effective default settings

Not defined

Member server effective default settings

Not defined

Client computer effective default settings

Not applicable

+ +| Server type or Group Policy Object (GPO) | Default value | +| - | - | +| Default domain policy | Not defined | +| Default domain controller policy | Not defined | +| Stand-alone server default settings | Not applicable | +| Domain controller effective default settings | Not defined | +| Member server effective default settings | Not defined | +| Client computer effective default settings | Not applicable |   ## Security considerations + More than a few unsuccessful password submissions during an attempt to log on to a computer might represent an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server operating systems can track logon attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached. + ### Vulnerability + A denial-of-service (DoS) condition can be created if an attacker abuses the [Account lockout threshold](account-lockout-threshold.md) policy setting and repeatedly attempts to log on with a specific account. After you configure the Account lockout threshold policy setting, the account will be locked out after the specified number of failed attempts. If you configure the **Account lockout duration** policy setting to 0, the account remains locked until you unlock it manually. + ### Countermeasure + Configure the **Account lockout duration** policy setting to an appropriate value for your environment. To specify that the account will remain locked until you manually unlock it, configure the value to 0. When the **Account lockout duration** policy setting is configured to a nonzero value, automated attempts to guess account passwords are delayed for this interval before resuming attempts against a specific account. Using this setting in combination with the [Account lockout threshold](account-lockout-threshold.md) policy setting makes automated password guessing attempts more difficult. + ### Potential impact + Configuring the **Account lockout duration** policy setting to 0 so that accounts cannot be automatically unlocked can increase the number of requests that your organization's Help Desk receives to unlock accounts that were locked by mistake. + ## Related topics + [Account Lockout Policy](account-lockout-policy.md)     diff --git a/windows/keep-secure/account-lockout-policy.md b/windows/keep-secure/account-lockout-policy.md index b40257e0c8..edf3c1a723 100644 --- a/windows/keep-secure/account-lockout-policy.md +++ b/windows/keep-secure/account-lockout-policy.md @@ -2,47 +2,34 @@ title: Account Lockout Policy (Windows 10) description: Describes the Account Lockout Policy settings and links to information about each policy setting. ms.assetid: eb968c28-17c5-405f-b413-50728cb7b724 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Account Lockout Policy + **Applies to** - Windows 10 + Describes the Account Lockout Policy settings and links to information about each policy setting. + Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your system might be a malicious user who is attempting to determine an account password by trial and error. Windows domain controllers keep track of logon attempts, and domain controllers can be configured to respond to this type of potential attack by disabling the account for a preset period of time. Account Lockout Policy settings control the threshold for this response and the actions to be taken after the threshold is reached. The Account Lockout Policy settings can be configured in the following location in the Group Policy Management Console: **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**. + The following topics provide a discussion of each policy setting's implementation and best practices considerations, policy location, default values for the server type or Group Policy Object (GPO), relevant differences in operating system versions, and security considerations (including the possible vulnerabilities of each policy setting), countermeasures that you can implement, and the potential impact of implementing the countermeasures. + ## In this section - ---- - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Account lockout duration](account-lockout-duration.md)

Describes the best practices, location, values, and security considerations for the Account lockout duration security policy setting.

[Account lockout threshold](account-lockout-threshold.md)

Describes the best practices, location, values, and security considerations for the Account lockout threshold security policy setting.

[Reset account lockout counter after](reset-account-lockout-counter-after.md)

Describes the best practices, location, values, and security considerations for the Reset account lockout counter after security policy setting.

+ +| Topic | Description | +| - | - | +| [Account lockout duration](account-lockout-duration.md) | Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting. | +| [Account lockout threshold](account-lockout-threshold.md) | Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting. | +| [Reset account lockout counter after](reset-account-lockout-counter-after.md) | Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting. |   ## Related topics + [Configure security policy settings](how-to-configure-security-policy-settings.md)     diff --git a/windows/keep-secure/account-lockout-threshold.md b/windows/keep-secure/account-lockout-threshold.md index 8844acfdab..56fedf53b7 100644 --- a/windows/keep-secure/account-lockout-threshold.md +++ b/windows/keep-secure/account-lockout-threshold.md @@ -2,104 +2,104 @@ title: Account lockout threshold (Windows 10) description: Describes the best practices, location, values, and security considerations for the Account lockout threshold security policy setting. ms.assetid: 4904bb40-a2bd-4fef-a102-260ba8d74e30 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Account lockout threshold + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting. + ## Reference + The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account cannot be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md). + Failed password attempts on workstations or member servers that have been locked by using CTRL+ALT+DELETE or password-protected screen savers do not count as failed sign-in attempts unless [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) is set to **Enabled**. If Interactive logon: Require Domain Controller authentication to unlock workstation is enabled, repeated failed password attempts to unlock the workstation will count against the account lockout threshold. + Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the effectiveness of such attacks. However, it is important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account. + ### Possible values + It is possible to configure the following values for the **Account lockout threshold** policy setting: - A user-defined number from 0 through 999 - Not defined + Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their identified threats and the risks that they are trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this topic + ### Best practices + The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, a setting above 4 and below 10 could be an acceptable starting point for your organization. -**Important**   -Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic. +> **Important:**  Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic.   ### Location + **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy** + ### Default values + The following table lists the actual and effective default policy values. Default values are also listed on the property page for the policy setting. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or Group Policy Object (GPO)Default value

Default domain policy

0 invalid sign-in attempts

Default domain controller policy

Not defined

Stand-alone server default settings

0 invalid sign-in attempts

Domain controller effective default settings

0 invalid sign-in attempts

Member server effective default settings

0 invalid sign-in attempts

Effective GPO default settings on client computers

0 invalid sign-in attempts

+ +| Server type or Group Policy Object (GPO) | Default value | +| - | - | +| Default domain policy | 0 invalid sign-in attempts | +| Default domain controller policy | Not defined | +| Stand-alone server default settings | 0 invalid sign-in attempts | +| Domain controller effective default settings | 0 invalid sign-in attempts | +| Member server effective default settings |0 invalid sign-in attempts | +| Effective GPO default settings on client computers |0 invalid sign-in attempts |   ### Policy management + This section describes features and tools that are available to help you manage this policy setting. + ### Restart requirements + None. Changes to this policy setting become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Implementation considerations + Implementation of this policy setting is dependent on your operational environment. You should consider threat vectors, deployed operating systems, and deployed apps, for example: - The likelihood of an account theft or a DoS attack is based on the security design for your systems and environment. You should set the account lockout threshold in consideration of the known and perceived risk of those threats. - When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases. - Not all apps that are used in your environment effectively manage how many times a user can attempt to sign-in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Brute force password attacks can use automated methods to try millions of password combinations for any user account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed sign-in attempts that can be performed. However, a DoS attack could be performed on a domain that has an account lockout threshold configured. An attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker might be able to lock every account without needing any special privileges or being authenticated in the network. -**Note**   -Offline password attacks are not countered by this policy setting. + +> **Note:** Offline password attacks are not countered by this policy setting.   ### Countermeasure + Because vulnerabilities can exist when this value is configured and when it is not configured, two distinct countermeasures are defined. Organizations should weigh the choice between the two, based on their identified threats and the risks that they want to mitigate. The two countermeasure options are: - Configure the **Account lockout threshold** setting to 0. This configuration ensures that accounts will not be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because it does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met: - The password policy setting requires all users to have complex passwords of 8 or more characters. - A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment. - Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account. + A good recommendation for such a configuration is 50 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed sign-in attempts. Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems. + ### Potential impact + If this policy setting is enabled, a locked account is not usable until it is reset by an administrator or until the account lockout duration expires. Enabling this setting will likely generate a number of additional Help Desk calls. + If you configure the **Account lockout threshold** policy setting to 0, there is a possibility that an malicious user's attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place. + If you configure this policy setting to a number greater than 0, an attacker can easily lock any accounts for which the account name is known. This is especially dangerous considering that no credentials other than access to the network are necessary to lock the accounts. + ## Related topics [Account Lockout Policy](account-lockout-policy.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/account-policies.md b/windows/keep-secure/account-policies.md index af7f9913a7..487d575c7f 100644 --- a/windows/keep-secure/account-policies.md +++ b/windows/keep-secure/account-policies.md @@ -2,50 +2,33 @@ title: Account Policies (Windows 10) description: An overview of account policies in Windows and provides links to policy descriptions. ms.assetid: 711b3797-b87a-4cd9-a2e3-1f8ef18688fb -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Account Policies + **Applies to** - Windows 10 + An overview of account policies in Windows and provides links to policy descriptions. + All account policies settings applied by using Group Policy are applied at the domain level. Default values are present in the built-in default domain controller policy for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. The domain account policy becomes the default local account policy of any device that is a member of the domain. If these policies are set at any level below the domain level in Active Directory Domain Services (AD DS), they affect only local accounts on member servers. -**Note**   -Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO). +> **Note:**  Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).   The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users log on to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where neither an OU account policy nor a domain policy applies. + ## In this section - ---- - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Password Policy](password-policy.md)

An overview of password policies for Windows and links to information for each policy setting.

[Account Lockout Policy](account-lockout-policy.md)

Describes the Account Lockout Policy settings and links to information about each policy setting.

[Kerberos Policy](kerberos-policy.md)

Describes the Kerberos Policy settings and provides links to policy setting descriptions.

+ +| Topic | Description | +| - | - | +| [Password Policy](password-policy.md) | An overview of password policies for Windows and links to information for each policy setting. | +| [Account Lockout Policy](account-lockout-policy.md) | Describes the Account Lockout Policy settings and links to information about each policy setting. | +| [Kerberos Policy](kerberos-policy.md) | Describes the Kerberos Policy settings and provides links to policy setting descriptions. |   ## Related topics + [Configure security policy settings](how-to-configure-security-policy-settings.md) -  -  diff --git a/windows/keep-secure/accounts-administrator-account-status.md b/windows/keep-secure/accounts-administrator-account-status.md index 140f423d18..6c992c3bcb 100644 --- a/windows/keep-secure/accounts-administrator-account-status.md +++ b/windows/keep-secure/accounts-administrator-account-status.md @@ -2,102 +2,105 @@ title: Accounts Administrator account status (Windows 10) description: Describes the best practices, location, values, and security considerations for the Accounts Administrator account status security policy setting. ms.assetid: 71a3bd48-1014-49e0-a936-bfe9433af23e -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Accounts: Administrator account status + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting. + ## Reference + This security setting determines whether the local administrator account is enabled or disabled. + If you try to enable the administrator account after it has been disabled, and if the current administrator password does not meet the password requirements, you cannot enable the account. In this case, an alternative member of the Administrators group must reset the password on the administrator account. + If you disable this policy setting, and one of the following conditions exists on the computer, the administrator account is not disabled. 1. No other local administrator account exists 2. The administrator account is currently in use 3. All other local administrator accounts are: 1. Disabled 2. Listed in the [Deny log on locally](deny-log-on-locally.md) User Rights Assignment + If the current administrator password does not meet the password requirements, you will not be able to enable the administrator account again after it has been disabled. In this case, another member of the Administrators group must set the password on the administrator account. + ### Possible values - Enabled - Disabled - Not defined + By default, this setting is **Not defined** on domain controllers and **Enabled** on stand-alone servers. + ### Best practices + - Disabling the administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there is no other local administrator account, you must restart the computer in safe mode to fix the problem that broke your connection status. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Disabled

+ +| Server type or GPO | Default value | +| Default Domain Policy | Not defined | +| Default Domain Controller Policy |Not defined | +| Stand-Alone Server Default Settings | Enabled | +| DC Effective Default Settings | Enabled | +| Member Server Effective Default Settings | Enabled | +| Client Computer Effective Default Settings | Disabled |   ## Policy management + Disabling the administrator account can become a maintenance issue under certain circumstances. Reasons that an organization might consider disabling the built-in administrator account include: + - For some organizations, periodically changing the passwords for local accounts can be a daunting management challenge. - By default, the administrator account cannot be locked—no matter how many failed attempts to sign in a user accrues. This makes it a prime target for brute-force, password-guessing attacks. - This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This means that even if you rename the administrator account, a malicious user could start a brute-force attack by using the SID. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ### Safe mode considerations + When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-domain joined and there are no other active local administrator accounts. If the computer is joined to a domain, the disabled administrator account is not enabled. If the administrator account is disabled, you can still access the computer by using safe mode with the current administrative credentials. For example, if a failure occurs using a secure channel with a domain-joined computer, and there is no other local administrator account, you must restart the device in safe mode to fix the failure. + ### How to access a disabled Administrator account + You can use the following methods to access a disabled Administrator account: - When there is only one local administrator account that is disabled, start the device in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that computer. -- When there are local administrator accounts in addition to the built-in account, start the computer in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that device. An alternate method is to sign in to Windows by using another local Administrator account that was created. +- When there are local administrator accounts in addition to the built-in account, start the computer in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that device. An alternate method is to sign in to Windows by using another local +Administrator account that was created. - When multiple domain-joined servers have a disabled local Administrator account that can be accessed in safe mode, you can remotely run psexec by using the following command: **net user administrator /active: no**. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + The built-in administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum. + ### Countermeasure + Disable the **Accounts: Administrator account status** setting so that the built-in Administrator account cannot be used in a normal system startup. If it is very difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in administrator account instead of relying on regular password changes to protect it from attack. + ### Potential impact + Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there is no other local administrator account, you must restart in safe mode to fix the problem that caused the secure channel to fail. If the current administrator password does not meet the password requirements, you cannot enable the administrator account after it is disabled. If this situation occurs, another member of the administrators group must set the password on the administrator account. + ## Related topics + [Security Options](security-options.md) -  -  diff --git a/windows/keep-secure/accounts-block-microsoft-accounts.md b/windows/keep-secure/accounts-block-microsoft-accounts.md index 57bf409adb..a482a7a88c 100644 --- a/windows/keep-secure/accounts-block-microsoft-accounts.md +++ b/windows/keep-secure/accounts-block-microsoft-accounts.md @@ -2,85 +2,85 @@ title: Accounts Block Microsoft accounts (Windows 10) description: Describes the best practices, location, values, management, and security considerations for the Accounts Block Microsoft accounts security policy setting. ms.assetid: 94c76f45-057c-4d80-8d01-033cf28ef2f7 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Accounts: Block Microsoft accounts + **Applies to** - Windows 10 + Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting. + ## Reference -This policy setting prevents users from adding new Microsoft accounts on a device + +This policy setting prevents users from adding new Microsoft accounts on a device. + If you click the **Users can’t add Microsoft accounts** setting option, users will not be able to switch a local account to a Microsoft account, or connect a domain account to a Microsoft account to drive sync, roaming, or other background services. This is the preferred option if you need to limit the use of Microsoft accounts in your enterprise. Users will still be able to add app-specific Microsoft accounts for use with consumer apps. To block this use, turn off the ability to install consumer apps or the Store. + If you click the **Users can’t add or log on with Microsoft accounts** setting option, existing Microsoft account users will not be able to log on to Windows. Selecting this option might make it impossible for an existing administrator to log on to a computer and manage the system. + If you disable or do not configure this policy (recommended), users will be able to use Microsoft accounts with Windows. + ### Possible values - This policy is disabled - Users can’t add Microsoft accounts - Users can’t add or log on with Microsoft accounts + By default, this setting is not defined on domain controllers and disabled on stand-alone servers. + ### Best practices + - By disabling or not configuring this policy setting on the client computer, users will be able to use their Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the user to connect a local or domain account to a Microsoft account. This provides a convenient option for your users. - If you need to limit the use of Microsoft accounts in your organization, click the **Users can’t add Microsoft accounts** setting option so that users will not be able to create new Microsoft accounts on a computer, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Disabled

DC Effective Default Settings

Disabled

Member Server Effective Default Settings

Disabled

Client Computer Effective Default Settings

Disabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Not defined | +| Default Domain Controller Policy | Not defined | +| Stand-Alone Server Default Settings | Disabled | +| DC Effective Default Settings | Disabled | +| Member Server Effective Default Settings | Disabled | +| Client Computer Effective Default Settings | Disabled |   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of the countermeasure implementation. + ### Vulnerability + Although Microsoft accounts are password-protected, they also have the potential of greater exposure outside of the enterprise. Additionally, if the owner of a Microsoft account is not easily distinguishable, auditing and forensics become more difficult. + ### Countermeasure + Require only domain accounts in your enterprise by limiting the use of Microsoft accounts. Click the **Users can’t add Microsoft accounts** setting option so that users will not be able to create new Microsoft accounts on a device, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account. + ### Potential impact + Establishing greater control over accounts in your organization can give you more secure management capabilities, including procedures around password resets. + ## Related topics + [Security Options](security-options.md)     diff --git a/windows/keep-secure/accounts-guest-account-status.md b/windows/keep-secure/accounts-guest-account-status.md index 20b050727a..2e66ee3ae1 100644 --- a/windows/keep-secure/accounts-guest-account-status.md +++ b/windows/keep-secure/accounts-guest-account-status.md @@ -2,77 +2,70 @@ title: Accounts Guest account status (Windows 10) description: Describes the best practices, location, values, and security considerations for the Accounts Guest account status security policy setting. ms.assetid: 07e53fc5-b495-4d02-ab42-5b245d10d0ce -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Accounts: Guest account status + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting. + ## Reference + The **Accounts: Guest account status** policy setting determines whether the Guest account is enabled or disabled. This account allows unauthenticated network users to gain access to the system by logging on as a Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This means that any network shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This can lead to the exposure or corruption of data. + ### Possible values + - Enabled - Disabled - Not defined + ### Best practices + Set **Accounts: Guest account status** to Disabled so that the built-in Guest account is no longer usable. All network users will have to authenticate before they can access shared resources on the system. If the Guest account is disabled and [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md) is set to **Guest only**, network logons—such as those performed by the SMB Service—will fail. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Disabled

DC Effective Default Settings

Disabled

Member Server Effective Default Settings

Disabled

Client Computer Effective Default Settings

Disabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Not defined | +| Default Domain Controller Policy | Not defined | +| Stand-Alone Server Default Settings | Disabled | +| DC Effective Default Settings | Disabled | +| Member Server Effective Default Settings | Disabled | +| Client Computer Effective Default Settings | Disabled |   ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + The default Guest account allows unauthenticated network users to log on as a Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data. + ### Countermeasure + Disable the **Accounts: Guest account status** setting so that the built-in Guest account cannot be used. + ### Potential impact + All network users must be authenticated before they can access shared resources. If you disable the Guest account and the **Network Access: Sharing and Security Model** option is set to **Guest Only**, network logons, such as those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact on most organizations because it is the default setting starting with Windows Vista and Windows Server 2003. + ## Related topics + [Security Options](security-options.md)     diff --git a/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md b/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md index 4a57c0cadc..9d8ddd27c9 100644 --- a/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md +++ b/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md @@ -2,88 +2,89 @@ title: Accounts Limit local account use of blank passwords to console logon only (Windows 10) description: Describes the best practices, location, values, and security considerations for the Accounts Limit local account use of blank passwords to console logon only security policy setting. ms.assetid: a1bfb58b-1ae8-4de9-832b-aa889a6e64bd -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Accounts: Limit local account use of blank passwords to console logon only + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting. + ## Reference + The **Accounts: Limit local account use of blank passwords to console logon only** policy setting determines whether remote interactive logons by network services such as Remote Desktop Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client. + This policy setting does not affect interactive logons that are performed physically at the console or logons that use domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting. Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to log on to systems. + Devices that are not in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the device can log on by using a user account that does not have a password. This is especially important for portable devices. + If you apply this security policy to the Everyone group, no one will be able to log on through Remote Desktop Services. + ### Possible values + - Enabled - Disabled - Not defined + ### Best practices + - It is advisable to set **Accounts: Limit local account use of blank passwords to console logon only** to Enabled. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Enabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Not defined | +| Default Domain Controller Policy | Not defined | +| Stand-Alone Server Default Settings | Enabled | +| DC Effective Default Settings | Enabled | +| Member Server Effective Default Settings | Enabled | +| Client Computer Effective Default Settings | Enabled |   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ### Policy conflict considerations + The policy as distributed through the GPO takes precedence over the locally configured policy setting on a computer joined to a domain. On the domain controller, use ADSI Edit or the dsquery command to determine effective minimum password length. + ### Group Policy + This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Blank passwords are a serious threat to computer security, and they should be forbidden through organizational policy and suitable technical measures. Starting with Windows Server 2003, the default settings for Active Directory domains require complex passwords of at least seven characters, and eight characters starting with Windows Server 2008. However, if users with the ability to create new accounts bypass your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to log on. + ### Countermeasure + Enable the **Accounts: Limit local account use of blank passwords to console logon only** setting. + ### Potential impact + None. This is the default configuration. + ## Related topics [Security Options](security-options.md) -  -  diff --git a/windows/keep-secure/accounts-rename-administrator-account.md b/windows/keep-secure/accounts-rename-administrator-account.md index d8c01feedb..8873990424 100644 --- a/windows/keep-secure/accounts-rename-administrator-account.md +++ b/windows/keep-secure/accounts-rename-administrator-account.md @@ -2,86 +2,87 @@ title: Accounts Rename administrator account (Windows 10) description: This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting. ms.assetid: d21308eb-7c60-4e48-8747-62b8109844f9 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Accounts: Rename administrator account + **Applies to** - Windows 10 + This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting. + ## Reference + The **Accounts: Rename administrator account** policy setting determines whether a different account name is associated with the security identifier (SID) for the administrator account. + Because the administrator account exists on all Windows 10 for desktop editions (Home, Pro, Enterprise, and Education), renaming the account makes it slightly more difficult for attackers to guess this user name and password combination. + Rename the Administrator account by specifying a value for the **Accounts: Rename administrator account** policy setting. + ### Possible values - User-defined text - Not defined + ### Best practices - Be sure to inform users who are authorized to use this account of the new account name. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Administrator

DC Effective Default Settings

Administrator

Member Server Effective Default Settings

Administrator

Client Computer Effective Default Settings

Administrator

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Not defined | +| Default Domain Controller Policy | Not defined | +| Stand-Alone Server Default Settings | Administrator | +| DC Effective Default Settings | Administrator | +| Member Server Effective Default Settings | Administrator | +| Client Computer Effective Default Settings | Administrator |   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Policy conflict considerations + None. + ### Group Policy + This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + The Administrator account exists on all versions Windows 10 for desktop editions. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination. Beginning with Windows Vista, the person who installs the operating system specifies an account that is the first member of the Administrator group and has full rights to configure the computer so this countermeasure is applied by default on new installations. If a device is upgraded from a previous version of Windows, the account with the name administrator is retained with all the rights and privileges that were defined for the account in the previous installation. + The built-in administrator account cannot be locked out, regardless of how many times an attacker might use a bad password. This capability makes the administrator account a popular target for brute-force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. + ### Countermeasure + Specify a new name in the **Accounts: Rename administrator account** setting to rename the Administrator account. + ### Potential impact + You must provide users who are authorized to use this account with the new account name. (The guidance for this setting assumes that the Administrator account was not disabled.) + ## Related topics + [Security Options](security-options.md)     diff --git a/windows/keep-secure/accounts-rename-guest-account.md b/windows/keep-secure/accounts-rename-guest-account.md index d4c774b3ba..f82b907968 100644 --- a/windows/keep-secure/accounts-rename-guest-account.md +++ b/windows/keep-secure/accounts-rename-guest-account.md @@ -2,84 +2,86 @@ title: Accounts Rename guest account (Windows 10) description: Describes the best practices, location, values, and security considerations for the Accounts Rename guest account security policy setting. ms.assetid: 9b8052b4-bbb9-4cc1-bfee-ce25390db707 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Accounts: Rename guest account + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting. + ## Reference + The **Accounts: Rename guest account** policy setting determines whether a different account name is associated with the security identifier (SID) for the Guest account. + ### Possible values + - *User-defined text* - Guest + ### Best practices + 1. For devices in unsecured locations, renaming the account makes it more difficult for unauthorized users to guess it. 2. For computers in secured or trusted locations, keeping the name of the account as Guest provides consistency among devices + ### Location + Computer Configuration\\Windows Settings\\Security Settings + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Guest

Default Domain Controller Policy

Guest

Stand-Alone Server Default Settings

Guest

DC Effective Default Settings

Guest

Member Server Effective Default Settings

Guest

Client Computer Effective Default Settings

User-defined text

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Guest | +| Default Domain Controller Policy | Guest | +| Stand-Alone Server Default Settings | Guest | +| DC Effective Default Settings | Guest | +| Member Server Effective Default Settings | Guest | +| Client Computer Effective Default Settings | *User-defined text* |   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ### Policy conflict considerations + None. + ### Group Policy + This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability -The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges or install software that could be used for a later attack on your system. + +The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges +or install software that could be used for a later attack on your system. + ### Countermeasure + Specify a new name in the **Accounts: Rename guest account** setting to rename the Guest account. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination. + ### Potential impact + There should be little impact because the Guest account is disabled by default in Windows 2000 Server, Windows Server 2003, and Windows XP. For later operating systems, the policy is enabled with **Guest** as the default. + ## Related topics + [Security Options](security-options.md)     diff --git a/windows/keep-secure/act-as-part-of-the-operating-system.md b/windows/keep-secure/act-as-part-of-the-operating-system.md index 7d61b7524f..5d4a39d466 100644 --- a/windows/keep-secure/act-as-part-of-the-operating-system.md +++ b/windows/keep-secure/act-as-part-of-the-operating-system.md @@ -2,87 +2,82 @@ title: Act as part of the operating system (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Act as part of the operating system security policy setting. ms.assetid: c1b7e084-a9f7-4377-b678-07cc913c8b0c -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Act as part of the operating system + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Act as part of the operating system** security policy setting. + ## Reference + The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs. Constant: SeTcbPrivilege + ### Possible values - User-defined list of accounts - Not defined + ### Best practices - Do not assign this right to any user accounts. Only assign this user right to trusted users. - If a service requires this user right, configure the service to log on by using the local System account, which inherently includes this user right. Do not create a separate account and assign this user right to it. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment + ### Default values + The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default domain policy

Not defined

Default domain controller policy

Not defined

Stand-alone server default settings

Not defined

Domain controller effective default settings

Not defined

Member server effective default settings

Not defined

Client computer effective default settings

Not defined

+ +| Server type or GPO | Default value | +| - | - | +| Default domain policy | Not defined | +| Default domain controller policy| Not defined | +| Stand-alone server default settings | Not defined | +| Domain controller effective default settings | Not defined | +| Member server effective default settings | Not defined | +| Client computer effective default settings | Not defined |   ## Policy management + A restart of the device is not required for this policy setting to be effective. + Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. + ### Group Policy + Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: 1. Local policy settings 2. Site policy settings 3. Domain policy settings 4. OU policy settings + When a local setting is greyed out, it indicates that a GPO currently controls that setting. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + The **Act as part of the operating system** user right is extremely powerful. Users with this user right can take complete control of the device and erase evidence of their activities. + ### Countermeasure + Restrict the **Act as part of the operating system** user right to as few accounts as possible—it should not even be assigned to the Administrators group under typical circumstances. When a service requires this user right, configure the service to log on with the Local System account, which inherently includes this privilege. Do not create a separate account and assign this user right to it. + ### Potential impact + There should be little or no impact because the **Act as part of the operating system** user right is rarely needed by any accounts other than the Local System account. + ## Related topics [User Rights Assignment](user-rights-assignment.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md b/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md index 7c7ee70851..ee2f72275b 100644 --- a/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md +++ b/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md @@ -2,21 +2,26 @@ title: Create a Device Guard code integrity policy based on a reference device (Windows 10) description: To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device. ms.assetid: 6C94B14E-E2CE-4F6C-8939-4B375406E825 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Create a Device Guard code integrity policy based on a reference device **Applies to** - Windows 10 + To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device. + ## Create a Device Guard code integrity policy based on a reference device + To create a code integrity policy, you'll first need to create a reference image that includes the signed applications you want to run on your protected devices. For information on how to sign applications, see [Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md). -**Note**  Before creating a code integrity policy, make sure your reference device is clean of viruses and malware. +> **Note:**  Before creating a code integrity policy, make sure your reference device is clean of viruses and malware.   **To create a code integrity policy based on a reference device** + 1. On your reference device, start PowerShell as an administrator. 2. In PowerShell, initialize variables by typing: ``` syntax @@ -99,7 +104,7 @@ To create a code integrity policy, you'll first need to create a reference image ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin ``` Once you have completed these steps, the Device Guard policy binary file (DeviceGuardPolicy.bin) and original xml file (InitialScan.xml) will be available on your desktop. -**Note**  We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options. +>**Note:**  We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options.   ## Related topics [Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md) diff --git a/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md b/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md index 228813557c..f7b4350a6f 100644 --- a/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md +++ b/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md @@ -2,53 +2,69 @@ title: Update and manage Windows Defender in Windows 10 (Windows 10) description: IT professionals can manage Windows Defender on Windows 10 endpoints in their organization using Microsoft Active Directory or Windows Server Update Services (WSUS), apply updates to endpoints, and manage scans using Group Policy SettingsWindows Management Instrumentation (WMI)PowerShell. ms.assetid: 045F5BF2-87D7-4522-97E1-C1D508E063A7 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: manage ms.sitesec: library +ms.pagetype: security author: jasesso --- + # Update and manage Windows Defender in Windows 10 + **Applies to** - Windows 10 + IT professionals can manage Windows Defender on Windows 10 endpoints in their organization using Microsoft Active Directory or Windows Server Update Services (WSUS), apply updates to endpoints, and manage scans using: + - Group Policy Settings - Windows Management Instrumentation (WMI) - PowerShell + ## Manage Windows Defender endpoints through Active Directory and WSUS + All Windows 10 endpoints are installed with Windows Defender and include support for management through: - Active Directory - WSUS + You can use the Active Directory to configure the settings; Group policies can be used for centralized configuration and enforcement of many Windows Defender settings including client user interface, scan settings, and exclusions. WSUS can be used to view basic update compliance and deploy updates manually or through automatic rules. + Note that System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including: + - Settings management - Definition update management - Alerts and alert management - Reports and reporting + When you enable *Endpoint Protection* on your clients, it will install an additional management layer on Windows Defender to manage the in-box Windows Defender agent. While the client user interface will still appear as Windows Defender, the management layer for System Center Endpoint Protection or Intune will be listed in the **Add/Remove Programs** control panel, though it will appear as if the full product is installed. Learn more about managing *Endpoint Protection*: + - [Help secure Windows PCs with Endpoint Protection for Microsoft Intune](https://technet.microsoft.com/library/dn646970.aspx) - [Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/hh508760.aspx) + Read more about System Center Configuration Manager in [Introduction to Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/hh508781.aspx). -**Important**  You must be licensed to use *Endpoint Protection* to manage clients in your Configuration Manager hierarchy. +> **Important:**  You must be licensed to use *Endpoint Protection* to manage clients in your Configuration Manager hierarchy.   ## Apply updates to Windows Defender endpoints + It is important to keep Windows Defender endpoints updated to ensure they are protected. All Windows Defender updates, including General Distribution Release (GDR) updates, are now applied as operating system updates. You can manage the distribution of updates through the [Windows Server Update Services (WSUS)](https://technet.microsoft.com/windowsserver/bb332157). + ## Manage email scans in Windows Defender + You can use Windows Defender to scan email files. Malware can install itself and hide in email files, and although real-time protection offers you the best protection from email malware, you can also scan emails stored on your PC or server with Windows Defender. -**Important**  Mail scanning only applies to on-demand and scheduled scans, not on-access scans. +> **Important:**  Mail scanning only applies to on-demand and scheduled scans, not on-access scans.   Windows Defender scans Microsoft Office Outlook 2003 and older email files. We identify the file type at run-time based on the content of the file, not on location or extension. -**Note**  Scanning email files might increase the time required to complete a scan. +> **Note: **  Scanning email files might increase the time required to complete a scan.   Windows Defender can extract embedded objects within a file (attachments and archived files, for example) and scan internally. -**Note**  While Windows Defender can be configured to scan email files, it can only remediate threats detected inside certain files, for example: +> **Note:**  While Windows Defender can be configured to scan email files, it can only remediate threats detected inside certain files, for example: - DBX - MBX - MIME   You can configure Windows Defender to scan PST files used by Outlook 2003 or older versions (where the archive type is set to non-uni-code), but Windows Defender cannot remediate threats detected inside PST files. We recommend using real-time protection to protect against email malware. + If Windows Defender detects a threat inside an email, it will show you the following information to assist you in identifying the compromised email, so you can remediate the threat: - Email subject - Attachment name @@ -56,77 +72,117 @@ Email scanning in Windows Defender is turned off by default. There are three way - *Group Policy* settings - WMI - PowerShell -**Important**  There are some risks associated with scanning some Microsoft Outlook files and email messages. You can read about tips and risks associated with scanning Outlook files and email messages in the following articles: +> **Important:**  There are some risks associated with scanning some Microsoft Outlook files and email messages. You can read about tips and risks associated with scanning Outlook files and email messages in the following articles: - [Scanning Outlook files in Outlook 2013](https://technet.microsoft.com/library/dn769141.aspx#bkmk-1) - [Scanning email messages in Outlook 2013](https://technet.microsoft.com/library/dn769141.aspx#bkmk-2)   ## Use *Group Policy* settings to enable email scans + This policy setting allows you to turn on email scanning. When email scanning is enabled, the engine will parse the mailbox and mail files to analyze the mail bodies and attachments. + Turn on email scanning with the following *Group Policy* settings: 1. Open the **Group Policy Editor**. 2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**. 3. Click **Scan**. 4. Double-click **Turn on e-mail scanning**. - This will open the **Turn on e-mail scanning** window: ![turn on e-mail scanning window](images/defender-scanemailfiles.png) + + This will open the **Turn on e-mail scanning** window: + + ![turn on e-mail scanning window](images/defender-scanemailfiles.png) + 5. Select **Enabled**. 6. Click **OK** to apply changes. + ## Use WMI to disable email scans + You can write a WMI script or application to disable email scanning. Read more about [WMI in this article](https://msdn.microsoft.com/library/windows/desktop/dn439477.aspx), and read about [Windows Preference classes in this article](https://msdn.microsoft.com/library/windows/desktop/dn455323.aspx). + Use the **DisableEmailScanning** property of the **MSFT\_MpPreference** class (part of the Windows DefenderWMI provider) to enable or disable this setting: **DisableEmailScanning** Data type: **boolean** Access type: Read-only Disable email scanning. + ## Use PowerShell to enable email scans + You can also enable email scanning using the following PowerShell parameter: 1. Open PowerShell or PowerShellIntegrated Scripting Environment (ISE). 2. Type **Set-MpPreference -DisableEmailScanning $false**. + Read more about this in: - • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx) - • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx) + ## Manage archive scans in Windows Defender + You can use Windows Defender to scan archive files. Malware can install itself and hide in archive files, and although real-time protection offers you the best protection from malware, you can also scan archives stored on your PC or server with Windows Defender. -**Important**  Archive scanning only applies to on-demand and scheduled scans, not on-access scans. +> **Important:**  Archive scanning only applies to on-demand and scheduled scans, not on-access scans.   Archive scanning in Windows Defender is turned on by default. There are four ways you can manage scans through Windows Defender: - *Group Policy* settings - WMI - PowerShell - Endpoint Protection -**Note**  Scanning archive files might increase the time required to complete a scan. +> **Note:**  Scanning archive files might increase the time required to complete a scan.   If you exclude an archive file type by using the **Extensions** box, Windows Defender will not scan files with that extension (no matter what the content is), even when you have selected the **Scan archive files** check box. For example, if you exclude .rar files but there’s a .r00 file that’s actually .rar content, it will still be scanned if archive scanning is enabled. + ## Use *Group Policy* settings to enable archive scans + This policy setting allows you to turn on archive scanning. + Turn on email scanning with the following *Group Policy* settings: 1. Open the **Group Policy Editor**. 2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**. 3. Click **Scan**. 4. Double-click **Scan archive files**. - This will open the **Scan archive files** window: ![scan archive files window](images/defender-scanarchivefiles.png) + + This will open the **Scan archive files** window: + + ![scan archive files window](images/defender-scanarchivefiles.png) + 5. Select **Enabled**. 6. Click **OK** to apply changes. + There are a number of archive scan settings in the **Scan** repository you can configure through *Group Policy*, for example: -- Maximum directory depth level into which archive files are unpacked during scanning ![specify the maximum depth to scan archive files window](images/defender-scanarchivedepth.png) -- Maximum size of archive files that will be scanned ![specify the maximum size of archive files to be scanned window](images/defender-scanarchivesize.png) -- Maximum percentage CPU utilization permitted during a scan ![specify the maximum percentage od cpu utilization during a scan window](images/defender-scanarchivecpu.png) +- Maximum directory depth level into which archive files are unpacked during scanning + + ![specify the maximum depth to scan archive files window](images/defender-scanarchivedepth.png) + +- Maximum size of archive files that will be scanned + + ![specify the maximum size of archive files to be scanned window](images/defender-scanarchivesize.png) + +- Maximum percentage CPU utilization permitted during a scan + + ![specify the maximum percentage od cpu utilization during a scan window](images/defender-scanarchivecpu.png) + ## Use WMI to disable archive scans + You can write a WMI script or application to disable archive scanning. Read more about [WMI in this article](https://msdn.microsoft.com/library/windows/desktop/dn439477.aspx), and read about [Windows Preference classes in this article](https://msdn.microsoft.com/library/windows/desktop/dn455323.aspx). + Use the **DisableArchiveScanning** property of the **MSFT\_MpPreference** class (part of the Windows DefenderWMI provider) to enable or disable this setting: **DisableArchiveScanning** Data type: **boolean** Access type: Read-only Disable archive scanning. + ## Use PowerShell to enable archive scans + You can also enable archive scanning using the following PowerShell parameter: 1. Open PowerShell or PowerShellISE. 2. Type **Set-MpPreference -DisableArchiveScanning $false**. + Read more about this in: -- • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx) -- • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx) +- [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx) +- [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx) + ## Use Endpoint Protection to configure archive scans + In Endpoint Protection, you can use the advanced scanning options to configure archive scanning. For more information, see [What are advanced scanning options?](https://technet.microsoft.com/library/ff823807.aspx) + ## Related topics + [Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md) [Troubleshoot Windows Defender in Windows 10](troubleshoot-windows-defender-in-windows-10.md)   diff --git a/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md b/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md index 3c60db513e..f9af00d1cd 100644 --- a/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md +++ b/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md @@ -2,28 +2,37 @@ title: Get apps to run on Device Guard-protected devices (Windows 10) description: Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard. ms.assetid: E62B68C3-8B9F-4842-90FC-B4EE9FF8A67E -ms.pagetype: security -keywords: ["Package Inspector", "packageinspector.exe", "sign catalog file"] +keywords: Package Inspector, packageinspector.exe, sign catalog file ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Get apps to run on Device Guard-protected devices + **Applies to** - Windows 10 + Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard. Device Guard can help to protect your enterprise devices against the accidental running of malicious apps by requiring all of your apps to be signed by a trusted entity. + To use Device Guard in an enterprise, you must be able to get your existing line-of-business and Independent Software Vendor (ISV)-developed apps to run on a protected device. Unfortunately, many line-of-business apps aren't signed, and in many cases, aren't even being actively developed. Similarly, you may have unsigned software from an ISV that you want to run, or you want to run certain applications from an ISV while not trusting all applications from that ISV. As part of the Device Guard features, Windows 10 includes a new tool called Package Inspector. Package Inspector scans your unsigned apps, and creates catalog files of the installed and running binaries, which can then be signed by the Sign Tool Windows SDK utility and distributed using Group Policy so that your apps will run on Device Guard-protected devices. + ## What you need to run your apps on Device-Guard protected devices + Before you can get your apps to run on Device Guard-protected devices, you must have: + - A device running Windows 10 Enterprise, Windows 10 Education, or Windows Server 2016 Technical Preview. - Determined which unsigned apps you need to include in your catalog file. - Created a code integrity policy for use by Device Guard. - A [code signing certificate](http://go.microsoft.com/fwlink/p/?LinkId=619282), created using an internal public key infrastructure (PKI). - [SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283). A command-line tool that digitally signs files, verifies signatures in files, or time stamps files. The tool is installed in the \\Bin folder of the Microsoft Windows Software Development Kit (SDK) installation path. + ## Create a catalog file for unsigned apps + You must run Package Inspector on a device that's running a temporary Code Integrity Policy in audit mode, created explicitly for this purpose. Audit mode lets this policy catch any binaries missed by the inspection tool, but because it's audit mode, allows everything to continue running. -**Important**  This temporary policy, shouldn't be used for normal business purposes. +> **Important:**  This temporary policy, shouldn't be used for normal business purposes.   **To create a catalog file for an existing app** 1. Start PowerShell as an administrator, and create your temporary policy file by typing: @@ -63,12 +72,13 @@ You must run Package Inspector on a device that's running a temporary Code Integ   4. Copy the app installation media to your C:\\ drive, and then install and run the program. + Copying the media to your local drive helps to make sure that the installer and its related files are included in your catalog file. If you miss the install files, your Code Integrity Policy might trust the app to run, but not to install. After you've installed the app, you should check for updates. If updates happen while the app is open, you should close and restart the app to make sure everything is caught during the inspection process. - **Note**   - Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process. + + > **Note:**  Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process.   5. **Optional:** If you want to create a multi-app catalog (many apps included in a single catalog file), you can continue to run Steps 2-3 for each additional app. After you've added all of the apps you want to add, you can continue to Step 5. - **Note**  To streamline your process, we suggest: + > **Note: **  To streamline your process, we suggest: - **Actively supported and updated apps.** Create a single catalog file for each app. - **Legacy apps, non-active or not updated.** Create a single catalog file for all of your legacy apps.   @@ -142,12 +152,16 @@ The following table shows the available options for both the `scan` and `stop` c   You can add additional parameters to your catalog beyond what's listed here. For more info, see the [MakeCat](http://go.microsoft.com/fwlink/p/?LinkId=618024) topic. + ## Sign your catalog file using Sign Tool + You can sign your catalog file using Sign Tool, located in the Windows 7 or later Windows Software Development Kit (SDK) or by using the Device Guard signing portal. For details on using the Device Guard signing portal, see [Device Guard signing](http://go.microsoft.com/fwlink/p/?LinkID=698760). This process shows how to use a password-protected Personal Information Exchange (.pfx) file to sign the catalog file. -**Important**  To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority. + +> **Important:**  To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority.   **To use Sign Tool** + 1. Check that your code signing certificates have been imported into your certificate store or that they're on the file system. 2. Open SignTool.exe and sign the catalog file, based on where your certificate is stored. If you are using the PFX from a file system location: @@ -204,13 +218,18 @@ This process shows how to use a password-protected Personal Information Exchange   For more detailed info and examples using the available options, see the [SignTool.exe (Sign Tool)](http://go.microsoft.com/fwlink/p/?LinkId=618026) topic. + 3. In File Explorer, right-click your catalog file, click **Properties**, and then click the **Digital Signatures** tab to make sure your catalog file's digital signature is accurate. 4. Copy your catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} and test the file. - **Note**  For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations. -   + + >**Note:**  For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations. + ## Troubleshooting the Package Inspector + If you see "Error 1181" while stopping the Package Inspector, you'll need to increase your USN journal size and then clear all of the cached data before re-scanning the impacted apps. + You must make sure that you clear the cache by creating and setting a new temporary policy. If you reuse the same policy, the Package Inspector will fail. + **To increase your journal size** 1. Open a command-prompt window, and then type: ``` syntax @@ -218,7 +237,9 @@ You must make sure that you clear the cache by creating and setting a new tempor ``` Where the "m" value needs to be increased. We recommend that you change the value to at least 4 times the default value of m=0x2000000. 2. Re-run the failed app installation(s). + **To clear your cached data and re-scan your apps** + 1. Delete the SIPolicy.p7b file from the C:\\Windows\\System32\\CodeIntegrity\\ folder. 2. Create a new temporary Code Integrity Policy to clear all of the cached data by starting Windows Powershell as an administrator and typing: ``` syntax @@ -229,7 +250,7 @@ You must make sure that you clear the cache by creating and setting a new tempor cp .\DenyPackageInspector.bin C:\Windows\System32\SIPolicy.p7b ``` 3. Restart your device and follow the steps in the [Create a catalog file for unsigned apps](#create-a-catalog-file-for-unsigned-apps) section. + ## Related topics + [Download SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283) -  -  diff --git a/windows/keep-secure/implement-microsoft-passport-in-your-organization.md b/windows/keep-secure/implement-microsoft-passport-in-your-organization.md index de7ca83f3f..95e304939b 100644 --- a/windows/keep-secure/implement-microsoft-passport-in-your-organization.md +++ b/windows/keep-secure/implement-microsoft-passport-in-your-organization.md @@ -2,22 +2,25 @@ title: Implement Microsoft Passport in your organization (Windows 10) description: You can create a Group Policy or mobile device management (MDM) policy that will implement Microsoft Passport on devices running Windows 10. ms.assetid: 47B55221-24BE-482D-BD31-C78B22AC06D8 -ms.pagetype: security -keywords: ["identity", "PIN", "biometric", "Hello"] +keywords: identity, PIN, biometric, Hello ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- + # Implement Microsoft Passport in your organization + **Applies to** - Windows 10 - Windows 10 Mobile + You can create a Group Policy or mobile device management (MDM) policy that will implement Microsoft Passport on devices running Windows 10. -**Important**   -The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Microsoft Passport for Work** policy settings to manage PINs. +> **Important:** The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Microsoft Passport for Work** policy settings to manage PINs.   ## Group Policy settings for Passport + The following table lists the Group Policy settings that you can configure for Passport use in your workplace. These policy settings are available in **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Microsoft Passport for Work**. @@ -132,7 +135,9 @@ The following table lists the Group Policy settings that you can configure for P
+ ## MDM policy settings for Passport + The following table lists the MDM policy settings that you can configure for Passport use in your workplace. These MDM policy settings use the [PassportForWork configuration service provider (CSP)](http://go.microsoft.com/fwlink/p/?LinkId=692070). @@ -276,10 +281,12 @@ The following table lists the MDM policy settings that you can configure for Pas
+ **Note**   If policy is not configured to explicitly require letters or special characters, users will be restricted to creating a numeric PIN.   ## Prerequisites + You’ll need this software to set Microsoft Passport policies in your enterprise. @@ -339,16 +346,26 @@ You’ll need this software to set Microsoft Passport policies in your enterpris Configuration Manager and MDM provide the ability to manage Passport policy and to deploy and manage certificates protected by Passport. Azure AD provides the ability to register devices with your enterprise and to provision Passport for organization accounts. Active Directory provides the ability to authorize users and devices using keys protected by Passport if domain controllers are running Windows 10 and the Microsoft Passport provisioning service in Windows 10 AD FS. + ## Passport for BYOD + Passport can be managed on personal devices that your employees use for work purposes using MDM. On personal devices, users can create a personal Passport PIN for unlocking the device and a separate work PIN for access to work resources. The work PIN is managed using the same Passport policies that you can use to manage Passport on organization owned devices. The personal PIN is managed separately using DeviceLock policy. DeviceLock policy can be used to control length, complexity, history, and expiration requirements and can be configured using the [Policy configuration service provider](http://go.microsoft.com/fwlink/p/?LinkID=623244). + ## Related topics + [Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md) + [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md) + [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) + [Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md) + [Microsoft Passport and password changes](microsoft-passport-and-password-changes.md) + + [Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md) + [Event ID 300 - Passport successfully created](passport-event-300.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/index.md b/windows/keep-secure/index.md index 0093a7cda3..5b1c59fb81 100644 --- a/windows/keep-secure/index.md +++ b/windows/keep-secure/index.md @@ -2,83 +2,36 @@ title: Keep Windows 10 secure (Windows 10) description: Learn about keeping Windows 10 and Windows 10 Mobile secure. ms.assetid: EA559BA8-734F-41DB-A74A-D8DBF36BE920 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- # Keep Windows 10 secure + Learn about keeping Windows 10 and Windows 10 Mobile secure. + ## In this section -
---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md)

This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md).

[Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md)

To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process.

[Device Guard certification and compliance](device-guard-certification-and-compliance.md)

Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when.

[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)

In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN.

[Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md)

Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition.

[Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md)

In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with.

[Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md)

Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services.

[Protect derived domain credentials with Credential Guard](credential-guard.md)

Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets.

[Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md)

With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.

[Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md)

Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected.

[VPN profile options](vpn-profile-options.md)

Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect.

[Security technologies](security-technologies.md)

Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.

[Enterprise security guides](windows-10-enterprise-security-guides.md)

Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.

+ +| Topic | Description | +| - | - | +| [Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md) | This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md). | +| [Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md) | To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process. | +| [Device Guard certification and compliance](device-guard-certification-and-compliance.md) | Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when. | +| [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) | In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. | +| [Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md) | Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition. | +| [Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md) | In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with. | +| [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md) | Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services. | +| [Protect derived domain credentials with Credential Guard](credential-guard.md) | Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets. | +| [Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md) | With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage. | +| [Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md) | Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. | +| [VPN profile options](vpn-profile-options.md) | Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. | +| [Security technologies](security-technologies.md) | Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile. | +| [Enterprise security guides](windows-10-enterprise-security-guides.md) | Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. |   ## Related topics + [Windows 10 and Windows 10 Mobile](../index.md)     diff --git a/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md b/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md index b87cd6ac93..99bab3e2fa 100644 --- a/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md +++ b/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md @@ -2,31 +2,41 @@ title: Install digital certificates on Windows 10 Mobile (Windows 10) description: Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. ms.assetid: FF7B1BE9-41F4-44B0-A442-249B650CEE25 -ms.pagetype: security -keywords: ["S/MIME", "PFX", "SCEP"] +keywords: S/MIME, PFX, SCEP ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- + # Install digital certificates on Windows 10 Mobile + **Applies to** - Windows 10 Mobile + Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services. + Certificates in Windows 10 Mobile are primarily used for the following purposes: - To create a secure channel using Secure Sockets Layer (SSL) between a phone and a web server or service. - To authenticate a user to a reverse proxy server that is used to enable Microsoft Exchange ActiveSync (EAS) for email. - For installation and licensing of applications (from the Windows Phone Store or a custom company distribution site). + ## Install certificates using Internet Explorer + A certificate can be posted on a website and made available to users through a device-accessible URL that they can use to download the certificate. When a user accesses the page and taps the certificate, it opens on the device. The user can inspect the certificate, and if they choose to continue, the certificate is installed on the Windows 10 Mobile device. + ## Install certificates using email + The Windows 10 Mobile certificate installer supports .cer, .p7b, .pem, and .pfx files. To install certificates via email, make sure your mail filters do not block .cer files. Certificates that are sent via email appear as message attachments. When a certificate is received, a user can tap to review the contents and then tap to install the certificate. Typically, when an identity certificate is installed, the user is prompted for the password (or passphrase) that protects it. + ## Install certificates using mobile device management (MDM) + Windows 10 Mobile supports root, CA, and client certificate to be configured via MDM. Using MDM, an administrator can directly add, delete, or query root and CA certificates, and configure the device to enroll a client certificate with a certificate enrollment server that supports Simple Certificate Enrollment Protocol (SCEP). SCEP enrolled client certificates are used by Wi-Fi, VPN, email, and browser for certificate-based client authentication. An MDM server can also query and delete SCEP enrolled client certificate (including user installed certificates), or trigger a new enrollment request before the current certificate is expired. -**Warning**   -Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certificate profile to support S/MIME on Windows 10 Mobile. For instructions on creating a PFX certificate profile in Microsoft Intune, see [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=718216). +> **Warning:**  Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certificate profile to support S/MIME on Windows 10 Mobile. For instructions on creating a PFX certificate profile in Microsoft Intune, see [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=718216).   **Process of installing certificates using MDM** + 1. The MDM server generates the initial cert enroll request including challenge password, SCEP server URL, and other enrollment related parameters. 2. The policy is converted to the OMA DM request and sent to the device. 3. The trusted CA certificate is installed directly during MDM request. @@ -34,17 +44,17 @@ Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certi 5. The device generates private/public key pair. 6. The device connects to Internet facing point exposed by MDM server. 7. MDM server creates a certificate that is signed with proper CA certificate and returns it to device. - **Note**   - The device supports the pending function to allow server side to do additional verification before issuing the cert. In this case, a pending status is sent back to the device. The device will periodically contact the server, based on preconfigured retry count and retry period parameters. Retrying ends when either: + + > **Note:**  The device supports the pending function to allow server side to do additional verification before issuing the cert. In this case, a pending status is sent back to the device. The device will periodically contact the server, based on preconfigured retry count and retry period parameters. Retrying ends when either: A certificate is successfully received from the server The server returns an error The number of retries reaches the preconfigured limit   8. The cert is installed in the device. Browser, Wi-Fi, VPN, email, and other first party applications have access to this certificate. - **Note**   - If MDM requested private key being stored in Trusted Process Module (TPM) (configured during enrollment request), the private key will be saved in TPM. Note that SCEP enrolled cert protected by TPM isn’t guarded by a PIN. However, if the certificate is imported to the Passport for Work Key Storage Provider (KSP), it is guarded by the Passport PIN. + + > **Note:**  If MDM requested private key being stored in Trusted Process Module (TPM) (configured during enrollment request), the private key will be saved in TPM. Note that SCEP enrolled cert protected by TPM isn’t guarded by a PIN. However, if the certificate is imported to the Passport for Work Key Storage Provider (KSP), it is guarded by the Passport PIN.   ## Related topics + [Configure S/MIME](configure-s-mime.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md b/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md index aac4a2f380..7f4b06da3d 100644 --- a/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md +++ b/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md @@ -2,41 +2,54 @@ title: Manage identity verification using Microsoft Passport (Windows 10) description: In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. ms.assetid: 5BF09642-8CF5-4FBC-AC9A-5CA51E19387E -ms.pagetype: security -keywords: ["identity", "PIN", "biometric", "Hello"] +keywords: identity, PIN, biometric, Hello ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- # Manage identity verification using Microsoft Passport + **Applies to** - Windows 10 - Windows 10 Mobile + In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. + Passport addresses the following problems with passwords: - Passwords can be difficult to remember, and users often reuse passwords on multiple sites. - Server breaches can expose symmetric network credentials. - Passwords can be subject to [replay attacks](http://go.microsoft.com/fwlink/p/?LinkId=615673). - Users can inadvertently expose their passwords due to [phishing attacks](http://go.microsoft.com/fwlink/p/?LinkId=615674). + Passport lets users authenticate to: - a Microsoft account. - an Active Directory account. - a Microsoft Azure Active Directory (AD) account. - Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](http://go.microsoft.com/fwlink/p/?LinkId=533889) authentication + After an initial two-step verification of the user during Passport enrollment, Passport is set up on the user's device and the user is asked to set a gesture, which can be Windows Hello or a PIN. The user provides the gesture to verify their identity. Windows then uses Passport to authenticate users and help them to access protected resources and services. + As an administrator in an enterprise or educational organization, you can create policies to manage Passport use on Windows 10-based devices that connect to your organization. + ## Benefits of Microsoft Passport + Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed. You may wonder [how a PIN can help protect a device better than a password](why-a-pin-is-better-than-a-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone. Because they're stored on the server, a server breach can reveal those stored credentials. + In Windows 10, Passport replaces passwords. The Passport provisioning process creates two cryptographic keys bound to the Trusted Platform Module (TPM), if a device has a TPM, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Passport enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identify provider knows from the combination of Passport keys and gesture that this is a verified identity and provides an authentication token that allows Windows 10 to access resources and services. In addition, during the registration process, the attestation claim is produced for every identity provider to cryptographically prove that the Passport keys are tied to TPM. During registration, when the attestation claim is not presented to the identity provider, the identity provider must assume that the Passport key is created in software. + ![how authentication works in microsoft passport](images/authflow.png) + Imagine that someone is looking over your shoulder as you get money from an ATM and sees the PIN that you enter. Having that PIN won't help them access your account because they don't have your ATM card. In the same way, learning your PIN for your device doesn't allow that attacker to access your account because the PIN is local to your specific device and doesn't enable any type of authentication from any other device. Passport helps protect user identities and user credentials. Because no passwords are used, it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Passport credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are generated within isolated environments of TPMs. + Microsoft Passport also enables Windows 10 Mobile devices to be used as [a remote credential](prepare-people-to-use-microsoft-passport.md#bmk-remote) when signing into Windows 10 PCs. During the sign-in process, the Windows 10 PC can connect using Bluetooth to access Microsoft Passport on the user’s Windows 10 Mobile device. Because users carry their phone with them, Microsoft Passport makes implementing two-factor authentication across the enterprise less costly and complex than other solutions. -**Note**  Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants. +> **Note:**  Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.   ## How Microsoft Passport works: key points + - Passport credentials are based on certificate or asymmetrical key pair. Passport credentials are bound to the device, and the token that is obtained using the credential is also bound to the device. - Identify provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps Microsoft Passport's public key to a user account during the registration step. - Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. @@ -46,26 +59,45 @@ Microsoft Passport also enables Windows 10 Mobile devices to be used as [a remo - Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use separate containers for keys. Non-Microsoft identity providers can generate keys for their users in the same container as the Microsoft account; however, all keys are separated by identity providers' domains to help ensure user privacy. - Certificates are added to the Passport container and are protected by the Passport gesture. - Windows Update behavior: After a reboot is required by Windows Update, the last interactive user is automatically signed on without any user gesture and the session is locked so the user's lock screen apps can run. + ## Comparing key-based and certificate-based authentication + Passport can use either keys (hardware or software) or certificates with keys in hardware or software to confirm identity. Enterprises that have a public key infrastructure (PKI) for issuing and managing certificates can continue to use PKI in combination with Passport. Enterprises that do not use PKI or want to reduce the effort associated with managing certificates can rely on key-based credentials for Passport. + Hardware-based keys, which are generated by TPM, provide the highest level of assurance. When the TPM is manufactured, an Endorsement Key (EK) certificate is resident in the TPM. This EK certificate creates a root trust for all other keys that are generated on this TPM. EK certification is used to generate an attestation identity key (AIK) certificate issued by a Microsoft certificate authority. This AIK certificate can be used as an attestation claim to prove to identity providers that the Passport keys are generated on the same TPM. The Microsoft certificate authority (CA) generates the AIK certificate per device, per user, and per IDP to help ensure that user privacy is protected. + When identity providers such as Active Directory or Azure AD enroll a certificate in Passport, Windows 10 will support the same set of scenarios as a smart card. When the credential type is a key, only key-based trust and operations will be supported. + ## Learn more + [Introduction to Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=786649), video presentation on Microsoft Virtual Academy + [What's new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview](http://go.microsoft.com/fwlink/p/?LinkId=708533) + [Windows Hello face authentication](http://go.microsoft.com/fwlink/p/?LinkId=626024) + [Biometrics hardware guidelines](http://go.microsoft.com/fwlink/p/?LinkId=626995) + [Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!](http://go.microsoft.com/fwlink/p/?LinkId=533890) + [Windows 10: The End Game for Passwords and Credential Theft?](http://go.microsoft.com/fwlink/p/?LinkId=533891) + [Authenticating identities without passwords through Microsoft Passport](http://go.microsoft.com/fwlink/p/?LinkId=616778) + [Microsoft Passport guide](http://go.microsoft.com/fwlink/p/?LinkId=691928) + ## Related topics + [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md) + [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md) + [Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md) + [Microsoft Passport and password changes](microsoft-passport-and-password-changes.md) + [Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md) + [Event ID 300 - Passport successfully created](passport-event-300.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/microsoft-passport-and-password-changes.md b/windows/keep-secure/microsoft-passport-and-password-changes.md index e4f15fc502..4325261928 100644 --- a/windows/keep-secure/microsoft-passport-and-password-changes.md +++ b/windows/keep-secure/microsoft-passport-and-password-changes.md @@ -2,37 +2,49 @@ title: Microsoft Passport and password changes (Windows 10) description: When you set up Microsoft Passport, the PIN or biometric (Windows Hello) gesture that you use is specific to that device. ms.assetid: 83005FE4-8899-47A6-BEA9-C17CCA0B6B55 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- # Microsoft Passport and password changes + **Applies to** - Windows 10 - Windows 10 Mobile + When you set up Microsoft Passport, the PIN or biometric (Windows Hello) gesture that you use is specific to that device. You can set up Passport for the same account on multiple devices. If the PIN or biometric is configured as part of a Microsoft Passport for Work, changing the account password will not impact sign-in or unlock with these gestures since it uses a key or certificate. However, if Microsoft Passport for Work is not deployed and the password for that account changes, you must provide the new password on each device to continue to use Passport. + ## Example + Let's suppose that you have set up a PIN for your Microsoft account on **Device A**. You use your PIN to sign in on **Device A** and then change the password for your Microsoft account. Because you were using **Device A** when you changed your password, the PIN on **Device A** will continue to work with no other action on your part. + Suppose instead that you sign in on **Device B** and change your password for your Microsoft account. The next time that you try to sign in on **Device A** using your PIN, sign-in will fail because the account credentials that Passport on **Device A** knows will be outdated. -**Note**   -This example also applies to an Active Directory account when [Passport for Work is not implemented](implement-microsoft-passport-in-your-organization.md). +> **Note:**  This example also applies to an Active Directory account when [Passport for Work is not implemented](implement-microsoft-passport-in-your-organization.md).   ## How to update Passport after you change your password on another device + 1. When you try to sign in using your PIN or biometric, you will see the following message: **Your password was changed on a different device. You must sign in to this device once with your new password, and then you can sign in with your PIN.** 2. Click **OK.** 3. Click **Sign-in options**. 4. Click the **Password** button. 5. Sign in with new password. 6. The next time that you sign in, you can select **Sign-in options** and then select **PIN** to resume using your PIN. + ## Related topics + [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) + [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md) + [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md) + [Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md) + [Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md) + + [Event ID 300 - Passport successfully created](passport-event-300.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md b/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md index 839e14a630..a9483a0b56 100644 --- a/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md +++ b/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md @@ -2,22 +2,30 @@ title: Microsoft Passport errors during PIN creation (Windows 10) description: When you set up Microsoft Passport in Windows 10, you may get an error during the Create a work PIN step. ms.assetid: DFEFE22C-4FEF-4FD9-BFC4-9B419C339502 -ms.pagetype: security -keywords: ["PIN", "error", "create a work PIN"] +keywords: PIN, error, create a work PIN ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- + # Microsoft Passport errors during PIN creation + **Applies to** - Windows 10 - Windows 10 Mobile + When you set up Microsoft Passport in Windows 10, you may get an error during the **Create a work PIN** step. This topic lists some of the error codes with recommendations for mitigating the problem. If you get an error code that is not listed here, contact Microsoft Support. + ## Where is the error code? + The following image shows an example of an error during **Create a work PIN**. + ![](images/pinerror.png) + ## Error mitigations + When a user encounters an error when creating the work PIN, advise the user to try the following steps. Many errors can be mitigated by one of these steps. 1. Try to create the PIN again. Some errors are transient and resolve themselves. 2. Sign out, sign in, and try to create the PIN again. @@ -25,6 +33,7 @@ When a user encounters an error when creating the work PIN, advise the user to t 4. Unjoin the device from Azure Active Directory (Azure AD), rejoin, and then try to create the PIN again. To unjoin a desktop PC, go to **Settings** > **System** > **About** and select **Disconnect from organization**. To unjoin a device running Windows 10 Mobile, you must [reset the device](http://go.microsoft.com/fwlink/p/?LinkId=715697). 5. On mobile devices, if you are unable to setup a PIN after multiple attempts, reset your device and start over. For help on how to reset your phone go to [Reset my phone](http://go.microsoft.com/fwlink/p/?LinkId=715697). If the error occurs again, check the error code against the following table to see if there is another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance. + @@ -186,6 +195,7 @@ If the error occurs again, check the error code against the following table to s   ## Errors with unknown mitigation For errors listed in this table, contact Microsoft Support for assistance. + | Hex | Cause | |-------------|-------------------------------------------------------------------------------------------------------| | 0x80072f0c | Unknown | @@ -208,12 +218,17 @@ For errors listed in this table, contact Microsoft Support for assistance. | 0x801C03F1 | ​There is no UPN in the token | | ​0x801C044C | There is no core window for the current thread |   + ## Related topics + [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) + [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md) + [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md) + [Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md) + [Microsoft Passport and password changes](microsoft-passport-and-password-changes.md) + [Event ID 300 - Passport successfully created](passport-event-300.md) -  -  diff --git a/windows/keep-secure/microsoft-passport-guide.md b/windows/keep-secure/microsoft-passport-guide.md index 509ae5dcad..70f6296988 100644 --- a/windows/keep-secure/microsoft-passport-guide.md +++ b/windows/keep-secure/microsoft-passport-guide.md @@ -2,84 +2,131 @@ title: Microsoft Passport guide (Windows 10) description: This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system. ms.assetid: 11EA7826-DA6B-4E5C-99FB-142CC6BD9E84 -ms.pagetype: security -keywords: ["security", "credential", "password", "authentication"] +keywords: security, credential, password, authentication ms.prod: W10 ms.pagetype: security ms.mktglfcycl: plan ms.sitesec: library +ms.pagetype: security author: challum --- + # Microsoft Passport guide + **Applies to** - Windows 10 + This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system. It highlights specific capabilities of these technologies that help mitigate threats from conventional credentials and provides guidance about how to design and deploy these technologies as part of your Windows 10 rollout. + A fundamental assumption about information security is that a system can identify who’s using it. In identifying a user, the system can decide whether the user has identified himself or herself appropriately (a process known as authentication), and then determine what that properly authenticated user should be able to do (a process known as authorization). The overwhelming majority of computer systems deployed throughout the world depend on user credentials as a means of making authentication and authorization decisions, and that means that these systems depend on reusable, user-created passwords for their security. The oft-cited maxim that authentication can involve “something you know, something you have, or something you are” neatly highlights the issue: a reusable password is an authentication factor all by itself, so anyone who knows the password can impersonate the user who owns it. + ## Problems with traditional credentials + Ever since the mid-1960s, when Fernando Corbató and his team at the Massachusetts Institute of Technology championed the introduction of the password, users and administrators have had to deal with the use of passwords for user authentication and authorization. Over time, the state of the art for password storage and use has advanced somewhat (with password hashing and salt being the two most noticeable improvements), but we’re still faced with two serious problems: passwords are easy to clone and easy to steal. Implementation faults may render them insecure, and users have a hard time balancing convenience and security. + **Credential theft** + The biggest risk of passwords is simple: an attacker can steal them easily. Every place a password is entered, processed, or stored is vulnerable. For example, an attacker can steal a collection of passwords or hashes from an authentication server by eavesdropping on network traffic to an application server, by implanting malware in an application or on a device, by logging user keystrokes on a device, or by watching to see which characters a user types — and those are just the most common attack methods. One can enact more exotic attacks to steal one or many passwords. + The risk of theft is driven by the fact that the authentication factor the password represents is the password. Without additional authentication factors, the system assumes that anyone who knows the password is the authorized user. Another, related risk is that of credential replay, in which an attacker captures a valid credential by eavesdropping on an insecure network, and then replays it later to impersonate a valid user. Most authentication protocols (including Kerberos and OAuth) protect against replay attacks by including a time stamp in the credential exchange process, but that protects the token that the authentication system issues, not the password that the user provides to get the ticket in the first place. + **Credential reuse** + The common approach of using an email address as the user name makes a bad problem worse. An attacker who successfully recovers a user name–password pair from a compromised system can then try that same pair on other systems. Surprisingly often, this tactic works to allow attackers to springboard from a compromised system into other systems. The use of email addresses as user names leads to other problems, too, which we’ll explore later in this guide. + ### + **Trading convenience for complexity** Most security is a tradeoff between convenience and security: the more secure a system is, the less convenient it will typically be for users. Although system designers and implementers have a broad range of tools to make their systems more secure, users get a vote, too. When users perceive that a security mechanism gets in the way of what they want to do, they often look for ways to circumvent it. This behavior leads to an arms race of sorts, with users adopting strategies to minimize the effort required to comply with their organization’s password policies as those policies evolve. + **Password complexity** + If the major risk to passwords is that an attacker might guess them through brute-force analysis, it might seem reasonable to require users to include a broader character set in their passwords or make them longer, but as a practical matter, password length and complexity requirements have two negative side effects. First, they encourage password reuse. Estimates by [Herley, Florêncio, and van Oorschot](http://go.microsoft.com/fwlink/p/?LinkId=627392) calculate that the stronger a password is, the more likely it is to be reused. Because users put more effort into the creation and memorization of strong passwords, they are much more likely to use the same credential across multiple systems. Second, adding length or character set complexity to passwords does not necessarily make them more difficult to guess. For example, P@ssw0rd1 is nine characters long and includes uppercase and lowercase letters, numbers, and special characters, but it’s easily guessed by many of the common password-cracking tools now available on the Internet. These tools can attack passwords by using a pre-computed dictionary of common passwords, or they can start with a base word such as password, and then apply common character substitutions. A completely random eight-character password might therefore actually take longer to guess than P@ssw0rd123. + **Password expiration** + Because a reusable password is the only authentication factor in password-based systems, designers have attempted to reduce the risk of credential theft and reuse. One common method for doing so is the use of limited-lifetime passwords. Some systems allow for passwords that can be used only once, but by far the more common approach is to make passwords expire after a certain period. Limiting the useful lifetime of a password puts a cap on how long a stolen password will be useful to an attacker. This practice helps protect against cases where a long-lived password is stolen, held, and used for a long time, but it also harkens back to the time when password cracking was impractical for everyone except nation state-level attackers. A smart attacker would attempt to steal passwords rather than crack them because of the time penalty associated with password cracking. The widespread availability of commodity password-cracking tools and the massive computing power available through mechanisms such as GPU-powered crackers or distributed cloud-based cracking tools has reversed this equation so that it is often more effective for an attacker to crack a password than to try to steal it. In addition, the widespread availability of self-service [password-reset mechanisms](#password-reset) means that an attacker needs only a short window of time during which the password is valid to change the password and thus reset the validity period. Relatively few enterprise networks provide self-service password-reset mechanisms, but they are common for Internet services. In addition, many users use the secure credential store on Windows and Mac OS X systems to store valuable passwords for Internet services, so an attacker who can compromise the operating system password may be able to obtain a treasure trove of other service passwords at no cost. Finally, overly short timelines for password expiration can tempt users to make small changes in their passwords at each expiration period — for example, moving from password123 to password456 to password789. This approach reduces the work necessary to crack the password, especially if the attacker knows any of the old passwords. + ### + **Password-reset mechanisms** + To let users better manage their own passwords, some services provide a way for users to change their own password. Some implementations require users to log on with their current password, while others allow users to select the **Forgot my password** option, which sends an email to the user’s registered email address. The problem with these mechanisms is that many of them are implemented such that an attacker can exploit them. For example, an attacker who can successfully guess or steal a user’s email password can merrily request password resets for all of the victim’s other accounts, because the reset emails go to the compromised account. For this reason, most enterprise networks are configured so that only administrators can reset user passwords; for example, Active Directory supports the use of a **Password must be changed on next logon** flag so that after the administrator resets a password, the user can reset the password only after providing the administrator-set password. Some mobile device management (MDM) systems support similar functionality for mobile devices. + **User password carelessness** + An insidious problem makes these design and implementation weaknesses worse: some users just aren’t careful with their passwords. They write them down in insecure locations, choose easy-to-guess passwords, take minimal (if any) precautions against malware, or even give their passwords to other people. These users aren’t necessarily careless because they don’t care; they want to get things done, and overly stringent password length or expiration policies or too many passwords hinders them. + **Mitigate credential risks** + Given the issues described so far, it might seem obvious that reusable passwords are a security hazard. The argument is simple: adding authentication factors reduces the value of the passwords themselves, because even a successful password theft won’t let an attacker log on to a system unless he or she also has the associated additional factors. Unfortunately, this simple argument has many practical complications. Security and operating system vendors have tried to solve the problems that reusable credentials pose for decades — with limited success. The most obvious mitigation to the risks reusable passwords pose is to add one or more authentication factors. At different times over the past 30 years, different vendors have attempted to solve this problem by calling for the use of biometric identifiers (including fingerprints, iris and retina scans, and hand geometry), software-based and hardware-based tokens, physical and virtual smart cards, and voice or Short Message Service (SMS) authentication through the user’s mobile phone. A detailed description of each of these authenticators and its pros and cons is outside the scope of this guide, but no matter which authentication method you choose, core challenges have limited adoption of all Multi-Factor Authentication (MFA) solutions, including: - **Infrastructure complexity and cost.** Any system that requires the user to provide an additional authentication factor at the point of access has to have a way to collect that information. Although it’s possible to retrofit fielded hardware by adding fingerprint readers, eye scanners, smart card readers, and so on, few enterprises have been willing to take on the cost and support burden required to do so. - **Lack of standardization.** Although Microsoft included operating system–level smart card support as part of the Windows Vista operating system, smart card and reader vendors were free to continue to ship their own drivers, as were manufacturers of other authentication devices. Lack of standardization led to both application and support fragmentation, which means that it wasn’t always possible to mix and match solutions within an enterprise, even when the manufacturers of those solutions advertised them as being compatible. - **Backward compatibility.** Retrofitting already-deployed operating systems and applications to use MFA has proven an extremely difficult task. Nearly three years after its release, Microsoft Office 2013 is finally getting support for MFA. The vast majority of both commercial and custom line-of-business (LOB) applications will never be retrofitted to take advantage of any authentication system other than what the underlying operating system provides. - **User inconvenience.** Solutions that require users to obtain, keep track of, and use physical tokens are often unpopular. If users have to have a particular token for remote access or other scenarios that are supposed to make things more convenient, they tend to become quickly dissatisfied with the burden of keeping up with an additional device. This pushback is multiplied for solutions that have to be attached to computers (such as smart card readers) because such solutions introduce problems of portability, driver support, and operating system and application integration. -- **Device compatibility.** Not every hardware form factor supports every authentication method. For example, despite occasional feeble efforts from vendors, no market for mobile phone-compatible smart card readers ever emerged. So when Microsoft first implemented smart cards as an authenticator for remote network access, one key limitation was that employees could log on only from desktop or laptop computers that had smart card readers. Any authentication method that relies on additional hardware or software may run into this problem. For example, several popular “soft token” systems rely on mobile apps that run on a limited number of mobile hardware platforms. +- **Device compatibility.** Not every hardware form factor supports every authentication method. For example, despite occasional feeble efforts from vendors, no market for mobile phone-compatible smart card readers ever emerged. +So when Microsoft first implemented smart cards as an authenticator for remote network access, one key limitation was that employees could log on only from desktop or laptop computers that had smart card readers. Any authentication method that relies on additional hardware or software may run into this problem. For example, several popular “soft token” systems rely on mobile apps that run on a limited number of mobile hardware platforms. Another pesky problem has to do with institutional knowledge and maturity. Strong authentication systems are complex. They have lots of components, and they can be expensive to design, maintain, and operate. For some enterprises, the additional cost and overhead of maintaining an in-house public key infrastructure (PKI) to issue smart cards or the burden of managing add-on devices exceeds the value they perceive in having stronger authentication. This is a special case of the common problem that financial institutions face: if the cost of fraud reduction is higher than the cost of the fraud itself, it’s hard to justify the economics of better fraud-prevention measures. + ## Solve credential problems + Solving the problems that passwords pose is tricky. Tightening password policies alone won’t do it: users may just recycle, share, or write down passwords. Although user education is critical for authentication security, education alone doesn’t eliminate the problem, either. + As you’ve seen, additional authenticators won’t necessarily help if the new authentication systems add complexity, cost, or fragility. In Windows 10, Microsoft addresses these problems with two new technologies: Windows Hello and Microsoft Passport. Working together, these technologies help increase both security and user convenience: - Microsoft Passport replaces passwords with strong two-factor authentication (2FA) by verifying existing credentials and by creating a device-specific credential that a user gesture (either biometric or PIN-based) protects. This combination effectively replaces physical and virtual smart cards as well as reusable passwords for logon and access control. - Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras, and fingerprint reader hardware can be used or added to devices that don’t currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users’ Microsoft Passport credentials. + ## What is Windows Hello? + Windows Hello is the name Microsoft has given to the new biometric sign-in system built into Windows 10. Because it is built directly into the operating system, Windows Hello allows face or fingerprint identification to unlock users’ devices. Authentication happens when the user supplies his or her unique biometric identifier to access the device-specific Microsoft Passport credentials, which means that an attacker who steals the device can’t log on to it unless that attacker has the PIN. The Windows secure credential store protects biometric data on the device. By using Windows Hello to unlock a device, the authorized user gains access to all of his or her Windows experience, apps, data, websites, and services. + The Windows Hello authenticator is known as a Hello. A Hello is unique to the combination of an individual device and a specific user; it doesn’t roam among devices, isn’t shared with a server, and cannot easily be extracted from a device. If multiple users share a device, each user gets a unique Hello for that device. You can think of a Hello as a token you can use to unlock (or release) a stored credential: the Hello itself doesn’t authenticate you to an app or service, but it releases credentials that can. + At the launch of Windows 10, the operating system supported three Hello types: - **PIN.** Before you can use Windows Hello to enable biometrics on a device, you must choose a PIN as your initial Hello gesture. After you’ve set a PIN, you can add biometric gestures if you want to. You can always use the PIN gesture to release your credentials, so you can still unlock and use your device even if you can’t use your preferred biometric because of an injury or because the sensor is unavailable or not working properly. - **Facial recognition.** This type uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well. - **Fingerprint recognition.** This type uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10. Biometric data used to implement these Hello gestures is stored securely on the local device only. It doesn’t roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there’s no single collection point an attacker can compromise to steal biometric data. Breaches that expose biometrics collected and stored for other uses (such as fingerprints collected and stored for law enforcement or background check purposes) don’t pose a significant threat: an attacker who steals biometrics literally has only a template of the identifier, and that template cannot easily be converted to a form that the attacker can present to a biometric sensor. The data path for Windows Hello-compatible sensors is resistant to tampering, too, which further reduces the chance that an attacker will be able to successfully inject faked biometric data. In addition, before an attacker can even attempt to inject data into the sensor pipeline, that attacker must gain physical access to the device — and an attacker who can do that can mount several other, less difficult attacks. Windows Hello offers several major benefits. First, when combined with Microsoft Passport, it effectively solves the problems of credential theft and sharing. Because an attacker must obtain both the device and the selected biometric, it is much more difficult to gain access without the user’s knowledge. Second, the use of biometrics means that users benefit from having a simple authenticator that’s always with them: there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for signing in to all their Windows devices. Finally, in many cases, there’s nothing additional to deploy or manage to use Windows Hello (although Microsoft Passport may require additional deployment, as described later in this guide). Windows Hello support is built directly into the operating system, and users or enterprises can add compatible biometric devices to provide biometric gesture recognition, either as part of a coordinated rollout or as individual users or groups decide to add the necessary sensors. Windows Hello is part of Windows, so no additional deployment is required to start using it. + ## What is Microsoft Passport? + Windows Hello provides a robust way for a device to recognize an individual user; that addresses the first part of the path between a user and a requested service or data item. After the device has recognized the user, however, it still must authenticate the user before deciding whether to grant access to a requested resource. Microsoft Passport provides strong 2FA, fully integrated into Windows, that replaces reusable passwords with the combination of a specific device and a Hello or PIN. Microsoft Passport isn’t just a replacement for traditional 2FA systems, though. It’s conceptually similar to smart cards: authentication is performed by using cryptographic primitives instead of string comparisons, and the user’s key material is secure inside tamper-resistant hardware. Microsoft Passport doesn’t require the extra infrastructure components required for smart card deployment, either. In particular, you don’t need a PKI if you don’t currently have one. Microsoft Passport combines the major advantage of smart cards — deployment flexibility for virtual smart cards and robust security for physical smart cards — without any of their drawbacks. + Microsoft Passport offers four significant advantages over the current state of Windows authentication: it’s more flexible, it’s based on industry standards, it’s an effective risk mitigator, and it’s ready for the enterprise. Let’s look at each of these advantages in more detail. + **It’s flexible** + Microsoft Passport offers unprecedented flexibility. Although the format and use of reusable passwords are fixed, Microsoft Passport gives both administrators and users options to manage authentication. First and foremost, Microsoft Passport works with both biometric identifiers and PINs, so users’ credentials are protected even on devices that don’t support biometrics. Users can even use their phone to release their credentials instead of a PIN or biometric gesture on the main device. Microsoft Passport seamlessly takes advantage of the hardware of the devices in use; as users upgrade to newer devices, Microsoft Passport is ready to use them, and organizations can upgrade existing devices by adding biometric sensors where appropriate. Microsoft Passport offers flexibility in the datacenter, too. To deploy it, in some modes you must add Windows Server 2016 Technical Preview domain controllers to your Active Directory environment, but you don’t have to replace or remove your existing Active Directory servers — the servers required for Microsoft Passport build on and add capability to your existing infrastructure. You don’t have to change the domain or forest functional level, and you can either add on-premises servers or use Microsoft Azure Active Directory to deploy Microsoft Passport on your network. The choice of which users you should enable for Microsoft Passport use is completely up to you: you choose the policies and devices to support and which authentication factors you want users to have access to. This makes it easy to use Microsoft Passport to supplement existing smart card or token deployments by adding strong credential protection to users who don’t currently have it or to deploy Microsoft Passport in scenarios that call for extra protection for sensitive resources or systems (described in the [Design a Microsoft Passport deployment](#design) section). + **It’s standardized** + Both software vendors and enterprise customers have come to realize that proprietary identity and authentication systems are a dead end. The future lies with open, interoperable systems that allow secure authentication across a variety of devices, LOBs, and external applications and websites. To this end, a group of industry players formed the Fast IDentity Online Alliance (FIDO), a nonprofit organization intended to address the lack of interoperability among strong authentication devices as well as the problems users face when they have to create and remember multiple user names and passwords. The FIDO Alliance plans to change the nature of authentication by developing specifications that define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to securely authenticate users of online services. This new standard for security devices and browser plug ins will allow any website or cloud application to interface with a broad variety of existing and future FIDO-enabled devices that the user has for online security. For more information, see the [FIDO Alliance website](http://go.microsoft.com/fwlink/p/?LinkId=627393). + In 2013, Microsoft joined the FIDO Alliance. FIDO standards enable a universal framework that a global ecosystem delivers for a consistent and greatly improved user experience of strong passwordless authentication. The FIDO 1.0 specifications, published in December 2014, provide for two types of authentications: passwordless (known as the Universal Authentication Framework \[UAF\]) and 2nd Factor (U2F). The FIDO Alliance is working on a set of 2.0 proposals to combine the best parts of the U2F and UAF FIDO 1.0 standards. Microsoft is actively contributing to the proposals, and Windows 10 is a reference implementation of these concepts. In addition to supporting those protocols, the Windows implementation covers other aspects of the end-to-end experience that the specification does not cover, including user interface to, storage of, and protection for users’ device keys and the tokens issued after authentication; supporting administrator policies; and providing deployment tools. Microsoft expects to continue working with the FIDO Alliance as the FIDO 2.0 specification moves forward. Interoperability of FIDO products is a hallmark of FIDO authentication. Microsoft believes that bringing a FIDO solution to market will help solve a critical need for enterprises and consumers alike. + **It’s effective** + Microsoft Passport effectively mitigates two major security risks. First, by eliminating the use of reusable passwords for logon, it reduces the risk that a user’s credential will be copied or reused. On devices that support the Trusted Platform Module (TPM) standard, user key material can be stored in the user device’s TPM, which makes it more difficult for an attacker to capture the key material and reuse it. For devices that lack TPM, Microsoft Passport can encrypt and store credential data in software, but administrators can disable this feature to force a “TPM or nothing” deployment. Second, because Microsoft Passport doesn’t depend on a single, centralized server, the risk of compromise from a breach of that server is removed. Although an attacker could theoretically compromise a single device, there’s no single point of attack that an intruder can leverage to gain widespread access to the environment. + **It’s enterprise-ready** + Every edition of Windows 10 includes Microsoft Passport functionality for individual use; enterprise and personal users can take advantage of Microsoft Passport to protect their individual credentials with compatible applications and services. In addition, enterprises whose users are running Windows 10 Professional and Windows 10 Enterprise have the ability to use Microsoft Passport for Work, an enhanced version of Microsoft Passport that includes the ability to centrally manage Microsoft Passport settings for PIN strength and biometric use through Group Policy Objects (GPOs). + ## How Microsoft Passport works + To use Microsoft Passport to sign in with an identity provider (IDP), a user needs a configured device, which means that the Microsoft Passport life cycle starts when you configure a device for Microsoft Passport use. When the device is set up, its user can use the device to authenticate to services. In this section, we explore how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process. + **Register a new user or device** + A goal of Microsoft Passport is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Microsoft Passport as registration. -**Note**   -This is separate from the organizational configuration required to use Microsoft Passport with Active Directory or Azure AD; that configuration is discussed later in this guide. This configuration must be completed before users can begin to register. +> **Note:**  This is separate from the organizational configuration required to use Microsoft Passport with Active Directory or Azure AD; that configuration is discussed later in this guide. This configuration must be completed before users can begin to register.   The registration process works like this: 1. The user configures an account on the device. @@ -88,26 +135,44 @@ The registration process works like this: The IDP that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends. 3. When the user has provided the proof to the IDP, the user enables PIN authentication (Figure 1). The PIN will be associated with this particular credential. + ![figure 1](images/passport-fig1.png) + Figure 1. Set up a PIN in the **Account Settings** control panel item + When the user sets the PIN, it becomes usable immediately (Figure 2). + ![figure 2](images/passport-fig2-pinimmeduse.png) + Figure 2. When set, the PIN is immediately usable + Remember that Microsoft Passport depends on pairing a device and a credential, so the PIN chosen is associated only with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Microsoft Passport supports are: + - A user who upgrades from the Windows 8.1 operating system will log on by using his or her existing enterprise password. That triggers MFA from the IDP side; after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN. - A user who typically uses a smart card to log on will be prompted to set up a PIN the first time he or she logs on to a Windows 10 device the user has not previously logged on to. - A user who typically uses a virtual smart card to log on will be prompted to set up a PIN the first time he or she logs on to a Windows 10 device the user has not previously logged on to. + When the user has completed this process, Microsoft Passport generates a new public–private key pair on the device. The TPM generates and stores this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. The protector key securely wraps the authentication key for a specific container. Each container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys (each of which is associated with a unique gesture). Microsoft Passport also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM. + At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means he or she is able to securely log on to the device with the PIN and thus that he or she can establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using his or her PIN, and then registers the new biometric (“smile for the camera!”), after which Windows generates a unique key pair and stores it securely. Future logons can then use either the PIN or the registered biometric gestures. + **What’s a container?** + You’ll often hear the term *container* used in reference to MDM solutions. Microsoft Passport uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 supports two containers: the default container holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and the enterprise container holds credentials associated with a workplace or school account. + The enterprise container exists only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. The enterprise container contains only key data for Active Directory or Azure AD. If the enterprise container is present on a device, it’s unlocked separately from the default container, which maintains separation of data and access across personal and enterprise credentials and services. For example, a user who uses a biometric gesture to log on to a managed computer can separately unlock his or her personal container by entering a PIN when logging on to make a purchase from a website. These containers are logically separate. Organizations don’t have any control over the credentials users store in the default container, and applications that authenticate against services in the default container can’t use credentials from the enterprise container. However, individual Windows applications can use the Microsoft Passport application programming interfaces (APIs) to request access to credentials as appropriate, so that both consumer and LOB applications can be enhanced to take advantage of Microsoft Passport. + It’s important to keep in mind that there are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials Microsoft Passport stores are protected without the creation of actual containers or folders. + Each container actually contains a set of keys, some of which are used to protect other keys. Figure 3 shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container. + ![figure 3](images/passport-fig3-logicalcontainer.png) + Figure 3. Each logical container holds one or more sets of keys + Containers can contain several types of key material: + - An *authentication key*, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key. - *Virtual smart card keys* are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked. - *Secure/Multipurpose Internet Mail Extensions (S/MIME) keys and certificates*, which a certification authority (CA) generates. The keys associated with the user’s S/MIME certificate can be stored in a Microsoft Passport container so they’re available to the user whenever the container is unlocked. @@ -115,14 +180,22 @@ Containers can contain several types of key material: Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways: - The IDP key pair can be associated with an enterprise CA through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](http://go.microsoft.com/fwlink/p/?LinkId=733947). In this case, Microsoft Passport requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Microsoft Passport in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container. - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Microsoft Passport in environments that don’t have or need a PKI. + **How keys are protected** + Any time key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Microsoft Passport for Work implementation takes advantage of onboard TPM hardware to generate, store, and process keys. However, Microsoft Passport and Microsoft Passport for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the machine can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed. + Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed. + **Authentication** + When a user wants to access protected key material — perhaps to use an Internet site that requires a logon or to access protected resources on a corporate intranet — the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called *releasing the key*. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. On a personal device that’s connected to an organizational network, users will use their personal PIN or biometric to release the key; on a device joined to an on-premises or Azure AD domain, they will use the organizational PIN. This process unlocks the protector key for the primary container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container. + These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or log on to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Microsoft Passport layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Windows Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device. + The actual authentication process works like this: + 1. The client sends an empty authentication request to the IDP. (This is merely for the handshake process.) 2. The IDP returns a challenge, known as a *nonce*. 3. The device signs the nonce with the appropriate private key. @@ -131,55 +204,85 @@ The actual authentication process works like this: 6. If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key. 7. The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token. 8. The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication. + When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices. + Remote unlock, which is planned for a future release of Windows 10, builds on these scenarios by enabling seamless remote authentication from a mobile device as a second factor. For example, suppose that you’re visiting another office at your company and you need to borrow a computer there temporarily, but you don’t want to potentially expose your credentials to capture. Rather than type in your credentials, you can click **other user** on the Windows 10 logon screen, type your user name, pick the tile for remote authentication, and use an app on your phone, which you already unlocked by using its built-in facial-recognition sensors. The phone and computer are paired and handshake via Bluetooth, you type your authentication PIN on the phone, and the computer gets confirmation of your identity from the IDP. All this happens without typing a password anywhere or typing your PIN on the PC. + **The infrastructure** + Microsoft Passport depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities: - Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to devices. You can use NDES to register devices directly, Microsoft System Center Configuration Manager Technical Preview or later for on-premises environments, or Microsoft Intune where it’s available to manage mobile device participation in Microsoft Passport. - You can configure Windows Server 2016 Technical Preview domain controllers to act as IDPs for Microsoft Passport. In this mode, the Windows Server 2016 Technical Preview domain controllers act as IDPs alongside any existing Windows Server 2008 R2 or later domain controllers. There is no requirement to replace all existing domain controllers, merely to introduce at least one Windows Server 2016 Technical Preview domain controller per Active Directory site and update the forest Active Directory Domain Services (AD DS) schema to Windows Server 2016 Technical Preview. - The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Microsoft Passport IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 Technical Preview domain controllers required. - Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides. In addition to the IDP, Microsoft Passport requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises System Center Configuration Manager deployment that meets the system requirements described in the [Deployment requirements](#deployreq) section of this document. + ## Design a Microsoft Passport for Work deployment + Microsoft Passport for Work is designed for integration with your existing and future directory infrastructure and device deployments, but this flexibility means there are many considerations to think about when you design your deployment. Some of these decisions are technical, while others are organizational or even political. In this section, we examine the key points where you have to make decisions about how to implement Microsoft Passport for Work. Remember, individual devices can use the individual version of Microsoft Passport without any infrastructure changes on your part. Microsoft Passport for Work allows you to control and centrally manage user authentication and device registration. To use the initial version of Microsoft Passport for Work, each device must have an Azure AD identity, so automatic registration of devices provides a means both to register new devices and to apply optional policies to manage Microsoft Passport for Work. + **One deployment strategy** + Different organizations will necessarily take different approaches to the deployment of Microsoft Passport depending on their capabilities and needs, but there is only one strategy: deploy Microsoft Passport for Work throughout the organization to get maximum protection for the maximum number of devices and resources. Organizations can take one of three basic routes to accomplish that strategy: + - Deploy Microsoft Passport for Work everywhere according to whatever device or user deployment strategy works best for the organization. - Deploy Microsoft Passport for Work first to high-value or high-risk targets, by using conditional access policies to restrict access to key resources only to users who hold strong authentication credentials. - Blend Microsoft Passport for Work into an existing multi-factor environment, using it as an additional form of strong authentication alongside physical or virtual smart cards. + **Deploy Microsoft Passport for Work everywhere** + In this approach, you deploy Microsoft Passport throughout the organization in a coordinated rollout. In some ways, this method is similar to any other desktop deployment project; the only real difference is that you must already have the Microsoft Passport infrastructure in place to support device registration before you can start using Microsoft Passport on Windows 10 devices. -**Note**   -You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Microsoft Passport for Work on a device until the device joins Azure AD and receives the appropriate policy. + +> **Note:**  You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Microsoft Passport for Work on a device until the device joins Azure AD and receives the appropriate policy.   The major benefit of this approach is that it provides uniform protection for all parts of the organization. Sophisticated attackers have shown a great deal of skill in breaching large organizations by identifying weak points in their security, including users and systems that don’t have high-value information but that can be exploited to get it. Applying consistent protection across every device that an attacker could use to access enterprise data is excellent protection against these types of attacks. + The downside to this approach is its complexity. Smaller organizations may find that managing the rollout of a new operating system across all devices is beyond the scope of their experience and capability. For these organizations, users can self-upgrade, and new users may end up with Windows 10 because they get new devices when they join. Larger organizations, especially those that are highly decentralized or have operations across many physical sites, may have more deployment knowledge and resources but face the challenge of coordinating rollout efforts across a larger user base and footprint. + For more information about desktop deployment of Windows 10, visit the [Windows 10 TechCenter](http://go.microsoft.com/fwlink/p/?LinkId=626581). + One key aspect of this deployment strategy is how to get Windows 10 in users’ hands. Because different organizations have wildly differing strategies to refresh hardware and software, there’s no one-size-fits-all strategy. For example, some organizations pursue a coordinated strategy that puts new desktop operating systems in users’ hands every 2–3 years on existing hardware, supplementing with new hardware only where and when required. Others tend to replace hardware and deploy whatever version of the Windows client operating system ships on the purchased devices. In both cases, there are typically separate deployment cycles for servers and server operating systems, and the desktop and server cycles may or may not be coordinated. + In addition to the issue of Windows 10 deployment to users, you must consider how and when (or if!) you’ll deploy biometric devices to users. Because Windows Hello can take advantage of multiple biometric identifiers, you have a flexible range of device options, which includes the purchase of new devices that incorporate your selected biometric, seeding select users with appropriate devices, rollout of biometric devices as part of a scheduled hardware refresh and using PIN gestures until users get devices, or relying on remote unlock as a second authentication factor. + **Deploy to high-value or high-risk targets** + This strategy takes into account the fact that in most networks, not every asset is equally protected or equally valuable. There are two ways to think about this. One is that you can focus on protecting the users and services that are most at risk of compromise because of their value. Examples include sensitive internal databases or the user accounts of your key executives. The other option is that you can focus on areas of your network that are the most vulnerable, such as users who travel frequently (and thus run a higher risk of lost or stolen devices or drive-by credential theft). Either way, the strategy is the same: selectively and quickly deploy Microsoft Passport to protect specific people and resources. For example, you might issue new Windows 10 devices with biometric sensors to all users who need access to a sensitive internal database, and then deploy the minimum required infrastructure to support Microsoft Passport–secured access to that database for those users. + One of the key design capabilities of Microsoft Passport for Work is that it supports Bring Your Own Device (BYOD) environments by allowing users to register their own devices with the organizational IDP (whether on premises, hybrid, or Azure AD). You may be able to take advantage of this capability to quickly deploy Microsoft Passport to protect your most vulnerable users or assets, ideally by using biometrics as an additional safety measure for the most valuable potential targets. + **Blend Microsoft Passport with your infrastructure** + Organizations that have already invested in smart cards, virtual smart cards, or token-based systems can still benefit from Microsoft Passport. Of those organizations, many use physical tokens and smart cards to protect only critical assets because of the expense and complexity of their deployment. Microsoft Passport offers a valuable complement to these systems because it protects users who currently rely on reusable credentials; protection of all users’ credentials is an important step toward blunting attacks that seek to leverage compromise of any credential into a widespread breach. This approach also gives you a great deal of flexibility in scheduling and deployment. Some enterprises have deployed multi-use smart cards that provide building-access control, access to copiers or other office equipment, stored value for lunchroom purchases, remote network access, and other services. Deployment of Microsoft Passport in such environments doesn’t prevent you from continuing to use smart cards for these services. You can leave the existing smart card infrastructure in place for its existing use cases, and then register desktop and mobile devices in Microsoft Passport and use Microsoft Passport to secure access to network and Internet resources. This approach requires a more complicated infrastructure and a greater degree of organizational maturity because it requires you to link your existing PKI with an enrollment service and Microsoft Passport itself. + Smart cards can act as a useful complement to Microsoft Passport in another important way: to bootstrap the initial logon for Microsoft Passport registration. When a user registers with Microsoft Passport on a device, part of that registration process requires a conventional logon. Rather than using a traditional password, organizations that have previously deployed the necessary infrastructure for smart cards or virtual smart cards can allow their users to register new devices by logging on with a smart card or virtual smart card. After the user has proved his or her identity to the organizational IDP with the smart card, the user can set up a PIN and proceed to use Microsoft Passport for future logons. + **Choose a rollout method** + Which rollout method you choose depends on several factors: + - **How many devices you need to deploy.** This number has a huge influence on your overall deployment. A global rollout for 75,000 users has different requirements than a phased rollout for groups of 200–300 users in different cities. - **How quickly you want to deploy Microsoft Passport for Work protection.** This is a classic cost–benefit tradeoff. You have to balance the security benefits of Microsoft Passport for Work against the cost and time required to deploy it broadly, and different organizations may make entirely different decisions depending on how they rate the costs and benefits involved. Getting the broadest possible Microsoft Passport coverage in the shortest time possible maximizes security benefits. - **The type of devices you want to deploy.** Windows device manufacturers are aggressively introducing new devices optimized for Windows 10, leading to the possibility that you might deploy Microsoft Passport first on newly purchased tablets and portable devices, and then deploy it on the desktop as part of your normal refresh cycle. - **What your current infrastructure looks like.** The individual version of Microsoft Passport doesn’t require changes to your Active Directory environment, but to support Microsoft Passport for Work, you may need a compatible MDM system. Depending on the size and composition of your network, mobile enrollment and management services deployment may be a major project in its own right. - **Your plans for the cloud.** If you’re already planning a move to the cloud, Azure AD eases the process of Microsoft Passport for Work deployment, because you can use Azure AD as an IDP alongside your existing on-premises AD DS setup without making significant changes to your on-premises environment. Future versions of Microsoft Passport for Work will support the ability to simultaneously register devices that are already members of an on-premises AD DS domain in an Azure AD partition so that they use Microsoft Passport for Work from the cloud. Hybrid deployments that combine AD DS with Azure AD give you the ability to keep machine authentication and policy management against your local AD DS domain while providing the full set of Microsoft Passport for Work services (and Microsoft Office 365 integration) for your users. If you plan to use on-premises AD DS only, then the design and configuration of your on-premises environment will dictate what kind of changes you may need to make. + ### + **Deployment requirements** + Table 1 lists six scenarios for deployment of Microsoft Passport for Work in the enterprise. The initial release of Windows 10 supports Azure AD–only scenarios, with support for on-premises Microsoft Passport for Work planned for a future release (see the [Roadmap](#roadmap) section for more details). + Depending on the scenario you choose, Microsoft Passport for Work deployment may require four elements: + - An organizational IDP that supports Microsoft Passport. This can be Azure AD or a set of on-premises Windows Server 2016 Technical Preview domain controllers in an existing AD DS forest. Using Azure AD means that you can establish hybrid identity management, with Azure AD acting as a Microsoft Passport IDP and your on-premises AD DS environment handling older authentication requests. This approach provides all the flexibility of Azure AD with the ability to manage computer accounts and devices running older versions of Windows and on-premises applications such as Microsoft Exchange Server or Microsoft SharePoint. - If you use certificates, an MDM system is required to allow policy management of Microsoft Passport for Work. Domain-joined devices in on-premises or hybrid deployments require Configuration Manager Technical Preview or later. Deployments with Azure AD must use either Intune or a compatible non-Microsoft MDM solution. - On-premises deployments require the forthcoming Active Directory Federation Services (AD FS) version included in Windows Server 2016 Technical Preview to support provisioning of Microsoft Passport credentials to devices. In this scenario, AD FS takes the place of the provisioning that Azure AD performs in cloud-based deployments. - Certificate-based Microsoft Passport deployments require a PKI, including CAs that are accessible to all devices that need to register. If you deploy certificate-based Microsoft Passport on premises, you don’t actually need Windows Server 2016 Technical Preview domain controllers. On-premises deployments do need to apply the Windows Server 2016 Technical Preview AD DS schema and have the Windows Server 2016 Technical Preview version of AD FS installed. Table 1. Deployment requirements for Microsoft Passport +
@@ -230,42 +333,55 @@ Table 1. Deployment requirements for Microsoft Passport Note that the current release of Windows 10 supports the Azure AD–only (RTM) and hybrid scenarios (RTM + November Update). Microsoft provides the forward-looking guidance in Table 1 to help organizations prepare their environments for planned future releases of Microsoft Passport for Work capabilities. **Select policy settings** + Another key aspect of Microsoft Passport for Work deployment involves the choice of which policy settings to apply to the enterprise. There are two parts to this choice: which policies you deploy to manage Microsoft Passport itself and which policies you deploy to control device management and registration. A complete guide to selecting effective policies is beyond the scope of this guide, but one example reference that may be useful is [Mobile device management capabilities in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=733877). + ## Implement Microsoft Passport + No configuration is necessary to use Windows Hello or Microsoft Passport on individual user devices if those users just want to protect their personal credentials. Unless the enterprise disables the feature, users have the option to use Microsoft Passport for their personal credentials, even on devices that are registered with an organizational IDP. However, when you make Microsoft Passport for Work available for users, you must add the necessary components to your infrastructure, as described earlier in the [Deployment requirements](#deployreq) section. + **How to use Azure AD** + There are three scenarios for using Microsoft Passport for Work in Azure AD–only organizations: - **Organizations that use the version of Azure AD included with Office 365.** For these organizations, no additional work is necessary. When Windows 10 was released to general availability, Microsoft changed the behavior of the Office 365 Azure AD stack. When a user selects the option to join a work or school network (Figure 4), the device is automatically joined to the Office 365 tenant’s directory partition, a certificate is issued for the device, and it becomes eligible for Office 365 MDM if the tenant has subscribed to that feature. In addition, the user will be prompted to log on and, if MFA is enabled, to enter an MFA proof that Azure AD sends to his or her phone. - **Organizations that use the free tier of Azure AD.** For these organizations, Microsoft has not enabled automatic domain join to Azure AD. Organizations that have signed up for the free tier have the option to enable or disable this feature, so automatic domain join won’t be enabled unless and until the organization’s administrators decide to enable it. When that feature is enabled, devices that join the Azure AD domain by using the **Connect to work or school** dialog box shown in Figure 4 will be automatically registered with Microsoft Passport for Work support, but previously joined devices will not be registered. - **Organizations that have subscribed to Azure AD Premium have access to the full set of Azure AD MDM features.** These features include controls to manage Microsoft Passport for Work. You can set policies to disable or force the use of Microsoft Passport for Work, require the use of a TPM, and control the length and strength of PINs set on the device. + ![figure 4](images/passport-fig4-join.png) + Figure 4: Joining an Office 365 organization automatically registers the device in Azure AD + **Enable device registration** + If you want to use Microsoft Passport at Work with certificates, you’ll need a device registration system. That means that you set up Configuration Manager Technical Preview, Intune, or a compatible non-Microsoft MDM system and enable it to enroll devices. This is a prerequisite step to use Microsoft Passport for Work with certificates, no matter the IDP, because the enrollment system is responsible for provisioning the devices with the necessary certificates. **Set Microsoft Passport policies** + As of the initial release of Windows 10, you can control the following settings for the use of Microsoft Passport for Work: - You can require that Microsoft Passport be available only on devices that have TPM security hardware, which means the device uses TPM 1.2 or TPM 2.0. - You can enable Microsoft Passport with a hardware-preferred option, which means that keys will be generated on TPM 1.2 or TPM 2.0 when available and by software when TPM is not available. - You can configure whether certificate-based Microsoft Passport is available to users. You do this as part of the device deployment process, not through a separately applied policy. - You can define the complexity and length of the PIN that users generate at registration. - You can control whether Windows Hello use is enabled in your organization. + These settings can be implemented through GPOs or through configuration service providers (CSPs) in MDM systems, so you have a familiar and flexible set of tools you can use to apply them to exactly the users you want. (For details about the Microsoft Passport for Work CSP, see [PassportForWork CSP)](http://go.microsoft.com/fwlink/p/?LinkId=733876). + ## Roadmap + The speed at which Universal Windows apps and services evolve means that the traditional design-build-test-release cycle for Windows is too slow to meet customers’ needs. As part of the release of Windows 10, Microsoft is changing how it engineers, tests, and distributes Windows. Rather than large, monolithic releases every 3–5 years, the Windows engineering team is committed to smaller, more frequent releases to get new features and services into the marketplace more rapidly without sacrificing security, quality, or usability. This model has worked well in Office 365 and the Xbox ecosystem. + In the Windows 10 initial release, Microsoft supports the following Microsoft Passport and Windows Hello features: + - Biometric authentication, with fingerprint readers that use the Windows fingerprint reader framework - Facial-recognition capability on devices that have compatible IR-capable cameras - Microsoft Passport for personal credentials on individually owned and corporate-managed devices - Microsoft Passport for Work support for organizations that have cloud-only Azure AD deployments -<<<<<<< HEAD - Group Policy settings to control Microsoft Passport PIN length and complexity + In future releases of Windows 10, we plan to add support for additional features: - Additional biometric identifier types, including iris recognition - Key-based Microsoft Passport for Work credentials for on-premises Azure AD deployments and hybrid on-premises/Azure AD deployments - Microsoft Passport for Work certificates issued by a trusted PKI, including smart card and virtual smart card certificates - TPM attestation to protect keys so that a malicious user or program can’t create keys in software (because those keys won’t be TPM attested and can thus be identified as fake) -======= - - Group Policy and MDM settings to control Microsoft Passport PIN length and complexity In the November 2015 release, Microsoft supports the following Microsoft Passport and Windows Hello features: @@ -280,7 +396,6 @@ In future releases of Windows 10, we plan to add support for additional feature - TPM attestation to protect keys so that a malicious user or program can’t create keys in software (because those keys won’t be TPM attested and can thus be identified as fake) ->>>>>>> master In the longer term, Microsoft will continue to improve on and expand the features of both Microsoft Passport and Windows Hello to cover additional customer requirements for manageability and security. We also are working with the FIDO Alliance and a variety of third parties to encourage adoption of Microsoft Passport by both web and LOB application developers.     diff --git a/windows/keep-secure/prepare-people-to-use-microsoft-passport.md b/windows/keep-secure/prepare-people-to-use-microsoft-passport.md index 11496345a8..74cebb3914 100644 --- a/windows/keep-secure/prepare-people-to-use-microsoft-passport.md +++ b/windows/keep-secure/prepare-people-to-use-microsoft-passport.md @@ -2,38 +2,60 @@ title: Prepare people to use Microsoft Passport (Windows 10) description: When you set a policy to require Microsoft Passport in the workplace, you will want to prepare people in your organization. ms.assetid: 5270B416-CE31-4DD9-862D-6C22A2AE508B -ms.pagetype: security -keywords: ["identity", "PIN", "biometric", "Hello"] +keywords: identity, PIN, biometric, Hello ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- + # Prepare people to use Microsoft Passport + **Applies to** - Windows 10 - Windows 10 Mobile + When you set a policy to require Microsoft Passport in the workplace, you will want to prepare people in your organization by explaining how to use Passport. + After enrollment in Passport, users should use their gesture (such as a PIN or fingerprint) for access to corporate resources. Their gesture is only valid on the enrolled device. + Although the organization may require users to change their Active Directory or Azure Active Directory (AD) account password at regular intervals, changes to their passwords have no effect on Passport. + People who are currently using virtual smart cards for authentication can use their virtual smart card to verify their identity when they set up Passport. + ## On devices owned by the organization + When someone sets up a new device, they are prompted to choose who owns the device. For corporate devices, they select **This device belongs to my organization**. + ![who owns this pc](images/corpown.png) + Next, they select a way to connect. Tell the people in your enterprise which option they should pick here. + ![choose how you'll connect](images/connect.png) + They sign in, and are then asked to verify their identity. People have options to choose from, such as a text message, phone call, or authentication app. After verification, they create their PIN. The **Create a work PIN** screen displays any complexity requirements that you have set, such as minimum length. + After Passport is set up, people use their PIN to unlock the device, and that will automatically log them on. + ## On personal devices + People who want to access work resources on their personal devices can add a work or school account in **Settings** > **Accounts** > **Work or school**, and then sign in with work credentials. The person selects the method for receiving the verification code, such as text message or email. The verification code is sent and the person then enters the verification code. After verification, the person enters and confirms new PIN. The person can access any token-based resource using this device without being asked for credentials. (This work account gesture doesn't affect the device unlock PIN.) + Assure people that their work credentials and personal credentials are stored in separate containers; the enterprise has no access to their personal credentials. + People can go to **Settings** > **Accounts** > **Work or school**, select the work account, and then select **Unjoin** to remove the account from their device. + ## Using Windows Hello and biometrics + If your policy allows it, people can add Windows Hello to their Passport. Windows Hello can be fingerprint, iris, and facial recognition, and is available to users only if the hardware supports it. + ![sign in to windows, apps, and services using fingerprint or face](images/hellosettings.png) + ## Use a phone to sign in to a PC + If your enterprise enables phone sign-in, users can pair a phone running Windows 10 Mobile to a PC running Windows 10 and then use an app on the phone to sign in to the PC using their Microsoft Passport credentials. -**Note**  Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants. +> **Note:**  Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.   **Prerequisites:** - The PC must be joined to the Active Directory domain or Azure AD cloud domain. @@ -42,21 +64,30 @@ If your enterprise enables phone sign-in, users can pair a phone running Windows - The free **Phone Sign-in** app must be installed on the phone. **Pair the PC and phone** 1. On the PC, go to **Settings** > **Devices** > **Bluetooth**. Tap the name of the phone and then tap **Pair** to begin pairing. + ![bluetooth pairing](images/btpair.png) + 2. On the phone, go to **Settings** > **Devices** > **Bluetooth**, and verify that the passcode for **Pairing accessory** on the phone matches the passcode displayed on the PC, and then tap **ok**. + ![bluetooth pairing passcode](images/bt-passcode.png) + 3. On the PC, tap **Yes**. **Sign in to PC using the phone** 1. Open the **Phone Sign-in** app and tap the name of the PC to sign in to. - **Note**  The first time that you run the Phone-Sign app, you must add an account. + > **Note: **  The first time that you run the Phone-Sign app, you must add an account.   2. Enter the work PIN that you set up when you joined the phone to the cloud domain or added a work account. + ## Related topics + [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) + [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md) + [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md) + [Microsoft Passport and password changes](microsoft-passport-and-password-changes.md) + [Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md) + [Event ID 300 - Passport successfully created](passport-event-300.md) -  -  diff --git a/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md b/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md index a0af51cade..ea019eb343 100644 --- a/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md +++ b/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md @@ -2,28 +2,41 @@ title: Switch PCR banks on TPM 2.0 devices (Windows 10) description: A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. ms.assetid: 743FCCCB-99A9-4636-8F48-9ECB3A3D10DE -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Switch PCR banks on TPM 2.0 devices **Applies to** - Windows 10 + A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. The size of the value that can be stored in a PCR is determined by the size of a digest generated by an associated hashing algorithm. A SHA-1 PCR can store 20 bytes – the size of a SHA-1 digest. Multiple PCRs associated with the same hashing algorithm are referred to as a PCR bank. + To store a new value in a PCR, the existing value is extended with a new value as follows: PCR\[N\] = HASHalg( PCR\[N\] || ArgumentOfExtend ) + The existing value is concatenated with the argument of the TPM Extend operation. The resulting concatenation is then used as input to the associated hashing algorithm, which computes a digest of the input. This computed digest becomes the new value of the PCR. + The [TCG PC Client Specific Platform TPM Profile for TPM 2.0](http://go.microsoft.com/fwlink/p/?LinkId=746577) defines the inclusion of at least one PCR bank with 24 registers. The only way to reset the first 16 PCRs is to reset the TPM itself. This restriction helps ensure that the value of those PCRs can only be modified via the TPM Extend operation. + Some TPM PCRs are used as checksums of log events. The log events are extended in the TPM as the events occur. Later, an auditor can validate the logs by computing the expected PCR values from the log and comparing them to the PCR values of the TPM. Since the first 16 TPM PCRs cannot be modified arbitrarily, a match between an expected PCR value in that range and the actual TPM PCR value provides assurance of an unmodified log. + ## How does Windows 10 use PCRs? + To bind the use of a TPM based key to a certain state of the PC, the key can be sealed to an expected set of PCR values. For instance, PCRs 0 through 7 have a well-defined value after the boot process – when the OS is loaded. When the hardware, firmware, or boot loader of the machine changes, the change can be detected in the PCR values. Windows 10 uses this capability to make certain cryptographic keys only available at certain times during the boot process. For instance, the BitLocker key can be used at a certain point in the boot, but not before or after. -It is important to note that this binding to PCR values also includes the hashing algorithm used for the PCR. For instance, a key can be bound to a specific value of the SHA-1 PCR\[12\], if using SHA-256 PCR banks, even with the same system configuration otherwise, the PCR values will not match. + +It is important to note that this binding to PCR values also includes the hashing algorithm used for the PCR. For instance, a key can be bound to a specific value of the SHA-1 PCR\[12\], if using SHA-256 PCR banks, even with the +same system configuration otherwise, the PCR values will not match. + ## What happens when PCR banks are switched? + When the PCR banks are switched, the algorithm used to compute the hashed values stored in the PCRs during extend operations is changed. For the same input, each hash algorithm will return a different cryptographic signature for the same inputs. + As a result, if the currently used PCR bank is switched all keys that have been bound to the previous PCR values will no longer work. For example, if you had a key bound to the SHA-1 value of PCR\[12\] and subsequently changed the PCR banks to SHA-256, the banks wouldn’t match, and you would be unable to use that key. The BitLocker key is secured using the PCR banks and Windows 10 will not be able to unseal it if the PCR banks are switched while BitLocker is enabled. + ## What can I do to switch PCRs when BitLocker is already active? + Before switching PCR banks you should suspend or disable BitLocker – or have your recovery key ready. For steps on how to switch PCR banks on your PC, you should contact your OEM or UEFI vendor. -  -  diff --git a/windows/keep-secure/vpn-profile-options.md b/windows/keep-secure/vpn-profile-options.md index dd626ba989..6f336cc6e6 100644 --- a/windows/keep-secure/vpn-profile-options.md +++ b/windows/keep-secure/vpn-profile-options.md @@ -2,32 +2,46 @@ title: VPN profile options (Windows 10) description: Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. ms.assetid: E3F99DF9-863D-4E28-BAED-5C1B1B913523 -ms.pagetype: networking ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: networking author: jdeckerMS --- + # VPN profile options + **Applies to** - Windows 10 - Windows 10 Mobile + Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. + ## Always On + Always On is a new feature in Windows 10 which enables the active VPN profile to connect automatically on the following triggers: - User sign-on - Network change + When a device has multiple profiles with Always On triggers, the user can specify the active profile in **Settings** > **Network & Internet** > **VPN** > *VPN profile* > **Let apps automatically use this VPN connection**. + ## App-triggered VPN + VPN profiles in Windows 10 can be configured to connect automatically on the launch of a specified set of applications. This feature was included in Windows 8.1 as "On demand VPN". The applications can be defined using the following: - Package family name for Universal Windows Platform (UWP) apps - File path for Classic Windows applications + ## Traffic filters + Traffic Filters give enterprises the ability to decide what traffic is allowed into the corporate network based on policy . With the ever-increasing landscape of remote threats on the corporate network and lesser IT controls on machines, it becomes essential to control the traffic that is allowed through. While server-side layers of firewalls and proxies help, by adding traffic filters the first layer of filtering can be moved onto the client with more advanced filtering on the server side. There are two types of Traffic Filter rules: + - **App-based rules**. With app-based rules, a list of applications can be marked such that only traffic originating from these apps is allowed to go over the VPN interface. - **Traffic-based rules**. Traffic-based rules are 5-tuple policies (ports, addresses, protocol) that can be specified such that only traffic matching these rules is allowed to go over the VPN interface. + There can be many sets of rules which are linked by **OR**. Within each set, there can be app-based rules and traffic-based rules; all the properties within the set will be linked by **AND**. This gives the IT admins a lot of power to craft the perfect policy befitting their use case. + ## LockDown VPN + A VPN profile configured with LockDown secures the device to only allow network traffic over the VPN interface. It has the following features: - The system attempts to keep the VPN connected at all times. - The user cannot disconnect the VPN connection. @@ -35,12 +49,12 @@ A VPN profile configured with LockDown secures the device to only allow network - The VPN LockDown profile uses forced tunnel connection. - If the VPN connection is not available, outbound network traffic is blocked. - Only one VPN LockDown profile is allowed on a device. -**Note**   -For inbox VPN, Lockdown VPN is only available for the Internet Key Exchange version 2 (IKEv2) tunnel type. +> **Note:**  For inbox VPN, Lockdown VPN is only available for the Internet Key Exchange version 2 (IKEv2) tunnel type.   ## Learn more + [VPNv2 configuration service provider (CSP) reference](http://go.microsoft.com/fwlink/p/?LinkId=617588) + [How to Create VPN Profiles in Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=618028) + [Help users connect to their work using VPN profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=618029) -  -  diff --git a/windows/keep-secure/why-a-pin-is-better-than-a-password.md b/windows/keep-secure/why-a-pin-is-better-than-a-password.md index 558cbc221c..5afeb6f914 100644 --- a/windows/keep-secure/why-a-pin-is-better-than-a-password.md +++ b/windows/keep-secure/why-a-pin-is-better-than-a-password.md @@ -2,51 +2,74 @@ title: Why a PIN is better than a password (Windows 10) description: Microsoft Passport in Windows 10 enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a password . ms.assetid: A6FC0520-01E6-4E90-B53D-6C4C4E780212 -ms.pagetype: security -keywords: ["pin", "security", "password"] +keywords: pin, security, password ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: jdeckerMS --- + # Why a PIN is better than a password + **Applies to** - Windows 10 - Windows 10 Mobile + Microsoft Passport in Windows 10 enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a password? On the surface, a PIN looks much like a password. A PIN can be a set of numbers, but enterprise policy might allow complex PINs that include special characters and letters, both upper-case and lower-case. Something like **t758A!** could be an account password or a complex Passport PIN. It isn't the structure of a PIN (length, complexity) that makes it better than a password, it's how it works. + + ## PIN is tied to the device One important difference between a password and a Passport PIN is that the PIN is tied to the specific device on which it was set up. That PIN is useless to anyone without that specific hardware. Someone who steals your password can sign in to your account from anywhere, but if they steal your PIN, they'd have to steal your physical device too! + Even you can't use that PIN anywhere except on that specific device. If you want to sign in on multiple devices, you have to set up Passport on each device. + ## PIN is local to the device + A password is transmitted to the server -- it can be intercepted in transmission or stolen from a server. A PIN is local to the device -- it isn't transmitted anywhere and it isn't stored on the server. When the PIN is created, it establishes a trusted relationship with the identity provider and creates an asymmetric key pair that is used for authentication. When you enter your PIN, it unlocks the authentication key and uses the key to sign the request that is sent to the authenticating server. -**Note**   -For details on how Passport uses asymetric key pairs for authentication, see [Microsoft Passport guide](http://go.microsoft.com/fwlink/p/?LinkId=691928). +> **Note:**  For details on how Passport uses asymetric key pairs for authentication, see [Microsoft Passport guide](http://go.microsoft.com/fwlink/p/?LinkId=691928).   ## PIN is backed by hardware + The Passport PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. All Windows 10 Mobile phones and many modern laptops have TPM. + User key material is generated and available within the Trusted Platform Module (TPM) of the user device, which protects it from attackers who want to capture the key material and reuse it. Because Microsoft Passport uses asymmetrical key pairs, users credentials can’t be stolen in cases where the identity provider or websites the user accesses have been compromised. + The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. After too many incorrect guesses, the device is locked. + ## PIN can be complex + The Passport PIN is subject to the same set of IT management policies as a password, such as complexity, length, expiration, and history. Although we generally think of a PIN as a simple four-digit code, administrators can set [policies](implement-microsoft-passport-in-your-organization.md) for managed devices to require a PIN complexity similar to a password. You can require or block: special characters, uppercase characters, lowercase characters, and digits. + ## What if someone steals the laptop or phone? + To compromise a Microsoft Passport credential that TPM protects, an attacker must have access to the physical device, and then must find a way to spoof the user’s biometrics or guess his or her PIN—and all of this must be done before TPM anti-hammer capabilities lock the device. You can provide additional protection for laptops that don't have TPM by enablng BitLocker and setting a policy to limit failed sign-ins. + **Configure BitLocker without TPM** 1. Use the Local Group Policy Editor (gpedit.msc) to enable the following policy: + **Computer Configuration** > **Administrative Templates** > **Windows Components** > **BitLocker Drive Encryption** > **Operating System Drives** > **Require additional authentication at startup** + 2. In the policy option, select **Allow BitLocker without a compatible TPM**, and then click **OK.** 3. Go to Control Panel > **System and Security** > **BitLocker Drive Encryption** and select the operating system drive to protect. **Set account lockout threshold** 1. Use the Local Group Policy Editor (gpedit.msc) to enable the following policy: + **Computer Configuration** >**Windows Settings** ?**Security Settings** >**Account Policies** > **Account Lockout Policy** > **Account lockout threshold** + 2. Set the number of invalid logon attempts to allow, and then click OK. + ## Why do you need a PIN to use Windows Hello? Windows Hello is the biometric sign-in for Microsoft Passport in Windows 10: fingerprint, iris, or facial recognition. When you set up Windows Hello, you're asked to create a PIN first. This PIN enables you to sign in using Passport when you can’t use your preferred biometric because of an injury or because the sensor is unavailable or not working properly. + If you only had a biometric sign-in configured and, for any reason, were unable to use that method to sign in, you would have to sign in using your account name and password, which doesn't provide you the same level of protection as Passport. + ## Related topics + [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) + [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md) -  -  +  \ No newline at end of file diff --git a/windows/keep-secure/windows-10-enterprise-security-guides.md b/windows/keep-secure/windows-10-enterprise-security-guides.md index dffeabae7b..510675e4ff 100644 --- a/windows/keep-secure/windows-10-enterprise-security-guides.md +++ b/windows/keep-secure/windows-10-enterprise-security-guides.md @@ -2,16 +2,22 @@ title: Enterprise security guides (Windows 10) description: Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. ms.assetid: 57134f84-bd4b-4b1d-b663-4a2d36f5a7f8 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: challum + --- + # Enterprise security guides + ## Purpose + Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. + ## In this section +
diff --git a/windows/keep-secure/windows-10-mobile-security-guide.md b/windows/keep-secure/windows-10-mobile-security-guide.md index fe2c16b438..1008003440 100644 --- a/windows/keep-secure/windows-10-mobile-security-guide.md +++ b/windows/keep-secure/windows-10-mobile-security-guide.md @@ -2,30 +2,43 @@ title: Windows 10 Mobile security guide (Windows 10) description: This guide provides a detailed description of the most important security features in the Windows 10 Mobile operating system—identity access and control, data protection, malware resistance, and app platform security. ms.assetid: D51EF508-699E-4A68-A7CD-91D821A97205 -ms.pagetype: security; mobile -keywords: ["data protection, encryption, malware resistance, smartphone, device, Windows Store"] +keywords: data protection, encryption, malware resistance, smartphone, device, Windows Store ms.prod: W10 ms.mktglfcycl: manage ms.sitesec: library +ms.pagetype: security; mobile author: AMeeus --- + # Windows 10 Mobile security guide + **Applies to** - Windows 10 Mobile + This guide provides a detailed description of the most important security features in the Windows 10 Mobile operating system—identity access and control, data protection, malware resistance, and app platform security. + ## Overview + Windows 10 Mobile is specifically designed for smartphones and small tablets. It uses the same security technologies as the Windows 10 operating system to help protect against known and emerging security threats across the spectrum of attack vectors. Several broad categories of security work went into Windows 10 Mobile: + - **Identity and access control.** Microsoft has greatly enhanced identity and access control features to simplify and improve the security of user authentication. These features include Windows Hello and Microsoft Passport, which better protect user identities through easy-to-deploy and easy-to-use multifactor authentication (MFA). (Windows Hello requires either a specialized illuminated infrared \[IR\] camera for facial recognition and iris detection or a finger print reader that supports the Windows Biometric Framework.) - **Data protection.** Confidential data is better protected from compromise than ever before. Windows 10 Mobile uses several data-protection technologies and delivers them in a user-friendly and IT-manageable way. - **Malware resistance.**Windows 10 Mobile helps protect critical system resources and apps to reduce the threat of malware, including support for enterprise-grade secure hardware and Secure Boot. -- **App platform security.** The Windows 10 Mobile enterprise-grade secure app platform provides multiple layers of security. For example, Windows Store checks all apps for malware to help prevent malware from reaching devices. In addition, AppContainer application isolation helps prevent any malicious app from compromising other apps. +- **App platform security.** The Windows 10 Mobile enterprise-grade secure app platform provides multiple layers of security. For example, Windows Store checks all apps for malware to help prevent malware from reaching devices. + +In addition, AppContainer application isolation helps prevent any malicious app from compromising other apps. + This guide explains each of these technologies and how they help protect your Windows 10 Mobile devices. + ## Identity and access control + A fundamental component of security is the notion that a user has a unique identity and that that identity is either allowed or denied access to resources. This notion is traditionally known as access control, which has three parts: - **Identification.** The user (subject) asserts a unique identity to the computer system for the purpose of accessing a resource (object), such as a file or an app. - **Authentication.** Authentication is the process of proving the asserted identity and verifying that the subject is indeed the subject. - **Authorization.** The system compares the authenticated subject’s access rights against the object’s permissions and either allows or denies the requested access. + The way an operating system implements these components makes a difference in preventing attackers from accessing corporate data. Only users who prove their identities and are authorized to access that data can access it. In security, however, there are varying degrees of identity proof and many different requirements for authorization limits. The access control flexibility most corporate environments need presents a challenge for any operating system. Table 1 lists typical Windows access control challenges and the solutions that Windows 10 Mobile offers. + Table 1. Windows 10 Mobile solutions for typical access control challenges
@@ -59,41 +72,67 @@ Table 1. Windows 10 Mobile solutions for typical access control challenges
  The following sections describe these challenges and solutions in more detail. + ### Microsoft Passport + Microsoft Passport provides strong MFA, fully integrated into Windows devices, to replace passwords. To authenticate, the user must have a Microsoft Azure Active Directory (Azure AD)–registered device and either a PIN or Windows Hello biometric gesture to unlock the device. Microsoft Passport is conceptually similar to a smart card but more flexible, as it doesn’t require a public key infrastructure or the implementation of additional hardware and supports biometric identification. + Microsoft Passport offers three significant advantages over the previous state of Windows authentication: it’s more flexible, it’s based on industry standards, and it more effectively mitigates risks. ### It's effective + Microsoft Passport eliminates the use of passwords for logon and so reduces the risk that an attacker will steal and reuse a user’s credentials. User key material, which includes the user’s private key, is available only on the device that generated it. The key material is protected with the TPM, which protects the key material from attackers who want to capture and reuse it. It is a Windows Hardware Certification Program requirement that every Windows 10 Mobile device include a TPM. + To compromise a Microsoft Passport credential that the TPM protects, an attacker must have access to the physical device, and then find a way to spoof the user’s biometrics identity or guess his or her PIN—and all of this must be done before TPM brute-force resistance capabilities lock the mobile device, the theft-protection mechanism kicks in, or the user or corporate administrator remotely wipes the device. This technology greatly reduces an attacker’s window of opportunity for compromising a user’s credentials. + ### It's flexible + Microsoft Passport offers unprecedented flexibility along with enterprise-grade security. + Most importantly, Microsoft Passport works with biometrics or PINs and gives you options beyond long, complex passwords. Instead of users memorizing and retyping often-changed passwords, Microsoft Passport enables PIN- and biometrics-based identification through Windows Hello to identify users more securely. + The Windows 10 Mobile device that the user logs on to is an authentication factor, as well. The credentials used and the private key on the device are device specific and bound to the device’s TPM. + In the future, Microsoft Passport will also enable people to use Windows 10 Mobile devices as a remote credential when signing in to PCs running Windows 10. Users will use their PINs or biometrics to unlock their phones, and their phones will unlock their PCs. Phone sign-in with Microsoft Passport will make implementing MFA for scenarios where the user’s credentials must be physically separate from the PC the user is signing in to less costly and complex than other solutions. Phone sign-in will also make it easier for users and IT pros because users can use their phones to sign in to any corporate device instead of enrolling a user credential on each. + With Microsoft Passport, you gain flexibility in the data center, too. To deploy it for Windows 10 Mobile devices, you must set up Azure AD, but you don’t have to replace or remove your existing Active Directory environment. Using Azure AD Connect, organizations can synchronize these two directory services. Microsoft Passport builds on and adds to your existing infrastructure and allows you to federate with Azure AD. + Microsoft Passport is also supported on the desktop, giving organizations a uniform way to implement strong authentication on all devices. This flexibility makes it simpler for Microsoft Passport to supplement existing smart card or token deployments for on-premises Windows PC scenarios, adding MFA to mobile devices and users who don’t currently have it for extra protection of sensitive resources or systems that these mobile devices access. + ### It's standardized + Both software vendors and enterprise customers have come to realize that proprietary identity and authentication systems are a dead end: the future lies with open, interoperable systems that allow secure authentication across a variety of devices, line-of-business (LOB) apps, and external applications and websites. To this end, a group of industry players formed the Fast Identity Online (FIDO) Alliance. The FIDO Alliance is a nonprofit organization that works to address the lack of interoperability among strong authentication devices as well as the problems users face in creating and remembering multiple user names and passwords. The FIDO Alliance plans to change the nature of authentication by developing specifications that define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to authenticate users of online services securely. This new standard can allow any business network, app, website, or cloud application to interface with a broad variety of existing and future FIDO-enabled devices and operating system platforms using a standardized set of interfaces and protocols. In 2014, Microsoft joined the board of the FIDO Alliance. FIDO standards enable a universal framework that a global ecosystem delivers for a consistent and greatly improved user experience of strong password-less authentication. The FIDO 1.0 specifications, published in December 2014, provide for two types of authentications: password-less (known as UAF) and second factor (U2F). The FIDO Alliance is working on a set of 2.0 proposals that incorporate the best ideas from its U2F and UAF FIDO 1.0 standards and of course new ideas. Microsoft has contributed Microsoft Passport technology to the FIDO 2.0 specification workgroup for review and feedback and continues to work with the FIDO Alliance as the FIDO 2.0 specification moves forward. Interoperability of FIDO products is a hallmark of FIDO authentication. Microsoft believes that bringing a FIDO solution to market will help solve a critical need for enterprises and consumers alike. + ### Windows Hello + Windows Hello is the new biometric framework for Windows 10. Because biometric identification is built directly into the operating system, it allows you to use your iris, face, or fingerprint to unlock your mobile device. Windows Hello unlocks Microsoft Passport credentials, which enable authentication to resources or relying parties such as software-as-a-service applications like Microsoft Office 365. Windows Hello supports three biometric sensor options that are suitable for enterprise scenarios: + - **Facial recognition** uses special IR cameras to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major manufacturers are already shipping laptops with integrated facial-recognition technology. Both Surface Pro 4 and Surface Book support this technology. - **Fingerprint recognition** uses a sensor to scan the user’s fingerprint. Although fingerprint readers have been available for computers running the Windows operating system for years, the detection, anti-spoofing, and recognition algorithms in Windows 10 are more advanced than in previous Windows versions. Most existing fingerprint readers (whether external to or integrated into laptops or USB keyboards) that support the Windows Biometric Framework will work with Windows Hello. - **Iris scanning** uses cameras designed to scan the user’s iris, the colorful and highly detailed portion of the eye. Because the data must be accurate, iris scanning uses a combination of an IR light source and a high-quality camera. Microsoft Lumia 950 and 950 XL devices support this technology. -**Note**   -Users must create an unlock PIN before they enroll a biometric gesture. The device uses this PIN as a fallback mechanism in situations where it cannot capture the biometric gesture. +> **Note:**  Users must create an unlock PIN before they enroll a biometric gesture. The device uses this PIN as a fallback mechanism in situations where it cannot capture the biometric gesture.   All three of these biometric factors—the face, the finger, and the iris—are unique to an individual. To capture enough data to uniquely identify an individual, a biometric scanner might initially capture images in multiple conditions or with additional details. For example, an iris scanner will capture images of both eyes; or both with and without eyeglasses or contact lenses. + Spoofing biometric data is often a big concern in enterprise environments. Microsoft employs several anti-spoofing techniques in Windows 10 Mobile that verify the trustworthiness of the biometric device as well as guard against intentional collision with stored biometric measurements. These techniques help improve the false-acceptance rate (the rate at which spoofed biometric data is accepted as authentic) while maintaining the overall usability and manageability of MFA. + The biometric image collected at enrollment is converted into an algorithmic form that cannot be converted back into the original image. Only the algorithmic form is kept; the actual biometric image is removed from the device after conversion. Windows 10 Mobile devices both encrypt the algorithmic form of the biometric data and bind the encrypted data to the device, both of which help prevent someone from removing the data from the phone. As a result, the biometric information that Windows Hello uses is a local gesture and doesn’t roam among the user’s devices. + Windows Hello offers several major benefits. First, it helps to address the problems of credential theft and sharing because an attacker must obtain the mobile phone and impersonate the user’s biometric identity, which is more difficult than stealing a device unlock password. Second, the use of biometrics gives users an authenticator that’s always with them—there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, enterprise-grade secure method for logging on to their Windows 10 Mobile device. Finally, there’s nothing additional to deploy, because Microsoft built Windows Hello support directly into the operating system. All you need is a device that includes a supported biometric sensor. + The device that senses the biometric factors must report the data to Windows Hello quickly and accurately. For this reason, Microsoft determines which factors and devices are trustworthy and accurate prior to their inclusion in Windows Hello. For more information, see [Windows 10 specifications](http://go.microsoft.com/fwlink/p/?LinkId=722908). + ## Data protection + Windows 10 Mobile continues to provide solutions that help protect information against unauthorized access and disclosure. + + ### Device encryption Windows 10 Mobile uses device encryption, based on BitLocker technology, to encrypt all internal storage, including operating system and data storage partitions. The user can activate device encryption, or the IT department can activate and enforce encryption for company-managed devices through MDM tools. When device encryption is turned on, all data stored on the phone is encrypted automatically. A Windows 10 Mobile device with encryption turned on helps protect the confidentiality of data stored if the device is lost or stolen. The combination of Windows Hello lock and data encryption makes it extremely difficult for an unauthorized party to retrieve sensitive information from the device. + You can customize how device encryption works to meet your unique security requirements. Device encryption even enables you to define your own cipher suite. For example, you can specify the algorithm and key size that Windows 10 Mobile uses for data encryption, which Transport Layer Security (TLS) cipher suites are permitted, and whether Federal Information Processing Standard (FIPS) policy is enabled. Table 2 lists the policies you can change to customize device encryption on Windows 10 Mobile devices. + Table 2. Windows 10 cryptography policies @@ -128,52 +167,79 @@ Table 2. Windows 10 cryptography policies
  For a complete list of policies available, see [Policy CSP](http://go.microsoft.com/fwlink/p/?LinkId=733963). + ### Enterprise data protection + Enterprises have seen huge growth in the convergence of personal and corporate data storage. Personal data is frequently stored on corporate devices and vice versa. This situation increases the potential for compromise of sensitive corporate data. + One growing risk is authorized users’ accidental disclosure of sensitive data—a risk that is rapidly becoming the biggest source of confidential data leakage as organizations allow personal devices to access corporate resources. One example is common among organizations: an employee connects his or her personal phone to the company’s Microsoft Exchange Server instance for email. He or she uses the phone to work on email that includes attachments with sensitive data. When sending the email, the user accidentally copies a supplier. Content protection is only as strong as the weakest link, and in this example, the unintended sharing of sensitive data with unauthorized people might not have been prevented with standard data encryption. + In Windows 10 Mobile, enterprise data protection (EDP) helps separate personal and enterprise data and prevent data leakage. Key features include its ability to: + - Automatically tag personal and corporate data. - Protect data while it’s at rest on local or removable storage. - Control which apps can access corporate data. - Control which apps can access a virtual private network (VPN) connection. - Prevent users from copying corporate data to public locations. -**Note**   -EDP is currently being tested in select customer evaluation programs. For more information about EDP, see [Enterprise data protection overview](../whats-new/edp-whats-new-overview.md). + +> **Note:**  EDP is currently being tested in select customer evaluation programs. For more information about EDP, see [Enterprise data protection overview](../whats-new/edp-whats-new-overview.md).   ### Enlightenment + Third-party data loss protection solutions usually require developers to wrap their apps. In contrast, EDP puts the intelligence in Windows 10 Mobile so that it doesn’t require wrappers. As a result, most apps require nothing extra to work with EDP. + EDP can enforce policy without the need for an app to change. This means that an app that always handles business data (such as an LOB app) can be added to the allowed list and will always encrypt all data that it handles. However, if the app does not use common controls, cut and paste operations from this app to a non-enterprise app will silently fail. In addition, if the app needs to handle personal data, this data will also be encrypted. Therefore, to improve the user experience, in some cases, developers should enlighten their apps by adding code to and compiling them to use the EDP application programming interfaces. Those cases include apps that: - Don’t use common controls for saving files. - Don’t use common controls for text boxes. - Work on personal and enterprise data simultaneously (for example, contact apps that display personal and enterprise data in a single view; a browser that displays personal and enterprise web pages on tabs within a single instance). + Figure 1 summarizes when an app might require enlightenment to work with EDP. Microsoft Word is a good example. Not only can Word access personal and enterprise data simultaneously, but it can also transmit enterprise data (for example, email attachments containing enterprise data). + In any case, most apps don’t require enlightenment for them to use EDP protection. Simply adding them to the EDP allow list is all you must do. Because unenlightened apps cannot automatically tag data as personal or enterprise, if they are in an EDP policy, they treat all data as enterprise data. An LOB app is a good example. Adding an LOB app to an EDP policy protects all data that the app handles. Another example is a legacy app that cannot be updated, which you can add to an EDP policy and use without even being aware that EDP exists. + ![figure 1](images/mobile-security-guide-fig1.png) + Figure 1. When is enlightenment required? + ### Data leakage control + To configure EDP in an MDM solution that supports it, add authorized apps to the EDP allow list. When a device running Windows 10 Mobile enrolls in the MDM solution, apps that this policy doesn’t authorize won’t have access to enterprise data. + EDP works seamlessly until users try to access enterprise data with or try to paste enterprise data into unauthorized apps or locations on the web. For example, copying enterprise data from an authorized app to another authorized app works as usual, but EDP blocks users from copying enterprise data from an authorized app to an unauthorized app. Likewise, EDP blocks users from using an unauthorized app to open a file that contains enterprise data. In addition, users cannot copy and paste data from authorized apps to unauthorized apps or locations on the Web without triggering one of the EDP protection levels: - **Block.** EDP blocks users from completing the operation. - **Override.** EDP notifies users that the operation is inappropriate but allows them to override the policy, although it logs the operation in the audit log. - **Audit.** EDP does not block or notify users but logs the operation in the audit log. - **Off.** EDP does not block or notify users and does not log operations in the audit log. + ### Data separation + As the name suggests, data separation separates personal from enterprise data. Most third-party solutions require an app wrapper, and from here, enterprise data goes in a container while personal data is outside the container. Often, people must use two different apps for the same purpose: one for personal data and another for enterprise data. + EDP provides the same data separation but neither uses containers nor requires a special version of an app to access business data, and then a second instance of it to access personal data. There are no containers, partitions, or special folders to physically separate personal and business data. Instead, Windows 10 Mobile is the access control broker, identifying enterprise data because it’s encrypted to the enterprise. Therefore, EDP provides data separation by virtue of encrypting enterprise data. + ### Visual cues + In Windows 10 Mobile, visual cues indicate the status of EDP to users (see Figure 2): + - **Start screen.** On the Start screen, apps that an EDP policy manages display a visual cue. - **Files.** In File Explorer, a visual cue indicates whether a file or folder contains enterprise data and is therefore encrypted. For example, Erwin is an employee at Fabrikam. He opens Microsoft Edge from the Start screen and sees that the tile indicates that an EDP policy manages the browser. Erwin opens the Fabrikam sales website and downloads a spreadsheet. In File Explorer, Erwin sees that the file he downloaded has a visual cue which indicates that it’s encrypted and contains enterprise data. When Erwin tries to paste data from that spreadsheet into an app that no EDP policy manages (for example, his Twitter app), Erwin might see a message that allows him to override protection while logging the action, depending on the protection level configured in the EDP policy. + ![figure 2](images/mobile-security-guide-fig2.png) + Figure 2. Visual cues in EDP + ## Malware resistance + Just as software has automated so much of our lives, malware has automated attacks on our devices. Those attacks are relentless. Malware is constantly changing, and when it infects a device, it can be difficult to detect and remove. The best way to fight malware is to prevent the infection from happening. Windows 10 Mobile provides strong malware resistance because it takes advantage of secured hardware and protects both the startup process and the core operating system architecture. + Table 3 lists specific malware threats and the mitigation that Windows 10 Mobile provides. + Table 3. Threats and Windows 10 Mobile mitigations + @@ -226,54 +292,78 @@ Table 3. Threats and Windows 10 Mobile mitigations
  -**Note**   -Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in section 27 of the UEFI specification, which can be found at [http://www.uefi.org/specsandtesttools](http://go.microsoft.com/fwlink/p/?LinkId=722912). This standard describes the process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based device before they are executed. +> **Note:**  Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in section 27 of the UEFI specification, which can be found at [http://www.uefi.org/specsandtesttools](http://go.microsoft.com/fwlink/p/?LinkId=722912). This standard describes the process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based device before they are executed.   The following sections describe these improvements in more detail. + ### Enterprise-grade secure hardware + Taking full advantage of Windows 10 Mobile security features requires advancements in hardware-based security. These advances include UEFI with Secure Boot, TPM, and biometric sensors (hardware dependent). + ### UEFI with Secure Boot + When a Windows 10 Mobile device starts, it begins the process of loading the operating system by locating the bootloader in the device’s storage system. Without safeguards in place, the phone might simply hand control over to the bootloader without even determining whether it’s a trusted operating system or malware. + UEFI is a standards-based solution that offers a modern-day replacement for the BIOS. In fact, it provides the same functionality as BIOS while adding security features and other advanced capabilities. Like BIOS, UEFI initializes devices, but UEFI components with the Secure Boot feature (version 2.3.1 or later) also help ensure that only trusted firmware in Option ROMs, UEFI apps, and operating system bootloaders can start on the mobile phone. UEFI can run internal integrity checks that verify the firmware’s digital signature before running it. Because only the mobile phone’s manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI has protection against firmware-based malware that loads before Windows 10 Mobile and can successfully hide its malicious behavior from Windows 10 Mobile. Firmware-based malware of this nature is typically called a bootkit. When a mobile device with UEFI and Secure Boot starts, the UEFI firmware verifies the bootloader’s digital signature to verify that no one has modified it after it was digitally signed. The firmware also verifies that a trusted authority issued the bootloader’s digital signature. This check helps to ensure that the system starts only after checking that the bootloader is both trusted and unmodified since signing. All Windows 10 Mobile devices always have Secure Boot enabled. In addition, they trust only the Windows operating system signature. + Neither Windows 10 Mobile, apps, or even malware can change the UEFI configuration. For more information about UEFI with Secure Boot, read [Protecting the pre-OS environment with UEFI](http://go.microsoft.com/fwlink/p/?LinkId=722909). + ### Trusted Platform Module + A Trusted Platform Module is a tamper-resistant cryptographic module that enhances the security and privacy of computing platforms. The TPM is incorporated as a component in a trusted computing platform like a PC, tablet, or mobile phone. A trusted computing platform is specially designed to work with the TPM to support privacy and security scenarios that software alone cannot achieve. It is a Windows 10 Mobile device hardware certification requirement to include a TPM in every Windows 10 Mobile device. + A proper implementation of a TPM as part of a trusted computing platform provides a hardware root of trust, meaning that the hardware behaves in a trusted way. For example, if you create a key in a TPM with the property that no one can export that key from the TPM, the key absolutely cannot leave the TPM. The close integration of a TPM with a platform increases the transparency of the boot process and supports device health scenarios by enabling reliable report of the software used to start a platform. + The following list describes key functionality that a TPM provides in Windows 10 Mobile: - **Manage cryptographic keys.** A TPM can create, store, and permit the use of keys in defined ways. Windows 10 Mobile uses the TPM to protect the encryption keys for BitLocker volumes, virtual smart cards, certificates, and various other keys. - **Safeguard and report integrity measurements.**Windows 10 Mobile uses the TPM to record and help protect integrity-related measurements of select hardware and Windows boot components for the Measured Boot feature. In this scenario, Measured Boot measures each component, from firmware up through the drivers, and then stores those measurements in the device’s TPM. From here, you can test the measurement log remotely so that a separate system verifies the boot state of the Windows 10 Mobile device. - **Prove a TPM is really a TPM.** Managing cryptographic keys and measuring integrity are so central to protecting privacy and security that a TPM must differentiate itself from malware that masquerades as a TPM. + Windows 10 Mobile supports TPM implementations that comply with the 2.0 standard. The TPM 2.0 standard includes several improvements that make it superior to the 1.2 standard, the most notable of which is cryptographic agility. TPM 1.2 is restricted to a fixed set of encryption and hash algorithms. At the time the TPM 1.2 standard appeared in the early 2000s, the security community considered these algorithms cryptographically strong. Since that time, advances in cryptographic algorithms and cryptanalysis attacks have increased expectations for stronger cryptography. TPM 2.0 supports additional algorithms that offer stronger cryptographic protection as well as the ability to plug in algorithms that certain geographies or industries may prefer. It also opens the possibility for inclusion of future algorithms without changing the TPM component itself. Many people assume that original equipment manufacturers (OEMs) must implant a TPM in hardware on a motherboard as a discrete module, but TPM can also be effective when implemented in firmware. Windows 10 Mobile supports only firmware TPM that complies with the 2.0 standard. Windows does not differentiate between discrete and firmware-based solutions because both must meet the same implementation and security requirements; therefore, any Windows 10 feature that can take advantage of TPM can be used with Windows 10 Mobile. -**Note**   -Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see [Minimum hardware requirements](http://go.microsoft.com/fwlink/p/?LinkId=733964). + +> **Note:**  Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see [Minimum hardware requirements](http://go.microsoft.com/fwlink/p/?LinkId=733964).   Several Windows 10 Mobile security features require TPM: - Virtual smart cards - Measured Boot - Health attestation (requires TPM 2.0 or later) Still other features will use the TPM if it is available. For example, Microsoft Passport does not require TPM but uses it if it’s available. Organizations can configure policy to require TPM for Microsoft Passport. + ### Biometrics + Windows 10 Mobile makes biometrics a core security feature. Microsoft has fully integrated biometrics into the Windows 10 Mobile security components, not just tacked it on top of the platform (as was the case in previous versions of Windows). This is a big change. Earlier biometric implementations were largely front-end methods that simplified authentication. Under the hood, the system used biometrics to access a password, which it then used for authentication behind the scenes. Biometrics may have provided convenience but not necessarily enterprise-grade authentication. Microsoft has been evangelizing the importance of enterprise-grade biometric sensors to the OEMs that create Windows 10 Mobile devices. These facial-recognition and iris-scanning sensors are fully supported by MFA features such as Microsoft Passport and Windows Hello. In the future, Microsoft expects OEMs to produce even more advanced enterprise-grade biometric sensors and to continue to integrate them into mobile devices. As a result, biometrics will become a commonplace authentication method as part of an MFA system. + ### Enterprise-grade secure Windows startup + UEFI with Secure Boot uses hardware technologies to help protect users from bootkits. Secure Boot can validate the integrity of the devices, firmware, and bootloader. After the bootloader launches, users must rely on the operating system to protect the integrity of the remainder of the system. + ### Trusted Boot + When UEFI with Secure Boot verifies that it trusts the bootloader and starts Windows 10 Mobile, the Windows Trusted Boot feature protects the rest of the startup process by verifying that all Windows startup components are trustworthy (for example, signed by a trusted source) and have integrity. The bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, and startup files. + If someone has modified a file (for example, if malware has tampered with it or it has been corrupted), Trusted Boot will detect the problem and attempt to automatically repair the corrupted component. When repaired, Windows will start normally after only a brief delay. + ### Measured Boot + The biggest challenge with rootkits and bootkits in earlier versions of Windows was that they could frequently be undetectable to the client. Because they often started before Windows defenses and the antimalware solution—and they had system-level privileges—rootkits and bootkits could completely disguise themselves while continuing to access system resources. Although UEFI with Secure Boot and Trusted Boot could prevent most rootkits and bootkits, intruders could still potentially exploit a few attack vectors (for example, if someone compromised the signature used to sign a boot component, such as a non-Microsoft driver, and used it to sign a malicious one). Windows 10 Mobile implements the Measured Boot feature, which uses the TPM hardware component to record a series of measurements for critical startup-related components, including firmware, Windows boot components, and drivers. Because Measured Boot uses the hardware-based security capabilities of TPM, which isolates and protects the measurement data against malware attacks, the log data is well protected against even sophisticated attacks. Measured Boot focuses on acquiring the measurement data and protecting it against tampering. You must couple it, however, with a service that can analyze the data to determine device health and provide a more complete security service. The next section introduces just such a service. + ### Device health attestation + Device health attestation is new feature in Windows 10 Mobile that helps prevent low-level malware infections. Device health attestation uses a device’s TPM and firmware to measure the critical security properties of the device’s BIOS and Windows startup processes. These measurements are made in such a way that even on a system infected with kernel-level malware or a rootkit, an attacker is unlikely to spoof the properties. You can integrate Device health attestation with Microsoft Intune or non-Microsoft MDM solutions and combine these hardware-measured security properties with other device properties to gain an overall view of the device’s health and compliance state. From there, you can use this integration in a variety of scenarios, from detecting jailbroken devices to monitoring device compliance, generating compliance reports, alerting users or administrators, initiating corrective action on the device, and managing conditional access to resources such as Office 365. + ### Conditional Access + The example that follows shows how Windows 10 protective measures integrate and work with Intune and non-Microsoft MDM solutions. It demonstrates how the phone security architecture in Windows 10 Mobile helps you monitor and verify compliance and how the security and trust rooted in the device hardware protect corporate resources end to end. + When a user turns on a phone: 1. The Secure Boot feature in Windows 10 Mobile helps protect the startup sequence, allows the device to boot into a defined and trusted configuration, and loads a factory-trusted boot loader. 2. Windows 10 Mobile Trusted Boot takes control when the Secure Boot process is complete, verifying the digital signature of the Windows kernel and the components that are loaded and executed during the startup process. @@ -282,94 +372,168 @@ When a user turns on a phone: 5. HAS reviews the audit trails, issues an encrypted and signed report, and forwards it to the device. 6. From your Device health attestation-enabled MDM solution, you can review the report in a protected, tamper-resistant, and tamper-evident communication channel to assess whether the device is running in a compliant (healthy) state, allow access, or trigger corrective action aligned with the organization’s security needs and policies. Because this solution can detect and prevent low-level malware that may be extremely difficult to detect any other way, Microsoft recommends that you consider implementing a Device health attestation-enabled MDM system like Intune that takes advantage of the Windows 10 Mobile cloud-based health attestation server feature to detect and block devices infected with advanced malware. + ## App platform security + Applications built for Windows are designed to be secure and free of defects, but the reality is that human error can create vulnerabilities in code. When malicious users and software identify such vulnerabilities, they may attempt to manipulate data in memory in the hope that they can compromise the system and take control. + To mitigate these risks, Windows 10 Mobile includes a series of improvements to make it more difficult for malware to compromise the device. Windows 10 Mobile even enables organizations to choose which apps are allowed to run on mobile devices. In addition, it includes improvements that can dramatically reduce the likelihood that newly discovered vulnerabilities can be successful exploited. It takes detailed knowledge of operating system architecture and malware exploit techniques to fully appreciate the impact of these improvements, but the sections that follow explain them at a high level. + ### Device Guard + Device Guard is a feature set that consists of both hardware and software system integrity-hardening features. These features revolutionize Windows operating system security by moving the entire operating system to a trust-nothing model. + All apps on Windows 10 Mobile must be digitally signed and come from Windows Store or a trusted enterprise store. Device Guard implements policies that further restrict this. By default, Device Guard supports all apps from Windows Store. You can create policies that define the apps that can and cannot run on the Windows 10 Mobile device. If the app doesn’t have a digital signature or is prevented by policy, or it does not come from a trusted store, it will not run on Windows 10 Mobile. + Advanced hardware features (described earlier in the [Enterprise-grade secure hardware](#secure-hardware) section) drive these security offerings. By integrating these hardware features further into the core operating system, Windows 10 Mobile can use them in new ways. To deliver this additional security, Device Guard requires UEFI with Secure Boot. + ### AppContainer + The Windows 10 Mobile security model is based on the principle of least privilege and uses isolation to achieve it. Every app and even portions of the operating system itself run inside their own isolated sandbox called an AppContainer—a secured isolation boundary within which an app and its processes can run. Each AppContainer is defined and implemented through a security policy. + The security policy of a specific AppContainer defines the operating system capabilities that apps have access to from within the AppContainer. A capability is a Windows 10 Mobile device resource such as geographical location information, camera, microphone, networking, and sensors. + A set of default permissions are granted to all AppContainers, including access to a unique, isolated storage location. In addition, access to other capabilities can be declared within the app code itself. Access to additional capabilities and privileges cannot be requested at run time, as can be done with traditional desktop applications. + The AppContainer concept is advantageous for the following reasons: + - **Attack surface reduction.** Apps can access only those capabilities that are declared in the application code and needed to perform their functions. - **User consent and control.** Capabilities that apps use are automatically published to the app details page in the Windows Store. App access to capabilities that may expose sensitive information automatically prompt the user to acknowledge and provide consent. - **App isolation.** Communication between Windows apps is tightly controlled. Apps are isolated from one another and can communicate only by using predefined communications channels and data types. + Apps receive the minimal privileges they need to perform their legitimate tasks. This means that even if a malicious attacker exploits an app, the potential damage is limited because the app cannot elevate its privileges and is contained within its AppContainer. Windows Store displays the permissions that the app requires along with the app’s age rating and publisher. + The combination of Device Guard and AppContainer help to prevent unauthorized apps from running. In the event malware slips into the app ecosystem, the AppContainer helps to constrain the app and limit potential damage. The Windows 10 Mobile trust-nothing model doesn’t assume that any component is perfect, however, potential vulnerabilities in apps, AppContainers, and Windows 10 Mobile itself could give an attacker a chance to compromise a system. For this reason, we need redundant vulnerability mitigations. The next several topics describe some of the redundant mitigations in Windows 10 Mobile. + ### Address Space Layout Randomization One of the most common techniques attackers use to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data reside, and then overwrite that information with a malicious payload. In the early days of operating systems, any malware that could write directly to the system memory could do such a thing; the malware would simply overwrite system memory in well-known and predictable locations. + Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 3 illustrates how ASLR works, showing how the locations of different critical Windows components can change in memory between restarts. + ![figure 3](images/mobile-security-guide-figure3.png) + Figure 3. ASLR at work + Microsoft has substantively improved the ASLR implementation in Windows 10 Mobile over previous versions, especially with 64-bit system and application processes that can take advantage of a vastly increased memory space, making it even more difficult for malware to predict where Windows 10 Mobile stores vital data. When used on systems that have TPMs, ASLR memory randomization will be increasingly unique across devices, making it even more difficult for a successful exploit that works on one system to work reliably on another. Microsoft also holistically applied ASLR across the entire system in Windows 10 Mobile rather than it working only on specific apps. + ### Data Execution Prevention + Malware depends on its ability to put a malicious payload into memory with the hope that an unsuspecting user will execute it later. ASLR makes that much more difficult. + Extending that protection, it would be great if you could prevent malware from running if it wrote to an area that you have allocated solely for the storage of information. Data Execution Prevention (DEP) does exactly that, substantially reducing the range of memory that malicious code can use for its benefit. DEP uses the **No execute** bit on modern CPUs to mark blocks of memory as read only so that malware can’t use those blocks to execute malicious code. All Windows 10 and Windows 10 Mobile devices support DEP. + ### Windows heap + The heap is a location in memory that Windows uses to store dynamic application data. Microsoft continues to improve on earlier Windows heap designs by further mitigating the risk of heap exploits that an attacker could use. Windows 10 Mobile has several important improvements to the security of the heap over previous versions of Windows: + - Internal data structures that the heap uses are better protected against memory corruption. - Heap memory allocations have randomized locations and sizes, making it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, Windows 10 Mobile adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable. - Windows 10 Mobile uses “guard pages” before and after blocks of memory as tripwires. If an attacker attempts to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and Windows 10 Mobile responds by instantly terminating the app. + ### Memory reservations + Microsoft reserves the lowest 64 KB of process memory for the operating system. Apps are no longer allowed to allocate that portion of the memory, which makes it more difficult for malware to overwrite critical system data structures in memory. + ### Control Flow Guard + When Windows loads applications into memory, it allocates space to those applications based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls additional code located in other memory addresses. The relationships among the code locations are well known—they are written in the code itself—but until Windows 10 Mobile, the operating system didn’t enforce the flow among these locations, giving attackers the opportunity to change the flow to meet their needs. In other words, an application exploit takes advantage of this behavior by running code that the application may not typically run. Windows 10 Mobile mitigates this kind of threat through the Control Flow Guard (CFG) feature. When a trusted application that its creator compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If CFG doesn’t trust the location, it immediately terminates the application as a potential security risk. + You cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when he or she compiles the application. Consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. Of course, browsers are a key entry point for attacks; thus Microsoft Edge and other Windows features take full advantage of CFG. + ### Protected processes + In general, preventing a computer security incident is more cost-effective than repairing the damage an incident can cause. For malware in particular, most security controls are designed to prevent an attack from being initially successful. The reasoning is that if malware cannot infect the system, the system is immune to malware. + Unfortunately, no device is immune to malware. Despite all the best preventative controls, malware can eventually find a way to infect any operating system or hardware platform. So, although prevention with a defense-in-depth strategy is important, it cannot be the only type of malware control. + The key security scenario is to assume that malware is running on a system but limit what it can do. Windows 10 Mobile has security controls and design features in place to reduce compromise from existing malware infections. Protected Processes is one such feature. + With Protected Processes, Windows 10 Mobile prevents untrusted processes from interacting or tampering with those that have been specially signed. Protected Processes defines levels of trust for processes: it prevents less trusted processes from interacting with and therefore attacking more trusted processes. Windows 10 Mobile uses Protected Processes more broadly across the operating system. + ### Store for Business + Store for Business allows IT pros to find, acquire, distribute, and manage apps for their organization. The model provides flexible ways to distribute apps, depending on the size of your organization, and does not require additional infrastructure in some scenarios. + UWP apps are inherently more secure than typical applications because they are sandboxed, which restricts the app’s risk of compromise or tampering with in a way that would put the system, data, and other applications at risk. Windows Store can further reduce the likelihood that malware will infect devices by reviewing all applications that enter the Windows Store ecosystem before making them available. Store for Business extends this concept by enabling you to distribute custom LOB apps, and even some Windows Store apps, to Windows 10 Mobile devices through the same Windows Store infrastructure. + Regardless of how users acquire UWP apps, they can use them with increased confidence. UWP apps run in an AppContainer sandbox with limited privileges and capabilities. For example, the apps have no system-level access, have tightly controlled interactions with other apps, and have no access to data unless the user explicitly grants the application permission. + In addition, all UWP apps follow the security principle of least privilege. Apps receive only the minimum privileges they need to perform their legitimate tasks, so even if an attacker exploits an app, the damage the exploit can do is significantly limited and should be contained within the sandbox. Windows Store displays the exact capabilities the app requires (for example, access to the camera), along with the app’s age rating and publisher. + The Windows Store app-distribution process and the app sandboxing capabilities of Windows 10 Mobile can dramatically reduce the likelihood that users encounter malicious apps on the system. + For more information about Store for Business, see [Windows Store for Business overview](../whats-new/windows-store-for-business-overview.md). + ### App management + An enterprise typically exerts some configuration and control over the apps installed on devices. In this way, the organization accomplishes several business goals, such managing software licenses, ensuring mandatory app deployment on required devices, and preventing the installation of unacceptable apps on corporate devices. + An important component in delivering on these goals is Store for Business, which builds on the Windows Store infrastructure that Microsoft hosts and enables you to deploy Windows Store apps across your Windows 10-based devices. Store for Business is both powerful and highly flexible. It allows you to extend and customize features without having to stand up new on-premises infrastructure. It supports and integrates with your existing MDM service but doesn’t require one. (Ask your MDM service vendor about integration with Store for Business.) You can configure Store for Business for a wide variety of scenarios, including online and offline licensing and different app-distribution options. For a more detailed description of the available Store for Business scenarios, see [Windows Store for Business overview](../whats-new/windows-store-for-business-overview.md). + A web-based portal for IT pros simplifies Windows 10 Mobile app deployment. The familiar look of Windows Store was used to design the Store for Business experience. It showcases apps relevant to business use, hand-selected and sorted by category. The store can use Azure AD accounts for all users, linking them to a single, unique organizational identity. + Another key benefit is licensing. Store for Business enables you to track and manage licenses for all UWP apps. You can easily determine which users have installed specific apps, track remaining licenses left, and acquire new licenses directly through the web interface. Those new licenses are added within Store for Business and do not require complex export and import processes. As long as your clients are online and have Internet connectivity, the licensing scenario with Store for Business is a great improvement over manual licensing tasks. + Store for Business allows you to find the right apps for your users, acquire them, manage app licenses, and distribute apps to individuals. The best way to understand Store for Business is to look at the steps involved in a common scenario: delivering apps to Windows 10 Mobile users without an MDM—specifically, deploying apps to Windows 10 Mobile users. In this scenario, you identify several apps that must be on each mobile device that are currently available for free in the Windows Store (for example, a VPN app for your Dell SonicWALL solution) and some internally developed LOB apps. + ### The IT side + You begin the app deployment process by preparing the private store and the apps before your users receive their new Windows 10 Mobile devices. + First, you open [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkId=722910) and use an Azure AD account to log in. This account is linked to the company’s unique organizational identity and must have an Azure AD tenant. In addition, the account must have Azure AD Enterprise Admin permissions if this is the first time you’re using Store for Business. You can delegate later access through permissions within Store for Business. Next, you locate and acquire any apps you want to deploy to the mobile devices, adding the apps and licenses to the organization’s inventory. + Along with existing Windows Store apps, you can use Store for Business to manage custom LOB apps that are developed for your organization. First, you grant permission for a trusted app developer to submit the apps. You and the developer submit these apps through the [Windows Dev Center](http://go.microsoft.com/fwlink/p/?LinkId=722911), and they must be digitally signed with a trusted certificate. These apps are not published to the retail Windows Store catalog and are not visible to anyone outside the organization. + You can deliver the apps through a private store within Windows Store. The next step, then, is for you to mark the app to be available in the private store, which you do through the Store for Business web portal. + Alternatively, you can choose one of two other app-distribution options in Store for Business web portal: - Assign the app to people in your organization by selecting one or more Azure AD identities - Add the app to the organization’s private store, and allow all users to discover and install it. For details about app distribution, see [Distribute apps using your private store](../manage/distribute-apps-from-your-private-store.md). + The IT process for preparing Store for Business for app deployment is shown in Figure 4. + ![figure 4](images/mobile-security-guide-figure4.png) + Figure 4. The IT process for Store for Business + For details about the process of distributing apps through Store for Business, see [Find and acquire apps](../manage/find-and-acquire-apps-overview.md). + ### The user side + After you have prepared Store for Business, the user side of the process takes over. This side of the process is designed to be user friendly, with the primary app deployment method—through Store for Business—streamlined and straightforward. This process doesn’t require an MDM system or any on-premises infrastructure. In fact, the user never sees the “for Business” label, just the familiar Windows Store. + 1. The user opens the Windows Store app on his or her Windows 10 Mobile device. + 2. The same Windows Store interface appears, with the addition of the private store you created. The private store appears as a new page, similar to Games and Music. The interface integrates the public Windows Store with the organization’s private store, which contains curated apps. + 3. The user simply selects and installs apps as usual. + If the user wants to make a private purchase of apps, music, movies, or TV shows with his or her Microsoft account, that’s an option, as well. The user pays for and owns his or her purchase, independent of the company. This flexibility enables hybrid scenarios for devices in many bring your own device environments. + ### Microsoft Edge + Windows 10 Mobile includes critical improvements designed to thwart attacks and malware. The environment is now more resistant to malware thanks to significant improvements to SmartScreen Filters. Internet browsing is a safer experience thanks to Microsoft Edge, a completely new browser. + Windows 10 Mobile includes Microsoft Edge, an entirely new web browser that goes beyond browsing with features like Reading View. Microsoft Edge is more secure than previous Microsoft web browsers in several ways: - **Microsoft Edge does not support non-Microsoft binary extensions.** Microsoft Edge supports Flash content and PDF viewing by default through built-in extensions but includes no non-Microsoft binary extensions, such as ActiveX controls or Java. - **Microsoft Edge is designed as a UWP app.** It is inherently compartmentalized and runs in an AppContainer that sandboxes the browser from the system, data, and other apps. - **Microsoft Edge simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, fewer security settings are required. In addition, Microsoft established Microsoft Edge default settings that align with security best practices, making it more secure by design. + The web browser is a critical component of any security strategy, and for good reason: it is the user’s interface to the Internet, an environment teeming with malicious sites and nefarious content. Most users cannot perform at least part of their job without a browser, and many users are completely reliant on one. This reality has made the browser the number one pathway from which malicious hackers initiate their attacks. + ## Related topics + + [Windows 10 security overview](windows-10-security-guide.md) + [Windows 10 Mobile and MDM](../manage/windows-10-mobile-and-mdm.md) + [Windows 10 and Windows 10 Mobile](../index.md) + [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkId=722910) + [Windows Store for Business overview](../whats-new/windows-store-for-business-overview.md) -  -  diff --git a/windows/keep-secure/windows-10-security-guide.md b/windows/keep-secure/windows-10-security-guide.md index 2e8afda0f6..2c0402513c 100644 --- a/windows/keep-secure/windows-10-security-guide.md +++ b/windows/keep-secure/windows-10-security-guide.md @@ -2,28 +2,37 @@ title: Windows 10 security overview (Windows 10) description: This guide provides a detailed description of the most important security improvements in the Windows 10 operating system, with links to more detailed articles about many of its security features. ms.assetid: 4561D80B-A914-403C-A17C-3BE6FC95B59B -ms.pagetype: security -keywords: ["configure", "feature", "file encryption"] +keywords: configure, feature, file encryption ms.prod: W10 ms.mktglfcycl: manage ms.sitesec: library +ms.pagetype: security author: challum --- + # Windows 10 security overview + **Applies to** - Windows 10 + This guide provides a detailed description of the most important security improvements in the Windows 10 operating system, with links to more detailed articles about many of its security features. Wherever possible, specific recommendations are provided to help you implement and configure Windows 10 security features. + ## Introduction + Windows 10 is designed to protect against known and emerging security threats across the spectrum of attack vectors. Three broad categories of security work went into Windows 10: - [**Identity and access control**](#identity) features have been greatly expanded to both simplify and enhance the security of user authentication. These features include Windows Hello and Microsoft Passport, which better protect user identities through easy-to-deploy and easy-to-use multifactor authentication (MFA). Another new feature is Credential Guard, which uses virtualization-based security (VBS) to help protect the Windows authentication subsystems and users’ credentials. - [**Information protection**](#information) that guards information at rest, in use, and in transit. In addition to BitLocker and BitLocker To Go for protection of data at rest, Windows 10 includes file-level encryption with Enterprise Data Protection that performs data separation and containment and, when combined with Rights Management services, can keep data encrypted when it leaves the corporate network. Windows 10 can also help keep data secure by using virtual private networks (VPNs) and Internet Protocol Security. - [**Malware resistance**](#malware) includes architectural changes that can isolate critical system and security components from threats. Several new features in Windows 10 help reduce the threat of malware, including VBS, Device Guard, Microsoft Edge, and an entirely new version of Windows Defender. In addition, the many antimalware features from the Windows 8.1 operating system— including AppContainers for application sandboxing and numerous boot-protection features, such as Trusted Boot—have been carried forward and improved in Windows 10. + ## Identity and access control + Traditionally, access control is a process that has three components: - **Identification** - when a user asserts a unique identity to the computer system for the purpose of gaining access to a resource, such as a file or a printer. In some definitions, the user is called the subject and the resource is the object. - **Authentication** - the process of proving the asserted identity and verification that the subject is indeed *the* subject. - **Authorization** - performed by the system to compare the authenticated subject’s access rights against the object’s permissions and either allow or deny the requested access. + The way these components are implemented makes the difference in stopping attackers from accessing secret data. Only a user who proves his or her identity – and is authorized to access that data – will access it. But in security, there are varying degrees of identity proof and many different requirements for authorization limits. The access control flexibility needed in most corporate environments presents a challenge for any operating system. Table 1 lists typical Windows access control challenges and the Windows 10 solutions. + Table 1. Windows 10 solutions to typical access control challenges @@ -63,40 +72,73 @@ Table 1. Windows 10 solutions to typical access control challenges
  The sections that follow describe these challenges and solutions in more detail. + **Microsoft Passport** + Microsoft Passport provides strong two-factor authentication (2FA), fully integrated into Windows, and replaces passwords with the combination of an enrolled device and either a PIN or Windows Hello. Microsoft Passport is conceptually similar to smart cards but more flexible. Authentication is performed by using an asymmetric key pair instead of a string comparison (for example, password), and the user’s key material can be secured by using hardware. Unlike smart cards, Microsoft Passport does not require the extra infrastructure components required for smart card deployment. In particular, you do not need public key infrastructure (PKI). If you already use PKI – for example, in secure email or VPN authentication – you can use the existing infrastructure with Microsoft Passport. Microsoft Passport combines the major advantages of smart card technology – deployment flexibility for virtual smart cards and robust security for physical smart cards – without any of their drawbacks. + Microsoft Passport offers three significant advantages over the current state of Windows authentication: It’s more flexible, it’s based on industry standards, and it effectively mitigates risks. The sections that follow look at each of these advantages in more detail. + **It’s flexible** + Microsoft Passport offers unprecedented flexibility. Although the format and use of passwords and smart cards is fixed, Microsoft Passport gives both administrators and users options to manage authentication. First and foremost, Microsoft Passport works with biometric sensors and PINs. Next, you can use your PC or even your phone as one of the factors to authenticate on your PC. Finally, your user credentials can come from your PKI infrastructure, or Windows can create the credential itself. + Microsoft Passport gives you options beyond long, complex passwords. Instead of requiring users to memorize and retype frequently-changed passwords, Microsoft Passport enables PIN- and biometrics-based authentication through Windows Hello to securely identify users. + With Microsoft Passport, you gain flexibility in the data center, too. To deploy it, you must add Windows Server 2016 domain controllers to your Active Directory environment, but you do not have to replace or remove your existing Active Directory servers: Microsoft Passport builds on and adds to your existing infrastructure. You can either add on premises servers or use Microsoft Azure Active Directory to deploy Microsoft Passport to your network. The choice of which users to enable for Microsoft Passport use is completely up to you – you choose which items to protect and which authentication factors you want to support. This flexibility makes it easy to use Microsoft Passport to supplement existing smart card or token deployments by adding 2FA to users who do not currently have it, or to deploy Microsoft Passport in scenarios that call for extra protection for sensitive resources or systems. + **It’s standardized** + Both software vendors and enterprise customers have come to realize that proprietary identity and authentication systems are a dead end: The future lies with open, interoperable systems that allow secure authentication across a variety of devices, line of business (LOB) apps, and external applications and websites. To this end, a group of industry players formed FIDO, the Fast IDentity Online Alliance. The FIDO Alliance is a nonprofit organization intended to address the lack of interoperability among strong authentication devices, as well as the problems users face when they need to create and remember multiple user names and passwords. The FIDO Alliance plans to change the nature of authentication by developing specifications that define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to securely authenticate users of online services. This new standard for security devices and browser plug ins will allow any website or cloud application to interface with a broad variety of existing and future FIDO-enabled devices that the user has for online security. + In 2014, Microsoft joined the board of the [FIDO Alliance](http://go.microsoft.com/fwlink/p/?LinkId=626934). FIDO standards enable a universal framework that a global ecosystem delivers for a consistent and greatly improved user experience of strong password-less authentication. The FIDO 1.0 specifications, published in December 2014, provide for two types of authentications: password-less (known as UAF) and second factor (U2F). The FIDO Alliance is working on a set of 2.0 proposals that incorporate the best ideas from its U2F and UAF FIDO 1.0 standards, and of course, on new ideas. Microsoft has contributed Microsoft Passport technology to the FIDO 2.0 specification workgroup for review and feedback and continues to work with the FIDO Alliance as the FIDO 2.0 specification moves forward. Interoperability of FIDO products is a hallmark of FIDO authentication. Microsoft believes that bringing a FIDO solution to market will help solve a critical need for enterprises and consumers alike. + **It’s effective** + Microsoft Passport effectively mitigates two major security risks. First, it eliminates the use of passwords for logon and so reduces the risk that a nefarious attacker will steal and reuse the user’s credentials. User key material is generated and available within the Trusted Platform Module (TPM) of the user device, which protects it from attackers who want to capture the key material and reuse it. Second, because Microsoft Passport uses asymmetrical key pairs, users credentials can’t be stolen in cases where the identity provider or websites the user accesses have been compromised. + To compromise a Microsoft Passport credential that TPM protects, an attacker must have access to the physical device, and then must find a way to spoof the user’s biometrics or guess his or her PIN—and all of this must be done before TPM anti-hammer capabilities lock the device. This sets the bar magnitudes of order higher than password phishing attacks. + ### + **Windows Hello** + Windows Hello is the name given to the new biometric sign-in option for Microsoft Passport. Because biometric authentication is built directly into the operating system, Windows Hello allows users to unlock their devices by using their face or fingerprint. From here, authentication to the devices and resources is enabled through a combination of the user’s unique biometric identifier and the device itself. + The user’s biometric data that is used for Windows Hello is considered a local gesture and consequently doesn’t roam among a user’s devices and is not centrally stored. The biometric image of the user the sensor takes is converted into an algorithmic form that cannot be converted back into the original image that the sensor took. Devices that have TPM 2.0 encrypt the biometric data in a form that makes it unreadable if the data is ever removed from the device. If multiple users share a device, each user will be able to enroll and use Windows Hello for his or her Windows profile. + Windows Hello supports two biometric sensor options that are suitable for enterprise scenarios: + - **Facial recognition** uses special infrared cameras to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major manufacturers are already shipping integrated devices with facial-recognition technology. - **Fingerprint recognition** uses a fingerprint sensor to scan the user’s fingerprint. Although fingerprint readers have been available for computers running Windows for years, the detection, antispoofing, and recognition algorithms in Windows 10 are more advanced than previous Windows versions. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) can be used with Windows Hello. -Windows Hello offers several major benefits. First, it addresses the problems of credential theft and sharing, because an attacker must obtain the device and impersonate the user’s biometric identity, which is more difficult than stealing a password or PIN. Second, the use of biometrics gives users an authenticator that’s always with them – there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for logging in to all their Windows devices. Finally, there’s nothing additional to deploy or manage. Because Windows Hello support is built directly into the operating system, there are no additional drivers to deploy. + +Windows Hello offers several major benefits. First, it addresses the problems of credential theft and sharing, because an attacker must obtain the device and impersonate the user’s biometric identity, which is more difficult than stealing a password or PIN. Second, the use of biometrics gives users an authenticator that’s always with them – there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for logging in to all their Windows devices. Finally, there’s nothing additional to deploy or manage. Because Windows Hello support is built directly into the operating system, +there are no additional drivers to deploy. + **Brute-force attack resistance** + A brute-force attack is the process used to break into a device simply by guessing a user’s password, PIN, or even his or her biometric identity over and over until the attacker gets it right. Over the last several versions of Windows, Microsoft has added features that dramatically reduce the chances that such an attack would succeed. + The Windows 7 operating system and previous versions defended against brute-force attacks in a straightforward way: they slowed or prevented additional guesses after multiple mistakes. When users use a full password to log on, Windows forces users to wait several seconds between attempts if they type their password incorrectly multiple times. You can even choose to have Windows lock out an account for a period of time when it detects a brute-force attack. Windows 8.1 and Windows 10 support an even more powerful – but optional – form of brute-force protection when the credentials are tied to TPM. If the operating system detects a brute-force attack against the Windows sign-in and BitLocker protects the system drive, Windows can automatically restart the device and put it in BitLocker recovery mode until someone enters a recovery key password. This password is a virtually unguessable 48-character recovery code that must be used before Windows will be able to start normally. + If you’re interested in learning how to configure brute-force protection, use a test Windows 10 PC on which BitLocker protection is enabled for the system drive, and then print the BitLocker recovery key to ensure that you have it available. Then, open the Local Group Policy Editor by running **gpedit.msc**, and go to Computer Configuration\\Windows Settings\\Security Settings\\Security Options. Open the policy **Interactive Login: Machine Account Lockout Threshold**, and set the value to **5**, as shown in Figure 1. + ![figure 1](images/security-fig1-invalidaccess.png) + Figure 1. Set the number of invalid access attempts prior to lockout + Now, your PC is configured with brute-force protection. Restart your PC. When prompted to log on, mistype your password until the PC restarts. Now, try to guess the 48-character recovery key. You will be glad you printed it out beforehand. + ## Information protection + When users travel, their organization’s confidential data goes with them. Wherever confidential data is stored, it must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000 operating system. More recently, BitLocker has provided encryption for full drives and portable drives; in Windows 10, BitLocker will even protect individual files, with data loss prevention capabilities. Windows consistently improves data protection by improving existing options and by providing new strategies. + Table 2 lists specific data-protection concerns and how they are addressed in Windows 10 and Windows 7. + Table 2. Data Protection in Windows 10 and Windows 7 + @@ -147,20 +189,29 @@ Table 2. Data Protection in Windows 10 and Windows 7
  The sections that follow describe these improvements in more detail. + **Prepare for drive and file encryption** + The best type of security measures are transparent to the user during implementation and use. Every time there is a possible delay or difficulty because of a security feature, there is strong likelihood that users will try to bypass security. This situation is especially true for data protection, and that’s a scenario that organizations need to avoid. Whether you’re planning to encrypt entire volumes, removable devices, or individual files, Windows 10 meets your needs by providing streamlined, usable solutions. In fact, you can take several steps in advance to prepare for data encryption and make the deployment quick and smooth. + **TPM pre-provisioning** + In Windows 7, preparing the TPM for use offered a couple of challenges: - You can turn on the TPM in the BIOS, which requires someone to either go into the BIOS settings to turn it on or to install a driver to turn it on from within Windows. - When you enable the TPM, it may require one or more restarts. Basically, it was a big hassle. If IT staff were provisioning new PCs, they could handle all of this, but if you wanted to add BitLocker to devices that were already in users’ hands, those users would have struggled with the technical challenges and would either call IT for support or simply leave BitLocker disabled. Microsoft includes instrumentation in Windows 10 that enables the operating system to fully manage the TPM. There is no need to go into the BIOS, and all scenarios that required a restart have been eliminated. + **Deploy hard drive encryption** + BitLocker is capable of encrypting entire hard drives, including both system and data drives. BitLocker pre-provisioning can drastically reduce the time required to provision new PCs with BitLocker enabled. With Windows 10, administrators can turn on BitLocker and the TPM from within the Windows Preinstallation Environment before they install Windows or as part of an automated deployment task sequence without any user interaction. Combined with Used Disk Space Only encryption and a mostly empty drive (because Windows is not yet installed), it takes only a few seconds to enable BitLocker. With earlier versions of Windows, administrators had to enable BitLocker after Windows had been installed. Although this process could be automated, BitLocker would need to encrypt the entire drive, a process that could take anywhere from several hours to more than a day depending on drive size and performance, which significantly delayed deployment. Microsoft has improved this process through multiple features in Windows 10. + **Device encryption** + Beginning in Windows 8.1, Windows automatically enables BitLocker device encryption on devices that support InstantGo. With Windows 10, Microsoft offers device encryption support on a much broader range of devices, including those that are InstantGo. Microsoft expects that most devices in the future will pass the testing requirements, which makes device encryption pervasive across modern Windows devices. Device encryption further protects the system by transparently implementing device-wide data encryption. + Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. The following list outlines how this happens: - When a clean installation of Windows 10 is completed and the out-of-box experience is finished, the computer is prepared for first use. As part of this preparation, device encryption is initialized on the operating system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker suspended state). - If the device is not domain joined, a Microsoft account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key by using his or her Microsoft account credentials. @@ -171,25 +222,36 @@ Microsoft recommends that device encryption be enabled on any systems that suppo - **Value**: PreventDeviceEncryption equal to True (1) - **Type**: REG\_DWORD Administrators can manage domain-joined devices that have device encryption enabled through Microsoft BitLocker Administration and Monitoring (MBAM). In this case, device encryption automatically makes additional BitLocker options available. No conversion or encryption is required, and MBAM can manage the full BitLocker policy set if any configuration changes are required. + **Used Disk Space Only encryption** + BitLocker in earlier Windows versions could take a long time to encrypt a drive, because it encrypted every byte on the volume (including parts that did not have data). That is still the most secure way to encrypt a drive, especially if a drive has previously contained confidential data that has since been moved or deleted, in which case traces of the confidential data could remain on portions of the drive marked as unused. But why encrypt a new drive when you can simply encrypt the data as it is being written? To reduce encryption time, BitLocker in Windows 10 lets users choose to encrypt just their data. Depending on the amount of data on the drive, this option can reduce encryption time by more than 99 percent. Exercise caution when encrypting only used space on an existing volume on which confidential data may have already been stored in an unencrypted state, however, because those sectors can be recovered through disk-recovery tools until they are overwritten by new encrypted data. In contrast, encrypting only used space on a brand-new volume can significantly decrease deployment time without the security risk because all new data will be encrypted as it is written to the disk. + **Encrypted hard drive support** + SEDs have been available for years, but Microsoft couldn’t support their use with some earlier versions of Windows because the drives lacked important key management features. Microsoft worked with storage vendors to improve the hardware capabilities, and now BitLocker supports the next generation of SEDs, which are called encrypted hard drives. Encrypted hard drives provide onboard cryptographic capabilities to encrypt data on drives, which improves both drive and system performance by offloading cryptographic calculations from the PC’s processor to the drive itself and rapidly encrypting the drive by using dedicated, purpose-built hardware. If you plan to use whole-drive encryption with Windows 10, Microsoft recommends that you investigate hard drive manufacturers and models to determine whether any of their encrypted hard drives meet your security and budget requirements. For more information about encrypted hard drives, see [Encrypted Hard Drive](http://go.microsoft.com/fwlink/p/?LinkId=733880). + **Preboot information protection** + An effective information protection implementation, like most security controls, considers usability as well as security. Users typically prefer a simple security experience. In fact, the more transparent a security solution becomes, the more likely users are to conform to it. It is crucial that organizations protect information on their PCs regardless of the state of the computer or the intent of users. This protection should not be cumbersome to users. One undesirable and previously commonplace situation is when the user is prompted for input during preboot, and then again during Windows logon. Challenging users for input more than once should be avoided. Windows 10 can enable a true SSO experience from the preboot environment on modern devices and in some cases even on older devices when robust information protection configurations are in place. The TPM in isolation is able to securely protect the BitLocker encryption key while it is at rest, and it can securely unlock the operating system drive. When the key is in use and thus in memory, a combination of hardware and Windows capabilities can secure the key and prevent unauthorized access through cold-boot attacks. Although other countermeasures like PIN-based unlock are available, they are not as user-friendly; depending on the devices’ configuration they may not offer additional security when it comes to key protection. For more information about how to configure BitLocker for SSO, see [BitLocker Countermeasures](bitlocker-countermeasures.md). + **Manage passwords and PINs** + When BitLocker is enabled on a system drive and the PC has a TPM, you can choose to require that users type a PIN before BitLocker will unlock the drive. Such a PIN requirement can prevent an attacker who has physical access to a PC from even getting to the Windows logon, which makes it virtually impossible for the attacker to access or modify user data and system files. Requiring a PIN at startup is a useful security feature because it acts as a second authentication factor (a second “something you know”). This configuration comes with some costs, however. One of the most significant is the need to change the PIN regularly. In enterprises that used BitLocker with Windows 7 and the Windows Vista operating system, users had to contact systems administrators to update their BitLocker PIN or password. This requirement not only increased management costs but made users less willing to change their BitLocker PIN or password on a regular basis. Windows 10 users can update their BitLocker PINs and passwords themselves, without administrator credentials. Not only will this feature reduce support costs, but it could improve security, too, because it encourages users to change their PINs and passwords more often. In addition, InstantGo devices do not require a PIN for startup: They are designed to start infrequently and have other mitigations in place that further reduce the attack surface of the system. For more information about how startup security works and the countermeasures that Windows 10 provides, see [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md). + **Configure Network Unlock** + Some organizations have location-specific data security requirements. This is most common in environments where high-value data is stored on PCs. The network environment may provide crucial data protection and enforce mandatory authentication; therefore, policy states that those PCs should not leave the building or be disconnected from the corporate network. Safeguards like physical security locks and geofencing may help enforce this policy as reactive controls. Beyond these, a proactive security control that grants data access only when the PC is connected to the corporate network is necessary. + Network Unlock enables BitLocker-protected PCs to start automatically when connected to a wired corporate network on which Windows Deployment Services runs. Anytime the PC is not connected to the corporate network, a user must type a PIN to unlock the drive (if PIN-based unlock is enabled). Network Unlock requires the following infrastructure: - Client PCs that have Unified Extensible Firmware Interface (UEFI) firmware version 2.3.1 or later, which supports Dynamic Host Configuration Protocol (DHCP) @@ -209,12 +271,19 @@ Part of the Microsoft Desktop Optimization Pack, MBAM makes it easier to manage - Integrates with existing management tools, such as System Center Configuration Manager. - Offers an IT-customizable recovery user experience. - Supports Windows 10. + For more information about MBAM, including how to obtain it, see [Microsoft BitLocker Administration and Monitoring](http://go.microsoft.com/fwlink/p/?LinkId=626935) on the MDOP TechCenter. + ## Malware resistance + In movies, security threats always seem to be initiated by a nefarious hacker sitting in front of a monitor with green text scrolling across it. In the real world, the vast majority of security threats occur without any human interaction at all. Just as software has automated so much of our lives, malware has automated attacks on our PCs. Those attacks are relentless. Malware is constantly changing, and when it infects a PC, it can in some cases be extremely difficult to detect and remove. + Prevention is the best bet, and Windows 10 provides strong malware resistance because it takes advantage of secure hardware, which secures the startup process, the core operating system architecture, and the desktop. + Table 3 lists specific malware threats and the mitigation that Windows 10 provides. + Table 3. Threats and Windows 10 mitigations + @@ -262,50 +331,72 @@ Table 3. Threats and Windows 10 mitigations
  The sections that follow describe these improvements in more detail. + **SMB hardening improvements for SYSVOL and NETLOGON connections** + In Windows 10 and Windows Server 2016 Technical Preview, client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers now require Server Message Block (SMB) signing and mutual authentication (such as Kerberos). - **What value does this change add?** This change reduces the likelihood of man-in-the-middle attacks. - **What works differently?** If SMB signing and mutual authentication are unavailable, a Windows 10 or Windows Server 2016 computer won’t process domain-based Group Policy and scripts. > **Note:** The registry values for these settings aren’t present by default, but the hardening rules still apply until overridden by Group Policy or other registry values. + For more information on these security improvements, (also referred to as UNC hardening), see [Microsoft Knowledge Base article 3000483](http://go.microsoft.com/fwlink/p/?LinkId=789216) and [MS15-011 & MS15-014: Hardening Group Policy](http://go.microsoft.com/fwlink/p/?LinkId=789215). **Secure hardware** + Although Windows 10 is designed to run on almost any hardware capable of running Windows 8, Windows 7, or Windows Vista, taking full advantage of Windows 10 security requires advancements in hardware-based security, including UEFI with Secure Boot, CPU virtualization features (for example, Intel VT-x), CPU memory-protection features (for example, Intel VT-d), TPM, and biometric sensors. + **UEFI with Secure Boot** + When a PC starts, it begins the process of loading the operating system by locating the bootloader on the PC’s hard drive. Without safeguards in place, the PC may simply hand control over to the bootloader without even determining whether it is a trusted operating system or malware. + UEFI is a standards-based solution that offers a modern-day replacement for the BIOS. In fact, it provides the same functionality as BIOS while adding security features and other advanced capabilities. Like BIOS, UEFI initializes devices, but UEFI components with the Secure Boot feature (version 2.3.1 or later) also ensure that only trusted firmware in Option ROMs, UEFI apps, and operating system bootloaders can start on the device. UEFI can run internal integrity checks that verify the firmware’s digital signature before running it. Because only the PC’s hardware manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI has protection from firmware bootkits. Thus, UEFI is the first link in the chain of trust. + UEFI with Secure Boot became a hardware requirement starting with Windows 8 devices. If a PC supports UEFI, it must be enabled by default. It is possible to disable the Secure Boot feature on many devices, but Microsoft strongly discourages doing so because it dramatically reduces the security of the startup process. + When a PC with UEFI and Secure Boot starts, the UEFI firmware verifies the bootloader’s digital signature to verify that it has not been modified after it was digitally signed. The firmware also verifies that a trusted authority issued the bootloader’s digital signature. This check helps to ensure that the system starts only after checking that the bootloader is both trusted and unmodified since signing. + All Windows 8 certified PCs must meet several requirements related to Secure Boot: - They must have Secure Boot enabled by default. - They must trust Microsoft’s certification authority (CA) and thus any bootloader Microsoft has signed. - They must allow the user to add signatures and hashes to the UEFI database. - They must allow the user to completely disable Secure Boot (although administrators can restrict this). + This behavior doesn’t limit the choice of operating system. In fact, users typically have three options for running non-Microsoft operating systems: -- **Use an operating system with a Microsoft-signed bootloader.** Microsoft offers a service to sign non-Microsoft bootloaders so that they can be used on the device. In this case, a signature from the Microsoft third-party UEFI CA is used to sign the non-Microsoft bootloader, and the signature itself is added to the UEFI database. Several non-Microsoft operating systems, including several varieties of Linux, have had their bootloaders signed by Microsoft so that they can take advantage of the Secure Boot capability. For more information about the Microsoft third-party UEFI signing policy, read [Microsoft UEFI CA Signing policy updates](http://go.microsoft.com/fwlink/p/?LinkId=626936) and [Pre-submission testing for UEFI submissions](http://go.microsoft.com/fwlink/p/?LinkId=626937). +- **Use an operating system with a Microsoft-signed bootloader.** Microsoft offers a service to sign non-Microsoft bootloaders so that they can be used on the device. In this case, a signature from the Microsoft third-party UEFI +CA is used to sign the non-Microsoft bootloader, and the signature itself is added to the UEFI database. Several non-Microsoft operating systems, including several varieties of Linux, have had their bootloaders signed by Microsoft so that they can take advantage of the Secure Boot capability. For more information about the Microsoft third-party UEFI signing policy, read [Microsoft UEFI CA Signing policy updates](http://go.microsoft.com/fwlink/p/?LinkId=626936) and [Pre-submission testing for UEFI submissions](http://go.microsoft.com/fwlink/p/?LinkId=626937). + **Note**   PCs configured to use Device Guard boot only a secured version of Windows and do not permit a third-party bootloader. For more information, see the [Device Guard](#device-guard) section of this document.   - **Configure UEFI to trust a non–Microsoft-signed bootloader or hashes.** Some Certified For Windows 8 or later PCs allow users to add noncertified bootloaders through a signature or hashes sent to the UEFI database, which allows them to run any operating system without Microsoft signing it. - **Turn off Secure Boot.**Windows 8 certified PCs allow users to turn off Secure Boot so they can run unsigned operating systems. In this mode, the behavior is identical to PCs that have BIOS: The PC simply runs the bootloader without any verification. Microsoft strongly recommends that Secure Boot remain enabled whenever the device starts so that it can help prevent bootkit infections. + **Note**   With Windows 10, original equipment manufacturers (OEMs) have the ability to ship built-to-order PCs that lock down UEFI Secure Boot so that it cannot be disabled and allows only the operating system of the customer’s choice to start on the device.   Windows, apps, and even malware cannot change the UEFI configuration. Instead, users must be physically present to manually boot a PC into a UEFI shell, and then change UEFI firmware settings. For more information about UEFI Secure Boot, read [Protecting the pre-OS environment with UEFI](http://go.microsoft.com/fwlink/p/?LinkId=626938). **Virtualization-based security** + One of the most powerful changes to Windows 10 is virtual-based security. Virtual-based security (VBS) takes advantage of advances in PC virtualization to change the game when it comes to protecting system components from compromise. VBS is able to isolate some of the most sensitive security components of Windows 10. These security components aren’t just isolated through application programming interface (API) restrictions or a middle-layer: They actually run in a different virtual environment and are isolated from the Windows 10 operating system itself. + VBS and the isolation it provides is accomplished through the novel use of the Hyper V hypervisor. In this case, instead of running other operating systems on top of the hypervisor as virtual guests, the hypervisor supports running the VBS environment in parallel with Windows and enforces a tightly limited set of interactions and access between the environments. + Think of the VBS environment as a miniature operating system: It has its own kernel and processes. Unlike Windows, however, the VBS environment runs a micro-kernel and only two processes called trustlets: - **Local Security Authority (LSA)** enforces Windows authentication and authorization policies. LSA is a well-known security component that has been part of Windows since 1993. Sensitive portions of LSA are isolated within the VBS environment and are protected by a new feature called Credential Guard. - **Hypervisor-enforced code integrity** verifies the integrity of kernel-mode code prior to execution. This is a part of the [Device Guard](#device-guard) feature described later in this document. VBS provides two major improvements in Windows 10 security: a new trust boundary between key Windows system components and a secure execution environment within which they run. A trust boundary between key Windows system components is enabled though the VBS environment’s use of platform virtualization to isolate the VBS environment from the Windows operating system. Running the VBS environment and Windows operating system as guests on top of Hyper-V and the processor’s virtualization extensions inherently prevents the guests from interacting with each other outside the limited and highly structured communication channels between the trustlets within the VBS environment and Windows operating system. + VBS acts as a secure execution environment because the architecture inherently prevents processes that run within the Windows environment – even those that have full system privileges – from accessing the kernel, trustlets, or any allocated memory within the VBS environment. In addition, the VBS environment uses TPM 2.0 to protect any data that is persisted to disk. Similarly, a user who has access to the physical disk is unable to access the data in an unencrypted form. + The VBS architecture is illustrated in Figure 2. + ![figure 2](images/security-fig2-vbsarchitecture.png) + Figure 2. The VBS architecture + Note that VBS requires a system that includes: - Windows 10 Enterprise Edition - A-64-bit processor @@ -314,16 +405,22 @@ Note that VBS requires a system that includes: - Virtualization extensions (for example, Intel VT-x, AMD RVI) - I/O memory management unit (IOMMU) chipset virtualization (Intel VT-d or AMD-Vi) - TPM 2.0 + **Trusted Platform Module** + A TPM is a tamper-resistant cryptographic module designed to enhance the security and privacy of computing platforms. The TPM is incorporated as a component in a trusted computing platform like a personal computer, tablet, or phone. The computing platform is specially designed to work with the TPM to support privacy and security scenarios that cannot be achieved through software alone. A proper implementation of a TPM as part of a trusted computing platform provides a hardware root of trust, meaning that the hardware behaves in a trusted way. For example, a key created in a TPM with the property that it can never be exported from the TPM really means the key cannot leave the TPM. The close integration of a TPM with a platform increases the transparency of the boot process and supports device health scenarios by enabling reliable report of the software used to start a platform. The functionality a TPM provides includes: - **Cryptographic key management.** Create, store, and permit the use of keys in defined ways. - **Safeguarding and reporting integrity measurements.** Software used to boot the platform can be recorded in the TPM and used to establish trust in the software running on the platform. - **Prove a TPM is really a TPM.** The TPM’s capabilities are so central to protecting privacy and security that a TPM needs to be able to differentiate itself from malware that masquerades as a TPM. + Microsoft combined this small list of TPM benefits with Windows 10 and other hardware security technologies to provide practical security and privacy benefits. + Among other functions, Windows 10 uses the TPM to protect the encryption keys for BitLocker volumes, virtual smart cards, certificates, and the many other keys that the TPM is used to generate. Windows 10 also uses the TPM to securely record and protect integrity-related measurements of select hardware and Windows boot components for the [Measured Boot](#measure-boot) feature described later in this document. In this scenario, Measured Boot measures each component, from firmware up through the drivers, and then stores those measurements in the PC’s TPM. From there, you can test the measurement log remotely so that a separate system verifies the boot state of the Windows 10 PC. Windows 10 supports TPM implementations that comply with either the 1.2 or 2.0 standards. Several improvements have been made in the TPM 2.0 standard, the most notable of which is cryptographic agility. TPM 1.2 is restricted to a fixed set of encryption and hash algorithms. At the time the TPM 1.2 standard was created in the early 2000s, these algorithms were considered cryptographically strong. Since that time, advances in cryptographic algorithms and cryptanalysis attacks have increased expectations for stronger cryptography. TPM 2.0 supports additional algorithms that offer stronger cryptographic protection as well as the ability to plug in algorithms that may be preferred in certain geographies or industries. It also opens the possibility for inclusion of future algorithms without changing the TPM component itself. + TPM is usually assumed to be implanted in hardware on a motherboard as a discrete module, but TPM can also be effective when implemented in firmware. Windows 10 supports both discrete and firmware TPM that complies with the 2.0 standard (1.2 can only be discrete). Windows does not differentiate between discrete and firmware-based solutions because they must meet the same requirements; therefore, any Windows feature that can take advantage of TPM can use either implementation. + **Note**   Microsoft will not initially require new Windows 10 PCs to include TPM support. Microsoft will require systems to include a TPM 2.0 beginning one year from the launch of Windows 10, however, to give manufacturers enough time to incorporate this critical functionality and to give IT pros enough time to determine which benefits they will leverage.   @@ -332,33 +429,53 @@ Several Windows 10 security features require TPM: - Measured Boot - Health attestation (requires TPM 2.0 or later) - InstantGo (requires TPM 2.0 or later) + Other Windows 10 security features like BitLocker may take advantage of TPM if it is available but do not require it to work. An example of this is Microsoft Passport. + All of these features are covered in this document. + **Biometrics** + You read in the [Windows Hello](#windows-hello) section of this document that Windows 10 has built-in support for biometric hardware. Windows has included some amount of built-in biometric support since the Windows XP operating system, so what’s different about this in Windows 10? Windows 10 makes biometrics a core security feature. Biometrics is fully integrated into the Windows 10 security components, not just tacked on as an extra part of a larger scheme. This is a big change. Earlier biometric implementations were largely front-end methods to simplify authentication. Under the hood, biometrics was used to access a password, which was then used for authentication behind the scenes. Biometrics may have provided convenience but not necessarily enterprise-grade authentication. Microsoft has evangelized the importance of enterprise-grade biometric sensors to the OEMs that create Windows PCs and peripherals. Many OEMs already ship systems that have integrated fingerprint sensors and are transitioning from swipe-based to touch-based sensors. Facial-recognition sensors were already available when Windows 10 launched and are becoming more commonplace as integrated system components. In the future, Microsoft expects OEMs to produce even more enterprise-grade biometric sensors and to continue to integrate them into systems as well as provide separate peripherals. As a result, biometrics will become a commonplace authentication method as part of an MFA system. + **Secure Windows startup** + UEFI Secure Boot uses hardware technologies to help protect users from bootkits. Secure Boot can validate the integrity of the devices, firmware, and bootloader. After the bootloader launches, users must rely on the operating system to protect the integrity of the remainder of the system. + **Trusted Boot** + When UEFI Secure Boot verifies that the bootloader is trusted and starts Windows, the Windows Trusted Boot feature protects the rest of the startup process by verifying that all Windows startup components are trustworthy (for example, signed by a trusted source) and have integrity. The bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM component. If a file has been modified (for example, if malware has tampered with it or it has been corrupted), Trusted Boot will detect the problem and automatically repair the corrupted component. When repaired, Windows will start normally after only a brief delay. + **Early Launch Antimalware** + Malware that targeted previous versions of Windows often attempted to start before the antimalware solution. To do this, some types of malware would update or replace a non-Microsoft–related driver that starts during the Windows startup process. The malicious driver would then use its system access privileges to modify critical parts of the system and disguise its presence so it could not be detected when the antimalware solution later started. Early Launch Antimalware (ELAM) is part of the Trusted Boot feature set and is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. ELAM checks the integrity of non-Microsoft drivers to determine whether the drivers are trustworthy. Because Windows needs to start as fast as possible, ELAM cannot be a complicated process of checking the driver files against known malware signatures; doing so would delay startup too much. Instead, ELAM has the simple task of examining every boot driver and determining whether it is on the list of trusted drivers. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits. ELAM also allows the registered antimalware provider to scan drivers that are loaded after the boot process is complete. The design is simple but effective. ELAM is a component of a full-featured antimalware solution, and it helps prevent malicious drivers and apps from starting before the rest of the antimalware solution starts later during the boot process. Indeed, ELAM runs only for a few seconds each time a PC starts. Windows Defender in Windows 10 supports ELAM, as does Microsoft System Center 2012 Endpoint Protection and several non-Microsoft antimalware apps. If you want to learn how to configure ELAM, you can use Group Policy settings to configure how ELAM responds to potentially malicious boot drivers. In the Group Policy Management Editor, go to Computer Configuration\\Administrative Templates\\System\\Early Launch Antimalware, and enable the **Boot-Start Driver Initialization Policy** setting. Now, you can select which driver classifications ELAM loads. When you select the **Good Only** setting, it provides the highest level of security, but test it thoroughly to ensure that it does not prevent users with healthy PCs from starting. + ### + **Measured Boot** + The biggest challenge with rootkits and bootkits in earlier versions of Windows is that they can frequently be undetectable to the client. Because they often start before Windows defenses and the antimalware solution and they have system-level privileges, rootkits and bootkits can completely disguise themselves while continuing to access system resources. Although UEFI Secure Boot and Trusted Boot can prevent most rootkits and bootkits, intruders could still potentially exploit a few attack vectors (for example, if UEFI with Secure Boot is disabled or if the signature used to sign a boot component, such as a non-Microsoft driver, has been compromised and is used to sign a malicious one). Windows 10 implements the Measured Boot feature, which uses the TPM hardware component built into newer PCs to record a series of measurements for critical startup-related components, including firmware, Windows boot components, drivers, and even the ELAM driver. Because Measured Boot leverages the hardware-based security capabilities of TPM, which isolates and protects the measurement data from malware attacks, the log data is well protected against even sophisticated attacks. + Measured Boot focuses on acquiring the measurement data and protecting it from tampering. It must be coupled with a service that can analyze the data to determine device health and provide a more complete security service. The next section introduces just such a service. + **Verify device compliance for conditional access to corporate resources** + Measured Boot itself does not prevent malware from loading during the startup process – that is the job of Secure Boot, Device Guard, and ELAM. Instead, Measured Boot provides a TPM-protected audit log that allows a trusted remote health attestation service to evaluate the PC’s startup components, state, and overall configuration. If the health attestation service detects that the PC loaded an untrustworthy component and is therefore out of compliance, the service can block the PC’s access to specific network resources or the entire network. You can even couple a health attestation service with a management system to facilitate conditional access capabilities that can initiate the quarantine and remediation processes to fix an infected PC and return it to a compliant state. + ![figure 3](images/security-fig3-healthattestation.png) + Figure 3. Health Attestation in Windows 10 + Figure 3 illustrates the following process for device compliance verification and conditional access implementation: + 1. The PC uses the TPM to record measurements of the bootloader, boot drivers, and ELAM driver. The TPM prevents anyone from tampering with these measurements, so even if malware is successfully loaded, it will not be able to modify the measurements. These measurements are signed with an Attestation Identity Key (AIK) that is stored in the TPM. Because the TPM hardware has signed the measurements, malware cannot modify them without being detected. 2. Health Attestation is not enabled by default and requires an enrollment with a mobile device management (MDM) server in order to enable it. If it is enabled, the health attestation client will contact a remote server, called a health attestation server. Microsoft provides a cloud-based Windows Health Attestation service that can help evaluate the health of a device. The health attestation client sends the signed measurements, the device’s TPM boot log, and an AIK certificate (if present), which lets the health attestation server verify that the key used to sign the measurements was issued to a trusted TPM. 3. The health attestation server analyzes the measurements and boot log and creates a statement of device health. This statement is encrypted to help ensure the confidentiality of the data. @@ -366,22 +483,35 @@ Figure 3 illustrates the following process for device compliance verification an 5. The enrolled device digitally signs the nonce with its AIK (which is stored in the TPM) and sends the MDM server the encrypted statement of device health, the digitally signed nonce, and a signed boot counter, which asserts that the device has not been restarted since it obtained the statement of health. 6. The MDM server can send the same data to the health attestation server. The server decrypts the statement of health, asserts that the boot counter in the statement matches the boot counter that was sent to the MDM server, and compiles a list of health attributes. 7. The health attestation server sends this list of health attributes back to the MDM server. The MDM server now enforces access and compliance policies if configured to do so. + For a list of data points that the health attestation server verifies, along with a description of the data, see the [HealthAttestation CSP article on MSDN](http://go.microsoft.com/fwlink/p/?LinkId=626940). The management system’s implementation determines which attributes within the statement of device health are evaluated when assessing a device’s health. Broadly speaking, the management server receives information about how the device booted, what kind of policy is enforced on the device, and how data on the device is secured. Depending on the implementation, the management server may add checks that go beyond what the statement of device health provides—for example, Windows patch level and other device attributes. Based on these data points, the management server can determine whether the client is healthy and grant it access to either a limited quarantine network or to the full network. Individual network resources, such as servers, can also grant or deny access based on whether the remote attestation client were able to retrieve a valid health certification from the remote attestation server. Because this solution can detect and prevent low-level malware that may be extremely difficult to detect any other way, Microsoft recommends that you consider the implementation of a management system, like Microsoft Intune, or any management solutions that take advantage of the Windows 10 cloud-based Health Attestation Server feature to detect and block devices that have been infected with advanced malware from network resources. + ## Secure the Windows core + Applications built for Windows are designed to be secure and free of defects, but the reality is that as long as human beings are writing code, vulnerabilities will continue to crop up. When identified, malicious users and software may attempt to exploit vulnerabilities by manipulating data in memory in the hope that they can bootstrap a successful exploit. To mitigate these risks, Windows 10 includes core improvements to make it more difficult for malware to perform buffer overflow, heap spraying, and other low-level attacks and even which code is allowed to run on the PC. In addition, these improvements dramatically reduce the likelihood that newly discovered vulnerabilities result in a successful exploit. It takes detailed knowledge of operating system architecture and malware exploit techniques to fully appreciate the impact of these improvements, but the sections that follow explain them at a high level. + ### + **Device Guard** + Today’s security threat landscape is more aggressive than ever before. Modern malicious attacks are focused on revenue generation, intellectual property theft, and targeted system degradation resulting in financial loss. Many of these nefarious attackers are sponsored by nation states that have ulterior motives and large cyber-terrorism budgets. These threats can enter a company through something as simple as an email and can permanently damage the organization’s reputation for securing employee and customer data and intellectual property, not to mention having a significant financial impact. The Windows 10 operating system introduces several new security features that help mitigate a large percentage of today’s known threats. + It is estimated that more than 300,000 new malware variants are discovered daily. Unfortunately, companies currently use an ancient method to discover this infectious software and prevent its use. In fact, current PCs trust everything that runs until antimalware signatures determine whether a threat exists; then, the antimalware software attempts to clean the PC, often after the malicious software’s effect has already occurred. This signature-based system focuses on reacting to an infection and then ensuring that that particular infection does not happen again. In this model, the system that drives malware detection relies on the discovery of malicious software; only then can a signature be provided to the client to remediate it, which implies that a computer has often already been infected. The time between detection of the malware and a client being issued a signature could mean the difference between losing data and staying safe. + In addition to antimalware solutions, “app control” or “whitelisting” technologies are available, including AppLocker. These perform single-instance or blanket allow or deny rules for running applications. In Windows 10, these types of solutions are most effective when deployed alongside the Windows 10 Device Guard feature. Device Guard breaks the current model of detection first-block later and allows only trusted applications to run, period. This methodology is consistent with the successful prevention strategy for mobile phone security. With Device Guard, Microsoft has changed how the Windows operating system handles untrusted applications, which makes its defenses difficult for malware to penetrate. This new prevention versus detection model will provide Windows clients with the necessary security for modern threats and, when implemented, mitigates many of today’s threats from day one. + **Device Guard overview** + Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features revolutionize the Windows operating system’s security by taking advantage of new VBS options to protect the system core and the processes and drivers running in kernel mode—the trust-nothing model you see in mobile device operating systems. A key feature used with Device Guard is *configurable code integrity*, which allows your organization to choose exactly which software from trusted software publishers is allowed to run code on your client machines—exactly what has made mobile phone security on some platforms, such as Windows Mobile, so successful. Trusted applications are those signed directly (in other words, binaries) or indirectly by using a signed file that lists the hash values for application binaries that are considered trustworthy. In addition, Device Guard offers organizations a way to sign existing LOB applications so that they can trust their own code without the requirement that the application be rebuilt or packaged. Also, this same method of signing can provide organizations a way to trust non-Microsoft applications, including those that may not have been signed directly. Device Guard with configurable code integrity, Credential Guard, and AppLocker present the most complete security defense that any Microsoft product has ever been able to offer a Windows client. -Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 can leverage them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Hyper V isolates core Windows services into a virtualization-based, protected container. This is just one example of how Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users. + +Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 can leverage them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Hyper V isolates core Windows services into a virtualization-based, protected container. This is just one example of how +Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users. + To deliver this additional security, Device Guard has the following hardware and software requirements: - UEFI Secure Boot (optionally with a non-Microsoft UEFI CA removed from the UEFI database) - Virtualization support enabled by default in the system firmware (BIOS): @@ -392,141 +522,240 @@ To deliver this additional security, Device Guard has the following hardware and - Kernel mode drivers signed and compatible with hypervisor-enforced code integrity - Windows 10 Enterprise only - X64 version of Windows + Along with these new features, some components of Device Guard are existing tools or technologies that have been included in this strategic security offering to provide customers with the most secure Windows operating system possible. Device Guard is intended as a set of client security features to be used in conjunction with the other threat-resistance features available in the Windows operating system, some of which are mentioned in this guide. + **Configurable code integrity** + The Windows operating system consists of two operating modes: user mode and kernel mode. The base of the operating system runs within the kernel mode, which is where the Windows operating system directly interfaces with hardware resources. User mode is primarily responsible for running applications and brokering information to and from the kernel mode for hardware resource requests. For example, when an application running in user mode needs additional memory, the user mode process must request the resources from the kernel, not directly from RAM. + Code integrity is the component of the Windows operating system that verifies that the code Windows is running came from a trusted source and is tamper free. Like the operating system, Windows code integrity contains two primary components: kernel mode code integrity (KMCI) and user mode code integrity (UMCI). KMCI has been used in recent versions of the Windows operating system to protect the kernel mode from executing unsigned drivers. Although effective, drivers are not the only route that malware can take to penetrate the kernel mode space of the operating system. In Windows 10, however, Microsoft has raised the requirements for kernel mode code out of the box as well as provided enterprises with a way to set their own UMCI and KMCI policies. Starting with the Code Integrity service itself and continuing through the policies a Windows client uses to verify that an application should be allowed to run, Microsoft has made Windows 10 more secure than any previous Windows release. Historically, UMCI has been available only in Windows RT and on Windows Mobile devices, which has made it difficult to infect these devices with viruses and malware. These same successful UMCI policies are available in Windows 10Windows 10. + Historically, most malware has been unsigned. Simply by deploying code integrity policies, organizations will immediately protect themselves against unsigned malware, which is estimated to be responsible for the vast majority of current attacks. By using code integrity policies, an enterprise can also select exactly which binaries are allowed to run in both user mode and kernel mode based on the signer, binary hash, or both. When completely enforced, it makes user mode in Windows function like some mobile platforms, trusting and running only specific applications or specific signatures. This feature alone fundamentally changes security in an enterprise. This additional security is *not* limited to Windows apps and does *not* require an application rewrite to be compatible with your existing and possibly unsigned applications. You can run configurable code integrity independent of Device Guard, thus making it available to devices that don’t meet Device Guard hardware requirements. + **Hardware security features and VBS** + The core functionality and protection of Device Guard starts at the hardware level. Devices that have processors equipped with SLAT technologies and virtualization extensions, such as Intel VT x and AMD V, will be able to take advantage of a VBS environment that dramatically enhances Windows security by isolating critical Windows services from the operating system itself. This isolation is necessary, because you must assume that the operating system kernel will be compromised, and you need assurance that some processes will remain secure. + Device Guard leverages VBS to isolate its Hypervisor Code Integrity (HVCI) service, which enables Device Guard to protect all kernel mode processes and drivers from vulnerability exploits and zero days. HVCI uses the processor’s IOMMU functionality to force all software running in kernel mode to safely allocate memory. This means that after memory has been allocated, its state must be changed from writable to read only or execute only. By forcing memory into these states, it helps ensure that attacks are unable to inject malicious code into kernel mode processes and drivers through techniques such as buffer overruns or heap spraying. In the end, the VBS environment protects the Device Guard HVCI service from tampering even if the operating system’s kernel has been fully compromised, and HVCI protects kernel mode processes and drivers so that a compromise of this magnitude can’t happen in the first place. Another Windows 10 feature that employs VBS is Credential Guard. Credential Guard protects credentials by running the Windows authentication service known as LSA, and then storing the user’s derived credentials (for example, NTLM hashes; Kerberos tickets) within the same VBS environment that Device Guard uses to protect its HVCI service. By isolating the LSA service and the user’s derived credentials from both user mode and kernel mode, an attacker that has compromised the operating system core will still be unable to tamper with authentication or access derived credential data. Credential Guard prevents pass-the-hash and ticket types of attacks, which are central to the success of nearly every major network breach you’ve read about, which makes Credential Guard one of the most impactful and important features to deploy within your environment. For more information about how Credential Guard complements Device Guard, see the [Device Guard with Credential Guard](#dgwithcg) section. + **Device Guard with AppLocker** + Although AppLocker is not considered a new Device Guard feature, you can use it to complement configurable code integrity functionality when enforced code integrity cannot be fully implemented or its functionality does not cover every desired scenario. There are many scenarios in which you could use code integrity policies alongside AppLocker rules. As a best practice, enforce code integrity policies at the most restrictive level possible for your organization, and then use AppLocker to fine-tune the restrictions to an even lower level. + **Note**   One example in which Device Guard functionality needs AppLocker supplementation is when your organization would like to limit which universal applications from the Windows Store users can install on a device. Microsoft has already validated universal applications from the Windows Store as trustworthy to run, but an organization may not want to allow specific universal applications to run in its environment. You could use an AppLocker rule to enforce such a stance. + In another example, you could enable a configurable code integrity policy to allow users to run all the apps from a specific publisher. To do so, you would add the publisher’s signature to the policy. If your organization decides that only specific apps from that publisher should be allowed to run, you would add the signature for the publisher to the configurable code integrity policy, and then use AppLocker to determine which specific apps can run.   AppLocker and Device Guard can run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, Microsoft recommends that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio. + ### + **Device Guard with Credential Guard** + Although Credential Guard isn’t a feature within Device Guard, many organizations will likely deploy Credential Guard alongside Device Guard for additional protection against derived credential theft. Similar to virtualization-based protection of kernel mode through the Device Guard HVCI service, Credential Guard leverages hypervisor technology to protect the Windows authentication service (the LSA) and users’ derived credentials. This mitigation is targeted at preventing the use of pass-the-hash and pass-the-ticket techniques. + Because Credential Guard uses VBS, it is decisive in its ability to prevent pass-the-hash and pass-the-ticket attacks from occurring on Windows 10 devices. Microsoft recognizes, however, that most organizations will have a blend of Windows versions running in their environments. Mitigations for devices not capable of running Credential Guard on both the client side and the server side are available to help with this scenario. Microsoft will be releasing details to TechNet regarding these additional mitigations in the near future. + **Unified manageability through Device Guard** + You can easily manage Device Guard features through the familiar enterprise and client-management tools that IT pros use every day. Use the following management tools to enable and manage Device Guard: - **Group Policy.**Windows 10 provides an administrative template that you can use to configure and deploy the configurable code integrity policies for your organization. This template also allows you to specify which hardware-based security features you would like to enable and deploy. You can manage these settings with your existing Group Policy objects, which makes it simple to implement Device Guard features. In addition to the code integrity and hardware-based security features, Group Policy can help you manage your catalog files. - **System Center Configuration Manager.** Use System Center Configuration Manager to simplify deployment and management of catalog files, code integrity policies, and hardware-based security features as well as to provide version control. - **MDM systems.** Organizations will be able to use Microsoft Intune and non-Microsoft MDM systems for deployment and management of code integrity policies and catalog files. - **Windows PowerShell.** You use Windows PowerShell primarily to create and service code integrity policies. These policies represent the most impactful component of Device Guard. These options provide the same experience you’re used to for management of your existing enterprise management solutions. + **Address Space Layout Randomization** + One of the most common techniques used to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. In the early days of operating systems, any malware that could write directly to the system memory could do such a thing; the malware would simply overwrite system memory in well-known and predictable locations. Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 4 illustrates how ASLR works by showing how the locations of different critical Windows components can change in memory between restarts. + ![image 4](images/security-fig4-aslr.png) + Figure 4. ASLR at work + Although the ASLR implementation in Windows 7 was effective, it wasn’t applied holistically across the operating system, and the level of entropy (cryptographic randomization) wasn’t always at the highest possible level. To decrease the likelihood that sophisticated attacks such as heap spraying could succeed in the Windows 8 operating system, Microsoft applied ASLR holistically across the system and increased the level of entropy many times. The ASLR implementation in Windows 8 and Windows 10 is greatly improved over Windows 7, especially with 64-bit system and application processes that can take advantage of a vastly increased memory space, which makes it even more difficult for malware to predict where Windows 10 stores vital data. When used on systems that have TPMs, ASLR memory randomization will be increasingly unique across devices, which makes it even more difficult for a successful exploit that works on one system to work reliably on another. + **Data Execution Prevention** + Malware depends on its ability to put a malicious payload into memory with the hope that it will be executed later, and ASLR will make that much more difficult. Wouldn’t it be great if you could prevent malware from running if it wrote to an area that has been allocated solely for the storage of information? + Data Execution Prevention (DEP) does exactly that, by substantially reducing the range of memory that malicious code can use for its benefit. DEP uses the No eXecute bit on modern CPUs to mark blocks of memory as read-only so that those blocks can’t be used to execute malicious code that may be inserted within through a vulnerability exploit. + Because of the importance of DEP, users cannot install Windows 10 on a computer that does not have DEP capability. Fortunately, most processors released since the mid-2000s support DEP. + If you want to see which apps use DEP, complete these steps: 1. Open Task Manager: Press Ctrl+Alt+Esc or by searching the Start screen. 2. Click **More Details** (if necessary), and then click the **Details** tab. 3. Right-click any column heading, and then click **Select Columns**. 4. In the **Select Columns** dialog box, select the last **Data Execution Prevention** check box. 5. Click **OK**. + You can now see which processes have DEP enabled. Figure 5 shows the processes running on a Windows 10 PC with a single process that does not support DEP. + ![figure 5](images/security-fig5-dep.png) + Figure 5. Processes on which DEP has been enabled in Windows 10 + **Windows Heap** + The *heap* is a location in memory that Windows uses to store dynamic application data. Windows 10 continues to improve on earlier Windows heap designs by further mitigating the risk of heap exploits that could be used as part of an attack. + Windows 10 has several important improvements to the security of the heap over Windows 7: - Internal data structures that the heap uses are now better protected against memory corruption. - Heap memory allocations now have randomized locations and sizes, which makes it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, Windows 10 adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable. - Windows 10 uses “guard pages” before and after blocks of memory as tripwires. If an attacker attempts to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and Windows 10 responds by instantly terminating the app. + Windows 10 resolves known heap attacks that could be used to compromise a PC running previous versions of Windows. + **Memory reservations** + The lowest 64 KB of process memory is reserved for the system. Apps are no longer allowed to allocate that portion of the memory, which makes it more difficult for malware to overwrite critical system data structures in memory. + **Control Flow Guard** + When applications are loaded into memory, they are allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls additional code located in other memory addresses. The relationships between the code locations are well known—they are written in the code itself—but previous to Windows 10, the flow between these locations was not enforced, which gives attackers the opportunity to change the flow to meet their needs. In other words, an application exploit takes advantage of this behavior by running code that the application may not typically run. This kind of threat is mitigated in Windows 10 through the Control Flow Guard (CFG) feature. When a trusted application that was compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If the location is not trusted, the application is immediately terminated as a potential security risk. An administrator cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when the application is compiled. Administrators should consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. Of course, browsers are a key entry point for attacks; thus Microsoft Edge, IE, and other Windows features take full advantage of CFG. + **Protected Processes** + Benjamin Franklin once said that "an ounce of prevention is worth a pound of cure." His wisdom directly applies to PC security. Most security controls are designed to prevent the initial infection point. The reasoning is that if malware cannot infect the system, the system is immune to malware. + No computer is immune to malware, however. Despite all the best preventative controls, malware can eventually find a way to infect any operating system or hardware platform. So, although prevention with a defense-in-depth strategy is important, it cannot be the only type of malware control. + The key security scenario is to assume that malware is running on a system but limit what it can do. Windows 10 has security controls and design features in place to reduce compromise from existing malware infections. Protected Processes is one such feature. + With Protected Processes, Windows 10 prevents untrusted processes from interacting or tampering with those that have been specially signed. Protected Processes defines levels of trust for processes. Less trusted processes are prevented from interacting with and therefore attacking more trusted processes. Windows 10 uses Protected Processes more broadly across the operating system, and for the first time, you can put antimalware solutions into the protected process space, which helps make the system and antimalware solutions less susceptible to tampering by malware that does manage to get on the system. + ## Secure the Windows desktop + Windows 10 includes critical improvements to the Windows core and the desktop environment, where attacks and malware most frequently enter. The desktop environment is now more resistant to malware thanks to significant improvements to Windows Defender and SmartScreen Filters. Internet browsing is a safer experience because of Microsoft Edge, a completely new browser. The Windows Store reduces the likelihood that malware will infect devices by ensuring that all applications that enter the Windows Store ecosystem have been thoroughly reviewed before being made available. Universal Windows applications are inherently more secure than typical applications because they are sandboxed. Sandboxing restricts the application’s risk of being compromised or tampered with in a way that would put the system, data, and other applications at risk. The sections that follow describe Windows 10 improvements to application security in more detail. + **Microsoft Edge and Internet Explorer 11** + Browser security is a critical component of any security strategy, and for good reason: The browser is the user’s interface to the Internet, an environment that is quite literally overwhelmed with malicious sites and content waiting to attack. Most users cannot perform at least part of their job without a browser, and many users are completely reliant on one. This reality has made the browser the number one pathway from which malicious hackers initiate their attacks. -All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples of this are Flash and Java extensions that enable their respective applications to run inside a browser. Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority. + +All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples of this are Flash and Java extensions that enable their respective applications to run inside a browser. +Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority. + Microsoft includes an entirely new browser, Microsoft Edge, in Windows 10. Microsoft Edge is more secure in several ways, especially: - **Microsoft Edge does not support non-Microsoft binary extensions.** Microsoft Edge supports Flash content and PDF viewing by default through built-in extensions but no other binary extensions, including ActiveX controls and Java. - **Microsoft Edge runs 64-bit processes.** A 64-bit PC running an older version of Windows often runs in 32-bit compatibility mode to support older and less secure extensions. When Microsoft Edge runs on a 64-bit PC, it runs only 64-bit processes, which are much more secure when vulnerabilities are discovered and attempts are made to exploit them. - **Microsoft Edge is designed as a Universal Windows app.** It is inherently compartmentalized and runs in an AppContainer that sandboxes the browser from the system, data, and other apps. IE11 on Windows 10 can also take advantage of the same AppContainer technology through Enhanced Protect Mode. However, because it can run ActiveX and BHOs, the browser and sandbox are susceptible to a much broader range of attacks than Microsoft Edge. - **Microsoft Edge simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, there are fewer required security settings. In addition, Microsoft created Microsoft Edge default settings that align with security best practices, which makes it secure by default. + In addition to Microsoft Edge, Microsoft includes IE11 in Windows 10 primarily for backwards-compatibility with websites and binary extensions that do not work with Microsoft Edge. It should not be configured as the primary browser but rather as an optional or automatic switchover, as shown in Figure 6. + ![figure 6](images/security-fig6-edge2.png) + Figure 6. Configure Windows 10 to switch from Microsoft Edge to IE11 for backwards-compatibility. + Microsoft’s recommendation is to use Microsoft Edge as the primary web browser because it provides compatibility with the modern web and the best possible security. For sites that require IE11 compatibility, including those that require binary extensions and plug ins, enable Enterprise mode and use the Enterprise Mode Site List to define which sites have the dependency. When configured, when users use Microsoft Edge and it identifies a site that requires IE11, they will automatically be switched to IE11. + **The SmartScreen Filter** + Recent versions of Windows have many effective techniques to prevent malware from installing itself without the user’s knowledge. To work around those restrictions, malware attacks often use social engineering techniques to trick users into running software. For example, malware known as a Trojan horse pretends to be something useful, such as a utility, but carries an additional, malicious payload. Starting with Windows Internet Explorer 8, the SmartScreen Filter has helped protect users from both malicious applications and nefarious websites by using the SmartScreen Filter’s application and URL reputation services. The SmartScreen Filter in Internet Explorer would check URLs and newly downloaded apps against an online reputation service that Microsoft maintained. If the app or URL were not known to be safe, SmartScreen Filter would warn the user or even prevent the app or URL from loading, depending on how systems administrators had configured Group Policy settings. For Windows 10, Microsoft further developed the SmartScreen Filter by integrating its app reputation abilities into the operating system itself, which allows the filter to protect users regardless of the web browser they are using or the path that the app uses to arrive on the device (for example, email, USB flash drive). The first time a user runs an app that originates from the Internet, even if the user copied it from another PC, the SmartScreen Filter checks the reputation of the application by using digital signatures and other factors against a service that Microsoft maintains. If the app lacks a reputation or is known to be malicious, the SmartScreen Filter warns the user or blocks execution entirely, depending on how the administrator has configured Group Policy (see Figure 7). + ![figure 7](images/security-fig7-smartscreenfilter.png) + Figure 7. The SmartScreen Filter at work in Windows 10 + By default, users have the option to bypass SmartScreen Filter protection so that it will not prevent a user from running a legitimate app. You can use Control Panel or Group Policy settings to disable the SmartScreen Filter or to completely prevent users from running apps that the SmartScreen Filter does not recognize. The Control Panel settings are shown in Figure 8. + ![figure 8](images/security-fig8-smartscreenconfig.png) + Figure 8. The Windows SmartScreen configuration options in Control Panel + If you want to try the SmartScreen Filter, use Windows 7 to download this simulated (but not dangerous) malware file:[freevideo.exe](http://go.microsoft.com/fwlink/p/?LinkId=626943). Save it to your computer, and then run it from Windows Explorer. As shown in Figure 9, Windows runs the app without much warning. In Windows 7, you might receive a warning message about the app not having a certificate, but you can easily bypass it. + ![figure 9](images/security-fig9-windows7allow.png) + Figure 9. Windows 7 allows the app to run + Now, repeat the test on a computer running Windows 10 by copying the file to a Windows 10 PC or by downloading the file again and saving it to your local computer. Run the file directly from File Explorer, and the SmartScreen Filter will warn you before it allows it to run. Microsoft’s data shows that for a vast majority of users, that extra warning is enough to save them from a malware infection. + **Universal Windows apps** + The good news is that the download and use of Universal Windows apps or even Windows Classic applications (Win32) from the Windows Store will dramatically reduce the likelihood that you encounter malware on your PC because all apps go through a careful screening process before being made available in the store. Apps that organizations build and distribute through sideloading processes will need to be reviewed internally to ensure that they meet organizational security requirements. + Regardless of how users acquire Universal Windows apps, they can use them with increased confidence. Unlike Windows Classic applications, which can run with elevated privileges and have potentially sweeping access to the system and data, Universal Windows apps run in an AppContainer sandbox with limited privileges and capabilities. For example, Universal Windows apps have no system-level access, have tightly controlled interactions with other apps, and have no access to data unless the user explicitly grants the application permission. In addition, all Universal Windows apps follow the security principle of least privilege. Apps receive only the minimum privileges they need to perform their legitimate tasks, so even if an attacker exploits an app, the damage the exploit can do is severely limited and should be contained within the sandbox. The Windows Store displays the exact capabilities the app requires (for example, access to the camera), along with the app’s age rating and publisher. In the end, the Windows Store app distribution process and the app sandboxing capabilities of Windows 10 will dramatically reduce the likelihood that users encounter malicious apps on the system. + **Windows Defender** + Antimalware software, also generically called virus scanners, antivirus, and a host of other names, has been around for a long time. Microsoft shipped its first program in this category, Microsoft Anti-Virus, in 1993 for MS DOS 6.0. At the time, the approach of running a standalone MS DOS program to locate and remove viruses was sufficient. + Times change and technology progresses, and antimalware software has also evolved. It is crucial to have multilayered defense with interoperability when you manage modern threats. Windows Defender uses the operating system extensively to achieve interoperability across the varying layers of defense. It is important to have an effective antimalware solution in place as an important obstacle between malware and enterprise assets, and it complements features like Device Guard. For example, an antimalware solution could help detect malicious behavior in memory or even within trusted applications, an area that Device Guard is not designed to address. Windows Defender has evolved to meet the growing complexity of IT and the challenges that come with this complexity. Windows included Windows Defender, a robust inbox antimalware solution, starting with Windows 8. Now, with Windows 10, Microsoft has significantly improved Windows Defender. + Windows Defender in Windows 10 uses a four-pronged approach to improve antimalware: rich local context, extensive global sensors, tamper proofing, and the empowerment of IT security professionals. This section explains each prong. + **Rich, local context** improves how malware is identified. Windows 10 informs Windows Defender not only about content like files and processes but also where the content came from, where it has been stored, and more. The information about source and history enables Windows Defender to apply different levels of scrutiny to different content. + For example, an application downloaded from the Internet would be more heavily scrutinized than an application installed from a trusted server. Windows 10 persists the history of the Internet-sourced application at the operating system level so that the app cannot erase its own tracks. The history is tracked and stored by the Persisted Store, a new feature in Windows 10 that securely manages the rich local context and prevents unauthorized modification or deletion. The rich local context improvements also help prevent malware from using tactics such as obfuscation as a means to evade detection. + Local context also extends to how antimalware software exposes interfaces. Windows Defender implements the Antimalware Scan Interface (AMSI), a generic public interface standard that allows applications and services to request Windows Defender to scan and analyze obfuscated code before execution. AMSI is available for any application and antimalware solution to implement. In Windows 10, AMSI is accessible through Windows PowerShell, the Windows Script Host, JavaScript, and Microsoft JScript. + In Windows 10, Microsoft implemented a new technology that allows Windows Defender to work closely with User Account Control (UAC) requests. When the UAC system is triggered, it requests a scan from Windows Defender before it prompts for elevation. Windows Defender scans the file or process and determines whether it's malicious. If it’s malicious, the user will see a message that explains that Windows Defender blocked the file or process from executing; if it's not malicious, then UAC will run and display the usual elevation request prompt. + **Extensive global sensors** help keep Windows Defender current and aware of even the newest malware. This is accomplished in two ways: by collecting the rich local context data from end points and by centrally analyzing that data. The goal is to identify new, emerging malware and block it in the first critical hours of its lifetime to limit exposure to the broader PC ecosystem. + With Windows Defender in Windows 8, Microsoft first introduced Windows Defender Cloud Protection, which helps to better react in the quickly evolving malware landscape. The goal is to block malware the "first time it’s seen" in the first critical hours of a malware attack. + To help preserve the privacy of customers, Microsoft allows customers to opt in or out of the system. To participate, you simply opt into the program. To opt in for Windows 10, click **Settings**, click **Update & Security**, and then click **Windows Defender**. The opt-in choices are shown in Figure 10. + ![figure 10](images/security-fig10-optinsettings.png) + Figure 10. Windows Defender opt-in settings in Windows 10 + Of course, system administrators have centralized control of all Windows Defender settings through Group Policy. The Windows Defender configuration settings are shown under Computer Configuration/Windows Components/Windows Defender, as shown in Figure 11. + ![figure 11](images/security-fig11-defendersettings.png) + Figure 11. Windows Defender settings in Group Policy– the sample submission options are listed under MAPS + **Tamper proofing** is the safeguarding of Windows Defender itself against malware attacks. Malware creators assume that antimalware software is implemented on most PCs. Many malware creators choose to overcome that obstacle by designing malware that modifies the antimalware software in some way, such as disabling real-time scanning or by hiding specific processes. Some malware goes as far as completely disabling the antimalware software while making it appear fully functional to the user. + Windows Defender is designed to resist tampering; it uses several security technologies available in Windows 10, the primary of which is Protected Processes, which prevents untrusted processes from attempting to tamper with Windows Defender components, its registry keys, and so on. Tamper proofing in Windows Defender is also the indirect result of system-wide security components, including UEFI with Secure Boot and ELAM. These components help provide a more secure environment in which Windows Defender can launch in before it begins to defend itself. -**Empowerment of IT security professionals** means that Windows Defender gives IT pros the tools and configuration options necessary to make it an enterprise-class antimalware solution. It has numerous enterprise-level features that put it on par with the top products in this category: + +**Empowerment of IT security professionals** means that Windows Defender gives IT pros the tools and configuration options necessary to make it an enterprise-class antimalware solution. It has numerous enterprise-level features +that put it on par with the top products in this category: - Integration with centralized management software, including Microsoft Intune, System Center Configuration Manager, and Microsoft System Center Operations Manager. Unlike Windows 8.1, no additional client is necessary, because Windows Defender is now integrated into Windows and only a management layer needs to be added. - Windows Defender supports the Open Mobile Alliance Device Management standard for centralized management by many non-Microsoft device management solutions. - It includes integrated classic command-line and Windows PowerShell cmdlet support. - Support for Windows Management Instrumentation reporting and application management is built in. - Full integration with Group Policy offers complete IT configuration management. + In addition, Windows Defender now integrates the Windows Defender Offline Tool, which formerly required the creation of a bootable, standalone version of Windows Defender into the Windows Recovery Environment. This simplifies the process of remediating low-level malware infections, which may prove difficult to detect and remove with the antimalware solution running on the Windows desktop. You can update signatures for this environment automatically from within the Windows Defender Offline experience. + Beyond Windows Defender, Windows 10 provides deep operating system access for antimalware products. Non-Microsoft antimalware vendors can take advantage of Microsoft’s new APIs and interfaces to gain unprecedented access to Windows 10 resources for malware detection and removal. Non-Microsoft antimalware solutions can implement ELAM drivers, which scan Windows 10 while it’s in its initial startup process. The broad set of new low-level interfaces lets non-Microsoft antimalware solutions perform advanced malware detection in a way that enables them to retain application compatibility even when Microsoft makes significant changes to Windows internals, such as are often made between major operating system versions. + This access presents a security challenge, however: How does Windows 10 grant antimalware software generous access while ensuring that malware doesn’t take advantage of the very same access? Microsoft has been hard at work with several non-Microsoft software vendors to meet this challenge. If a third party wants this level of access, it must meet certain criteria and vetting requirements, and then Microsoft must digitally sign its software. This allows Microsoft to verify the authenticity of the software vendors and prevent nefarious individuals from creating their own self-signed fake malware scanners. + To be clear, Microsoft is not restricting the antimalware vendors or their innovations. Nor is Microsoft changing software distribution channels. When Microsoft has signed the antimalware application, you can deploy and install it through any means. Microsoft is basically ensuring that these software developers are authentic, industry-recognized entities before signing their antimalware software and, in doing so, granting extended privileges to it. Another security threat that customers face particularly in consumer and bring your own device (BYOD) scenarios is a disabled or outdated antimalware product. A BYOD computer that has an installed but ineffective antimalware product can be more dangerous than no product at all, because it gives the illusion of security. Windows Defender in Windows 10 mitigates this threat by helping ensure that either Windows Defender or the customer’s preferred non-Microsoft solution is running and in a healthy state. + Whenever non-Microsoft real-time protection is in an inoperable state (for example, disabled, expired) for 24 hours, Windows Defender automatically turns on to ensure that the device is protected. Windows attempts to help the user remediate the issue with the non-Microsoft antimalware solution by notifying him or her as early as 5 days before the software expires. If the solution expires, Windows enables Windows Defender and continues to remind the user to renew the non-Microsoft solution. When the user updates or reactivates the solution, Windows Defender is automatically disabled. In the end, the goal is to make sure that an operable antimalware solution is running at all times. + ## Conclusion + Windows 10 is the culmination of many years of effort from Microsoft, and its impact from a security perspective will be significant. Many of us still remember the years of Windows XP, when the attacks on the Windows operating system, applications, and data increased in volume and matured into serious threats. With the existing platforms and security solutions that you’ve likely deployed, you’re better defended than ever. But as attackers have become more advanced, there is no doubt that they have exceeded your ability to defend your organization and users. Evidence of this fact can be found in the news virtually every day as yet another major organization falls victim. Microsoft specifically designed Windows 10 to address these modern threats and tactics from the most advanced adversaries. It can truly change the game for your organization, and it can restore your advantage against those would like to make you their next victim. + ## Related topics + [Windows 10 Specifications](http://go.microsoft.com/fwlink/p/?LinkId=625077 ) + [HealthAttestation CSP](http://go.microsoft.com/fwlink/p/?LinkId=626940 ) + [Making Windows 10 More Personal and More Secure with Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=626945) + [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md) -  -  diff --git a/windows/keep-secure/windows-defender-in-windows-10.md b/windows/keep-secure/windows-defender-in-windows-10.md index e2f59150de..72d8554def 100644 --- a/windows/keep-secure/windows-defender-in-windows-10.md +++ b/windows/keep-secure/windows-defender-in-windows-10.md @@ -2,39 +2,52 @@ title: Windows Defender in Windows 10 (Windows 10) description: This topic provides an overview of Windows Defender, including a list of system requirements and new features. ms.assetid: 6A9EB85E-1F3A-40AC-9A47-F44C4A2B55E2 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: manage ms.sitesec: library +ms.pagetype: security author: jasesso --- + # Windows Defender in Windows 10 + **Applies to** - Windows 10 + Windows Defender in Windows 10 is a built-in antimalware solution that provides security and antimalware management for desktops, portable computers, and servers. This topic provides an overview of Windows Defender, including a list of system requirements and new features. + For more important information about running Windows Defender on a server platform, see [Windows Defender Overview for Windows Server Technical Preview](https://technet.microsoft.com/library/dn765478.aspx). + Take advantage of Windows Defender by configuring the settings and definitions using the following tools: - Microsoft Active Directory *Group Policy* for settings - Windows Server Update Services (WSUS) for definitions + Windows Defender provides the most protection when cloud-based protection is enabled. Learn how to enable cloud-based protection in [Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md). -**Note**  System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including: +> **Note:**  System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including: - Settings management - Definition update management - Alerts and alert management - Reports and report management + When you enable endpoint protection for your clients, it will install an additional management layer on Windows Defender to manage the in-box Windows Defender agent. While the client user interface will still appear as Windows Defender, the management layer for Endpoint Protection will be listed in the **Add/Remove Programs** control panel, though it will appear as if the full product is installed.   ### Minimum system requirements + Windows Defender has the same hardware requirements as Windows 10. For more information, see: - [Minimum hardware requirements](https://msdn.microsoft.com/library/windows/hardware/dn915086.aspx) - [Hardware component guidelines](https://msdn.microsoft.com/library/windows/hardware/dn915049.aspx) + ### New and changed functionality + - **Improved detection for unwanted applications and emerging threats using cloud-based protection.** Use the Microsoft Active Protection Service to improve protection against unwanted applications and advanced persistent threats in your enterprise. - **Windows 10 integration.** All Windows Defender in Windows 10 endpoints will show the Windows Defender user interface, even when the endpoint is managed. - **Operating system, enterprise-level management, and bring your own device (BYOD) integration.** Windows 10 introduces a mobile device management (MDM) interface for devices running Windows 10. Administrators can use MDM-capable products, such as Intune, to manage Windows Defender on Windows 10 devices. + For more information about what's new in Windows Defender in Windows 10, see [Windows Defender in Windows 10: System integration](https://www.microsoft.com/security/portal/enterprise/threatreports_august_2015.aspx) on the Microsoft Active Protection Service website. + ## In this section +