• CAcronyms
  • Mitre technical report




    Download 252.44 Kb.
    bet6/6
    Sana21.03.2020
    Hajmi252.44 Kb.
    TuriReport
    1   2   3   4   5   6
    BCompliance Checklist

    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

    1 http://iase.disa.mil/stigs/stig/index.html

    2 Jesse Burns, iSEC Partners, Developing Secure Mobile Applications for Android, October 2008, Version 1.0

    3 http://developer.android.com/reference/android/Manifest.permission.html

    4 Application Security and Development STIG, V3R2, 3.8 Authentication, Figure 3-2, DISA Field Security Operations 29 October 2010

    5 Application Security and Development STIG, V3R2, 3.8.1.2 User Authentication, DISA Field Security Operations 29 October 2010

    6 Application Security and Development STIG, V3R2, 3.8.2.1 Standalone Application Authentication 29 October 2010

    7 Application Security and Development STIG, V3R2, 3.8.4 Password Authentication, DISA Field Security Operations 29 October 2010

    8 Draft Android 2.2 (Dell) Technology Overview, V1R0.1, E.2 Provisioning Procedures, DISA Field Security Operations 01 June 2011

    9 Application Security and Development STIG, V3R2, 3.8.8 Logon Banner, DISA Field Security Operations 29 October 2010

    10 http://www.hwaci.com/sw/sqlite/see.html

    11 http://sqlite-crypt.com

    12 http://sqlcipher.net

    13 http://code.google.com/p/android/issues/detail?id=191

    14 http://www.oracle.com/technetwork/java/seccodeguide-139067.html

    15 http://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf

    16 Application Security and Development STIG, V3R2, 3.8.1.3 Authentication, Figure 3-2, DISA Field Security Operations 29 October 2010

    17 http://developer.android.com/sdk/ndk/overview.html, retrieved on 9 June 2011.

    18 Adapted from http://code.google.com/p/android/issues/detail?id=16041 and http://download.oracle.com/javase/6/docs/api/java/security/KeyStore.html

    19 Enck, et al. A Study of Android Application Security. http://www.cse.psu.edu/~swarat/pubs/enck-sec11.pdf

    20 Chin, et al. Analyzing Inter-Application Communication in Android. MobiSys 2011. http://www.cs.berkeley.edu/~afelt/intentsecurity-mobisys.pdf

    21 http://www.enck.org/pubs/enck-sec11.pdf

    22 http://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf

    23 iSEC Partners, Developing Secure Mobile Applications for Android. http://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf

    24 From Chin, et al

    25 From Chin, et al

    26 From Chin, et al

    27 Jesse Burns, iSEC Partners, Developing Secure Mobile Applications for Android. http://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf

    28 Jesse Burns, iSEC Partners, Developing Secure Mobile Applications for Android. http://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf

    Approved for Public Release: 12-3459. Distribution Unlimited


    Download 252.44 Kb.
    1   2   3   4   5   6




    Download 252.44 Kb.

    Bosh sahifa
    Aloqalar

        Bosh sahifa



    Mitre technical report

    Download 252.44 Kb.