Partager via

What's Changed in Security Technologies in Windows 8.1

  • Article

Applies To: Windows 8, Windows 8.1

This evaluation topic for the IT professional describes the security features in Windows 8.1 and provides links to additional content about these features.

The Windows 8.1 operating system provides security features that can protect devices and data from unauthorized access and software threats. Windows 8.1 builds on the security foundation in Windows 8 to provide improvements in:

  • Device management through the support of the Simple Certificate Enrollment Protocol (SCEP), which uses the Open Mobile Alliance Device Management (OMA DM) protocol.

    SCEP is a device management protocol that is designed to manage mobile devices, such as mobile phones and tablet computers. SCEP is an established certificate enrollment protocol that was developed for routers, and Windows 8 did not support it. Windows 8.1 exposes the OMA DM protocol for mobile device management solutions that are implemented by non-Microsoft software vendors..

  • Memory randomization and additional malware protection for startup and running processes, which prevents malware from finding a place to insert itself. In addition, devices running Windows 8.1 are required to have Trusted Platform Module 2.0 installed.

  • The startup process to implement the Unified Extensible Firmware Interface (UEFI). UEFI is a standards-based solution that provides the same functionality as the system BIOS and adds security features and other advanced capabilities. Like BIOS, PCs start UEFI before any other software, and UEFI then starts the operating system’s bootloader. The startup process also includes a process for ELAM-compliant systems for non-Microsoft software on a remote server to securely verify the security of every startup component in a way that would be very difficult for malware to forge.

  • The Windows access control model to improve checks on code integrity labels on processes before starting.

  • Certificate integrity through TPM and key attestation processes. In Windows 8.1, certificate attestation is applied to public certificates and keys.

  • Fingerprint biometrics for easier implementation and use.

  • Data protection through expanded device encryption in the enterprise and the ability to selectively revoke access to corporate data on remote devices.

This topic contains information about the following security features:

  • Malware resistance

    • Trusted Platform Module

    • Address space layout randomization

    • Data execution prevention

    • Secure Boot

    • Trusted Boot

    • Provable PC Health

    • Windows Defender

  • Access control, identity, and authentication

    • Dynamic Access Control

    • Trustworthy identities and devices

    • TLS/SSL (Schannel SSP)

    • Credentials protection and management

      • Restricted Admin mode for Remote Desktop

      • LSA protection

      • Protected Users security group

      • Authentication Policy and Silos

      • Credential Locker

    • Automatic restart after Windows Update

    • Fingerprint biometrics

    • Virtual smart cards

  • Sensitive data protection

    • Device encryption

    • BitLocker

    • Selective Wipe

Malware resistance

Windows 8.1 and Windows 8 work with hardware that is designed for improved malware mitigation, including the following:

Trusted Platform Module

A Trusted Platform Module (TPM) is a tamper-resistant security processor, which is capable of storing cryptographic keys and hashes. Besides storing data, a TPM can digitally sign data by using a private key that software cannot access. Among other functions, Windows uses the TPM for cryptographic calculations and to store the keys for BitLocker volumes, virtual smart cards, and other public key certificates. The Unified Extensible Firmware Interface (UEFI) and the operating system can use the TPM to store hashes (which verify that a file has not been changed) and keys (which verify that a digital signature is genuine).

Firmware-based TPM devices allow always-on scenarios, such as InstantGo. As more personal devices are appearing in enterprise environments, and managing those devices increases in volume and complexity, the adoption of a TPM solution is increasing and is becoming an industry standard.

To support InstantGo, TPM 2.0 is a requirement for the Windows 8.1 and Windows 8 operating systems, but only recommended if InstantGo support is not necessary. Otherwise TPM 1.2 is the minimum required for Windows 8.1. For Windows Server 2012 R2, TPM is not required but both TPM 1.2 and TPM 2.0 are supported.

Address space layout randomization

Address space layout randomization (ASLR) makes the type of attacks that write directly to the system memory much more difficult by randomizing how and where important data is stored in the memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack.

In Windows 8.1, ASLR memory randomization can be unique across devices, making it even more difficult for an exploit that is successful on one system to work reliably on another.

Data execution prevention

Data execution prevention (DEP) substantially reduces the range of memory that malicious code can use for its benefit. DEP uses the Never eXecute (NX) bit on supported CPUs to mark blocks of memory as data that should never be run as code. Therefore, even if malicious users succeed in loading the malware code into the memory, they will not be able to run it.

Windows 8.1 and Windows 8 are the first versions of Windows that require a processor that includes hardware-based DEP support. These Windows operating systems cannot be installed on a computer that is not DEP-enabled.

Secure Boot

Windows 8.1 and Windows 8 will only run on certified PCs. Certification is based, in part, on UEFI.UEFI is a standards-based solution that provides the same functionality as the system BIOS and adds security features and other advanced capabilities.

Bootkits are the most dangerous form of malware. They start before Windows starts, and they hide between the hardware and operating system where they are virtually undetectable and have unlimited access to system resources.

Recent implementations of UEFI are able to run internal integrity checks that verify the firmware’s digital signature before running it. Because only the PC’s hardware manufacturer can control which digital certificates are permitted to create a valid firmware signature, UEFI offers protection from firmware rootkits. Thus, UEFI is the first link in the chain of trust.

With Secure Boot, the computer’s UEFI verifies that the Windows bootloader is secure before loading it. If the bootloader has been modified (for example, if a bootkit is installed) or replaced, Secure Boot will prevent running it.

Trusted Boot

Windows 8.1 and Windows 8 also include Trusted Boot, which verifies that all Windows boot components have integrity and can be trusted. The bootloader verifies the digital signature kernel before loading it. The kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and the ELAM component.

In Windows 8.1, Measured Boot has been added to the startup process for ELAM-compliant systems. Measured Boot allows non-Microsoft software on a remote server to securely verify the security of every startup component in a way that would be very difficult for malware to forge. If any tampering with the Windows boot process or the antimalware’s ELAM driver is detected, Trusted Boot repairs the system by restoring the original files.

Provable PC Health

Provable PC Health is a free consumer service to which the owners of devices that connect to your network can subscribe. In a simple sense, it provides remote PC analysis; however, the service does not provide remote attestation. The Secure Data Client periodically sends information, including data about the state of the computer, to the cloud service. If an issue is detected as the data is analyzed, the cloud service sends a message to the client service with remediation recommendations. The client service responds to the recommendation by offering the user actions to take.

Windows Defender

In Windows 8, Windows Defender was upgraded from antispyware to a full-featured antimalware solution capable of detecting and stopping a wider range of potentially malicious software, including viruses. Windows Defender supports the ELAM feature in Windows 8, which makes it capable of detecting rootkits that infect non-Microsoft drivers. If Windows Defender detects an infected driver, it prevents the driver from starting.

In Windows Server 2012 R2 and Windows 8.1, Windows Defender is available on Server Core installation options (without the user interface), and it is enabled by default.

Windows Defender is primarily intended for consumer and unmanaged PC scenarios, and most large organizations will want to use an enterprise antimalware solution such as System Center 2012 Endpoint Protection, which also includes support for ELAM.

For more information about how Windows Defender was implemented, see Windows Defender and Resulting Internet Communication in Windows 8 and Windows Server 2012.

Access control, identity, and authentication

This section describes features and their changes which enable your user’s ability to access resources.

Dynamic Access Control

Dynamic Access Control uses dynamic rules-based policies to protect shares, folders, and files. These policies can allow or deny access, based on combinations of user, device, and data properties, rather than statically maintained user lists and security groups.

By using Dynamic Access Control, administrators can create detail audit policies, potentially to document who accesses highly sensitive information and to meet compliance reporting and forensic analysis requirements. Unlike traditional auditing capabilities where an ocean of prioritized audit data is collected, Dynamic Access Control and its rules-based policies enable you to collect everything, or target specific data and types of data to audit.

For more information about using dynamic rules-based policies, see Dynamic Access Control: Scenario Overview.

Trustworthy identities and devices

Windows 8.1 includes improvements to increase the public key infrastructure (PKI) trustworthiness by proving the integrity of public and local keys and certificates and verifying their authenticity.

Securing private certificates and keys with TPM KSP plus key attestation

In Windows 8, the TPM-based key storage provider (KSP) addresses the risk of a malicious user exporting certificates with private keys. This implementation creates a strong binding between the private key and the hardware through the TPM. The TPM prevents a usable private key from being exported from the system where it might be able to be used for some other purpose. The TPM-based KSP secures the client side, but the server still inherently trusts client-side certificates if they appear to have integrity.

In Windows 8.1 adds key attestation. A server or service can require proof that the certificates and keys where protected by a TPM, and they have remained that way. If the proof is provided, access is granted. Otherwise, access can be denied. With the capability of TPM KSP with key attestation there is greater assurance that certificates that were provisioned to devices were provisioned securely, are stored securely, and are used securely on trusted devices and by users.

For more information about the TPM Key Storage Provider updates for platform and key attestation, see What's New for the TPM in Windows 8.1.

Securing public certificates and keys

In Windows 8.1, certificate attestation is applied to public certificates and keys. The SmartScreen feature in Internet Explorer is aligned with a web service that provides an early warning system to notify users of suspicious websites that could be engaging in phishing attacks or distributing malware through a socially engineered attack.

An analysis service is included, which can detect fraudulent or fraudulently used certificates. The service is able to detect when certificates are issued by unexpected sources, and it can investigate anomalies that would initiate remedial actions or suggest revoking the certificate.

For more information about how SmartScreen worked in the previous release, see SmartScreen Filter and Resulting Internet Communication in Windows 8 and Windows Server 2012.

TLS/SSL (Schannel SSP)

The Transport Layer Security (TLS) protocol, a component of the Schannel Security Support Provider, is used to secure data that is sent between applications across an untrusted network. TLS/SSL can be used to authenticate servers and client computers, and also to encrypt messages between the authenticated parties.

Devices that connect TLS to servers frequently need to reconnect due to session expiration. Windows 8.1 and Windows Server 2012 R2 now support RFC 5077 (TLS Session Resumption without Server-Side State). This modification provides Windows Phone and Windows RT devices with:

  • Reduced resource usage on the server

  • Reduced bandwidth, which improves the efficiency of client connections

  • Reduced time spent for the TLS handshake due to resumptions of the connection.

Note

The client-side implementation of RFC 5077 was added in Windows 8.

For information about stateless TLS session resumption, see the IETF document RFC 5077.

For information about changes to the Kerberos protocol and Digest Authentication, see the next section, Credentials protection and management.

Credentials protection and management

In Windows Server 2012 R2 and Windows 8.1, new credential protection and domain authentication controls have been added to address credential theft.

  • Restricted Admin mode for Remote Desktop Connection

    The Remote Desktop Services (RDS) client can connect in Restricted Admin mode. Using this mode with administrator credentials, RDS attempts to interactively logon to a host that also supports this mode without sending credentials. When the host verifies that the user account connecting to it has administrator rights and supports Restricted Admin mode, the connection succeeds. Otherwise, the connection attempt fails. Restricted Admin mode does not at any point send plain text or other re-usable forms of credentials to remote computers.

    For more information, see What's New in Remote Desktop Services in Windows Server 2012 R2.

  • LSA protection

    The Local Security Authority (LSA), which includes the Local Security Authority Security Service (LSASS) process, validates users for local and remote sign-ins and maintains local security policies. The Windows 8.1 operating system provides additional protection for the LSA to prevent code injection by non-protected processes. This provides added security for the credentials that the LSA stores and manages. This protected process setting for LSA can be configured in Windows 8.1 but is on by default in Windows RT 8.1 and cannot be changed.

    For information about configuring LSA protection, see Configuring Additional LSA protection.

    For more information about the LSA and the LSASS, see the Windows Logon and Authentication Technical Overview.

  • Protected Users security group

    This new domain global group triggers new non-configurable protection on devices and host computers running Windows Server 2012 R2 and Windows 8.1. The Protected Users group enables additional protections for domain controllers and domains in Windows Server 2012 R2 domains. This greatly reduces the types of credentials available when users are signed in to computers on the network from a non-compromised computer.

    Members of the Protected Users group are limited further by the following methods of authentication:

    • A member of the Protected Users group can only sign on using the Kerberos protocol. The account cannot authenticate using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8.1, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.

    • The Kerberos protocol will not use the weaker DES or RC4 encryption types in the preauthentication process. This means that the domain must be configured to support at least the AES cipher suite.

    • The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.

    • The default Kerberos Ticket Granting Tickets (TGTs) lifetime setting of four hours is configurable using Authentication Policies and Silos accessed through the Active Directory Administrative Center (ADAC). This means that when four hours has passed, the user must authenticate again.

    For more information, see Protected Users Security Group.

  • Authentication Policy and Silos

    Forest-based Active Directory policies are introduced, and they can be applied to accounts in a domain with a Windows Server 2012 R2 domain functional level. These authentication policies can control which hosts a user can use to sign in. They work in conjunction with the Protected Users security group, and admins can apply access control conditions for authentication to the accounts. These authentication policies isolate related accounts to constrain the scope of a network.

    The new Active Directory object class, Authentication Policy, allows you to apply authentication configuration to account classes in domains with a Windows Server 2012 R2 domain functional level. Authentication policies are enforced during the Kerberos AS or the TGS exchange. Active Directory account classes are:

    • User

    • Computer

    • Managed Service Account

    • Group Managed Service Account

For more information about these additional protections for credentials, see Credentials Protection and Management.

Credential Locker

Credential Locker is a service that creates and maintains secure storage on the local computer that stores user names and passwords that the user saved from websites and Windows Store apps. In Windows 8, the Web Authentication Broker was introduced to help connect an app with resources on the web and manage the credentials.

Credential Locker supports seamless sign in by using Windows Store apps that use Web Authentication Broker. It remembers passwords for services like Facebook and Twitter, so the user does not have to enter credentials multiple times. This seamless sign-in experience has been extended across the user’s devices that are running Windows 8.1.

Formerly, when multiple credentials were stored for the same resource, there was no way to specify a “default” credential. In Windows 8.1, the user can designate a default credential for a particular resource. And to assist with the user’s choice, credentials stored in Credential Locker display the date when they were last used.

For more information about Credential Locker in Windows 8, see Credential Locker Overview.

Automatic restart after Windows Update

When device users postpone or ignore accepting software updates, devices can fall out of compliance with corporate policies. In Windows 8.1, Windows Update automatically performs updates to the system. If a restart is necessary, the user who is signed in to the computer is automatically signed in again, the applications running before the update are restarted, and the session is locked (using the Secure Desktop).

This automatic restart feature requires that the credentials of the user who is signed in to the console can be cached, and that BitLocker is enabled and can persist throughout the process. This new process does not change the user initiated startup and sign in process, or the sign out and shutdown process.

Fingerprint biometrics

Enhancements made to the Windows Biometrics Framework in Windows 8.1 have enabled scenarios that leverage biometrics authentication using built-in features for user enrollment, and new APIs exposed to Windows Store App developers to integrate biometric authentication into apps for user consent.

For more information about these changes and their benefits, see What’s New in Biometrics in Windows 8.1.

The Windows Biometric Framework has provided means for developers of biometric devices to integrate their products with Windows. For Windows Store app development, APIs have been added so that developers can build apps that can request biometric authentication. This user consent verification ability can restrict certain apps to specific identities, thereby restricting use of supported apps when the device is shared between users.

For an overview of the programming model, see the existing MSDN documentation for the Windows Biometric Framework API (Windows).

For a summary of changes to the WBF, see Windows Biometric Framework Overview.

Virtual smart cards

Virtual smart cards offer multifactor authentication and compatibility with many smart card infrastructures. Most importantly, virtual smart cards offer users the convenience of not having to carry a physical card, so users are more likely to follow their organization’s security guidelines rather than working around them.

With virtual smart cards, Windows 8 stores the smart card’s certificate in the PC, and then protects it by using the device’s tamper-proof TPM security chip. In this way, the PC actually becomes the smart card. The user can only access the virtual smart card from PCs that their administrators configure, which fulfills the “something they have” requirement. The user still needs to type a PIN, which fulfills the “something they know” requirement.

In Windows 8.1, the process to enroll TPM-enabled devices as a virtual smart card device has improved. APIs are added to simplify the enrollment process, making it easier to enroll a device with a virtual smart card regardless of whether they are domain joined and regardless of the hardware. Developers can build Windows Store apps to create and manage virtual smart cards, including:

  • Setting a PIN policy

  • Creating certificate objects, and building a certificate chain and verifying it

  • Performing certificate-based operations such as signing and verification and encryption and decryption (including CMS-based signing and verification)

  • Enumerating My store and filtering certificates for users

  • Installing certificates to the user’s My store

  • Establishing user identities that rely on the device management protocol, OMA DM

For more information, see Understanding and Evaluating Virtual Smart Cards on the Microsoft Download Center.

Sensitive data protection

With the use of personal devices to receive and manage corporate data, the risk that information will leak outside the corporation is increased. In Windows Server 2012 R2 and Windows 8.1, features and processes distinguish corporate data from user data. Windows technologies encrypt and control access to corporate data when an end-to-end data loss prevention solution is not available.

Device encryption

Device encryption was introduced in Windows RT as an automatic data protection mechanism for consumer devices. In enterprise editions of Windows 8, device encryption was limited to BitLocker. In Windows 8.1, device encryption is available in all editions of Windows that are InstantGo certified to support a connected standby state.

Some benefits of device encryption include:

  • Encryption of the operating system volume is automatic and configured by default.

  • Protection is enabled once an administrator uses a Microsoft Account to sign in.

  • If encryption is unmanaged, the key recovery password is stored in SkyDrive.

  • In Professional and Enterprise editions of Windows 8.1, device encryption can be reconfiguration to use BitLocker features.

Device encryption in Windows 8.1 permits greater flexibility of personal device use within an organization because it helps protect corporate data across a variety of Windows editions so that:

  • Data on a device in a connected standby state is always protected through encryption.

  • User data on all fixed volumes on a device in a connected standby state is always protected through encryption.

  • When the device in a connected standby state is joined to the domain, it can comply with enterprise security policies.

BitLocker

BitLocker provides support for device encryption on x86-based and x64-based computers with a TPM that supports the connected standby state, InstantGo. Previously this form of encryption was only available on devices running Windows RT.

For more information, see What's New in BitLocker for Windows 8.1 and Windows Server 2012 R2.

Selective Wipe

Selective Wipe is new in Windows 8.1, and it enables services to secure corporate data. Corporate apps can be developed to set a Selective Wipe policy on their data, by protecting it to an internet domain that is owned by the enterprise, and can later choose to revoke access to data protected to that domain. A client app uses the FileRevocationManager APIs to set and enforce a Selective Wipe policy this way. Protecting files to a domain encrypts them to a key associated with that domain and those files are only accessible to the user protecting them with that app. Revoking wipes the key associated with the given domain, rendering the protected content inaccessible. Selective Wipe uses Encrypting File System (EFS) to protect access to the data with a symmetric key that is stored in Credential Locker.

Selective Wipe is used by the Mail app to protect attachments in accounts that have an Exchange ActiveSync (EAS) security policy set, and to revoke access to those attachments when an EAS RemoteWipe command is received for the account. Similarly, Work Folders policy can be configured to encrypt data, and uses Selective Wipe protection.

Exchange ActiveSync (EAS) can revoke access to data tagged with the work email domain when the Mail app is used to access work email, so Work Folders protection policy should be configured with a matching domain. The OMA DM protocol can be used to send and receive the command to revoke access when the device is managed through Windows Intune, or any Mobile Device Management (MDM) solution that uses the Windows OMA DM agent. Windows Intune, using the OMA DM agent, revokes the domains of all managed email addresses when it receives a wipe or unregisters the device.

For information about how the revoke command works to identify corporate data, and what policies are available by using the Exchange ActiveSync policy engine, see Exchange ActiveSync Policy Engine Overview.

For more information about Work Folders, see Work Folders Overview.

For information about understanding mobile device management using Windows Intune, see What's New in Windows Intune - New Features, Changes

For information about changes in security technologies from Windows 7 to Windows 8, see What's Changed in Security Technologies in Windows 8.

For information about security features and technologies in Windows 8, see Windows 8 Security Overview.

For a listing of changes in security technologies from Windows Server 2012 to Windows Server 2012 R2, see Security and Protection overview.

For information about changes in all technologies, including security, from Windows Server 2008 R2 to Windows Server 2012, see What's New in Windows Server 2012.