draftMobile Application Security Requirements GuideThe Mobile Application Security Requirements Guide (SRG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the NIST 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil.DISA, Field Security OperationsSTIG.DOD.MILRelease: 0.2 Benchmark Date: 22 Jul 20142I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>I - Mission Critical Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>SRG-APP-000033-MAPP-000010<GroupDescription></GroupDescription>SRG-APP-000033-MAPP-000010The mobile app must not modify, request, or assign values for operating system parameters unless necessary to perform application functions.<VulnDiscussion>A mobile app that operates with the privileges of its host OS is vulnerable to integrity issues and escalated privileges that would affect the entire platform and device. If the app is able to obtain OS privileges greater than necessary for proper operation, then an adversary is able to breach the app, has access to these additional privileges, and can perform unauthorized functions. These functions might include the ability to read sensitive data or execute unauthorized code. If the latter, then additional attacks on the system and DoD networks may be possible. Prohibiting an app from assigning itself unnecessary privileges greatly mitigates the risk of unauthorized use of those privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000213Modify the mobile app code so that the app does not modify, request, or assign values for operating system parameters unless necessary to perform application functions.Perform a review of the app's documentation to understand the app's operational requirements or the functionality of the app to establish the level of OS privilege required to operate. Based on the review, determine the appropriate OS permissions the app should have assigned during and at the time of installation. Next, conduct a static program analysis to assess the app's ability to restrict user OS privileges except where explicitly required for the app to operate. If the static program analysis reveals OS access privileges that exist, are modifiable or can be requested that are beyond requirements are granted to the application, this is a finding.SRG-APP-000033-MAPP-000011<GroupDescription></GroupDescription>SRG-APP-000033-MAPP-000011The mobile app must not execute as a privileged operating system process unless necessary to perform any app functions.<VulnDiscussion>A mobile app that operates with the privileges of its host OS will make the OS, device, and other apps vulnerable to such issues as escalated privileges that would affect the entire platform and device. If the app is able to obtain OS privileges greater than necessary for proper operation, then an adversary able to breach the app has access to these additional privileges and can perform unauthorized functions. These functions might include the ability to read sensitive data, or execute unauthorized code. If the latter, then additional attacks on the system and DoD networks may be possible. In applying this control, the device and data are protected against attacks that would be easily executed by a malicious user who has gained numerous privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000213Modify the mobile app code so that the app does not execute as a privileged operating system process unless necessary to perform any app functions.Perform a review of the app's documentation to understand the app's operational requirements or the functionality of the app to establish the level of OS privilege required to operate. Based on the review, determine the appropriate OS permissions the app should have assigned for normal app operations during and at the time of installation. Next, conduct a static program analysis to assess the app's ability to restrict user OS privileges except where explicitly required for the app to operate. If the static program analysis reveals OS access privileges that are beyond requirements are granted to the application, this is a finding.SRG-APP-000033-MAPP-000012<GroupDescription></GroupDescription>SRG-APP-000033-MAPP-000012A mobile app must not call APIs or otherwise invoke resources external to the mobile app unless such activity serves the documented purposes of the mobile app.<VulnDiscussion>A mobile app that does not operate within what should be appropriate limits will expose the device and all stored data inadvertently to non-secure domains, as well as provide a path for a malicious intruder to access the device and the data stored in it. If the mobile app calls APIs outside of its purpose, it could potentially perform unauthorized functions. These might include revealing the location of the user, obtaining data from the user's contact database, or other unauthorized functions. This control limits the API set and mitigates the risk that unauthorized actions are taking place with the app that could compromise the data’s confidentiality, as well as the user's safety and mission.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000213Modify mobile app code and architecture to create a sandbox environment for the app to prevent it from controlling APIs and accessing other resources that do not relate to the app's functional and operational requirements.Review the requirements for the app design, and assess which external resources it will require to address for normal operation. Perform a document review to evaluate the functional requirements to understand which APIs require addressing in order to meet these requirements. Next, perform a static program analysis and assess which APIs are addressed, i.e., camera, microphone, Bluetooth, address book, GPS, etc., and which apps, as well as other resources external to the app that are addressed. If the design/functional requirements documentation and static program analysis reveal that APIs and resources addressed or available are beyond those which the functional and operational requirements demand, this is a finding.SRG-APP-000342-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000342-MAPP-000100The mobile app must prevent organization-defined software from executing at higher privilege levels than users executing the software.<VulnDiscussion>In certain situations, software applications/programs need to execute with elevated privileges to perform required functions. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by organizations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002233Configure or code the mobile app to ensure the app prevents organization-defined software from executing at higher privilege levels than users executing the software.Review the mobile app configuration or code to determine if the app prevents organization-defined software from executing at higher privilege levels than users executing the software. If the app does not do this, it is a finding.SRG-APP-000372-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000372-MAPP-000100The mobile app must synchronize internal information system clocks to the MOS-based authoritative time source.<VulnDiscussion>Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events.
Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider setting time periods for different types of systems (e.g., financial, legal, or mission-critical systems). Organizations should also consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). This requirement is related to the comparison done every 24 hours in CCI-001891 because a comparison must be done in order to determine the time difference.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002046Configure or code the mobile app to synchronize internal information system clocks to the MOS-based authoritative time source.Review the mobile app configuration or code to determine if the app synchronizes the internal information system clocks to the MOS-based authoritative time source. If the app does not, this is a finding.SRG-APP-000381-MAPP-000010<GroupDescription></GroupDescription>SRG-APP-000381-MAPP-000010The mobile app must not change the file permissions of any files other than those dedicated to its own operation.<VulnDiscussion>A file's access level is pivotal to a mobile app and its data's security. The modification of a file's permission must be strictly controlled in an effort to maintain the integrity and confidentially of the data stored. If the file permissions are easily changed, attackers will try to gain any possible level of access and then try to escalate that level until they are able to obtain restricted data or make unapproved system modifications. This control mitigates the risk of privilege escalation by an unauthorized process or user resulting in data integrity and confidentiality issues. Please refer to CWEs: 250, 265, 272, and 284. The MApp SRG Overview contains additional information on the use of CWEs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001814Modify the mobile app code so it does not change the file permission on any files not dedicated to the mobile app's operation.Perform a static program analysis to determine if the mobile app code attempts to change the file permissions of files external to the operation of the mobile app. If this is not feasible, perform a dynamic program analysis to determine if routine installation and operation of the mobile app changes the permissions of any files other than those dedicated to the app. In order to complete this analysis, the permissions after operation of the mobile app will have to be measured against a known baseline of all the file permissions in the file system. If static analysis is not feasible and the MOS does not permit visibility into file system permissions, then this should be marked "Not Reviewed". If data files not dedicated to the operation of the app can have their permission attributes modified by the app, this is a finding.SRG-APP-000133-MAPP-000030<GroupDescription></GroupDescription>SRG-APP-000133-MAPP-000030The mobile app must not enable other applications or non-privileged processes to modify software libraries.<VulnDiscussion>Many apps leverage software libraries to perform app functions. If the app makes these library files world writeable or otherwise allows unauthorized changes, then other processes on the device could modify the library to give the app capabilities it did not have originally. These capabilities might enable the app to exfiltrate sensitive DoD information or permit privilege escalation, possibly leading to attacks on additional systems. Libraries could be modified through enabling other apps to do so or through the app itself allowing the user to do so. Implementing this control prevents apps from acquiring capabilities for which they were not originally authorized. Please refer to CWEs: 250, 265, 272, and 284. The MAPP SRG Overview contains additional information on the use of CWEs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001499Configure or code the mobile app to limit access to the app's software libraries to the app only.Perform a documentation review to assess if the app supports other apps or non-privileged processes that enable the app to modify software libraries. If the app functional requirements review cannot be carried out or is inconclusive, perform a static program analysis to assess if code exists that invokes other apps or other non-privileged processes that enables them the ability to modify software libraries. If the app's functional requirements review and/or the static program analysis reveals the app can enable other apps, as well as permit privileged processes the ability to modify software libraries, this is a finding.SRG-APP-000141-MAPP-000031<GroupDescription></GroupDescription>SRG-APP-000141-MAPP-000031The mobile app must not include source code, unreferenced code or subroutines that are never invoked during operation, except for software components and libraries from approved third-party products.<VulnDiscussion>Unused software and libraries increase a program size without any benefits and furthermore, may contain malicious code that would be later executed, and compromise the app and all stored data. Typically, unknown code cannot be evaluated as it is never executed during run time and thus it is not fully known that it is present until malicious action takes place. Implementing this control mitigates the risk of dormant code executing at an opportune moment, allowing itself privileges and compromising the integrity and confidentiality of all stored data on the device. Please refer to CWEs: 398, 478, 561, 563, 570, and 571 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000381Modify code to remove unused code, unused variables, and expressions whose logical state persists.Perform a static program analysis to search for code that is never executed. This analysis must also:
- assess if there are any variables that are assigned values but are never used.
- search for expressions that are hard coded as TRUE or FALSE.
If the code analysis reveals that there is either unused code, unused variables with values or expressions that are hard coded as TRUE or FALSE, this is a finding.SRG-APP-000142-MAPP-000032<GroupDescription></GroupDescription>SRG-APP-000142-MAPP-000032The mobile app must utilize ports or protocols in a manner consistent with DoD Ports and Protocols guidance.<VulnDiscussion>Failure to comply with DoD Ports, Protocols Services Management (PPSM) Category Assurance List (CAL) and associated vulnerability assessments may result in compromise of mobile protections or functionality of the app. Ports that are incorrectly used leave the app and device vulnerable to exposure from attacks that exploit ports that are open, are not used, and have no protection. This control assures that all application ports, protocols, and services needed for the app operation are in compliance with the DoD PPSM guidance. Implementing this control also mitigates the threat from malicious exploitation of open and unprotected ports that can lead to data integrity and confidentiality risks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000382Configure or code the mobile app so that it uses ports and protocols in accordance with the DoD PPSM.Perform a documentation review to assess all necessary ports, services, and protocols needed for the app's operation. Next conduct a static analysis to assess which ports are open, services used, and protocols available during the operation of the app. If a static analysis is not feasible, conduct a dynamic program analysis in conjunction with port scanning or protocol analysis tools to determine how the app uses network ports. Next, review the documentation at the following URL. (http://iase.disa.mil/ports/index.html)
Compare the findings of the above two documents and the static analysis results to assess if the ports, protocols, and services are in compliance with the Ports Protocols Services Management (PPSM) guidance, available at the above URL. If the documentation review and/or the static program analysis reveal that the app is not in compliance with DoD Ports and Protocols guidance, this is a finding.SRG-APP-000057-MAPP-000017<GroupDescription></GroupDescription>SRG-APP-000057-MAPP-000017The mobile app must enforce organization-defined limitations on the embedding of data types within other data types.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. Embedding of data within other data is often used for the surreptitious transfer of data. For example, embedding data within an image file (e.g., .jpg) is referred to as steganography and is used to circumvent protections in place to protect information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000029Configure or code the mobile app to limit the ability to embed data types within other data types.If the organization has no defined limitations on the embedding of data types within other data types, this requirement is NA. Perform a static program analysis to determine whether the mobile app contains code to limit the embedding of data types within other data types according to organization-defined specifications. Alternatively, perform a dynamic program analysis to determine if the app enforces the restriction in operation. This will require embedding data in other data in a manner that violates the organization-defined limitations, and then verifying the mobile app enforces the limitation. If the mobile app neither contains code to enforce the restriction nor can be demonstrated to enforce the organization-defined restriction, this is a finding.SRG-APP-000391-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000391-MAPP-000100The mobile app must accept Public Key Infrastructure (PKI) credentials.<VulnDiscussion>The use of PKI credentials facilitates standardization and reduces the risk of unauthorized access.
The DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001953Configure or code the mobile app to accept PKI credentials.Review the mobile app configuration, code, vendor documentation or JITC Certification to determine if the mobile app accepts PKI credentials for access to DODIN. If it does not, this is a finding.SRG-APP-000392-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000392-MAPP-000100The mobile app must electronically verify Personal Identity Verification (PIV) credentials.<VulnDiscussion>The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access.
The DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001954Configure or code the mobile app to electronically verify PKI credentials.Review the mobile app configuration, code, vendor documentation or JITC Certification to determine if the mobile app verifies PKI credentials for access to DODIN. If it does not, this is a finding.SRG-APP-000243-MAPP-000049<GroupDescription></GroupDescription>SRG-APP-000243-MAPP-000049The mobile app must not write data to persistent memory accessible to other applications.<VulnDiscussion>Persistent memory is memory that retains data even when the device is no longer powered on. It is often referred to as non-volatile memory and is typically used for file storage. If the app shares the same location of persistent memory with that used by other apps to include encrypted data, then the data is at great risk to exposure through being available to other apps after the app has shut down or a user session has terminated. Furthermore, even though the OS will always be able to read files, other apps that share the same persistent memory are potentially less secure and thus offer an accessible means for malicious intruders to retrieve this information through the other app. In many operating environments, assigning unique process IDs to each app facilitates their separation from one another. In applying this control, the user will be less susceptible to malicious intrusion and extrusion of data that resides in areas shared by other apps.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001090Modify code to assure the app does not share its persistent memory allocation with other apps and processes and does not address areas of persistent memory used by other apps and processes.If the mobile OS on which the mobile app resides does not permit the app to share persistent memory, then the app is compliant with this control. If the above control is not available, perform a static program analysis to assess if the app ever modifies the permissions of files to enable other apps to read or modify the files. If the static program analysis reveals that the app grants permissions that enable the app to share its area of persistent memory with other apps or processes, this is a finding. If the static program analysis reveals that the app's persistent memory is not secured and can be addressed and used by other apps and processes that allow file permissions to be changed, this is a finding. When applicable, examine the file permissions of files created by the app. If they permit other apps to access the files, this is a finding.SRG-APP-000439-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000439-MAPP-000100The mobile app must protect the confidentiality and integrity of transmitted information.<VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered.
Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002418Configure or code the mobile app to protect the confidentiality and integrity of transmitted information.This requirement is only valid if the MOS does not provide this service. Review the mobile app configuration and code to determine if the mobile app protects the confidentiality and integrity of transmitted information. If the app does not protect confidentiality and integrity of transmitted information, this is a finding.SRG-APP-000416-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000416-MAPP-000100The mobile app must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.<VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The app must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002450Modify the mobile app code to ensure it utilizes NSA-approved and validated cryptography for modules implementing encryption approved for classified information, key exchange, digital signature, and hash.Identify what cryptography, if any, protects classified information stored, processed, or transmitted on the device. Verify that the cryptography is NSA-approved for the protection of classified information from the documentation submitted with the app. If the app does not use cryptography to protect classified information, or does not use NSA-approved cryptography for this purpose, this is a finding.SRG-APP-000514-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000514-MAPP-000100If the underlying MOS does not provide NIST FIPS-validated crypto modules, the mobile app must implement NIST FIPS-validated cryptography for the following: to provision digital signatures; to generate cryptographic hashes; and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.<VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The app must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002450Modify the mobile app code to ensure it utilizes FIPS-validated cryptography to provision digital signatures; to generate cryptographic hashes; and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.Identify what cryptography, if any, protects unclassified information stored, processed, or transmitted on the device. Verify that the cryptography is FIPS-validated from the documentation submitted with the app. If the app does not use cryptography to protect unclassified information, or does not use FIPS-validated cryptography for this purpose, this is a finding.SRG-APP-000225-MAPP-000047<GroupDescription></GroupDescription>SRG-APP-000225-MAPP-000047The mobile app must fail to an initial state when the application unexpectedly terminates, unless it maintains a secure state at all times.<VulnDiscussion>An app maintains a secure state when there is strong assurance that each of its state transitions is consistent with the app's security policy. For many mobile apps, the only state for which the state is known to be compliant is the initial state because it does not have a documented security policy regarding state transitions. An app could be compromised, providing an attack vector to the app and OS if initialization, shutdown, and aborts are not designed to keep the app in a secure state. If the app fails without closing or shutting down processes or open sessions; authentication and validation mechanisms are considered weak and do not provide sufficient protection against unauthorized access to the application and all stored data. In applying this control, the app can be secured to its initial level of security in the event the app crashes or terminates. This will mitigate the threat of an unauthorized user taking control of the device and accessing the app and stored data, compromising its integrity and confidentiality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001190Modify the code to ensure the app returns to a secure, initial state upon unexpected termination.For apps that do not maintain a secure state at all times, perform a dynamic program analysis and perform transactions, so the app is in a state other than its initial state. Use OS controls to terminate the app or to create conditions that would force the app to terminate or crash. Restart the app and examine the app to determine if it is in its initial state. If it is not in its initial state, this is a finding.SRG-APP-000267-MAPP-000060<GroupDescription></GroupDescription>SRG-APP-000267-MAPP-000060The mobile app must not transmit error messages to any entity other than authorized audit logs, the MDM, or the device display.<VulnDiscussion>Error messages that are transmitted outside of the app environment reveal weaknesses in the app that will offer the potential for exposure to malicious users. By default many error messages contain data pertaining to the session, the ports, and user and in some instances, their authentication credentials. Through this control, any issues that an app may have are restricted to the user and the personnel who have access to audit logs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001314Configure or code the mobile app to send error messages to authorized audit logs, the MDM, or the device display.Review the mobile app configuration, documentation, or code to determine if the app transmits any errors to any entity other than audit logs, the MDM, or user display. Do the following:
- launch the app
- create an error condition using incorrect input (fuzzing the input with automated tools is one method that could be applied)
- observe any error messages that result on screen
- observe where any log files containing error messages are stored.
If the analysis reveals that error messages are sent to an entity other than audit logs, the MDM, or user display, this is a finding.SRG-APP-000516-MAPP-000064<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000064The mobile app code must not contain hardcoded references to resources external to the app.<VulnDiscussion>Hardcoded resources include URLs and path references to files outside of the app environment. An adversary who is aware of such references can attack the app by breaching the external resource it calls. In most cases, such references may be placed in configuration files that may be updated when the resource reference is no longer valid. This also makes such references more transparent than they would be if they remained embedded in app code.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Remove all hardcoded external resource references from the mobile app code.Perform a static program analysis and search the source code for common URL prefixes and suffixes (i.e., "http://", "ftp://", ".mil", ".com"). Also, look for common file path references (e.g., /bin). If there are any such references referring to something other than local app resources such as a configuration file, this is a finding.SRG-APP-000516-MAPP-000065<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000065The mobile app must remove temporary files when it terminates.<VulnDiscussion>Temporary files left on the system after an app has terminated may contain sensitive information. Such sensitive information includes authentication credentials or session identifiers that would enable an adversary to gain unauthorized access to other resources. Removing such files when an app terminates greatly mitigates the risk of this attack that would exploit these files and use them to re-launch the app, enjoy user privileges or breach the confidentiality or integrity of the data stored on the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Configure or code the mobile app to remove all temporary files before the application exits.Perform a dynamic program analysis by launching the app and checking to see if it stores any temporary files. Close the app. If any of these temporary files remain in persistent memory, this is a finding. If memory is not released and the app is not using garbage collection process for memory (e.g., Java Applications), this is a finding. Re-launch the app to perform selected actions that will knowingly generate temporary files. Exit the app, and then search for temporary files that are not being deleted by the app. If files generated during the app’s session were not deleted, this is a finding.SRG-APP-000516-MAPP-000066<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000066The mobile app must remove cookies or information used to track a users identity when it terminates.<VulnDiscussion>If the app does not remove temporary data, such as authentication data, temporary files containing sensitive data, and cookies, the data can be used again if the device is lost or stolen. Such information could also be used to track the user across app sessions or even across different apps, which poses an OPSEC risk. The temporary data could be used to reauthenticate the user or allow unauthorized access to sensitive data. Removing cookies assures the DoD greater security from intruders and unauthorized users accessing the temporary data and using it to potentially access the system, accessing sensitive data and compromising sensitive data's integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Configure or code the app to remove cookies or other information used to track the user's identity before the application exits.Determine if the app uses cookies or otherwise saves information used to track a user's identity. Perform a dynamic program analysis by launching the app and performing a transaction that would cause a cookie or other information tracking a user's identity to be downloaded onto the device. A baseline of the hash files of all app files may be needed to check whether changes have occurred. If the cookie or other information tracking a user's identity remains, this is a finding.SRG-APP-000516-MAPP-000067<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000067The mobile app must clear or overwrite memory blocks used to process potentially sensitive data. Sensitive data may include PII, a user's location, or authentication credentials.<VulnDiscussion>Sensitive data in memory should be cleared or overwritten to protect data that may be available to an attacker seeking ways to gain access to data that otherwise appears erased. Unless an app can overwrite memory blocks, the possibility exists for an attacker to cause the app to crash and analyze a memory dump of the app for sensitive information. Clearing memory will ensure the DoD the app can operate more securely, with greater protection applied to sensitive data that will be properly removed when no longer required. Additional overwriting requirements may be applicable to classified apps. Please refer to CWEs: 14, 226, 244, and 591 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Configure or code the mobile app to clear memory blocks used for storing sensitive data before the memory is released to other processes.If the app does not contain sensitive data, this check is not applicable. Furthermore, if the MOS on which the app runs clears memory whenever an app releases memory, this check is not applicable. Otherwise, perform a dynamic program analysis of the app and assess how memory blocks are cleared of sensitive data. This will likely require the use of a MOS emulator. If the app releases memory blocks before clearing them, this is a finding.SRG-APP-000516-MAPP-000068<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000068The mobile app must not be vulnerable to integer arithmetic vulnerabilities.<VulnDiscussion>Integer overflows occur when an integer has not been properly checked and is used in memory allocation, copying, and concatenation. Also, when incrementing integers past their maximum possible value, it could potentially become a very small or negative number. Integer overflows can lead to infinite looping when loop index variables are compromised and cause a denial of service. If the integer is used in data references, the data can become corrupt. Also, using the integer in memory allocation can cause buffer overflows and a denial of service. Integers used in access control mechanisms can potentially trigger buffer overflows, which can be used to execute arbitrary code. Removing integer arithmetic vulnerabilities mitigates the risk of multiple vulnerabilities to include denial of service to the app and the execution of arbitrary code. Please refer to CWEs: 125, 126, 190, 195, 197, 398, 787, and 805 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Modify code to reflect the following measures that will remove integer arithmetic vulnerabilities from the app code:
- Use unsigned values whenever possible.
- Use only unsigned integers in memory allocation.
- Use only unsigned array indexing functions.
- Validate user input of numeric value, allowing only known good data to pass.
- Compile with the highest warning level possible.If an app does not take any numeric inputs, this control is not applicable. Perform a static program analysis and assess the app for code that prevents integer overflow through a number of tests to include the following:
- Input negative values for numeric input.
- Input border case values (i.e., 0, 7, 8, 254, 255, 16353, and 16354).
- Input extremely large string values (> 64k).
- Input strings whose lengths equal border cases (32k, 32k-1, 64k, 64k-1).
If any of the above tests produce an integer overflow condition, this is a finding. See https://www.owasp.org for additional details.SRG-APP-000516-MAPP-000069<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000069The mobile app must not call functions vulnerable to buffer overflows.<VulnDiscussion>Buffer overflow attacks occur when improperly validated input is passed to an app overwriting memory. Buffer overflow errors stop execution of the app causing a minimum of denial of service and possibly a system call to a command shell giving an attacker access to the underlying operating system. An app that avoids buffer flow situations assures the DoD greater availability of the app due to better security against DoS attacks. Please refer to CWEs: 20, 74, 78, 88, 117, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 250, 251, 265, 415, 560, 686, 733, 787, and 805 for further information. The MAPP SRG Overview contains additional information on the use of CWEs. Further information on testing for buffer overflows can be seen at https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Modify code to remove identified or likely sources of buffer overflow vulnerabilities to include the following:
- Use static analysis tools that are known to find this class of vulnerability with few false positives.
- Validate all input before use, allowing only known-good input through.
- Recheck all calculations to ensure buffer sizes are calculated correctly.
- Recheck all array access and flow control calculations.
- Use compile-time options that add compiler buffer overrun defenses.Perform a static program analysis to assess how the app is written to properly manage buffer overflows. The static program analysis should evaluate measures that are in place that size buffers as appropriate for the operation of the app. Also, the analysis should seek the following areas of vulnerability:
- Cases where input is not checked before being copied into a buffer
- Incorrect use of some of the functions listed in Appendix B of the Application Security and Development STIG
- Incorrect calculations to determine buffer sizes
- Incorrect calculations to determine array indexes
Furthermore, for IPV6 capable apps, existing libraries must be checked to ensure they are capable of processing the increased size of IPv6 addresses to avoid buffer overflows. See section 5.4 of the Application Security and Development STIG for additional details.
If any of these vulnerabilities are found, this is a finding.SRG-APP-000516-MAPP-000071<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000071The mobile app must not be vulnerable to race conditions.<VulnDiscussion>A race condition occurs when an app receives two or more actions on the same resource in an unanticipated order which causes a conflict. Sometimes, the resource is locked by different users or functions within the app, creating a deadlock situation. Racing can occur when the design uses global variables in place of local variables, or a multi-threaded app does not use thread safe functions when threads are accessing the same object or data, as two examples. Applying this control, the DoD is protected against situations that would reduce the security posture of the app, device, data, and network as a result of security-related components not able to function as a result of the race condition. Furthermore, the user is also protected against access and availability issues that result from the app or certain components of the app from functioning correctly as a result of the race condition. Examples of race conditions vulnerabilities can be obtained from the OWASP website at https://www.owasp.org.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Remove any race conditions from the code.If the app does not use multiple threads or if it runs on a MOS that does not support multiple threads, then this control is not applicable. If the operating system is not multi-threaded or never runs more than one app at a time, or effectively mitigates risk through some other mechanism, then the requirement is non-applicable.
Perform a review of the documentation to understand how the app manages and is designed around the following items:
- Race conditions
- Using global variables when local variables could be used
- Multi-threaded app uses thread safe functions
- Global resources being locked before being accessed by the application Global objects and resources
- Multiple threads or processes are accessing the same object
- Resources created in common areas
- Overly permissive ACLs
If the documentation review cannot be carried out or is inconclusive, perform a static program analysis to assess how the app approaches each of the above items. Dynamic program analysis may also be useful to determine if race conditions are realized during operation. If the documentation and static program analysis reveal that the app design is reasonably likely to result in a race condition, this is a finding.SRG-APP-000516-MAPP-000073<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000073The mobile app must initialize all parameter values on startup.<VulnDiscussion>A mobile app could be compromised, providing an attack vector to it if the app initialization process is not designed to keep the app in both a secure and functional state. Any operating parameter in the app, such as variables and settings, must be reset and initialized to default values, otherwise an adversary in possession of the device could access the app with privileges. An app that re-initializes its parameters at start up is assured a more secure session since the app has initialized all functional components that allow it to operate properly and thus securely.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Configure or code the mobile app to initialize all parameter values on startup.Perform a dynamic program analysis to assess if the app upon startup initializes all parameter values the app uses. If the dynamic program analysis identifies any parameter value that is not initialized on startup, this is a finding.SRG-APP-000516-MAPP-000075<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000075The mobile app must not record or forward sensor data unless explicitly authorized to do so.<VulnDiscussion>Sensors include the GPS, gyroscope, accelerometer, camera, and microphone. When sensor data is either recorded locally or sent to a remote server, the potential exists for an adversary to obtain sensitive information that could be used to harm the user or compromise information systems. In particular, when location data is forwarded, the user may be physically targeted. User safety and mission assurance risks are mitigated when sensor data is only collected or forwarded when expressly authorized.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Configure or code the mobile app so that it does not record or forward sensor data unless explicitly authorized to do so.Perform a static program analysis to determine if the mobile app accesses any sensor data during its operation. If it does not, then there is no finding. If it does, perform a static or dynamic program analysis to determine whether the app either locally records the sensor information or forwards it to another host. If it does either of these, then verify that the activity is authorized. If it is not authorized, then this is a finding.SRG-APP-000516-MAPP-000077<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000077The mobile app source code must not contain adware or known malware.<VulnDiscussion>Malware will compromise the app data, device, and system. Under no circumstances will any code that is known to contain adware or malware be used. The entire application ecosystem will operate at a higher security with much higher integrity than a system with known malware.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Remove all known malware and adware from the app source code.Scan the app files using a program that uses a malware signature database to identify known malware. Use of commercial anti-virus tools that also scan for mobile app malware and adware will suffice. If the tool identifies any instance of known malware in the app files, this is a finding.SRG-APP-000516-MAPP-000078<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000078Unless the MOS manages app signing, the mobile app installation package must be digitally signed in accordance with FIPS 186-3 approved methods.<VulnDiscussion>One of the biggest risks on a mobile device is that it will execute malware that will compromise sensitive data on the device or enable subsequent attacks on other DoD information systems. One of the most effective means for preventing malware execution is to authenticate that software comes from a trusted source before it is installed. Digital signatures on software can be used to authenticate that the software comes from a trusted source. Signing the software in accordance with FIPS 186-3 provides additional assurance that the signature was affixed properly.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Digitally sign the application package using FIPS 186-3 approved methods.Perform a static program analysis to assess if the installation package uses digital signatures. If there is no digital signature, or if the signature was performed in a manner inconsistent with the guidance in FIPS 186-3, this is a finding. If the static program analysis reveals the installation package is not FIPS 186-3 compliant with regard to its digital signatures and the algorithms used, this is a finding.SRG-APP-000516-MAPP-000034<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000034The mobile app must not lock or set permissions on application files in a manner such that the operating system or an approved backup application cannot copy the files.<VulnDiscussion>If the app is able to lock files or modify file permissions in a manner that prevents higher-level system operations, such as backup and copying from taking place, then the potential exists for the data to be lost. This condition may also be a form of denial of service if the operating system cannot recover the locked areas, thereby leaving fewer resources for other processes. In applying this control, the system is able to perform its overarching control and functional procedures, above any privileges the app, the user, or an intruder may have. The control must be employed judiciously. For example, file access should not be so broad as to allow non-approved apps from reading the files (e.g., by setting files to world readable).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Configure or code the mobile app so the MOS or approved backup application is not prevented from copying mobile app files.Perform a static program analysis to assess the app's ability to lock or set file permissions that would prevent OS and other approved apps from performing copy and backup functions. If the app has the ability to set and lock file permissions, this is a finding.SRG-APP-000388-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000388-MAPP-000100The mobile app, when conditions defined in CCI-0002856, CP-12 are detected, must enter a safe mode of operation defined in CCI-0002857, CP-12.<VulnDiscussion>Configuring the app to revert to a predetermined safe mode of operation helps ensure continuity of critical operations during adverse conditions.
For apps supporting mission-critical functions, including military operations and weapons systems (especially real-time operational environments), organizations may choose to identify certain conditions under which the app will revert to a predetermined safe mode of operation. The safe mode of operation, which can be activated automatically or manually, restricts the types of app functions/commands that can be performed when those conditions are encountered. Restrictions include, for example, allowing only certain functions that could be carried out under limited power or with reduced communications bandwidth.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002855Configure or code the mobile app so that, when organization-defined conditions are detected, it enters a safe mode of operation with organization-defined restrictions.Review the mobile app configuration or code to determine if the mobile app, when organization-defined conditions are detected, enters a safe mode of operation with organization-defined restrictions. If the app does not enter a safe mode under the appropriate conditions, this is a finding.SRG-APP-000393-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000393-MAPP-000100The mobile app must implement organization-defined out-of-band authentication under organization-defined conditions.<VulnDiscussion>Out-of-band authentication uses two separate networks or channels to communicate between two parties or devices. For example, a user can access a site through a network connection, and a one-time password can be sent through a cellular network to that user's mobile device. This reduces the probability of the authentication process being compromised.
This type of authentication can be employed by organizations to mitigate actual or suspected man-in the-middle attacks. The conditions for activation can include, for example, suspicious activities, new threat indicators or elevated threat levels, or the impact level or classification level of information in requested transactions.
Out-of-band authentication (OOBA) refers to the use of two separate communication paths to identify and authenticate users or devices to an information system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-001957Configure or code the mobile app to implement organization-defined out-of-band authentication under organization-defined conditions.Review the mobile app configuration or code to determine if the mobile app implements organization-defined out-of-band authentication under organization-defined conditions. If it does not, this is a finding.SRG-APP-000516-MAPP-000038<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000038Mobile apps involved in the production, control, and distribution of symmetric cryptographic keys must use NIST approved or NSA approved key management technology and processes.<VulnDiscussion>Symmetric cryptographic keys must be managed according to approved processes using approved technology, to ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. If non-standard practices are applied to production, control, and distribution of symmetric cryptographic keys, then the DoD is potentially vulnerable to attack from adversaries who are able to exploit weak encryption keys that have been used by the app and system. This control assures the DoD a much higher degree of assurance that intruders will not gain access to the network through weaknesses that are mitigated or eradicated through best and approved practices and key management technologies.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Modify the mobile app code to use NIST approved or NSA approved symmetric key management technology and processes.If the mobile app is not involved in the production, control, and distribution of asymmetric cryptography keys, this control is not applicable. For mobile apps involved in the production, control, and distribution of symmetric cryptographic keys, perform a documentation review to verify NIST SP 800-57 approved technology and processes have been applied to the design of the app. The documentation review will also include assessing if there is a JITC certification of the key management technology's presence in the app. If the documentation review is inconclusive, perform a static program analysis to assess the app for inclusion of functional code, able to execute routines and functions that enable the application to comply with the above requirements. If any of the above requirements cannot be executed by the code, this is a finding. If NIST SP 800-57 Recommendation For Key Management is not used or enforced, this is a finding.SRG-APP-000516-MAPP-000039<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000039Mobile apps involved in the production, control, and distribution of asymmetric cryptographic keys must use NIST approved or NSA approved key management technology and processes.<VulnDiscussion>Asymmetric cryptographic keys must be managed according to approved processes using approved technology, to ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. If non-standard practices are applied to production, control, and distribution of asymmetric cryptographic keys, then the DoD is potentially vulnerable to attack from adversaries who are able to exploit weak encryption keys that have been used by the app and system. In applying this control, the DoD can be assured of a much higher degree of assurance that intruders will not gain access to the network through weaknesses that are mitigated or eradicated through best and approved practices and key management technologies.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Modify the mobile app code to use NIST approved or NSA approved asymmetric key management technology and processes.For mobile apps involved in the production, control, and distribution of asymmetric cryptographic keys, perform a documentation review to verify NIST SP 800-57 approved technology and processes have been applied to the design of the app. The documentation review will also include assessing if there is a JITC certification of the key management technology's presence in the app. If the documentation review is inconclusive, perform a static program analysis to assess the app for inclusion of functional code, able to execute routines and functions that enable the app to comply with the above requirements. If any of the above requirements cannot be executed by the code, this is a finding. If NSA recommendations for key management are not used or enforced, this is a finding.SRG-APP-000516-MAPP-000040<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000040Mobile apps involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 certificates or prepositioned keying material.<VulnDiscussion>Class 3 certificates are issued to individuals, organizations, servers, devices, and administrators for CAs and root authorities (RAs). Class 3 certificates undergo independent verification and checking of identity and authority which is performed by the issuing (CA). Networks and applications not using Class 3 Certificates are vulnerable to a multiple of malicious attacks that would essentially allow unauthorized access to and intrusion in a network. Similarly, using approved PKI class 3 certificates ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. In applying this control, the use of approved PKI Class 3 certificates will assure authentication, message, data and content integrity, and confidentiality encryption.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Modify the mobile app code to ensure it uses approved Class 3 certificates or prepositioned keying material.For mobile apps that are involved in the production, control, and distribution of asymmetric cryptographic keys, perform a documentation review to assess if approved Class 3 certificates or prepositioned keying material are used by the app. The documentation review will also include assessing if there is a JITC certification of the key management technology's presence in the app. If the documentation review is inconclusive, perform a dynamic program analysis to assess if approved Class 3 certificates or prepositioned keying material are used by the app. If the dynamic program analysis could not be performed or the results were inconclusive, carry out a static program analysis to assess if the app supports functional code, able to execute routines and functions that enable the app use of approved, Class 3 certificates or prepositioned keying material. If the documentation review, dynamic program analysis and/or the static program analysis reveal that the app is unable to or does not use approved PKI Class 3 certificates or prepositioned keying material, this is a finding.SRG-APP-000516-MAPP-000041<GroupDescription></GroupDescription>SRG-APP-000516-MAPP-000041Mobile apps involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 or class 4 certificates and hardware tokens that protect the user's private key.<VulnDiscussion>Class 3 and 4 certificates are issued by individuals, organizations, servers, devices, and administrators for CAs and root authorities (RAs). A hardware token offers an additional layer of security in addition to a password. Networks and applications not using hardware tokens to protect the private Class 3 certificates are vulnerable to a multiple of malicious attacks that would essentially allow unauthorized access and intrusion in a network. Networks and applications not using Class 3 and 4 certificates and hardware tokens are vulnerable to a multiple of malicious attacks that would essentially allow unauthorized access to and intrusion in a network. Similarly, using approved PKI class 3/4 certificates and hardware tokens, ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. Users of Class 3/4 certificates, as well as hardware tokens, will be assured of an extra level of security that will protect their certificates and the user's private key. The DoD CAC is an example of a compliant solution.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-000366Modify the mobile app code to use approved Class 3 or 4 certificates in conjunction with a hardware token that protects the user's private key.This requirement does not apply to the use of ephemeral key material (i.e., keys used only once for transactions such as wrapping or generating other keys). For mobile apps that are involved in the production, control, and distribution of asymmetric cryptographic keys, perform a documentation review to assess if the app employs use of approved Class 3 or 4 certificates in conjunction with hardware token. The documentation review will also include assessing if there is a JITC certification of the key management technology's presence in the app. The DoD CAC is a compliant solution. If the documentation review is inconclusive, perform a dynamic program analysis to assess if the app employs use of approved, Class 3 and 4 certificates in conjunction with a hardware token. If the documentation and/or review reveals that the app is unable to or does not use approved PKI Class 3 certificates or hardware tokens, this is a finding.SRG-APP-000449-MAPP-000100<GroupDescription></GroupDescription>SRG-APP-000449-MAPP-000100The mobile app must validate information output from software programs and/or applications defined in SI-15, CCI-0002770 to ensure the information is consistent with the expected content.<VulnDiscussion>Certain types of cyber attacks (e.g., SQL injections) produce output results that are unexpected or inconsistent with the output results that would normally be expected from software programs or applications. This requirement focuses on detecting extraneous content, preventing such extraneous content from being displayed, and alerting monitoring tools that anomalous behavior has been discovered.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>CCI-002771CCI-000366Configure or code the mobile app to validate information output from organization-defined software programs and/or applications to ensure the information is consistent with the expected content.Review the mobile app configuration, documentation, or code to determine if the mobile app validates information output from organization-defined software programs and/or applications to ensure the information is consistent with the expected content. If the app does not validate information output to ensure the information is consistent with the expected content, this is a finding.