This section proposes a set of specific use cases to assist in the definition
and validation of a policy framework.
The use cases are not claimed to be exhaustive, but illustrative.
3.1 Policy management
These use cases relate to how a policy is created, configured and maintained.
Use cases vary according to:
-
who the authority for the policy is: either the user, or an external
authority such as an enterprise, or a combination;
-
the nature of the initial policy configuration (eg whether it is a universal
default, or is a specific policy determined by the authority to support a
specific objective);
-
the nature of the policy maintenance and update.
3.1.1 Use case PM1: user-controlled configuration
In this use-case:
-
the user of a device is the sole authority that decides access rights of
applications;
-
there is a "universal default" initial policy configuration;
-
there is no external policy authority and hence no externally-triggered
policy update. Policy maintenance occurs only to the extent that the user
modifies configuration settings interactively via a "preferences" facility, or
asks the UA to remember certain responses to prompts.
This use-case is the expected case in most situations where there is no
external policy authority such as a network operator or enterprise.
Although the initial configuration is "empty" (ie it only contains universal
default rules), it is possible for the policy to be extended over time as the
cumulative result of explicit user configuration and persistently remembered
user decisions.
The configured policy, at any given time, may be stored locally on the device
or may be stored remotely and be accessible via a network service, or both.
3.1.2 Use case PM2: user-delegated configuration
In this use-case:
-
the user of a device delegates authority for access control policy to an
external service provider;
-
the external service provider provides advice on the trustworthiness of
specific applications, and determines an access control policy that embodies
that advice. The advice may be based on a knowledgebase of known trustworthy
and/or malicious applications, or algorithms for detecting malicious
behaviour, or both;
-
the policy defined by the external authority is updated regularly in
response to new information on known threats.
The policy configuration provided by the external policy provider may be
supplemented by user control as in PM1.
The configured policy, at any given time, may be stored locally on the device
or may be stored remotely and be accessible via a network service, or both.
This use-case mirrors current practice with products such as virus scanners or
other malware detectors.
3.1.3 Use case PM3: external policy authority
In this use case:
-
an external body has authority over the device and, in particular, security
policy configuration.
-
an initial security policy configuration may be provided by the external
authority, together with any other associated device configuration (such as
root certificates). The configured policy may determine acces control policy
without reference to the user, or may refer certain decisions to the user.
-
the policy may be updated periodically under the authority of the policy
authority. Policy maintenance may also occur as the cumulative effect of
certain user decisions being remembered.
The external policy authority may configure the policy as part of the
commissioning of the device (eg a network operator's configuration applied by
the manufacturer prior to sale, or an enterprise configuring device policy
using a secured device management interface).
In determining the policy, the policy authority has the opportunity to define
a policy that supports a specific objective - such as to limit access to APIs
to only those web applications that are themselves distributed by the policy
authority (eg to control its exposure to the financial risk of abuse of device
APIs).
3.2 Policy interoperability
These use cases relate to reading and writing of policy definitions in an
interoperable format.
3.2.1 Use case PI1: device-independent policy definition
In this case case, a single policy authority wishes to define and configure a
security policy for multiple dissimilar devices. A typical network operator's
portfolio many include tens or even hundreds of models, each based on
different platforms, and different UAs. A commonly supported interoperable
format for configuration of a policy dramatically impacts the practicality of
achieving the desired configuration across all devices. This is relevant to
Policy Management use case PM3.
3.2.2 Use case PI2: portability of user settings
A user may establish a policy configuration (through explicit configuration of
preferences, and remembered decisions) and there is the option of reusing this
configuration across multiple devices. A user with multiple devices may wish
for their security preferences to be consistent (or to at least have the
option of consistency) across those devices. Rather than have to manually
configure the preferences on each device, it should be possible for there to
be a seamless security experience across devices, e.g. by switching SIM card
between devices and as a result automatically applying a policy resident on
the SIM card or synchronizing with a network-based policy management system. A
specific case is the case where a user wishes to transfer a configuration from
an old device to a new device. This is relevant to Policy Management use cases
PM1, PM2, PM3.
3.2.3 Use case PI3: policy provisioning as part of service deployment
Configuration of some parts of access control policy may be part of the
overall configuration required to enable a particular application or service.
This, along with many other configuration parameters, may be remotely
configurable via device management. The configuration required to enable a
service may be provided by the service provider as a policy fragment, to be
added to the overall policy by the policy authority. An interoperable
representation of such policy fragments would enable this to be done without
authoring the configuration updates separately for each target device,
platform, or UA.
3.3 Examples of statements or rules that may be expressed in a policy
These use cases are specific examples of statements or rules that may be
expressed in a policy.
-
A widget whose signature chains to operator root can read and write
from the PIM databases.
-
A widget downloaded from
weather.example.com can access
geolocation coordinates if the user says it’s OK.
-
The
weather.example.com widget can connect to
weather.example.com without
notifying the user, except when roaming.
-
All widgets with a reliably identified author can save data
persistently if the user says it’s OK.
-
No widget can get my location, no matter who trusts it.
-
No widget can access
evil.example.org.
-
An unsigned widget cannot launch another application without user
consent.
Example web site use cases, to give examples of the types of
policy that might be expressed:
-
A reliably identified website can access geolocation
coordinates if the
user confirms it’s OK.
-
Any website in a subdomain
of
mynetwork.example.com can read phone
status
properties.
-
Reliably identified websites can send and receive SMS
except to premium
rate numbers.
-
evil.example.com cannot access any device APIs.
-
The
weather.example.com foo widget
can access geolocation coordinates but
only if it’s embedded on the foo home page.
3.4 Abuse Cases
This section outlines some abuse cases for misuse of APIs.
The landscape that is being created is the enablement of cross-platform, cross-device, easy to develop, highly functional applications based on browser technology that has been proven repeatedly to be untrustworthy - a perfect recipe for evil. Will this meet all the criteria for really successful malware on mobile devices for example?
Up until now the measures taken by the mobile industry have proven highly successful in ensuring no major malware incident has affected the industry. There have been attempts: the MMS-spreading Commwarrior is probably the most infamous, along with the Spyware tool, Flexispy. An additional factor in ensuring the success of mobile security has been the fact that mobile platforms have been too fragmented and complex, therefore not representing an attractive target so far. Existing modus operandi from technology-related attacks can provide indicators as to the types of attack and abuse that can be expected on widgets and web applications as device APIs are opened up.
3.4.1 Abuse Case AC1: Premium Rate Abuse
A widget that seems benign but is actually spewing out SMSs to premium rate numbers without the user’s knowledge. This could be modified from an original safe widget such as a game. For the malware author, the key piece to solve is to dupe the user into thinking that the SMS capability is something that is part of the original application. Examples of this have been seen in the past, created from games and this model could be used for ‘diallers’ too (which plagued the desktop world in the days of dial-up networking). There have been recent warnings about this kind of abuse from security firms.
3.4.2 Abuse Case AC2: Privacy Breach
An application that gains access to locations, contacts and gallery, silently uploading the data in the background to a site owned by the attacker. This is something that has been a clear goal for attackers already. There have been numerous high-profile examples in the past in the mobile world. Celebrities such as Paris Hilton, Miley Cyrus and Lindsay Lohan have all had private pictures, phone numbers and voicemails stolen from devices or networks in clear breach of their privacy. There has been embarrassment for teachers who had their pictures and videos copied by the children in their class and spread around school. The most high-profile case in the UK of a mobile related privacy breach was that of the News of the World's use of voicemail hacking to gain access to private information about Royalty. The Royal editor, Clive Goodman was jailed for four months and the editor, Andy Coulson resigned over this blatant privacy breach. Given the appetite for breaching privacy, users need to be safe in the knowledge that their personal data will not leak in any way.
3.4.3 Abuse Case AC3: Integrity Breach
A widget that replaces the voicemail number with a premium rate number instead? There are number of reasons why an attacker would want to breach the integrity of the device. Simply changing the telephone number of the voicemail that is stored on the device could be enough to make an attacker a lot of money. Users usually have a shortcut key to their voicemail and may not notice for a long time that anything is wrong. A more sinister use could be to plant evidence on a device. Pictures, files and even criminal contacts could potentially be anonymously planted all without the user's consent or knowledge. Proving innocence could suddenly become very difficult.
There are also a number of reasons why somebody would want to steal data. The contents of corporate e-mails would be very interesting to a competitor, as would sabotaging data stored in spreadsheets and presentations on the target phone.
3.4.4 Abuse Case AC4: Phishing
A widget that replaces the voicemail number with a premium rate number instead? There are number of reasons why an attacker would want to breach the integrity of the device. Simply changing the telephone number of the voicemail that is stored on the device could be enough to make an attacker a lot of money. Users usually have a shortcut key to their voicemail and may not notice for a long time that anything is wrong. A more sinister use could be to plant evidence on a device. Pictures, files and even criminal contacts could potentially be anonymously planted all without the user's consent or knowledge. Proving innocence could suddenly become very difficult.
There are also a number of reasons why somebody would want to steal data. The contents of corporate e-mails would be very interesting to a competitor, as would sabotaging data stored in spreadsheets and presentations on the target phone.