|
|
Deploying ‘Smart Device’ PoliciesA PRACTICAL GUIDE TO DEPLOYING ‘SMART DEVICE’ POLICIES“Smart phones have become essential tools for business. To maximise their benefits, companies should determine which features and functions are appropriate in the user’s work environment, which capabilities if enabled could encourage risky behaviour, and which are not required to complete the task…Companies should therefore assess which general functions and capabilities will be enabled or disabled for its workers based on its general business practices, industry requirements, and regulatory compliance needs…This paper will quantify an approach to identifying the most appropriate policies in various situations, and look at their impact both on the end user and the business. INTRODUCTIONMost organisations will benefit by effectively managing their mobile devices. Benefits include lower cost of operations, securing against leakage of corporate data assets, meeting regulatory guidelines, maximising workforce efficiency and minimising support costs. Specific industries and worker classes may have unique requirements against which companies must develop a comprehensive set of policies and procedures to effectively deploy and maintain mobile devices. This guide will address creating requirements for specific scenarios and then provide concrete recommendations on which Smart Device policies should be set to meet the organisation’s management and security needs. The policies included in this guide should generally be applicable to most if not all such devices. DEFINING MOBILE WORKER SMART PHONE POLICIESSmart phones have become essential tools for business. To maximise their benefits, companies should determine which features and functions are appropriate in the user’s work environment, which capabilities if enabled could encourage risky behaviour, and which are not required to complete the task. For instance, some device features geared towards the consumer usage model create limited or even potentially harmful business effects (e.g., cameras, media players, web surfing, texting). Enabling them may be beneficial to the user despite not being work required, but companies must evaluate appropriate policy on a risk/reward basis. Companies should therefore assess which general functions and capabilities will be enabled or disabled for its workers based on its general business practices, industry requirements, and regulatory compliance needs. Many companies determine their own set of corporate standards concerning compliance that may either be an extension of existing external guidelines and regulations, or may be an attempt to create their own internal standards when no clearly defined external regulatory requirements exist. It is not uncommon for companies to have a pre-defined set of policies they have established which are created to limit liability and create a standardised environment for all employees. However, not all workers in the organisation are necessarily treated equally, and specific rules and exceptions based on defined classes of workers, device type, specific organisational roles, and/or level within the corporate hierarchy may modify these general policies and their enforcement on an exception basis. Organisations should therefore remain flexible in specifying and deploying polices, and should assume that there will be individual exceptions to many of the general policies. POLICY IMPACT STATEMENTCompanies must evaluate their policy requirements based on the impact they will have on both the business and the end user. Different business entities based on size or industry may be concerned with setting different polices. And different classes of users may have different desires and needs. Every policy choice will have an impact on the end user, as well as the organisation. Full device lockdowns will maximise the end user impact by preventing users from accessing some functions of the device, but may offer increased amounts of protection to the business. Each person, group and organisation will see a different policy impact depending on job function, type of work done, regulatory situation, type of information accessible by users, etc. Risk/Reward considerations are important to judge what level of policy is acceptable in each situation. We recommend taking the approach of building a Policy Impact Statement that specifies what the impact will be on both the end user and the business entity when specific policies are enacted. From this analysis, companies can determine the requirements (on a scale of low to high) for implementation of various organisational and group policies. This paper will quantify an approach to identifying the most appropriate policies in various situations, and look at their impact both on the end user and the business. We will also look at various job functions and generalise a set of policies for each based on certain assumptions about risk/reward and policy impact. Our impact measurement will consist of a balance between the needs of the business and the wants/desires of the individual. For this evaluation, we will use the following ranking:
The three colour coded levels represent a continuum from maximum openness of the device and end user control (Green) to maximum control by the enterprise or organisation with limited control and access by the end user (Red). Red level policy settings will have the maximum impact on end users who may not appreciate the lack of personal flexibility. But Red also allows organisations to exert maximise control and achieve the highest level of management and security. Many company policies will fall somewhere in the middle. DETERMINING REQUIREMENTSWhile the needs of individual organisations will vary, we believe the following criteria need to be evaluated on a company by company basis in order to achieve a proper user and corporate impact balance. Organisations need to identify such key characteristics as:
Each of these criteria will have an effect on the overall policy enforcement decision process, and will affect the level (e.g., green, red, something in between) of the general policies implemented. COMPANY SPECIFIC REQUIREMENTSCompanies need to assess which policies are appropriate based upon their industry, size, regulatory requirements, mobile applications requirements, type of mobile workforce, etc. Appropriate policy setting will have an impact on the overall operations and efficiency of the organisation. Policies may initially be evaluated on a company-wide basis, with some general company classes defined below. However, organisations should make certain modifications/exceptions to their general organisation-wide policies based on the needs of the various classes of users within the company, which will be addressed in the next section. CLASS 1 – HIGHLY REGULATED INDUSTRIESIndustries such as financial services, health care, banking, insurance, retail and other companies that work with customer data and individual records are subject to a number of governmental regulations and significant penalties for non-compliance. These companies must use utmost care to prevent any data exposure, and often set policies that are highly restrictive. This class of company will generally engage in the most stringent review of user requirements and set the most stringent policies, including locking down features of the device (e.g., app loading, media player, web access) and severely restricting individual user control. CLASS 2 – LARGER ORGANISATIONSEnterprises generally have a high level of security in place to prevent the loss of sensitive corporate data and to limit the ability for outsiders to obtain access to corporate resources. These organisations generally set policies that make access and data discovery difficult, and often limit the type of user applications that can be utilised. However, enterprises may have a significant number of different user classes with diverse application needs (e.g., email, CRM, ERP) requiring multiple policies to meet individual needs rather than a single company-wide policy. Nevertheless, most policies are set at relatively high levels to minimise risk, ensure corporate safety, and limit the amount of end user control over the device (e.g., only accessing email in a corporate-sanctioned way). CLASS 3 – MEDIUM SIZED ENTERPRISESMid-sized organisations are often less restrictive than large enterprises, allowing a reasonable amount of latitude in defining and implementing mobile device policies. This class of organisation will generally set those policies that affect corporate access and data use to a medium level of restrictiveness, but may have individual policies modified for classes of workers (e.g., executives), and have relatively few restrictions on the personal use of the device. CLASS 4 – SMALLER BUSINESSESSmaller businesses generally implement a limited amount of policy level changes and often utilise the default settings inherent in deployed mobile infrastructure systems. Generally these organisations deploy the least restrictive level of policy and allow users the maximum amount of self control over their device. USER CLASS SPECIFIC REQUIREMENTSCompany specific requirements are clearly important but may not be the only consideration in choosing which policy to implement for a given individual. Mobile workers in many organisations will fall into several different categories or user classes based on their function and level in the organisation. And in addition to evaluating the impact based on specific organisational characteristics, companies should base any potential exceptions to general policies by identifying the needs of workers that fall into the following typical user classes: CLASS 1 – HIGH LEVEL EXECUTIVESThese individuals generally have access to highly sensitive corporate data files and communications as well as being subject to the most stringent regulatory compliance requirements. Policies for this class must include a high degree of data leakage prevention and device control. However, quite often this user class will not accept complete feature/function lockdown of the device, and will have the ability to influence or select certain features to be enabled. They may even have an ability to select alternative device models according to their own preference. Any policies governing this class will therefore have to take a balanced approach by maximising corporate protection while allowing end user flexibility. This class will have the most exceptions implemented against general organisational policies, and can generally demand certain capabilities be implemented. CLASS 2 – GENERAL KNOWLEDGE WORKERSThis class of workers is often involved in the day to day operations of the company and has access to sensitive corporate communications. Less impacted by regulatory issues than higher level executives, this class nevertheless requires a relatively high level of data leakage protection and device security. Access to functions like email, applications enablement, web and IM/texting are often required and should generally be allowed. Many companies also allow access to features like media player, camera and gaming. This class may have a significant number of individual exceptions to general organisational polices. CLASS 3 – ADMINISTRATIVE AND SUPPORT STAFFThis class of worker is generally involved in supporting executives and knowledge workers, and must have access to communications functions (email, texting) and certain types of applications involved in day to day operations. Most companies choose to control access to non-job specific functions of the device (i.e., web surfing, media player, camera) for this class of worker. This class of worker generally does not have the ability to obtain an individual exception to organisational policies. CLASS 4 – PRODUCTION WORKERSThis class usually has the most restrictions applied to it as organisations generally lock out any capability that is not job-specific in nature. This class often has dedicated applications deployed, and may also include access to communications functions (i.e., email, IM). Most other functions/capabilities are governed by the corporate policies and few individual exceptions are implemented. CLASS 5 – USER LIABLE DEVICE OWNERSThis is a relatively new user class that is based on the growing trend in which organisations allow their users to choose their own preferred device (within certain guidelines). This class is also often a subclass of the higher level (executive and knowledge worker) classes. It also represents the greatest challenge to organisations, as not all devices are equal to deploying business policies, even though many of the users in this class have access to very sensitive information. Companies must carefully evaluate offering User Liable devices based on the ability to manage and deploy corporate policies to those devices. Often, such devices will have only limited capabilities available to users to limit organisational exposure (i.e., limited access to email, and virtually no access to corporate apps). As the number and type of popular devices change, the need for individual exceptions to organisational policy will grow. SOME IMPACT GUIDELINESBelow are some specific guidelines that companies can follow to determine what level of control they should exercise. This is a suggested ranking and each organisation should evaluate their specific needs on an individual basis. We will look at 5 key criteria: Company Characteristics, Industries, Access Types, Application Requirements and User Classes. We then suggest guidelines for each of the criteria for each level of control. GREEN LEVELCOMPANY CHARACTERISTICS: Primarily non-regulated industries and those industries that don’t regularly work with personal or confidential materials. This level is also generally relevant for smaller organisations in the industries below that don’t wish to supplement the default policies shipped with the device. INDUSTRIES: These industries might include construction, manufacturing, package delivery, real estate, facilities maintenance and some trades. ACCESS TYPES: Voice, email, messaging, limited Internet connectivity, limited or no organisational-specific applications. APPLICATION REQUIREMENTS: Primarily email based interactions. If any specific-use applications are required, they are primarily Web-based accessed through a browser. The user will have access to most features that are available within the standard device for both business and personal use. USER CLASSES: Generally applied to administration and support users and users with user liable devices that don’t meet stricter company policy enforcement capabilities. In some cases, other classes may meet this level, but usually on an exception basis. YELLOW LEVELCompany Characteristics: Organisations that deal with sensitive company or client information that could be sensitive if disclosed. This includes company financial data, competitive information, and client directed interactions. This level may be relevant as a more secure environment than the one above for smaller organisations in the industries below. This level is generally applicable for medium to larger organisations and those that are divisions within enterprises who require access to corporate systems. INDUSTRIES: Education, maintenance and repair workers, retail clerks, tradesmen, knowledge workers, information technology, consultants, professional services ACCESS TYPES: Voice, email, messaging, customer contact information, personal information on clients and organisational information, access to corporate back office systems, special purpose applications, web browsing. APPLICATION REQUIREMENTS: Limiting organisational or industry-supplied applications to specific purposes, including limitations on use of personal applications to minimise organisational exposure to sensitive data loss. Users often require access to customer data and corporate applications (e.g., Exchange, Word, Excel, CRM, ERP). This may require purpose-build applications. Organisations should restrict some functions of the device and limit the ability to download new applications to protect sensitive data on the device. Restrictions to user control of the device (e.g., password, configuration) are generally applied. USER CLASSES: General knowledge workers fall into this category, as do some higher level executives in unregulated industries or where data is not of a sensate nature. Some knowledge workers and executives may fit into this category by exception even within companies that generally would set higher level policies for their use. RED LEVELCOMPANY CHARACTERISTICS: Companies that have real time data requirements and where information transmission in a time critical manner is imperative. These organisations are often public service entities, or workers within larger organisations that may need access to corporate applications, data and resources. This class applies to organisations that work with credit card information, financial transaction records, personally identifiable information, or corporate sensitive information and that must meet strict regulatory compliance and legal requirements. Many corporate executives often fall under this category. INDUSTRIES: Public utilities, public services (e.g., Fire, Police), health care, enterprise executives, financial services, accounting, legal services ACCESS TYPES: Voice, email (restricted to organisational infrastructure), limited messaging, limited app loading and use (restricted to organisational selection and loading), limited use of personal apps (e.g., media player, personal messaging) that may hinder or expose sensitive information, and may or may not allow web browsing depending on circumstances. APPLICATION REQUIREMENTS: Often includes purpose-built apps that are the cornerstone of the worker’s productivity. Such dedicated workers are restricted from the more personal use capabilities of the device, which they can access by exception only (e.g., web browsing, music, camera, peripheral support). Most devices in this class of user are heavily controlled by the organisation to protect against any sensitive and potentially legally actionable data losses. While some organisational special purpose apps are included, the scope and access capability are closely managed. This group generally has no user control of device set-up, modification and working parameters. USER CLASSES: This level is generally reserved for classes of workers dealing with highly sensitive data and/or dedicated production workers who need to have access limited to specific functions. Support and Administration classes may also fall into this category, as well as certain knowledge workers. User liable devices with minimal policy enforcement capabilities also fall into this category. HOW TO USE THIS GUIDEBelow we identify 10 policy area groupings that include generally related policies, and then within each grouping, three policy enforcement levels (green, yellow and red) that represent increasingly more stringent levels of organisational control and/or meet particular needs. Most companies will likely implement the suggested policy settings primarily from the green or yellow group, with organisations implementing the red policy settings to meet the special or more stringent control requirements of certain regulated industries or organisational classes. For each colour coded setting, we provide a suggested setting point for that policy (either the default value, or an alternative). As a general rule, the green policy settings define what we believe is a minimum setting, enabling maximum control by the user. Control shifts increasingly towards the organisation as policy settings in the yellow and red levels are implemented. Companies with a specific general policy level setting may need to modify that setting for a particular class of users. Therefore, although an organisation may choose a general policy setting, individual exceptions for specific classes of users may require a change to that setting (either higher or lower), and companies should evaluate users based on both general policy and class before a final setting is determined. Although many organisations can likely accept the recommended settings provided for many policies, they should nevertheless evaluate the suggested settings to see if they meet the particular needs of the organisation. The policy settings identified by the three colour codes are suggestions and/or starting points and companies should look at each policy keeping its own unique needs in mind, and then accept or modify them accordingly. Below we provide details on the individual policy groupings, and then provide recommended settings based on our color-coded criteria described earlier. POLICY “GROUPINGS”Many related policies can be grouped together to achieve a specific purpose or set a specific control point. These policy groupings can then be set at a specific level to achieve a broad-based level of management and/or protection for the organisation. While the groupings are somewhat subjective, below are 10 key areas where we believe grouping policies can be effective. Further, these groupings allow the organisation to asses the level of importance or criticality to the business in enforcing these policies, by assigning a relative value to them based on the organisation’s profile (e.g., size of business, industry, regulatory and statutory obligations, etc.). LOGON AND AUTHENTICATION AND DEFAULT SETUP This grouping is related to the need for passwords and authentication on the device. The complexity level of the password is relevant as more complex passwords are harder to guess and therefore offer more security should the device be lost or stolen. Further, timeouts provide an ability to lock a device after it remains idle. Finally, this group also sets up various end user preferences, defaults and functions related to the device and desktop interactions. PREVENTING UNAUTHORISED USE This grouping is related to blocking unauthorised users from gaining access to the device and discovering potentially sensitive data contained therein. It includes owner information and lockout settings which are critical to protect the data contents of the device. DATA PROTECTION AND ENCRYPTION This grouping involves policies which protect individual files and data stored on the device. It involves policies which enforce private key storage for encryption, content protection strength, encryption settings/strength, and device wiping. These policies are necessary to secure the device, set the device for compliance with various standards, and clear the device of sensitive information should it be lost or stolen. APPLICATION LOADING AND CONTROL This grouping defines the types of applications that can be loaded onto the device, as well as how and when applications may be used. These policies establish how users interact with the device and how the organisation controls that interaction. MALICIOUS CODE AND USER ACTION LIMITATION This grouping provides control of applications to prevent loading unsafe or malicious applications to the device. It further defines the actions and limitations of the browser, to protect the device from malicious attack. MANAGING NETWORK ACCESS AND CONNECTIVITY This grouping involves policies that define how and when the device connects, what location information is provided, and SIM-related functions and capabilities such as when and how calls are made. These policies also define how often and what contents of the device are synchronised to protect the integrity of the device and its data. MESSAGING AND COLLABORATION FUNCTIONALITY This grouping defines the functions and capabilities of the device in the various messaging functions it enables., including SMS, MSM and PIN to PIN messaging, the messaging encryption key management and the duration of time between synchronisation. WEB ACCESS CONTROL This policy grouping controls the functionality of the browser and Internet access, including when it can be used, what functions of the browser are available, what types of content can be viewed and how attachments may be handled. This policy grouping is critical to determining the device’s Internet capabilities for general browsing as well as company Internet-based applications. PERIPHERAL ENABLEMENT (E.G., CAMERAS, BLUETOOTH, SD CARD) This grouping determines how peripherals, particularly Bluetooth enabled peripherals, will connect and interact with the device. Further, it determines how add-on memory functions, as well as camera functionality. This grouping determines the ability of the device to utilise external and internal peripheral resources and provide a way for organisations to prevent user interactions with peripherals. MEDIA ACCESS
This grouping provides policies to determine how media on the device will be accessed and what functionality users will have enabled. POLICY SETTING RECOMMENDATIONSBelow, within each of the groupings identified above, we indicate a recommended policy setting for each colour coded level (green, yellow, red) representing the levels from maximum end user control to maximum organisational control. There are obviously hundreds of individual polices that can be set, but we have included only the most obvious, popular settings in this guide. LOGON AND AUTHENTICATION AND DEFAULT SETUPPASSWORD REQUIRED This rule specifies whether a user must configure a password on a ‘Smart Device’. We recommend the following settings:
USER CAN DISABLE PASSWORD This rule specifies whether a user can turn off a ‘Smart Device’ password. We recommend the following settings:
FORCE LOCK WHEN HOLSTERED This rule specifies whether a ‘Smart Device’ locks when a user inserts it in the holster. We recommend the following settings:
SET OWNER INFO This rule specifies the owner information that appears on a ‘Smart Device’. We recommend the following settings:
MAXIMUM PASSWORD AGE This rule specifies the number of days before a ‘Smart Device’ password expires and a user must set a new password. We recommend the following settings:
MAXIMUM PASSWORD HISTORY This rule specifies the maximum number of previous passwords that a ‘Smart Device’ checks new passwords against to prevent a user from reusing previous passwords. We recommend the following settings:
MINIMUM PASSWORD LENGTH This rule specifies the minimum number of characters that are required for a ‘Smart Device’ password. o We recommend the following settings:
SUPPRESS PASSWORD ECHO This rule specifies whether, after a given number of incorrect password attempts, the characters that a user types in the Password dialog box appear on the screen. We recommend the following settings:
LOCK OWNER INFO This rule specifies whether a user can change the owner information for a ‘Smart Device’. You can lock the Information field, the Name field, or both fields.
SET MAXIMUM PASSWORD ATTEMPTS: This rule specifies the number of password attempts that a user can make before a ‘Smart Device’ erases all of the application data. The permitted range is 3 through 10 attempts. We recommend the following settings:
SET PASSWORD TIMOUT: This rule specifies the number of minutes of inactivity before the security timeout occurs and a ‘Smart Device’ user must type the password to unlock the ‘Smart Device’. We recommend the following settings:
PASSWORD PATTERN CHECKS This rule specifies whether to verify that a ‘Smart Device’ password matches certain character pattern requirements. We recommend the following settings:
Figure 1: Logon and Authentication and Default Setup Group - Classification Where Policies Must First Be Changed From Default  PREVENTING UNAUTHORISED USE •MAXIMUM SECURITY TIMEOUT This rule specifies the maximum time (in minutes) that a ‘Smart Device’ user can specify as the security timeout value. The security timeout value is the number of minutes of inactivity before the device locks. The permitted range is 10 through 480 minutes. We recommend the following settings:
USER CAN CHANGE TIMEOUT This rule specifies whether a ‘Smart Device’ user can override the security timeout value. We recommend the following settings:
REMOTE WIPE RESET TO FACTORY DEFAULTS This rule specifies whether a ‘Smart Device’ resets to the default settings when it receives the Erase Data and Disable Handheld IT administration command over a wireless network. We recommend the following settings:
ALLOW OUTGOING CALL WHEN LOCKED This rule specifies whether users can place calls while a ‘Smart Device’ is locked. We recommend the following settings:
ENABLE LONG-TERM TIMEOUT This rule specifies whether a ‘Smart Device’ locks after a predefined period of time, regardless of user activity. We recommend the following settings:
Figure 2: Preventing Unauthorised Use - Classification Where Policies Must First Be Changed From Default DATA PROTECTION AND ENCRYPTION  CONTENT PROTECTION STRENGTH This rule specifies the cryptography strength that a ‘Smart Device’ uses to encrypt content that it receives while it is locked. When you specify a value, the content protection feature is turned on. We recommend the following settings:
DISABLE ADDRESS BOOK TRANSFER This rule specifies whether to prevent a ‘Smart Device’ from exchanging address book data with a supported Bluetooth® enabled device. We recommend the following settings:
DISABLE FILE TRANSFER This rule specifies whether to prevent a ‘Smart Device’ from exchanging files with supported devices. We recommend the following settings:
ALLOW SCREEN SHOT CAPTURE This rule specifies whether a ‘Smart Device’ permits applications, including third-party applications, to take screen shots. We recommend the following settings:
REQUIRE LED CONNECTION INDICATOR This rule specifies whether the LED must flash when a ‘Smart Device’ is connected to a Bluetooth® enabled device. We recommend the following settings:
DISABLE PHONE CALL LOG WIRELESS SYNCHRONISATION This rule specifies whether wireless data synchronisation for call logs is turned off. We recommend the following settings:
DISABLE MEMOPAD WIRELESS SYNCHRONISATION This rule specifies whether wireless data synchronisation for memos is turned off. We recommend the following settings:
DISABLE ORGANISER DATA ACCESS APPLICATIONS This rule specifies whether an application can access the ‘Smart Device’ PIM APIs, which control access to the user's personal information on the ‘Smart Device’, such as the address book. We recommend the following settings:
DISABLE WI-FI DIRECT ACCESS TO ‘SMART DEVICE’ ENTERPRISE SERVER This rule specifies whether a ‘Smart Device’ can connect to the ‘Smart Device’® Enterprise Server using a Wi-Fi® connection. We recommend the following settings:
DISABLE WIRELESS BYPASS This rule specifies whether a ‘Smart Device’® device uses wireless bypass using Bluetooth® technology We recommend the following settings:
DISABLE WI-FI IT This rule specifies whether a user can access a Wi-Fi® network from a Wi-Fi enabled ‘Smart Device’. We recommend the following settings:
KEEP MESSAGE DURATION This rule specifies the maximum time (in days) that a ‘Smart Device’ keeps messages. The permitted range is -1 through 180 days. We recommend the following settings:
Figure 3: PREVENTING UNAUTHORISED USE - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
APPLICATION LOADING AND CONTROL Allow Application Download Services This rule specifies whether application download service icons appear on a ‘Smart Device’ when the wireless service provider assigns a service to a ‘Smart Device’ and the appropriate service books are present on the ‘Smart Device’ device. We recommend the following settings:
DISALLOW THIRD PARTY APPLICATION DOWNLOADS This rule specifies whether a user can install an application that the device/corporate signing authority system has not digitally signed on a ‘Smart Device’. We recommend the following settings:
DISABLE PUBLIC PHOTO SHARING APPLICATIONS This rule specifies whether to prevent a ‘Smart Device’® device user from uploading pictures to the Internet using public photo sharing applications. We recommend the following settings:
DISABLE PUBLIC SOCIAL NETWORKING APPLICATIONS This rule specifies whether a user can install public social networking applications on a ‘Smart Device’ to access public social networking services (for example, Facebook®). We recommend the following settings:
ALLOW THIRD PARTY APPS TO USE SERIAL PORT This rule specifies whether third-party applications can use the serial port, IrDA® port, or USB port on a ‘Smart Device’. We recommend the following settings:
DISABLE ‘SMART DEVICE’ APP WORLD This rule specifies whether the Application (App) Store is turned off on the ‘Smart Device’ We recommend the following settings:
DISABLE APPLICATION CENTRE This rule specifies whether to prevent the application centre from running on a ‘Smart Device’. We recommend the following settings:
Figure 4: APPLICATION LOADING AND CONTROL - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
MALICIOUS CODE AND USER ACTION LIMITATION Disable Serial Port Profile This rule specifies whether a ‘Smart Device’ can use the Bluetooth® SPP. We recommend the following settings:
DISALLOW DEVICE USER REQUESTED UPGRADE This rule specifies whether to prevent a ‘Smart Device’® user from requesting available updates for the ‘Smart Device’ Software over the wireless network. We recommend the following settings:
DISALLOW DEVICE USER REQUESTED ROLLBACK This rule specifies whether to prevent a ‘Smart Device’® device user from returning to a previous version of the ‘Smart Device’ Software after a previously successful update of the ‘Smart Device’ Software over the wireless network. We recommend the following settings:
DISABLE DESKTOP CONNECTIVITY This rule specifies whether to prevent a ‘Smart Device’ from using Bluetooth® technology to connect to the ‘Smart Device’ Desktop Software. We recommend the following settings:
ALLOW NON ENTERPRISE UPGRADE This rule specifies whether to permit The Device manufacturer or a wireless service provider to request that a ‘Smart Device’ download updates to the ‘Smart Device’ Software over the wireless network. We recommend the following settings:
ATTACHMENT VIEWING This rule specifies whether a ‘Smart Device’® device user can view supported attachments in messages and calendar entries. We recommend the following settings:
Figure 5: MALICIOUS CODE AND USER ACTION LIMITATION - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
MANAGING NETWORK ACCESS AND CONNECTIVITY Disable Discoverable Mode This rule specifies whether to prevent ‘Smart Device’® users from making their ‘Smart Device’ discoverable. A ‘Smart Device’ that is discoverable can be found by other Bluetooth® enabled devices within range of the ‘Smart Device’. We recommend the following settings:
WI-FI ALLOW HANDHELD CHANGES This rule specifies whether users can change all Wi-Fi® policy rules on their ‘Smart Devices’. We recommend the following settings:
ENABLE ENTERPRISE LOCATION TRACKING This rule specifies whether a ‘Smart Device’® can use the GPS feature to report its location to the ‘Smart Device’ Server regularly. A ‘Smart Device’ user must click Yes when prompted to permit location tracking on a ‘Smart Device’ device. We recommend the following settings:
ALLOW PUBLIC WLM SERVICES This rule specifies whether a user can use Windows Live™ Messenger on a ‘Smart Device’ We recommend the following settings:
DISABLE FORWARDING BETWEEN SERVICES This rule specifies whether to prevent a ‘Smart Device’ user from forwarding or replying to a message on a ‘Smart Device’ using an email account or messaging service that is associated with a ‘Smart Device’ Server or ‘Smart Device’ Internet Service that is different from the service that delivered the original message. Use this rule to prevent forwarding or replying to a PIN message with an email message, or replying to an email message with a PIN message. We recommend the following settings:
DISABLE DIAL-UP NETWORKING This rule specifies whether to prevent a ‘Smart Device’ from using the Bluetooth® DUN profile We recommend the following settings:
ALLOW SPLIT-PIPE CONNECTIONS This rule specifies whether applications, including third-party applications, can open internal and external connections on a ‘Smart Device’ simultaneously. Opening internal and external connections simultaneously might present a security issue because applications can collect data from inside the firewall and send it outside the firewall without any auditing. We recommend the following settings:
Figure 6: MANAGING NETWORK ACCESS AND CONNECTIVITY - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
Messaging and Collaboration Functionality ALLOW PEER-TO-PEER MESSAGES This rule specifies whether a user can send PIN messages. We recommend the following settings:
ALLOW PUBLIC AIM SERVICES This rule specifies whether a user can use AOL® Instant Messenger™ on a ‘Smart Device’. We recommend the following settings:
ALLOW PUBLIC ICQ SERVICES This rule specifies whether a user can send SMS text messages. We recommend the following settings:
DISABLE SMS MESSAGES WIRELESS SYNCHRONISATION This rule specifies whether wireless data synchronisation for SMS text messages is turned off. We recommend the following settings:
ALLOW PUBLIC GOOGLE TALK SERVICES This rule specifies whether a user can use Google Talk™ on a ‘Smart Device’. We recommend the following settings:
ALLOW PUBLIC IM SERVICES This rule specifies whether a user can use public instant messaging applications for ‘Smart Device’. We recommend the following settings:
DISABLE ‘SMART DEVICE’ MESSENGER This rule specifies whether ‘Smart Device’® Messenger is turned off. We recommend the following settings:
DISABLE MMS This rule specifies whether a ‘Smart Device’ user can send and receive MMS messages. We recommend the following settings:
FIGURE 7: MANAGING NETWORK ACCESS AND CONNECTIVITY - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
WEB ACCESS CONTROL ALLOW IBS BROWSER This rule specifies whether a separate icon appears on a ‘Smart Device’ if the appropriate service books are present for ‘Smart Device’ Internet Service Browsing. We recommend the following settings:
ENABLE WAP CONFIG. This rule specifies whether a separate icon appears on a ‘Smart Device’ if the appropriate service books are present for the WAP Browser. We recommend the following settings:
DISABLE JAVASCRIPT IN BROWSER This rule specifies whether the ‘Smart Device’® Browser can run JavaScript®. We recommend the following settings:
FIGURE 8: WEB ACCESS CONTROL - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
PERIPHERAL ENABLEMENT (E.G., CAMERAS, BLUETOOTH, SD CARD) DISABLE USB MASS STORAGE This rule specifies whether USB mass storage is turned on. If you change this rule to True, a ‘Smart Device’ cannot access an external file system that is connected to the USB port. We recommend the following settings:
REQUIRE PASSWORD FOR DISCOVERABLE MODE This rule specifies whether a user must type the ‘Smart Device’ password before a ‘Smart Device’ can be discovered by Bluetooth® enabled devices. We recommend the following settings:
REQUIRE PASSWORD FOR ENABLING BLUETOOTH SUPPORT This rule specifies whether a user must type the ‘Smart Device’ password to turn on Bluetooth® technology. We recommend the following settings:
DISABLE BLUETOOTH This rule specifies whether support for Bluetooth® technology on a ‘Smart Device’® is turned off. We recommend the following settings:
DISABLE PHOTO CAMERA This rule specifies whether the camera is available on a ‘Smart Device’® device. We recommend the following settings:
DISABLE VIDEO CAMERA This rule specifies whether the video camera feature on a ‘Smart Device’ is turned on. We recommend the following settings:
FIGURE 9: PERIPHERAL ENABLEMENT - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
MEDIA ACCESS EXTERNAL FILE SYSTEM ENCRYPTION LEVEL This rule specifies the level of encryption that a ‘Smart Device’ uses to encrypt files that it stores on an external file system, such as an external memory device. We recommend the following settings:
DISABLE EXTERNAL MEMORY This rule specifies whether to prevent a ‘Smart Device’ user from accessing the media card on a supported ‘Smart Device’ device. We recommend the following settings:
FIGURE 10: MEDIA ACCESS - CLASSIFICATION WHERE POLICIES MUST FIRST BE CHANGED FROM DEFAULT
POLICY GROUP SETTINGS SUMMARY Below we provide a summary chart that indicates how many policies are discussed within each of the policy groups, as well as the number of policies that are first changed from the default value in their respective color-coded area. FIGURE 11: TOTAL NUMBER OF POLICIES PER GROUPING AND CLASSIFICATION LEVEL WHERE THEY ARE FIRST CHANGED FROM THE DEFAULT VALUE
(report courtesy of J.Gold Associates via ComputerWorld.com) |
