Sie sind auf Seite 1von 23

Windows Phone 8 Security Guide

This white paper is part of a series of technical papers designed for IT professionals. This whitepaper reviews how security is implemented on Windows Phone in apps and with data and also reviews how Mobile Device Management (MDM) and Exchange ActiveSync can be used to implement a managed and security-enhanced environment for Windows Phone.

September 2013

Legal Disclaimer

2013 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and

views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Published: September 2013

Table of Contents
Windows Phone 8 Security Guide..1 WINDOWS PHONE OVERVIEW..2 PLATFORM INTEGRITY..3 APP PLATFORM SECURITY..6 CHAMBERS AND CAPABILITIES..6 THE BROWSER..7 WINDOWS PHONE STORE..7 ENTERPRISE LINE-OF-BUSINESS (LOB) APPS..8 WINDOWS PHONE UPDATES..8 DATA PROTECTION..9 DEVICE ACCESS AND SECURITY POLICIES..9 DEVICE ENCRYPTION..10 REMOVABLE STORAGE..10 INFORMATION RIGHTS MANAGEMENT..10 CERTIFICATES..11 MOBILE DEVICE MANAGEMENT.....13 SUPPORTED EXCHANGE ACTIVESYNC FEATURES BY EXCHANGE SERVER VERSION..14 EXCHANGE ACTIVESYNC SECURITY..16 SUPPORTED EXCHANGE ACTIVESYNC POLICY SETTINGS..16 DIRECT PUSH AND FIREWALL SETTINGS..19 SSL FOR EXCHANGE SERVER ENCRYPTION AND AUTHENTICATION..21

Windows Phone Overview


As organizations of all sizes expand their support for an increasingly mobile workforce, privacy and security are essential. Windows Phone is designed with security in mind for both users and organizations. The result is a feature-rich and flexible smartphone that uses a holistic approach to security design. Smartphones help organizations to be productive and competitive, but these technologies also require increased security vigilance. The pervasive threat of malicious software, or malware, and the need to prevent data leakage are two of the reasons why a thoughtful, comprehensive security design is essential. Organizations want smartphones that protect data when it is stored and when it is communicated. Windows Phone 8 uses a defense-in-depth, multi-layered approach that addresses organizational security requirements in numerous ways. Because Windows Phone 8 uses the same NT Kernel as Windows 8 and Windows Server 2012, it shares the same driver model, developer platform, security and networking stack, and graphics and media platform with the desktop operating systems. The result is a smartphone that has security features that are unique in todays marketplace.

Platform integrity
Trusted Boot and code signing help to ensure the platform integrity of Windows Phone 8. These features help to safeguard the Windows Phone 8 boot process and operating system from malware attacks, especially rootkits, by allowing only validated software components to execute. These features help to deliver a security-enhanced platform for application developers and corporate customers alike, and helps to assure consumers that steps have been taken to help safeguard the information that they care about. Trusted Boot validates firmware images on Windows Phone devices before they are allowed to load the operating system. Trusted Boot is built on a root of trust, which is fused into the
Layered security platform diagram

device during manufacturing and ensures that all binaries, starting with the very first boot loader loaded from system storage, must be signed by a trusted authority. Windows Phone architecture uses a System-on-a-Chip (SoC) design provided by SoC vendors. The SoC vendor and device manufactures provide the pre-UEFI boot loaders and the UEFI environment. The UEFI environment implements the UEFI secure boot standard that is described in section 27 of the UEFI Specification (http://www.uefi.org/specs). This standard describes a process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI runtime variable before they are executed. The UEFI and Windows document (http://msdn.microsoft.com/enus/windows/hardware/gg463149.aspx) on MSDN describes the advantages of using UEFI and how UEFI is supported by desktop versions of the Windows operating system. Although the document focuses on UEFI and Windows, most of the information in the document also applies to Windows Phone. Microsoft provides the Windows Phone boot manager in the UEFI environment. After the pre-UEFI and UEFI components complete their boot processes, the Windows Phone boot manager takes over to complete the Windows Phone 8 boot process so that the user can start using the smartphone. All code in the Windows Phone operating system is signed by Microsoft, including OEM

drivers and applications. Also, applications that are added after manufacturing, or installed from the Windows Phone Store or a private enterprise store must be properly signed to execute. Windows Phone 8 is designed to help mitigate threats or risks with the following platform security features:

Threat or Risk Access to data because of device theft or loss

Windows Phone security feature Strong device password protection Device lock requires a password or PIN to access the device when it is turned on Local device wipe occurs after a specified number of incorrect login attempts Remote device wipe erases data and helps to prevent unauthorized use Exponential back-off if incorrect passwords are entered Password policy enforcement, such as required password for sync

Access to data during transmission

Secure Sockets Layer (SSL) encryption of all data transmitted between the device and the corporate mail server Advanced Encryption Standard for SSL channel encryption in 128 bit cipher strength Encrypted data passes through a single SSL port on the firewall Supports Information Rights Management protection of e-mail

Unauthorized penetration of phone

Security policies such as password enforcement, password complexity, and device encryption, help to control overthe-air access to device Bluetooth discovery mode is turned on only in Bluetooth settings NFC can be turned off to help guard device integrity

Malicious software or viruses on mobile devices

Office for Windows Phone does not support macros, so viruses cannot leverage them to do damage

App platform security


Microsoft takes a multi-pronged approach to help safeguard Windows Phone 8 devices against malware. One aspect of this approach is the Trusted Boot process that is described in the previous section that helps to prevent rootkit installation. Other methods include items such as a least privileged chamber model, app signing, and security-enhanced browsing.

Chambers and capabilities


The Windows Phone 8 security model is based on the principle of least privilege and uses isolation to achieve it. Every app on Windows Phone (including Microsoft apps and non-Microsoft apps) runs in its own isolated chamber. A chamber is a configured secured isolation boundary within which a process can run. Each chamber is defined and implemented using a security policy. The security policy of a specific chamber defines the operating system capabilities that can be called by the processes in that chamber. A capability is a Windows Phone resource that has user privacy, security, cost, or business impact. Examples of capabilities include geographical location information, camera, microphone, networking, and sensors. A basic set of permissions is granted to all app chambers by default, including access to isolated storage. However, the set of permissions for a chamber can be expanded by using capabilities that are granted during app installation. App permissions cannot be elevated at run time. The chamber concept is advantageous for the following reasons: Attack surface reduction. Each app receives only the capabilities that it needs to perform all its use cases. User consent and control. Application developers are required to disclose app capabilities to the user on the app details page in the Windows Phone Store, and provide an explicit prompt

upon app installation for certain capabilities, such as geographic location. Isolation. No communication channels exist between apps on the phone. Apps are isolated from each other and cannot access memory used or data stored by other applications, including the keyboard cache.

The browser
Windows Phone 8 includes Internet Explorer 10 for Windows Phone. Internet Explorer helps to protect the user as it runs in an isolated chamber and prevents web apps from accessing other app resources. In addition, Internet Explorer does not support a plug-in model, so malicious plug-ins cannot be installed. SmartScreen technology is also available in Internet Explorer for Windows Phone. This technology warns users of websites that are known to be malicious.
Screenshot: SmartScreen technology blocking a malicious website

Windows Phone Store


To help protect users, Microsoft uses a carefully architected store submission and approval process to help prevent malware from reaching its marketplace. All Windows Phone apps that are submitted to the store must be certified before they can be made available to users for downloading and installation. The certification process checks Windows Phone apps for inappropriate content, store policies, and security issues. This process plays an important role in helping to safeguard Windows Phones against malware. In addition, Microsoft scans all apps for known viruses before publication. Although most malware exists on the Internet, apps that are developed in unmanaged environments with minimal security precautions could be unwitting transmitters of malware. Apps must also be signed during the certification process before they can be installed and run on Windows Phones.

Enterprise line-of-business (LOB) apps


With Windows Phone 8, enterprise customers can register with Microsoft to obtain the tools to privately sign and distribute custom LOB apps directly to their employees. Enterprise customers are no longer required to submit business apps to the Windows Phone Store before deploying them. After registration, organizations can privately develop, package, sign, and distribute apps to employees using a validated process. To provide a way for employees and other users to install company apps, an enterprise can develop a Company Hub app. A Company Hub is an app that acts as a portal to company-specific experiences on the phone. At a minimum, a Company Hub enables
Screenshot: Example of a custom developed Company Hub

users to discover, install, and optionally run LOB apps created by the enterprise. Company Hubs can also provide other companyspecific experiences or features, such as displaying current company news, upcoming company events, and alerts from the IT department. For more information about LOB app distribution and Company Hubs for Windows Phone, see the Company app distribution for Windows Phone topic (http://msdn.microsoft.com/enus/library/windowsphone/develop/jj206943(v=vs.105).aspx) on MSDN.

Windows Phone updates


Windows Phone updates are delivered to customers using the Windows Phone update service. Microsoft manages and distributes feature updates and improvements that are developed by hardware manufacturers, mobile operators, and the Windows Phone engineering team. Also, Windows Phone was designed using the industry-leading Microsoft Security Development Lifecycle (SDL). SDL is a software development security assurance process used by all Microsoft engineering teams that includes extensive threat modeling,

penetration testing, and security development practices, all of which help to prevent unauthorized access to phone resources.

Data protection
The Windows Phone security design addresses the need for data protection. To accomplish this, every Windows Phone supports the same set of management and security controls, regardless of hardware manufacturer, enabling organizations to manage all Windows Phones in a consistent, predictable way that helps to mitigate risk.

Device access and security policies


As a first line of defense, a user can set a PIN or password via the settings panel to lock their phone. IT departments can use Exchange ActiveSync policies to require users to set PINs or passwords, and also to configure additional password policies to manage password length, complexity, and other parameters. Exchange ActiveSync policies can also be used to configure additional security functionality. Exchange ActiveSync is a time-tested and robust communications protocol that provides Windows Phone users with world-class mailbox synchronization functionality as well as policy control. Windows Phone 8 is compatible with version 14.1 of the Exchange ActiveSync protocol and supports the synchronization of email, calendar, task, and contact information with Exchange Server 2003 SP2 and all subsequent releases as well as with Microsoft Office 365. If a Windows Phone is lost or stolen, IT administrators can initiate a remote wipe of the device by using the Exchange Server Management Console, and users can initiate a remote wipe of the device by using Outlook Web App. After registering their phone at http://www.windowsphone.com, users can map the location of their phone, make it ring, and wipe its data if necessary.

Device encryption
Windows Phone 8 uses BitLocker technology to support the encryption of all internal data storage on the phone with AES 128. Encryption is enabled by either Exchange ActiveSync policy RequireDeviceEncryption or device management policy. After BitLocker is enabled, the phone automatically begins encrypting the internal storage. The encryption key is protected by the Trust Platform Module (TPM), which is bound to UEFI Trusted Boot to ensure that the encryption key will only be released to trusted boot components. With both PIN-lock and BitLocker enabled, the combination of data encryption and device lock would make it extremely difficult for an attacker to recover sensitive information from a device.

10

Removable storage
Windows Phone 8 supports removable storage using micro SD cards, so users can easily extend the memory available for storage on their phones to store pictures, movies, or music when needed. The Windows Phone operating system allows users to store only media files on SD cards. Although the Windows Phone 8 operating system and user data partitions are encrypted, files that are stored on SD cards that are inserted in the phone are not encrypted. IT professionals can prevent the use of external storage cards on Windows Phones by configuring an Exchange ActiveSync policy setting.

Information Rights Management


Windows Phone is currently the only smartphone that offers native support for IRM, enabling users to fully participate in IRMprotected email conversations and to access IRM-protected documents on their phones. Support for IRM in Windows Phone is based on Windows Rights Management Services. When IRM is

employed, the data in rights-protected documents or email messages is encrypted, so that it can only be viewed by authorized users. IRM can also be used to limit other rights to a document or message, such as by limiting access to read-only, by preventing content in the document or message from being copied, or by preventing the document or message from being printed. IRM relies on Windows Rights Management Services (Windows RMS), a Windows Server-based technology that IT administrators can configure to create the issuance license and perform the encryption of rights-protected documents. In addition, Windows RMS can be applied to email so that messages can circulate in a protected environment, but not be forwarded outside the organization. Windows RMS can also be applied to documents that are attached to email or stored on Microsoft SharePoint servers, limiting distribution and editing capabilities and helping to prevent information from being leaked to unauthorized personnel. IRM can be configured by using the Exchange ActiveSync policy Allow IRM over EAS. For more information about Information Rights Management, see the Information Rights Management topic (http://technet.microsoft.com/dd638140.aspx) on TechNet.

11

Certificates
Windows Phone 8 applications are signed with certificates that are unique to the application and that establish a license for the application. Only signed applications are allowed to run on Windows Phone 8. The only sources of apps for Windows Phone 8 are the Windows Phone Store (http://windowsphone.com/store) and company sites that offer line-of-business apps that are signed with enterprise certificates. A company can sign and distribute its own apps by following the procedures outlined in the Company app distribution for Windows Phone topic (http://msdn.microsoft.com/enus/library/windowsphone/develop/jj206943(v=vs.105).aspx) on MSDN to acquire an enterprise certificate from Symantec.

Applications and games can be made available in the Windows Phone Store through the Windows Phone Dev Center (http://dev.windowsphone.com). All submissions are reviewed for compliance with app policies. Approved applications and games are signed with VeriSign certificates. Certificates in Windows Phone 8 are primarily used to: Create a secure channel using Secure Sockets Layer (SSL) between a phone and a web server or service. Authenticate a user to a reverse proxy server that is used to enable Microsoft Exchange ActiveSync (EAS) for email. Install and license applications (from the Windows Phone Store or a custom company distribution site). Certificates can be installed on the phone using either of the following two methods: Installing certificates via 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 device. Installing certificates via email: The certificate installer supports .cer, .p7b, .pem, and .pfx files. To install certificates via email, make sure that 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 on the certificate file to review the contents and install the certificate. Typically, when an identity certificate is installed, the user is prompted for the password (or passphrase) that protects it. Note: Certificates may also be installed via Mobile Device Management service provider.

12

Mobile Device Management


Windows Phone 8 has native mobile device management (MDM) based off the OMA DM device management protocol, which organizations can use with Windows Intune or third-party MDM systems such as AirWatch, Mobile Iron, Zenprise, Symantec, and others to implement a managed environment for Windows Phone. MDM provides capabilities that include device enrollment and management, software distribution, configuration management, and reporting. If organizations also have Microsoft System Center Configuration Manager 2012 SP1, the Configuration Management console can be used to set policies, distribute apps, and view reports. The use of MDM offers several advantages over solely using EAS policy: One-step device enrollment and policy provisioning Line-of-business app deployment and automated deployment of company apps Ongoing app deployment and automatic app updates Remote or local removal of device enrollment, line-ofbusiness apps, and related app data Asset and inventory management Management of a custom Company Hub

13

The use of an MDM solution also facilitates comprehensive reporting functionality including: Server configured policy values Query installed enterprise apps Device name Device ID OS platform type Firmware version OS version Device local time Processor type Device model

Device manufacturer Device processor architecture Device language

Supported Exchange ActiveSync features by Exchange Server version


Although Windows Phone 8 supports the latest Exchange ActiveSync EAS features, previous versions of Exchange Server might not support all EAS features that are supported by Windows Phone. The following table shows the Exchange ActiveSync features that are supported in each version of Exchange Server. Exchange ActiveSync feature
Direct Push Email sync Calendar sync Contacts sync Remote wipe Sync multiple folders 128-bit SSL encrypted transmission User-initiated remote wipe Link access HTML mail GAL lookup Follow-up flags Meeting attendee information Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

14

Exchange Server 2007


Yes Yes Yes Yes Yes Yes Yes

Exchange Server 2010


Yes Yes Yes Yes Yes Yes Yes

Exchange Server 2013


Yes Yes Yes Yes Yes Yes Yes

Exchange ActiveSync feature


Autodiscover Bandwidth reductions Reply state Nickname cache Block/Allow/Quarantine list Allow attachment download 256-bit SSL encrypted transmission

Exchange Server 2007


Yes Yes No No No

Exchange Server 2010


Yes Yes Yes Yes Yes

Exchange Server 2013


Yes Yes Yes Yes Yes

15

No

Yes

Yes

No

Yes

Yes

Exchange ActiveSync Security


Supported Exchange ActiveSync policy settings
Similar to Group Policy settings for PC operating systems, Exchange ActiveSync (EAS) mailbox policies allow an administrator to apply a common set of policy and security settings to a group of users. EAS security-related configuration policy settings that can be managed by using the Exchange Management Console include those shown in the following table: Policy setting
AllowSimpleDevicePassword

16

Description
Specifies whether a simple device password is allowed. A simple password is one consisting only of repeated "2222" or sequential abcd" characters. The default is $true.

AlphanumericDevicePasswordReq uired

Specifies whether the password for the mobile phone must be alphanumeric. The default is $false.

DevicePasswordEnabled

Specifies whether a password is required. When set to $true, DevicePasswordEnabled requires that the user set a password for the mobile phone. The default is $false.

Policy setting
DevicePasswordExpiration

Description
Specifies the length of time, in days, that a password can be used. After this length of time, a new password must be created. The format of the setting is dd.hh.mm:ss; for example, 24.00:00 = 24 hours.

DevicePasswordHistory

Specifies the number of previously used passwords to store. When a user creates a new password, the user can't reuse a stored password that was previously used.

17

IrmEnabled

Specifies whether IRM is enabled for the mailbox policy.

MaxDevicePasswordFailedAttemp ts

Specifies the number of attempts a user can make to enter the correct password for the mobile phone before a device reset to factory settings is initiated. You can specify any number from 4 through 16. The default is 8.

MaxInactivityTimeDeviceLock

Specifies the length of time that the mobile phone can be inactive before the password is required to reactivate it. You can specify any interval between 30 seconds and 1 hour. The default is 15 minutes. The format of the setting is hh.mm:ss; for example, 15:00 = 15 minutes.

Policy setting
MinDevicePasswordComplexChara cters

Description
Specifies the number of character groups that are required to be present in the password. The character groups are defined as: Lowercase alphabetical characters Uppercase alphabetical characters Numbers Non-alphanumeric characters For example, if the value of MinDevicePasswordComplexChara cters is 2, a password with both uppercase and lowercase alphabetical characters would be sufficient, as would a password with lowercase alphabetical characters and numbers.

18

MinDevicePasswordLength

Specifies the minimum number of characters in the device password. You can specify any number from 1 through 16. The maximum length a password can be is 16 characters. The default is 4.

RequireDeviceEncryption

Specifies whether encryption is required on the device. Once set, device encryption automatically begins on the internal storage of the phone. The default is $false.

RemoteWipe

Deletes data on the user data partition and resets the phone to default settings.

Policy setting
AllowNonProvisionableDevices

Description
Specifies with the server running Exchange. When set to $true, it enables all mobile phones to synchronize with the Exchange server, regardless of whether the phone can enforce all the specific settings established in the Exchange ActiveSync policy. This also includes mobile phones managed by a separate device management system. When set to $false, this setting blocks mobile phones that aren't provisioned from synchronizing with the Exchange server. The default is $false.

19

Direct Push and Firewall Settings


For Direct Push to work through the network firewall, TCP port 443 must be open. This port is required for Secure Sockets Layer (SSL) and must be opened between the Internet and the Client Access server. The network idle connection time-out value indicates how long a connection is permitted to live without traffic after a TCP connection is fully established. The firewall session interval must be set to allow the heartbeat interval and enterprise session interval to communicate effectively. If the firewall closes the session, mail would be undelivered until the client reconnects, and the user could be unsynchronized for an extended period of time. By setting the firewall session timeout to a value that is equal to or greater than the idle timeout value on the mobile operator's network, the firewall will not close the session. Microsoft recommends setting the firewall's idle connection timeouts as follows:

Mobile operators should set the idle connection timeout values on outgoing firewalls to 30 minutes. Organizations should set timeout values on their incoming firewalls to 30 minutes.

Web servers, network security appliances, and system network stacks have several time-based thresholds that are intended to insulate them from insufficiently tested or malicious clients. You should be able to safely increase the idle connection time-out value setting without compromising the security of the network. The following table shows examples of attacks and describes how other settings can be used to mitigate exposure to them:

20

Denial of service (DoS) threat


A DoS attack is launched by failing to complete the handshake that is implicit in the creation of a TCP connection. The attacker attempts to create a large number of partially open TCP connections. A DoS attack is launched against IIS by opening a large number of TCP connections but never issuing an HTTP request over any of them.

Mitigation of exposure to attacks


The time within which a TCP handshake must be completed is a separate threshold that is governed by the Windows TCP/IP stack.

IIS mitigates this threat by requiring that a client submit a fully-formed HTTP request within a certain time before dropping the connection. The name of the connection time-out setting in the IIS management console is misleading; TCP connections are closed when the connection time-out value is exceeded (120 seconds by default).

An attacker establishes a large number of TCP connections, issues HTTP requests over all of them, but never consumes the responses.

This threat is mitigated by the same time-out as the previous scenario. The connection time-out setting in IIS defines the time within which a client must issue either its first request after a TCP connection is established or a subsequent request in an HTTP keepalive scenario.

A short time-out value causes the mobile phone to initiate a new HTTPS request more frequently. This can shorten the battery life of the mobile phone. Higher heartbeat intervals result in longer battery life for the phone.

SSL for Exchange Server encryption and authentication


To help protect outgoing and incoming data, deploy SSL to encrypt all Exchange Server traffic. You can configure SSL security features on an Exchange server to help prevent Internet-based server spoofing attacks and other types of attacks. The Exchange server, just like any web server, requires a valid server certificate to establish SSL communications. By default, when the Client Access Server role is installed, Exchange ActiveSync is configured to use either Basic authentication or Certificate-Based authentication (CBA) with Secure Sockets Layer (SSL). Exchange ActiveSync runs on a computer with Exchange that has the Client Access server role installed. This server role is installed with a default self-signed digital certificate. Although the selfsigned certificate is supported for Exchange ActiveSync, it isn't the most secure method of authentication. For additional security, consider deploying a trusted certificate from a third-party commercial certification authority (CA) or a trusted Windows public key infrastructure (PKI) certification authority. You can save a digital certificate to a file and install a digital certificate on a Windows Phone. A digital certificate might need to be installed on the Windows Phone device if Exchange ActiveSync is required to use Secure Sockets Layer (SSL) and your organization uses a certificate that isn't from a trusted commercial certification authority (CA). For more information about using SSL for server authentication, see the Configuring SSL and Exchange ActiveSync topic (http://technet.microsoft.com/en-us/bb430752(v=exchg.141).aspx) on TechNet.

21

Das könnte Ihnen auch gefallen