 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
The Operator typically determines the requirements for the security configuration. The most important consideration in this decision is the tradeoff between application compatibility and device security. The point chosen on this spectrum determines the rest of the security configuration.
The security model has many degrees of flexibility that can be used to configure the device in a very large number of ways. However, some of the settings are interdependent, so it is possible to create a security configuration that is not self-consistent. Such configurations would not represent a coherent policy. Among the configurations that are self-consistent, the ones that are most common map to the policy choices represented below. These four security configurations cover the entire spectrum of the trade-off between app compatibility and device security.
It is possible to implement the following four security configurations for Windows Mobile devices, both in one-tier and two-tier device settings.
| Security Configurations | Application Execution | Device Configuration | Remote API Access |
|---|---|---|---|
|
Security OFF No security checks at all. Previously known as "Unrestricted." |
All executables from any source can install and run with access to all the device resources. |
All configuration files from all sources will execute with all privileges. |
Any desktop application can access a connected device with all privileges. |
|
Prompt User is prompted when application source is unknown or anonymous. Previously known as "Standard." |
Allows user visibility into installation and execution when source is not known |
User must OK changes from unknown sources. |
Remote access is available. |
|
3rdParty-Signed Third party vendors that are identified through the Mobile2Market (M2M) program are allowed access. |
An application must be M2M signed to run on the device. |
M2M signed application vendors are required not to make configuration changes that impact security. |
Remote access is restricted. |
|
Locked Only the OEM and Operator, or their licensed vendors are allowed access. Previously known as "Restricted" |
Third party applications are not allowed to run or install. |
Only OEM and Operator can change configuration. |
Remote access is closed. |
Security-OFF – Not
Recommended
The Security OFF configuration implies that applications are not required to have code signatures. In this case, it would be possible for an attacker to write a malicious application while hiding his identity. A rogue application will be able to install and run on the device without any visible indication to the user or to the operator. This is especially troublesome because Windows Mobile devices typically have instant-on data connections. A rogue application could spread very rapidly among the device population before being detected.
Because of these risks, Microsoft does not recommend the Security OFF policy for any Windows Mobile device.
Prompt
Like Security-OFF, the Prompt configuration also does not require applications to be signed. This means that an attacker could create a rogue application while hiding his identity. However, with the Prompt policy, the installation and/or execution of an unsigned application would be visible to the user and under his/her control. This would have the effect of slowing down the spread of the rogue application in the device population. And it would give the user the ability to protect him/herself by saying no. The security system is enabled as well, so it is possible to revoke the application to prevent further damage.
There are a number of software vendors who released applications for Windows Mobile Standard without signing them. Among Windows Mobile Professional compatible applications, the share of those that are unsigned is much larger. Since the user has the option to allow unsigned applications, the Prompt policy is favorable towards application compatibility and allows the user to take advantage of the largest variety of applications compatible with his/her device.
However, allowing applications from unknown and anonymous sources comes with an inherent risk. Once the application is allowed to execute, defending against malicious code becomes much more difficult, and the damage potential becomes much greater. Therefore, the Prompt policy should be configured only after a careful consideration of the trade-off between application compatibility requirements and device security.
3rd Party Signed
In this configuration, the security system is designed to not allow anonymous applications. In order to run, the application must be signed with a certificate that chains to the root certificate of one of the Code Signing certificate authority (CA) that are vendors in Microsoft Mobile2Market (M2M) Program. The application developer's certificate is a strong code identity and ties the application developer's legal identity to the application. This creates some protection against rogue and intentionally malicious applications.
For more information about the
Mobile2Market
Programsee this
The most important enabler for a rogue application is the anonymous nature of code execution on most computing devices. An attacker can unleash a rogue application in a device population and be completely assured that his identity is not traceable. M2M removes this veil on anonymity. Certificate Authorities that participate in the M2M program verify the application developer's legal identity, through processes that are codified and audited. The certificate they issue to the application developer binds the application developer's legal identity. The signing process ensures that the identity is attached to the application developer's application. Thus, the application developer cannot deny responsibility for the actions of their applications.
The second enabler for rogue apps is the difficulty of collecting forensics that provide evidence of the intent to harm and the evidence of harm. The M2M program mitigates this problem by keeping track of signing activity, which provides evidence in the case of alleged wrong-doing.
Finally, application developers that participate in M2M are contractually required to ensure that their applications do not modify the security policy on the device. The application developers are also required to take full responsibility for the harm their applications may bring.
The verified legal identity, the contractual requirements, and the evidence of activity available in the signing program create a framework for enforceable security. This removes the veil of anonymity, enables forensic investigation, and creates an environment of legal accountability. This framework of enforceable security creates a strong deterrent against rogue applications.
Locked
Locked configuration implies that the device is out of reach for all third party applications.
Locked configuration is useful in settings where the device is not intended as a platform for third party applications. Such devices are designed to fulfill a specific function, and designed from hardware up to fulfill this function only. Examples are in industrial, vertically integrated settings where the device fulfils a business or work-flow function; appliances which operate in a standalone fashion with little or no general user interaction.
For settings where the device is intended as a personal communication device for consumers or business end-users, Locked configuration is not recommended. In such a setting, blocking third party application vendors severely reduces the value of the device to the user.