Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For applications that store a single classification of data or have multiple personas, this check does not apply. For applications that store classified data, perform a static program analysis of the application software to assess if the highest data classification attribute is automatically or manually created. If the supporting code is not present, this is a finding.
Modify code to enable the creation and storage of a highest data classification attribute.
For applications that store a single classification of data or have multiple personas, this check does not apply. For applications that store classified data, perform a static program analysis of the application software to assess if the highest data classification attribute is automatically or manually created. If the supporting code is not present, this is a finding.
Modify code and functionality that prohibits an application from reclassifying the data downwardly.
For applications that store a single classification of data or have multiple personas, this check does not apply. For applications that transmit classified data, perform a dynamic program analysis to assess if any data classification attributes are transmitted with the data. Check the received data and examine it for the inclusion of classification attributes. If the dynamic program analysis is inconclusive, or cannot be performed, carry out a static program analysis to assess if the code supports any data classification attributes are transmitted with the data. If the static or dynamic program analysis reveals no data classification attributes are transmitted with the data, this is a finding. This test may entail an end-to-end test that extends beyond that of the application, to ensure the data file construct meets the requirements of data classification attribute presence.
Modify code to include data classification attributes with transmitted data.
For applications that store a single classification of data or have multiple personas, this check does not apply. For applications that store, process, or transmit classified data, carry out a dynamic program analysis to assess if the application assigns a classification attribute to any newly created data file or transmitted data stream. Examine each data file created and assess if an attribute is included. If the dynamic program analysis is inconclusive, or cannot be performed, carry out a static program analysis to assess if code is present that makes the application assign a classification attribute to any newly created data file and transmitted data stream. If the dynamic or static program analysis reveals no data classification attributes are assigned to any newly created data file or transmit data stream, this is a finding.
Modify code to assign a classification attribute to any newly created data file or stream when the application stores, processes, or transmits classified data.
For applications that combine classified data from multiple data elements, perform a dynamic program analysis to assess if the application assigns the highest classification of the combination's elements to the classification attribute of the combination whole. Examine each data file created and assess if the appropriate attribute is included. If the dynamic program analysis is inconclusive, or cannot be performed, carry out a static program analysis to assess if code is present that forces the application to assign the highest classification of the combination's elements to the classification attribute of the combination whole. If the static or dynamic program analysis reveals the application does not assign the highest classification of the combination's elements to the classification attribute of the combination whole, this is a finding.
Modify code to ensure the application assigns the highest classification of the combination's elements to the classification attribute of the combination whole.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For applications that transmit classified data, perform a dynamic program analysis to assess if the application was able to maintain the binding of classification attributes to data throughout transmission. These attributes must be able to be properly processed by automated policy action on the receive side and thus the network to which the application transmits the data must be a part of the test. If the dynamic program analysis is inconclusive, or cannot be performed, carry out a static program analysis to assess if the application is able to maintain the binding of classification attributes to information when it is being transmitted. This test may entail an end-to-end test that extends beyond that of the application, to ensure the data file constructs meets the requirements of data attribute presence and binding. If the dynamic or static program analysis reveals the application does not maintain the binding of classification attributes to information with sufficient assurance that the information/attribute association can be used as the basis for automated policy actions, this is a finding.
Modify code to strongly bind classification attributes to information using asymmetric cryptography or an approved alternative technology that provides sufficient assurance that the information/attribute association can be used as the basis for automated policy actions.
For applications that process, store, or transmit classified data, research the mobile application's CONOPs and assess if the applications' stored, processed, and transmitted data is to be uniformly treated as one, single security classification. If the latter is true, then the application is in compliance. If the CONOPS review reveals that no requirement for handling data at a single classification level exists, then perform a dynamic program analysis to assess if the application allows a user to manually assign a classification to the data stored on the device. If the dynamic program analysis is inconclusive, or cannot be performed, carry out a static program analysis on the application to assess if code exists that allows all data to be held and attributed at one, single classification level. If the dynamic or static program analysis concluded that the user cannot manually assign a classification to the data stored on the device, this is a finding.
If the CONOPs do not require data to be classified uniformly at one level, modify code to support manual classification of the data by the user.
For applications that process, store, or transmit classified data, perform a dynamic program analysis to assure that the user is reliably informed in human readable form of the classification of any data that the user works with on the mobile device. If no function exists to display the classification of the data in human readable form whenever it displays any data to the user of the mobile device, this is a finding.
Modify code to create functionality that displays the classification of the data in human readable form whenever it displays any data to the user of the mobile device.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a static program analysis to determine if the application executes non DoD-approved external code at any time. Check whether calls to such code include a user acceptance or direction step. Perform a dynamic program analysis to verify the application does not execute non DoD- approved code without user direction. In this context, user direction refers to the user either accepting or requesting the service or capability that the code provides upon each instance code is executed which has not been executed previously. It is not acceptable to have a one-time acceptance to accept automatic execution. If the application ever executes non DoD-approved external code, this is a finding.
Modify code to prevent execution of code non DoD-approved without user direction.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a review of the application's documentation to understand the application's operational requirements or the functionality of the application to establish the level of OS privilege required to operate. Based on the review, determine the appropriate OS permissions the application should have assigned during and at the time of installation. Next, conduct a static program analysis to assess the application's ability to restrict user OS privileges except where explicitly required for the application 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.
Modify the code to secure the boundaries within which the application may operate with respect to OS privileges.
Perform a review of the application's documentation to understand the application's operational requirements or the functionality of the application to establish the level of OS privilege required to operate. Based on the review, determine the appropriate OS permissions the application should have assigned for normal application operations during and at the time of installation. Next, conduct a static program analysis to assess the application's ability to restrict user OS privileges except where explicitly required for the application to operate. If the static program analysis reveals OS access privileges that are beyond requirements are granted to the application, this is a finding.
Modify the code to secure the boundaries within which the application may operate with respect to OS privileges.
Review the requirements for the application 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 applications, as well as other resources external to the application 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.
Modify code and architecture to create a sandbox environment for the application to prevent it from controlling APIs and accessing other resources that do not relate to the application's functional and operational requirements.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For mobile applications that support multiple persona, perform a dynamic program analysis to assess the application's ability: - to identify the domains not authorized for using DoD data. - to prevent inter-domain transfer of data on the device through any designed in policy controls if they are present. If the dynamic program analysis cannot be performed or is inconclusive, perform a static program analysis to assess if code is present that will support the application's ability to identify the domains not authorized for accessing DoD data and the ability to prevent data transfer between these identified domains. If the dynamic program analysis and static program analysis concludes that domains cannot be identified and discerned between, this is a finding.
Implement non-discretionary access controls in the application or operating system to prohibit unauthorized transfers between domains.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For mobile applications that support multiple personas, perform one or more of the following: Conduct a dynamic program analysis to assess the application's ability to: - identify data that is authorized for inter-domain transfer. - grant the ability to transfer the above data. - prevent inter-domain transfer of data if it is not authorized to do so. If the dynamic program analysis cannot be performed or is inconclusive, perform a static program analysis to assess if code is present that will support the application's ability to identify data authorized for inter-domain transfer. The review must also identify code that will prevent the inter-domain transfer of data, if not it is not authorized for such transfer. The mobile application may also leverage available MOS or virtualization services that enforce persona separation to achieve compliance. If the dynamic program analysis and/or static program analysis conclude that data authorized for inter-domain transfer cannot be identified, this is a finding. If the dynamic program analysis and/or static program analysis conclude that data transfer between domains is always permitted, this is a finding. If the dynamic program analysis and/or static program analysis reveal there is no ability to discern authorized and non authorized data for inter-domain transfer, this is a finding.
Modify code or operating system configuration to prohibit the transfer of identified unauthorized data between domains.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If the application does not support multiple personas, this requirement is not applicable. For mobile applications that support multiple personas, conduct a dynamic program analysis to assess the application's ability to identify the source persona. This is primarily achieved by verifying the application enforces known restrictions on inter-persona transfers. If the dynamic program analysis cannot be performed or is inconclusive, perform a static program analysis to assess if code is present that will support the application's ability to identify the source persona in such scenarios. If the dynamic program analysis and/or static program analysis conclude that the application does not identify the source persona when transferring data from one persona to another, this is a finding.
Modify code to identify the source persona when data is transferred from one persona to another.
If the application does not support multiple personas, this requirement is not applicable. For mobile applications that support multiple personas, conduct a dynamic program analysis to assess the application's ability to authenticate the source persona. This is primarily achieved by verifying the application enforces known restrictions on inter-persona transfers. If the dynamic program analysis cannot be performed or is inconclusive, perform a static program analysis to assess if code is present that will support the application's ability to authenticate the source persona in such scenarios. If the dynamic program analysis and/or static program analysis conclude that the application does not authenticate the source persona when transferring data from one person to another, this is a finding.
Modify code to authenticate the source persona when data is transferred from one persona to another.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
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 application 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 application 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 application enforces the limitation. If the mobile application neither contains code to enforce the restriction nor can be demonstrated to enforce the organization defined restriction, this is a finding.
Modify the code to limit the ability to embed data types within other data types.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For mobile applications that support multiple personas, conduct a dynamic program analysis to assess the application's ability to detect and log all failed attempts to transfer data between security domains. Observe any on-screen messages and system logs that would reflect a failed attempt to transfer the data. If the dynamic program analysis cannot be performed or is inconclusive, perform a static program analysis to assess the application's ability to detect and log all failed attempts to transfer data between security domains. Search for code that supports the ability to force any on-screen messaging or create any log file that would reflect a failed attempt to transfer the data. If the dynamic or static program analysis concludes that no means are available to detect failed attempts of cross domain data transfer, this is a finding.
Modify code so the application records a log entry when there is a failed attempt to improperly transfer data from one domain to another.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
e requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a review of the application documentation to assess if the application design prevents the application from executing unsigned Category 1A mobile code. If the documentation review is inconclusive, conduct a dynamic program analysis of all major components of the application to assess if: - mobile code is in use and the mobile application will prompt to download the code. - at the download prompt, the application will indicate that code has been digitally signed. If the code has not been signed or the application warns that code cannot be invoked due to security settings, this is a finding. If the code has not been signed with a DoD approved PKI certificate, this is a finding. Definitions for mobile code categories can be found at http://iase.disa.mil/mcp/index.html
Modify the code so that the application does not execute unsigned DoD Mobile Code Policy Category 1A or 2 mobile code.
Perform a review of the application documentation to assess if the application design validates the signature on Category 1A and 2 mobile code. If the documentation review is inconclusive, conduct a dynamic program analysis to assess if code is available that performs the necessary functions required to validate all digital signatures. If the dynamic program analysis reveals the code does not validate digital signatures through a DoD approved PKI certificate, this is a finding. Definitions for mobile code categories can be found in DoD Instruction 8552.01.
Modify code so the application will verify DoD Mobile Code Policy Category 1A and 2 mobile code before executing it.
If the application does not download or interpret mobile code, this requirement is not applicable. Perform a static analysis of the code to assess of code is present that forces the application to access system resources external to the application. If the code review reveals the application executes mobile code that attempts to access local operating system resources or establish network connections to servers other than the application server, this is a finding.
Modify code so that DoD Mobile Code Policy Category 2 mobile code is unable to access resources not dedicated to the mobile application.
If the application does not download or interpret mobile code, this requirement is not applicable. Review the documents at http://iase.disa.mil/mcp/index.html which detail all mobile codes, categorized per DoD policy. Definitions for mobile code categories can be found at this site. Conduct a review of the application documentation and assess which mobile codes are present. Compare the two documents to assess if the application uses mobile code technologies or interpreters are present for such technologies not permitted by DoD policy. If the documentation review is inconclusive or cannot be carried out, perform a static code analysis and assess which mobile code technologies and/or interpreters are present in the application code. If the documentation and/or code review reveal that technologies and/or interpreters are present for code not permitted by DoD policy, this is a finding.
Remove uncategorized mobile code and interpreters for uncategorized mobile code.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Review the installation package and look for a digital signature. Assess if it identifies the developer. If no digital signature is available or if a signature is present but does not identify the developer, this is a finding.
Modify the application and the application's installation code to support identifying digital signatures.
For mobile applications that process digitally signed data or code, perform a dynamic program analysis that uses data or code with invalid signatures on it. The check should involve at least the following three invalid signature scenarios: expired certificate, revoked certificate, and certificate issued by cryptographically unrecognized certificate authority. If the dynamic program analysis reveals the code or data with invalid signatures is accepted and processed under any invalidity scenario, this is a finding.
Modify code to include digital signature validation.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
e requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
e requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a static program analysis to assess if the application hosts interprets that process mobile code. If this is not feasible, conduct a dynamic program analysis in conjunction with a protocol analyzer to determine if the mobile application downloads and executes mobile code, thereby providing evidence of an embedded interpreter. Also, check what type of mobile code is being downloaded to determine whether it is prohibited. If the source code contains an embedded interpreter that executes prohibited mobile code, this is a finding.
Modify the application architecture so it does not require embedded interpreters.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If both the mobile application and the MOS use the same time source (e.g., GPS), then it is not necessary for the mobile application to refer to the MOS system time, and this check is not applicable. Otherwise, perform a documentation review to assess if the mobile devices system time is used as the authoritative time source. If the documentation review is inconclusive, perform a static program analysis to assess if code exists that supports the application using the mobile device's internal clock as a source for all timing the application uses. If the application uses a different timing source other than the device's system time, this is a finding.
Modify code to use the device's system time for its authoritative time source, removing any code that uses other sources.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a static program analysis to determine if the mobile application code attempts to change the file permissions of files external to the operation of the mobile application. If this is not feasible, perform a dynamic program analysis to determine if routine installation and operation of the mobile application changes the permissions of any files other than those dedicated to the application. In order to complete this analysis, the permissions after operation of the mobile application 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 application can have their permission attributes modified by the application, this is a finding.
Modify the code so it does not change the file permission on any files not dedicated to the mobile application's operation.
If the MOS fulfills all of the mobile application's access control requirements, then this requirement is NA. Investigate the application's access control requirements. Identify requirements that are not addressed by the operating system. For each identified requirement, perform a dynamic program analysis to assess the ability of the application to automatically impose restrictions related to that requirement. Alternatively, perform a static analysis to verify appropriate automation exists for each of the indentified requirements. Automated enforcement includes any mechanism not based on user enforcement. If a user must type a password or present a biometric, this is still considered automated because the inability to access information without presenting these credentials is automated. If restrictions to data were based on user trust and not a technical mechanism, this would not be automated. If either the dynamic or static program analyses reveal that one or more requirements are not addressed through automated enforcement, this is a finding.
Modify code to implement automated enforcement of access control not provided by the operating system.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a documentation review to assess if the application supports other applications or non-privileged processes that enable the application the ability to modify software libraries. If the application functional requirements review cannot be carried out or is inconclusive perform a static program analysis to assess if code exists that invokes other applications or other non-privileged processes that enables them the ability to modify software libraries. If the application's functional requirements review and/or the static program analysis reveals the application can enable other applications, as well as permit privileged processes the ability to modify software libraries, this is a finding.
Modify the code or installation configuration files to limit an application's access to its software libraries to the application only.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
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.
Modify code to remove unused code, unused variables, and expressions whose logical state persists.
Perform a documentation review to assess all necessary ports, services, and protocols needed for the application's operation. Next conduct a static analysis to assess which ports are open, services used, and protocols available during the operation of the application. If a static analysis is not feasible, conduct a dynamic program analysis in conjunction with port scanning or protocol analysis to determine how the application 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 application is not in compliance with DoD Ports and Protocols guidance, this is a finding.
Modify code that the mobile application uses ports, protocols, and services in accordance with the DoD PPSM.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For mobile applications that are transaction based, perform a review of the application's documentation to assess if the application uses an on-board database, such as SQLite, Oracle9i Lite, Jdatastore, etc. Review the documentation to assess if the on-board databases support journaling and rollback. If the application's database does not support journaling or rollback or the application is unable to provide the same, this is a finding.
Implement rollback and journaling features in the application or incorporate products with rollback and journaling features.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a static program analysis, to assess the application's ability to lock or set file permissions that would prevent OS and other approved applications from performing copy and backup functions. If the application has the ability to set and lock file permissions, this is a finding.
Modify code so the MOS or approved backup application is not prevented from copying application files.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For mobile applications that manage wireless network connections for other devices, perform a documentation review to assess if the application uses encryption when managing other wireless connections for other devices. If the documentation review is inconclusive, perform a dynamic program analysis to assess if the application offers the user set up options or readily indicates encryption is present when managing other wireless connections for other devices. If the above tests are inconclusive, perform a static program analysis and assess if code is available that supports providing the user options for encryption when managing other wireless connections for other devices. If the documentation review, dynamic program analysis, or static program analysis reveals the application does not authenticate devices using bidirectional cryptographic authentication, this is a finding.
Modify code to support the use of bidirectional cryptographic authentication.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a documentation review to assess if the application is in compliance with DoD PPSM related guidance. If the documentation review was inconclusive, perform a dynamic program analysis to assess if the application will close ports after an application has terminated a session, or after an organizationally defined time period. This may include the use of port scanners or protocol analyzers. Next, perform a static program analysis to assess if code is present and able to be executed that scans the status of ports used by the application. The code must be able to identify all ports used and force a port closure following termination of the mobile application session. Termination of the application can be either through user action or an unexpected crash. Code must also be present that detects a period of user inactivity that will also force a closure of all ports. If the documentation, dynamic program analysis or static program analysis reveals that ports are not closed either automatically following a session's termination or following a predefined timeout period, this is a finding.
Modify code to close network ports when the application closes or after a period of inactivity.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If the mobile application is not involved in the production, control, and distribution of asymmetric cryptography keys, this IA control is not applicable. For mobile applications 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 application. If the documentation review is inconclusive, perform a static program analysis to assess the application 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.
Modify code to adopt the recommendation of NIST SP 800-57 for key management processes and technologies.
If the mobile application is not involved in the production, control, and distribution of asymmetric cryptography keys, this IA control is not applicable. For mobile applications 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 application. If the documentation review is inconclusive, perform a static program analysis to assess the application 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 NSA recommendations for key management are not used or enforced, this is a finding
Modify code to adopt the recommendation of NIST SP 800-57 for key management processes and technologies.
If the mobile application is not involved in the production, control, and distribution of asymmetric cryptography keys, this IA control is not applicable. For mobile applications 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 application. 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 application. If the dynamic program analysis could not be performed or the results were inconclusive, carry out a static program analysis to assess if the application supports functional code, able to execute routines and functions that enable the application 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 application is unable to or does not use approved PKI Class 3 certificates or prepositioned keying material, this is a finding.
Modify code and/or architecture of the application to ensure approved, Class 3 certificates or prepositioned keying material is used.
is 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 applications that are involved in the production, control, and distribution of asymmetric cryptographic keys, perform a documentation review to assess if the application employs use of approved Class 3 or 4 certificates in conjunction with hardware token. DoD CAC is a compliant solution. If the documentation review is inconclusive, perform a dynamic program analysis to assess if the application employs use of approved, Class 3 and 4 certificates in conjunction with a hardware token. If the documentation and/or review reveals that the application is unable to or does not use approved PKI Class 3 certificates or hardware tokens, this is a finding.
Modify code and/or architecture of the application to use approved Class 3 or 4 certificates in conjunction with a hardware token.
In the case of unclassified equipment, when the mobile application either runs on a mobile operating system with applicable FIPS 140-2 validated cryptographic modules or has its own native FIPS 140-2 validated cryptographic modules, then it is presumed to comply with all applicable federal laws, Executive Orders, directives, regulations, standards, and guidance. This check only applies when the reviewer has identified a specific requirement related to cryptographic protections beyond the FIPS 140-2 requirement. If there no such known additional requirements, there is no finding with respect to this potential vulnerability. Perform a review of the application's documentation to assess if the mobile application implements and uses required protections, using cryptographic modules per the identified legal and policy requirements. Refer to http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm for a list of approved cryptography devices. If the documentation review is unable to prove the application implements the required protections or is inconclusive, perform a static program analysis to assess if the application hosts code that is functional and able to be executed that uses cryptographic modules that protects in accordance with the requirements. If the documentation and or static program analysis reveals the application does not employ code in order to implement the necessary protections, this is a finding.
Modify code and architecture to ensure all protection in use or to be applied is in compliance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
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 application. If the application does not use cryptography to protect classified information, or does not use NSA approved cryptography for this purpose, this is a finding.
Modify code and architecture to ensure the application utilizes NSA-approved and validated cryptography for modules implementing encryption approved for classified information, key exchange, digital signature, and hash.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If the application does not contain security functions beyond those provided by the MOS, this requirement is not applicable. Perform a static analysis and assess if there is code present that checks for the presence and availability of required security functions which will then shut the application down. If the static analysis reveals that no code exists that checks for the presence and availability of required security functions which will then shut the application down, this is a finding.
Modify code to assure the application will shut down or perform an organization defined response action when one of its required security features is not available.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Perform a static program analysis of the application software to assess if security attributes are associated with data in transit. If the static analysis is not possible or inconclusive, perform a dynamic analysis to assess if the remote end receives security attributes. If the static analysis reveals that supporting code is not present, or if the dynamic analysis reveals security attributes are not received, this is a finding.
Modify code to associate security attributes with information exchanged between systems.
For mobile applications that transmit classified data, review the application documentation to assess if the application supports mechanisms assuring the integrity of transmitted labels and security parameters. If the documentation review is inconclusive or cannot be done, perform a dynamic program analysis of the application by logging in and assessing if there is support for integrity mechanisms that serve transmission of both incoming and outgoing labels and classification attributes. If the dynamic program analysis cannot be performed or is inconclusive, perform a static program analysis to assess if code is present that will provide support for integrity mechanisms that serve transmission of both incoming and outgoing labels and classification attributes. If the dynamic program analysis and static program analysis reveals the application does not support integrity mechanisms for any transmitted data or its labels and attributes, this is a finding.
Implement integrity mechanisms for transmission of both incoming and outgoing data labels and classification attributes.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
For applications that do not maintain a secure state at all times, perform a dynamic program analysis and perform transactions, so the application is in a state other than its initial state. Use OS controls to terminate the application or to create conditions that would force the application to terminate or crash. Restart the application and examine the application to determine if it is in its initial state. If it is not in its initial state, this is a finding.
Modify the code and architecture to ensure the application returns to a secure, initial state upon unexpected termination.
If the application fails to an initial state, then it is not required to preserve any state information. Otherwise, perform a static program analysis to determine if the code supports the preservation of state information at all times. If the code does not support the preservation of state information at all times, this is a finding.
Modify the code so that state information is preserved in the event of an application failure.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If the mobile OS on which the mobile application resides does not permit the application to share persistent memory, then the application is compliant with this IA control. If the above control is not available, perform a static program analysis to assess if the application ever modifies the permissions of files to enable other applications to read or modify the files. If the static program analysis reveals that the application grants permissions that enable the application to share its area of persistent memory with other applications or processes, this is a finding. If the static program analysis reveals that the application's persistent memory is not secured and can be addressed and used by other applications and processes that allow file permissions to be changed, this is a finding. When applicable, examine the file permissions of files created by the application. If they permit other applications to access the files, this is a finding.
Modify code and architecture to assure the application does not share its persistent memory allocation with other applications and processes and does not address areas of persistent memory used by other applications and processes.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If the application does not interpret XML, this requirement is not applicable. Perform a static program analysis to assess if code is present that will prevent XML injection attacks. Search for code that uses XML Schema Definition (XSD) Restrictions and XML Schema Regular Expressions which server to minimize XML injection attacks. If the static program analysis reveals there is no code that protects the application from XML injection attacks, this is a finding. Examples of XML injection vulnerabilities can be obtained from the OWASP at https://www.owasp.org
Modify code to correct XML injection flaws.
Review the application documentation for the test plans, and determine if testing was performed for invalid input. Invalid input includes presence of scripting tags within text fields, query string manipulation, and invalid data types and sizes. If the test plans indicate these types of tests were performed, only a small sampling of testing is required. If the test plans do not exist or do not indicate that these types of tests were performed, more detailed testing is required. Perform a dynamic program analysis by fuzzing all user inputs of the application by providing invalid, unexpected, or random data to the inputs. Test the application for invalid sizes and types. Test input and try to exceed buffer limits on the input fields. Try to put wrong types of data in the input fields. For example, put character data in a numeric field. If the application requires the entry of IP addresses as an example, and is not capable of handling IPv6 Formats that are 128 bits long, this is finding. If the application is not capable of handling IPv6 formats and accepts characters that are of hexadecimal notation including colons, this is a finding. Perform a static analysis to assess if code is present that when executed, checks input data for validation against defined constraints. If no input validation code is present, this is a finding.
Modify code so that the application validates all input.
For mobile applications that accept character data, perform a static program analysis on the application by checking for the declaration of the character set. Next, perform a dynamic program analysis and test the application for invalid sizes and types. Test input and try to exceed buffer limits on the input fields. Try to put wrong types of data in the input fields. For example, put character data in a numeric field. If the static analysis reveals no character set was declared, this is a finding. If the dynamic analysis reveals invalid input is not rejected, such as numbers being accepted where only alpha characters are required, this is a finding. As a further example, If the application requires the entry of IP addresses is not capable of handling IPv6 formats that are 128 bits long, this is a finding. If the application is not capable of handling IPv6 formats and accepts characters that are of hexadecimal notation including colons, this is a finding.
Modify the code to fix the character set for the application.
Review the application documentation for static program analysis or scan results from the entire application. This can be provided as results from an automated static program analysis or a vulnerability scanning tool. If the documentation review is inconclusive or testing results are not available, perform a static program analysis to assess if code is present that manages the vulnerabilities associated with input string formatting. If the documentation review and/or static program analysis reveal that the application does not validate input string formats, this is a finding. Examples of format string vulnerabilities can be seen on the OWASP website. https://www.owasp.org
Remove format string vulnerabilities from the code.
For mobile applications that run on a mobile operating system that does not support command shells, then the mobile application is compliant. Perform a documentation review and assess if the application was tested for command injection vulnerabilities and if results from a static program analysis or a vulnerability scanning tool are included. If the documentation review is unavailable or inconclusive, perform a dynamic program analysis by injecting commands through an input and assess the results. If the documentation review reveals that no test results are available for command injection vulnerabilities, or if the dynamic program analysis reveals the code cannot identify command injection vulnerabilities, this is a finding. Examples of format string vulnerabilities can be seen on the OWASP website. https://www.owasp.org
Modify the code to remove command injection attack vulnerabilities.
This IA control does not apply when the SQL database resides on a remote system. In that case, SQL must be controlled on the remote system, not the remote device. If the application uses a local SQL database, perform a dynamic program analysis to assess if the application is vulnerable to SQL injection by performing the following. Fill in login and other input fields with potentially valid user names (e.g., admin, system, root, and administrator) with a comment field to ignore the rest of the SQL query. Also, fill in the password fields with any values and submit the form. username' -- username' # username'/* ' or 1=1-- ' or 1=1# ' or 1=1/* ') or 1=1-- ') or 1=1# ') or 1=1/* If the dynamic program analysis reveals that the application bypasses user authentication with these inputs or provides an authenticated user access or elevated access to the application to data, this is a finding. In addition to the above dynamic program analysis, review application documentation or interview the application representative and request a demonstration for how the application: - uses prepared statements for SQL queries. - does not provide direct access to tables (e.g., access is provided by views and stored procedures). - does not use concatenation or use replacement to build SQL queries. Next, perform a static program analysis to assess how the application does exactly what is listed above. If the static program analysis cannot provide results or the application representative cannot demonstrate the application uses prepared statements for SQL queries, this is a finding. If the static program analysis cannot provide results or the application representative cannot demonstrate the application does not use concatenation or use replacement to build SQL queries, this is a finding. If the static program analysis cannot provide results or the application representative cannot demonstrate the application does not directly accesses tables in a database, this is a finding.
Modify the source code to remove SQL injection vulnerabilities.
This requirement is NA for the MAPP SRG.
e requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
e requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If the operating system encrypts all data in transit or the mobile application leverages a VPN client that encrypts all data in transit, then the mobile application is compliant and the requirement not applicable. Perform a dynamic program analysis with a protocol analyzer to determine if the application is protecting data in transit. If the data in transit is not encrypted, this is a finding.
Configure the application or leverage OS or other applications that provide protection of data in transit. Otherwise modify the code to provide such protections.
The reviewer is only required to check whether the mobile application identifies improper inputs, unless there are specific known error conditions that require additional investigation. Perform a dynamic program analysis by fuzzing all user inputs of the application by providing invalid, unexpected, or random data to the inputs. Test the application for invalid sizes and types. Test input and try to exceed buffer limits on the input fields. Try to put wrong types of data in the input fields. For example, put character data in a numeric field. If the application requires the entry of IP addresses as an example, and is not capable of handling IPv6 Formats that are 128 bits long, this is finding. If the application is not capable of handling IPv6 formats and accepts characters that are of hexadecimal notation including colons, this is a finding. Perform a static analysis to assess if code is present that when executed, checks input data for validation against defined constraints. If no input validation code is present, this is a finding.
Modify code to identify potentially-relevant error conditions.
Perform a dynamic program analysis to assess if the user's credentials or application code and structure, and internal workings that could be exploited are contained in error reporting messages as follows: - login to the application - create an error condition using incorrect input - observe any error messages that result - assess above error message for any authentication credential. If the dynamic program analysis reveals error messages contain user credentials, this is a finding.
Modify code for logging functions to exclude sensitive information not necessary for IA functions from being written to the logs.
Perform a static program analysis to assess if any errors are transmitted to any other entity other than audit logs, the MDM, or user display. Do the following: - launch the application - create an error condition using incorrect input - observe any error messages that result on screen - observe where any log files containing error messages are stored. If the static program analysis reveals that error messages are sent to an entity other than a user defined audit log, the MDM, or the device screen, this is a finding.
Modify code to send error messages to MOS audit logs, the MDM or the device display.
Perform a static program analysis to assess if the application sends an alert to either the MOS or MDM upon the failure of an application component. This alert may consist of an entry in the MOS logs. Moreover, it is acceptable to alert the MDM via the OS logs, if the MDM is configured to obtain the logs on a periodic basis. The testing must force a condition where each component that forms the application is purposely failed. If the application does not alert the MOS of a component failure, this is a finding.
Modify code to alert the MOS when an application component fails.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
If an application does not include its own automated security tests, then this check does not apply. If the application documentation or website does not describe an automated security test, it can be presumed that one does not exist. For applications that have their own, automated security tests, perform a dynamic program analysis to assess if the application sends an alert or notification to either the MOS logs, the MDM, or the user upon the failure of an automated security test. The testing must force a condition where an application's security test is purposely failed. If the application does not alert the OS, MDM, or the user of an automated security test failure, this is a finding.
Modify code to send a notification to the MOS logs, MDM, or user when an application fails an automated security test.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
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 a local application resources such as a configuration file, this is a finding.
Remove hardcoded resource references from the application code.
Perform a dynamic program analysis by launching the application and checking to see if it stores any temporary files. Close the application. If any of these temporary files remain in persistent memory, this is a finding. If memory is not released and the application is not using garbage collection process for memory (e.g., Java Applications), this is a finding. Re-launch the application to perform selected actions that will knowingly generate temporary files. Exit the application, and then search for temporary files that are not being deleted by the application. If files generated during the application’s session were not deleted, this is a finding.
Modify code to remove all temporary files whenever the application is terminated.
If the application does not contain sensitive or classified information this check is not applicable. Furthermore, if the MOS on which the application runs clears memory whenever an application releases memory, this check is not applicable. Otherwise, perform a dynamic program analysis of the application and assess how memory blocks are cleared of sensitive or classified data. This will likely require the use of a MOS emulator. If the application releases memory blocks before clearing them, this is a finding.
Modify code to clear memory blocks used for storing sensitive and classified data before the memory is released to other processes.
Determine if the application uses cookies or otherwise saves information used to track a user's identity. Perform a dynamic program analysis by launching the application 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 application 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.
Configure or redesign the application to remove cookies or other information used to track the user's identity before the application exits.
If an application does not take any numeric inputs, this IA control is not applicable. Perform a static program analysis and assess the application 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.
Modify code to reflect the following measures that will remove integer arithmetic vulnerabilities from the application 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.
Perform a static program analysis to assess how the application 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 application. 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 applications, 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.
Modify 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.
Review the documentation to assess if the following two issues are documented: - Access control decisions based upon a resource name. - Failure to reduce a resource name to its canonical form before use. If the documentation review is inconclusive, perform a static program analysis to assess if the above two issues hold the potential to manifest. If the documentation review and/or the static analysis reveal canonical representation vulnerabilities are identified, this is a finding. Examples of Canonical Representation vulnerabilities can be obtained from the OWASP website. See https://www.owasp.org.
Modify code so access to resources is not based solely on the name of the resource. The following measures can be applied as appropriate: In order to minimize canonical representation issues in the application, implement the following procedures: - Do not rely solely on resource names to control access. - If using resource names to control access, validate the names to ensure they are in the proper format; reject all names not fitting the known-good criteria. - Use operating system-based access control mechanisms, such as permissions and ACLs.
If the application does not use multiple threads or if it runs on a MOS that does not support multiple threads, then is IA control is not applicable. If the operating system is not multi-threaded, or never runs more than one application 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 application manages and is designed around the following items: - Race conditions. - Using global variables when local variables could be used. - Multi-threaded application 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 application 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 application design is reasonably likely to result in a race condition, this is a finding.
Remove race conditions from the code.
Perform a dynamic program analysis to assess if the application, upon startup initializes all parameter values the application uses. If the dynamic program analysis identifies any parameter value that is not initialized on startup, this is a finding.
Modify code to ensure upon starting, the application initializes all parameter values.
Perform a static program analysis to determine if the application 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 application 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.
Remove code that records or forwards sensor data or cease using the mobile application.
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 regards to its digital signatures and the algorithms used, this is a finding.
Digitally sign the application package using FIPS 186-3 approved methods.
This requirement is NA for the MAPP SRG.
The requirement is NA. No fix is required.
Scan the application 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 application malware will suffice. If the tool identifies any instance of known malware, this is a finding.
Remove known malware from the application code.