Resco Mobile CRM Security Guide - Resco Mobile CRM
Resco Mobile CRM Security Guide

1.  Overview
1.1  Resco Cloud
1.2  Microsoft Dynamics CRM and Dynamics 365 synchronization
1.3  Salesforce Synchronization
2.  Resco Mobile CRM Client
 2.1  User Password
2.2  Data Encryption Details
 3.  Back-end solution
 3.1  Resco Cloud
 3.2  Microsoft Dynamics CRM/Dynamics 365
 3.3  Salesforce
 4.  Resco Licensing Service
4.1  Enterprise Security
 4.2  Mobile Device Management Tools
 4.3  Index
 4.4  Groups
 4.5  Model, OS & ID
 4.6  Synchronization log
 4.7  App version and user
5.0  MAM tools – push actions (Mobile Application Management Tools
5.1  Lock
5.2  Wipe Out
5.3  Force Full Sync
6.0  Mobile Application Management Tools
6.1  Session Timeout
6.2  AppLock
6.3  AppWipe
6.4  Check security policy on login
6.5  Force server connection
6.6  Force wipe
6.7  Business hours
6.8  Password validation
7.0  Remote Application Management Tools

 

 

1.   Overview

 

1.1. Resco Cloud

The Resco Mobile application (client) communicates directly with the Resco Cloud server (public or private).

To synchronize the Resco Mobile CRM application with Resco Cloud, only the connectivity to the standard Resco Web Services is required. All the communication between the app and Resco Cloud uses a standard Web Services via HTTPS protocol secured by the TLS 1.2, TLS.1.1 and TLS 1.0 certificates.

If deploying an on premise instance of Resco’s CRM server, customers can also take advantage of VPN and Direct Access Connection for additional security of the data transfer.

 

1.2. Microsoft Dynamics CRM and Dynamics365 synchronization

The Resco Mobile application (client) communicates directly with the Dynamics CRM server.

JSBridge Guide 001

When synchronizing the Resco Mobile app with Microsoft Dynamics CRM, the communication uses standard Dynamic CRM Web Services provided by Microsoft. There is no middleware or transient data storage. The CRM data is not stored (or cached) anywhere except for the local storage on the client. The local storage (SQL database and files) contains only the configured subset of the CRM data. Selected CRM data (entities) can be configured to be “online only”, in which case it is not stored on the client at all.

For Mobile CRM Client Access License validation, the system uses only a minimal dataset needed for validation of the license for the particular Dynamics CRM users. Section 4 provides more details about the data sent to the Resco Licensing Service.

For overall architecture security there are 3 important parts described in the following sections:

  • Mobile client security
  • Dynamics CRM/Communication security
  • Data provided for the license validation

 

 

1.3. Salesforce synchronization

When connected to Salesforce, the Resco Mobile app communicates with Resco Cloud to download metadata (object schema, mobile customizations) and with Salesforce’s SOAP and REST APIs to manipulate the business data (objects and fields).

JSBridge Guide 001

To download metadata from Resco Cloud, connectivity to standard Resco Web Services is required. All the communication between the app and Resco Cloud uses standard Web Services via HTTPS protocol secured by the TLS 1.2, TLS.1.1 and TLS 1.0 certificates.

Data synchronization with Salesforce, the target organization, must support access to its data via standard Salesforce API.

 

2.   Resco Mobile CRM Client

The local storage encryption is enabled by default and cannot be disabled by the user. The administrator can use the Woodford tool to disable the encryption, but this is not recommended.

 

2.1. User Password

The main security token for the application is the application master password. The application uses this master password to encrypt the application database and other sensitive information stored in Mobile CRM application, as described later in more detail.

In case of legacy authentication methods which require the app to submit the user’s password to server (standard user, external user), the server password is used for encrypting the application master password for user’s convenience. With the OAuth2 authentication, the user must provide a dedicated password used for encrypting the application master password. Regarding password storage, the app can be configured to either:

  • Require the user to enter the password each time the application is launched (or resumed from background), or
  • Store the password in the device secure storage so that the user does not need to type it in repeatedly.

Explanation:

The device’s PIN protects the secure storage so that it cannot be decrypted until the device is unlocked. The device secure storage implementation is platform specific. (iOS secure storage (keychain) security http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords.pdf)

The device’s PIN prevents access to the device. Most platforms allow for the PIN to be disabled, in which case the application should not rely on storing the password in the device secure storage.

 

2.2. Data Encryption Details

Data encryption is based on an application key. The application key is randomly generated and protected by the user password. The key is used to encrypt all local CRM data. The details of this procedure are explained below.

The application generates the random application key when it creates its local database. Afterwards, it is stored in an encrypted form on the device file system and the application decrypts it when needed. The application key AES256 is used together with the user password (PBKDF2), a random IV and salt for encryption/decryption.

The following explains how the application key is used to secure application data. Remember, there are two data stores: the database and the blob store (attachments).

For encrypting the SQLite database, the application key is passed to the SQLite database driver.

The driver uses the application key and IV to encrypt/decrypt individual database pages using AES128 in CFB mode. Each page (1024 bytes) is encrypted separately. The IV is the page header (contains variable/unpredictable data).

Each file in the blob store (attachment store) contains a header with random IV (16 bytes) and encrypted data. The blob data is encrypted with AES256 in CBC mode using the application key, file header IV. PKCS7 is used for data alignment.

 

3.   Back-end solution

Regardless of the target backend system, it is of utmost importance to ensure there is a reliable and secure network connection between mobile devices and the backend servers, the servers are kept up-to-date with the latest security updates and configured to reject all unauthorized requests.

 

3.1 Resco Cloud

Servers in Resco Cloud are by default configured to be accessible via internet by the Resco Mobile solution and no special configuration is necessary. Resco Cloud makes use of HTTPS protocol for all communication. When deployed as a Private Cloud solution it is important for the company infrastructure to make sure the servers are accessible from mobile devices.

 

3.2. Microsoft Dynamics CRM / Dynamics365

The minimal requirement for the synchronization with the Dynamics CRM server is the Dynamics CRM web services and the authentication services availability. In case of the Internet Facing configuration, the Active Directory Federation Services (ADFS) must be accessible, too.

In cases where the Dynamics CRM server and the Active Directory Federation Services are not exposed to the Internet, use VPN or Direct Access connection.

Note: The default configuration of Dynamics CRM with Active Directory authentication uses HTTP protocol. It is highly insecure to expose the server to the Internet in this configuration. We strongly recommend using either VPN or Direct Access, or changing the configuration to use HTTPS to secure the data exchange between the Mobile CRM client and the Dynamics CRM Server.

 

 

3.3. Salesforce

In addition to the HTTPS network connection to Salesforce cloud, the Resco Mobile solution requires the target Salesforce organization to have API Access enabled. It is also crucial that Resco Cloud utilized for storing customizations and metadata (https://connect.rescocrm.com) is accessible from the mobile device.

 

4.   Resco Licensing Service

The Resco Mobile CRM Client Access License is validated online by Resco Licensing Service (https://iservices.resco.net).

For this purpose, the mobile application sends the server organization specific information, such as server organization ID and user unique ID, to Resco Licensing Service. This information is also stored in the encrypted local database just as all the other data.

A typical request looks like

<MobileClient>
   <Version>6.1.0.0</Version>
   <Edition>Resco</Edition>
   <DeviceId>45d780e4f18354949676f743b0h11633951652bc</DeviceId>
   <DeviceInfo>iPad 2 Wi-Fi only (iPad2,1) iPhone OS 6.0</DeviceInfo>
   <OrganizationId>4F767AFF-B33F-437C-A7CB-00249948C82B</OrganizationId>
   <OrganizationUrl>https://testcrm.resco.net</OrganizationUrl>
   <OrganizationName>testcrm</OrganizationName>
   <UserId>661BAC34-1128-40B1-9653-00B9F54158CD</UserId>
</MobileClient>

 

For deployment scenarios where the Resco Licensing Service is not reachable from client devices, an offline license can be stored in the CRM organization. Still the OrganizationId, OrganiationUrl and UserId must be supplied for an offline license to be issued.

 

 

4.1   Enterprise Security

As important as it is to get the data about your customers, is to keep them secure once you have them. Especially on a mobile device. With Resco Enterprise Security pack, you don’t need to worry anymore. Now you are able to apply enterprise security measures and restrictions, set rules and user rights, select which data can be downloaded to the application, or even wipe-out the data from the application. You can do it all remotely, fortified with push technology. It does not matter anymore what mobile platform your employees use, you can take control of all your mobile device’s security rules through one simple mobile device management (MDM) console.

 

4.2   Mobile Device Management tools

 

4.3      Index

You can index all your mobile devices in one structured list. This feature will give you a quick access to all the necessary information about all the mobile devices used to access CRM data in your company.

 

4.4      Groups

Divide the mobile devices into groups and apply different security rules. You can create unlimited number of groups and assign them various security policies. The group can consist of many devices or contain just a single device. It is up to you and your needs.

 

4.5      Model, OS and ID

View details about a mobile device like the model, running OS, and device ID.

 

4.6      App version and user

Woodford allows you to also see the currently installed version of the MobileCRM app and user of the mobile device. This is helpful to keep your staff updated. You can just view which version of the app is your mobile user currently using and force the update.

 

4.7      Synchronization log

See when your employees lastly synchronized the app. Keep track of the synchronizations and if it is necessary, force the synchronization remotely

JSBridge Guide 001

 

5. MAM tools—push actions (Mobile Application Management tools):

 

5.1      Lock

If a device is stolen or there are concerns about the security of offline data, the administrator is able to lock the application remotely on a single device, or a whole group of devices, in just one click and block the user from opening the application.

 

5.2      Wipe out

In the worst-case scenario you can completely wipe out the data from the application. All is done remotely just by one click and regardless the synchronization. This means that you delete the data remotely from the mobile device and nobody will be longer available to see them.

 

5.3      Force full sync

By just one click, you can force the application to perform a full synchronization of the data during the next synchronization of the app.

JSBridge Guide 001

 

6. Mobile Application Management tools

 

6.1      Session Timeout:

By enabling this option, you set the rule that the application locks automatically after X minutes of inactivity. After the lock, login is required to resume work with the application. Assuming that the device is lost, with this feature enabled there is very little possibility left for the unauthorized person to access the data using the mobile application.

 

6.2      AppLock:

In a case of need you can remotely locks the application. The user will not be able to work with the application until the access is enabled again by the admin.

 

6.3      AppWipe:

Wipe out the data from the application remotely.

 

6.4      Check security policy on login

If there is a policy set for the user or for the group of users, the application will verify it directly before the login. This makes sure the security policies apply on every launch of the application.

 

6.5      Force server connection:

The mobile device must connect to the server every (x) hours otherwise the login is refused. This way you can force the mobile users to use application and synchronize offline date on regular basis.

 

6.6      Force wipe:

If the app does not connect to the server in (x) hours, all the local data will be wiped out. You can set the interval you consider most fitting to your data security policy. This means that even if the device is left somewhere unattended, the unauthorized user will not be able to access the data after a configured period because it will be already gone. Simple, smart & safe.

 

6.7      Business hours

You can allow users to access the application only within the configured business hours. For example, if you set the working hours to be 10am-5pm the user will not be able to work with the application at any other time, prior or after these hours. You can set this rule for one user or for a group of users, and you can do it all remotely, even without notifying the users.

 

6.8      Password validation

Locks the app or wipes out the data after a number of incorrect password entry attempts. This is a great feature to prevent dictionary based or brute force attacks. If somebody will try to login to your mobile CRM application and you have this option enabled, they will lock the application directly after the configured number of incorrect logins.

 

All the Enterprise Security features can be combined to create an ideal security policy to keep your data safe from misusage.

JSBridge Guide 001

 

7.0 Remote Application Management Tools

To simplify the initial user access to the Resco app, use push applications via Remote Device Management. Follow the below mentioned parameters in your MDM to have control over your enterprise mobility.

Note: that this is the Apple-defined protocol, therefore, it applies only to iOS users for all MDM providers. Since iOS version 9.3, the mobile application supports MDM key-value pair provisioning on iOS devices.

You are able to specify the following parameters in your MDM:

UserMode                     (0:Standard, 1:External, 2: Anonymous, 3:CurrentWinUser, 4: OAuth2)

OrganizationUrl

UserName

Password

Domain

HomeRealm

ADFSUsername

SavePassword                  (true/false)

 

ExchangeUrl

ExchangeEmail

ExchangeUserName

ExchangePassword

 

SharePointServerType          (0: SameAsCrm, 1: AD, 2: Online, 3: ADFS)

SharePointUserName

SharePointPassword

 

Once the above configuration is specified, the application skips the initial tutorial and shows the synchronization window (with the above values pre-filled) on the first run.