A security risk analysis must be performed on a mobile operating (OS) system application by the DAA or DAA authorized approval authority prior to the application being approved for use.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-29894	WIR-MOS-AND-006-03	SV-39452r1_rule	DCCB-1 ECWN-1	High

Description
Non-approved applications can contain malware. Approved applications should be reviewed and tested by the approving authority to ensure they do not contain malware, spyware, or have unexpected features (e.g., send private information to a web site, track user actions, connect to a non-DoD management server).

STIG	Date
Android 2.2 (Dell) Security Technical Implementation Guide	2014-08-26

Details

Check Text ( C-38371r1_chk )
One of the primary security issues with the Android Operating System (OS) is the lack of strong application controls. Key issues include: •The list of OS resource permissions that must be selected during application install is vague and confusing and leads to applications being assigned OS permissions that are not needed. Successful exploits related to any of these issues could allow an attacker to obtain DoD sensitive information and potentially obtained elevated system or even root privileges on the device. •Applications operate in their own protected area (sandbox) but Android allows applications to share data which breaks the sandbox model. •Android allows applications to share memory space. •The Android signing key mechanism is weak. Applications can share signing keys. It is easy for an attacker to break an application’s signing key, add malware, and then resign the modified app with the original key, thereby allowing the modified application to appear as the original application. •The Android event handling mechanism is poorly implemented. Any application can listen for an event (Intent) and intercept the event, even if it is not intended for the application. An app can send an Intent to another app, which could cause unsecure conditions Detailed Requirements: Core applications are applications included in the smartphone operating system. Applications added by the wireless carrier are not considered core applications. A security risk analysis must be performed by the DAA or DAA approved approval authority prior to a mobile OS application being approved for use. -Since native encryption module included in the Android OS is not FIPS 140-2 validated, Android non-core applications can only be approved if they meet the following conditions: -- The application does not store any data locally on the device; or -- The application stores data locally on the device and the data is encrypted using a FIPS 140-2 validated cryptographic module; or --The application and application data are stored on the device micro SD card where FIPS 140-2 validated encryption is used. The DAA, DAA designated Application Configuration Control Board, or other DAA designated process has the responsibility to approve all third-party applications installed on Android devices under the purview of the DAA. The application review and approval process must include an evaluation of what OS level permissions are required by the application and how the application shares data and memory space with other applications. The review process must also ensure: - Approved applications do not contain malware or share data stored on the mobile OS device with non-DoD servers. - All approved applications are validated to ensure appropriate event handling features and proper permissions are applied on all Intents for approved applications. Check Procedures: Review this check after reviewing check WIR-MOS-AND-06-01 (V-24986). Determine if any non-core mobile OS applications have been approved by the DAA. -If no, this check is not applicable. -If yes, complete the following procedures: Ask the site for documentation that shows what security risk analysis procedures are used by the DAA prior to approving non-core applications for use. Determine if the procedures include an evaluation of the following: - What OS level permissions are required by the application? -How the application shares data and memory space with other applications. -The application does not contain malware. -The application does not share data stored on the smartphones with non-DoD servers. -Proper permissions are applied on all Intents in the application. -If the application stores data, the application data storage container is FIPS 140-2 validated. -Mark as a finding if the application security risk review procedures do not contain the required risk assessment evaluation tasks.

Check Text ( C-38371r1_chk )

One of the primary security issues with the Android Operating System (OS) is the lack of strong application controls. Key issues include:

•The list of OS resource permissions that must be selected during application install is vague and confusing and leads to applications being assigned OS permissions that are not needed. Successful exploits related to any of these issues could allow an attacker to obtain DoD sensitive information and potentially obtained elevated system or even root privileges on the device.

•Applications operate in their own protected area (sandbox) but Android allows applications to share data which breaks the sandbox model.

•Android allows applications to share memory space.

•The Android signing key mechanism is weak. Applications can share signing keys. It is easy for an attacker to break an application’s signing key, add malware, and then resign the modified app with the original key, thereby allowing the modified application to appear as the original application.

•The Android event handling mechanism is poorly implemented. Any application can listen for an event (Intent) and intercept the event, even if it is not intended for the application. An app can send an Intent to another app, which could cause unsecure conditions

Detailed Requirements:
Core applications are applications included in the smartphone operating system. Applications added by the wireless carrier are not considered core applications. A security risk analysis must be performed by the DAA or DAA approved approval authority prior to a mobile OS application being approved for use.

-Since native encryption module included in the Android OS is not FIPS 140-2 validated, Android non-core applications can only be approved if they meet the following conditions:
-- The application does not store any data locally on the device; or
-- The application stores data locally on the device and the data is encrypted using a FIPS 140-2 validated cryptographic module; or
--The application and application data are stored on the device micro SD card where FIPS 140-2 validated encryption is used.

The DAA, DAA designated Application Configuration Control Board, or other DAA designated process has the responsibility to approve all third-party applications installed on Android devices under the purview of the DAA. The application review and approval process must include an evaluation of what OS level permissions are required by the application and how the application shares data and memory space with other applications. The review process must also ensure:
- Approved applications do not contain malware or share data stored on the mobile OS device with non-DoD servers.
- All approved applications are validated to ensure appropriate event handling features and proper permissions are applied on all Intents for approved applications.

Check Procedures:

Review this check after reviewing check WIR-MOS-AND-06-01 (V-24986). Determine if any non-core mobile OS applications have been approved by the DAA.
-If no, this check is not applicable.

-If yes, complete the following procedures:

Ask the site for documentation that shows what security risk analysis procedures are used by the DAA prior to approving non-core applications for use.

Determine if the procedures include an evaluation of the following:
- What OS level permissions are required by the application?
-How the application shares data and memory space with other applications.
-The application does not contain malware.
-The application does not share data stored on the smartphones with non-DoD servers.
-Proper permissions are applied on all Intents in the application.
-If the application stores data, the application data storage container is FIPS 140-2 validated.

-Mark as a finding if the application security risk review procedures do not contain the required risk assessment evaluation tasks.

Fix Text (F-33666r1_fix)
Have DAA or Command IT CCB use the required procedures to review mobile OS applications prior to approving them.