Introduction
This document is targeted towards developers of Android mobile applications and those with Information Assurance responsibilities over mobile deployments. This document’s purpose is to ensure that Cyber Security and Information Assurance best practices are incorporated into the application development process.
Android applications and mobile devices have many challenges within DoD Information Assurance (IA) IT systems. Generally, a DoD IT system must apply for IA certification & accreditation (C&A) through one of the following documented processes: DoD Information Assurance Certification and Accreditation Process (DIACAP) or Platform IT (PIT). Both have stringent guidance programs which must be addressed in order to receive an authority to operate (ATO) with a DoD Designated Approving Authority (DAA).
Systems that do not have connectivity to the Global Information Grid (GIG) can apply as PIT with their DAA. If accepted, the PIT system has a lower level of guidance to follow for IA. Most systems, however, have some connection to the GIG, and fall under the IA category of DIACAP.
Systems that plan to follow DIACAP should assign an IA Manager (IAM) to address, guide, and ensure all programmatic DIACAP instructions and directives are adequately met. Along with the IAM, an IA Technical (IAT) engineer should be engaged for the lifecycle of the project to work as an integral part of an Integrated Project Team (IPT), as well as the IA liaison to the IAM.
Programs adhering to DIACAP should review documents DoD Directive 8500.1 and DoD Instruction 8500.2 for identification of artifacts necessary for C&A. From an engineering perspective, the first level of technical security guidance can be found in Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs). In the context of Android applications, operating systems, devices, and communications, the challenges are great. DISA has released a draft STIG for Android, but the STIG's focus is on email and calendar collaboration tools using the Good Mobile Messaging suite and Dell Android 2.2 devices. The finalized Android STIG is scheduled for October 2011. Projects using other Android devices or using Android devices for broader purposes need to request additional STIGs from DISA. DAA’s leverage DISA STIG’s when assessing a systems level of technical IA. DIACAP related document DoDI 8500.2 identifies STIG’s as an example of security guidance for engineering. The ultimate goal is for DoD information systems to maintain the appropriate level of confidentiality, integrity, authentication, non-repudiation, and availability.
As a general rule, the IPT determines which STIGs directly apply to its project. In the case of Android applications, we look to guidance from “Application Security and Development STIG Version 3 Release 2”, released 10 October 2010 and “Draft Android 2.2 (Dell) STIG Version 1 Release 0.1”, released 17 June 20111. Along with relevant STIGs, industry best practices for application development on the Android platform are leveraged; including Google’s Android documentation, and multiple security engineering print resources.
Application Permissions
Android implements an application permission framework that provides the ability to control the allowed operations of individual applications. This section provides guidance on making appropriate use of Android’s permission framework.
Leverage Android Permissions Model
This section identifies guidance for application permissions. It addresses how an application obtains access to capabilities of the Android device, and how a developer should grant and document the necessity for each granted access.
Android application permissions are expressed in the application’s AndroidManifest.xml file. Typically, the user is shown the list of requested permissions at install time, though this varies based on the particular mechanism used to install the application.
Do not anticipate Android users will understand the technical vernacular. Avoid using Binder, Activity, or Intent when describing permissions to users.2
When applying any android.permission, the developer shall provide external documentation as to the need/nature of the permission. As a rule, the requested permissions shall be limited to those required for the application to perform its intended tasks. An example of a permissions entry in the AndroidManifest.xml follows. In this example, the application requests the ability to receive SMS messages.
package="com.android.app.myapp" >
...
As of this writing, there are 116 Manifest permissions documented in the Android Developers SDK.3 See Appendix A for all permissions and details.
Creating New Manifest Permissions
If an application requires access to another application, a new permission may be defined. Our guidance recommends that developers define new permissions for controlling inter-application access. More details are provided in Section 7.
Any newly defined manifest permission shall be documented with rationale of the need. If the purpose of a custom permission is to reduce several individual permission messages, each of the intentionally bypassed permissions shall be documented. The documented manifest permission rationale will be included as an artifact for certification & accreditation.
General Application Authentication
This section leverages DISA’s draft Android STIG and the Application Security and Development STIG to provide guidance for application authentication and access control.
DISA guidance on application authentication is generally focused on applications connecting to web and/or application servers (i.e. multi-tier), and a backend database. For the approach with Android mobile apps, we need to recognize that some apps may have multi-tier implementations, whereas others may be confined to on-device installation. Either way, the premise of identifying all potential authentication points is crucial to providing proper access control.
 4
Figure 3‑1 Potential Sample Authentication
The sample application described from DISA guidance identifies a multi-tier application that connects to middleware servers and backend databases. If such an Android application is being developed, the developers shall review section 3.8 in “Application Security and Development STIG, V3R2” and recognize the necessity to substitute some assumptions. A model as defined above will require DoD Public Key Infrastructure (PKI)-approved credentials as detailed in DoDI 8520.2 and would require an approved common access card (CAC) reader, either built-in to an Android device or external. From the perspective of the DISA Application Security STIG, the “web browser” is the Android mobile application, and the “web user” is the Android device user.
For on-device applications that do not interface with remote services or backend databases, the complex authentication model described above does not directly apply to the Android application development model. An Android APK contains the application client, code, data, and database in a single file. “If application users are required to be authenticated, then this authentication must be performed using DoD-approved PKI credentials. Certain applications providing read-only public releasable information may not require user authentication.5”
Standalone applications, defined as not providing, using, or otherwise interacting with the network or application services, can make use of other authentication methods. For example, Android OS authentication can be used to establish identity to the application and resources. 6 Android OS authentication is not addressed in this publication.
For additional detailed direction on application authentication, refer to Application Security and Development STIG, V3R2, 3.8 Authentication.
| 