Policies

There is a growing importance in having a mobile device policy in organizations.  Each organization needs to consider their own needs and tailor the policy to their organization.

This is a sample policy that works to encompass many of the elements that are crucial to a mobile device policy.  Feel free to take this policy and adopt it to your organization’s needs.  Many policies do not include justification statements in them but they are provided in this policy for your reference.  Seeing the justifications behind each policy element are important for understanding how crucial they are to the security of the organization.

Sample Policy


 

Purpose: This policy outlines the minimum security requirements for mobile devices that will be used for organizational purposes.

Overview: Mobile devices allow employees to work outside of the office and reflect a driving need to conduct business on varying schedules and accommodate changing work environments. The use of these devices can help drive the organization’s mission but also add risks that must be mitigated as much as possible while balancing usability.

Scope: This policy applies to all mobile devices that will be using any organization resource including but not limited to: files, email, instant messaging, Wi-Fi, or any other organizational resource. A mobile device may include but is not limited to: smart phones (Android, iPhone, BlackBerry, Windows Phone), tablets (iPad, Nexus, Kindle Fire), or others such as an iPod Touch.

  1. Passcodes: All devices must have a password of at least 7 characters and include at least one special character and one number. This password must not be used on any other device or system such an email account. This password must also not be shared with anyone for any reason.

    2. Justification: To ensure strong device security in the event of a lost or stolen device a long passcode should be used to protect the device. Many Android devices also require a passcode of this length and complexity to enable encryption which is also required in this policy.

  2. Data Erasure: The device must be setup to automatically erase all data in a number of different events:
    • The device is reported as lost or stolen
    • A password has been entered incorrectly more than 10 times in a row
    • Before sending device into repair
    • Before recycling device or another user receives the device

    Justification: To ensure the confidentiality of the data contained on the device it must be erased if there is a chance the device might have been compromised. When a device is lost or stolen it could be vulnerable to an attacker. Entering a password incorrectly more than 10 times could be a sign that the device is being attacked and it should be erased automatically as a security measure. Before the phone leaves the assigned parties control it must be erased whether that be for repair, recycling, or another party is going to use the device.

  3. Encryption: The device must have a minimum of 128 AES encryption enabled at all times on the device. 256 AES encryption should be used whenever possible to offer better data protection. This includes data that is stored on the device, on memory cards in the device, or organizational data that is being transmitted.

    4. Justification: Data stored in an encrypted form is very difficult for a malicious party to decode and in the event the device is compromised the data is less likely to be exposed. The higher the level of encryption the harder it would be for an attacker to gain access to the data. When combined with a policy that wipes the device after 10 invalid password attempts it should make the data very secure in the event the device is lost or stolen.

  4. Screen Locking: The device must time out and lock the screen after no longer than 10 minutes of inactivity.

    5. Justification: A device that has not been used in ten minutes or more could have been left unattended or out of sight of the user which could leave it vulnerable to attack by a malicious person. Requiring the user to reenter their device passcode after that length of inactivity helps balance usability and security.

  5. Mobile Applications: Applications may not be downloaded and/or installed from application stores other than the official store for the operating system. For example iPhones, iPads, and iPods may only install applications from the official Apple App Store and Android devices may only download applications from the Google Play Store. Extreme caution should be taken when downloading any application to a mobile device, any questions about downloading an application to a device should be directed to the IT department for clarification.

    6. Justification: There has been a significant rise in the number of malicious applications targeted at mobile devices. The official application stores have a stronger screening process than unofficial application stores or application websites.

  6. Modified Devices: Devices must not be rooted, jail broken, or otherwise modified in a way to circumvent the operating system’s security measures.

    7. Justification: Rooting or jail breaking a device can allow the user greater access to device’s features but can also introduce new security risks onto a device. This could allow a malicious application to bypass built in security mechanisms in the device such as sandboxing which means confidential data could be leaked.

  7. Wi-Fi: The device should not be set to automatically connect to open networks. Extreme caution should be used when utilizing public Wi-Fi connections such as airports and coffee shops, unencrypted organizational business shall not take place over these networks.

    8. Justification: Due to the increasing cost of mobile data and the fact that some devices do not come with cellular radios installed it would not be very feasible to restrict the device to only using cellular or private Wi-Fi connections. It should be noted that public Wi-Fi is often unencrypted and can be vulnerable to attack by a malicious party.

  8. Bluetooth: The device shall not use Bluetooth for purposes other than hands free communication through a headset or car audio system. Other uses such as phone book profiles and networking must not be used.

    9. Justification: Bluetooth allows devices to synchronize together for a number of purposes but there are risks associated with certain uses that could lead to data being leaked from the device such as the phone book or other files that are stored on the mobile device like pictures or documents.

  9. Camera Use: The device shall not be used to take photographs of confidential organization information.

    10. Justification: Most mobile devices are based around easily sharing information which could lead to a confidential photo being accidentally shared with an unintended party or application.

  10. Device Registration: The device must be registered with the IT department and enrolled in the MDM (mobile device management system) before accessing organizational resources.

    11. Justification: Before allowing the device to have access to organizational resources it is important for the IT department to assess the device, register it in the mobile device management system, and to ensure that after registration it meets all compliance standards.

  11. Software Updates: The device must have the latest software updates from the manufacturer installed within thirty days of the software being released. This includes any major OS upgrades or minor patches.

    12. Justification: This is to help ensure that major security vulnerabilities are fixed within a reasonable amount of time. The thirty days allows for the updates to be pushed OTA (over the air) to the device or for the device to be manually upgraded if the update cannot be performed OTA.

  12. Minimum Mobile OS: The minimum operating system supported for iOS (Apple) devices is 5.1.1 and the minimum Android operating system is 4.0 (Ice Cream Sandwich).

    13. Justification: The minimum support for the mobile versions ensures the devices support the encryption that is required by this policy. Encryption was not supported by Android devices before 3.0 but many mobile device policies are not available on any OS lower than 4.0. On iOS devices version 5.1.1 ensures that all devices support hardware based encryption.

  13. Lost/Stolen Devices: Devices that are perceived to be stolen must be reported immediately to the IT department. Devices that were lost or otherwise out of the control of the assigned party must be reported within 8 hours to the IT department.

    14. Justification: If the device was thought to be stolen then the device should have a remote wipe carried out on it immediately to help protect the data on the device. If the device was perceived to just have been lost then giving the user of the device a small amount of time to search for it would be deemed an acceptable risk and depending on the MDM it might be possible to attempt to remotely locate the device. If a lost device is not found in a reasonable amount of time it should be remotely wiped to help maintain the confidentiality of the data.

     

     

    Portions of this policy were adopted from:

    DAS-Information Security Office. “State of Iowa Enterprise Mobile Device Security Standard.” State of Iowa Enterprise IT Security Standards. State of Iowa, 1 Nov. 2011. Web. 12 Feb. 2013. http://das.ite.iowa.gov/standards/documents/20111103_Mobile_Device.pdf.

    Defense Information Systems Agency (DISA). “APPLE IOS 6 TECHNOLOGY OVERVIEW.” Network / Perimeter / Wireless – Wireless (Smartphone/Tablet). Defense Information Systems Agency, 4 Jan. 2013. Web. 10 Feb. 2013. http://iase.disa.mil/stigs/net_perimeter/wireless/u_apple_iOS_6_v1r1_iscg.zip.