Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

Mobile Application Security Requirements Guide

V1R1 · · · Released 13 Dec 2012 · 314 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

The 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.
Sort by
b
The application must be able to define the maximum number of concurrent sessions for an application account globally, by account type, by account, or a combination thereof.
AC-10 - Medium - CCI-000054 - V-35072 - SV-46339r1_rule
RMF Control
AC-10
Severity
M
CCI
CCI-000054
Version
SRG-APP-000001-MAPP-NA
Vuln IDs
  • V-35072
Rule IDs
  • SV-46339r1_rule
A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. When the application design specifies the application rather than the operating system will determine when to lock the session, the application session lock event must include an obfuscation of the display screen so as to prevent other users from reading what was previously displayed. An example of obfuscation is a screensaver creating a viewable pattern that overwrites the entire screen rendering the screen contents unreadable. Rationale for non-applicability: This control is required in the MOS SRG. A user may lock a session by locking the device. Permitting a mobile application to obfuscate the screen independently from the operating system control would make the operating system and other applications vulnerable to a Denial of Service (DoS) attack.
Checks: C-43461r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39624r1_fix

The requirement is NA. No fix is required.

b
The application must ensure that the screen display is obfuscated when an application session lock event occurs.
AC-11 - Medium - CCI-000060 - V-35075 - SV-46343r1_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000060
Version
SRG-APP-000002-MAPP-NA
Vuln IDs
  • V-35075
Rule IDs
  • SV-46343r1_rule
A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. When the application design specifies the application rather than the operating system will determine when to lock the session, the application session lock event must include an obfuscation of the display screen so as to prevent other users from reading what was previously displayed. An example of obfuscation is a screensaver creating a viewable pattern that overwrites the entire screen rendering the screen contents unreadable. Rationale for non-applicability: This control is required in the MOS SRG. A user may lock a session by locking the device. Permitting a mobile application to obfuscate the screen independently from the operating system control would make the operating system and other applications vulnerable to a Denial of Service (DoS) attack.
Checks: C-43462r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39626r1_fix

The requirement is NA. No fix is required.

b
The application must support the requirement to initiate a session lock after an organization defined time period of system or application inactivity has transpired.
AC-11 - Medium - CCI-000057 - V-35076 - SV-46348r1_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000057
Version
SRG-APP-000003-MAPP-NA
Vuln IDs
  • V-35076
Rule IDs
  • SV-46348r1_rule
A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their application session prior to vacating the vicinity, applications need to be able to identify when a users' application session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled. This is typically at the operating system-level and results in a system lock, but may be at the application-level where the application interface window is secured instead. The organization defines the period of inactivity that shall pass before a session lock is initiated so this must be configurable. Rationale for non-applicability: This control is required in the MOS SRG. The operating system will lock the device after a specified period of inactivity. Permitting a mobile application to lock the device independently from the operating system control would make the operating system and other applications vulnerable to a DoS attack.
Checks: C-43463r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39627r1_fix

The requirement is NA. No fix is required.

b
Applications must ensure that users can directly initiate session lock mechanisms which prevent further access to the system.
AC-11 - Medium - CCI-000058 - V-35077 - SV-46350r1_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000058
Version
SRG-APP-000004-MAPP-NA
Vuln IDs
  • V-35077
Rule IDs
  • SV-46350r1_rule
A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. Rather than be forced to wait for a period of time to expire before the user session can be locked, applications need to provide users with the ability to manually invoke a session lock so users may secure their application should the need arise for them to temporarily vacate the immediate physical vicinity. Rationale for non-applicability: This control is required in the MOS SRG. The mobile operating system is best positioned to handle user requests to lock access to the system. If an application were able to directly prevent further access to the system, this would be a DoS vulnerability for other applications on the device.
Checks: C-43464r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39628r1_fix

The requirement is NA. No fix is required.

b
The application must have the ability to retain a session lock remaining in effect until the user re-authenticates using established identification and authentication procedures.
AC-11 - Medium - CCI-000056 - V-35078 - SV-46358r1_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000056
Version
SRG-APP-000005-MAPP-NA
Vuln IDs
  • V-35078
Rule IDs
  • SV-46358r1_rule
A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically determined and performed at the operating system-level, but in some instances it may be at the application-level. Regardless of where the session lock is determined and implemented, once invoked the session lock shall remain in place until the user re-authenticates. No other system or application activity aside from re-authentication shall unlock the system. Rationale for non-applicability: This control is required in the MOS SRG. If the mobile application accesses a remote enterprise application, the remote application can require re-authentication as needed.
Checks: C-43465r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39629r1_fix

The requirement is NA. No fix is required.

c
The mobile application must store an associated data attribute corresponding to the highest classification of data in the file it stores classified data.
AC-16 - High - CCI-001399 - V-35083 - SV-46370r1_rule
RMF Control
AC-16
Severity
H
CCI
CCI-001399
Version
SRG-APP-000006-MAPP-00001
Vuln IDs
  • V-35083
Rule IDs
  • SV-46370r1_rule
A classification attribute assures the data is correctly handled and processed according to its sensitivity. If the classification attribute is missing, then there is risk to data misclassification which could result in a data spill. This control greatly reduces the risk of misclassification that can result in data leaks and spillage.
Checks: C-43470r1_chk

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.

Fix: F-39634r1_fix

Modify code to enable the creation and storage of a highest data classification attribute.

c
The mobile application must not permit any classification attribute to be modified to a lower level of classification if it processes classified data.
AC-16 - High - CCI-001400 - V-35084 - SV-46371r1_rule
RMF Control
AC-16
Severity
H
CCI
CCI-001400
Version
SRG-APP-000007-MAPP-00002
Vuln IDs
  • V-35084
Rule IDs
  • SV-46371r1_rule
A classification attribute assures the data is correctly handled and processed according to its sensitivity. If the classification attribute can be modified, then there is a risk to misclassification of the data resulting in a data spill. This control greatly reduces the risk of unauthorized downward classification of sensitive data that could result in the data being inadvertently combined with non-sensitive data, creating a data spill.
Checks: C-43471r1_chk

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.

Fix: F-39635r1_fix

Modify code and functionality that prohibits an application from reclassifying the data downwardly.

c
The mobile application must include classification attributes with transmitted data if it transmits classified data.
AC-16 - High - CCI-001401 - V-35085 - SV-46372r1_rule
RMF Control
AC-16
Severity
H
CCI
CCI-001401
Version
SRG-APP-000008-MAPP-00003
Vuln IDs
  • V-35085
Rule IDs
  • SV-46372r1_rule
A classification attribute assures the data is correctly handled and processed according to its sensitivity when it is transmitted. Transmitted data is vulnerable to exposure through incorrect labeling if its classification attribute is not transmitted with it, and when it is received and processed. This control assures the data is handled accordingly regarding its classification during transmission and subsequent distribution, greatly reducing the risk of misclassification and the eventual spill that may occur.
Checks: C-43472r1_chk

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.

Fix: F-39636r1_fix

Modify code to include data classification attributes with transmitted data.

b
The mobile application must assign a classification attribute to any newly created data file or stream if it stores, processes, or transmits classified data.
AC-16 - Medium - CCI-001424 - V-35086 - SV-46373r1_rule
RMF Control
AC-16
Severity
M
CCI
CCI-001424
Version
SRG-APP-000009-MAPP-00004
Vuln IDs
  • V-35086
Rule IDs
  • SV-46373r1_rule
A classification attribute assures the data is correctly stored, transmitted, handled, and processed according to its sensitivity. Stored, processed, or transmitted data is vulnerable to exposure through incorrect labeling if its classification attribute is not transmitted with it. Implementing this control assures the data is handled accordingly regarding its classification during transmission and subsequent distribution, greatly reducing the risk of misclassification and data spills.
Checks: C-43473r1_chk

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.

Fix: F-39637r1_fix

Modify code to assign a classification attribute to any newly created data file or stream when the application stores, processes, or transmits classified data.

c
The mobile application must assign the classification corresponding to the highest classification of its elements whenever it combines data elements classified at multiple levels.
AC-16 - High - CCI-001424 - V-35087 - SV-46374r1_rule
RMF Control
AC-16
Severity
H
CCI
CCI-001424
Version
SRG-APP-000009-MAPP-00005
Vuln IDs
  • V-35087
Rule IDs
  • SV-46374r1_rule
A classification attribute assures the data is correctly handled and processed according to its sensitivity. Data of mixed classification is vulnerable to accidental exposure if it is combined with several other data elements and not properly reclassified. This control greatly reduces the risk of misclassification when data of multiple classifications are combined.
Checks: C-43474r1_chk

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.

Fix: F-39638r1_fix

Modify code to ensure the application assigns the highest classification of the combination's elements to the classification attribute of the combination whole.

b
The application must provide the capability to specify administrative users and grant them the right to change application security attributes pertaining to application data.
AC-16 - Medium - CCI-001425 - V-35093 - SV-46380r1_rule
RMF Control
AC-16
Severity
M
CCI
CCI-001425
Version
SRG-APP-000010-MAPP-NA
Vuln IDs
  • V-35093
Rule IDs
  • SV-46380r1_rule
Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. Security attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy. Organizations define the security attributes of their data. (e.g., classified, FOUO, sensitive). Changing security attributes within an application is usually performed by a person or persons who have been delegated the task and the associated responsibilities accorded to application administrative personnel. Applications creating and/or assigning security attributes to data must have the flexibility to allow authorized staff to change these security attributes. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not have administrative users.
Checks: C-43481r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39645r1_fix

The requirement is NA. No fix is required.

b
The mobile application must 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 if it transmits classified data.
AC-16 - Medium - CCI-001426 - V-35095 - SV-46382r1_rule
RMF Control
AC-16
Severity
M
CCI
CCI-001426
Version
SRG-APP-000011-MAPP-00006
Vuln IDs
  • V-35095
Rule IDs
  • SV-46382r1_rule
Losing a data classification attribute bind or using a weak bind offers a very high potential for this data to be misclassified once it has been received and further distributed as a result of its non classification. If the bind is weak, an adversary could modify it. If the bind is either weak or not present, the potential for sensitive data being inadvertently blended with non-classified data is very high. This control ensures a data classification attribute is strongly bound to the data during transmission so its subsequent processing assures the data is correctly handled according to its sensitivity.
Checks: C-43483r1_chk

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.

Fix: F-39647r1_fix

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.

b
The mobile application must enable the user of the mobile device to assign a classification level to any data the user creates while using the mobile device, unless the application concept of operations requires that all data be handled at a single classification level.
AC-16 - Medium - CCI-001427 - V-35097 - SV-46384r1_rule
RMF Control
AC-16
Severity
M
CCI
CCI-001427
Version
SRG-APP-000012-MAPP-00007
Vuln IDs
  • V-35097
Rule IDs
  • SV-46384r1_rule
Data at rest or data in transit is at risk to exposure if improperly classified; IA controls not in place as a result of incorrect or non-labeling can result in non-secure transmission and storage of sensitive data. Data that has no classification level assigned to it can be misclassified or improperly handled when it is used or once it is forwarded. In some cases, it is possible that users can upwardly reclassify data in order to ensure correct handling of the data. Implementing this control prevents inadvertent use of or misclassification of data when the system is operating at one or more level of classification.
Checks: C-43485r1_chk

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.

Fix: F-39649r1_fix

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.

b
The mobile application must display the classification of the data in human readable form whenever it displays any data to the user of the mobile device if it processes, stores, or transmits classified data.
AC-16 - Medium - CCI-001428 - V-35100 - SV-46387r1_rule
RMF Control
AC-16
Severity
M
CCI
CCI-001428
Version
SRG-APP-000013-MAPP-00008
Vuln IDs
  • V-35100
Rule IDs
  • SV-46387r1_rule
Unlabeled, sensitive data could easily be mixed with unclassified data and misclassified data could be transmitted on a no secure network. Unless the application informs the user of the sensitivity of any data he or she is working with, then the potential exists for a data spillage. This control assures the user is fully aware of the data's classification which provides greater assurance against it being misclassified and incorrectly handled.
Checks: C-43488r1_chk

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.

Fix: F-39652r1_fix

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.

b
Applications providing remote access capabilities must utilize approved cryptography to protect the confidentiality of remote access sessions.
AC-17 - Medium - CCI-000068 - V-35106 - SV-46393r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
SRG-APP-000014-MAPP-NA
Vuln IDs
  • V-35106
Rule IDs
  • SV-46393r1_rule
Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over either the public Internet or the Public Switched Telephone Network (PSTN). Since neither of these internetworking mechanisms are private nor secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Cryptography provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of confidentiality. The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection. Rationale for non-applicability: Remote access applications are not within the scope of this SRG. In general, remote access to the mobile device is most appropriately controlled by the operating system, not third party applications. Applications supporting remote access to the mobile device are not permitted on DoD CMD, with the exception of native OS support for personal hotspots and USB tethering that is compliant with the MOS SRG. The SRG scope also does not cover applications which include plug-in or portable code that will make the application: (i) support multiple users; (ii) enable remote user access or administration; and (iii) provide network or application services to other nodes.
Checks: C-43494r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39658r1_fix

The requirement is NA. No fix is required.

b
Applications providing remote access connectivity must use cryptography to protect the integrity of the remote access session.
AC-17 - Medium - CCI-001453 - V-35110 - SV-46397r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
SRG-APP-000015-MAPP-NA
Vuln IDs
  • V-35110
Rule IDs
  • SV-46397r1_rule
Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over the public Internet, the Public Switched Telephone Network (PSTN) or sometimes both. Since neither of these internetworking mechanisms are private nor secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and potentially modified. Cryptography provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of integrity. The encryption strength of mechanism is selected based on the security categorization of the information that is traversing the remote connection. Rationale for non-applicability: Remote access applications are not within the scope of this SRG. In general, remote access to the mobile device is most appropriately controlled by the operating system, not third party applications. Applications supporting remote access to the mobile device are not permitted on DoD CMD, with the exception of native OS support for personal hotspots and USB tethering that is compliant with the MOS SRG. The SRG scope also does not cover applications which include plug-in or portable code that will make the application: (i) support multiple users; (ii) enable remote user access or administration; and (iii) provide network or application services to other nodes.
Checks: C-43498r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39662r1_fix

The requirement is NA. No fix is required.

b
The application must employ automated mechanisms to facilitate the monitoring and control of remote access methods.
AC-17 - Medium - CCI-000067 - V-35111 - SV-46398r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000067
Version
SRG-APP-000016-MAPP-NA
Vuln IDs
  • V-35111
Rule IDs
  • SV-46398r1_rule
Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will occur over the public Internet. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to audit user activities on a variety of information system components (e.g., servers, workstations, notebook/laptop computers) and to ensure compliance with remote access policy. Remote access applications, such as those providing remote access to network devices and information systems and are individually configured with no monitoring or automation capabilities, increase risk and makes remote user access management difficult at best. Applications providing remote access capability need to provide the ability to automatically monitor and control remote user sessions. This includes the capability to directly trigger actions based on user activity or past information and/or data to a separate application or entity that can then perform automated tasks based on the information. Rationale for non-applicability: Mobile applications that support remote access to the mobile device are outside the scope of this SRG. Applications supporting remote access to the mobile device are not permitted on DoD CMD, with the exception of native OS support for personal hotspots and USB tethering that is compliant with the MOS SRG. The SRG scope also does not cover applications which include plug-in or portable code that will make the application: (i) support multiple users; (ii) enable remote user access or administration; and (iii) provide network or application services to other nodes.
Checks: C-43499r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39663r1_fix

The requirement is NA. No fix is required.

b
Applications providing remote access must have capabilities that allow all remote access to be routed through managed access control points.
AC-17 - Medium - CCI-000069 - V-35113 - SV-46400r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000069
Version
SRG-APP-000017-MAPP-NA
Vuln IDs
  • V-35113
Rule IDs
  • SV-46400r1_rule
This requirement relates to the use of applications providing remote access services. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over either the public Internet or the Public Switched Telephone Network (PSTN). Please note, utilization of a virtual private network when adequately provisioned with appropriate security controls, is considered an internal network and is not considered remote access. Without centralized control of inbound connections, management of these access points is difficult at best. It is critical that applications providing or offering remote access capabilities also have the capability to route the access through managed access control points. One example is the use of software applications, such as PCAnywhere or Terminal Services. Rather than having PCAnywhere installed on multiple systems, remote access software must have the capability to be centrally managed and controlled so there are not multiple disparate access points into the environment. Applications providing remote access must have capabilities that allow all remote access to be routed through managed access control points. Rationale for non-applicability: Mobile applications that support remote access to the mobile device are outside the scope of this SRG. Applications supporting remote access to the mobile device are not permitted on DoD CMD, with the exception of native OS support for personal hotspots and USB tethering that is compliant with the MOS SRG.
Checks: C-43501r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39665r1_fix

The requirement is NA. No fix is required.

b
The application must monitor for unauthorized remote connections to the information system on an organization-defined frequency.
AC-17 - Medium - CCI-000071 - V-35115 - SV-46402r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000071
Version
SRG-APP-000018-MAPP-NA
Vuln IDs
  • V-35115
Rule IDs
  • SV-46402r1_rule
Organizations need to monitor for unauthorized remote access connections to information systems in order to determine if break-in attempts or other unauthorized activity is occurring. There are already other SRG requirements for applications to generate audit connection logs to record connection activity. It is for the organization to determine which of those audited connections is unauthorized. This task is usually handled by the IDS, log alarming or some other security mechanism specifically designed to automate and address this requirement. This requirement is NA for applications not designed to monitor for unauthorized remote connections to information systems. Applications designed to meet this requirement must be able to do so on an organization defined frequency. Rationale for non-applicability: Mobile applications that support remote access to the mobile device are outside the scope of this SRG. Applications supporting remote access to the mobile device are not permitted on DoD CMD, with the exception of native OS support for personal hotspots and USB tethering that is compliant with the MOS SRG. The SRG scope also does not cover applications which include plug-in or portable code that will make the application: (i) support multiple users; (ii) enable remote user access or administration; and (iii) provide network or application services to other nodes.
Checks: C-43502r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39666r1_fix

The requirement is NA. No fix is required.

b
The application must ensure remote sessions for accessing an organization-defined list of security functions and security-relevant information are audited.
AC-17 - Medium - CCI-001454 - V-35119 - SV-46406r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001454
Version
SRG-APP-000019-MAPP-NA
Vuln IDs
  • V-35119
Rule IDs
  • SV-46406r1_rule
Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network and system access is accomplished by leveraging common communication protocols to establish a remote connection. These connections will typically originate over either the public Internet or the Public Switched Telephone Network (PSTN). Neither of these internetworking mechanisms is private or secure and they do not by default restrict access to networked resources once connectivity is established. Numerous best practices are employed to protect remote connections, such as utilizing encryption to protect data sessions and firewalls to restrict and control network connectivity. In addition to these protections, auditing must also be utilized in order to track system activity, assist in diagnosing system issues and provide evidence needed for forensic investigations post security incident. When organizations define security related application functions or security-related application information, it is incumbent upon the application providing access to that data to ensure auditing of remote connectivity to those resources occurs in support of organizational requirements. Remote access to security functions (e.g., user management, audit log management, etc.) and security relevant information requires the activity be audited by the organization. Any application providing remote access must support organizational requirements to audit access or organization defined security functions and security-relevant information. Rationale for non-applicability: Mobile applications that support remote access are outside the scope of this SRG. Applications supporting remote access are not permitted on DoD CMD. The SRG scope also does not cover applications which include plug-in or portable code that will make the application: (i) support multiple users; (ii) enable remote user access or administration; and (iii) provide network or application services to other nodes.
Checks: C-43507r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39671r1_fix

The requirement is NA. No fix is required.

b
Applications must support the capability to disable network protocols deemed by the organization to be nonsecure except for explicitly identified components in support of specific operational requirements.
AC-17 - Medium - CCI-001436 - V-35122 - SV-46409r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001436
Version
SRG-APP-000020-MAPP-NA
Vuln IDs
  • V-35122
Rule IDs
  • SV-46409r1_rule
This control is related to remote access but more specifically to the networking protocols allowing systems to communicate. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Some networking protocols allowing remote access may not meet security requirements to protect data and components. Bluetooth and peer-to-peer networking are examples of less than secure networking protocols. The DoD Ports, Protocols, and Services Management (PPSM) program provides implementation guidance on the use of IP protocols and application and data services traversing the DoD Networks in a manner supporting net-centric operations. Applications implementing or utilizing remote access network protocols need to ensure the application is developed and implemented in accordance with the PPSM requirements. In situations where it has been determined that specific operational requirements outweigh the risks of enabling an insecure network protocol, the organization may pursue a risk acceptance. Rationale for non-applicability: Mobile applications are not expected to have the capability to disable network protocols. If a network protocol is deemed by the organization to be insecure, it must be rewritten and reissued with secure communications protocols. The mobile operating system and Mobile Device Management (MDM) can disable applications that use insecure protocols.
Checks: C-43510r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39674r1_fix

The requirement is NA. No fix is required.

b
The application must monitor for unauthorized connections of mobile devices to organizational information systems.
AC-19 - Medium - CCI-000085 - V-35124 - SV-46411r1_rule
RMF Control
AC-19
Severity
M
CCI
CCI-000085
Version
SRG-APP-000021-MAPP-NA
Vuln IDs
  • V-35124
Rule IDs
  • SV-46411r1_rule
Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). Organization-controlled mobile devices include those devices for which the organization has the authority to specify and the ability to enforce specific security requirements. Usage restrictions and implementation guidance related to mobile devices include, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). In order to detect unauthorized mobile device connections, organizations must first identify and document what mobile devices are authorized. Monitoring for unauthorized connections is usually handled by configuration management software, log alarming, IDS, or some other security mechanism specifically designed to automate and address this requirement. This requirement is NA for applications not designed to monitor for unauthorized connections to information systems. Applications designed to meet this requirement must be able to do so according to organizational usage restrictions and policy. Rationale for non-applicability: Mobile applications that support remote access are outside the scope of this SRG. Apps supporting remote access are not permitted on DoD CMD.
Checks: C-43512r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39676r1_fix

The requirement is NA. No fix is required.

b
The mobile application must not permit execution of code without user direction unless the code is sourced from an organization-defined list of approved network resources.
AC-19 - Medium - CCI-000087 - V-35126 - SV-46413r1_rule
RMF Control
AC-19
Severity
M
CCI
CCI-000087
Version
SRG-APP-000022-MAPP-00009
Vuln IDs
  • V-35126
Rule IDs
  • SV-46413r1_rule
Unapproved and thus untrusted code presents a very high risk for malicious action by network and device intruders. Some mobile applications enable adware and other real time execution of code. If the mobile application executes code that was not installed when the application was installed, then that code has not been reviewed as part of the application certification process, which scans for known malicious code among other vulnerabilities. In this situation, it is more likely that malicious code may run on the mobile device. Execution of malicious code may compromise sensitive DoD data or potentially cause a privilege elevation that might enable subsequent attacks. There are several ways to mitigate this risk. First, if the user explicitly authorizes exceptions, the user may be able to stop unauthorized execution. Second, if the mobile application authenticates the code, at least the code has been shown to come from a known source. This control protects the user from code that cannot be trusted and exhibits the potential to compromise the device, application, network, and all stored data. Please refer to CWEs: 250, 265, 272, and 284 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-43513r1_chk

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.

Fix: F-39677r1_fix

Modify code to prevent execution of code non DoD-approved without user direction.

b
Applications must provide automated mechanisms for supporting user account management. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure providing automated account management.
AC-2 - Medium - CCI-000015 - V-35130 - SV-46417r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000015
Version
SRG-APP-000023-MAPP-NA
Vuln IDs
  • V-35130
Rule IDs
  • SV-46417r1_rule
A comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in non-centralized account stores, such as multiple servers. Enterprise environments make application user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight. Automated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organizations automated account management requirements. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management. If the mobile application supports multiple user accounts, then it must be evaluated against the full Core Application SRG.
Checks: C-43518r2_chk

This requirement is NA for the MAPP SRG.

Fix: F-39682r2_fix

The requirement is NA. No fix is required.

b
The application must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period.
AC-2 - Medium - CCI-000016 - V-35145 - SV-46432r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000016
Version
SRG-APP-000024-MAPP-NA
Vuln IDs
  • V-35145
Rule IDs
  • SV-46432r1_rule
Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. To address this, in the event temporary application accounts are required, the application must ensure that accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management, whether during an application's installation or at run time. Therefore, no temporary accounts are created or maintained to install a mobile application.
Checks: C-43531r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39695r1_fix

The requirement is NA. No fix is required.

b
The application must be capable of automatically disabling accounts after a 35 day period of account inactivity.
AC-2 - Medium - CCI-000017 - V-35146 - SV-46433r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000017
Version
SRG-APP-000025-MAPP-NA
Vuln IDs
  • V-35146
Rule IDs
  • SV-46433r1_rule
Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track periods of user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43532r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39696r1_fix

The requirement is NA. No fix is required.

b
Applications must support the requirement to automatically audit account creation.
Medium - V-35147 - SV-46434r1_rule
RMF Control
Severity
M
CCI
Version
SRG-APP-000026-MAPP-NA
Vuln IDs
  • V-35147
Rule IDs
  • SV-46434r1_rule
Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43533r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39697r1_fix

The requirement is NA. No fix is required.

b
Applications must support the requirement to automatically audit account modification.
AC-2 - Medium - CCI-001403 - V-35149 - SV-46436r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001403
Version
SRG-APP-000027-MAPP-NA
Vuln IDs
  • V-35149
Rule IDs
  • SV-46436r1_rule
Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method and best practice for mitigating this risk. A comprehensive application account management process ensures an audit trail automatically documents the modification of application user accounts and, as required, notifies administrators, application owners, and/or appropriate individuals. Applications must provide this capability directly, leveraging complimentary technology providing this capability or a combination thereof. Automated account auditing processes greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and DAP. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43535r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39699r1_fix

The requirement is NA. No fix is required.

b
The application must automatically audit account disabling actions and notify appropriate individuals
AC-2 - Medium - CCI-001404 - V-35152 - SV-46439r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001404
Version
SRG-APP-000028-MAPP-NA
Vuln IDs
  • V-35152
Rule IDs
  • SV-46439r1_rule
When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43537r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39701r1_fix

The requirement is NA. No fix is required.

b
The application must automatically audit account termination and notify appropriate individuals.
AC-2 - Medium - CCI-001405 - V-35154 - SV-46441r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001405
Version
SRG-APP-000029-MAPP-NA
Vuln IDs
  • V-35154
Rule IDs
  • SV-46441r1_rule
When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account terminating actions and notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Examples include but are not limited to, Active Directory and LDAP. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43538r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39703r1_fix

The requirement is NA. No fix is required.

b
Applications must support the organizational requirement to automatically monitor on atypical usage of accounts.
AC-2 - Medium - CCI-001356 - V-35155 - SV-46442r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001356
Version
SRG-APP-000030-MAPP-NA
Vuln IDs
  • V-35155
Rule IDs
  • SV-46442r1_rule
Atypical account usage is behavior that is not part of normal usage cycles. For example, user account activity occurring after hours or on weekends. A comprehensive account management process will ensure that an audit trail which documents the use of application user accounts and as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that compromised user accounts will continue to be used by unauthorized persons and provides logging that can be used for forensic purposes. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43539r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39704r1_fix

The requirement is NA. No fix is required.

b
Service Oriented Architecture (SOA) based applications must dynamically manage user privileges and associated access authorizations.
AC-2 - Medium - CCI-000020 - V-35158 - SV-46445r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000020
Version
SRG-APP-000031-MAPP-NA
Vuln IDs
  • V-35158
Rule IDs
  • SV-46445r1_rule
Web services are web applications providing a method of communication between two or more different electronic devices. They are normally used by applications to provide each other with data. The World Wide Web Consortium (W3C) defines a web service as: "a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically, Web Services Description Language or WSDL). Other systems interact with the web service in a manner prescribed by its description using Simple Object Access Protocol (SOAP) messages typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards". Web services provide different challenges in managing access than what is presented by typical user based applications. In contrast to conventional access control approaches which employ static information system accounts and predefined sets of user privileges, many service-oriented architecture implementations rely on run time access control decisions facilitated by dynamic privilege management. While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. Service Oriented Architecture (SOA) based applications need to take this possibility into account and leverage dynamic access control methodologies. Rationale for non-applicability: While mobile applications may connect to other SOA based resources, they will not have their own SOA-based architecture. This SRG applies to single-user applications that do not perform server functions.
Checks: C-43540r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39706r1_fix

The requirement is NA. No fix is required.

b
The application must employ automated mechanisms enabling authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared.
AC-21 - Medium - CCI-000099 - V-35160 - SV-46447r1_rule
RMF Control
AC-21
Severity
M
CCI
CCI-000099
Version
SRG-APP-000032-MAPP-NA
Vuln IDs
  • V-35160
Rule IDs
  • SV-46447r1_rule
User based collaboration and information sharing applications present challenges regarding classification and dissemination of information generated and shared among the application users. These types of applications are intended to share information created and stored within the application; however, not all users have a need to view all data created or stored within the collaboration tool. Collaboration tools and all applications handling information that may be restricted in some manner (e.g., privileged medical, contract-sensitive, proprietary, personally identifiable information, special access programs/compartments) must provide the capability to automatically enable authorized users to make information sharing decisions based upon access authorizations. Depending on the information-sharing circumstance, the sharing partner may be defined at the individual, group, or organization level and information may be defined by specific content, type, or security categorization. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43543r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39709r2_fix

The requirement is NA. No fix is required.

c
The mobile application must not modify, request, or assign values for operating system parameters unless necessary to perform application functions.
AC-3 - High - CCI-000213 - V-35164 - SV-46451r1_rule
RMF Control
AC-3
Severity
H
CCI
CCI-000213
Version
SRG-APP-000033-MAPP-00010
Vuln IDs
  • V-35164
Rule IDs
  • SV-46451r1_rule
An application 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 application is able to obtain OS privileges greater than necessary for proper operation, then an adversary is able to breach the application, 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 application from assigning itself unnecessary privileges greatly mitigates the risk of unauthorized use of those privileges.
Checks: C-43545r1_chk

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.

Fix: F-39712r1_fix

Modify the code to secure the boundaries within which the application may operate with respect to OS privileges.

c
The mobile application must not execute as a privileged operating system process unless necessary to perform any application functions.
AC-3 - High - CCI-000213 - V-35166 - SV-46453r1_rule
RMF Control
AC-3
Severity
H
CCI
CCI-000213
Version
SRG-APP-000033-MAPP-00011
Vuln IDs
  • V-35166
Rule IDs
  • SV-46453r1_rule
An application that operates with the privileges of its host OS will make the OS, device, and other applications vulnerable to such issues as escalated privileges that would affect the entire platform and device. If the application is able to obtain OS privileges greater than necessary for proper operation, then an adversary, able to breach the application 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.
Checks: C-43548r1_chk

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.

Fix: F-39716r1_fix

Modify the code to secure the boundaries within which the application may operate with respect to OS privileges.

b
A mobile application must not call APIs or otherwise invoke resources external to the mobile application unless such activity serves the documented purposes of the mobile application.
AC-3 - Medium - CCI-000213 - V-35168 - SV-46455r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-000213
Version
SRG-APP-000033-MAPP-00012
Vuln IDs
  • V-35168
Rule IDs
  • SV-46455r1_rule
An application that does not operate within what should be an appropriate sandbox 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 application 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 application that could compromise the data confidentiality, as well as the user's safety and mission.
Checks: C-43550r1_chk

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.

Fix: F-39718r1_fix

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.

b
The application must enforce dual authorization, based on organizational policies and procedures for organization-defined privileged commands.
AC-3 - Medium - CCI-000021 - V-35169 - SV-46456r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-000021
Version
SRG-APP-000034-MAPP-NA
Vuln IDs
  • V-35169
Rule IDs
  • SV-46456r1_rule
Dual authorization requires 2 distinct approving authorities to approve the use of an application command prior to it being invoked. This capability is typically reserved for specific application functionality where the application owner, data owner or organization requires an additional assurance that certain application commands are only invoked under the utmost authority. When a policy is defined stating that certain commands contained within an application require dual-authorization before they may be invoked, or when an organization defines a set of application related privileged commands requiring dual authorization, the application must support those requirements. Due to potential delays in obtaining secondary approvals prior to executing commands, dual authorization mechanisms should not be utilized when an immediate response is necessary in order to ensure public and/or environmental safety. If, after due consideration, it is determined the benefit of dual authorization outweighs identified risks, the organization must establish documented procedures, assign specific personnel to provide approvals and establish operational exercises assuring that any risks to public safety, environmental safety or otherwise, are minimized. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43551r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39719r1_fix

The requirement is NA. No fix is required.

b
When the mobile application supports multiple persona (e.g., DoD work and non-DoD personal or public), the mobile application must enforce a non-discretionary access control policy that prohibits a user from accessing DoD data when operating in a persona not authorized for access to data categorized at that level.
AC-3 - Medium - CCI-000022 - V-35171 - SV-46458r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-000022
Version
SRG-APP-000035-MAPP-00013
Vuln IDs
  • V-35171
Rule IDs
  • SV-46458r1_rule
If a device supports multiple persona, the potential exists for data to migrate from one domain to another in an unauthorized or inadvertent manner. In the case of a dual persona device that supports both personal and DoD use, the potential exists for a user operating in a personal mode to access DoD data, which would be a violation of security policy. Enforcing non-discretionary access control policies to prevent access to domains outside of that which the user is operating greatly mitigates the risk of unauthorized disclosure of sensitive DoD data. Implementation of this control forces the correct domain to be used given the non-discretionary nature of the control.
Checks: C-43553r2_chk

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.

Fix: F-39721r1_fix

Implement non-discretionary access controls in the application or operating system to prohibit unauthorized transfers between domains.

b
The application must enforce a Discretionary Access Control (DAC) policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both.
AC-3 - Medium - CCI-001362 - V-35172 - SV-46459r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-001362
Version
SRG-APP-000036-MAPP-NA
Vuln IDs
  • V-35172
Rule IDs
  • SV-46459r1_rule
Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). DAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong. It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly. Data protection requirements may result in a DAC policy being specified as part of the application design. Discretionary access controls would be employed at the application level to restrict and control access to application objects and data thereby providing increased information security for the organization. When DAC controls are employed, those controls must limit sharing to named application users, groups of users or both. The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require user account management.
Checks: C-43554r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39722r1_fix

The requirement is NA. No fix is required.

b
The application must prevent access to organization-defined security-relevant information except during secure, non-operable system states.
AC-3 - Medium - CCI-000024 - V-35173 - SV-46460r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-000024
Version
SRG-APP-000037-MAPP-NA
Vuln IDs
  • V-35173
Rule IDs
  • SV-46460r1_rule
Security-relevant information is any information within the information system that can potentially impact the operation of security functions in a manner possibly resulting in failure to enforce the system security policy or maintain isolation of code and data. Organizations may define specific security relevant information requiring protection. Filtering rules for routers and firewalls, cryptographic key management information, key configuration parameters for security services, and access control lists are examples of security-relevant information. Secure, non-operable system states are states in which the information system is not performing mission/business-related processing (e.g., the system is off-line for maintenance, troubleshooting, boot-up, shutdown). Access to these types of data is to be prevented unless the system is in a maintenance mode or has otherwise been brought off-line. The goal is to minimize the potential a security configuration or data may be dynamically and perhaps, surreptitiously overwritten or changed (without going through a formal system change process that can document the changes). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Any controls that manage the dissemination of secure data within a system are covered by relevant SRGs and STIGs. At the device level, local interprocess communication is a core operating system function; OS security controls will preside over application-level controls in the event an application is taken over by a malicious user.
Checks: C-43555r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39723r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow control must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.
AC-4 - Medium - CCI-001368 - V-35174 - SV-46461r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001368
Version
SRG-APP-000038-MAPP-NA
Vuln IDs
  • V-35174
Rule IDs
  • SV-46461r1_rule
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. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities transforming data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43556r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39724r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow control must enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.
AC-4 - Medium - CCI-001414 - V-35177 - SV-46464r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001414
Version
SRG-APP-000039-MAPP-NA
Vuln IDs
  • V-35177
Rule IDs
  • SV-46464r1_rule
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. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information that is marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43558r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39726r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow control must use explicit security attributes on information, source, and destination objects as a basis for flow control decisions.
AC-4 - Medium - CCI-000025 - V-35179 - SV-46466r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000025
Version
SRG-APP-000040-MAPP-NA
Vuln IDs
  • V-35179
Rule IDs
  • SV-46466r1_rule
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. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43559r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39727r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow control must provide the capability for privileged administrators to enable/disable security policy filters.
AC-4 - Medium - CCI-000034 - V-35180 - SV-46467r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000034
Version
SRG-APP-000041-MAPP-NA
Vuln IDs
  • V-35180
Rule IDs
  • SV-46467r1_rule
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. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43560r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39728r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow controls must provide the capability for privileged administrators to configure security policy filters to support different organizational security policies.
AC-4 - Medium - CCI-000035 - V-35181 - SV-46468r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000035
Version
SRG-APP-000042-MAPP-NA
Vuln IDs
  • V-35181
Rule IDs
  • SV-46468r1_rule
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. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43561r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39729r1_fix

The requirement is NA. No fix is required.

b
Applications providing flow control must identify data type, specification and usage when transferring information between different security domains so that policy restrictions may be applied.
AC-4 - Medium - CCI-000218 - V-35206 - SV-46493r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000218
Version
SRG-APP-000043-MAPP-NA
Vuln IDs
  • V-35206
Rule IDs
  • SV-46493r1_rule
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. An example of flow control restrictions includes: keeping export controlled information from being transmitted in the clear to the Internet. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., users, networks, devices) within information systems and between interconnected systems. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, application layer gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Flow control is based on the characteristics of the information and/or the information path. Applications providing flow control must identify data type, specification, and usage when transferring information between different security domains so policy restrictions may be applied. A Security domain is defined as a domain implementing a security policy and is administered by a single authority. Data type, specification and usage includes, using file naming to reflect the type of data being transferred and limiting data transfer based on file type. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43578r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39752r1_fix

The requirement is NA. No fix is required.

b
Applications, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms.
AC-4 - Medium - CCI-000219 - V-35207 - SV-46494r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000219
Version
SRG-APP-000044-MAPP-NA
Vuln IDs
  • V-35207
Rule IDs
  • SV-46494r1_rule
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. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Policy enforcement mechanisms include the filtering and/or sanitization rules applied to information prior to transfer to a different security domain. Parsing transfer files facilitates policy decisions on source, destination, certificates, classification, subject, attachments, and other information security-related component differentiators. Policy rules for cross domain transfers include, limitations on embedding components/information types within other components/information types, prohibiting more than two-levels of embedding, and prohibiting the transfer of archived information types. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Local interprocess communication is a core operating system function.
Checks: C-43579r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39753r1_fix

The requirement is NA. No fix is required.

b
When the mobile application supports multiple persona (e.g., DoD work and non-DoD personal or public), the mobile application must implement or incorporate policy filters that constrain data objects and structure attributes according to organizational security policy statements.
AC-4 - Medium - CCI-001372 - V-35208 - SV-46495r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001372
Version
SRG-APP-000045-MAPP-00014
Vuln IDs
  • V-35208
Rule IDs
  • SV-46495r1_rule
Transferring data between various personas, such as DoD, non-DoD, personal or public etc., subjects the data to both accidental exposure and malicious intruders able to gain access to the device or application through the least-secure domain. In the case of a dual persona device that supports both personal and DoD use, the potential exists for a user operating in a personal mode to access DoD data, which would be a violation of security policy unless the data was authorized for such transfer. This control greatly mitigates the risk of unauthorized disclosure of sensitive DoD data by incorporating policy that will prevent the user from transferring the data between domains inadvertently, unless he/she chooses to do so, fully aware of the action that is being taken.
Checks: C-43580r2_chk

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.

Fix: F-39754r1_fix

Modify code or operating system configuration to prohibit the transfer of identified unauthorized data between domains.

b
Applications designed to control information flow must provide the ability to detect unsanctioned information being transmitted across security domains.
AC-4 - Medium - CCI-001373 - V-35209 - SV-46496r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001373
Version
SRG-APP-000046-MAPP-NA
Vuln IDs
  • V-35209
Rule IDs
  • SV-46496r1_rule
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. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, application layer gateways, cross domain guards, content filters) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Actions to support this requirement include, but are not limited to checking all transferred information for malware, implementing dirty word list searches on transferred information, and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload. Rationale for non-applicability: Applications designed to control information flow are outside the scope of this SRG. The transfer of information across security domains is a function of the MOS, to the extent the MOS even supports multiple security domains or permits transfer from one domain to another. This IA control is more appropriate to network guards, which do not run on mobile devices.
Checks: C-43581r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39755r1_fix

The requirement is NA. No fix is required.

b
Applications must provide the ability to prohibit the transfer of unsanctioned information in accordance with security policy.
AC-4 - Medium - CCI-001374 - V-35210 - SV-46497r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001374
Version
SRG-APP-000047-MAPP-NA
Vuln IDs
  • V-35210
Rule IDs
  • SV-46497r1_rule
The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. 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. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Actions to support this requirement include, but are not limited to, checking all transferred information for malware, implementing dirty word list searches on transferred information, and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG. Any controls that manage the dissemination of secure data within a system are covered by relevant SRGs and STIGs. At the device level, local interprocess communication is a core operating system function; OS security controls will preside over application-level controls in the event an application is taken over by a malicious user.
Checks: C-43582r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39756r1_fix

The requirement is NA. No fix is required.

b
Applications must provide the ability to enforce security policies regarding information on interconnected systems.
AC-4 - Medium - CCI-000221 - V-35211 - SV-46498r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000221
Version
SRG-APP-000048-MAPP-NA
Vuln IDs
  • V-35211
Rule IDs
  • SV-46498r1_rule
The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. 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. Transferring information between interconnected information systems of differing security policies introduces risk that such transfers violate one or more policies. While security policy violations may not be absolutely prohibited, policy guidance from information owners/stewards is implemented at the policy enforcement point between the interconnected systems. Specific architectural solutions are mandated, when required, to reduce the potential for undiscovered vulnerabilities. Architectural solutions include: (i) prohibiting information transfers between interconnected systems (i.e., implementing access only, one way transfer mechanisms); (ii) employing hardware mechanisms to enforce unitary information flow directions; and (iii) implementing fully tested, re-grading mechanisms to reassign security attributes and associated security labels. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43583r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39757r1_fix

The requirement is NA. No fix is required.

b
The mobile application must identify the persona from which data is coming before permitting transfer to or from a DoD persona when the mobile application supports multiple personas.
AC-4 - Medium - CCI-001376 - V-35228 - SV-46515r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001376
Version
SRG-APP-000049-MAPP-00015
Vuln IDs
  • V-35228
Rule IDs
  • SV-46515r1_rule
Transfer of data from one persona to another on a device that supports multiple personas poses two significant risks. First, malware present in one persona could migrate to another persona. In this case, the malware could be used to breach other systems, potentially resulting in the unauthorized disclosure of sensitive DoD data. Second, sensitive data from one persona could be exfiltrated to another persona. This also could result in the unauthorized disclosure of sensitive DoD data. Indentifying the source persona is a critical step in preventing improper transfer of data and malware because it enables the implementation of security filters that stop unauthorized transfers.
Checks: C-43600r1_chk

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.

Fix: F-39774r1_fix

Modify code to identify the source persona when data is transferred from one persona to another.

b
A mobile application must authenticate the persona from which data is coming before permitting transfer to or from a DoD persona when the mobile application supports multiple personas.
AC-4 - Medium - CCI-001377 - V-35229 - SV-46516r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001377
Version
SRG-APP-000050-MAPP-00016
Vuln IDs
  • V-35229
Rule IDs
  • SV-46516r1_rule
Transfer of data from one persona to another on a device that supports multiple personas poses two significant risks. First, malware present in one persona could migrate to another persona. In this case, the malware could be used to breach other systems, potentially resulting in the unauthorized disclosure of sensitive DoD data. Second, sensitive data from one persona could be exfiltrated to another persona. This also could result in the unauthorized disclosure of sensitive DoD data. Authenticating the source persona is a critical step in preventing improper transfer of data and malware because it provides assurance that security filters that stop unauthorized transfers are basing decisions on accurate information.
Checks: C-43601r1_chk

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.

Fix: F-39775r1_fix

Modify code to authenticate the source persona when data is transferred from one persona to another.

b
Applications must uniquely identify destination domains for information transfer.
AC-4 - Medium - CCI-001555 - V-35230 - SV-46517r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001555
Version
SRG-APP-000051-MAPP-NA
Vuln IDs
  • V-35230
Rule IDs
  • SV-46517r1_rule
The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. 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. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Attribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43602r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39776r1_fix

The requirement is NA. No fix is required.

b
The application must bind security attributes to information to facilitate information flow policy enforcement.
AC-4 - Medium - CCI-000223 - V-35231 - SV-46518r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000223
Version
SRG-APP-000052-MAPP-NA
Vuln IDs
  • V-35231
Rule IDs
  • SV-46518r1_rule
The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. 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. Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. Binding security attributes to information allows policy enforcement mechanisms to act on that information and enforce policy. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43603r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39777r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow control must track problems associated with the binding of security attributes to data.
AC-4 - Medium - CCI-000224 - V-35239 - SV-46526r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000224
Version
SRG-APP-000053-MAPP-NA
Vuln IDs
  • V-35239
Rule IDs
  • SV-46526r1_rule
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. Attribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. In order to identify problems that may occur when binding security attributes to information, tracking and or auditing of these binding events must take place. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43607r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39785r1_fix

The requirement is NA. No fix is required.

b
Applications must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions.
AC-4 - Medium - CCI-000026 - V-35242 - SV-46529r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000026
Version
SRG-APP-000054-MAPP-NA
Vuln IDs
  • V-35242
Rule IDs
  • SV-46529r1_rule
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. Information flow enforcement using explicit security attributes can be used, for example, to control the release of certain types of information. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43610r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39788r1_fix

The requirement is NA. No fix is required.

b
Applications must prevent encrypted data from bypassing content-checking mechanisms.
AC-4 - Medium - CCI-000028 - V-35243 - SV-46530r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000028
Version
SRG-APP-000056-MAPP-NA
Vuln IDs
  • V-35243
Rule IDs
  • SV-46530r1_rule
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. When data is encrypted, devices and software designed to examine data content so as to detect attacks or malicious code are unable to accomplish the task unless they are capable of unencrypting the data. Example includes decrypting email in order to scan attachments. Rationale for non-applicability: Mobile applications residing at the edge of a network decrypt all encrypted data intended for the user's consumption. In this context, there would never be a requirement to bypass content checking mechanisms on the device given the device is at the edge of the network. The MDM SRG addresses content checking requirement for mobile email systems.
Checks: C-43612r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39790r1_fix

The requirement is NA. No fix is required.

a
The mobile application must enforce organization defined limitations on the embedding of data types within other data types.
Low - V-35244 - SV-46531r1_rule
RMF Control
Severity
L
CCI
Version
SRG-APP-000057-MAPP-00017
Vuln IDs
  • V-35244
Rule IDs
  • SV-46531r1_rule
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.
Checks: C-43613r1_chk

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.

Fix: F-39791r1_fix

Modify the code to limit the ability to embed data types within other data types.

b
Applications must enforce information flow control on metadata.
AC-4 - Medium - CCI-000030 - V-35245 - SV-46532r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000030
Version
SRG-APP-000058-MAPP-NA
Vuln IDs
  • V-35245
Rule IDs
  • SV-46532r1_rule
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. Metadata is defined as data providing information about one or more other pieces of data such as; purpose of the data, author/creator of the data, network location of where data was created, and application specific data information. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43614r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39792r1_fix

The requirement is NA. No fix is required.

b
Applications must use security policy filters as a basis for making information flow control decisions.
AC-4 - Medium - CCI-000032 - V-35246 - SV-46533r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000032
Version
SRG-APP-000059-MAPP-NA
Vuln IDs
  • V-35246
Rule IDs
  • SV-46533r1_rule
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 not explicitly allowed by the information flow policy. Security policy filters are defined by the organization and include, dirty word filters, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. - Structured data typically describes data intended for storage in a data management system such as a relational database. - Unstructured data refers to masses of digital information that do not have a data structure such as word processing documents, email, pictures, audio, and video. - In the case of unstructured data, metadata is considered to be data about the data in question. - In the case of structured data, metadata is considered to be data about the containers of the data. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43615r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39793r1_fix

The requirement is NA. No fix is required.

b
Applications providing information flow control must uniquely authenticate destination domains when transferring information.
AC-4 - Medium - CCI-001556 - V-35247 - SV-46534r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001556
Version
SRG-APP-000060-MAPP-NA
Vuln IDs
  • V-35247
Rule IDs
  • SV-46534r1_rule
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. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, application gateways, guards, cross domain systems) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Attribution, (e.g., the ability to attribute actions to individuals), processes or systems, is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43616r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39794r1_fix

The requirement is NA. No fix is required.

a
When the mobile application supports multiple persona (e.g., DoD work and non-DoD personal or public), the application must record a log entry when there is a failed attempt to improperly transfer data from one domain to another.
AC-4 - Low - CCI-001557 - V-35248 - SV-46535r1_rule
RMF Control
AC-4
Severity
L
CCI
CCI-001557
Version
SRG-APP-000061-MAPP-00018
Vuln IDs
  • V-35248
Rule IDs
  • SV-46535r1_rule
Transferring data between various domains exposes the data to both accidental and malicious intruders able to perform physical attacks. This form of attack will allow an unauthorized user to gain access to the operating system or application through one of the domains. Similarly, sensitive data conveyed to a less-secure domain holds the potential to cause data exposure. This control provides the user a more secure operating domain; adding controls that prevent the transfer of data between security domains mitigates a number of IA risks. Furthermore, logging all failed attempts to transfer data between security domains will enable the user and administrator to identify when there has been a likely breach of system security and take appropriate incident responses measures.
Checks: C-43617r1_chk

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.

Fix: F-39795r1_fix

Modify code so the application records a log entry when there is a failed attempt to improperly transfer data from one domain to another.

b
Applications must support organizational requirements to implement separation of duties through assigned information access authorizations.
AC-5 - Medium - CCI-000037 - V-35249 - SV-46536r1_rule
RMF Control
AC-5
Severity
M
CCI
CCI-000037
Version
SRG-APP-000062-MAPP-NA
Vuln IDs
  • V-35249
Rule IDs
  • SV-46536r1_rule
Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. Additionally, the person or entity accountable for monitoring the activity must be separate as well. To meet this requirement, applications, when applicable, shall be divided where functionality is based on roles and duties. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require separation of duties.
Checks: C-43618r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39796r1_fix

The requirement is NA. No fix is required.

b
Application users must utilize a separate, distinct administrative account when accessing application security functions or security-relevant information. Non-privileged accounts must be utilized when accessing non-administrative application functions.
AC-6 - Medium - CCI-000040 - V-35250 - SV-46537r1_rule
RMF Control
AC-6
Severity
M
CCI
CCI-000040
Version
SRG-APP-000063-MAPP-NA
Vuln IDs
  • V-35250
Rule IDs
  • SV-46537r1_rule
This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy such as Role Based Access Control (RBAC) is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. Audit of privileged activity may require physical separation employing information systems on which the user does not have privileged access. To limit exposure and provide forensic history of activity when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. If feasible, applications should provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. Rationale for non-applicability: This SRG applies to single-user applications. When changes to the security configuration of a mobile application are required, this is typically achieved by upgrading the application.
Checks: C-43619r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39797r1_fix

The requirement is NA. No fix is required.

b
Applications must be able to function within separate processing domains (virtualized systems), when specified, so as to enable finer-grained allocation of user privileges.
AC-6 - Medium - CCI-000226 - V-35251 - SV-46538r1_rule
RMF Control
AC-6
Severity
M
CCI
CCI-000226
Version
SRG-APP-000064-MAPP-NA
Vuln IDs
  • V-35251
Rule IDs
  • SV-46538r1_rule
Applications must employ the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Employing virtualization techniques to allow greater privilege within a virtual machine, while restricting privilege to the underlying actual machine is an example of providing separate processing domains for finer-grained allocation of user privileges. Rationale for non-applicability: This control is best implemented by the virtualization technology and not through each mobile application. Mobile applications are written to run on specified operating systems. If these operating systems are virtualized correctly, the mobile application would also function in that environment.
Checks: C-43620r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39798r1_fix

The requirement is NA. No fix is required.

b
Applications must have the capability to limit the number of failed login attempts based upon an organization defined number of consecutive invalid attempts occurring within an organization defined time period.
AC-7 - Medium - CCI-000044 - V-35252 - SV-46539r1_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000044
Version
SRG-APP-000065-MAPP-NA
Vuln IDs
  • V-35252
Rule IDs
  • SV-46539r1_rule
Anytime an authentication method is exposed so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. Rationale for non-applicability: In general, mobile applications will not authenticate users although they may do so when required by a remote application. In this case, the remote application, rather than the local application, must enforce restrictions on the number of failed logon attempts. If the local application were responsible for the security of the remote application, this would make the remote application vulnerable to breaches on the mobile device.
Checks: C-43621r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39799r1_fix

The requirement is NA. No fix is required.

b
The application must enforce the organization-defined time period during which the limit of consecutive invalid access attempts by a user is counted.
AC-7 - Medium - CCI-001452 - V-35253 - SV-46540r1_rule
RMF Control
AC-7
Severity
M
CCI
CCI-001452
Version
SRG-APP-000066-MAPP-NA
Vuln IDs
  • V-35253
Rule IDs
  • SV-46540r1_rule
Anytime an authentication method is exposed, so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To aid in defeating these attempts, organizations define the number of times that a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. Rationale for non-applicability: This control is required in the MOS SRG. The mobile operating system is best positioned to handle user authentication transactions. If the mobile application connects to a remote enterprise resource, the remote application must count the number of invalid access attempts. If this function were performed locally, it would be a vulnerability for the remote application.
Checks: C-43622r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39800r1_fix

The requirement is NA. No fix is required.

b
Applications, when the maximum number of unsuccessful attempts are exceeded, must automatically lock the account/node for an organization-defined time period or lock the account/node until released by an administrator IAW organizational policy.
AC-7 - Medium - CCI-000047 - V-35255 - SV-46542r1_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000047
Version
SRG-APP-000067-MAPP-NA
Vuln IDs
  • V-35255
Rule IDs
  • SV-46542r1_rule
Anytime an authentication method is exposed so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. Rationale for non-applicability: Mobile applications covered by this SRG do not require authentication. If the mobile application connects to a remote enterprise application that requires authentication, the remote application should enforce its authentication requirements.
Checks: C-43623r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39801r1_fix

e requirement is NA. No fix is required.

b
Applications must display an approved system use notification message or banner before granting access to the system.
AC-8 - Medium - CCI-000048 - V-35256 - SV-46543r1_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
SRG-APP-000068-MAPP-NA
Vuln IDs
  • V-35256
Rule IDs
  • SV-46543r1_rule
Applications are required to display an approved system use notification message or banner before granting access to the system providing privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and (iv) the use of the system indicates consent to monitoring and recording. System use notification messages can be implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access, including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist. Use this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner shall be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." For Blackberries and other PDAs/PEDs with severe character limitations use the following: "I've read & consent to terms in IS user agreem't." Rationale for non-applicability: The MOS banner requirement covers mobile applications residing on the device. There is no requirement for a second banner to be displayed on the launch of a mobile application just as there is no requirement to display a banner when a user launches a word processing or spreadsheet application on PC or laptop. When the mobile application connects to a remote application that has a banner requirement, this requirement is outside the scope of the MAPP SRG, which addresses the local application only.
Checks: C-43624r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39802r1_fix

The requirement is NA. No fix is required.

b
Applications must display an approved system use notification message or banner before granting access to the system.
AC-8 - Medium - CCI-001384 - V-35258 - SV-46545r1_rule
RMF Control
AC-8
Severity
M
CCI
CCI-001384
Version
SRG-APP-000070-MAPP-NA
Vuln IDs
  • V-35258
Rule IDs
  • SV-46545r1_rule
Applications must display an approved system use notification message or banner before granting access to the system. The banner shall be formatted in accordance with the DoD policy "Use of DoD Information Systems - Standard Consent and User Agreement". The message banner shall provide privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and shall state that: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and is subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; (iv) the use of the system indicates consent to monitoring and recording; (v) in the notice given to public users of the information system, shall provide a description of the authorized uses of the system. System use notification messages are implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist. The banner shall state: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Rationale for Non applicability: The MOS banner requirement covers mobile applications residing on the device. There is no requirement for a second banner to be displayed on the launch of a mobile application, just as there is no requirement to display a banner when a user launches a word processing or spreadsheet application on PC or laptop. When the mobile application connects to a remote application that has a banner requirement, this requirement is outside the scope of the MAPP SRG, which addresses the local application only.
Checks: C-43626r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39804r1_fix

The requirement is NA. No fix is required.

b
Applications must configure their auditing to reduce the likelihood of storage capacity being exceeded.
AU-4 - Medium - CCI-000138 - V-35259 - SV-46546r1_rule
RMF Control
AU-4
Severity
M
CCI
CCI-000138
Version
SRG-APP-000071-MAPP-NA
Vuln IDs
  • V-35259
Rule IDs
  • SV-46546r1_rule
Applications need to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs. During the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient enough to meet storage requirements. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security-critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43627r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39805r1_fix

The requirement is NA. No fix is required.

b
Applications must allocate audit record storage capacity.
AU-4 - Medium - CCI-000137 - V-35260 - SV-46547r1_rule
RMF Control
AU-4
Severity
M
CCI
CCI-000137
Version
SRG-APP-000072-MAPP-NA
Vuln IDs
  • V-35260
Rule IDs
  • SV-46547r1_rule
In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. Rationale for non-applicability: This control is required in the MOS SRG. Mobile applications are expected to use system logs for audit records to facilitate centralized reporting and alerting. If a mobile application were able to allocate record storage in the system logs, this would be a DoS vulnerability for other applications.
Checks: C-43628r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39806r1_fix

The requirement is NA. No fix is required.

b
Applications scanning for malicious code must scan all media used for system maintenance prior to use.
MA-3 - Medium - CCI-000870 - V-35261 - SV-46548r1_rule
RMF Control
MA-3
Severity
M
CCI
CCI-000870
Version
SRG-APP-000073-MAPP-NA
Vuln IDs
  • V-35261
Rule IDs
  • SV-46548r1_rule
There are security-related issues arising from software brought into the information system specifically for diagnostic and repair actions. (e.g., a software packet sniffer installed on a system in order to troubleshoot system traffic, or a vendor installing or running a diagnostic application in order to troubleshoot an issue with a vendor supported system). This requirement ensures the media containing the application is scanned for malicious code prior to use. Rationale for non-applicability: Malicious code protections are within the scope of the MDM SRG.
Checks: C-43629r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39807r1_fix

The requirement is NA. No fix is required.

c
The mobile application must not execute unsigned DoD Mobile Code Policy Category 1A or 2 mobile code.
SC-18 - High - CCI-001687 - V-35262 - SV-46549r1_rule
RMF Control
SC-18
Severity
H
CCI
CCI-001687
Version
SRG-APP-000074-MAPP-00020
Vuln IDs
  • V-35262
Rule IDs
  • SV-46549r1_rule
Use of un-trusted Level 1 and 2 mobile code technologies can introduce security vulnerabilities and malicious code into the client system. Unsigned code is potentially dangerous to use since there is no verification the code is tested and free of defects that will cause security issues. Also, the code, being untested could contain malware. Category IA mobile code largely involves mobile code that runs on Microsoft Windows. While this code primarily concerns traditional PC and laptop computers, it may also function on versions of Microsoft Windows for mobile devices, either today or in subsequent releases. It is also possible for applications to be written for other MOS to incorporate the capability to interpret category IA mobile code. This control assures the user greater security against using code that is prohibited because it is untrusted and untested.
Checks: C-43630r3_chk

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

Fix: F-39808r1_fix

Modify the code so that the application does not execute unsigned DoD Mobile Code Policy Category 1A or 2 mobile code.

c
The mobile application must validate the signature on DoD Mobile Code Policy Category 1A and 2 mobile code before executing such code.
SC-18 - High - CCI-001687 - V-35263 - SV-46550r1_rule
RMF Control
SC-18
Severity
H
CCI
CCI-001687
Version
SRG-APP-000074-MAPP-00021
Vuln IDs
  • V-35263
Rule IDs
  • SV-46550r1_rule
Untrusted mobile code may contain malware or malicious code and digital signatures provide a source of the content which is crucial to authentication and trust of the data. Category 2 mobile code that operates in an unconstrained environment, like category 1, must possess a signature that indicates the identity of the developer. Unsigned code is potentially dangerous to use since there is no verification the code is tested and free of defects that will cause security issues. Also, the code, being untested could also contain malware. In applying this control, the user is assured greater security against using code that is prohibited because it is untrusted and untested.
Checks: C-43632r1_chk

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.

Fix: F-39809r1_fix

Modify code so the application will verify DoD Mobile Code Policy Category 1A and 2 mobile code before executing it.

c
The mobile application must not permit DoD Mobile Code Policy Category 2 mobile code to access any resource not dedicated to the mobile application.
SC-18 - High - CCI-001687 - V-35264 - SV-46551r1_rule
RMF Control
SC-18
Severity
H
CCI
CCI-001687
Version
SRG-APP-000074-MAPP-00022
Vuln IDs
  • V-35264
Rule IDs
  • SV-46551r1_rule
Mobile code cannot conform to traditional installation and configuration safeguards. The use of local operating system resources and spawning of network connections introduce harmful and uncertain effects. In applying this control, the user is assured greater security and defense against malicious users who will access the application and device through escalated privileges as a result of a weak security posture.
Checks: C-43633r1_chk

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.

Fix: F-39810r1_fix

Modify code so that DoD Mobile Code Policy Category 2 mobile code is unable to access resources not dedicated to the mobile application.

c
The mobile application must not use mobile code technology that is not yet categorized in accordance with the DoD Mobile Code Policy.
SC-18 - High - CCI-001687 - V-35265 - SV-46552r1_rule
RMF Control
SC-18
Severity
H
CCI
CCI-001687
Version
SRG-APP-000074-MAPP-00023
Vuln IDs
  • V-35265
Rule IDs
  • SV-46552r1_rule
Mobile code does not require any traditional software acceptance testing or security validation. Mobile code needs to follow sound policy to maintain a reasonable level of trust. Mobile code that does not fall into existing policy cannot be trusted. In applying this policy, the user is assured greater security from using tested and signed code.
Checks: C-43634r2_chk

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.

Fix: F-39811r1_fix

Remove uncategorized mobile code and interpreters for uncategorized mobile code.

b
Applications upon successful logon, must display to the user the date and time of the last logon (access).
AC-9 - Medium - CCI-000052 - V-35266 - SV-46553r1_rule
RMF Control
AC-9
Severity
M
CCI
CCI-000052
Version
SRG-APP-000075-MAPP-NA
Vuln IDs
  • V-35266
Rule IDs
  • SV-46553r1_rule
Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the date and time of their last successful login allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional interactive logons to information systems and general accesses to information systems that occur in other types of architectural configurations (e.g., service oriented architectures). Rationale for non-applicability: This control is required in the MOS SRG. Mobile applications do not have additional authentication requirements. If the mobile application connects to a remote enterprise application, the remote application can provide any required notifications.
Checks: C-43635r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39812r1_fix

The requirement is NA. No fix is required.

b
In order to inform the user of failed login attempts made with the users account, the application upon successful logon/access must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access.
AC-9 - Medium - CCI-000053 - V-35267 - SV-46554r1_rule
RMF Control
AC-9
Severity
M
CCI
CCI-000053
Version
SRG-APP-000076-MAPP-NA
Vuln IDs
  • V-35267
Rule IDs
  • SV-46554r1_rule
Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional logons to information systems and general accesses to information systems that occur in other types of architectural configurations (e.g., service oriented architectures). Rationale for non-applicability: This control is required in the MOS SRG. Mobile applications do not have additional authentication requirements. If the mobile application connects to a remote enterprise application, the remote application can provide any required notifications.
Checks: C-43636r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39813r1_fix

The requirement is NA. No fix is required.

b
In order to inform the user of the number of successful login attempts made with the users account, the application must notify the user of the number of successful logins/accesses occurring during an organization-defined time period.
AC-9 - Medium - CCI-001391 - V-35268 - SV-46555r1_rule
RMF Control
AC-9
Severity
M
CCI
CCI-001391
Version
SRG-APP-000077-MAPP-NA
Vuln IDs
  • V-35268
Rule IDs
  • SV-46555r1_rule
Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of successful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional logons to information systems and general accesses to information systems occurring in other types of architectural configurations (e.g., service oriented architectures). Rationale for non-applicability: This control is required in the MOS SRG. Mobile applications do not have additional authentication requirements. If the mobile application connects to a remote enterprise application, the remote application can provide any required notifications.
Checks: C-43637r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39814r1_fix

The requirement is NA. No fix is required.

b
The application must notify the user of the number of unsuccessful login/access attempts occurring during an organization-defined time period.
AC-9 - Medium - CCI-001392 - V-35269 - SV-46556r1_rule
RMF Control
AC-9
Severity
M
CCI
CCI-001392
Version
SRG-APP-000078-MAPP-NA
Vuln IDs
  • V-35269
Rule IDs
  • SV-46556r1_rule
Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional logons to information systems and general accesses to information systems occurring in other types of architectural configurations (e.g., service oriented architectures). In order to inform the user of the number of unsuccessful login attempts made with the users account. Rationale for non-applicability: This control is required in the MOS SRG. Mobile applications do not have additional authentication requirements. If the mobile application connects to a remote enterprise application, the remote application can provide any required notifications.
Checks: C-43638r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39815r1_fix

The requirement is NA. No fix is required.

b
Applications must notify users of organization-defined security-related changes to the users account occurring during the organization-defined time period.
AC-9 - Medium - CCI-001395 - V-35270 - SV-46557r1_rule
RMF Control
AC-9
Severity
M
CCI
CCI-001395
Version
SRG-APP-000079-MAPP-NA
Vuln IDs
  • V-35270
Rule IDs
  • SV-46557r1_rule
Some organizations may define certain security events as events requiring user notification. An organization may define an event such as a password change to a user's account occurring outside of normal business hours as a security related event requiring that the application user be notified. In those instances, where organizations define such events, the application must notify the affected user or users. Rationale for non-applicability: An assumption of this SRG is that a single user will be operating the mobile device, eliminating the need for OS and application account management and for notifying users regarding changes to account security. To the extent that the local application connects to a remote multi-user application, the remote application can notify the user of security changes through a variety of mechanisms outside the scope of the local application.
Checks: C-43639r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39816r1_fix

The requirement is NA. No fix is required.

b
The application must protect against an individual falsely denying having performed a particular action.
AU-10 - Medium - CCI-000166 - V-35271 - SV-46558r1_rule
RMF Control
AU-10
Severity
M
CCI
CCI-000166
Version
SRG-APP-000080-MAPP-NA
Vuln IDs
  • V-35271
Rule IDs
  • SV-46558r1_rule
Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. Rationale for non-applicability: The SRG assumes that there is a single user in the mobile application environment, thereby obviating the need to rule out any other user from claiming or denying a particular action. To the extent that non-repudiation services are required for certain application transactions, user authentication to the device would protect against that user falsely denying having performed a particular action. Additional application assurance is unnecessary in this context.
Checks: C-43640r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39817r1_fix

The requirement is NA. No fix is required.

a
The digital signature on the mobile application installation code must identify the entity responsible for the application.
AU-10 - Low - CCI-001338 - V-35272 - SV-46559r1_rule
RMF Control
AU-10
Severity
L
CCI
CCI-001338
Version
SRG-APP-000081-MAPP-00024
Vuln IDs
  • V-35272
Rule IDs
  • SV-46559r1_rule
Any code that a mobile application uses must contain a signature to authenticate the actual publisher in order to prove the source code is not only legitimate, but has also been created by a trusted source itself. Using software that cannot be traced to a trusted source means the code may have been written by an untrusted source. This situation can lead to an adversary creating an application that has the appearance and utility of an application in current use that will eventually be downloaded by a user in the form of an update, for example. In this instance, the application will contain malicious code that will gain root access and other escalated privileges compromising the security posture of the device and the data on it. This control assures the user that the code came from a trusted source that will protect against such instances as malicious action through escalated privilege that could corrupt or compromise the integrity and confidentiality of data on the device.
Checks: C-43641r1_chk

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.

Fix: F-39818r1_fix

Modify the application and the application's installation code to support identifying digital signatures.

b
If the mobile application processes digitally signed data or code, then it must validate the digital signature.
AU-10 - Medium - CCI-001339 - V-35273 - SV-46560r1_rule
RMF Control
AU-10
Severity
M
CCI
CCI-001339
Version
SRG-APP-000082-MAPP-00025
Vuln IDs
  • V-35273
Rule IDs
  • SV-46560r1_rule
Mobile code and data files created by an untrusted source may contain malware or malicious code as a result of the source's nature. Though digital signatures provide a level of authenticity which is crucial to trusting the data, the digital signature, typically in the form of a certificate will still require to be fully validated. Validation includes checking whether the certificate used to sign the code or data has expired, been revoked, or was issued by a cryptographically unrecognized certificate authority. The application that is using code whose digital signature cannot be validated opens the application and OS to many vulnerabilities; the data or code the application uses may contain malicious code that could gain root access and other escalated privileges compromising the security posture of the device and the data on it. This control protects users from the potential of malicious code being executed when invalid signatures are used.
Checks: C-43642r2_chk

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.

Fix: F-39819r1_fix

Modify code to include digital signature validation.

b
Applications must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released.
AU-10 - Medium - CCI-001340 - V-35274 - SV-46561r1_rule
RMF Control
AU-10
Severity
M
CCI
CCI-001340
Version
SRG-APP-000083-MAPP-NA
Vuln IDs
  • V-35274
Rule IDs
  • SV-46561r1_rule
Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. Non-repudiation services can be used to determine if information originated from an individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Non-repudiation services are obtained by employing various techniques or mechanisms (e.g., digital signatures, digital message receipts). When it comes to data review and data release, there must be a correlation between the data that is reviewed and the person who performs the review. If the reviewer is a human or if the review function is automated but separate from the release/transfer function, the application associates the identity of the reviewer of the information to be released with the information and the information label. In the case of human reviews, this requirement provides appropriate organizational officials the means to identify who reviewed and released the information. In the case of automated reviews, this control enhancement helps ensure only approved review functions are employed. Rationale for non-applicability: This SRG applies to single-user applications. To the extent a chain of custody is ever required, the application data is presumed to be in the custody of the user to which the mobile device is assigned.
Checks: C-43643r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39820r1_fix

The requirement is NA. No fix is required.

b
The application must validate the binding of the reviewers identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain.
AU-10 - Medium - CCI-001341 - V-35275 - SV-46562r1_rule
RMF Control
AU-10
Severity
M
CCI
CCI-001341
Version
SRG-APP-000084-MAPP-NA
Vuln IDs
  • V-35275
Rule IDs
  • SV-46562r1_rule
This non-repudiation control enhancement is intended to mitigate the risk that information could be modified between review and transfer/release particularly when transfer is occurring between security domains. In those instances where the application is transferring data intended for release across security domains, the application must validate the binding of the reviewer's identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain. Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-43644r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39821r1_fix

The requirement is NA. No fix is required.

b
Applications utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights.
AC-3 - Medium - CCI-001693 - V-35276 - SV-46563r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-001693
Version
SRG-APP-000085-MAPP-NA
Vuln IDs
  • V-35276
Rule IDs
  • SV-46563r1_rule
Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user controlled file permissions. DAC models have the potential for the access controls to propagate without limit resulting in unauthorized access to said objects. When applications provide a discretionary access control mechanism, the application must be able to limit the propagation of those access rights. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, access rights cannot propagate to other users.
Checks: C-43645r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39822r1_fix

The requirement is NA. No fix is required.

b
The application must provide the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization-defined level of tolerance.
AU-12 - Medium - CCI-000174 - V-35277 - SV-46564r1_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000174
Version
SRG-APP-000086-MAPP-NA
Vuln IDs
  • V-35277
Rule IDs
  • SV-46564r1_rule
Audit generation and audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). The events occurring must be time-correlated on order to conduct accurate forensic analysis. In addition, the correlation must meet a certain tolerance criteria. For instance, the organization may define that the time stamps of different audited events must not differ by any amount greater than ten seconds. Rationale for non-applicability: To the extent that a mobile application has auditing functionality, it would be expected to send audit events to the appropriate system log, which will then be transferred to an MDM server or centralized audit system. A centralized audit system is significantly more likely to provide the required time-correlated audit trail than audit capabilities developed for specific mobile applications.
Checks: C-43646r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39823r1_fix

The requirement is NA. No fix is required.

b
Applications that utilize Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user.
AC-3 - Medium - CCI-001694 - V-35278 - SV-46565r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-001694
Version
SRG-APP-000087-MAPP-NA
Vuln IDs
  • V-35278
Rule IDs
  • SV-46565r1_rule
DAC is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user controlled file permissions. Including or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g. files, folders) on a per single user basis. Applications that utilize Discretionary Access Control (DAC) must enforce a policy that Includes or excludes access to the granularity of a single user. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, all policies specify access to the granularity of a single user by definition.
Checks: C-43647r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39824r1_fix

The requirement is NA. No fix is required.

b
The application must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format.
AU-12 - Medium - CCI-001353 - V-35279 - SV-46566r1_rule
RMF Control
AU-12
Severity
M
CCI
CCI-001353
Version
SRG-APP-000088-MAPP-NA
Vuln IDs
  • V-35279
Rule IDs
  • SV-46566r1_rule
Audits records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security-critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43648r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39825r1_fix

e requirement is NA. No fix is required.

b
The application must provide audit record generation capability for defined auditable events within defined application components.
AU-12 - Medium - CCI-000169 - V-35280 - SV-46567r1_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000169
Version
SRG-APP-000089-MAPP-NA
Vuln IDs
  • V-35280
Rule IDs
  • SV-46567r1_rule
Audit records can be generated from various components within the information system. (e.g. network interface, hard disk, modem etc.). From an application perspective, certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked). Organizations define which application components shall provide auditable events. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43649r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39826r1_fix

The requirement is NA. No fix is required.

b
The application must allow designated organizational personnel to select which auditable events are to be audited by specific components of the system.
AU-12 - Medium - CCI-000171 - V-35281 - SV-46568r1_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000171
Version
SRG-APP-000090-MAPP-NA
Vuln IDs
  • V-35281
Rule IDs
  • SV-46568r1_rule
Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked). Organizations may define the organizational personal accountable for determining which application components shall provide auditable events. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43650r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39827r1_fix

The requirement is NA. No fix is required.

b
Applications must generate audit records for the DoD selected list of auditable events.
AU-12 - Medium - CCI-000172 - V-35282 - SV-46569r1_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
SRG-APP-000091-MAPP-NA
Vuln IDs
  • V-35282
Rule IDs
  • SV-46569r1_rule
Audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). DoD shall select the list of auditable events and applications must generate audit records for those events. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43651r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39828r1_fix

The requirement is NA. No fix is required.

b
The application must initiate session auditing upon start up.
AU-14 - Medium - CCI-001464 - V-35283 - SV-46570r1_rule
RMF Control
AU-14
Severity
M
CCI
CCI-001464
Version
SRG-APP-000092-MAPP-NA
Vuln IDs
  • V-35283
Rule IDs
  • SV-46570r1_rule
Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43652r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39829r1_fix

The requirement is NA. No fix is required.

b
The application must provide the capability to capture, record, and log all content related to a user session.
AU-14 - Medium - CCI-001462 - V-35284 - SV-46571r1_rule
RMF Control
AU-14
Severity
M
CCI
CCI-001462
Version
SRG-APP-000093-MAPP-NA
Vuln IDs
  • V-35284
Rule IDs
  • SV-46571r1_rule
While a great deal of effort is made to secure applications so as to prevent unauthorized access, in certain instances there can be valid requirements to capture, record and log all content related to a particular user's application session. These instances are reserved for monitoring or investigative purposes supported through policy and are officially sanctioned. Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. These monitoring events occur at the application layer and as such maybe required to be conducted at a host system however in some cases network monitoring may be involved as well. Applications must support valid monitoring requirement capabilities performed in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. This includes the capability to capture, record and log all content related to an established user session. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43653r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39830r1_fix

The requirement is NA. No fix is required.

b
The application must provide the capability to remotely view/hear all content related to an established user session in real time.
AU-14 - Medium - CCI-001463 - V-35285 - SV-46572r1_rule
RMF Control
AU-14
Severity
M
CCI
CCI-001463
Version
SRG-APP-000094-MAPP-NA
Vuln IDs
  • V-35285
Rule IDs
  • SV-46572r1_rule
While a great deal of effort is made to secure applications so as to prevent unauthorized access, in certain instances there can be valid requirements to listen/hear or view all content related to a particular user's application session in real time as it occurs. These instances are reserved for monitoring or investigative purposes supported through policy and are officially sanctioned. Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. These monitoring events occur at the application layer and as such, maybe required to be conducted at a host system however, in some cases network monitoring may be involved as well. Applications must support valid monitoring requirement capabilities performed in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. This includes the capability to remotely view/hear all content related to an established user session in real time. Rationale for non-applicability: Any application supporting remote access is outside the scope of the SRG as the assumption is that all access to the application is local. Applications supporting remote access to the mobile device are not permitted on DoD CMD, with the exception of native OS support for mobile hotspots and USB tethering that is compliant with the MOS SRG. The SRG scope also does not cover applications which include plug-in or portable code that will make the application: (i) support multiple users; (ii) enable remote user access or administration; and (iii) provide network or application services to other nodes.
Checks: C-43654r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39831r1_fix

The requirement is NA. No fix is required.

b
The application must produce audit records containing sufficient information to establish what type of events occurred.
AU-3 - Medium - CCI-000130 - V-35286 - SV-46573r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
SRG-APP-000095-MAPP-NA
Vuln IDs
  • V-35286
Rule IDs
  • SV-46573r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43655r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39832r1_fix

The requirement is NA. No fix is required.

b
The application must produce audit records containing sufficient information to establish when (date and time) the events occurred.
AU-3 - Medium - CCI-000131 - V-35287 - SV-46574r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000131
Version
SRG-APP-000096-MAPP-NA
Vuln IDs
  • V-35287
Rule IDs
  • SV-46574r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43656r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39833r1_fix

The requirement is NA. No fix is required.

b
The application must produce audit records containing sufficient information to establish where the events occurred.
AU-3 - Medium - CCI-000132 - V-35288 - SV-46575r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000132
Version
SRG-APP-000097-MAPP-NA
Vuln IDs
  • V-35288
Rule IDs
  • SV-46575r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43657r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39834r1_fix

The requirement is NA. No fix is required.

b
The application must produce audit records containing sufficient information to establish the sources of the events.
AU-3 - Medium - CCI-000133 - V-35289 - SV-46576r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000133
Version
SRG-APP-000098-MAPP-NA
Vuln IDs
  • V-35289
Rule IDs
  • SV-46576r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited to: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. Without information establishing the source of activity, the value of audit records from a forensics perspective is questionable. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS but application developers may do so for application-specific concerns.
Checks: C-43658r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39835r1_fix

The requirement is NA. No fix is required.

b
The application must produce audit records that contain sufficient information to establish the outcome (success or failure) of the events.
AU-3 - Medium - CCI-000134 - V-35290 - SV-46577r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000134
Version
SRG-APP-000099-MAPP-NA
Vuln IDs
  • V-35290
Rule IDs
  • SV-46577r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited to: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. Success and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43659r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39836r1_fix

The requirement is NA. No fix is required.

b
The application must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event.
AU-3 - Medium - CCI-001487 - V-35291 - SV-46578r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-001487
Version
SRG-APP-000100-MAPP-NA
Vuln IDs
  • V-35291
Rule IDs
  • SV-46578r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43660r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39837r1_fix

The requirement is NA. No fix is required.

b
Applications must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.
AU-3 - Medium - CCI-000135 - V-35292 - SV-46579r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000135
Version
SRG-APP-000101-MAPP-NA
Vuln IDs
  • V-35292
Rule IDs
  • SV-46579r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked In addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events. These events may be identified by type, location, or subject. An example of detailed information that the organization may require in audit records is full-text recording of privileged commands or the individual identities of group account users. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43661r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39838r1_fix

The requirement is NA. No fix is required.

b
To support DoD requirements to centrally manage the content of audit records, applications must provide the ability to write specified audit record content to a centralized audit log repository.
AU-3 - Medium - CCI-000136 - V-35293 - SV-46580r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000136
Version
SRG-APP-000102-MAPP-NA
Vuln IDs
  • V-35293
Rule IDs
  • SV-46580r1_rule
Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. When organizations define application components requiring centralized audit log management, applications need to support that requirement. Rationale for non-applicability: The mobile operating system is best positioned to provide support for central management of audit records. Local applications can write to the local system log. If a mobile application provides this functionality, it must perform network communications with remote hosts, which creates the possibility of a remote attack on the device and audit traffic.
Checks: C-43662r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39839r1_fix

The requirement is NA. No fix is required.

b
Applications themselves, or the logging mechanism the application utilizes, must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity.
AU-5 - Medium - CCI-000143 - V-35294 - SV-46581r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000143
Version
SRG-APP-000103-MAPP-NA
Vuln IDs
  • V-35294
Rule IDs
  • SV-46581r1_rule
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. If audit log capacity were to be exceeded then events subsequently occurring will not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g. application has exceeded 80 % of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. Rationale for non-applicability: The mobile operating system is best positioned to provide support for central management of audit records. Local applications can write to the local system log. It is significantly more difficult for a system administrator to manage storage limitations on an application-by-application basis. Permitting application-specific logs is more likely to result in unreviewed audit records relative to having applications leverage device system logs.
Checks: C-43663r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39840r1_fix

The requirement is NA. No fix is required.

b
The application must provide a real-time alert when organization-defined audit failure events occur.
AU-5 - Medium - CCI-000144 - V-35295 - SV-46582r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000144
Version
SRG-APP-000104-MAPP-NA
Vuln IDs
  • V-35295
Rule IDs
  • SV-46582r1_rule
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Organizations shall define audit failure events requiring an application to send an alarm. When those defined events occur, the application will provide a real-time alert to the appropriate personnel. Rationale for non-applicability: The mobile operating system is best positioned to provide support for central management of audit records. Local applications can write to the local system log. Centralized audit systems are much more likely to be configured in a manner that facilitates meaningful incident detection and response.
Checks: C-43664r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39841r1_fix

The requirement is NA. No fix is required.

b
The application must enforce configurable traffic volume thresholds representing auditing capacity for network traffic.
AU-5 - Medium - CCI-000145 - V-35296 - SV-46583r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000145
Version
SRG-APP-000105-MAPP-NA
Vuln IDs
  • V-35296
Rule IDs
  • SV-46583r1_rule
It is critical when a system is at risk of failing to process audit logs as required; actions are automatically taken to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. One method used to thwart the auditing system is for an attacker to attempt to overwhelm the auditing system with large amounts of irrelevant data. The end result being audit logs that are either overwritten and activity thereby erased or disk space that is exhausted and any future activity is no longer logged. Applications and/or logging mechanisms employed by applications must take steps to enforce configurable volume thresholds representing the auditing capacity for network traffic. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43665r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39842r1_fix

The requirement is NA. No fix is required.

b
The application must reject or delay, as defined by the organization, network traffic generated above configurable traffic volume thresholds.
AU-5 - Medium - CCI-001574 - V-35297 - SV-46584r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-001574
Version
SRG-APP-000106-MAPP-NA
Vuln IDs
  • V-35297
Rule IDs
  • SV-46584r1_rule
It is critical when a system is at risk of failing to process audit logs as required; actions are automatically taken to mitigate the failure or risk of failure. One method used to thwart the auditing system is for an attacker to attempt to overwhelm the auditing system with large amounts of irrelevant data. The end result being audit logs that are either overwritten and activity thereby erased or disk space that is exhausted and any future activity is no longer logged. In many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage. Rationale for non-applicability: Management of network traffic volume is best addressed by the mobile device carrier or enterprise network infrastructure, or by the operating system. Even if a mobile application fully utilizes the available network throughput on a mobile device, this will not have an appreciable impact on other users. Mobile device operating systems have mechanisms to throttle data throughput for background processes. Artificially restricting the throughput of the foreground application could cause a performance issue or even a DoS.
Checks: C-43666r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39843r1_fix

The requirement is NA. No fix is required.

b
The application must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists.
AU-5 - Medium - CCI-001343 - V-35298 - SV-46585r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-001343
Version
SRG-APP-000107-MAPP-NA
Vuln IDs
  • V-35298
Rule IDs
  • SV-46585r1_rule
It is critical when a system is at risk of failing to process audit logs as required; it takes action to mitigate the failure. If the system were to continue processing without auditing enabled, actions can be taken on the system that cannot be tracked and recorded for later forensic analysis. Audit processing failures include; software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. In many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage. This forces the application to detect and take actions. Rationale for non-applicability: The mobile operating system is best positioned to provide support for central management of audit records. Permitting an application to shutdown the system in the event of an audit failure is a DoS vulnerability.
Checks: C-43667r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39844r1_fix

The requirement is NA. No fix is required.

b
The application must alert designated organizational officials in the event of an audit processing failure.
AU-5 - Medium - CCI-000139 - V-35339 - SV-46626r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000139
Version
SRG-APP-000108-MAPP-NA
Vuln IDs
  • V-35339
Rule IDs
  • SV-46626r1_rule
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include; software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Rationale for non-applicability: The mobile operating system is best positioned to provide support for management of audit failure notifications. Local applications can write to the local system log. Centralized audit systems are much more likely to be configured in a manner that facilitates meaningful incident detection and response.
Checks: C-43707r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39885r1_fix

The requirement is NA. No fix is required.

b
The application must be capable of taking organization-defined actions upon audit failure (e.g., overwrite oldest audit records, stop generating audit records, cease processing, notify of audit failure).
AU-5 - Medium - CCI-000140 - V-35340 - SV-46627r1_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000140
Version
SRG-APP-000109-MAPP-NA
Vuln IDs
  • V-35340
Rule IDs
  • SV-46627r1_rule
It is critical when a system is at risk of failing to process audit logs as required; it detects and takes action to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Applications are required to be capable of either directly performing or calling system level functionality performing defined actions upon detection of an application audit log processing failure. Rationale for non-applicability: The mobile operating system is best positioned to respond to audit failures. Local applications can write to the local system log. If a mobile application maintains its own log, it is much more likely that audits events will be lost than if these events are forwarded to a system log.
Checks: C-43708r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39886r1_fix

The requirement is NA. No fix is required.

b
To support audit review, analysis and reporting the application must integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities.
AU-6 - Medium - CCI-000152 - V-35345 - SV-46632r1_rule
RMF Control
AU-6
Severity
M
CCI
CCI-000152
Version
SRG-APP-000110-MAPP-NA
Vuln IDs
  • V-35345
Rule IDs
  • SV-46632r1_rule
Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Audit review, analysis and reporting are all activities related to the evaluation of system activity through the inspection and analysis of system log data. Some examples include but are not limited to: organizational requirements to cooperate with legal counsel and/or auditors in order to provide reports on certain types of system activity or analyzing system logs to ascertain sources or causes of certain system activity. Rationale for non-applicability: This control is required in the MDM SRG. Mobile applications can leverage the audit review, analysis, and reporting tools of centralized logging systems.
Checks: C-43713r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39891r1_fix

e requirement is NA. No fix is required.

b
Applications must provide the capability to centralize the review and analysis of audit records from multiple components within the system.
AU-6 - Medium - CCI-000154 - V-35346 - SV-46633r1_rule
RMF Control
AU-6
Severity
M
CCI
CCI-000154
Version
SRG-APP-000111-MAPP-NA
Vuln IDs
  • V-35346
Rule IDs
  • SV-46633r1_rule
Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Segregation of logging data to multiple disparate computer systems is counter-productive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems. Rationale for non-applicability: This control is required in the MDM SRG. Mobile applications can leverage the audit review, analysis, and reporting tools of centralized logging systems.
Checks: C-43715r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39893r1_fix

The requirement is NA. No fix is required.

c
The mobile application code must not include embedded interpreters for prohibited mobile code.
SC-18 - High - CCI-001695 - V-35348 - SV-46635r1_rule
RMF Control
SC-18
Severity
H
CCI
CCI-001695
Version
SRG-APP-000112-MAPP-00026
Vuln IDs
  • V-35348
Rule IDs
  • SV-46635r1_rule
Embedding interpreters for prohibited code will expose the device and stored data to all forms of malicious attacks. Prohibited code is intentionally not used in order to maintain the security and integrity of the device and all stored data. If interpreters are embedded in an application that invokes prohibited code that is either resident on the device or transferred to the device from an external server, then the device, stored data, and network are vulnerable to various forms of malicious attack. This control assures the device data stored and network of higher security as a result of inhibiting or stopping prohibited code from being executed.
Checks: C-43716r1_chk

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.

Fix: F-39894r1_fix

Modify the application architecture so it does not require embedded interpreters.

b
The application must provide an audit reduction capability.
AU-7 - Medium - CCI-000156 - V-35349 - SV-46636r1_rule
RMF Control
AU-7
Severity
M
CCI
CCI-000156
Version
SRG-APP-000113-MAPP-NA
Vuln IDs
  • V-35349
Rule IDs
  • SV-46636r1_rule
Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. Audit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis requirements and after-the-fact investigations of security incidents. Rationale for non-applicability: This control is required in the MDM SRG. Mobile applications can leverage the audit review, analysis, and reporting tools of centralized logging systems.
Checks: C-43717r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39895r1_fix

The requirement is NA. No fix is required.

b
Applications must provide a report generation capability for audit reduction data.
AU-7 - Medium - CCI-000157 - V-35350 - SV-46637r1_rule
RMF Control
AU-7
Severity
M
CCI
CCI-000157
Version
SRG-APP-000114-MAPP-NA
Vuln IDs
  • V-35350
Rule IDs
  • SV-46637r1_rule
In support of Audit Review, Analysis, and Reporting requirements, audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. Before a security review is conducted, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. In order to identify and report on what (repetitive) data has been removed via the use of audit reduction, the application must provide a capability to generate reports containing what values were removed by the audit reduction. Audit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis based on policy based requirements and after-the-fact investigations of security incidents. Reporting tools employing audit reduction methods must not alter the original audit data. An example of a tool employing audit reduction methods is the Windows Event Viewer tool which is used to view and analyze audit logs on Windows systems. Rationale for non-applicability: This control is required in the MDM SRG. Mobile applications can leverage the audit review, analysis, and reporting tools of centralized logging systems.
Checks: C-43718r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39896r1_fix

The requirement is NA. No fix is required.

b
Applications must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria.
AU-7 - Medium - CCI-000158 - V-35351 - SV-46638r1_rule
RMF Control
AU-7
Severity
M
CCI
CCI-000158
Version
SRG-APP-000115-MAPP-NA
Vuln IDs
  • V-35351
Rule IDs
  • SV-46638r1_rule
Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. An audit reduction capability provides support for near real-time audit review and analysis based on policy requirements regarding what must be audited on the system and after-the-fact investigations of security incidents. It is important to recognize audit reduction does not alter original audit records. Audit reduction and reporting tools do not alter original audit records. To leverage the complete capability of audit reduction, the application must possess the ability to specify and automatically process certain event criteria that are selectable in nature. In other words, a system administrator (SA) may be performing a manual review of audit data to identify a particular problem. The SA has determined that backup activity and network connections from a particular host comprise the bulk of the events. However, these events are not related to the activity being investigated. The application must be able to automatically process these audit records for audit reduction purposes rather than making the administrator manually process them. Rationale for non-applicability: This control is required in the MDM SRG. Mobile applications can leverage the audit review, analysis, and reporting tools of centralized logging systems.
Checks: C-43719r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39897r1_fix

The requirement is NA. No fix is required.

b
Applications must use internal system clocks to generate time stamps for audit records.
AU-8 - Medium - CCI-000159 - V-35352 - SV-46639r1_rule
RMF Control
AU-8
Severity
M
CCI
CCI-000159
Version
SRG-APP-000116-MAPP-NA
Vuln IDs
  • V-35352
Rule IDs
  • SV-46639r1_rule
Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Time stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Rationale for non-applicability: The MOS SRG contains a requirement for logging application startup and a number of other security critical events. No further audit logging must be coded into each application running on the MOS, but application developers may do so for application-specific concerns.
Checks: C-43720r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39899r1_fix

The requirement is NA. No fix is required.

a
The mobile application must use the mobile devices system time for its authoritative time source.
AU-8 - Low - CCI-000160 - V-35353 - SV-46640r1_rule
RMF Control
AU-8
Severity
L
CCI
CCI-000160
Version
SRG-APP-000117-MAPP-00027
Vuln IDs
  • V-35353
Rule IDs
  • SV-46640r1_rule
Synchronizing with authorized timing sources enables an application to perform a number of important, back-office functions that require synchronization between the application, the device, network, and back office infrastructure. If the mobile device uses a system for timing synchronization other than that for its authoritative time source, a number of issues could arise concerning control functions that must be accomplished in both short time frames and time stamping of events. This control assures the mobile application will be fully synchronized with the device's system time, which is derived from the OS. This will support accurate time stamping of events concerned with auditing; time-sensitive processes will complete and not time out; and coordinated functions between the application, device, and back office will function with greater stability and accuracy.
Checks: C-43721r1_chk

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.

Fix: F-39900r1_fix

Modify code to use the device's system time for its authoritative time source, removing any code that uses other sources.

b
The application must protect audit information from any type of unauthorized access.
AU-9 - Medium - CCI-000162 - V-35354 - SV-46641r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
SRG-APP-000118-MAPP-NA
Vuln IDs
  • V-35354
Rule IDs
  • SV-46641r1_rule
If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Rationale for non-applicability: The mobile operating system is best positioned to protect audit information from unauthorized access. System logs can be protected by nondiscretionary access control. This protects the audit records even if the root account has been compromised. Mobile applications cannot provide this level of assurance for their own logs. It is preferred that they write records to local system logs to the extent that they include audit functionality at all.
Checks: C-43722r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39901r1_fix

The requirement is NA. No fix is required.

b
The application must protect audit information from unauthorized modification.
AU-9 - Medium - CCI-000163 - V-35356 - SV-46643r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000163
Version
SRG-APP-000119-MAPP-NA
Vuln IDs
  • V-35356
Rule IDs
  • SV-46643r1_rule
If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions, and limiting log data locations. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Rationale for non-applicability: The mobile operating system is best positioned to protect audit information from unauthorized access. System logs can be protected by nondiscretionary access control. This protects the audit records even if the root account has been compromised. Mobile applications cannot provide this level of assurance for their own logs. It is preferred that they write records to local system logs to the extent that they include audit functionality at all.
Checks: C-43723r1_chk

This requirement is NA for the MAPP SRG

Fix: F-39903r1_fix

The requirement is NA. No fix is required.

b
The application must protect audit information from unauthorized deletion.
AU-9 - Medium - CCI-000164 - V-35357 - SV-46644r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000164
Version
SRG-APP-000120-MAPP-NA
Vuln IDs
  • V-35357
Rule IDs
  • SV-46644r1_rule
If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include: ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access and backing up log data to ensure log data is retained. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Rationale for non-applicability: The mobile operating system is best positioned to protect audit information from unauthorized access. System logs can be protected by nondiscretionary access control. This protects the audit records even if the root account has been compromised. Mobile applications cannot provide this level of assurance for their own logs. It is preferred that they write records to local system logs to the extent that they include audit functionality at all.
Checks: C-43724r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39904r1_fix

The requirement is NA. No fix is required.

b
The application must protect audit tools from unauthorized access.
AU-9 - Medium - CCI-001493 - V-35359 - SV-46646r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001493
Version
SRG-APP-000121-MAPP-NA
Vuln IDs
  • V-35359
Rule IDs
  • SV-46646r1_rule
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools. Audit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. Rationale for non-applicability: Audit tools are within the scope of the MDM SRG. Mobile applications are not expected to have their own audit tools. Instead, mobile applications should leverage the capabilities of centralized logging services if they include logging functionality.
Checks: C-43725r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39905r1_fix

The requirement is NA. No fix is required.

b
The application must protect audit tools from unauthorized modification.
AU-9 - Medium - CCI-001494 - V-35360 - SV-46647r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001494
Version
SRG-APP-000122-MAPP-NA
Vuln IDs
  • V-35360
Rule IDs
  • SV-46647r1_rule
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are compromised it could provide attackers with the capability to manipulate log data. It is, therefore, imperative that audit tools be controlled and protected from unauthorized modification. Audit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. Rationale for non-applicability: Audit tools are within the scope of the MDM SRG. Mobile applications are not expected to have their own audit tools. Instead, mobile applications should leverage the capabilities of centralized logging services if they include logging functionality.
Checks: C-43727r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39907r1_fix

The requirement is NA. No fix is required.

b
The application must protect audit tools from unauthorized deletion.
AU-9 - Medium - CCI-001495 - V-35363 - SV-46650r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001495
Version
SRG-APP-000123-MAPP-NA
Vuln IDs
  • V-35363
Rule IDs
  • SV-46650r1_rule
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are deleted, it would affect the administrator's ability to access and review log data. Audit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. Rationale for non-applicability: Audit tools are within the scope of the MDM SRG. Mobile applications are not expected to have their own audit tools. Instead, mobile applications should leverage the capabilities of centralized logging services if they include logging functionality.
Checks: C-43728r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39909r1_fix

The requirement is NA. No fix is required.

b
The application must have the capability to produce audit records on hardware-enforced, write-once media.
AU-9 - Medium - CCI-000165 - V-35364 - SV-46651r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000165
Version
SRG-APP-000124-MAPP-NA
Vuln IDs
  • V-35364
Rule IDs
  • SV-46651r1_rule
Applications are typically designed to incorporate their audit logs into the auditing sub-system hosted by the operating system. However, in some instances application developers may decide to forego the audit capabilities offered by the operating system and maintain application audit logs separately. The protection of audit records from unauthorized or accidental deletion or modification requires that information systems be able to produce audit records on hardware enforced write-once media. Applications that do not write audit records to a resource (e.g., underlying OS or separate system) that is capable of producing audit records on hardware enforced, write-once media must provide the capability to do so. This requirement is related to backup of records and not real-time creation of audit records. Examples of such hardware devices include, but are not limited to: CD-R or DVD-R. Rationale for non-applicability: Given the small form factor of mobile devices and the necessity to minimize the size and number of components, mobile devices are not expected to support write-once media. If audit records must be written to write-once media, this is best enforced through a centralized enterprise audit system.
Checks: C-43729r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39911r1_fix

The requirement is NA. No fix is required.

b
The application must support the requirement to back up audit data and records onto a different system or media than the system being audited on an organization-defined frequency.
AU-9 - Medium - CCI-001348 - V-35365 - SV-46652r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001348
Version
SRG-APP-000125-MAPP-NA
Vuln IDs
  • V-35365
Rule IDs
  • SV-46652r1_rule
Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained. Rationale for non-applicability: This control is required in the MDM SRG. Mobile applications can leverage the audit review, analysis, and reporting tools of centralized logging systems.
Checks: C-43731r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39913r1_fix

The requirement is NA. No fix is required.

b
The application must protect the audit records generated as a result of remote accesses to privileged accounts and the execution of privileged functions.
AU-9 - Medium - CCI-001352 - V-35367 - SV-46654r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001352
Version
SRG-APP-000127-MAPP-NA
Vuln IDs
  • V-35367
Rule IDs
  • SV-46654r1_rule
Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place. Auditing might not be reliable when performed by an information system which the user being audited has privileged access to. The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus, limiting the users with audit-related privileges. Reducing the risk of audit compromises by privileged users can also be achieved, for example, by performing audit activity on a separate information system where the user in question has limited access or by using storage media that cannot be modified (e.g., write-once recording devices). Rationale for non-applicability: Mobile applications that support remote access are outside the scope of this SRG. Applications supporting remote access are not permitted on DoD CMD.
Checks: C-43732r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39914r1_fix

The requirement is NA. No fix is required.

b
The mobile application must not change the file permissions of any files other than those dedicated to its own operation.
CM-5 - Medium - CCI-000345 - V-35369 - SV-46656r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-000345
Version
SRG-APP-000128-MAPP-00028
Vuln IDs
  • V-35369
Rule IDs
  • SV-46656r1_rule
A file's access level is pivotal to a mobile application 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.
Checks: C-43733r1_chk

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.

Fix: F-39915r1_fix

Modify the code so it does not change the file permission on any files not dedicated to the mobile application's operation.

b
The mobile application must implement automated mechanisms to enforce access control restrictions which are not provided by the operating system
CM-5 - Medium - CCI-000346 - V-35370 - SV-46657r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-000346
Version
SRG-APP-000129-MAPP-00029
Vuln IDs
  • V-35370
Rule IDs
  • SV-46657r1_rule
Applications often have additional access control requirements beyond those provided by the operating system. For example, a contact or key database may contain particular sensitive records that require additional levels of authentication beyond device unlock. When access control mechanisms are not automated, they are much less likely to be properly enforced. Users may either inadvertently fail to enforce the restrictions or intentionally do so as a matter of convenience. Without the proper enforcement of controls, it is more likely that DoD data will be disclosed in an unauthorized manner. Automated enforcement of access controls significantly reduces the risk of unauthorized disclosure of data. There are various ways to implement automated mechanisms. Mandatory access control (MAC) provides the greatest assurance because the user has no discretion in this framework. Other automated controls might include file permissions or cryptography.
Checks: C-43735r1_chk

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.

Fix: F-39918r1_fix

Modify code to implement automated enforcement of access control not provided by the operating system.

b
The application must support the employment of automated mechanisms supporting the auditing of enforcement actions.
CM-5 - Medium - CCI-000347 - V-35372 - SV-46659r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-000347
Version
SRG-APP-000130-MAPP-NA
Vuln IDs
  • V-35372
Rule IDs
  • SV-46659r1_rule
Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Access restrictions for change also include software libraries. Examples of access restrictions include: physical and logical access controls, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). Rationale for non-applicability: The mobile operating system is best positioned to supporting auditing of enforcement actions, most of which are related to OS controls. One reason for this is that system logs can be protected by nondiscretionary access control. This protects the audit records even if the root account has been compromised. Mobile applications cannot provide this level of assurance for their own logs. It is preferred that they write records to local system logs.
Checks: C-43736r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39919r1_fix

The requirement is NA. No fix is required.

b
Applications must prevent the installation of organization-defined critical software programs not signed with a certificate that has been recognized and approved by the organization.
CM-5 - Medium - CCI-000352 - V-35374 - SV-46661r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-000352
Version
SRG-APP-000131-MAPP-NA
Vuln IDs
  • V-35374
Rule IDs
  • SV-46661r1_rule
Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, software defined by the organization as critical software may be signed with a certificate recognized and approved by the organization. Examples of critical software programs and/or modules include, for example, patches, service packs, software libraries and where applicable, device drivers. Rationale for non-applicability: This control is required in the MOS SRG. The operating system must control the installation of software to protect itself and other applications. Application enforcement mechanisms are vulnerable to breach by OS privileged processes.
Checks: C-43737r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39920r1_fix

The requirement is NA. No fix is required.

b
The application must support the enforcement of a two-person rule for changes to organization-defined application components and system-level information.
CM-5 - Medium - CCI-000354 - V-35375 - SV-46662r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-000354
Version
SRG-APP-000132-MAPP-NA
Vuln IDs
  • V-35375
Rule IDs
  • SV-46662r1_rule
Regarding access restrictions for changes made to organization defined information system components and system level information. Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. A two person rule requires two separate individuals acknowledge and approve those changes. Two person rule for changes to critical application components helps to reduce risks pertaining to availability and integrity. Rationale for non-applicability: This SRG applies to single-user applications. Enforcement of a two-person rule is not feasible in this context.
Checks: C-43738r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39921r1_fix

The requirement is NA. No fix is required.

b
The mobile application must not enable other applications or non-privileged processes to modify software libraries.
CM-5 - Medium - CCI-001499 - V-35377 - SV-46664r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001499
Version
SRG-APP-000133-MAPP-00030
Vuln IDs
  • V-35377
Rule IDs
  • SV-46664r1_rule
Many applications often leverage software libraries to perform application functions. If the application makes these library files world writeable or otherwise allows unauthorized changes, then other processes on the device could modify the library to give the application capabilities it did not have originally. These capabilities might enable the application to exfiltrate sensitive DoD information or permit privilege escalation, possibly leading to attacks on additional systems. Libraries could be modified through enabling other applications to do so or through the application itself allowing the user to do so. Implementing this control prevents applications 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.
Checks: C-43740r1_chk

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.

Fix: F-39924r1_fix

Modify the code or installation configuration files to limit an application's access to its software libraries to the application only.

b
Applications must automatically implement organization-defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately.
CM-5 - Medium - CCI-001500 - V-35378 - SV-46665r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001500
Version
SRG-APP-000134-MAPP-NA
Vuln IDs
  • V-35378
Rule IDs
  • SV-46665r1_rule
Any changes to the application components of the information system can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to the application components for purposes of initiating changes, including upgrades and modifications. In order to ensure a prompt response to unauthorized changes to application security functions or security mechanisms, organizations may define countermeasures and safeguards that monitoring applications must undertake in the event these types of changes occur. This degree of functionality is typically built into a support architecture providing change management and/or system monitoring capabilities. Automatic implementation of safeguards and countermeasures includes: reversing the change; halting the system; or triggering an audit alert when an unauthorized modification to a critical security file or process occurs. Examples of such support architecture include but are not limited to: HIDS, change management software or file/process monitoring software. Rationale for non-applicability: The mobile OS is best positioned to detect and respond to inappropriate changes in security functions. In most cases, the application is not able to assess the integrity of security functions because the operating system does not expose this information to the application.
Checks: C-43741r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39925r1_fix

The requirement is NA. No fix is required.

b
Configuration management applications must employ automated mechanisms to centrally manage configuration settings.
CM-6 - Medium - CCI-000370 - V-35379 - SV-46666r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000370
Version
SRG-APP-000135-MAPP-NA
Vuln IDs
  • V-35379
Rule IDs
  • SV-46666r1_rule
Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each and every system when making application configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of systems and applications in a large scale environment. To support this requirement, configuration management applications will employ automated mechanisms to centrally manage configuration settings and applications, in general, will ensure that they do not hinder the use of such tools. Rationale for non-applicability: Configuration management applications are within the scope of the MDM SRG.
Checks: C-43743r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39926r1_fix

The requirement is NA. No fix is required.

b
Configuration management applications must employ automated mechanisms to centrally apply configuration settings.
CM-6 - Medium - CCI-000371 - V-35382 - SV-46669r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000371
Version
SRG-APP-000136-MAPP-NA
Vuln IDs
  • V-35382
Rule IDs
  • SV-46669r1_rule
Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of systems and applications in a large scale environment. Centrally apply means to apply settings from a centralized location. In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies. This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution. To support this requirement, configuration management applications will employ automated mechanisms to centrally apply configuration settings and applications in general will ensure they do not hinder the use of such tools. Rationale for non-applicability: Configuration management applications are within the scope of the MDM SRG.
Checks: C-43744r1_chk

This requirement is NA for the MAPP SRG

Fix: F-39928r1_fix

The requirement is NA. No fix is required.

b
Configuration management applications must employ automated mechanisms to centrally verify configuration settings.
CM-6 - Medium - CCI-000372 - V-35383 - SV-46670r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000372
Version
SRG-APP-000137-MAPP-NA
Vuln IDs
  • V-35383
Rule IDs
  • SV-46670r1_rule
Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system, including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of systems and applications in a large scale environment. Centrally verify means to verify settings have taken effect from a centralized location. In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies. This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution. To support this requirement, configuration management applications will employ automated mechanisms to centrally verify configuration settings and applications in general will ensure they do not hinder the use of such tools. Rationale for non-applicability: Configuration management applications are within the scope of the MDM SRG.
Checks: C-43745r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39930r1_fix

The requirement is NA. No fix is required.

b
Configuration management applications must employ automated mechanisms to centrally respond to unauthorized changes to configuration settings.
CM-6 - Medium - CCI-000374 - V-35385 - SV-46672r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000374
Version
SRG-APP-000138-MAPP-NA
Vuln IDs
  • V-35385
Rule IDs
  • SV-46672r1_rule
Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system, including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Responses to unauthorized changes to configuration settings can include: alerting designated organizational personnel, restoring mandatory/organization-defined configuration settings, or in the extreme case, halting affected information system processing. Centrally respond means to respond to unauthorized changes to settings have taken effect from a centralized location. In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies. This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution. Rationale for non-applicability: Configuration management applications are within the scope of the MDM SRG.
Checks: C-43746r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39931r1_fix

The requirement is NA. No fix is required.

b
Configuration management solutions must track unauthorized, security-relevant configuration changes.
CM-6 - Medium - CCI-001589 - V-35386 - SV-46673r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-001589
Version
SRG-APP-000139-MAPP-NA
Vuln IDs
  • V-35386
Rule IDs
  • SV-46673r1_rule
Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Incident Response teams require input from authoritative sources in order to investigate events that have occurred. Configuration management solutions are a logical source for providing information regarding system configuration changes. Unauthorized, security-relevant configuration changes must be incorporated into the organization's incident response capability to ensure such detected events are tracked for historical purposes. Rationale for non-applicability: Configuration management applications are within the scope of the MDM SRG.
Checks: C-43747r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39933r1_fix

The requirement is NA. No fix is required.

b
The application must enforce requirements for remote connections to the information system.
AC-17 - Medium - CCI-000066 - V-35388 - SV-46675r1_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000066
Version
SRG-APP-000140-MAPP-NA
Vuln IDs
  • V-35388
Rule IDs
  • SV-46675r1_rule
Applications that provide remote access to information systems must be able to enforce remote access policy requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Examples of policy requirements include but are not limited to; Authorizing remote access to the information system, limiting access based on authentication credentials and monitoring for unauthorized access. Rationale for non-applicability: Applications that support remote access to the mobile device are outside the scope of this SRG. The SRG does not cover mobile applications that perform server functions.
Checks: C-43748r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39934r1_fix

The requirement is NA. No fix is required.

b
The mobile application must not include source code never invoked during operation, except for software components and libraries from approved third-party products.
CM-7 - Medium - CCI-000381 - V-35391 - SV-46678r1_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
SRG-APP-000141-MAPP-00031
Vuln IDs
  • V-35391
Rule IDs
  • SV-46678r1_rule
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 application 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.
Checks: C-43749r2_chk

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.

Fix: F-39937r1_fix

Modify code to remove unused code, unused variables, and expressions whose logical state persists.

b
The mobile application must not utilize ports or protocols in a manner inconsistent with DoD Ports and Protocols guidance.
CM-7 - Medium - CCI-000382 - V-35392 - SV-46679r1_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
SRG-APP-000142-MAPP-00032
Vuln IDs
  • V-35392
Rule IDs
  • SV-46679r1_rule
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 application. Ports that are incorrectly used leave the application 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 application 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.
Checks: C-43750r1_chk

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.

Fix: F-39939r1_fix

Modify code that the mobile application uses ports, protocols, and services in accordance with the DoD PPSM.

b
To support the requirements and principles of least functionality, the application must support organizational requirements regarding the use of automated mechanisms preventing program execution on the information system in accordance with the organization defined specifications.
CM-7 - Medium - CCI-000386 - V-35394 - SV-46681r1_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000386
Version
SRG-APP-000143-MAPP-NA
Vuln IDs
  • V-35394
Rule IDs
  • SV-46681r1_rule
Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Standard operating procedure for placing an information system into a production environment includes creating a baseline configuration of the system. The baseline configuration provides information about the components of the information system (e.g., the standard software load for a workstation, server, network component, or mobile device including operating system/installed applications with current version numbers and patch information), network topology, and the logical placement of the component within the system architecture. It is sometimes convenient to provide multiple services from a single information system, but doing so increases risk when compared to limiting the services provided by any one system. This is particularly true when these services have conflicting missions, user communities or availability requirements. This requirement addresses the need to provide an automated mechanism that will prevent the execution of programs not associated with the established baseline configuration. This is a requirement to disable services as part of the baseline process and provide automated tools that monitor the system and prevent unauthorized system processes from executing. This requirement will apply to configuration management applications, HIDS applications and other similar types of applications designed to manage system processes and configurations. Rationale for non-applicability: Per the MOS SRG, the mobile operating system has automated mechanisms to prevent unauthorized program execution. Mobile apps on most commercial mobile OS run as a single executable, which precludes the ability to prevent program execution -- i.e., one would have to execute the program to implement the mechanisms to prevent execution, which is contradictory.
Checks: C-43751r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39940r1_fix

The requirement is NA. No fix is required.

b
The mobile application must implement transaction recovery if it is transaction based.
CP-10 - Medium - CCI-000553 - V-35396 - SV-46683r1_rule
RMF Control
CP-10
Severity
M
CCI
CCI-000553
Version
SRG-APP-000144-MAPP-00033
Vuln IDs
  • V-35396
Rule IDs
  • SV-46683r1_rule
Transaction based systems must have transaction rollback and transaction journaling, or technical equivalents implemented to ensure the system can recover from an attack or faulty transaction data. A transaction based application that has just recovered from an attack or has crashed due to erroneous transaction data is vulnerable to a denial of service attack. This control mitigates the risk of denial of service attacks following the recovery of an application crash or unexpected termination.
Checks: C-43752r1_chk

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.

Fix: F-39941r1_fix

Implement rollback and journaling features in the application or incorporate products with rollback and journaling features.

b
Backup / Disaster Recovery oriented applications must be capable of backing up user-level information per a defined frequency.
CP-9 - Medium - CCI-000535 - V-35397 - SV-46684r1_rule
RMF Control
CP-9
Severity
M
CCI
CCI-000535
Version
SRG-APP-000145-MAPP-NA
Vuln IDs
  • V-35397
Rule IDs
  • SV-46684r1_rule
Information system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD defined frequency. Rationale for non-applicability: Mobile OSs implement application sandboxing, which precludes the ability of a backup application to backup data from other applications. Some data in designated OS resources (e.g., the contact database) may be accessible to all applications, in which case there is no issue as to whether an application can back up the data on an organization-defined frequency.
Checks: C-43753r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39942r1_fix

The requirement is NA. No fix is required.

a
The mobile application 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.
CP-9 - Low - CCI-000537 - V-35398 - SV-46685r1_rule
RMF Control
CP-9
Severity
L
CCI
CCI-000537
Version
SRG-APP-000146-MAPP-00034
Vuln IDs
  • V-35398
Rule IDs
  • SV-46685r1_rule
If the application is able to lock files or modify file permissions in a manner that prevents higher-level system operations, such as backup and copying to take 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 over-arching control and functional procedures, above any privileges the application, 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 applications from reading the files (e.g., by setting files to world readable).
Checks: C-43754r1_chk

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.

Fix: F-39943r1_fix

Modify code so the MOS or approved backup application is not prevented from copying application files.

b
The application must support and must not impede organizational requirements to conduct backups of information system documentation including security-related documentation per organization-defined frequency.
CP-9 - Medium - CCI-000539 - V-35399 - SV-46686r1_rule
RMF Control
CP-9
Severity
M
CCI
CCI-000539
Version
SRG-APP-000147-MAPP-NA
Vuln IDs
  • V-35399
Rule IDs
  • SV-46686r1_rule
Information system backup is a critical step in maintaining data assurance and availability. Information system and security related documentation contains information pertaining to system configuration and security settings. Backups shall be consistent with organizational recovery time and recovery point objectives. Rationale for non-applicability: Mobile applications are presumed not to have local documentation. In most cases, this documentation would not be accessible to users if stored locally because applications do not have native document readers. If the local documentation were accessible by a document reader outside of the application, then any security information in that documentation would be vulnerable to disclosure.
Checks: C-43755r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39945r1_fix

The requirement is NA. No fix is required.

b
The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
IA-2 - Medium - CCI-000764 - V-35401 - SV-46688r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
SRG-APP-000148-MAPP-NA
Vuln IDs
  • V-35401
Rule IDs
  • SV-46688r1_rule
To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the information system without identification or authentication. Rationale for non-applicability: An assumption of this SRG is that a single user will be operating the mobile device, eliminating the need to uniquely authenticate organizational users. If a local application interacts with a remote enterprise application, the remote application will perform the authentication transaction. Permitting the local application to perform the authentication on behalf of the remote application would be an improper delegation of trust.
Checks: C-43756r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39947r1_fix

The requirement is NA. No fix is required.

b
The application must use multifactor authentication for network access to privileged accounts.
IA-2 - Medium - CCI-000765 - V-35402 - SV-46689r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000765
Version
SRG-APP-000149-MAPP-NA
Vuln IDs
  • V-35402
Rule IDs
  • SV-46689r1_rule
Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as: An information system account with authorizations of a privileged user. Network Access is defined as: Access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). Rationale for non-applicability: This SRG applies to single-user applications. Applications will not be remotely accessed.
Checks: C-43757r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39948r1_fix

The requirement is NA. No fix is required.

b
The application must use multifactor authentication for network access to non-privileged accounts.
IA-2 - Medium - CCI-000766 - V-35405 - SV-46692r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000766
Version
SRG-APP-000150-MAPP-NA
Vuln IDs
  • V-35405
Rule IDs
  • SV-46692r1_rule
Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A non-privileged account is defined as: An information system account with authorizations of a regular or non-privileged user. Network Access is defined as: Access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43758r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39950r1_fix

The requirement is NA. No fix is required.

b
The application must use multifactor authentication for local access to privileged accounts.
IA-2 - Medium - CCI-000767 - V-35407 - SV-46694r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000767
Version
SRG-APP-000151-MAPP-NA
Vuln IDs
  • V-35407
Rule IDs
  • SV-46694r1_rule
Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Local Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Rationale for non-applicability: This SRG applies to single-user applications. These users do not have privileged accounts.
Checks: C-43759r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39952r1_fix

The requirement is NA. No fix is required.

b
The application must use multifactor authentication for local access to non-privileged accounts.
IA-2 - Medium - CCI-000768 - V-35408 - SV-46695r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000768
Version
SRG-APP-000152-MAPP-NA
Vuln IDs
  • V-35408
Rule IDs
  • SV-46695r1_rule
Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. Local Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device.
Checks: C-43760r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39953r1_fix

The requirement is NA. No fix is required.

b
Applications authenticating users must ensure users are authenticated with an individual authenticator prior to using a group authenticator.
IA-2 - Medium - CCI-000770 - V-35410 - SV-46697r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000770
Version
SRG-APP-000153-MAPP-NA
Vuln IDs
  • V-35410
Rule IDs
  • SV-46697r1_rule
To assure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated. A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. An example of a group authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'sa' account or a "helpdesk" account. For example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator. Some applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information. These types of accesses are allowed but must be explicitly identified and documented by the organization. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not support group authenticators.
Checks: C-43762r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39954r1_fix

The requirement is NA. No fix is required.

b
Applications using multifactor authentication when accessing privileged accounts via the network must provide one of the factors by a device that is separate from the information system gaining access.
IA-2 - Medium - CCI-000771 - V-35411 - SV-46698r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000771
Version
SRG-APP-000154-MAPP-NA
Vuln IDs
  • V-35411
Rule IDs
  • SV-46698r1_rule
Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as; any access to an information system by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Out Of Band 2 factor Authentication (OOB2FA) is defined as: when one of the authentication factors is provided by a device that is separate from the system that is used to gain access. For example, a mobile device such as a smart phone is registered within the application to an application user. Upon a successful authentication, the system sends instructions to the registered mobile device in the form of on-screen prompts instructing the user on how to complete the login process. OOB2FA employs separate communication channels where at least one is independently maintained and trusted to authenticate an end user. Applications using multifactor authentication when accessing privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43763r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39955r1_fix

The requirement is NA. No fix is required.

b
Applications using multifactor authentication when accessing non-privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access.
IA-2 - Medium - CCI-000772 - V-35412 - SV-46699r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000772
Version
SRG-APP-000155-MAPP-NA
Vuln IDs
  • V-35412
Rule IDs
  • SV-46699r1_rule
Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a non-privileged user or simply, a regular user. Network access is defined as any access to an information system by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Out Of Band 2 Factor Authentication is defined as: when one of the authentication factors is provided by a device that is separate from the system that is used to gain access. For example, a mobile device such as a smart phone is registered within the application to an application user. Upon a successful authentication, the system sends instructions to the registered mobile device in the form of on-screen prompts instructing the user on how to complete the login process. OOB2FA employs separate communication channels where at least one is independently maintained and trusted to authenticate an end user. Applications using multifactor authentication when accessing non-privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43764r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39956r1_fix

The requirement is NA. No fix is required.

b
The application must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts.
IA-2 - Medium - CCI-000774 - V-35413 - SV-46700r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000774
Version
SRG-APP-000156-MAPP-NA
Vuln IDs
  • V-35413
Rule IDs
  • SV-46700r1_rule
An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonce's (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43765r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39957r1_fix

The requirement is NA. No fix is required.

b
The application must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts.
IA-2 - Medium - CCI-000776 - V-35414 - SV-46701r1_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000776
Version
SRG-APP-000157-MAPP-NA
Vuln IDs
  • V-35414
Rule IDs
  • SV-46701r1_rule
An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonce's (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. Rationale for non-applicability: The MOS SRG prohibits remote access to the mobile device. Similarly, mobile applications that support remote access are not within the scope of the MAPP SRG.
Checks: C-43766r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39958r1_fix

The requirement is NA. No fix is required.

b
Applications required to identify devices must uniquely identify and authenticate an organization-defined list of specific and/or types of devices before establishing a connection.
IA-3 - Medium - CCI-000778 - V-35416 - SV-46703r1_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000778
Version
SRG-APP-000158-MAPP-NA
Vuln IDs
  • V-35416
Rule IDs
  • SV-46703r1_rule
Device authentication is a solution enabling an organization to manage both users and devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43767r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39960r1_fix

The requirement is NA. No fix is required.

b
Applications managing devices must authenticate devices before establishing remote network connections using bidirectional authentication between devices that are cryptographically based.
IA-3 - Medium - CCI-000779 - V-35417 - SV-46704r1_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000779
Version
SRG-APP-000159-MAPP-NA
Vuln IDs
  • V-35417
Rule IDs
  • SV-46704r1_rule
Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. Remote network connection is any connection with a device communicating through an external network (e.g., the Internet). Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43768r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39961r1_fix

The requirement is NA. No fix is required.

b
The mobile application must authenticate devices using bidirectional cryptographic authentication if it manages wireless network connections for other devices.
IA-3 - Medium - CCI-000780 - V-35418 - SV-46705r1_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000780
Version
SRG-APP-000160-MAPP-00035
Vuln IDs
  • V-35418
Rule IDs
  • SV-46705r1_rule
If a wireless device authenticates on a network without using encryption to protect the authentication data, then the device is vulnerable to intruders who will perform either replay or man-in-the-middle and spoofing attacks, as well as the many other attacks that take advantage of weak or no encryption. Intruders who exploit these weaknesses can launch further attacks on other network components and attempt to gain control of the network. Bidirectional authentication greatly mitigates the risk that the mobile application will allow connections from unauthorized devices and helps prevent remote devices from improperly connecting to a rogue network. One of the assumptions of the MAPP SRG is that an application does not perform server functions or support remote devices. This control addresses the exception to that general assumption, namely applications that support permitted personal hotspots or alternative technology that bridges connections to networks without permitting access to the device itself.
Checks: C-43770r1_chk

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.

Fix: F-39963r1_fix

Modify code to support the use of bidirectional cryptographic authentication.

b
Applications managing network connectivity must have the capability to authenticate devices before establishing network connections by using bidirectional authentication that is cryptographically based.
IA-3 - Medium - CCI-000781 - V-35455 - SV-46742r1_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000781
Version
SRG-APP-000161-MAPP-NA
Vuln IDs
  • V-35455
Rule IDs
  • SV-46742r1_rule
Device authentication is a solution enabling an organization to manage both users and devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43809r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39998r1_fix

The requirement is NA. No fix is required.

b
Web services applications establishing identities at run-time for previously unknown entities must dynamically manage identifiers, attributes, and associated access authorizations.
IA-4 - Medium - CCI-000802 - V-35457 - SV-46744r1_rule
RMF Control
IA-4
Severity
M
CCI
CCI-000802
Version
SRG-APP-000162-MAPP-NA
Vuln IDs
  • V-35457
Rule IDs
  • SV-46744r1_rule
Web services are web applications providing a method of communication between two or more different electronic devices. They are normally used by applications to provide each other with data. The W3C defines a web service as: "a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically Web Services Description Language or WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards". Web services provide different challenges in managing access than what is presented by typical user based applications. In contrast to conventional access control approaches which employ static information system accounts and predefined sets of user privileges, many service-oriented architecture implementations rely on run time access control decisions facilitated by dynamic privilege management. While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. In contrast to conventional approaches to identification and authentication which employ static information system accounts for preregistered users, many service-oriented architecture implementations rely on establishing identities at run time for entities that were previously unknown. Dynamic establishment of identities and association of attributes and privileges with these identities are anticipated and provisioned. Pre-established trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential. Rationale for non-applicability: Mobile applications that perform service functions are outside the scope of this SRG. Therefore, web services applications are not applicable.
Checks: C-43810r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-39999r1_fix

The requirement is NA. No fix is required.

b
Applications must support organizational requirements to disable user accounts after an organization-defined time period of inactivity.
IA-4 - Medium - CCI-000795 - V-35458 - SV-46745r1_rule
RMF Control
IA-4
Severity
M
CCI
CCI-000795
Version
SRG-APP-000163-MAPP-NA
Vuln IDs
  • V-35458
Rule IDs
  • SV-46745r1_rule
Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly, particularly if the anomaly is related to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive user account can potentially obtain and maintain undetected access to an application. Applications need to track periods of user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or will have data compromised. Management of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual. To avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. Rationale for non-applicability: This SRG applies to single-user applications. Single-user applications do not require account management.
Checks: C-43811r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40000r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce minimum password length.
IA-5 - Medium - CCI-000205 - V-35459 - SV-46746r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000205
Version
SRG-APP-000164-MAPP-NA
Vuln IDs
  • V-35459
Rule IDs
  • SV-46746r1_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password is, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43812r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40001r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to prohibit password reuse for the organization-defined number of generations.
IA-5 - Medium - CCI-000200 - V-35460 - SV-46747r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000200
Version
SRG-APP-000165-MAPP-NA
Vuln IDs
  • V-35460
Rule IDs
  • SV-46747r1_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43813r2_chk

This requirement is NA for the MAPP SRG.

Fix: F-40002r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce password complexity by the number of upper case characters used.
IA-5 - Medium - CCI-000192 - V-35462 - SV-46749r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000192
Version
SRG-APP-000166-MAPP-NA
Vuln IDs
  • V-35462
Rule IDs
  • SV-46749r1_rule
Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements
Checks: C-43814r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40003r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce password complexity by the number of lower case characters used.
IA-5 - Medium - CCI-000193 - V-35465 - SV-46752r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000193
Version
SRG-APP-000167-MAPP-NA
Vuln IDs
  • V-35465
Rule IDs
  • SV-46752r1_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43816r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40004r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce password complexity by the number of numeric characters used.
IA-5 - Medium - CCI-000194 - V-35466 - SV-46753r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000194
Version
SRG-APP-000168-MAPP-NA
Vuln IDs
  • V-35466
Rule IDs
  • SV-46753r1_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43817r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40006r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce password complexity by the number of special characters used.
IA-5 - Medium - CCI-001619 - V-35467 - SV-46754r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-001619
Version
SRG-APP-000169-MAPP-NA
Vuln IDs
  • V-35467
Rule IDs
  • SV-46754r1_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43818r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40007r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce the number of characters that get changed when passwords are changed.
IA-5 - Medium - CCI-000195 - V-35468 - SV-46755r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000195
Version
SRG-APP-000170-MAPP-NA
Vuln IDs
  • V-35468
Rule IDs
  • SV-46755r1_rule
Passwords need to be changed at specific policy based intervals. If the information system or application allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that has not had enough elements changed to meet the policy requirements. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43819r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40008r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce password encryption for storage.
IA-5 - Medium - CCI-000196 - V-35469 - SV-46756r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000196
Version
SRG-APP-000171-MAPP-NA
Vuln IDs
  • V-35469
Rule IDs
  • SV-46756r1_rule
Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission. Rationale for non-applicability: The MAPP SRG does not require user authentication for local applications. In the case of mobile applications that connect to remote servers, the password should be stored on the remote server in an encrypted format and not on the local device. Accordingly, there are no stored passwords that require encryption
Checks: C-43820r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40009r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to enforce password encryption for transmission.
IA-5 - Medium - CCI-000197 - V-35470 - SV-46757r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000197
Version
SRG-APP-000172-MAPP-NA
Vuln IDs
  • V-35470
Rule IDs
  • SV-46757r1_rule
Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission. Rationale for non-applicability: The MAPP SRG does not have a requirement for user authentication to local applications, which obviates the need for passwords. To the extent the local application facilitates user authentication to a remote application, the remote application can enforce a variety of mechanisms to protect the password, including encryption of passwords using SSL/TLS.
Checks: C-43821r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40010r1_fix

The requirement is NA. No fix is required.

b
Applications must enforce password minimum lifetime restrictions.
IA-5 - Medium - CCI-000198 - V-35471 - SV-46758r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000198
Version
SRG-APP-000173-MAPP-NA
Vuln IDs
  • V-35471
Rule IDs
  • SV-46758r1_rule
Password minimum lifetime is defined as: the minimum period of time, (typically in days) a user's password must be in effect before the user can change it. Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy based intervals, however if the application allows the user to immediately and continually change their password then the password could be repeatedly changed in a short period of time so as to defeat the organizations policy regarding password reuse. This would allow users to keep using the same password over and over again by immediately changing their password X number of times. This would effectively negate password policy. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the mobile application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43822r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40011r1_fix

The requirement is NA. No fix is required.

b
Applications must enforce password maximum lifetime restrictions.
IA-5 - Medium - CCI-000199 - V-35472 - SV-46759r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000199
Version
SRG-APP-000174-MAPP-NA
Vuln IDs
  • V-35472
Rule IDs
  • SV-46759r1_rule
Password maximum lifetime is defined as: the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. Passwords need to be changed at specific policy based intervals as per policy. Any password no matter how complex can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords there is the risk that the system and/or application passwords could be compromised. Rationale for non-applicability: This SRG does not impose any requirements for local authentication to mobile applications. Authentication to the mobile device is an acceptable proxy for authentication to the application on a single-user device. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements.
Checks: C-43823r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40012r1_fix

The requirement is NA. No fix is required.

b
The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor.
IA-5 - Medium - CCI-000185 - V-35473 - SV-46760r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000185
Version
SRG-APP-000175-MAPP-NA
Vuln IDs
  • V-35473
Rule IDs
  • SV-46760r1_rule
A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes, certificate revocation lists or online certificate status protocol responses. Rationale for non-applicability: There is no requirement for a user to authenticate to the mobile application because the operating system has already authenticated the user. Additionally, the scope of the MAPP SRG excludes mobile applications that serve external users and processes. Thus, no external users or processes would authenticate to the mobile application using certificates or otherwise.
Checks: C-43824r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40013r1_fix

The requirement is NA. No fix is required.

b
The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key.
IA-5 - Medium - CCI-000186 - V-35474 - SV-46761r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000186
Version
SRG-APP-000176-MAPP-NA
Vuln IDs
  • V-35474
Rule IDs
  • SV-46761r1_rule
The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. Rationale for non-applicability: This control is required in the MOS SRG. The mobile application should leverage the key storage capabilities of the mobile device OS whenever feasible. Applications are unable to provide the same level of IA as the OS for private key storage because privileged accounts may be able to override application permissions.
Checks: C-43826r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40015r1_fix

The requirement is NA. No fix is required.

b
Applications must ensure that PKI-based authentication maps the authenticated identity to the user account.
IA-5 - Medium - CCI-000187 - V-35475 - SV-46762r1_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000187
Version
SRG-APP-000177-MAPP-NA
Vuln IDs
  • V-35475
Rule IDs
  • SV-46762r1_rule
The cornerstone of the PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information. Rationale for non-applicability: This SRG does not apply to mobile applications that perform server functions. Therefore, the mobile application would never map an identity to a user account. If the mobile application connects to a remote enterprise application requiring PKI authentication, then the remote application will perform the requisite mapping.
Checks: C-43827r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40016r1_fix

The requirement is NA. No fix is required.

b
The application must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.
IA-6 - Medium - CCI-000206 - V-35504 - SV-46791r1_rule
RMF Control
IA-6
Severity
M
CCI
CCI-000206
Version
SRG-APP-000178-MAPP-NA
Vuln IDs
  • V-35504
Rule IDs
  • SV-46791r1_rule
To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information. Rationale for non-applicability: User authentication functions are outside the scope of the MAPP SRG.
Checks: C-43840r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40041r1_fix

The requirement is NA. No fix is required.

b
The application must use mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.
IA-7 - Medium - CCI-000803 - V-35505 - SV-46792r1_rule
RMF Control
IA-7
Severity
M
CCI
CCI-000803
Version
SRG-APP-000179-MAPP-NA
Vuln IDs
  • V-35505
Rule IDs
  • SV-46792r1_rule
Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. Applications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 is the current standard for validating cryptographic modules and NSA Type-X (where X=1, 2, 3, 4) products are NSA certified hardware based encryption modules. Rationale for non-applicability: In most cases, the mobile OS or third party product provided cryptographic support to mobile applications. In these cases, both the application and cryptographic module are trusted and do not require authentication. When a mobile application contains its own cryptographic module, the code is embedded in the application, obviating the need for authentication. When the cryptographic module is native to the MOS, the MOS SRG covers this control. Other IA controls address requirements for FIPS 140-2 validation generally.
Checks: C-43845r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40046r1_fix

The requirement is NA. No fix is required.

b
The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
IA-8 - Medium - CCI-000804 - V-35506 - SV-46793r1_rule
RMF Control
IA-8
Severity
M
CCI
CCI-000804
Version
SRG-APP-000180-MAPP-NA
Vuln IDs
  • V-35506
Rule IDs
  • SV-46793r1_rule
Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Non-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server. Accordingly, a risk assessment is used in determining the authentication needs of the organization. Scalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation. Rationale for non-applicability: The MAPP SRG does not have a requirement for user authentication, so consequently authentication of non-organizational users is also out of scope. In general, non-DoD users will not use or access DoD CMD.
Checks: C-43846r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40047r1_fix

The requirement is NA. No fix is required.

b
Applications that are designed and intended to address incident response scenarios must provide a configurable capability to automatically disable an information system if any of the organization defined security violations are detected.
IR-4 - Medium - CCI-000831 - V-35507 - SV-46794r1_rule
RMF Control
IR-4
Severity
M
CCI
CCI-000831
Version
SRG-APP-000181-MAPP-NA
Vuln IDs
  • V-35507
Rule IDs
  • SV-46794r1_rule
When responding to a security incident a capability must exist allowing authorized personnel to disable a particular system if the system exhibits a security violation and the organization determines an action is warranted. Organizations shall define a list of security violations that warrant an immediate disabling of a system. Rationale for non-applicability: The MDM SRG covers the ability to disable a mobile device in the event of a security incident.
Checks: C-43847r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40048r1_fix

The requirement is NA. No fix is required.

b
Applications related to incident tracking must support organizational requirements to employ automated mechanisms to assist in the tracking of security incidents.
IR-5 - Medium - CCI-000833 - V-35508 - SV-46795r1_rule
RMF Control
IR-5
Severity
M
CCI
CCI-000833
Version
SRG-APP-000182-MAPP-NA
Vuln IDs
  • V-35508
Rule IDs
  • SV-46795r1_rule
Incident tracking is a method of monitoring networks and systems for activity indicative of viral infection or system attack. Monitoring for this type of activity provides the organization with the capability to proactively detect and respond to attacks. Automated mechanisms for tracking security incidents and collecting/analyzing incident information include, the Einstein network monitoring device and monitoring online Computer Incident Response Centers (CIRCs) or other electronic databases of incidents. Rationale for non-applicability: The MDM SRG covers the centralized management of audit logs and alerts, which is closely integrated with tracking of security incidents.
Checks: C-43848r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40049r1_fix

The requirement is NA. No fix is required.

b
Applications used for non-local maintenance sessions must protect those sessions through the use of a strong authenticator tightly bound to the user.
MA-4 - Medium - CCI-000884 - V-35509 - SV-46796r1_rule
RMF Control
MA-4
Severity
M
CCI
CCI-000884
Version
SRG-APP-000183-MAPP-NA
Vuln IDs
  • V-35509
Rule IDs
  • SV-46796r1_rule
Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Identification and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions must be consistent with the network access requirements in IA-2. Strong authenticators include, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Examples of types of applications used for non-local maintenance and diagnostic activities are provided below. Use as an example does not imply compliance with policy requirements or approval for use. Examples include but are not limited to: - Terminal Services - Remote Desktop - Dameware - VNC (all variants). Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43849r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40050r1_fix

The requirement is NA. No fix is required.

b
The application must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.
MA-4 - Medium - CCI-000888 - V-35510 - SV-46797r1_rule
RMF Control
MA-4
Severity
M
CCI
CCI-000888
Version
SRG-APP-000184-MAPP-NA
Vuln IDs
  • V-35510
Rule IDs
  • SV-46797r1_rule
Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information, and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43850r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40051r1_fix

The requirement is NA. No fix is required.

b
The application must employ strong identification and authentication techniques when establishing non-local maintenance and diagnostic sessions
MA-4 - Medium - CCI-000877 - V-35511 - SV-46798r1_rule
RMF Control
MA-4
Severity
M
CCI
CCI-000877
Version
SRG-APP-000185-MAPP-NA
Vuln IDs
  • V-35511
Rule IDs
  • SV-46798r1_rule
Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43851r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40052r1_fix

The requirement is NA. No fix is required.

b
The application must terminate all sessions and network connections when non-local maintenance is completed.
MA-4 - Medium - CCI-000879 - V-35512 - SV-46799r1_rule
RMF Control
MA-4
Severity
M
CCI
CCI-000879
Version
SRG-APP-000186-MAPP-NA
Vuln IDs
  • V-35512
Rule IDs
  • SV-46799r1_rule
Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43852r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40053r1_fix

The requirement is NA. No fix is required.

b
Applications employed to write data to portable digital media must use cryptographic mechanisms to protect and restrict access to information on portable digital media.
MP-2 - Medium - CCI-001009 - V-35513 - SV-46800r1_rule
RMF Control
MP-2
Severity
M
CCI
CCI-001009
Version
SRG-APP-000187-MAPP-NA
Vuln IDs
  • V-35513
Rule IDs
  • SV-46800r1_rule
When data is written to portable digital media such as thumb drives, floppy diskettes, compact disks, magnetic tape etc, there is risk of data loss. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. When the organization has determined the risk warrants it, data written to portable digital media must be encrypted. Rationale for non-applicability: The MOS SRG requires this control. More specifically, it requires that the operating system cryptographically bind the removable media to the mobile device so data stored on the media card can only be read by that mobile device. In this context, further application controls would be redundant and could cause conflicts resulting in denial of service.
Checks: C-43853r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40054r1_fix

The requirement is NA. No fix is required.

b
Applications must support organizational requirements to employ cryptographic mechanisms to protect information in storage.
MP-4 - Medium - CCI-001019 - V-35514 - SV-46801r1_rule
RMF Control
MP-4
Severity
M
CCI
CCI-001019
Version
SRG-APP-000188-MAPP-NA
Vuln IDs
  • V-35514
Rule IDs
  • SV-46801r1_rule
When data is written to digital media such as, hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and data compromise. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. Rationale for non applicability: Per the MOS SRG, the MOS must implement FIPS 140-2 validated cryptographic modules for protection of data. To the extent the mobile application uses cryptography not offered by the MOS, FIPS requirements are covered under SRG-APP-000196.
Checks: C-43854r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40055r1_fix

The requirement is NA. No fix is required.

b
Application software used to detect the presence of unauthorized software must employ automated detection mechanisms and notify designated organizational officials in accordance with the organization-defined frequency.
RA-5 - Medium - CCI-001069 - V-35515 - SV-46802r1_rule
RMF Control
RA-5
Severity
M
CCI
CCI-001069
Version
SRG-APP-000189-MAPP-NA
Vuln IDs
  • V-35515
Rule IDs
  • SV-46802r1_rule
Scanning software is purpose built to check for vulnerabilities in the information system and hosted applications and is also used to enumerate platforms, software flaws, and improper configurations. Organizations are required to scan for vulnerabilities in information systems and hosted applications on an organization defined frequency and/or randomly in accordance with an organization defined process. Scanning software includes the capability to scan for specific functions, applications, ports, protocols, and services that should not be accessible to users or devices and for improperly configured or incorrectly operating information flow mechanisms. Rationale for non-applicability: The MDM SRG covers applications used to detect the presence of unauthorized software.
Checks: C-43855r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40056r1_fix

The requirement is NA. No fix is required.

a
The mobile application must close opened network ports at the end of the application session or after an organization defined time period of inactivity.
SC-10 - Low - CCI-001133 - V-35516 - SV-46803r1_rule
RMF Control
SC-10
Severity
L
CCI
CCI-001133
Version
SRG-APP-000190-MAPP-00037
Vuln IDs
  • V-35516
Rule IDs
  • SV-46803r1_rule
Ports that are not closed upon termination of an application or following a pre-defined period of inactivity leave the device vulnerable to exposure from attacks that exploit ports that remain open. As an example, wireless ports, such as Wi-Fi and Bluetooth, are both vulnerable to an adversary in a war driving scenario. In this event, the unauthorized user has the potential to access the device, compromising the security posture of the stored data. Applying this control assures that threat from malicious exploitation of open and unprotected ports that can lead to data integrity and confidentiality risks are mitigated.
Checks: C-43856r1_chk

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.

Fix: F-40057r1_fix

Modify code to close network ports when the application closes or after a period of inactivity.

b
The application must establish a trusted communications path between the user and organization-defined security functions within the information system.
SC-11 - Medium - CCI-001135 - V-35517 - SV-46804r1_rule
RMF Control
SC-11
Severity
M
CCI
CCI-001135
Version
SRG-APP-000191-MAPP-NA
Vuln IDs
  • V-35517
Rule IDs
  • SV-46804r1_rule
The application user interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. A trusted path shall be employed for high-confidence connections between the security functions of the information system and the user (e.g., for login). Rationale for non-applicability: This control is required in the MOS SRG. The operating system provides the only means to establish trusted communications paths internal to a mobile device because the operating system can always act as a man-in-the-middle to any application control.
Checks: C-43857r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40058r1_fix

The requirement is NA. No fix is required.

b
Mobile applications involved in the production, control, and distribution of symmetric cryptographic keys must use NIST approved or NSA approved key management technology and processes.
SC-12 - Medium - CCI-001140 - V-35518 - SV-46805r1_rule
RMF Control
SC-12
Severity
M
CCI
CCI-001140
Version
SRG-APP-000192-MAPP-00038
Vuln IDs
  • V-35518
Rule IDs
  • SV-46805r1_rule
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 application and system. This control assures 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.
Checks: C-43858r1_chk

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.

Fix: F-40059r1_fix

Modify code to adopt the recommendation of NIST SP 800-57 for key management processes and technologies.

b
Mobile applications involved in the production, control, and distribution of asymmetric cryptographic keys must use NIST approved or NSA approved key management technology and processes.
SC-12 - Medium - CCI-001141 - V-35519 - SV-46806r1_rule
RMF Control
SC-12
Severity
M
CCI
CCI-001141
Version
SRG-APP-000193-MAPP-00038
Vuln IDs
  • V-35519
Rule IDs
  • SV-46806r1_rule
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 application 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.
Checks: C-43859r1_chk

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

Fix: F-40060r1_fix

Modify code to adopt the recommendation of NIST SP 800-57 for key management processes and technologies.

b
Mobile applications involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 certificates or prepositioned keying material.
SC-12 - Medium - CCI-001142 - V-35520 - SV-46807r1_rule
RMF Control
SC-12
Severity
M
CCI
CCI-001142
Version
SRG-APP-000194-MAPP-00040
Vuln IDs
  • V-35520
Rule IDs
  • SV-46807r1_rule
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.
Checks: C-43860r1_chk

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.

Fix: F-40061r1_fix

Modify code and/or architecture of the application to ensure approved, Class 3 certificates or prepositioned keying material is used.

b
Mobile applications 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 users private key.
SC-12 - Medium - CCI-001143 - V-35521 - SV-46808r1_rule
RMF Control
SC-12
Severity
M
CCI
CCI-001143
Version
SRG-APP-000195-MAPP-00041
Vuln IDs
  • V-35521
Rule IDs
  • SV-46808r1_rule
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. DoD CAC is an example of a compliant solution.
Checks: C-43861r1_chk

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.

Fix: F-40062r1_fix

Modify code and/or architecture of the application to use approved Class 3 or 4 certificates in conjunction with a hardware token.

b
The mobile application must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
SC-13 - Medium - CCI-001144 - V-35522 - SV-46809r1_rule
RMF Control
SC-13
Severity
M
CCI
CCI-001144
Version
SRG-APP-000196-MAPP-00042
Vuln IDs
  • V-35522
Rule IDs
  • SV-46809r1_rule
Cryptographic protection assures all data at rest and in transit is protected from malicious intruders. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. The control assures the DoD that the data's integrity and privacy is maintained through use of a set of approved and proven cryptographic modules.
Checks: C-43862r1_chk

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.

Fix: F-40063r1_fix

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.

b
Applications must employ FIPS-validated cryptography to protect unclassified information.
SC-13 - Medium - CCI-001145 - V-35523 - SV-46810r1_rule
RMF Control
SC-13
Severity
M
CCI
CCI-001145
Version
SRG-APP-000197-MAPP-NA
Vuln IDs
  • V-35523
Rule IDs
  • SV-46810r1_rule
Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. Rationale for non-applicability: Per the MOS SRG, the MOS must implement FIPS 140-2 validated cryptographic modules for protection of data. To the extent the mobile application uses cryptography not offered by the MOS, FIPS requirements are covered under SRG-APP-000196.
Checks: C-43863r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40064r1_fix

The requirement is NA. No fix is required.

c
The mobile application must employ NSA-approved cryptography to protect classified information.
SC-13 - High - CCI-001146 - V-35524 - SV-46811r1_rule
RMF Control
SC-13
Severity
H
CCI
CCI-001146
Version
SRG-APP-000198-MAPP-00043
Vuln IDs
  • V-35524
Rule IDs
  • SV-46811r1_rule
Unclassified information is also at risk to exposure if no encryption is used, or if a non-NSA validated cryptography module is not used. NSA-compliant cryptography must be applied; unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. Additionally, it must be known that FIPS 140-2 validated encryption is not suitable for classified information. In applying this control, integrity and privacy of unclassified information is maintained. Organizations should contact their NSA liaison to determine what the available options are for cryptographic support.
Checks: C-43864r1_chk

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.

Fix: F-40065r1_fix

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.

b
Applications must employ FIPS-validated cryptography to protect unclassified information when such information must be separated from individuals who have the necessary clearances yet lack the necessary access approvals.
SC-13 - Medium - CCI-001147 - V-35525 - SV-46812r1_rule
RMF Control
SC-13
Severity
M
CCI
CCI-001147
Version
SRG-APP-000199-MAPP-NA
Vuln IDs
  • V-35525
Rule IDs
  • SV-46812r1_rule
Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data. FIPS 140-2 Security Requirements for Cryptographic Modules can be found at the following web site: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf. Although persons may have a security clearance, they may not have a "need to know" and are required to be separated from the information in question. Applications must employ FIPS validated cryptography to protect unclassified information from those individuals who have no "need to know". Rationale for non-applicability: This SRG applies to single-user applications. Therefore there is no need to separate data from other individuals.
Checks: C-43865r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40066r1_fix

The requirement is NA. No fix is required.

b
The mobile application must shut down or take an alternative organization defined action when it determines that one of its required security functions is unavailable.
SI-6 - Medium - CCI-001674 - V-35526 - SV-46813r1_rule
RMF Control
SI-6
Severity
M
CCI
CCI-001674
Version
SRG-APP-000200-MAPP-00044
Vuln IDs
  • V-35526
Rule IDs
  • SV-46813r1_rule
While mobile applications primarily rely on MOS security controls, a mobile application may contain security functions that enable the device and user to operate in a secure manner. For example, the mobile application may operate its own cryptographic modules for data at rest and data in transit. In the event a security function that would normally encrypt data at rest, data in motion or perform some other form of security measure is not present, then all data, the device and network are at risk to exposure and intrusion from a malicious, unauthorized user. This measure mitigates DoD risk and exposure from being compromised due to the security posture of the device being weakened as a result of failed or disabled security modules. When the application shuts down it must cease running and not just deny services to a user. Other organization defined response actions might include writing an entry to the audit log, notifying the user, or limiting access to particular application features, such as the ability to export data.
Checks: C-43866r1_chk

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.

Fix: F-40067r1_fix

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.

b
The application must protect the integrity and availability of publicly available information and applications.
SC-14 - Medium - CCI-001149 - V-35527 - SV-46814r1_rule
RMF Control
SC-14
Severity
M
CCI
CCI-001149
Version
SRG-APP-000201-MAPP-NA
Vuln IDs
  • V-35527
Rule IDs
  • SV-46814r1_rule
The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG. The mobile application does not serve publically available information to other users and therefore is not concerned with the integrity of publically available information.
Checks: C-43867r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40068r1_fix

The requirement is NA. No fix is required.

b
Software and/or firmware used for collaborative computing devices must prohibit remote activation excluding the organization-defined exceptions where remote activation is to be allowed.
SC-15 - Medium - CCI-001150 - V-35528 - SV-46815r1_rule
RMF Control
SC-15
Severity
M
CCI
CCI-001150
Version
SRG-APP-000202-MAPP-NA
Vuln IDs
  • V-35528
Rule IDs
  • SV-46815r1_rule
Collaborative computing devices include, networked white boards, cameras, and microphones. Collaborative software examples include instant messaging or chat clients. Rationale for non-applicability: Remote activation requires the application to provide some form of server functionality even if only to listen for remote activation calls. Server applications are expressly excluded from the scope of this SRG. If the remote activation is achieved locally through an operating system command, then this control must be implemented by the operating system. In this case, the application has no reliable mechanism to detect that the activation is remote.
Checks: C-43868r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40069r1_fix

The requirement is NA. No fix is required.

b
The mobile application must associate security attributes with information exchanged between information systems.
SC-16 - Medium - CCI-001157 - V-35530 - SV-46817r1_rule
RMF Control
SC-16
Severity
M
CCI
CCI-001157
Version
SRG-APP-000203-MAPP-00045
Vuln IDs
  • V-35530
Rule IDs
  • SV-46817r1_rule
When data is exchanged between information systems, security attributes must be associated with this data. Security attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system, and used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy. Applying this control assures security attributes may be explicitly or implicitly associated with the information contained within the information system to support correct handling of the data according to its classification.
Checks: C-43870r1_chk

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.

Fix: F-40071r1_fix

Modify code to associate security attributes with information exchanged between systems.

c
The mobile application must provide integrity protection for the classification attributes bound to the transmitted data if it transmits classified data.
SC-16 - High - CCI-001158 - V-35531 - SV-46818r1_rule
RMF Control
SC-16
Severity
H
CCI
CCI-001158
Version
SRG-APP-000204-MAPP-00046
Vuln IDs
  • V-35531
Rule IDs
  • SV-46818r1_rule
Data classification attributes include the level of classification (e.g., Secret, Top Secret) and additional handling or program parameters if they exist. Data classification attributes are used to ensure classified data is properly handled when transmitted and correctly distributed and stored upon receipt. If integrity checks are not used to detect errors or manipulative action by intruders to data streams, there is no way to ensure the integrity of the application data as it traverses the network. This means the data classification attribute is also subject to manipulative action which could lead to incorrect handling and distribution upon receipt. This control assures the integrity of the transmitted data's classification attributes have been secured which will further mitigate any risks associated with further handling of the data.
Checks: C-43872r1_chk

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.

Fix: F-40072r1_fix

Implement integrity mechanisms for transmission of both incoming and outgoing data labels and classification attributes.

b
Applications must support organizational requirements to issue public key certificates under an appropriate certificate policy or obtain public key certificates under an appropriate certificate policy from an approved service provider.
SC-17 - Medium - CCI-001159 - V-35536 - SV-46823r1_rule
RMF Control
SC-17
Severity
M
CCI
CCI-001159
Version
SRG-APP-000205-MAPP-NA
Vuln IDs
  • V-35536
Rule IDs
  • SV-46823r1_rule
For user certificates, each organization attains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice. This control focuses on certificates with a visibility external to the information system and does not include certificates related to internal system operations, for example, application-specific time services. Rationale for non-applicability: The issuance of public key certificates is a server function. Server applications are outside the scope of this SRG.
Checks: C-43875r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40076r1_fix

The requirement is NA. No fix is required.

b
Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must implement detection and inspection mechanisms to identify unauthorized mobile code
SC-18 - Medium - CCI-001166 - V-35538 - SV-46825r1_rule
RMF Control
SC-18
Severity
M
CCI
CCI-001166
Version
SRG-APP-000206-MAPP-NA
Vuln IDs
  • V-35538
Rule IDs
  • SV-46825r1_rule
Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Policy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. Rationale for non-applicability: The MDM SRG addresses malware issues.
Checks: C-43878r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40080r1_fix

The requirement is NA. No fix is required.

b
Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must take corrective actions, when unauthorized mobile code is identified.
SC-18 - Medium - CCI-001662 - V-35541 - SV-46828r1_rule
RMF Control
SC-18
Severity
M
CCI
CCI-001662
Version
SRG-APP-000207-MAPP-NA
Vuln IDs
  • V-35541
Rule IDs
  • SV-46828r1_rule
Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Policy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. Rationale for non-applicability: The MDM SRG addresses malware issues.
Checks: C-43881r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40082r1_fix

The requirement is NA. No fix is required.

b
Applications utilizing mobile code must meet policy requirements regarding the acquisition, development, and/or use of mobile code.
SC-18 - Medium - CCI-001167 - V-35543 - SV-46830r1_rule
RMF Control
SC-18
Severity
M
CCI
CCI-001167
Version
SRG-APP-000208-MAPP-NA
Vuln IDs
  • V-35543
Rule IDs
  • SV-46830r1_rule
Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers, and mobile code downloaded and executed on individual workstations. DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. Rationale for non-applicability: SRG-APP-000208 is redundant with SRG-APP-000074. All applicable mobile code requirements are associated with SRG-APP-000074 rather than repeated here.
Checks: C-43883r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40084r1_fix

The requirement is NA. No fix is required.

b
Applications designed to enforce policy pertaining to organizational use of mobile code must prevent the download and execution of prohibited mobile code.
SC-18 - Medium - CCI-001169 - V-35545 - SV-46832r1_rule
RMF Control
SC-18
Severity
M
CCI
CCI-001169
Version
SRG-APP-000209-MAPP-NA
Vuln IDs
  • V-35545
Rule IDs
  • SV-46832r1_rule
Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Rationale for non-applicability: The MOS SRG requires application sandboxing, which is core security architecture common to most commercial mobile OSs. In this environment, an application cannot enforce the behavior or actions of another application. Only the OS can effectively enforce mobile code requirements throughout the device. If an application were ever granted the privileges to perform such a function on a mobile device, the application would pose a significant IA risk to device integrity.
Checks: C-43885r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40086r1_fix

The requirement is NA. No fix is required.

b
Applications designed to enforce policy pertaining to the use of mobile code must prevent the automatic execution of mobile code in organization-defined software applications and require organization-defined actions prior to executing the code.
SC-18 - Medium - CCI-001170 - V-35547 - SV-46834r1_rule
RMF Control
SC-18
Severity
M
CCI
CCI-001170
Version
SRG-APP-000210-MAPP-NA
Vuln IDs
  • V-35547
Rule IDs
  • SV-46834r1_rule
Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Organization-defined software may be a specific application, web site or web sites in general. Organization-defined actions include but are not limited to: alerts to the user, logging actions, a centralized alarm, or any combination thereof. Rationale for non-applicability: The MOS SRG requires application sandboxing, which is core security architecture common to most commercial mobile OSs. In this environment, an application cannot enforce the behavior or actions of another application. Only the OS can effectively enforce mobile code requirements throughout the device. If an application were ever granted the privileges to perform such a function on a mobile device, the application would pose a significant IA risk to device integrity.
Checks: C-43887r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40088r1_fix

The requirement is NA. No fix is required.

b
The application must separate user functionality (including user interface services) from information system management functionality.
SC-2 - Medium - CCI-001082 - V-35548 - SV-46835r1_rule
RMF Control
SC-2
Severity
M
CCI
CCI-001082
Version
SRG-APP-000211-MAPP-NA
Vuln IDs
  • V-35548
Rule IDs
  • SV-46835r1_rule
Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. Rationale for non-applicability: The MDM SRG covers mobile applications that have information system management functionality. Mobile operating systems typically do not permit applications to perform information system management.
Checks: C-43888r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40089r1_fix

The requirement is NA. No fix is required.

b
The application must prevent the presentation of information system management-related functionality at an interface utilized by general (i.e., non-privileged) users.
SC-2 - Medium - CCI-001083 - V-35550 - SV-46837r1_rule
RMF Control
SC-2
Severity
M
CCI
CCI-001083
Version
SRG-APP-000212-MAPP-NA
Vuln IDs
  • V-35550
Rule IDs
  • SV-46837r1_rule
Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. Rationale for non-applicability: The MDM SRG covers mobile applications that have information system management functionality. Mobile operating systems typically do not permit non-MDM applications to perform information system management.
Checks: C-43890r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40091r1_fix

The requirement is NA. No fix is required.

b
The application must provide additional data origin and integrity artifacts along with the authoritative data the system returns in response to name/address resolution queries.
SC-20 - Medium - CCI-001178 - V-35551 - SV-46838r1_rule
RMF Control
SC-20
Severity
M
CCI
CCI-001178
Version
SRG-APP-000213-MAPP-NA
Vuln IDs
  • V-35551
Rule IDs
  • SV-46838r1_rule
This control enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. The DNS security controls are consistent with, and referenced from, OMB Memorandum 08-23. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
Checks: C-43892r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40093r1_fix

The requirement is NA. No fix is required.

b
The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems.
SC-20 - Medium - CCI-001663 - V-35553 - SV-46840r1_rule
RMF Control
SC-20
Severity
M
CCI
CCI-001663
Version
SRG-APP-000215-MAPP-NA
Vuln IDs
  • V-35553
Rule IDs
  • SV-46840r1_rule
A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
Checks: C-43893r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40094r1_fix

The requirement is NA. No fix is required.

b
The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems.
SC-21 - Medium - CCI-001180 - V-35555 - SV-46842r1_rule
RMF Control
SC-21
Severity
M
CCI
CCI-001180
Version
SRG-APP-000216-MAPP-NA
Vuln IDs
  • V-35555
Rule IDs
  • SV-46842r1_rule
A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
Checks: C-43895r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40096r1_fix

The requirement is NA. No fix is required.

b
The application must perform data origin authentication and data integrity verification on all resolution responses received whether or not local client systems explicitly request this service.
SC-21 - Medium - CCI-001181 - V-35557 - SV-46844r1_rule
RMF Control
SC-21
Severity
M
CCI
CCI-001181
Version
SRG-APP-000217-MAPP-NA
Vuln IDs
  • V-35557
Rule IDs
  • SV-46844r1_rule
A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources owning DNS data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
Checks: C-43897r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40098r1_fix

The requirement is NA. No fix is required.

b
Applications that collectively provide name/address resolution service for an organization must implement internal/external role separation.
SC-22 - Medium - CCI-001183 - V-35558 - SV-46845r1_rule
RMF Control
SC-22
Severity
M
CCI
CCI-001183
Version
SRG-APP-000218-MAPP-NA
Vuln IDs
  • V-35558
Rule IDs
  • SV-46845r1_rule
A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least two authoritative domain name system DNS servers, one configured as primary and the other as secondary. Additionally, the two servers are commonly located in two different network subnets and geographically separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an internal role, only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address ranges, explicit lists). Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
Checks: C-43899r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40100r1_fix

The requirement is NA. No fix is required.

b
Application must ensure authentication of both client and server during the entire session. An example of this is SSL Mutual Authentication.
SC-23 - Medium - CCI-001184 - V-35560 - SV-46847r1_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001184
Version
SRG-APP-000219-MAPP-NA
Vuln IDs
  • V-35560
Rule IDs
  • SV-46847r1_rule
This control focuses on communications protection at the session, versus packet, level. At the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity. Proper use of session IDs addressed man-in-the-middle attacks including session hijacking or insertion of false information into a session. This control is only implemented where deemed necessary by the organization (e.g., sessions in service-oriented architectures providing web-based services). Rationale for non-applicability: The scope of the MAPP SRG concerns applications local to the mobile device. The SRG does not impose any requirements for local authentication. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements. The mobile application can leverage SSL/TLS functionality of the operating system when required.
Checks: C-43900r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40101r1_fix

The requirement is NA. No fix is required.

b
Applications must terminate user sessions upon user logout or any other organization or policy defined session termination events, such as idle time limit exceeded.
SC-23 - Medium - CCI-001185 - V-35561 - SV-46848r1_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001185
Version
SRG-APP-000220-MAPP-NA
Vuln IDs
  • V-35561
Rule IDs
  • SV-46848r1_rule
This requirement focuses on communications protection at the application session, versus network packet level. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session so as to minimize the potential for an attacker to hijack that particular user session. Rationale for non-applicability: The MAPP SRG expressly excludes a requirement for user authentication because user authentication is already addressed in the MOS SRG. The MOS SRG also covers requirements related to lockout resulting from exceeding idle time limits. As a consequence of having no requirement to logon, there is no requirement to logout.
Checks: C-43902r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40102r1_fix

The requirement is NA. No fix is required.

b
Applications providing a login capability must also provide a logout functionality to allow the user to manually terminate the session.
SC-23 - Medium - CCI-001186 - V-35563 - SV-46850r1_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001186
Version
SRG-APP-000221-MAPP-NA
Vuln IDs
  • V-35563
Rule IDs
  • SV-46850r1_rule
An application that will not allow the user the ability to log out will leave the application and all stored data vulnerable to unauthorized access in the event an adversary is able to unlock the device and re-launch the application or continue the prior session. If a user cannot log out of a mobile application, an adversary could continue to use the previous user's session, access the stored data with malicious intent, and compromise the integrity and confidentiality of the data. This control provides the DoD greater assurance that the device and all stored data is less vulnerable to malicious action in the event a device is stolen or found. Rationale for non-applicability: The MAPP SRG does not require user authentication. Since there is no requirement for a login capability, there similarly is no requirement to provide a logout capability.
Checks: C-43903r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40104r1_fix

The requirement is NA. No fix is required.

b
Applications must generate a unique session identifier for each session.
SC-23 - Medium - CCI-001187 - V-35565 - SV-46852r1_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001187
Version
SRG-APP-000222-MAPP-NA
Vuln IDs
  • V-35565
Rule IDs
  • SV-46852r1_rule
This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. Rationale for non-applicability: Session identifiers are relevant for multi-user applications, typically involving network communication. The MAPP SRG covers single-user applications only. Even in the rare case in which a single user may have several sessions within the context of a single-user application, there is no risk of external breach of any of these sessions because they are all accessed locally. If a remote application to which the mobile application connects employs session identifiers, it is the responsibility of the remote application to enforce randomness requirements.
Checks: C-43905r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40106r1_fix

The requirement is NA. No fix is required.

b
Applications must recognize only system-generated session identifiers.
SC-23 - Medium - CCI-001664 - V-35566 - SV-46853r1_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001664
Version
SRG-APP-000223-MAPP-NA
Vuln IDs
  • V-35566
Rule IDs
  • SV-46853r1_rule
This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions Rationale for non-applicability: The scope of the MAPP SRG is limited to the mobile application and does not extend to components of the Information Server such as the remote server.
Checks: C-43907r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40108r1_fix

The requirement is NA. No fix is required.

b
Applications must generate unique session identifiers with organization defined randomness requirements.
SC-23 - Medium - CCI-001188 - V-35568 - SV-46855r1_rule
RMF Control
SC-23
Severity
M
CCI
CCI-001188
Version
SRG-APP-000224-MAPP-NA
Vuln IDs
  • V-35568
Rule IDs
  • SV-46855r1_rule
This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. Organizations can define the randomness of unique session identifiers when deemed necessary (e.g., sessions in service-oriented architectures providing web-based services). Rationale for non-applicability: Session identifiers are relevant for multi-user applications, typically involving network communication. The MAPP SRG covers single-user applications only. Even in the rare case in which a single user may have several sessions within the context of a single-user application, there is no risk of external breach of any of these sessions because they are all accessed locally. If a remote application to which the mobile application connects employs session identifiers, it is the responsibility of the remote application to enforce randomness requirements.
Checks: C-43908r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40109r1_fix

The requirement is NA. No fix is required.

b
The mobile application must fail to an initial state when the application unexpectedly terminates, unless it maintains a secure state at all times.
SC-24 - Medium - CCI-001190 - V-35570 - SV-46857r1_rule
RMF Control
SC-24
Severity
M
CCI
CCI-001190
Version
SRG-APP-000225-MAPP-00047
Vuln IDs
  • V-35570
Rule IDs
  • SV-46857r1_rule
An application maintains a secure state when there is strong assurance that each of its state transitions is consistent with the application's security policy. For many mobile applications, 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 application could be compromised, providing an attack vector to the application and OS if initialization, shutdown, and aborts are not designed to keep the application in a secure state. If the application 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 application can be secured to its initial level of security in the event the application crashes or terminates. This will mitigate the threat of an unauthorized user taking control of the device and accessing the application and stored data, compromising its integrity and confidentiality.
Checks: C-43910r1_chk

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.

Fix: F-40111r1_fix

Modify the code and architecture to ensure the application returns to a secure, initial state upon unexpected termination.

a
The mobile application must preserve organization-defined system state information in the event of an application failure.
SC-24 - Low - CCI-001665 - V-35573 - SV-46860r1_rule
RMF Control
SC-24
Severity
L
CCI
CCI-001665
Version
SRG-APP-000226-MAPP-00048
Vuln IDs
  • V-35573
Rule IDs
  • SV-46860r1_rule
Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.
Checks: C-43913r1_chk

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.

Fix: F-40114r1_fix

Modify the code so that state information is preserved in the event of an application failure.

b
Applications must enforce requirements regarding the connection of mobile devices to organizational information systems.
AC-19 - Medium - CCI-000086 - V-35574 - SV-46861r1_rule
RMF Control
AC-19
Severity
M
CCI
CCI-000086
Version
SRG-APP-000227-MAPP-NA
Vuln IDs
  • V-35574
Rule IDs
  • SV-46861r1_rule
Applications designed to manage the connection of mobile devices to information systems must be able to enforce organizational connectivity requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). Organizational connectivity requirements may include usage restrictions and implementation guidance related to mobile devices. For example, the organization may require the device be part of the configuration management environment or may require mandatory protective software be installed prior to connecting to the infrastructure (e.g., malicious code detection or a firewall). Scanning devices for malicious code may be required prior to connecting, as well as updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). An example of information system functionality that may need to be disabled prior to connecting includes the capability for automatic execution of code, such as AutoRun and AutoPlay. Rationale for non-applicability: Requirements related to connections to remote organization information systems must be enforced by the remote information system and not the mobile application. If this control were enforced on mobile device instead of the remote organizational information system, it would make that system more rather than less vulnerable.
Checks: C-43914r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40115r1_fix

The requirement is NA. No fix is required.

b
The application must disable network access by unauthorized components/devices or notify designated organizational officials.
CM-8 - Medium - CCI-000417 - V-35579 - SV-46866r1_rule
RMF Control
CM-8
Severity
M
CCI
CCI-000417
Version
SRG-APP-000228-MAPP-NA
Vuln IDs
  • V-35579
Rule IDs
  • SV-46866r1_rule
Maintaining system and network integrity requires all systems on the network are identified and accounted for. Without an accurate accounting of systems utilizing the network, the opportunity exists for the introduction of rogue systems. The significance of this manner of security compromise increases exponentially over time and could become a persistent threat. Therefore, organizations must employ automated mechanisms to detect the addition unauthorized devices. Information deemed to be necessary by the organization to achieve effective property accountability can include, for example, hardware inventory specifications (manufacturer, type, model, serial number, physical location), software license information, information system/component owner, and for a networked component/device, the machine name and network address. The monitoring for unauthorized components/devices on information system networks may be accomplished on an ongoing basis or by the periodic scanning of organizational networks for that purpose. Automated mechanisms can be implemented within the information system and/or in another separate information system or device. Applications that are designed as systems configuration management solutions or other solutions developed specifically to fill the role of identifying or managing systems in the enterprise must be able to either disable the identified device or notify the appropriate personnel when new systems have been introduced into the environment. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43921r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40120r1_fix

The requirement is NA. No fix is required.

b
Only a Honey Pot information system and/or application must include components that proactively seek to identify web-based malicious code. Honey Pot systems must be not be shared or used for any other purpose other than described.
SC-26 - Medium - CCI-001196 - V-35581 - SV-46868r1_rule
RMF Control
SC-26
Severity
M
CCI
CCI-001196
Version
SRG-APP-000229-MAPP-NA
Vuln IDs
  • V-35581
Rule IDs
  • SV-46868r1_rule
A Honey Pot is an organization designated information system and/or application that includes components specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting, and analyzing such attacks. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-43923r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40122r1_fix

The requirement is NA. No fix is required.

b
Applications must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission. When transmitting data, applications need to leverage transmission protection mechanisms such as TLS, SSL VPN, or IPSEC tunnel.
SC-9 - Medium - CCI-001132 - V-35583 - SV-46870r1_rule
RMF Control
SC-9
Severity
M
CCI
CCI-001132
Version
SRG-APP-000230-MAPP-NA
Vuln IDs
  • V-35583
Rule IDs
  • SV-46870r1_rule
Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. Alternative physical protection measures include, protected distribution systems. Protective Distribution Systems (PDS) are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS. Rationale for non-applicability: This functionality is provided by the mobile operating system through numerous controls, including user authentication, application sandboxing, and encryption of data at rest and in transit. The mobile application must necessarily reveal data to the user of the application. Therefore, the application cannot maintain strict confidentiality during many packaging transactions.
Checks: C-43925r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40124r1_fix

The requirement is NA. No fix is required.

b
Applications must take needed steps to protect data at rest and ensure confidentiality and integrity of application data.
SC-28 - Medium - CCI-001199 - V-35585 - SV-46872r1_rule
RMF Control
SC-28
Severity
M
CCI
CCI-001199
Version
SRG-APP-000231-MAPP-NA
Vuln IDs
  • V-35585
Rule IDs
  • SV-46872r1_rule
This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. User data generated, as well as, application specific configuration data needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. Rationale for non-applicability: This functionality is provided by the operating system, which is required to encrypt all data at rest using FIPS 140-2 validated cryptographic modules.
Checks: C-43927r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40126r1_fix

The requirement is NA. No fix is required.

b
Applications handling data requiring data at rest protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information that is at rest unless otherwise protected by alternative physical measures.
SC-28 - Medium - CCI-001200 - V-35587 - SV-46874r1_rule
RMF Control
SC-28
Severity
M
CCI
CCI-001200
Version
SRG-APP-000232-MAPP-NA
Vuln IDs
  • V-35587
Rule IDs
  • SV-46874r1_rule
This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Alternative physical protection measures include, protected distribution systems. Rationale for non-applicability: This functionality is provided by the operating system, which is required to encrypt all data at rest using FIPS 140-2 validated cryptographic modules.
Checks: C-43929r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40128r1_fix

The requirement is NA. No fix is required.

b
Applications must isolate security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions.
SC-3 - Medium - CCI-001084 - V-35589 - SV-46876r1_rule
RMF Control
SC-3
Severity
M
CCI
CCI-001084
Version
SRG-APP-000233-MAPP-NA
Vuln IDs
  • V-35589
Rule IDs
  • SV-46876r1_rule
Security functions are defined as "the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based". Developers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles. Rationale for non-applicability: It is assumed that mobile applications leverage the security functions of the operating system and that the operating system provides the requisite isolation of security functions from other functions. If an application embeds additional security functionality, those security functions are protected from other applications via applications sandboxing. When the mobile application connects to remote enterprise application resources, the remote resources perform the required isolation.
Checks: C-43931r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40130r1_fix

The requirement is NA. No fix is required.

b
The application must automatically terminate emergency accounts after an organization defined time period for each type of account.
AC-2 - Medium - CCI-001682 - V-35591 - SV-46878r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001682
Version
SRG-APP-000234-MAPP-NA
Vuln IDs
  • V-35591
Rule IDs
  • SV-46878r1_rule
Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. In the event emergency application accounts are required, the application must ensure that accounts that are designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. The application must provide or utilize a mechanism to automatically terminate accounts that have been designated as temporary or emergency accounts after an organization defined time period. Rationale for non-applicability: This SRG applies to single-user applications. There is no possibility of emergency accounts in these applications.
Checks: C-43933r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40132r1_fix

The requirement is NA. No fix is required.

b
Applications must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions.
SC-3 - Medium - CCI-001086 - V-35592 - SV-46879r1_rule
RMF Control
SC-3
Severity
M
CCI
CCI-001086
Version
SRG-APP-000235-MAPP-NA
Vuln IDs
  • V-35592
Rule IDs
  • SV-46879r1_rule
Application functionality is typically broken down into modules that perform various tasks or roles. Examples of non-privileged application functionality include, but are not limited to, application modules written for displaying data or printing reports. Application security functionality that performs security tasks such as enforcing access and information flow control requires additional system privilege and can have a large impact on the security of the application and its data. Rather than allowing the entire application access to this security functionality, application developers must isolate these critical functions from non-privileged application functions and other security functions. Rationale for non-applicability: It is assumed that mobile applications leverage the security functions of the operating system and that the operating system provides the requisite isolation of security functions from other functions. If an application embeds additional security functionality, those security functions are protected from other applications via applications sandboxing. When the mobile application connects to remote enterprise application resources, the remote resources perform the required isolation.
Checks: C-43935r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40134r1_fix

The requirement is NA. No fix is required.

b
Applications must meet organizational requirements to implement an information system isolation boundary that minimizes the number of non-security functions included within the boundary containing security functions.
SC-3 - Medium - CCI-001087 - V-35594 - SV-46881r1_rule
RMF Control
SC-3
Severity
M
CCI
CCI-001087
Version
SRG-APP-000236-MAPP-NA
Vuln IDs
  • V-35594
Rule IDs
  • SV-46881r1_rule
The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process. Rationale for non-applicability: It is assumed that mobile applications leverage the security functions of the operating system and that the operating system provides the requisite isolation of security functions from other functions. If an application embeds additional security functionality, those security functions are protected from other applications via applications sandboxing. When the mobile application connects to remote enterprise application resources, the remote resources perform the required isolation.
Checks: C-43936r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40135r1_fix

The requirement is NA. No fix is required.

b
The application must employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications.
SI-4 - Medium - CCI-001274 - V-35597 - SV-46884r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001274
Version
SRG-APP-000237-MAPP-NA
Vuln IDs
  • V-35597
Rule IDs
  • SV-46884r1_rule
Applications will typically utilize logging mechanisms for maintaining a historical log of activity that occurs within the application. This information can then be used for diagnostic purposes, forensics purposes or other purposes relevant to ensuring the availability and integrity of the application. While it is important to log events identified as being critical and relevant to security, it is equally important to notify the appropriate personnel in a timely manner so they are able to respond to events as they occur. Solutions that include a manual notification procedure do not offer the reliability and speed of an automated notification solution. Applications must employ automated mechanisms to alert security personnel of inappropriate or unusual activities that have security implications. If this capability is not built directly into the application, the application must be able to integrate with existing security infrastructure that provides this capability. Rationale for non-applicability: Mobile applications should leverage the audit and alert functionality of the operating system and MDM. Stove-piped alert systems for particular mobile applications are likely to inhibit rather than facilitate proper incident response. If the mobile application connects to a remote enterprise resource, the enterprise application managing access to that resource would implement an appropriate alert mechanism.
Checks: C-43940r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40138r1_fix

The requirement is NA. No fix is required.

b
Applications must meet organizational requirements to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers
SC-3 - Medium - CCI-001089 - V-35629 - SV-46916r1_rule
RMF Control
SC-3
Severity
M
CCI
CCI-001089
Version
SRG-APP-000238-MAPP-NA
Vuln IDs
  • V-35629
Rule IDs
  • SV-46916r1_rule
The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process. Rationale for non-applicability: The mobile application exists at the highest security layer of the mobile device architecture. Therefore, it cannot depend on the functionality or correctness of higher layers.
Checks: C-43972r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40169r1_fix

The requirement is NA. No fix is required.

b
The application must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission.
SC-33 - Medium - CCI-001209 - V-35631 - SV-46918r1_rule
RMF Control
SC-33
Severity
M
CCI
CCI-001209
Version
SRG-APP-000239-MAPP-NA
Vuln IDs
  • V-35631
Rule IDs
  • SV-46918r1_rule
Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the application take steps to validate and assure the integrity of data while at these stages of processing. For example, an application developer may determine based upon application requirements that various application data must accumulate in a processing queue where the application analyses, packages or transforms the data pending a data transfer. A window of time now exists where if an attacker were to gain access to the data residing in the application queue they could potentially compromise that data or alter results. The application must ensure the integrity of data that is pending transfer is maintained. If the application were to simply transmit aggregated, packaged or transformed data without ensuring the data was not manipulated during these processes, then the integrity of the data may be called into question. Rationale for non-applicability: Transformation of data inherently affects the integrity of the data inputs. Several operating system controls, including application sandboxing and white listing of applications, greatly mitigates the risk that any processes will be able to modify data in an unauthorized manner.
Checks: C-43974r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40171r1_fix

The requirement is NA. No fix is required.

b
Applications required to be non-modifiable must support organizational requirements to provide components that contain no writeable storage capability. These components must be persistent across restart and/or power on/off.
SC-34 - Medium - CCI-001214 - V-35635 - SV-46922r1_rule
RMF Control
SC-34
Severity
M
CCI
CCI-001214
Version
SRG-APP-000240-MAPP-NA
Vuln IDs
  • V-35635
Rule IDs
  • SV-46922r1_rule
Organizations may require applications or application components to be non-modifiable or to be stored and executed on non-writeable storage. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion. Rationale for non-applicability: This control conflicts with a core requirement that mobile applications be modifiable. The primary means for updating the configuration of mobile applications is to replace the entire application.
Checks: C-43978r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40177r1_fix

The requirement is NA. No fix is required.

b
Applications must, for organization-defined information system components, load and execute the operating environment from hardware-enforced, read-only media.
SC-34 - Medium - CCI-001210 - V-35638 - SV-46925r1_rule
RMF Control
SC-34
Severity
M
CCI
CCI-001210
Version
SRG-APP-000241-MAPP-NA
Vuln IDs
  • V-35638
Rule IDs
  • SV-46925r1_rule
Organizations may require the information system to load the operating environment from hardware enforced read-only media. The term operating environment is defined as the code upon which applications are hosted, for example, a monitor, executive, operating system, or application running directly on the hardware platform. Hardware-enforced, read-only media include, CD-R/DVD-R disk drives. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Rationale for non-applicability: Given the small form factor of mobile devices and the necessity to minimize the size and number of components, mobile devices are not expected to support read-only media for any application. Even in cases in which this requirement was enforced, it would be as a result of a policy requirement on specialized hardware. There is no technical means for an application to enforce this control as it has no control over the hardware on which it resides.
Checks: C-43980r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40179r1_fix

The requirement is NA. No fix is required.

b
Applications must support organizationally-defined requirements to load and execute from hardware-enforced, read-only media.
SC-34 - Medium - CCI-001211 - V-35640 - SV-46927r1_rule
RMF Control
SC-34
Severity
M
CCI
CCI-001211
Version
SRG-APP-000242-MAPP-NA
Vuln IDs
  • V-35640
Rule IDs
  • SV-46927r1_rule
Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Organizations may require the information system to load specified applications from hardware enforced read-only media. Hardware-enforced, read-only media include, CD-R/DVD-R disk drives. Rationale for non-applicability: Given the small form factor of mobile devices and the necessity to minimize the size and number of components, mobile devices are not expected to support read-only media for any application. Even in cases in which this requirement was enforced, it would be as a result of a policy requirement on specialized hardware. There is no technical means for an application to enforce this control as it has no control over the hardware on which it resides.
Checks: C-43982r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40182r1_fix

The requirement is NA. No fix is required.

b
The mobile application must not write data to persistent memory accessible to other applications.
SC-4 - Medium - CCI-001090 - V-35642 - SV-46929r1_rule
RMF Control
SC-4
Severity
M
CCI
CCI-001090
Version
SRG-APP-000243-MAPP-00049
Vuln IDs
  • V-35642
Rule IDs
  • SV-46929r1_rule
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 application shares the same location of persistent memory with that used by other applications to include encrypted data, then the data is at great risk to exposure through being available to other applications after the application has shut down or a user session has terminated. Furthermore, even though the OS will always be able to read files, other applications 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 application. In many operating environments, assigning unique process IDs to each application 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 applications.
Checks: C-43984r1_chk

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.

Fix: F-40184r1_fix

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.

b
Applications must not share resources used to interface with systems operating at different security levels.
SC-4 - Medium - CCI-001091 - V-35644 - SV-46931r1_rule
RMF Control
SC-4
Severity
M
CCI
CCI-001091
Version
SRG-APP-000244-MAPP-NA
Vuln IDs
  • V-35644
Rule IDs
  • SV-46931r1_rule
The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Shared resources include memory, input/output queues, and network interface cards. Rationale for non-applicability: Mobile applications that interface with system operating at different security levels are outside the scope of the MAPP SRG.
Checks: C-43986r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40186r1_fix

The requirement is NA. No fix is required.

b
Applications must protect against or limit the effects of the organization-defined or referenced types of Denial of Service (DoS) attacks.
SC-5 - Medium - CCI-001092 - V-35646 - SV-46933r1_rule
RMF Control
SC-5
Severity
M
CCI
CCI-001092
Version
SRG-APP-000245-MAPP-NA
Vuln IDs
  • V-35646
Rule IDs
  • SV-46933r1_rule
A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization's internal network from being directly affected by DoS attacks. Employing increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks. Rationale for non-applicability: Mobile applications are lightweight and are not expected to have embedded mechanisms to protect against DoS, most of which cannot be known prior to the exploited vulnerability. The mobile operating system has a variety of mechanisms, including application sandboxing and memory management, to protect against application-based DoS attacks.
Checks: C-43988r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40188r1_fix

The requirement is NA. No fix is required.

b
Applications must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks.
SC-5 - Medium - CCI-001094 - V-35648 - SV-46935r1_rule
RMF Control
SC-5
Severity
M
CCI
CCI-001094
Version
SRG-APP-000246-MAPP-NA
Vuln IDs
  • V-35648
Rule IDs
  • SV-46935r1_rule
When it comes to DoS attacks most of the attention is paid to ensuring that systems and applications are not victims of these attacks. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by denial of service attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. Applications and application developers must take the steps needed to ensure that users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so that users are not able to generate unlimited network traffic via the application. The methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it. Rationale for non-applicability: Mobile applications are lightweight and are not expected to have embedded mechanisms to restrict users to launch DoS attacks. An MDM can disable devices that are determined to be the source of DoS attacks.
Checks: C-43990r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40190r1_fix

The requirement is NA. No fix is required.

b
Applications must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.
SC-5 - Medium - CCI-001095 - V-35650 - SV-46937r1_rule
RMF Control
SC-5
Severity
M
CCI
CCI-001095
Version
SRG-APP-000247-MAPP-NA
Vuln IDs
  • V-35650
Rule IDs
  • SV-46937r1_rule
In the case of application DoS attacks, care must be taken when designing the application so as to ensure that the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. The methods employed to meet this requirement will vary depending upon the technology the application utilizes. However, a variety of technologies exist to limit, or in some cases, eliminate the effects of application related DoS attacks. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS attacks. Rationale for non-applicability: This requirement is most appropriately targeted at server-based applications that can manage capacity or redundancy. Mobile applications are single-user applications that have very limited ability to either perform a DoS to other devices or to appreciably change the level of resources they employ.
Checks: C-43992r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40192r1_fix

The requirement is NA. No fix is required.

b
Applications must limit the use of resources by priority and not impede the host from servicing processes designated as a higher-priority.
SC-6 - Medium - CCI-001096 - V-35651 - SV-46938r1_rule
RMF Control
SC-6
Severity
M
CCI
CCI-001096
Version
SRG-APP-000248-MAPP-NA
Vuln IDs
  • V-35651
Rule IDs
  • SV-46938r1_rule
Priority protection helps prevent a lower-priority process from delaying or interfering with the information system servicing any higher-priority process. This control does not apply to components in the information system for which there is only a single user/role. The application must limit the use of resources by priority. Rationale for non-applicability: Prioritization of access to device resources is a core operating system function. The operating system, and not the application, must set priorities. If a mobile application were granted the authority to affect resource prioritization, this would be a significant vulnerability to other processes running on the device.
Checks: C-43993r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40193r1_fix

The requirement is NA. No fix is required.

b
Applications functioning in the capacity of a firewall must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination.
SC-7 - Medium - CCI-001117 - V-35653 - SV-46940r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001117
Version
SRG-APP-000249-MAPP-NA
Vuln IDs
  • V-35653
Rule IDs
  • SV-46940r1_rule
In regards to boundary controls such as routers and firewalls, examples of restricting and prohibiting communications are: restricting external web traffic only to organizational web servers within managed interfaces and prohibiting external traffic that appears to be spoofing an internal address as the source. Rationale for non-applicability: The mobile operating system provides firewall functionality on mobile devices. The requirement for application sandboxing precludes applications from checking the inbound and outbound traffic of other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
Checks: C-43995r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40195r1_fix

The requirement is NA. No fix is required.

b
The application must be capable of implementing host-based boundary protection mechanisms for servers, workstations, and mobile devices.
SC-7 - Medium - CCI-001118 - V-35655 - SV-46942r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001118
Version
SRG-APP-000250-MAPP-NA
Vuln IDs
  • V-35655
Rule IDs
  • SV-46942r1_rule
A host-based boundary protection mechanism is a host-based firewall. Host-based boundary protection mechanisms are employed on mobile devices, such as notebook/laptop computers, and other types of mobile devices where such boundary protection mechanisms are available. Rationale for non-applicability: The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
Checks: C-43997r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40197r1_fix

The requirement is NA. No fix is required.

b
The mobile application must prevent XML injection.
SI-10 - Medium - CCI-001310 - V-35656 - SV-46943r1_rule
RMF Control
SI-10
Severity
M
CCI
CCI-001310
Version
SRG-APP-000251-MAPP-00051
Vuln IDs
  • V-35656
Rule IDs
  • SV-46943r1_rule
XML injection may result in an immediate loss of integrity of the data. Any vulnerability associated with a DoD Information system, the exploitation of which, by a risk factor, will directly and immediately result in loss of confidentiality, availability, or integrity of the system associated data. If a mobile application does not permit XML injection, then the risk of exploits from this form of attack is greatly reduced. Please refer to CWE 91 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-43998r1_chk

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

Fix: F-40198r1_fix

Modify code to correct XML injection flaws.

b
The mobile application must validate the correctness of data inputs.
SI-10 - Medium - CCI-001310 - V-35658 - SV-46945r1_rule
RMF Control
SI-10
Severity
M
CCI
CCI-001310
Version
SRG-APP-000251-MAPP-00052
Vuln IDs
  • V-35658
Rule IDs
  • SV-46945r1_rule
Inputs may come from users or other processes. Absence of input validation opens an application to improper application functioning, the risk of manipulation of data by an adversary and the security risks associated with SQL script and integer overflow attacks. The lack of input validation can lead to immediate access to an application, denial of service, and malicious action on the stored data. In applying this control, the user is provided greater protection against malicious intruders, attempting to access the application or its remote server with data input that may allow access to the application or may cause unpredictable operation and corruption of data. Please refer to CWEs: 15, 20, 22, 73, 77, 78, 79, 80, 82, 83, 87, 88, 89, 90, 94, 95, 98, 99, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 117, 119, 120, 125, 126, 129, 131, 134, 170, 190, 193, 195, 197, 398 , 434, 466, 470, 501, 564, 566, 601, 639, 643, 692, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-44000r1_chk

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.

Fix: F-40200r1_fix

Modify code so that the application validates all input.

a
The mobile application must define a character set for data inputs.
SI-10 - Low - CCI-001310 - V-35660 - SV-46947r1_rule
RMF Control
SI-10
Severity
L
CCI
CCI-001310
Version
SRG-APP-000251-MAPP-00053
Vuln IDs
  • V-35660
Rule IDs
  • SV-46947r1_rule
Characters entered in an application's input fields that are undefined can lead to unpredictable results and leave the application's stored data vulnerable. By setting the character set for the application, the possibility of receiving unexpected input that uses other character set encodings could cause the application to operate unpredictably and allow an intruder access to the application through manipulation of certain characters that would allow access and privileges of authorized users. In defining character sets for input, users are assured of a greater security posture through use of a defined set of characters that are filtered for use with the application. Please refer to CWEs: 74, 78, and 88 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-44002r1_chk

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.

Fix: F-40202r1_fix

Modify the code to fix the character set for the application.

b
The mobile application must not contain format string vulnerabilities.
SI-10 - Medium - CCI-001310 - V-35665 - SV-46952r1_rule
RMF Control
SI-10
Severity
M
CCI
CCI-001310
Version
SRG-APP-000251-MAPP-00054
Vuln IDs
  • V-35665
Rule IDs
  • SV-46952r1_rule
Format string vulnerabilities usually occur when invalidated input is entered and is directly written into the format string used to format data in the print style family of C/C++ functions. If an attacker can manipulate a format string, this may result in a buffer overflow causing a denial of service for the application. Format string vulnerabilities may lead to information disclosure vulnerabilities. Format string vulnerabilities may be used to execute arbitrary code. If the application code does not contain format string vulnerabilities, then the risk of buffer overflows and other software exploits is significantly mitigated. Please refer to CWEs: 20, 74, 78, 88, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 251, 415, 560, 686, 733, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-44007r1_chk

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

Fix: F-40207r1_fix

Remove format string vulnerabilities from the code.

b
The mobile application must not be vulnerable to command injection.
SI-10 - Medium - CCI-001310 - V-35666 - SV-46953r1_rule
RMF Control
SI-10
Severity
M
CCI
CCI-001310
Version
SRG-APP-000251-MAPP-00055
Vuln IDs
  • V-35666
Rule IDs
  • SV-46953r1_rule
Format string vulnerabilities usually occur when invalidated input is entered and is directly written into the format string used to format data in the print style family of C/C++ functions. If an attacker can manipulate a format string, this may result in a buffer overflow causing a denial of service for the application. Format string vulnerabilities may lead to information disclosure vulnerabilities. Format string vulnerabilities may be used to execute arbitrary code. If the application code does not contain format string vulnerabilities, then the risk of buffer overflows and other software exploits is significantly mitigated. Please refer to CWEs: 20, 74, 78, 88, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 251, 415, 560, 686, 733, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-44009r1_chk

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

Fix: F-40209r1_fix

Modify the code to remove command injection attack vulnerabilities.

b
The mobile application must prevent SQL injection.
SI-10 - Medium - CCI-001310 - V-35668 - SV-46955r1_rule
RMF Control
SI-10
Severity
M
CCI
CCI-001310
Version
SRG-APP-000251-MAPP-00056
Vuln IDs
  • V-35668
Rule IDs
  • SV-46955r1_rule
Format string vulnerabilities usually occur when invalidated input is entered and is directly written into the format string used to format data in the print style family of C/C++ functions. If an attacker can manipulate a format string, this may result in a buffer overflow causing a denial of service for the application. Format string vulnerabilities may lead to information disclosure vulnerabilities. Format string vulnerabilities may be used to execute arbitrary code. If the application code does not contain format string vulnerabilities, then the risk of buffer overflows and other software exploits is significantly mitigated. Please refer to CWEs: 20, 74, 78, 88, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 251, 415, 560, 686, 733, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
Checks: C-44010r2_chk

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.

Fix: F-40210r1_fix

Modify the source code to remove SQL injection vulnerabilities.

b
Boundary protection applications must prevent discovery of specific system components (or devices) composing a managed interface.
SC-7 - Medium - CCI-001124 - V-35670 - SV-46957r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001124
Version
SRG-APP-000252-MAPP-NA
Vuln IDs
  • V-35670
Rule IDs
  • SV-46957r1_rule
Firewall control requirement for isolating and preventing the discovery of management interfaces. This control enhancement is intended to protect the network addresses of information system components that are part of the managed interface from discovery through common tools and techniques used to identify devices on a network. Rationale for non-applicability: The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
Checks: C-44012r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40212r1_fix

e requirement is NA. No fix is required.

b
Applications designed to enforce protocol formats must employ automated mechanisms to enforce strict adherence to protocol format.
SC-7 - Medium - CCI-001125 - V-35672 - SV-46959r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001125
Version
SRG-APP-000253-MAPP-NA
Vuln IDs
  • V-35672
Rule IDs
  • SV-46959r1_rule
Automated mechanisms used to enforce protocol formats include, deep packet inspection firewalls and XML gateways. These devices verify adherence to the protocol specification (e.g., IEEE) at the application layer and serve to identify significant vulnerabilities that cannot be detected by devices operating at the network or transport layer. It is impractical to expect protocol format inspection to be conducted manually. Rationale for non-applicability: Mobile applications often employ communications protocols but they do not enforce protocol formats for other applications. The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
Checks: C-44014r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40214r1_fix

The requirement is NA. No fix is required.

b
Boundary protection applications must fail securely in the event of an operational failure.
SC-7 - Medium - CCI-001126 - V-35673 - SV-46960r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001126
Version
SRG-APP-000254-MAPP-NA
Vuln IDs
  • V-35673
Rule IDs
  • SV-46960r1_rule
Fail secure is a condition achieved by the application of a set of information system mechanisms to ensure that in the event of an operational failure of a boundary protection device at a managed interface (e.g., router, firewall, guard, application gateway residing on a protected sub network commonly referred to as a demilitarized zone), the system does not enter into an unsecure state where intended security properties no longer hold. A failure of a boundary protection device cannot lead to, or cause information external to the boundary protection device to enter the device, nor can a failure permit unauthorized information release. Rationale for non-applicability: Mobile applications do not provide network services to other devices. Most mobile devices function outside the organization's security boundary and therefore are not positioned to provide boundary protection services in any case
Checks: C-44015r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40215r1_fix

The requirement is NA. No fix is required.

b
Boundary protection applications must be capable of preventing public access into the organizations internal networks except as appropriately mediated by managed interfaces.
SC-7 - Medium - CCI-001100 - V-35675 - SV-46962r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001100
Version
SRG-APP-000255-MAPP-NA
Vuln IDs
  • V-35675
Rule IDs
  • SV-46962r1_rule
Access into an organization's internal network and to key internal boundaries must be tightly controlled and managed. Applications monitoring and/or controlling communications at the external boundary of the system and at key internal boundaries must be capable of preventing public access into the organization's internal networks except as appropriately mediated by managed interfaces. Rationale for non-applicability: Mobile applications do not provide network services to other devices. Most mobile devices function outside the organization's security boundary and therefore are not positioned to provide boundary protection services in any case.
Checks: C-44017r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40217r1_fix

The requirement is NA. No fix is required.

b
Any software application designed to function as a firewall must be capable employing a default deny all configuration.
SC-7 - Medium - CCI-001109 - V-35677 - SV-46964r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001109
Version
SRG-APP-000256-MAPP-NA
Vuln IDs
  • V-35677
Rule IDs
  • SV-46964r1_rule
A firewall default deny is a firewall configuration setting that will force the administrator to explicitly allow network or application traffic rather than allowing all traffic by default. The purpose is to prevent unmanaged access into the internal network or in the case of an application firewall, to application content, features, or functionality. Rationale for non-applicability: Mobile applications do not provide network services to other devices. Most mobile devices function outside the organization's security boundary and therefore are not positioned to provide boundary protection services in any case.
Checks: C-44019r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40219r1_fix

The requirement is NA. No fix is required.

b
Applications providing remote connectivity must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communications path with resources in external networks.
SC-7 - Medium - CCI-001111 - V-35688 - SV-46975r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001111
Version
SRG-APP-000257-MAPP-NA
Vuln IDs
  • V-35688
Rule IDs
  • SV-46975r1_rule
This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings that are not configurable by the user of that device. An example of a non-remote communications path from a remote device is a virtual private network. When a non-remote connection is established using a virtual private network, the configuration settings prevent split-tunneling. Split-tunneling might otherwise be used by remote users to communicate with the information system as an extension of that system and to communicate with local resources such as, a printer or file server. Since the remote device, when connected by a non-remote connection, becomes an extension of the information system, allowing dual communications paths such as split-tunneling would be, in effect, allowing unauthorized external connections into the system. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
Checks: C-44030r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40230r1_fix

The requirement is NA. No fix is required.

b
Proxy applications must support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy applications must also be configurable with o
SC-7 - Medium - CCI-001112 - V-35690 - SV-46977r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001112
Version
SRG-APP-000258-MAPP-NA
Vuln IDs
  • V-35690
Rule IDs
  • SV-46977r1_rule
External networks are networks outside the control of the organization. Proxy servers support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy servers are also configurable with organization-defined lists of authorized and unauthorized websites. Rationale for non-applicability: Mobile applications do not provide network services to other devices.
Checks: C-44033r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40233r1_fix

e requirement is NA. No fix is required.

b
Applications performing extrusion detection must be capable of denying network traffic and auditing internal users (or malicious code) posing a threat to external information systems.
SC-7 - Medium - CCI-001115 - V-35692 - SV-46979r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001115
Version
SRG-APP-000259-MAPP-NA
Vuln IDs
  • V-35692
Rule IDs
  • SV-46979r1_rule
Detecting internal actions that may pose a security threat to external information systems is sometimes termed extrusion detection. Extrusion detection at the information system boundary includes the analysis of network traffic (incoming as well as, outgoing) looking for indications of an internal threat to the security of external systems. Rationale for non-applicability: The requirement for application sandboxing precludes applications from providing extrusion detection for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
Checks: C-44035r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40234r1_fix

The requirement is NA. No fix is required.

b
Applications that serve to protect organizations and individuals from spam messages must incorporate update mechanisms updating protection mechanisms and signature updates when new application releases are available in accordance with organizational configuration management policies and procedures.
SI-8 - Medium - CCI-001306 - V-35693 - SV-46980r1_rule
RMF Control
SI-8
Severity
M
CCI
CCI-001306
Version
SRG-APP-000260-MAPP-NA
Vuln IDs
  • V-35693
Rule IDs
  • SV-46980r1_rule
Senders of spam messages are continually modifying their tactics and source email addresses in order to elude protection mechanisms. To stay up-to-date with the changing threat and to identify spam messages, it is critical that spam protection mechanisms are kept current. Rationale for non-applicability: Enterprise email server functionality is not within the scope of the Mobile Applications SRG, which applies to single-user applications that do not provide server functionality to other hosts.
Checks: C-44036r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40236r1_fix

The requirement is NA. No fix is required.

b
Applications that are utilized to address the issue of spam and provide protection from spam must automatically update any and all spam protection measures including signature definitions.
SI-8 - Medium - CCI-001308 - V-35694 - SV-46981r1_rule
RMF Control
SI-8
Severity
M
CCI
CCI-001308
Version
SRG-APP-000261-MAPP-NA
Vuln IDs
  • V-35694
Rule IDs
  • SV-46981r1_rule
Originators of spam emails are constantly changing their source email addresses in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment which necessitates an automatic update capability. Rationale for non-applicability: Enterprise email server functionality is not within the scope of the Mobile Applications SRG, which applies to single-user applications that do not provide server functionality to other hosts.
Checks: C-44038r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40238r1_fix

The requirement is NA. No fix is required.

b
Applications utilized for integrity verification must detect unauthorized changes to software and information.
SI-7 - Medium - CCI-001297 - V-35696 - SV-46983r1_rule
RMF Control
SI-7
Severity
M
CCI
CCI-001297
Version
SRG-APP-000262-MAPP-NA
Vuln IDs
  • V-35696
Rule IDs
  • SV-46983r1_rule
Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts. Rationale for non-applicability: The MDM SRG addresses integrity verification on mobile devices.
Checks: C-44039r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40239r1_fix

The requirement is NA. No fix is required.

b
Applications must provide automated support for the management of distributed security testing.
SI-6 - Medium - CCI-001295 - V-35697 - SV-46984r1_rule
RMF Control
SI-6
Severity
M
CCI
CCI-001295
Version
SRG-APP-000263-MAPP-NA
Vuln IDs
  • V-35697
Rule IDs
  • SV-46984r1_rule
The need to verify security functionality applies to all security functions. For those security functions that are not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include: startup, restart, shutdown, and abort. Rationale for non-applicability: The MDM SRG addresses automated support for the management of distributed security testing.
Checks: C-44040r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40240r1_fix

The requirement is NA. No fix is required.

b
The mobile application must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission.
SC-9 - Medium - CCI-001131 - V-35698 - SV-46985r1_rule
RMF Control
SC-9
Severity
M
CCI
CCI-001131
Version
SRG-APP-000264-MAPP-00057
Vuln IDs
  • V-35698
Rule IDs
  • SV-46985r1_rule
Unencrypted sensitive application data could be intercepted in transit. Encryption of data in transit will protect the data from being extricated, modified or being used for malicious purposes. When the data is encrypted prior to transmission, the risk of unauthorized disclosure from interception and the subsequent use thereof is greatly reduced.
Checks: C-44041r1_chk

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.

Fix: F-40241r1_fix

Configure the application or leverage OS or other applications that provide protection of data in transit. Otherwise modify the code to provide such protections.

b
The mobile application must identify potentially security-relevant error conditions.
SI-11 - Medium - CCI-001311 - V-35699 - SV-46986r1_rule
RMF Control
SI-11
Severity
M
CCI
CCI-001311
Version
SRG-APP-000265-MAPP-00058
Vuln IDs
  • V-35699
Rule IDs
  • SV-46986r1_rule
The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. An error condition can occur when an attacker provides unexpected values at an input prompt, causing the mobile application to crash or force it to excessively consume resources, such as battery, memory and CPU. This can also expose the application to data confidentiality and integrity issues as a result of the attacker gaining control of the device. Applying this control assures that security-relevant issues arising from data input correctness are addressed.
Checks: C-44042r1_chk

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.

Fix: F-40242r1_fix

Modify code to identify potentially-relevant error conditions.

b
The mobile application must not include sensitive information in system logs not necessary for IA functions.
SI-11 - Medium - CCI-001312 - V-35700 - SV-46987r1_rule
RMF Control
SI-11
Severity
M
CCI
CCI-001312
Version
SRG-APP-000266-MAPP-00059
Vuln IDs
  • V-35700
Rule IDs
  • SV-46987r1_rule
The application must only generate messages that provide information necessary for corrective actions and without revealing organization defined sensitive or potentially harmful information. Any application providing too much information in system logs and in administrative messages to the screen risks compromising the data and security of the application and system. This control assures DoD is given greater protection against authentication credentials being exposed to both internal and malicious external users, when an error occurs. Please refer to CWE 388 for further information. The MAPP SRG Overview contains additional information on CWEs.
Checks: C-44043r2_chk

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.

Fix: F-40243r1_fix

Modify code for logging functions to exclude sensitive information not necessary for IA functions from being written to the logs.

a
The mobile application must not transmit error messages to any entity other than authorized audit logs, the MDM, or the device display.
SI-11 - Low - CCI-001314 - V-35701 - SV-46988r1_rule
RMF Control
SI-11
Severity
L
CCI
CCI-001314
Version
SRG-APP-000267-MAPP-00060
Vuln IDs
  • V-35701
Rule IDs
  • SV-46988r1_rule
Error messages that are transmitted outside of the application environment reveal weaknesses in the application 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 application may have are restricted to the user and the personnel who have access to audit logs.
Checks: C-44044r3_chk

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.

Fix: F-40244r1_fix

Modify code to send error messages to MOS audit logs, the MDM or the device display.

a
The mobile application must alert the MOS or MDM upon each instance of an application component failure
SI-13 - Low - CCI-001328 - V-35702 - SV-46989r1_rule
RMF Control
SI-13
Severity
L
CCI
CCI-001328
Version
SRG-APP-000268-MAPP-00061
Vuln IDs
  • V-35702
Rule IDs
  • SV-46989r1_rule
An application that suffers a component failure is vulnerable to exposure that leaves the application, device, and stored data exposed to potential malicious activity. One component that may fail, yet leave the application operational is a security module that provides encryption of all data at rest or in transit. Similarly, a module that labels data with the appropriate classification attribute could also fail, yet allow the application to continue to function. In these instances, and with components that have failed, the application is no longer able to protect itself to the same level of security when fully operational. Alerts sent to the MOS provide information that can be used to initiate a fix or invoke incident response procedures.
Checks: C-44045r1_chk

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.

Fix: F-40245r1_fix

Modify code to alert the MOS when an application component fails.

b
Applications providing patch management capabilities must support the organizational requirements to install software updates automatically.
SI-2 - Medium - CCI-001232 - V-35703 - SV-46990r1_rule
RMF Control
SI-2
Severity
M
CCI
CCI-001232
Version
SRG-APP-000269-MAPP-NA
Vuln IDs
  • V-35703
Rule IDs
  • SV-46990r1_rule
Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously. Anytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability. Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates. Rationale for non-applicability: The MDM determines the state of information system components with respect to flaw remediation. This is outside the scope of this SRG. Moreover, typically mobile applications are not "patched" but are replaced with an updated version.
Checks: C-44046r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40246r1_fix

The requirement is NA. No fix is required.

b
Applications serving to determine the state of information system components with regard to flaw remediation (patching) must use automated mechanisms to make that determination. The automation schedule must be determined on an organization-defined basis.
SI-2 - Medium - CCI-001233 - V-35704 - SV-46991r1_rule
RMF Control
SI-2
Severity
M
CCI
CCI-001233
Version
SRG-APP-000270-MAPP-NA
Vuln IDs
  • V-35704
Rule IDs
  • SV-46991r1_rule
Organizations are required to identify information systems containing software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws) and report this information to designated organizational officials with information security responsibilities (e.g., senior information security officers, information system security managers, information systems security officers). To support this requirement, an automated process or mechanism is required. This role is usually assigned to patch management software that is deployed in order to track the number of systems installed in the network, as well as, the types of software installed on these systems, the corresponding versions, and the related flaws that require patching. Rationale for non-applicability: The MDM determines the state of information system components with respect to flaw remediation. This is outside the scope of this SRG. Moreover, typically mobile applications are not "patched" but are replaced with an updated version.
Checks: C-44047r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40247r1_fix

The requirement is NA. No fix is required.

b
The application must support organizational requirements to employ automated patch management tools to facilitate flaw remediation to organization-defined information system components. Patch management tools must be automated.
SI-2 - Medium - CCI-001237 - V-35705 - SV-46992r1_rule
RMF Control
SI-2
Severity
M
CCI
CCI-001237
Version
SRG-APP-000271-MAPP-NA
Vuln IDs
  • V-35705
Rule IDs
  • SV-46992r1_rule
The organization (including any contractor to the organization) shall promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, shall also be addressed expeditiously. Due to information system integrity and availability concerns, organizations shall give careful consideration to the methodology used to carry out automatic updates. Rationale for non-applicability: Automated updates of mobile application software is an MDM function and is therefore outside the scope of this SRG.
Checks: C-44048r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40248r1_fix

The requirement is NA. No fix is required.

b
The application must automatically update malicious code protection mechanisms, including signature definitions. Examples include anti-virus signatures and malware data files employed to identify and/or block malicious software from executing.
SI-3 - Medium - CCI-001247 - V-35706 - SV-46993r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001247
Version
SRG-APP-000272-MAPP-NA
Vuln IDs
  • V-35706
Rule IDs
  • SV-46993r1_rule
Anti-virus and malicious software detection applications utilize signature definitions in order to identify viruses and other malicious software. These signature definitions need to be constantly updated in order to identify the new threats that are discovered every day. All anti-virus and malware software shall come with an update mechanism that automatically updates these signatures. The organization (including any contractor to the organization) is required to promptly install security-relevant malicious code protection software updates (e.g., anti-virus signature updates and hot fixes). Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: The MDM SRG addresses white listing of applications, which is the primary mechanism for protecting mobile devices from malware.
Checks: C-44049r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40249r1_fix

The requirement is NA. No fix is required.

b
The application must prevent non-privileged users from circumventing malicious code protection capabilities.
SI-3 - Medium - CCI-001248 - V-35707 - SV-46994r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001248
Version
SRG-APP-000273-MAPP-NA
Vuln IDs
  • V-35707
Rule IDs
  • SV-46994r1_rule
Malicious code protection software must be protected so as to prevent a non-privileged user or malicious piece of software from disabling the protection mechanism. A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Examples include the capability for non-administrative user's to turn off or otherwise disable anti-virus. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44050r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40250r1_fix

The requirement is NA. No fix is required.

b
Malicious code protection applications must update malicious code protection mechanisms only when directed by a privileged user.
SI-3 - Medium - CCI-001249 - V-35708 - SV-46995r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001249
Version
SRG-APP-000274-MAPP-NA
Vuln IDs
  • V-35708
Rule IDs
  • SV-46995r1_rule
Malicious code protection software must be protected to prevent a non-privileged user or malicious piece of software from manipulating the protection update mechanism. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44051r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40251r1_fix

The requirement is NA. No fix is required.

b
The mobile application must provide notification of failed automated security tests.
SI-6 - Medium - CCI-001294 - V-35709 - SV-46996r1_rule
RMF Control
SI-6
Severity
M
CCI
CCI-001294
Version
SRG-APP-000275-MAPP-00062
Vuln IDs
  • V-35709
Rule IDs
  • SV-46996r1_rule
Automated security tests may include checking the cryptographic hash of key application files, and verifying the presence of critical MOS services, the presence of a VPN connection, correct file permission, or other security functionality. The need to verify security functionality applies to all security functions, and can be achieved through automated security tests of the application. When an application fails one of its automated security tests with security components unavailable or non-functional, the application is no longer able to protect itself to the same level of security were the security components functional. In applying this control, the application is able to activate an alarm and/or automatically notify the user a security test has failed and provides the user a greater level of security knowing that the application should stop being used. Logging the event is also an acceptable means of notification.
Checks: C-44052r1_chk

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.

Fix: F-40252r1_fix

Modify code to send a notification to the MOS logs, MDM, or user when an application fails an automated security test.

b
Applications providing malicious code protection must support organizational requirements to update malicious code protection mechanisms (including signature definitions) whenever new releases are available in accordance with organizational configuration
SI-3 - Medium - CCI-001240 - V-35710 - SV-46997r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001240
Version
SRG-APP-000276-MAPP-NA
Vuln IDs
  • V-35710
Rule IDs
  • SV-46997r1_rule
Malicious code protection mechanisms include, but are not limited to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44053r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40253r1_fix

The requirement is NA. No fix is required.

b
Applications scanning for malicious code must support organizational requirements to configure malicious code protection mechanisms to perform periodic scans of the information system on an organization-defined frequency.
SI-3 - Medium - CCI-001241 - V-35711 - SV-46998r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001241
Version
SRG-APP-000277-MAPP-NA
Vuln IDs
  • V-35711
Rule IDs
  • SV-46998r1_rule
Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed. This software must periodically scan the system to search for malware on an organization defined frequency. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44054r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40254r1_fix

The requirement is NA. No fix is required.

b
Applications providing malicious code protection must support organizational requirements to configure malicious code protection mechanisms to perform real-time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy.
SI-3 - Medium - CCI-001242 - V-35712 - SV-46999r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001242
Version
SRG-APP-000278-MAPP-NA
Vuln IDs
  • V-35712
Rule IDs
  • SV-46999r1_rule
Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44055r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40255r1_fix

The requirement is NA. No fix is required.

b
Applications providing malicious code protection must support organizational requirements to be configured to perform organization-defined action(s) in response to malicious code detection.
SI-3 - Medium - CCI-001243 - V-35713 - SV-47000r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001243
Version
SRG-APP-000279-MAPP-NA
Vuln IDs
  • V-35713
Rule IDs
  • SV-47000r1_rule
Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Applications providing this capability must be able to perform actions in response to detected malware. Responses include, but are not limited to, quarantine, deletion, and alerting. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44056r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40256r1_fix

The requirement is NA. No fix is required.

b
Applications providing malicious code protection must support organizational requirements to address the receipt of false positives during malicious code detection, eradication efforts, and the resulting potential impact on the availability of the information system.
SI-3 - Medium - CCI-001245 - V-35714 - SV-47001r1_rule
RMF Control
SI-3
Severity
M
CCI
CCI-001245
Version
SRG-APP-000280-MAPP-NA
Vuln IDs
  • V-35714
Rule IDs
  • SV-47001r1_rule
In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Applications providing this capability must have an ability to address the issue of false alerts. False alerts can overwhelm reporting and administrative interfaces making it difficult to identify the true threat. A filtering capability that serves to identify and remove false positives is often employed to address this issue. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
Checks: C-44057r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40257r1_fix

The requirement is NA. No fix is required.

b
Intrusion detection software must be able to interconnect using standard protocols to create a system wide intrusion detection system.
SI-4 - Medium - CCI-001259 - V-35715 - SV-47002r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001259
Version
SRG-APP-000281-MAPP-NA
Vuln IDs
  • V-35715
Rule IDs
  • SV-47002r1_rule
When utilizing intrusion detection software, monitoring components are usually dispersed throughout the network, such as, when utilizing HIDS and multiple NIDS sensors. In order to leverage the capabilities of intrusion detection systems to get a complete overall view of network and host activity, these separate components must be able to report and react to activity they detect. Non-standard or custom communication protocols do not provide the reliability and veracity required of an enterprise class intrusion detection system. An example of a custom protocol includes, but is not limited to, vendor specific communication protocols that have not undergone IETF RFC evaluation and/or are not in common use throughout the Internet as a whole. Rationale for non-applicability: The MDM SRG addresses mechanisms that check the integrity of the mobile device.
Checks: C-44058r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40258r1_fix

The requirement is NA. No fix is required.

b
For those instances where the organization requires encrypted traffic to be visible to information system monitoring tools, the application transmitting the encrypted traffic must make provisions to allow that traffic to be visible to specific system monitoring.
SI-4 - Medium - CCI-001272 - V-35717 - SV-47004r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001272
Version
SRG-APP-000282-MAPP-NA
Vuln IDs
  • V-35717
Rule IDs
  • SV-47004r1_rule
There is a recognized need to balance encrypting traffic versus the need to have insight into the traffic from a monitoring perspective. For some organizations, the need to ensure the confidentiality of traffic is paramount; for others, the mission-assurance concerns are greater. Rationale for non-applicability: The mobile application resides at a network endpoint. If it performs end-to-end encryption, then network traffic will not be visible to intermediate devices. IF there is a requirement for monitoring of this traffic, keys must be shared with the intermediate device. Achieving this capability is outside the scope of the mobile application, as the necessary modifications must be made to the intermediate device, not the end points.
Checks: C-44060r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40260r1_fix

The requirement is NA. No fix is required.

b
Applications providing malware and/or firewall protection must monitor inbound and outbound communications for unauthorized activities or conditions.
SI-4 - Medium - CCI-001262 - V-35718 - SV-47005r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001262
Version
SRG-APP-000283-MAPP-NA
Vuln IDs
  • V-35718
Rule IDs
  • SV-47005r1_rule
Unusual/unauthorized activities or conditions include internal traffic indicating the presence of malicious code within an information system or propagating among system components, the unauthorized export of information, or signaling to an external information system. Evidence of malicious code is used to identify potentially compromised information systems or information system components. Examples of applications that provide monitoring capability for unusual/unauthorized activities include, but are not limited to, Intrusion Detection, Anti-Virus and Malware etc. Rationale for non-applicability: The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the mobile application could perform a man-in-the-middle attack on other applications running on the device.
Checks: C-44061r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40261r1_fix

The requirement is NA. No fix is required.

b
Applications that detect and alarm on security events such as Intrusion Detection, Firewalls, Anti-Virus, or Malware must provide near real-time alert notification.
SI-4 - Medium - CCI-001263 - V-35719 - SV-47006r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001263
Version
SRG-APP-000284-MAPP-NA
Vuln IDs
  • V-35719
Rule IDs
  • SV-47006r1_rule
When an intrusion detection security event occurs it is imperative the application that has detected the event immediately notify the appropriate support personnel so they can respond accordingly. Lack of this capability increases the risk that attacks will go unnoticed or responses will be delayed. Rationale for non-applicability: The MDM SRG covers the mechanisms for security-related alerts. This SRG strongly encourages that mobile applications forward security-related events to the system audit logs accessible by the MDM centralized auditing solution.
Checks: C-44062r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40262r1_fix

The requirement is NA. No fix is required.

b
Applications providing IDS and prevention capabilities must prevent non-privileged users from circumventing intrusion detection and prevention capabilities.
SI-4 - Medium - CCI-001265 - V-35720 - SV-47007r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001265
Version
SRG-APP-000285-MAPP-NA
Vuln IDs
  • V-35720
Rule IDs
  • SV-47007r1_rule
Any application providing intrusion detection and prevention capabilities must be architected and implemented so as to prevent non-privileged users from circumventing such protections. This can be accomplished through the use of user roles, use of proper systems permissions, auditing, logging, etc. Rationale for non-applicability: The MDM SRG addresses mechanisms that check the integrity of the mobile device. The mobile operating system enforces controls that prevent circumvention of MDM capabilities.
Checks: C-44063r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40263r1_fix

The requirement is NA. No fix is required.

b
Applications providing notifications regarding suspicious events must include the capability to notify an organization-defined list of response personnel who are identified by name and/or by role.
SI-4 - Medium - CCI-001266 - V-35722 - SV-47009r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001266
Version
SRG-APP-000286-MAPP-NA
Vuln IDs
  • V-35722
Rule IDs
  • SV-47009r1_rule
Incident response applications are by their nature designed to monitor, detect, and alarm on defined events occurring on the system or on the network. A large part of their functionality is accurate and timely notification of events. Notifications can be made more efficient by the creation of notification groups containing members who would be responding to a particular alarm or event. Rationale for non-applicability: The MDM SRG covers the mechanisms for security related alerts.
Checks: C-44065r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40265r1_fix

The requirement is NA. No fix is required.

a
The mobile application must notify the user or MDM, or shut down if it fails an automated security test.
SI-4 - Low - CCI-001670 - V-35723 - SV-47010r1_rule
RMF Control
SI-4
Severity
L
CCI
CCI-001670
Version
SRG-APP-000287-MAPP-NA
Vuln IDs
  • V-35723
Rule IDs
  • SV-47010r1_rule
System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action that the application takes to terminate suspicious events. A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system. Rationale for non-applicability: Security monitoring functions are out of scope, as they are primarily addressed through MOS and MDM controls.
Checks: C-44066r2_chk

This requirement is NA for the MAPP SRG.

Fix: F-40266r2_fix

The requirement is NA. No fix is required.

b
The application must enforce organizational requirements to protect information obtained from intrusion monitoring tools from unauthorized access, modification, and deletion.
SI-4 - Medium - CCI-001269 - V-35725 - SV-47012r1_rule
RMF Control
SI-4
Severity
M
CCI
CCI-001269
Version
SRG-APP-000288-MAPP-NA
Vuln IDs
  • V-35725
Rule IDs
  • SV-47012r1_rule
Intrusion monitoring applications are by their nature designed to monitor and record network and system traffic and activity. They can accumulate a significant amount of sensitive data, examples of which could include user account information and application data not related to the intrusion monitoring application itself. Intrusion monitoring tools also obtain information that is critical to conducting forensic analysis on attacks occurring within the network. This data may be sensitive in nature. Information obtained by intrusion monitoring applications in the course of evaluating network and system security needs to be protected. Rationale for non-applicability: Intrusion monitoring tools are not within the scope of this SRG. The MDM SRG addresses mechanisms that check the integrity of the mobile device.
Checks: C-44068r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40268r1_fix

The requirement is NA. No fix is required.

b
The application must either implement compensating security controls or the organization explicitly accepts the risk of not performing the verification as required.
SI-6 - Medium - CCI-001291 - V-35726 - SV-47013r1_rule
RMF Control
SI-6
Severity
M
CCI
CCI-001291
Version
SRG-APP-000289-MAPP-NA
Vuln IDs
  • V-35726
Rule IDs
  • SV-47013r1_rule
Application security functional testing involves testing the application for conformance to the applications security function specifications, as well as, for the underlying security model. The need to verify security functionality applies to all security functions. The conformance criteria state the conditions necessary for the application to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry. Organizations may define conditions requiring verification and the frequency in which such testing occurs. Security function testing usually occurs during the development phase and can in some instances occur in the production phase if the developer provides the security conformance criteria or if the conformance criteria can be established. There are application testing frameworks available that can perform functional testing on production systems however they are limited in their applicability and are language or product centric. Rationale for non-applicability: An assumption of this SRG is that the controls delineated in this SRG reduce risk to an acceptable level and that additional compensating controls are not required. Defense in depth is also provided by controls in the MOS SRG and MDM SRG.
Checks: C-44069r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40269r1_fix

The requirement is NA. No fix is required.

b
The application must use cryptographic mechanisms to protect the integrity of audit tools
AU-9 - Medium - CCI-001496 - V-35728 - SV-47015r1_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001496
Version
SRG-APP-000290-MAPP-NA
Vuln IDs
  • V-35728
Rule IDs
  • SV-47015r1_rule
Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced. An example is a checksum hash of the file or files. Applications that function as audit tools must use cryptographic mechanisms to protect the integrity of the tools or allow cryptographic protection mechanisms to be applied to their tools. All applications must not impede or hamper this requirement. Rationale for non-applicability: Mobile devices are not expected to have local audit tools. Instead, the mobile device will transfer logs to centralized audit tools for analysis and reporting.
Checks: C-44071r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40271r1_fix

The requirement is NA. No fix is required.

b
The application must notify appropriate individuals when accounts are created.
AC-2 - Medium - CCI-001683 - V-35729 - SV-47016r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001683
Version
SRG-APP-000291-MAPP-NA
Vuln IDs
  • V-35729
Rule IDs
  • SV-47016r1_rule
Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must support the requirement to notify appropriate individuals upon account creation. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
Checks: C-44072r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40272r1_fix

The requirement is NA. No fix is required.

b
The application must notify appropriate individuals when accounts are modified.
AC-2 - Medium - CCI-001684 - V-35730 - SV-47017r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001684
Version
SRG-APP-000292-MAPP-NA
Vuln IDs
  • V-35730
Rule IDs
  • SV-47017r1_rule
Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify or copy an existing account. Notification of account modification is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the modification of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created or modified and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must support the requirement to notify appropriate individuals when accounts are modified. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
Checks: C-44073r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40273r1_fix

The requirement is NA. No fix is required.

b
The application must notify appropriate individuals when account disabling actions are taken.
AC-2 - Medium - CCI-001685 - V-35731 - SV-47018r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001685
Version
SRG-APP-000293-MAPP-NA
Vuln IDs
  • V-35731
Rule IDs
  • SV-47018r1_rule
When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must audit account disabling actions and, as required, notify as required the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must notify, or leverage other mechanisms that notify, the appropriate individuals when accounts disabling actions are taken. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
Checks: C-44074r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40274r1_fix

The requirement is NA. No fix is required

b
The application must notify appropriate individuals when accounts are terminated.
AC-2 - Medium - CCI-001686 - V-35732 - SV-47019r1_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001686
Version
SRG-APP-000294-MAPP-NA
Vuln IDs
  • V-35732
Rule IDs
  • SV-47019r1_rule
When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms that meet or exceed access control policy requirements. Examples include but are not limited to Active Directory and LDAP. The application must automatically notify the appropriate individuals when accounts are terminated. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
Checks: C-44075r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40275r1_fix

The requirement is NA. No fix is required.

b
The mobile application code must not contain hardcoded references to resources external to the application.
CM-6 - Medium - CCI-000366 - V-35746 - SV-47033r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00064
Vuln IDs
  • V-35746
Rule IDs
  • SV-47033r1_rule
Hardcoded resources include URLs and path references to files outside of the application environment. If an adversary is aware of such references, they can attack the application 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 application code.
Checks: C-44089r1_chk

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.

Fix: F-40290r1_fix

Remove hardcoded resource references from the application code.

a
The mobile application must remove temporary files when it terminates.
CM-6 - Low - CCI-000366 - V-35747 - SV-47034r1_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00065
Vuln IDs
  • V-35747
Rule IDs
  • SV-47034r1_rule
Temporary files left on the system after an application 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 application terminates greatly mitigates the risk of this attack that would exploit these files and use them to re-launch the application, enjoy user privileges or to breach the confidentiality or integrity of the data stored on the device.
Checks: C-44090r2_chk

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.

Fix: F-40291r1_fix

Modify code to remove all temporary files whenever the application is terminated.

b
The mobile application must clear or overwrite memory blocks used to process sensitive data.
CM-6 - Medium - CCI-000366 - V-35748 - SV-47035r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00067
Vuln IDs
  • V-35748
Rule IDs
  • SV-47035r1_rule
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 application can overwrite memory blocks, the possibility exists for an attacker to cause the application to crash and analyze a memory dump of the application for sensitive information. Clearing memory will ensure the DoD the application 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 applications. Please refer to CWEs: 14, 226, 244, and 591 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.
Checks: C-44092r1_chk

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.

Fix: F-40293r1_fix

Modify code to clear memory blocks used for storing sensitive and classified data before the memory is released to other processes.

a
The mobile application must remove cookies or information used to track a users identity when it terminates.
CM-6 - Low - CCI-000366 - V-35749 - SV-47036r1_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00066
Vuln IDs
  • V-35749
Rule IDs
  • SV-47036r1_rule
If the application 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 lost or stolen. Such information could also be used to track the user across application sessions or even across different applications, which poses an OPSEC risk. The temporary data could be used to re-authenticate the user or allow unauthorized access to sensitive data. Removing cookies assures 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.
Checks: C-44093r1_chk

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.

Fix: F-40294r1_fix

Configure or redesign the application to remove cookies or other information used to track the user's identity before the application exits.

b
The mobile application must not be vulnerable to integer arithmetic vulnerabilities.
CM-6 - Medium - CCI-000366 - V-35750 - SV-47037r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00068
Vuln IDs
  • V-35750
Rule IDs
  • SV-47037r1_rule
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 application 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.
Checks: C-44094r2_chk

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.

Fix: F-40295r1_fix

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.

b
The mobile application must not call functions vulnerable to buffer overflows.
CM-6 - Medium - CCI-000366 - V-35751 - SV-47038r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00069
Vuln IDs
  • V-35751
Rule IDs
  • SV-47038r1_rule
Buffer overflow attacks occur when improperly validated input is passed to an application overwriting of memory. Buffer overflow errors stop execution of the application 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 application that avoids buffer flow situations assures DoD greater availability of the application 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.
Checks: C-44095r2_chk

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.

Fix: F-40296r2_fix

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.

b
The mobile application must not have canonical representation vulnerabilities.
CM-6 - Medium - CCI-000366 - V-35752 - SV-47039r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00070
Vuln IDs
  • V-35752
Rule IDs
  • SV-47039r1_rule
Canonical representation issues arise when the name of a resource is used to control resource access. There are multiple methods of representing resource names on a computer system. An application relying solely on a resource name to control access may incorrectly make an access control decision if the name is specified in an unrecognized format. Through this control, DoD can be assured of greater security from inadvertent or malicious use of resources on the device that could, if used, would compromise the device, user and sensitive on-board data. Please refer to CWEs: 22, 73, 94, 98, 99, and 601 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.
Checks: C-44096r2_chk

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.

Fix: F-40297r2_fix

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.

b
The mobile application must not be vulnerable to race conditions.
CM-6 - Medium - CCI-000366 - V-35753 - SV-47040r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00071
Vuln IDs
  • V-35753
Rule IDs
  • SV-47040r1_rule
A race condition occurs when an application 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 application creating a deadlock situation. Racing can occur when the design uses global variables in place of local variables, multi-threaded application do 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 application, 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 application or certain components of the application 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.
Checks: C-44097r2_chk

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.

Fix: F-40298r1_fix

Remove race conditions from the code.

b
The mobile application must initialize all parameter values on start up.
CM-6 - Medium - CCI-000366 - V-35754 - SV-47041r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00073
Vuln IDs
  • V-35754
Rule IDs
  • SV-47041r1_rule
An application could be compromised, providing an attack vector to it if the application initialization process is not designed to keep the application in both a secure and functional state. Any operating parameter in the application, such as variables and settings, must be reset and initialized to default values otherwise an adversary, in possession of the device could access the application with privileges. An application that re-initializes its parameters at start up is assured a more secure session since the application has initialized all functional components that allow it to operate properly and thus securely.
Checks: C-44098r1_chk

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.

Fix: F-40299r1_fix

Modify code to ensure upon starting, the application initializes all parameter values.

c
The mobile application must not record or forward sensor data unless explicitly authorized to do so.
CM-6 - High - CCI-000366 - V-35755 - SV-47042r1_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00075
Vuln IDs
  • V-35755
Rule IDs
  • SV-47042r1_rule
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.
Checks: C-44099r1_chk

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.

Fix: F-40300r1_fix

Remove code that records or forwards sensor data or cease using the mobile application.

b
The mobile application installation package must be digitally signed in accordance with FIPS 186-3.
CM-6 - Medium - CCI-000366 - V-35756 - SV-47043r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00078
Vuln IDs
  • V-35756
Rule IDs
  • SV-47043r1_rule
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.
Checks: C-44101r1_chk

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.

Fix: F-40302r1_fix

Digitally sign the application package using FIPS 186-3 approved methods.

b
Applications must enforce information flow using dynamic control based on policy that allows or disallows information flow based on changing conditions or operational considerations.
AC-4 - Medium - CCI-000027 - V-35800 - SV-47087r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-000027
Version
SRG-APP-000055-MAPP-NA
Vuln IDs
  • V-35800
Rule IDs
  • SV-47087r1_rule
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. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet, blocking outside traffic claiming to be from within the organization and not passing any web requests to the Internet that are not from the internal web proxy. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Flow control is also based on the characteristics of the information and/or the information path. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
Checks: C-44146r1_chk

This requirement is NA for the MAPP SRG.

Fix: F-40348r1_fix

The requirement is NA. No fix is required.

c
The mobile application source code must not contain known malware.
CM-6 - High - CCI-000366 - V-35801 - SV-47088r1_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
SRG-APP-999999-MAPP-00077
Vuln IDs
  • V-35801
Rule IDs
  • SV-47088r1_rule
Malware will compromise the application data, device, and system to every possible compromising scenario. Under no circumstances will any code that is known to contain malware be used. The entire application ecosystem will operate at a higher security with much higher integrity than a system with known malware.
Checks: C-44147r1_chk

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.

Fix: F-40349r1_fix

Remove known malware from the application code.