The 5 Layers of Secure Mobile Architecture

Mobile applications and the corresponding security vulnerabilities presented by them are a crucial next step in the evolution of training systems used by today’s Warfighters.  With the enhanced toolset presented by these devices, applications are able to use a variety of new information that was previously not possible and presents many exciting new possibilities in the realm of training and simulation.

Added feature sets include mobile devices ability to track the Warfighter with GPS, connect the Warfighter with cellular data feeds, help the Warfighter report and document their field of vision with cameras, detect sudden changes in inertia with the accelerometer, and the ability for an unlimited amount of different sensors to be interfaced to the mobile device by third party companies.  As exciting as the possibilities are, they come at a great cost to operational security in the form of exploitation of these additional data sources.  To help mitigate against successful exploitation, a set of standards exists put forth by various security compliance organizations such as DISA, Common Criteria, and the National IA Partnership (NIAP).

To properly field a mobile application in a secure manner, five layers of security need to be addressed.  These layers, as detailed in diagram A, are device security, data security, application security, network security, and cloud security.  Each layer has its own set of challenges which must be addressed for a training system incorporating mobile architecture to pass its certification and accreditation process (C&A) and receive an authority to operate (ATO).  DoD IA controls which currently dictate information assurance compliance are available within the appropriate DISA STIGs and can be traced back to their underlying DoDI 8500.2 IA Control.  We have broken up the specific controls as they fit into the five layers of security detailed in diagram A and also provided a brief explanation of them as follows:

  1. 1.      Device Security
  • ·        DCAS-1 | Acquisition Standards:  Mobile OS’s must be selected from the NIAP Approved Products List (APL), or the Common Criteria (CC) list.  As of this writing, only Windows Mobile and Blackberry are certified on the CC or NIAP; however DISA is publishing guidance for Android and Apple iOS.  For any Army application the Common Operating Environment (COE) guidance is also available for reference.
  • ·        IAIA-1 | Individual Identification and Authentication:  A device must be secured by a secure device passcode policy as a first line of defense against unauthorized access to any and all mobile devices.
  • ·        DCCS-1 | Configuration Specifications: As of this writing, mobile architecture DISA STIGs are in their draft stages but are increasingly maturing.  As final versions are released, compliance of these STIGs will be required by any trainer with mobile components seeking an ATO.
  • ·        DCSR-2 | Specified Robustness – Medium:  These details that all mobile products used should be selected which at a minimum meet a robustness level of medium.
  • ·        IAAC-1 | Account Control:  An approved account management policy with the ability to configure the mobile endpoints remotely through an MDM should be incorporated.
  • ·        ECLO-1 | Logon:  Mobile devices should be configured to reflect current DISA STIG settings such as denying access after multiple unsuccessful attempts, incorporating a time-delay control system,  as well as limiting the number of unsuccessful attempts in a given time period.
  • ·        ECWM-1 | Warning Message:  The mobile device should warn any users that they are entering a Government owned information system prior to granting access.
  • ·        PESL-1 | Screen Lock:  An MDM should have the ability to activate and remotely push settings for a screen lock given a pre-determined period of inactivity.

 

  1. 2.      Data Security
  • ·        ECCR-1 | Encryption for Confidentiality (Data at Rest):   Federal Information Processing Standard (FIPS) 140-2 approved encryption should be built-in for protecting data at rest just in case a mobile device is lost or stolen.
  • ·        ECNK-1 | Encryption for Need to Know:  FIPS 140-2 approved encryption should separate out any data classified as “need to know”.

 

  1. 3.      Application Security
  • ·        ECRC-1 | Resource Control:  The system should guarantee that no residual data is maintained on any device if the device is repurposed and/or reissued to different personnel.
  • ·        ECTP-1 | Audit Trail Protection:  The MDM used on the system should have auditing capture capabilities of all mobile device events and have the ability to safeguard these audit logs.

 

  1. 4.      Network Security
  • ·        ECWN-1 | Wireless Computing and Networking:  Any unused wireless functionality of mobile devices should be turned off and the device should also prohibit end users from reconfiguring these capabilities.
  • ·        ECCT-1 | Encryption for Confidentiality (Data in Transit):  FIPS 140-2 approved encryption should be used for encrypting data as it moves through other commercial and wireless networks.
  • ·        EBVC-1 | Virtual Private Network (VPN) Controls:  Mobile devices should be able to connect to VPN servers.

 

  1. 5.      Cloud Security
  • ·        PRTN-1 | IA Training:  Personnel supporting a cloud data center should be trained through a program setup to ensure compliance with information assurance roles and responsibilities.  In addition, users of the mobile devices should have training on the security risks associated with the mobile devices.
  • ·        CODB-1 | Data Backup Procedures:  MDM Server and mobile device data should be backed up at least weekly.
  • ·        VIVM-1 | Vulnerability Management (VM):  An Information Assurance Vulnerability Management (IAVM) plan should include any mobile devices to ensure that mobile OS patches and Information Assurance Vulnerability Alerts (IAVAs) are installed in a timely manner.