Advertisements

Home » ISMS: Mobile devices Policy

ISMS: Mobile devices Policy

A mobile device (or handheld computer) is a computing device small enough to hold and operate in the hand. Typically, the device has a either flatscreen display with a small numeric keypad or alphanumeric keyboard, or a touchscreen providing a virtual keyboard and buttons (icons) on-screen. Many such devices can connect to the Internet and interconnect with other devices such as car entertainment systems or headsets via Wi-Fi, Bluetooth or near field communication (NFC). Integrated cameras, digital media players, mobile phone and Global Positioning System (GPS) capabilities are common. Power is typically provided by a lithium battery. Mobile devices may run mobile operating systems that allow third-party apps specialized for said capabilities to be installed and run. Strictly speaking, many so-called mobile devices are not mobile. It is the host that is mobile, i.e., a mobile human host carries a non-mobile smart phone device. Device mobility can be viewed in the context of several dimensions:

  • Physical dimensions and weight
  • Whether or not the device is mobile or some kind of host to which it is attached to is mobile
  • What kind of host devices can be bound to
  • How devices are attached to a host
  • When the mobility occurs

Teleworking (i.e., telecommuting), e-commerce, use of intranets, online education, and the increase use of portable computing devices (e.g., laptops, tablets, smartphones) are driving the need for access to information resources from any place at any time. Today’s mobile workforce or users are no longer just trying to check e-mail from home but part and full-time telecommuters, business partners, Employees and vendors who rely on access to organizations networks to accomplish day-to-day business functions. Information security controls specifically targeting mobile computing and remote access to information resources are becoming an increasingly critical component of any information security program ensuring the protection of the integrity of the organizational networks while allowing remote access to it. To enable remote access to institutional information resources, many organizations are implementing Virtual Private Networks (VPN) technology to provide a secure connection to the institutional network. VPNs send data securely through a shared network. VPNs can be established between remote users and a network or between two or more networks thus using the Internet as the medium for transmitting information securely over and between networks via a process called tunneling.
Mobile devices have been designed for many applications. They include:

  • Mobile computers
    • Mobile Internet devices
    • Tablet computers
    • Laptops
    • Wearable computers
      • Calculator watches
      • Smartwatches
      • Head-mounted displays
    • Personal digital assistants
    • Enterprise digital assistants
    • Calculators
    • Handheld game consoles
    • Portable media players
    • Ultra-mobile PCs
    • Digital media player
  • Digital still cameras (DSC)
  • Digital video cameras (DVC) or digital camcorders
  • Mobile phones
    • Smartphone
    • feature phones
  • Pagers
  • Personal navigation devices (PND)
  • Smart cards
  • Project Ara

The following definitions have been added  so as to be precise about the terms.

  1. Handheld device: A communication device small enough to be carried in the hand or pocket and variously known as a personal digital assistant or personal communication device. Handheld devices considered in this document provide a broad range of services beyond simple telephony, and are closer to mobile computers than legacy mobile phones. Examples of handheld devices: pocket PCs, smartphones, palmtops, the Blackberry.
  2. Pocket PCs: Handheld devices having a touchscreen and a stylus, in addition to smartphone functionality. For Windows Mobile Pocket PCs, two distinct versions exist that present functions in addition to Windows Mobile Standard:
    Pocket PC: Windows Mobile Classic
    Pocket PC Phone Edition: Windows Mobile Professional
  3. Smartphones: The principal difference with pocket PCs is that smartphones do not have a touchscreen. Sometimes this results in a slightly different implementation at the OS level. However, the word “smartphone” recently has become a universal term to designate all types of handheld devices (including both pocket PCs and smartphones). In this document, “smartphone” is synonymous with handheld devices.

A. 6.2.1 Mobile device policy

Control

A policy and supporting security measures should be adopted to manage the risks introduced by using mobile devices.

Implementation guidance

When using mobile devices, special care should be taken to ensure that business information is not compromised. The mobile device policy should take into account the risks of working with mobile devices in unprotected environments.
The mobile device policy should consider:

  1. registration of mobile devices;
  2. requirements for physical protection;
  3. restriction of software installation;
  4. requirements for mobile device software versions and for applying patches;
  5. restriction of connection to information services;
  6. access controls;
  7. cryptographic techniques;
  8. malware protection;
  9. remote disabling, erasure or lockout;
  10. backups;
  11. usage of web services and web apps.

Care should be taken when using mobile devices in public places, meeting rooms and other unprotected areas. Protection should be in place to avoid the unauthorized access to or disclosure of the information stored and processed by these devices, e.g. using cryptographic techniques and enforcing use of secret authentication information. Mobile devices should also be physically protected against theft especially when left, for example, in cars and other forms of transport, hotel rooms, conference centres and meeting places. A specific procedure taking into account legal, insurance and other security requirements of the organization should be established for cases of theft or loss of mobile devices. Devices carrying important, sensitive or critical business information should not be left unattended and, where possible, should be physically locked away. or special locks should be used to secure the devices. Training should be arranged for personnel using mobile devices to raise their awareness of the additional risks resulting from this way of working and the controls that should be implemented. Where the mobile device policy allows the use of privately owned mobile devices, the policy and related security measures should also consider:

  1. separation of private and business use of the devices, including using software to support such separation and protect business data on a private device;
  2. providing access to business information only after users have signed an end user agreement acknowledging their duties (physical protection. software updating. etc.), waiving ownership of business data, allowing remote wiping of data by the organization in case of theft or loss of the device or when no longer authorized to use the service.This policy needs to take account of privacy legislation.

Other Information

Mobile device wireless connections are similar to other types of network connection. but have important differences that should be considered when identifying controls. Typical differences are:

  1. some wireless security protocols are immature and have known weaknesses;
  2. information stored on mobile devices may not be backed~up because of limited network bandwidth or because mobile devices may not be connected at the times when backups are scheduled.

Mobile devices generally share common functions, e.g. networking, internet access, e-mail and file handling. with fixed use devices. information security controls for the mobile devices generally consist of those adopted in the fixed use devices and those to address threats raised by their usage outside the organization’s premises.

Establishing Mobile Device:

The organisation must be able to demonstrate a policy and supporting security controls to reduce the risk posed by mobile or remote devices. As a result of this, it is the organisations responsibility to issue a mobile device policy that should cover the registration/de-registration of mobile devices, physical security requirements, technical security requirements including remote connections, software control, access control and encryption at rest/in-transit. The mobile device policy should  state the businesses requirements for use of mobile devices and when they are appropriate. It is in this policy that the company should specify their expectations for topics such as bring your own device (BYOD). BYOD is a hot topic for information security, with many practitioners agreeing that the risks posed by unmanaged, personally owned devices is too great. However, ISO 27001 does not specify whether BYOD is or is not permitted – it simply requires that the organisation determines this, issues a policy stating their intentions and monitors compliance with this policy through audit or technical controls. For example, a mobile device policy may state that “only corporately issued and managed devices can be used to process company data” and that “unauthorized devices must not be used to access, store or process company data”. If this is the policy, the organisation must monitor for the use of unauthorized devices and specify what the consequences of not adhering to the policy may be e.g. disciplinary procedures. As well as BYOD, the mobile device policy should address technical subjects such as access control, secure configuration and remote access methods. For example, the organisation may require its employees to utilize secure authentication methods such as two-factor authentication and only connect over encrypted channels such as VPN’s. If these methods of connection are specified, as above, compliance with the policy should be enforced technically, monitored for compliance and reported on. In most cases, if the technical capability is not there to support the policy users will not adhere with it so making device builds include VPN clients and reminding users of the need for secure authentication goes a long way.  Other considerations should include physical security of devices in public areas, shoulder surfing and other physical security issues. Employees should be aware of the need to protect their device from unauthorized access at all times, especially when in public places such as on trains and coffee shops. The policy should include a section addressing these requirements. Once the policy has been issued, signed-off by management and communicated to all employees the organisation should continue to monitor compliance through auditing and technical controls. For example, mobile device management (MDM) tools may be used to enforce policy and monitor for policy violations. Furthermore, logs may be reviewed periodically to identify unauthorized access attempts.

The steps involved in establishing Mobile Device Policy

Step 1: Define your scope.

  • Establishing rules people must follow (i.e., policies, standards, procedures) or non-binding recommendations (i.e., guidelines)? Some of both?
  • Do you have a clear definition of what a “mobile Internet device” is for your organization?
    • Your organization must define “mobile Internet devices” as any portable technology running an operating system optimized or designed for mobile computing, such as Android, Blackberry OS (RIM), Apple’s iOS, Windows Mobile, and Symbian. To avoid confusion, your definition should exclude technology running traditional/ classic or more general-purpose operating systems such as any of the Microsoft Windows desktop or server operating systems, versions of MacOS, or Linux.
    • Strive to understand what mobile Internet devices your users actually have and use (including personally owned devices). There may be more of them out there than your expect!
  • Does ownership (i.e., personally owned vs. organization owned) of the device matter?
  •  Requirements for the protection of physical assets?
    • Fake or Stolen Hardware: Organizations and users should also be alert that they may encounter fake or stolen mobile Internet devices. These devices may not work at all, or may break, or may stop working at the next operating system upgrade. Only purchase mobile Internet devices from reputable authorized dealers.
    • It’s A Hard World Out There: Mobile Internet devices live in the real world, and are subject to a panoply of environmental threats ranging from being dropped to getting wet, or getting cooked in hot cars or frozen in cold ones. You may want to encourage users to keep their device on their person, and to consider purchasing and using a case or holster to minimize at least some of those threats.
  • Requirements for the protection of digital data?
    • What Mobile Internet Devices Should You Support?
      It is hard to support “everything” well, and your users may end up more-or-less randomly selecting a mobile Internet device based on word-of-mouth or aggressive salesmanship. Should you be making some specific recommendations? In fact, should you have a standardized list of supported mobile Internet devices?
      Does the cellular connectivity matter from a security point of view? Do you want to standardize on GSM? CDMA? How about iDEN? Do you have opinions about 3G and 4G protocols?
      If you want influence over mobile device selection, are you willing to pay to obtain that influence (e.g., by subsidizing some mobile Internet device choices), or do you just want to try influencing those decisions via policy?
    • What About Enterprise Device Management?
      Some Organizations require all personal computers to be centrally managed. If you’re from one of those sites, will you be comfortable if mobile Internet devices aren’t also centrally managed? Central management of institutionally owned mobile Internet devices may allow you to do things such as: setting minimum device password length, complexity, maximum time between changes, max failures before wiping, etc. adding or removing root certificates configuring institutional WiFi and VPN controlling installation of third party applications, recreational uses, etc.
      If you’re planning to centrally manage mobile Internet devices, you may want to review device enterprise management feature support options as part of deciding what mobile Internet devices you want to endorse and support. Specifically, what options are available for securely and scalably pushing policy to your users’ mobile Internet devices?Also consider that it may be desirable to use different policies for vendors and Guest than for employees. Network access control policies on your residence hall networks as compared to faculty and staff networks may be a good illustrative example of how some institutions treat these populations differently.
      If your intention is to enforce policy on any mobile Internet device connecting to your infrastructure (however you define that), be aware that this will almost certainly include personally owned devices. Decide in advance how you will address inevitable questions, challenges and concerns regarding this decision. Unless your organization is requiring use of personally owned devices to perform official duties, there is likely no obligation for anyone to do so. In other words, it may be entirely at the discretion of the device owner to connect to your organization’s infrastructure. If an individual does not agree with or accept your organization’s terms for doing so they can choose not to use their mobile Internet device to interact with your institution. This may be similar to how many organizations explicitly prohibit the use of personal computers in designated areas, for specific roles or when accessing specific systems or data. In short, you may wish to think of mobile Internet devices connected to your organization’s network in the same way as laptops. That is, if you have specific requirements (e.g., network access control enforcement; no unauthorized Internet connection sharing; etc.) for laptops connecting to your wireless (or wired) network, you will very likely want those same requirements enforced on mobile Internet devices for the same (or similar) reasons. Similarly, you may wish to think about mobile Internet devices not connected to your organization’s wired or wireless networks as any other non-trusted computer on the Internet, even though these devices may be physically present on your campus.
    • What About Mobile Device App Choices, Web Site Readiness and New Features?
      Mobile Internet devices have a far more constrained application development environment than traditional desktops and laptops. Thus, for example, while you may have standardized on one web browser for use on desktops and laptops, such as Firefox, perhaps, you may be surprised to find that choice may not even be available on some mobile Internet devices. Is this a problem for you or your applications
      You should also take time to look at how critical  online resources look on a mobile Internet device. A home page that’s optimized for a large screen and a high-speed connection may not work well on a mobile device with more modest capabilities. For example, try viewing your organizational web sites via simulators such as http://www.testiphone.com/ — are your web pages still usable? Should you create a mobile version of your home page? (If www.example.com is your normal home page, you might create a simplified home page at m.example.com for mobile users). Recognize, too, that mobile devices bring some new capabilities, such as QR (“quick response”) codes, the square dot-like codes that are readable by camera-equipped mobile Internet devices. They’re cool, aren’t they? But how do you know what a code points to? Should you be using them yourself to increase ease of use for your mobile Internet device users? Or do they represent a security threat that should be discouraged? You should begin having these conversations at your site.
    • How about Spam and Malware Management On Mobile Internet Devices
      Recognize that spammers will still target users even if they’re on mobile Internet devices. What spam management options do users have for a given service? How can they report spam that slips through? Malware may still target users of mobile devices, but due to the device architecture, traditional antivirus software may not be needed (or may not even be available!) Your security team and/or operational support staff should talk about how they want to approach issues such as spam and malware on supported mobile Internet devices.
    • How About Hardware and Data Encryption?
      Personally identifiable information (“PII”) is a material concern at many sites. Do the mobile devices you’ve chosen to support have hardware encryption? Is that encryption solid enough to meet your PII protection requirements? Similarly, some mobile Internet devices may forgo the use of on-device storage and store all data “in the cloud.” You likely already have requirements in place to protect sensitive or important institutional data. Make sure devices that store institutional data in the cloud meet applicable security and privacy requirements for doing so.
    • And Remote Wipe Capabilities?
      If you lose control over an Organizational owned mobile Internet device, do you need the ability to remotely send the device a magic “kill code?” (Note that even if you can remotely wipe the device, there may still be off-site backups floating around, or the device may get taken offline before the kill code can be sent and processed by the device, so don’t depend too much on being able to send remote kill codes)
    • Jailbreaking Apple iPhones, Rooting Android Devices
      Normally only Apple-approved applications run on the iPhone. However, some users have developed hacks (NOT blessed by Apple!) that will allow users to “break out of that jail” and run whatever applications they want. Jailbreaking your iPhone violates the license agreement and voids its warranty, but it is estimated that 5-10% of all iPhone users have nonetheless done so.
      Because jailbreaking is operating system version specific, many users of jailbroken iPhones hesitate to upgrade their iPhones even when important patches are released, because upgrading will reverse the jailbroken status of their phone. Users who want to jailbreak their iPhones may also be specifically targeted by malicious applications masquerading as jailbreaking tools. For that matter, any sort of application for a jailbroken iPhone obtained from a third party source may not have been subject to any security review or auditing, unlike applications from Apple’s official AppStore, and may include malicious routines.
      “Rooting” can be understood as the Android equivalent of jailbreaking. As described above, rooting Android based devices can introduce new or unexpected security and/or privacy risks to data stored on the device. For all these reasons, your site may want to discourage or forbid jailbreaking or rooting of institutionally supported mobile devices.
    • Institutional Contact With Users’ Mobile Devices
      Many Organizations ask  their employees, vendors and customers to register their mobile numbers with the school for purposes such as emergency notification. Be careful not to abuse the numbers entrusted to you solely for emergency purposes for unrelated activities, such as routine announcements or push marketing purposes.
      Expectations should also be set for work-related contacts over mobile devices. That is, unless an employee is officially on call (and paid for that status), or it’s a real emergency, avoid calling employees outside of work hours. Let employees have some time off to spend with their families and their friends, or to just sleep and recuperate! Please don’t treat employees as if they’re on unpaid call status 24×7, or you may find a sudden increase in “cellular connectivity issues” spontaneously arising, potentially at some very inopportune times.
  •  Requirements for the protection of personal privacy?
    Mobile Internet devices can potentially have profound privacy implications. By way of example, almost all mobile Internet devices have the ability to have their physical location tracked by a variety of means, a wonderful invention if you’re having a heart attack and have just called 911 for an ambulance, but potentially a huge invasion of your privacy if this service gets abused by a stalker, or by an intrusive marketer.
    Mobile Internet devices also emit cellular radiation. While those emissions are limited by law, and are believed to be at safe levels, some phones emit less radiation than others, and use of hands-free devices may also reduce (or shift) the amount of radiation you receive. If this issue is important to you, we encourage you to make appropriate choices.
    Users of mobile Internet devices needs to be careful when it comes to where and when they use their devices. In particular, please  NOT use your mobile Internet device while you’re driving. Driving while distracted can be as bad as driving while under the influence of alcohol, and you don’t want to see cool mobile Internet devices result in totally avoidable tragic accidents. Many organizations may want to explicitly forbid use of mobile Internet devices while driving.
  • Defining acceptable use in general? You will likely want to treat employee devices differently from vendors devices. What about guests?
  • Does existing physical asset, technology or data-specific policy cover all or part of your defined scope?
    If not, consider revising existing policy. Doing so may be easier or more desirable than crafting new policy. If at all possible, implement a technology-agnostic policy framework that allows you to create more specific standards, procedures or guidelines without having to modify policy.
  • Communicate what you are trying to accomplish and a high-level implementation plan with your constituents.
    Help your executives understand residual risks associated with your chosen approach and why/how mobile Internet devices may be different from more familiar computing technologies.

Step 2: Defining Mobile Device Characteristics

Mobile device features are constantly changing, so it is difficult to define the term “mobile device”. However, as features change, so do threats and security controls, so it is important to establish a baseline of mobile device features. The following hardware and software characteristics collectively can be define as the baseline

  • A small form factor
  • At least one wireless network interface for network access (data communications). This interface uses Wi-Fi, cellular networking, or other technologies that connect the mobile device to network infrastructures with connectivity to the Internet or other data networks.
  • Local built-in (non-removable) data storage
  • An operating system that is not a full-fledged desktop or laptop operating system
  • Applications available through multiple methods (provided with the mobile device, accessed through web browser, acquired and installed from third parties)
    The list below details other common, but optional, characteristics of mobile devices. These features do not define the scope of devices included in the publication, but rather indicate features that are particularly important in terms of security risk. This list is not intended to be exhaustive, and is merely illustrative of common features of interest as of this writing.
  • Network services:
    • One or more wireless personal area network interfaces, such as Bluetooth or near-field communications
    • One or more wireless network interfaces for voice communications, such as cellular
    • Global Positioning System (GPS), which enables location services
  • One or more digital cameras/video recording devices
  • Microphone
  • Storage:
    • o Support for removable media
    • Support for using the device itself as removable storage for another computing device
  • Built-in features for synchronizing local data with a different location (desktop or laptop computer, organization servers, telecommunications provider servers, other third party servers, etc.)

High-Level Threats and Vulnerabilities

Mobile devices typically need to support multiple security objectives. These can be accomplished through a combination of security features built into the mobile devices and additional security controls applied to the mobile devices and other components of the enterprise IT infrastructure. The most common security objectives for mobile devices are as follows:

  • Confidentiality—ensure that transmitted and stored data cannot be read by unauthorized parties
  • Integrity—detect any intentional or unintentional changes to transmitted and stored data
  • Availability—ensure that users can access resources using mobile devices whenever needed.

To achieve these objectives, mobile devices should be secured against a variety of threats. Mobile devices often need additional protection because their nature generally places them at higher exposure to threats than other client devices (e.g., desktop and laptop devices only used within the organization’s facilities and on the organization’s networks). Before designing and deploying mobile device solutions, organizations should develop system threat models for the mobile devices and the resources that are accessed through the mobile devices. Threat modeling involves identifying resources of interest and the feasible threats, vulnerabilities, and security controls related to these resources, then quantifying the likelihood of successful attacks and their impacts, and finally analyzing this information to determine where security controls need to be improved or added. Threat modeling helps organizations to identify security requirements and to design the mobile device solution to incorporate the controls needed to meet the security requirements. Major security concerns for these technologies that would be included in most mobile device threat models are listed below.

  1. Lack of Physical Security Controls
    Mobile devices are typically used in a variety of locations outside the organization’s control, such as employees’ homes, coffee shops, hotels, and conferences. Even mobile devices only used within an organization’s facilities are often transported from place to place within the facilities. The devices’ mobile nature makes them much more likely to be lost or stolen than other devices, so their data is at increased risk of compromise. When planning mobile device security policies and controls, organizations should assume that mobile devices will be acquired by malicious parties who will attempt to recover sensitive data either directly from the devices themselves or indirectly by using the devices to access the organization’s remote resources. The mitigation strategy for this is layered. One layer involves requiring authentication before gaining access to the mobile device or the organization’s resources accessible through the device. A mobile device usually has a single authenticator—not a separate account for each user of the device—as it is generally assumed that the device only has one user.3 So there is no username, just a password, which is often a PIN. More robust forms of authentication, such as token-based authentication, network-based device authentication, and domain authentication, can be used instead of or in addition to the built-in device authentication capabilities. A second mitigation layer involves protecting sensitive data—either encrypting the mobile device’s storage so that sensitive data cannot be recovered from it by unauthorized parties, or not storing sensitive data on mobile devices. Even if a mobile device is always in the possession of its owner, there are other physical security risks, such as an attacker looking over a teleworker’s shoulder at a coffee shop and viewing sensitive data on the mobile device’s screen (for example, a password being entered). Finally, another layer of mitigation involves user training and awareness, to reduce the frequency of insecure physical security practices.
  2. Use of Untrusted Mobile Devices
    Many mobile devices, particularly those that are personally owned (bring your own device, BYOD), are not necessarily trustworthy. Most current mobile devices lack the root of trust features (e.g., trusted platform modules, TPMs) that are increasingly built into laptops and other types of hosts. There is also frequent jailbreaking and rooting of mobile devices, which means that the built-in restrictions on security, operating system use, etc. have been bypassed. Organizations should assume that all mobile devices are untrusted unless the organization has properly secured them and monitors their security continuously while in use with enterprise applications or data. There are several possible mitigation strategies related to use of untrusted mobile devices. One option is to restrict or prohibit use of BYOD devices, thus favoring organization-issued devices. Another effective technique is to fully secure each organization-issued mobile device; this gets the mobile device in as trusted a state as possible, and deviations from this secure state can be monitored and addressed. There are also technical solutions for achieving degrees of trust in BYOD devices, such as running the organization’s software in a secure, isolated sandbox/secure container on the mobile device, or using device integrity scanning applications.
  3. Use of Untrusted Networks
    Because mobile devices primarily use non-organizational networks for Internet access, organizations normally have no control over the security of the external networks the devices use. Communications systems may include wireless mechanisms such as Wi-Fi and cellular networks. These communications systems are susceptible to eavesdropping, which places sensitive information transmitted at risk of compromise. Man-in-the-middle attacks may also be performed to intercept and modify communications. Unless it is absolutely certain that the mobile device will only be used on trusted networks controlled by the organization, organizations should plan their mobile device security on the assumption that the networks between the mobile device and the organization cannot be trusted.Risk from use of untrusted networks can be reduced by using strong encryption technologies (such as virtual private networks, VPNs) to protect the confidentiality and integrity of communications, as well as using mutual authentication mechanisms to verify the identities of both endpoints before transmitting data. Another possible mitigation is to prohibit use of insecure Wi-Fi networks, such as those running known vulnerable protocols. Also, all network interfaces not needed by the device can be disabled, thus reducing the attack surface.
  4. Use of Untrusted Applications
    Mobile devices are designed to make it easy to find, acquire, install, and use third-party applications from mobile device application stores. This poses obvious security risks, especially for mobile device platforms and application stores that do not place security restrictions or other limitations on third-party application publishing. Organizations should plan their mobile device security on the assumption that unknown third-party mobile device applications downloadable by users should not be trusted. Risk from these applications can be reduced in several ways, such as prohibiting all installation of third-party applications, implementing whitelisting to allow installation of approved applications only, verifying that applications only receive the necessary permissions on the mobile device, or implementing a secure sandbox/secure container that isolates the organization’s data and applications from all other data and applications on the mobile device. Another possible mitigation is to perform a risk assessment on each third-party application before permitting its use on the organization’s mobile devices. It is important to note that even if these mitigation strategies are implemented for third-party applications, users can still access untrusted web-based applications through browsers built into their mobile devices. The risks inherent in this can be reduced by prohibiting or restricting browser access; by forcing mobile device traffic through secure web gateways, HTTP proxy servers, or other intermediate devices to assess URLs before allowing them to be contacted; or by using a separate browser within a secure sandbox/secure container for all browser-based access related to the organization, leaving the mobile device’s built-in browser for other uses.
  5. Interaction with Other Systems
    Mobile devices may interact with other systems in terms of data exchange (including synchronization) and storage. Local system interaction generally involves connecting a mobile device to a desktop or laptop wirelessly or via a cable for syncing. It can also involve tethering, such as using one mobile device to provide network access for another mobile device. Remote system interaction most often involves automatic backups of data to a cloud-based storage solution. When all of these components are under the organization’s control, risk is generally acceptable, but often one or more of these components are external. Examples include connecting a personally-owned mobile device to an organization-issued laptop, connecting an organization-issued mobile device to a personally-owned laptop, connecting an organization-issued mobile device to a remote backup service, and connecting any mobile device to an untrusted charging station. In all of these scenarios, the organization’s data is at risk of being stored in an unsecured location outside the organization’s control; transmission of malware from device to device is also a possibility. There are also concerns regarding mobile devices exchanging data with each other. The mitigation strategies depend on the type of attachment. Preventing an organization-issued mobile device from syncing with a personally-owned computer necessitates security controls on the mobile device that restrict what devices it can synchronize with. Preventing a personally-owned mobile device from syncing with an organization-issued computer necessitates security controls on the organization-issued computer, restricting the connection of mobile devices. Preventing the use of remote backup services can possibly be achieved by blocking use of those services (e.g., not allowing the domain services to be contacted) or by configuring the mobile devices not to use such services. Users should be instructed not to connect their mobile devices to unknown charging devices; they should carry and use their own charging devices. Finally, mobile devices can be prevented from exchanging data with each other through logical or physical means (blocking use of services through configuration or physical shielding, etc.)
  6. Use of Untrusted Content
    Mobile devices may use untrusted content that other types of devices generally do not encounter. An example is Quick Response (QR) codes. They are specifically designed to be viewed and processed by mobile device cameras. Each QR code is translated to text, typically a URL, so malicious QR codes could direct mobile devices to malicious websites. This could allow for targeted attacking, such as placing malicious QR codes at a location where targeted users gather.
    A primary mitigation strategy is to educate users on the risks inherent in untrusted content and to discourage users from accessing untrusted content with any mobile devices they use for work. Another mitigation is to have applications, such as QR readers, display the unobfuscated content (e.g., the URL) and allow users to accept or reject it before proceeding. Depending on the network configuration, it may also be possible to use secure web gateways, HTTP proxy servers, or other intermediate devices to validate URLs before allowing them to be contacted. In high security situations, it is also possible to restrict peripheral use on mobile devices, such as disabling camera use in order to prevent QR codes from being processed.
  7. Use of Location Services
    Mobile devices with GPS capabilities typically run what are known as location services. These services map a GPS-acquired location to the corresponding businesses or other entities close to that location. Location services are heavily used by social media, navigation, web browsers, and other mobile-centric applications. In terms of organization security and personal privacy, mobile devices with location services enabled are at increased risk of targeted attacks because it is easier for potential attackers to determine where the user and the mobile device are, and to correlate that information with other sources about who the user associates with and the kinds of activities they perform in particular locations. This situation can be mitigated by disabling location services or by prohibiting use of location services for particular applications such as social networking or photo applications. Users may also be trained to turn off location services when in sensitive areas. However, a similar problem can occur even if GPS capabilities or location services are disabled. It is increasingly common for websites and applications to determine a person’s location based on their Internet connection, such as a Wi-Fi hotspot or IP address range. The primary mitigation for this is to opt out of such location services whenever possible. Organizations should be aware that keeping location services enabled can also have positive effects on information security. For example, different security policies can be enforced depending on whether the mobile device is being used within the organization’s facilities or outside the organization’s facilities.

Step 3: Establishing the required Technologies for Mobile Device Management

Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and personally-owned mobile devices by enterprise users. In addition to managing the configuration and security of mobile devices, these technologies offer other features, such as providing secure access to enterprise computing resources. This section provides an overview of the current state of these technologies, focusing on the technologies’ components, architectures, and capabilities.

  1. Components and Architectures
    There are two basic approaches to centralized mobile device management: use a messaging server’s management capabilities (often from the same vendor that makes a particular brand of mobile device operating system), or use a product from a third party, which is designed to manage one or more brands of mobile device operating systems.It may be possible with the latter approach to have a single product that can manage multiple brands of mobile device operating systems desired for use within an enterprise. However, a product provided by a mobile device manufacturer may have more robust support for the mobile devices than third party products.Both approaches can provide the necessary centralized management functionality. Architecturally, both approaches to centralized mobile device management are quite similar. The typical solution has a straightforward client/server architecture. The enterprise contains one or more servers that provide the centralized management capabilities, and one or more client applications are installed on each mobile device and configured to run in the background at all times. If the device is organization issued, the client application typically manages the configuration and security of the entire device. If the device is BYOD, the client application typically manages only the configuration and security of itself and its data, not the entire device. The client application and data should be sandboxed from the rest of the device’s applications and data in a secure container, both helping to protect the enterprise from a compromised device and helping to preserve the privacy of the device’s owner. The centralized mobile device management may make use of other enterprise services, such as domain authentication services and VPN services. If there is not a centralized management solution, or certain mobile devices cannot use it, then mobile devices have to be managed individually and manually. In addition to the additional resources expended, there are two major security problems with this:

    • The security controls provided by a mobile device often lack the rigor of those provided by a centralized mobile device management client application. For example, a mobile device often supports only a short passcode for authentication and may not support strong storage encryption. This will necessitate acquiring, installing, configuring, and maintaining a variety of third-party security controls that provide the missing functionality.
    • It may not be possible to manage the security of the device when it is not physically present within the enterprise. It is possible to install utilities that manage devices remotely, but it will require significantly more effort to use such utilities to manually apply updates and perform other maintenance and management tasks with out-of-office mobile devices.

    To avoid these problems, organizations may choose to prohibit the use of any mobile devices that are not centrally managed.

  2. Capabilities
    Now let us describes security services commonly needed for security management of mobile devices. These services may be provided by the mobile device operating system, enterprise mobile device management (MDM) software, or other security controls. These services apply to the entire mobile device (if it is fully managed) or to the mobile device’s secure sandbox/secure container, unless explicitly noted otherwise. These services are equally relevant for centrally managed or individually managed mobile devices. Most organizations will not need all of the security services listed in this section. Organizations deploying mobile devices should consider the merits of each security service, determine which services are needed for their environment, and then design and acquire one or more solutions that collectively provide the necessary services.

    1. General policy. The centralized technology can enforce enterprise security policies on the mobile device. General policy restrictions of particular interest for mobile device security include the following:
      • Restrict user and application access to hardware, such as the digital camera, GPS, Bluetooth interface, USB interface, and removable storage.
      • Restrict user and application access to native OS services, such as the built-in web browser, email client, calendaring, contacts, application installation services, etc.
      • Manage wireless network interfaces (Wi-Fi, Bluetooth, etc.)
      • Automatically monitor, detect, and report when policy violations occur, such as changes from the approved security configuration baseline, and automatically take action when possible and appropriate
      •  Limit or prevent access to enterprise services based on the mobile device’s operating system version (including whether the device has been rooted/jailbroken), vendor/brand, model, or mobile device management software client version (if applicable). Note that this information may be spoofable.
    2.  Data Communication and Storage
      • Strongly encrypt data communications between the mobile device and the organization. This is most often in the form of a VPN, although it can be established through other uses of secure protocols and encryption.
      • Strongly encrypt stored data on both built-in storage and removable media storage. Removable media can also be “bound” to particular devices such that encrypted information can only be decrypted when the removable media is attached to the device, thereby mitigating the risk of offline attacks on the media.
      • Wipe the device (to scrub its stored data) before reissuing it to another user, retiring the device, etc.
      • Remotely wipe the device (to scrub its stored data) if it is suspected that the device has been lost, stolen, or otherwise fallen into untrusted hands and is at risk of having its data recovered by an untrusted party
      • A device often can also be configured to wipe itself after a certain number of incorrect authentication attempts.
    3.  User and Device Authentication
      • Require a device password/passcode and/or other authentication (e.g., token-based authentication, network-based device authentication, domain authentication) before accessing the organization’s resources. This includes basic parameters for password strength and a limit on the number of retries permitted without negative consequences (e.g., locking out the account, wiping the device).
      • If device account lockout is enabled or the device password/passcode is forgotten, an administrator can reset this remotely to restore access to the device.
      • Have the device automatically lock itself after it is idle for a period (e.g., 5 minutes).
      • Under the direction of an administrator, remotely lock the device if it is suspected that the device has been left in an unlocked state in an unsecured location.
    4. Applications
      • Restrict which app stores may be used.
      • Restrict which applications may be installed through whitelisting (preferable) or blacklisting.
      • Restrict the permissions (e.g., camera access, location access) assigned to each application.
      • Install, update, and remove applications. Safeguard the mechanisms used to perform these actions. Keep a current inventory of all applications installed on each device.
      •  Restrict the use of operating system and application synchronization services (e.g., local device synchronization, remote synchronization services and websites).
      • Verify digital signatures on applications to ensure that only applications from trusted entities are installed on the device and that code has not been modified.
      • Distribute the organization’s applications from a dedicated mobile application store.

Step 4: Security for the Enterprise Mobile Device Solution Life Cycle

Organizations may follow a project management methodology or life cycle model  in the model presented here. The phases of the life cycle are as follows:

Phase 1: Initiation.

This phase involves the tasks that an organization should perform before it starts to design a mobile device solution. These include identifying needs for mobile devices, providing an overall vision for how mobile device solutions would support the mission of the organization, creating a high-level strategy for implementing mobile device solutions, developing a mobile device security policy, and specifying business and functional requirements for the solution. The initiation phase involves many preparatory actions, such as identifying current and future needs, and specifying requirements for performance, functionality, and security. A critical part of the initiation phase is the development of a mobile device security policy for an organization. A mobile device security policy should define which types of the organization’s resources may be accessed via mobile devices, which types of mobile devices are permitted to access the organization’s resources, the degree of access that various classes of mobile devices may have (for example, organization-issued devices versus personally- owned devices), and how provisioning should be handled. It should also cover how the organization’s centralized mobile device management servers are administered, how policies in those servers are updated, and all other requirements for mobile device management technologies. The mobile device security policy should be documented in the system security plan. To the extent feasible and appropriate, the mobile device security policy should be consistent with and complement security policy for non-mobile systems.

  1. Restrictions on Mobile Devices and Access Levels
    An organization’s mobile device security policy often limits the types of mobile devices that may be used for enterprise access; this is done for a variety of reasons, including security concerns and technology limitations. For example, an organization might permit only organization-owned mobile devices to be used. Some organizations have tiered levels of access, such as allowing organization-issued mobile devices to access many resources, BYOD mobile devices running the organization’s mobile device management client software to access a limited set of resources, and all other BYOD mobile devices to access only a few web-based resources, such as email. This allows an organization to limit the risk it incurs by permitting the most-controlled devices to have the most access and the least-controlled devices to have only minimal access. Some organizations also maintain lists of approved mobile devices (by operating system version, by brand/model of phone, etc.) Each organization should make its own risk-based decisions about what levels of access should be permitted from which types of mobile devices. Factors that organizations should consider when setting mobile device security policy for this include the following:

    • Sensitivity of work. Some work involves access to sensitive information or resources, while other work does not. Organizations may have more restrictive requirements for work involving sensitive information, such as permitting only organization-issued devices to be used. Organizations should also be concerned about the issues involved in remotely scrubbing sensitive information from BYOD mobile devices
    • The level of confidence in security policy compliance. Meeting many of an organization’s security requirements can typically be ensured only if the organization controls the configuration of the mobile devices. For devices not running the organization’s mobile device management client software, some requirements can possibly be verified by automated security health checks conducted by the mobile device management server when mobile devices attempt to connect, but other requirements cannot be verified. Organizations may decide to require mobile devices to run the specified mobile device management software.
    • Cost. Costs associated with mobile devices will vary based on policy decisions. The primary direct cost from a security perspective is issuing mobile devices and client software. There are also indirect costs in maintaining the security of mobile devices and in providing security-related technical support for users.
    • Work location. Risks will generally be lower for devices used only in the enterprise environment than for devices used in a variety of locations.
    • Technical limitations. Certain types of mobile devices or operating systems may be needed, such as for running a particular application. Also, an organization’s mobile device management client software may only support certain types of mobile devices (e.g., particular operating system versions).
    • Compliance with mandates and other policies. Organizations may need to comply with mobile device-related requirements from mandates and other sources, such as a Federal department issuing policy requirements to its member agencies. An example of a possible requirement is restrictions on using mobile devices in foreign countries that have strong known threats against Federal agency systems; in such cases, it may be appropriate to issue “loaner” mobile devices or to prohibit mobile device use altogether.

    Organizations may choose to specify additional security requirements that are tied to factors such as the sensitivity of work. Many organizations require more stringent security controls for work situations that are particularly high-risk, such as permitting the work only from organization-issued and secured mobile devices, and requiring the use of multi-factor authentication for access to the mobile device and to enterprise resources. Another possible security control is to migrate high-risk resources to servers that assume responsibility for protecting them; for example, a mobile device could connect to a server that holds sensitive data that the user needs to access, instead of the sensitive data being stored locally on the mobile device. In high-risk situations, organizations may also choose to reduce risk by prohibiting mobile devices from accessing particular types of information, such as sensitive personally identifiable information (PII).
    There are frequent changes in mobile device capabilities, the security controls available to organizations, the types of threats made to different types of devices, and so on. Therefore, organizations should periodically reassess their policies for mobile devices and consider changing which types of mobile devices are permitted, what levels of access they may be granted, and which security controls are required. Organizations should also be aware of the emergence of new types of mobile device solutions and of major changes to existing mobile device management technologies, and ensure that the organization’s policies are updated accordingly as needed.

  2. Additional User Requirements
    Organizations often have additional security considerations for mobile devices that, while helpful in mitigating threats, cannot necessarily be directly enforced by the organization. Organizations should educate users on the importance of these additional security measures and define users’ responsibilities for implementing these measures in policy and mobile device agreements.
    One possible security consideration involves wireless personal area networks (WPAN), which are small-scale wireless networks that require no infrastructure to operate. Examples of WPAN technologies are using a wireless keyboard or mouse with a computer, printing wirelessly, synchronizing a mobile device with a computer wirelessly, and using a wireless headset or earpiece with a smart phone. Commonly used types of WPAN technologies include Bluetooth and near-field communications. For devices within proximity of significant threats, mobile device users should enable these technologies only when needed to prevent misuse by unauthorized parties.

Phase 2: Development.

In this phase, personnel specify the technical characteristics of the mobile device solution and related components. These include the authentication methods and the cryptographic mechanisms used to protect communications and stored data. The types of mobile devices (brands, operating systems, etc.) to be authorized for use should also be considered, since they can affect the desired policies. Care should be taken to ensure that the mobile device security policy can be employed and enforced by all authorized clients. At the end of this phase, solution components are procured. Once the organization has established a mobile device security policy, identified mobile device needs, and completed other preparatory activities, the next steps are to determine which types of mobile device management technologies should be used and to design a solution to deploy. There are many considerations for designing a solution, most of which are generally applicable to any IT technology. Major considerations include the following:

  • Architecture. Designing the architecture includes the selection of mobile device management server and client software, the placement of the mobile device management server and other centralized elements, and the architecture of any virtual private network (VPN) solutions.
  • Authentication. Authentication involves selecting device and/or user authentication methods, including determining procedures for issuing and resetting authenticators and for provisioning users and/or client devices with authenticators. Authentication includes access to or integration with existing enterprise authentication systems.
  • Cryptography. Decisions related to cryptography include selecting the algorithms for encryption and integrity protection of mobile device communications, and setting the key strength for algorithms that support multiple key lengths. Configuration requirements. This involves setting minimum security standards for mobile devices, such as mandatory host hardening measures and patch levels, and specifying additional security controls that must be employed on the mobile device, such as a VPN client.
  • Device provisioning. It is important to determine how both new and existing devices will be provisioned with client software, authenticators, configuration settings, etc.
  •  Application vetting and certification requirements. This sets security, performance, and other requirements that applications must meet and determines how proof of compliance with requirements must be demonstrated.

The security aspects of the mobile device solution design should be documented in the system security plan. The organization should also consider how incidents involving the mobile device solutions should be handled and document those plans as well.

Phase 3: Implementation.

In this phase, equipment is configured to meet operational and security requirements, including the mobile device security policy documented in the system security plan, installed and tested as a pilot, and then activated on a production network. Implementation includes integration with other security controls and technologies, such as security event logging and authentication servers. After the mobile device solution has been designed, the next step is to implement and test a pilot of the design, before putting the solution into production. Aspects of the solution that should be evaluated for each type of mobile device include the following:

  • Connectivity. Users can establish and maintain connections from the mobile device to the organization from the locations they are expected to use. Users can connect to all of the organization’s resources that they are permitted to and cannot connect to any other organization resources.
  • Protection. Information stored on the mobile device and communications between the mobile device and the organization are protected in accordance with the established requirements.
  • Authentication. Authentication is required and cannot be readily compromised or circumvented. All device, user, and domain authentication policies are enforced.
  • Applications. The applications to be supported by the mobile device solution function properly. All restrictions on installing applications are enforced. All restrictions on uninstalling applications (such as enterprise mobile device management software) are enforced.
  • Management. Administrators can configure and manage all components of the solution effectively and securely. The ease of deployment and configuration is particularly important. Another concern is the ability of users to alter device/client software settings, which could weaken mobile device security.
  • Logging. The mobile device solution logs security events in accordance with the organization’s policies. Note that the security logging capabilities of mobile devices vary widely.
  • Performance. All components of the solution provide adequate performance during normal and peak usage. It is important to also consider the performance of intermediate devices, such as routers and firewalls.
  • Security of the Implementation. The mobile device implementation itself may contain vulnerabilities and weaknesses that attackers could exploit. Organizations with high security needs may choose to perform extensive vulnerability assessments against the mobile device solution components. At a minimum, all components should be updated with the latest available patches and configured following sound security practices. The organization should also take basic measures to prevent the user from circumventing the device’s security features. Also, jailbroken or rooted mobile devices should be automatically detected to prohibit their use, for cases in which detection is feasible.
  • Default Settings. On a per-OS version basis, implementers should carefully review the default values for each mobile device setting and alter the settings as necessary to support security requirements. Implementers should also ensure that the mobile device solution does not unexpectedly “fall back” to insecure default settings for interoperability or other reasons.

Organizations should fully secure each organization-issued mobile device before allowing a user to access it. Any already-deployed mobile device with an unknown security profile (e.g., unmanaged device) should be fully secured to a known good state (for example, through deployment and use of enterprise mobile device management technologies). Supplemental security controls should be deployed as risk merits, such as antivirus software and data loss prevention (DLP) technologies.

Phase 4: Operations and Maintenance.

This phase includes security-related tasks that an organization should perform on an ongoing basis once the mobile device solution is operational, including patching, log reviews, and attack detection. Operational processes that are particularly helpful for maintaining mobile device security, and thus should be performed regularly, include the following:

  • Checking for upgrades and patches to the mobile device solution components (including mobile device infrastructure components, mobile device operating systems, and mobile device applications), and acquiring, testing, and deploying the updates
  • Ensuring that each mobile device infrastructure component (mobile device management servers, authentication servers, etc.) has its clock synced to a common time source so that its timestamps will match those generated by other systems
  • Re-configuring access control features as needed based on factors such as policy changes, technology changes, audit findings, and new security needs
  • Detecting and documenting anomalies within the mobile device infrastructure through continuous monitoring, including unauthorized configuration changes to mobile devices. Such anomalies might indicate malicious activity or deviations from policy and procedures. Anomalies should be reported to other systems’ administrators as appropriate.
  • Keeping an active inventory of each mobile device, its user(s), and its applications
  • Providing training and awareness activities for mobile device users on threats and recommended security practices
  • Revoking access to or deleting an application that has already been installed but has subsequently been assessed as too risky to use
  • Scrubbing sensitive data from mobile devices before reissuing them to other users

Organizations should also periodically perform assessments to confirm that the organization’s mobile device policies, processes, and procedures are being followed properly. Assessment activities may be passive, such as reviewing logs, or active, such as performing vulnerability scans and penetration testing.

Phase 5: Disposal.

This phase encompasses tasks that occur when a mobile device solution or its components are being retired, including preserving information to meet legal requirements, sanitizing media, and disposing of equipment properly.
Before a mobile device component permanently leaves an organization (such as when a leased server’s lease expires or when an obsolete mobile device is being recycled) or is reassigned to another user, the organization should remove any sensitive data from the mobile device. The task of scrubbing all sensitive data from storage devices such as hard drives and memory cards is often surprisingly difficult because of all the places where such data resides and the increasing reliance on flash memory instead of magnetic disks.

An example of Mobile Device Policy

  1.  Introduction                                                                                          Mobile devices, such as smartphones and tablet computers, are important tools for the organization and Company supports their use to achieve business goals. However, mobile devices also represent a significant risk to data security as, if the appropriate security applications and procedures are not applied, they can be a conduit for unauthorized access to the organization’s data and IT infrastructure. This can subsequently lead to data leakage and system infection.
    <Company X> has a requirement to protect its information assets in order to safeguard its customers, intellectual property and reputation. This document outlines a set of practices and requirements for the safe use of mobile devices and applications.
  2. Scope
    1. All mobile devices, whether owned by <Company X> or owned by employees, inclusive of smartphones and tablet computers, that have access to corporate networks, data and systems are governed by this mobile device security policy. The scope of this policy does not include corporate IT-managed laptops.
    2. Exemptions: Where there is a business need to be exempted from this policy (too costly, too complex, adversely impacting other business requirements) a risk authorized by security management must be conducted.
    3. Applications used by employees on their own personal devices which store or access corporate data, such as cloud storage applications, are also subject to this policy.
  3.  Policy
    1. Technical Requirements
      1. Devices must use the following Operating Systems: Android 2.2 or later, iOS 4.x or later. <add or remove as necessary>
      2. Devices must store all user-saved passwords in an encrypted password store.
      3. Devices must be configured with a secure password that complies with <Company X>’s password policy. This password must not be the same as any other credentials used within the organization.
      4. Only devices managed by IT will be allowed to connect directly to the internal corporate network.
      5. These devices will be subject to the valid compliance rules on security features such as encryption, password, key lock, etc. These policies will be enforced by the IT department using Mobile Device Management software.
    2. User Requirements
      1. Users may only load corporate data that is essential to their role onto their mobile device(s).
      2. Users must report all lost or stolen devices to <Company X> IT immediately.
      3. If a user suspects that unauthorized access to company data has taken place via a mobile device, they must report the incident in alignment with <Company X>’s incident handling process.
      4. Devices must not be “jailbroken” or “rooted”* or have any software/firmware installed which is designed to gain access to functionality not intended to be exposed to the user.
      5. Users must not load pirated software or illegal content onto their devices.
      6. Applications must only be installed from official platform-owner approved sources. Installation of code from untrusted sources is forbidden. If you are unsure if an application is from an approved source contact <Company X> IT.
      7. Devices must be kept up to date with manufacturer or network provided patches. As a minimum patches should be checked for weekly and applied at least once a month.
      8. Devices must not be connected to a PC which does not have up to date and enabled anti-malware protection and which does not comply with corporate policy.
      9. Devices must be encrypted in line with <Company X>’s compliance standards.
      10. Users may must be cautious about the merging of personal and work email accounts on their devices. They must take particular care to ensure that company data is only sent through the corporate email system. If a user suspects that company data has been sent from a personal email account, either in body text or as an attachment, they must notify <Company X> IT immediately.
      11. The above requirements will be checked regularly and should a device be non-compliant that may result in the loss of access to email, a device lock, or in particularly severe cases, a device wipe.
      12. The user is responsible for the backup of their own personal data and the company will accept no responsibility for the loss of files due to a non compliant device being wiped for security reasons.
      13. (If applicable to your organization) Users must not use corporate workstations to backup or synchronize device content such as media files, unless such content is required for legitimate business purposes.

      *To jailbreak/root a mobile device is to remove the limitations imposed by the manufacturer. This gives access to the operating system, thereby unlocking all its features and enabling the installation of unauthorized software.

    3. Actions which may result in a full or partial wipe of the device, or other interaction by IT
      1. A  device is jailbroken/rooted
      2. A device contains an app known to contain a security vulnerability (if not removed within a given time-frame after informing the user)
      3. A device is lost or stolen
      4. A user has exceeded the maximum number of failed password attempts
    4. Use of particular applications which have access to corporate data
      1. Cloud storage solutions: Company X supports the use of the following cloud storage solutions xxxxxx
      2. The use of solutions other than the above will lead to a compliance breach and the loss of access to the corporate network for the user

—————————End of example—————————————

 

pdf Example of Mobile Device Policy for Worcestershire NHS

Your Donation can make a difference

We have chosen to make our Resources freely and openly available on the web with the hope that it touches the life of thousands of readers who visits us daily. We hope our blog has helped in enhancing the knowledge of our readers and added value to organization and their implementers. We would request you to make donation large and small, so as to provide us the resources needed to distribute, collect, digitize as it is becoming extremely difficult for us to afford the full cost of updating and enriching our site content. Your contribution will ensure that we can keep our blog  up-to-date and add more of the rich resources — such as video — that make a difference for so many worldwide. Your donation will demonstrate your commitment to knowledge as a public good and is an important part of our overall sustainability plan. Your donation is also important in demonstrating to us how much you value the site and motivates us to devote more of our time towards developing this blog.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at: preteshbiswas@gmail.com or call Pretesh Biswas at +919923345531. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.

[contact-form-7 404 "Not Found"]

 

Advertisements

Leave a comment

Your email address will not be published. Required fields are marked *

Pretesh Biswas

Pretesh Biswas

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 1,225 other subscribers

%d bloggers like this: