Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata
 

Android Remediation

Purpose

The purpose of this document is to explain the basics of Android remediation and how to set up and test the policies.

Overview

Six remediation policies, which define the conditions that make a device non-compliant, are available for Android devices. The following table provides a name and description of each policy. It is also important to understand which component triggers remediation (server or client), which is determined by the type of policy being implemented. Some policies require clients to detect non-compliant devices, which then contacts the server and extracts instructions on which steps to take for remediation. Others are detected by the server when an inventory exchange takes place.

Policy

Detection

Description

Administrator Setting Disabled

Client

Remediation triggered by Afaria client not being a device administrator

Password Policy Disabled

Client

Remediation triggered by ignoring a prompt requesting to implement a password policy on the mobile device. Prompt is typically generated by a password requirement defined in configuration policies

Device Compromised

Server

Remediation triggered when a device is found to be “compromised,” i.e., rooted or jail broken

Device in blocked group

Server

Remediation triggered when device is found to belong to a blocked group (Defined in the devices tab of Access Control Option)

Device not in selected group

Server

Remediation triggered when device does not belong to a specified group

Device not connected within

Server

Remediation triggered when a device has not connected to the Afaria Server within a specified timeframe

*Depending on the policy, detection will occur on either the server or the client

Note: It is important to emphasize that remediation policies are not retroactive, meaning that devices will not be remediated based on policies established after enrollment.

Remediation Action

Remediation actions are steps taken to alert users of non-compliance and/or to contain a possible incident. Remotely wiping email, for example, allows Afaria administrators to protect information from exposure to external entities---thus protecting organizational information and containing the incident to a simple policy violation. Alerting users of non-compliance comes in two forms: email and GCM. A simple notification is delivered to the device if GCM is enabled, whereas an email is sent to the users email address if email is enabled. Both options can be enabled if preferred.

Note: GCM messages require a note to be assigned to the group definition. This note is used as the content of the GCM message.

Re-compliant Message Settings

A second message is communicated to devices and users when a once non-compliant device has been reconfigured to be compliant. The messages are broadcasted when the device has been audited and determined to be in compliance. Re-compliant messages share the same features as those offered for Remediation Action.

Enabling and Testing Policies

Note: A complete remediation policy should be agreed upon and defined before enrolling any mobile devices with Afaria Server. This assures all devices are audited on the same conditions and that no rogue devices exist within or outside of groups.

                Enabling a specific remediation policy within Afaria Administrator is done by simply placing a check mark in the box corresponding to the target policy to be enabled. These selections are enabled by simply clicking the box, which produces the check mark, and then clicking the save button.  

Testing Specific Policies

                The following subsections cover the process of enabling and testing each Android-specific remediation policy.

Administrator Setting Disabled

Objective: The following steps are used to enable and test the “Administrator setting disabled” remediation policy.

Expected Outcome:

  • Define and successfully implement the Administrator Setting Disabled policy
  • Break compliance, resulting in remediation actions based on the defined policy
  • Bring device back into compliance, resulting in additional actions

Procedure:

  1. Enabling and applying the Policy:
    1. From the Access Control Option page of Afaria Administrator, click the Remediation Policy tab
    2. Place a check mark in the box to the immediate left of “Administrator setting disabled
    3. Under “Remediation Action
      Enable ”Send message to client when device remediated”
      Enable GCM
    4. Under “Re-Compliant Message Settings
      Enable “Send message to client when device becomes compliant”
      Enable GCM
    5. Enroll mobile device
    6. Testing the policy:
      1. [stage:Breaking Compliance] On the mobile device
        navigate to the Security Settings
        Select Device Administrators
        Disable Afaria as a device administrator
      2.  [stage:Forcing Audit] From the Afaria Administrator (server) Configuration Panel

Expand the collapsible Server menu
Click Schedule
Place a check mark in the box to the immediate left of “Client Group Auto Refresh”
From the newly appearing menu bar, click Run now

This forces a connection between the client and the server, which encourages auditing of clients. Non-compliant devices will then be remediated. 

  1. [stage:Bringing device back to compliance] On the mobile device

navigate to the Security Settings
Select Device Administrators
Enable Afaria as a device administrator

  1. [stage:Forcing Audit]

Repeat actions pertaining to step 2b

Password Policy Disabled

                A password policy greatly enhances the security of a mobile device. Access is controlled by forcing an individual to authenticate with the device before any interaction is allowed. Minimum password requirements such as length and complexity can be enforced. These details are all adjusted in configuration policies and must be applied before remediation will take place. Users will then be prompted to define a password for the device upon enrollment. When the “password policy disabled” remediation sub-policy is enabled, a device will be remediated if the user cancels or ignores the password prompt during initial enrollment.

Objective: The following steps are used to enable and test the “Password policy disabled” policy.

Expected Outcome:

  • Define and successfully implement the “Password policy disabled” policy
  • Break compliance, resulting in remediation actions based on the defined policy
  • Bring device back into compliance, resulting in additional actions

Procedure:

  1. Enabling and applying the policy:
    1. From the Access Control Option page of Afaria Administrator, click the Remediation Policy tab
    2. Place a check mark in the box to the immediate left of “Password policy disabled
    3. Under “Remediation Action

Enable ”Send message to client when device remediated”
Enable GCM

  1. Under “Re-Compliant Message Settings

Enable “Send message to client when device becomes compliant”
Enable GCM

  1. Define password policy in an Android configuration policy
  2. Enroll mobile device

Do not define device password when prompted

  1. Testing the policy:
    1. [stage:Breaking Compliance] on the mobile device

Select either a password or pin to define(This will vary depending on the Android configuration policy)
When prompted to enter the password/pin, simply hit the home or cancel button

  1. Remediating this setting may require canceling the password definition a number of times before triggering

This should result in remediation in a manner as defined in the remediation action policy

  1. [stage:Bringing device back to compliance] On the mobile device

Open Afaria, resulting in a prompt to define a password
Define a password that fulfills all requirements of the corresponding configuration policy

  1. [stage:Forcing Audit]

Repeat actions pertaining to step 2b
Another message alerting the user of compliance should be delivered to the device

Device Compromised

Note: A compromised Android device, or one eligible to be compromised, is required in order to conduct a thorough test of this feature. The word “compromised” is simply a label assigned to devices that have been freed from any form of manufacturer or developer controls, commonly known as “rooted.” Rooting a device is beyond the scope of this document and not an advised endeavor.

Objective: Define and test a remediation policy that detects compromised devices.

Expected Outcome: Detection and remediation, in the form of GCM or email messages, of compromised mobile devices.

Procedure:

  1. Enabling and applying the policy
    1. From the Access Control Option page of Afaria Administrator, click the Remediation Policy tab
    2. Place a check mark in the box to the immediate left of “Device compromised
    3. Under “Remediation Action

Enable ”Send message to client when device remediated”
Enable GCM

  1. Under “Re-Compliant Message Settings

Enable “Send message to client when device becomes compliant”
Enable GCM

  1. Enroll mobile device

                                                               i.      Compromised devices can still enroll, but will be marked as non-compliant

  1. Testing the policy
    1. If not already completed, compromise device
    2. [stage:Forcing Audit] From the Afaria Administrator (server) Configuration Panel

Expand the collapsible Server Menu
Click Schedule
Place a check mark in the box to the immediate left of “Client Group Auto Refresh
From the newly appearing menu bar, click Run Now

This forces a connection between the client and the server, which encourages auditing of clients. Non-compliant devices will then be remediated.

  1. [stage:Bringing device back to compliance] On the mobile device

Restoring a device back to a non-rooted device is the only method of bringing it back into compliance

Device in Blocked Group

Particular groups of devices or users can be blocked from accessing Afaria servers. This is easily accomplished by defining a specific group that is representative of devices or users to be denied access to the server. Once a group defined and configured, navigate to the Access Control Option menu of the server configuration page. Similar to the steps of adding a group to an enrollment policy select the blocked group and add it to the Selected Groups. Objects belonging to this group are now “blocked,” and are prepared for detection and remediation.

Objective: Define and implement a remediation policy that detects devices in a blocked group

Expected Outcome: Devices belonging to a blocked group should be remediated in the form of GCM or email message

Procedure:

  1. Targeting the blocked group
    1. Create a group for the devices to be blocked
    2. From the Access Control Option page of Afaria Administrator, click the Groups tab
    3. From the Available Groups selection panel, place a check mark in the box beside the group to be blocked
    4. Similar to adding a group to an enrollment policy, move the target group from Available Groups to Selected Groups
    5. Click Save.  
  2. Enabling and applying the policy
    1. From the Access Control Option page of Afaria Administrator, click the Remediation Policy tab
    2. place a check mark in the box to the immediate left of  the “Device in blocked group” remediation policy
    3. Under “Remediation Action

Enable ”Send message to client when device remediated”
Enable GCM

  1. Under “Re-Compliant Message Settings

Enable “Send message to client when device becomes compliant”
Enable GCM

  1. Enroll mobile device
  2. Testing the policy
    1.  [stage:Forcing Audit] From the Afaria Administrator (server) Configuration Panel

Expand the collapsible Server menu
Click Schedule
Place a check mark in the box to the immediate left of “Client Group Auto Refresh
From the newly appearing menu bar, click Run Now

  1. This forces a connection between the client and the server, which encourages auditing of clients. Non-compliant devices will then be remediated.
  2. [stage:Bringing device back to compliance] On the mobile device

Simply moving the device out of the blocked group will bring the device back into compliance

Device Not in Selected Group

Similar to the policy governing devices belonging to blocked group, this policy remediates devices that do not belong to a specific group. Essentially, this functions in an inverse manner. By navigating to the Groups tab of the Access Control Option section of the server configuration page, the option to “Only allow selected groups” must be enabled by checking the enable box in order to apply this policy. Add approved groups to the “Selected Groups” section. Devices belonging to other groups will be remediated once audited.

Objective: Detect and remediate enrolled device that do not belong to an approved group.

Expected Outcome:  Action devices not in a selected group.

Procedure:

  1. Enabling and applying the policy
    1. From the Access Control Option page of Afaria Administrator, click the Remediation Policy tab
    2. place a check mark in the box to the immediate left of  the “Device not in selected group
    3. Under “Remediation Action

Enable ”Send message to client when device remediated”
Enable GCM

  1. Under “Re-Compliant Message Settings

Enable “Send message to client when device becomes compliant”
Enable GCM

  1. From the same section as the Access Policy tab, click the Groups tab

Enable “Only allow selected groups”
From the “Available Groups Pane,” place a check mark beside a group the mobile device about to be enrolled will NOT be a member of.
Using the right arrow button, move the group to the “Selected Groups” pane
Save these changes

  1. Enroll mobile device

Be certain that conditions place the device in a group that is not in a selected group before enrollment

  1. Testing the policy
    1.  [stage:Forcing Audit] From the Afaria Administrator (server) Configuration Panel

Expand the collapsible Server Menu
Click Schedule
Place a check mark in the box to the immediate left of “Client Group Auto Refresh”
From the newly appearing menu bar, click run now

  1. This forces a connection between the client and the server, which encourages auditing of clients. Non-compliant devices will then be remediated.

Device Not Connected Within a Specific Time Frame

                Devices must periodically connect to Afaria Servers in order to obtain the latest policies, newest enterprise application listings, and to also deliver inventory lists. Not enforcing period connections to the server can result in devices operating with outdated information or in a non-compliant state. Thus it is beneficial to remediate devices, which can send alerts to users requesting a session, to encourage a connection. Using this sub-policy, a device will be remediated if it has not connected to the server within a frame that has been defined by an administrator.

Objective: The following steps are used to enable and test the “Device not connected within” sub-policy of the overall remediation policy.

Expected Outcome:

  • Define and successfully implement the “Device not connected within” sub-policy
  • Break compliance, resulting in remediation actions based on the defined sub-policy
  • Bring device back into compliance, resulting in additional actions
  1. Enabling and applying the policy
    1. From the Access Control Option Screen, place a check mark in the box to the immediate left of  the “Device not connected within” remediation policy

Adjust the time period for a reasonable time-frame for testing purposes. The minimum amount of time is one (1) hour.

  1. Under “Remediation Action”

Enable ”Send message to client when device remediated”
Enable GCM

  1. Under “Re-Compliant Message Settings”

Enable “Send message to client when device becomes compliant”
Enable GCM

  1. Enroll mobile device
  2. Testing the policy
    1. [stage:Breaking Remediation] occurs by simply waiting for the minimum amount of time to pass. Remediation should take place after that period of time.
  • No labels