Section
|
Description
|
DIACAP or STIG Reference
|
2.1
|
When requesting any Android permission, the developer must provide documentation as to the need for the permission.
|
|
2.4
|
Passwords should be masked so that they are not visibly displayed.
|
|
2.4
|
Passwords must be at least # characters long.
|
|
2.4
|
Insert additional password requirements.
|
|
2.4
|
Passwords must be encrypted in transit when transmitted.
|
|
2.4
|
Mobile devices require the use of a standard Notice and Consent banner, the contents of which are detailed in this section. The banner shall be implemented as a click-through at logon to the device or application.
|
|
3.1
|
Sensitive and personally identifiable information (PII) shall be protected by means of FIPS 140-2 compliant cryptographic algorithms and implementations.
|
|
3.2
|
Sensitive data should not be stored in the /sdcard partition.
|
|
3.4
|
Sensitive data should not be stored in files with world-read or world-write permissions.
|
|
4.1
|
Text fields should be strongly typed, meaning that the allowed characters, lengths, and ranges are known and enforced through input validation.
|
|
4.1.1
|
User input should not be directly passed to SQL queries. Instead, prepared or parameterized statements should be used for SQL queries.
|
|
4.1.2
|
The Java Class.forName, Class.newInstance, and Runtime.exec method calls should be avoided, with native Java calls used instead of making system calls when possible. If these methods need to be used, the developer must justify their use in documentation.
|
|
4.2
|
All Android application packages must be signed by a private key associated with a certificate held by the application developer or a trusted authority.
|
|
4.3
|
Application developers should avoid use of the Android NDK or Java JNI unless their use is necessary. Developers must justify in writing any use of the NDK or JNI.
|
|
5
|
Mobile applications should use data-in-transit encryption for all transmitted information unless a specific reason exists not to, which must be justified in writing.
|
|
5.1.1
|
SSL version 2.0 must not be used.
|
|
5.1.1
|
TLS versions 1.0, 1.1, 1.2, or above should be used.
|
|
5.1.1
|
In RSA PKI certificate environments, the TLS recommended cipher suites are:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
|
|
5.1.1
|
In elliptic curve PKI certificate environments, the TLS recommended cipher suites are:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
|
|
5.1.2
|
Android applications should be configured to only trust the appropriate PKI root certification authorities that are needed for communication by that application, rather than using the default Android root certificate list.
|
|
5.1.3
|
FIPS validated cryptographic implementations should be used.
|
|
5.1.4
|
TLS clients must always authenticate the server's certificate.
|
|
5.1.4
|
TLS client certificate authentication should be used when possible as it is a strong authentication method.
|
|
5.1.4
|
When username and password authentication is used, storing passwords on the Android device is prohibited. Instead, the client should obtain an authentication token from the server and store that instead if needed.
|
|
5.1.5
|
When IPsec VPNs are used, the guidance in NIST Special Publication 800-77 and 800-57 Part 3 should be followed. A FIPS validated IPsec client should be used.
|
|
5.2
|
Sensitive information such as phone number,device serial number, and device ID should not be used to identify connections.
|
|
6.1.1.1
|
Applications should use explicit Intents whenever it is possible to address a specific destination component.
|
|
6.1.1.1
|
Applications must use explicit Intents if the Intent is for an internal component (intra-application communication).
|
|
6.1.1.1
|
When sending broadcast Intents, applications should define a custom permission (or use existing appropriate permission) and only send the Intent to receivers that hold the permission in order to control who can receive the Intent. If all receiving applications are written by the same developer and signed by the same key, the permission should be declared as a signature-level permission.
|
|
6.1.1.1
|
Especially when implicit Intents are used, applications should avoid placing sensitive information inside the Intent. Applications should also perform input validation on any received response.
|
|
6.1.1.2
|
Before sending an explicit Intent, an application should check that the receiving application holds an appropriate permission to receive the Intent. In especially sensitive environments, an application should check the receiving application's package signature to ensure that it matches an expected value.
|
|
6.1.2
|
Internal application components (that have no need to be invoked by other applications) should explicitly be declared as not exported in the manifest
|
|
6.1.2
|
Applications must perform null checks on all received Intents.
|
|
6.1.2
|
Applications must ensure that received broadcast messages match an expected action before continuing processing them.
|
|
6.1.2
|
Applications should set permissions on their external components to control which other applications can invoke them. In especially sensitive environments, the application should obtain the sending application's package signature to ensure that it matches an expected value.
|
|
6.1.3
|
Sticky Broadcasts should not be used to send Intents with sensitive information.
|
|
6.2
|
Content Providers must only be exported when other applications have a need to use them.
|
|
6.2
|
If a Content Provider is exported, the application developer must define read and write permissions to prevent the Content Provider from being misused by malicious applications.
|
|
|
|
|
CAcronyms
AES Advanced Encryption Standard
APK (Android) Application Package
ATO Authority to Operate
C&A Certification and Accreditation
CA Certification Authority
CAC Common Access Card
CBC Cypher-Block Chaining
COMSEC Communications Security
CVE Common Vulnerabilities and Exposures
DAA Designated Approving Authority
DARPA Defense Advanced Research Projects Agency
DBA Database Administrator
DHE Diffie-Hellman (key exchange)
DIACAP DoD Information Assurance Certification and Accreditation Process
DISA Defense Information Systems Agency
DoD Department of Defense
DoDI Department of Defense Instruction
ECDHE Elliptic-curve Diffie-Hellman
ECDSA Elliptic-curve Digital Signature Algorithm
FIPS Federal Information Protection Standard
GIG Global Information Grid
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IA Information Assurance
IAM Information Assurance Manager
IAT Information Assurance Technical
IETF Internet Engineering Task Force
IP Internet Protocol
IPT Integrated Project Team
IT Information Technology
JNI Java Native Interface
NDK (Android) Native Development Kit
NIPRNET Non-secure Internet Protocol Router Network
NIST National Institute of Standards and Technology
NSA National Security Agency
OS Operating System
PED Portable Electronic Device
PII Personally Identifiable Information
PIT Platform Information Technology
PKI Public Key Infrastructure
PIV Personal Identification Verification
RDBMS Relational Database Management System
RFC (IETF) Request for Comment
RSA Rivest, Shamir and Adleman (algorithm for PKI)
SD Secure Digital (Card)
SEE SQLite Encryption Extension
SHA Secure Hash Algorithm
SQL Structured Query Language
STIG Security Technical Implementation Guide
SDK Software Development Kit
SMS Short Messaging System
SSL Secure Sockets Layer
TLS Transport Layer Security
US United States
VPN Virtual Private Network
| 