Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

Mobile Application Security Requirements Guide

  • Version/Release: V1R1
  • Published: 2013-01-04
  • Released: 2012-12-13
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

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.
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
High
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
High
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
High
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
Medium
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
High
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
High
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
High
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Low
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
Medium
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
Medium
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
Medium
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
Low
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
High
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
High
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
High
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
High
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Low
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
High
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
Medium
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
Medium
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
Medium
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
Medium
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
Low
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Low
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
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
Medium
CCI
CCI-000831
Version
SRG-APP-000181-MAPP-NA
Vuln IDs
  • V-35507
Rule IDs
  • SV-46794r1_rule
<