Mobile Application Security Requirements Guide

U_Mobile_Application_V1R1_manual-xccdf.xml

Version/Release Published Filters Downloads Update
V1R1 2013-01-04      
Update existing CKLs to this version of the STIG
The Mobile Application Security Requirements Guide (SRG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the NIST 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Vuln Rule Version CCI Severity Title Description
SV-46339r1_rule SRG-APP-000001-MAPP-NA CCI-000054 MEDIUM 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. 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.
SV-46343r1_rule SRG-APP-000002-MAPP-NA CCI-000060 MEDIUM The application must ensure that the screen display is obfuscated when an application session lock event occurs. 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.
SV-46348r1_rule SRG-APP-000003-MAPP-NA CCI-000057 MEDIUM The application must support the requirement to initiate a session lock after an organization defined time period of system or application inactivity has transpired. 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.
SV-46350r1_rule SRG-APP-000004-MAPP-NA CCI-000058 MEDIUM Applications must ensure that users can directly initiate session lock mechanisms which prevent further access to the system. 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.
SV-46358r1_rule SRG-APP-000005-MAPP-NA CCI-000056 MEDIUM 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. 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.
SV-46370r1_rule SRG-APP-000006-MAPP-00001 CCI-001399 HIGH The mobile application must store an associated data attribute corresponding to the highest classification of data in the file it stores classified data. 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.
SV-46371r1_rule SRG-APP-000007-MAPP-00002 CCI-001400 HIGH The mobile application must not permit any classification attribute to be modified to a lower level of classification if it processes classified data. 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.
SV-46372r1_rule SRG-APP-000008-MAPP-00003 CCI-001401 HIGH The mobile application must include classification attributes with transmitted data if it transmits classified data. 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.
SV-46373r1_rule SRG-APP-000009-MAPP-00004 CCI-001424 MEDIUM The mobile application must assign a classification attribute to any newly created data file or stream if it stores, processes, or transmits classified data. 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.
SV-46374r1_rule SRG-APP-000009-MAPP-00005 CCI-001424 HIGH The mobile application must assign the classification corresponding to the highest classification of its elements whenever it combines data elements classified at multiple levels. 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.
SV-46380r1_rule SRG-APP-000010-MAPP-NA CCI-001425 MEDIUM The application must provide the capability to specify administrative users and grant them the right to change application security attributes pertaining to application data. 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.
SV-46382r1_rule SRG-APP-000011-MAPP-00006 CCI-001426 MEDIUM 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. 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.
SV-46384r1_rule SRG-APP-000012-MAPP-00007 CCI-001427 MEDIUM 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. 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.
SV-46387r1_rule SRG-APP-000013-MAPP-00008 CCI-001428 MEDIUM 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. 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.
SV-46393r1_rule SRG-APP-000014-MAPP-NA CCI-000068 MEDIUM Applications providing remote access capabilities must utilize approved cryptography to protect the confidentiality of remote access sessions. 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.
SV-46397r1_rule SRG-APP-000015-MAPP-NA CCI-001453 MEDIUM Applications providing remote access connectivity must use cryptography to protect the integrity of the remote access session. 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.
SV-46398r1_rule SRG-APP-000016-MAPP-NA CCI-000067 MEDIUM The application must employ automated mechanisms to facilitate the monitoring and control of remote access methods. 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.
SV-46400r1_rule SRG-APP-000017-MAPP-NA CCI-000069 MEDIUM Applications providing remote access must have capabilities that allow all remote access to be routed through managed access control points. 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.
SV-46402r1_rule SRG-APP-000018-MAPP-NA CCI-000071 MEDIUM The application must monitor for unauthorized remote connections to the information system on an organization-defined frequency. 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.
SV-46406r1_rule SRG-APP-000019-MAPP-NA CCI-001454 MEDIUM The application must ensure remote sessions for accessing an organization-defined list of security functions and security-relevant information are audited. 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.
SV-46409r1_rule SRG-APP-000020-MAPP-NA CCI-001436 MEDIUM 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. 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.
SV-46411r1_rule SRG-APP-000021-MAPP-NA CCI-000085 MEDIUM The application must monitor for unauthorized connections of mobile devices to organizational information systems. 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.
SV-46413r1_rule SRG-APP-000022-MAPP-00009 CCI-000087 MEDIUM 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. 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.
SV-46417r1_rule SRG-APP-000023-MAPP-NA CCI-000015 MEDIUM 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. 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.
SV-46432r1_rule SRG-APP-000024-MAPP-NA CCI-000016 MEDIUM The application must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period. 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.
SV-46433r1_rule SRG-APP-000025-MAPP-NA CCI-000017 MEDIUM The application must be capable of automatically disabling accounts after a 35 day period of account inactivity. 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.
SV-46434r1_rule SRG-APP-000026-MAPP-NA MEDIUM Applications must support the requirement to automatically audit account creation. 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.
SV-46436r1_rule SRG-APP-000027-MAPP-NA CCI-001403 MEDIUM Applications must support the requirement to automatically audit account modification. 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.
SV-46439r1_rule SRG-APP-000028-MAPP-NA CCI-001404 MEDIUM The application must automatically audit account disabling actions and notify appropriate individuals 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.
SV-46441r1_rule SRG-APP-000029-MAPP-NA CCI-001405 MEDIUM The application must automatically audit account termination and notify appropriate individuals. 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.
SV-46442r1_rule SRG-APP-000030-MAPP-NA CCI-001356 MEDIUM Applications must support the organizational requirement to automatically monitor on atypical usage of accounts. 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.
SV-46445r1_rule SRG-APP-000031-MAPP-NA CCI-000020 MEDIUM Service Oriented Architecture (SOA) based applications must dynamically manage user privileges and associated access authorizations. 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.
SV-46447r1_rule SRG-APP-000032-MAPP-NA CCI-000099 MEDIUM 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. 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.
SV-46451r1_rule SRG-APP-000033-MAPP-00010 CCI-000213 HIGH The mobile application must not modify, request, or assign values for operating system parameters unless necessary to perform application functions. 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.
SV-46453r1_rule SRG-APP-000033-MAPP-00011 CCI-000213 HIGH The mobile application must not execute as a privileged operating system process unless necessary to perform any application functions. 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.
SV-46455r1_rule SRG-APP-000033-MAPP-00012 CCI-000213 MEDIUM 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. 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.
SV-46456r1_rule SRG-APP-000034-MAPP-NA CCI-000021 MEDIUM The application must enforce dual authorization, based on organizational policies and procedures for organization-defined privileged commands. 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.
SV-46458r1_rule SRG-APP-000035-MAPP-00013 CCI-000022 MEDIUM 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. 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.
SV-46459r1_rule SRG-APP-000036-MAPP-NA CCI-001362 MEDIUM 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. 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.
SV-46460r1_rule SRG-APP-000037-MAPP-NA CCI-000024 MEDIUM The application must prevent access to organization-defined security-relevant information except during secure, non-operable system states. 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.
SV-46461r1_rule SRG-APP-000038-MAPP-NA CCI-001368 MEDIUM Applications providing information flow control must enforce approved authorizations for controlling the flow of information within the system 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. 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.
SV-46464r1_rule SRG-APP-000039-MAPP-NA CCI-001414 MEDIUM Applications providing information flow control must enforce approved authorizations for controlling the flow of information 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. 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.
SV-46466r1_rule SRG-APP-000040-MAPP-NA CCI-000025 MEDIUM Applications providing information flow control must use explicit security attributes on information, source, and destination objects as a basis for flow control decisions. 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.
SV-46467r1_rule SRG-APP-000041-MAPP-NA CCI-000034 MEDIUM Applications providing information flow control must provide the capability for privileged administrators to enable/disable security policy filters. 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.
SV-46468r1_rule SRG-APP-000042-MAPP-NA CCI-000035 MEDIUM Applications providing information flow controls must provide the capability for privileged administrators to configure security policy filters to support different organizational security policies. 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.
SV-46493r1_rule SRG-APP-000043-MAPP-NA CCI-000218 MEDIUM 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. 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.
SV-46494r1_rule SRG-APP-000044-MAPP-NA CCI-000219 MEDIUM Applications, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms. 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.
SV-46495r1_rule SRG-APP-000045-MAPP-00014 CCI-001372 MEDIUM 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. 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.
SV-46496r1_rule SRG-APP-000046-MAPP-NA CCI-001373 MEDIUM Applications designed to control information flow must provide the ability to detect unsanctioned information being transmitted across security domains. 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.
SV-46497r1_rule SRG-APP-000047-MAPP-NA CCI-001374 MEDIUM Applications must provide the ability to prohibit the transfer of unsanctioned information in accordance with security policy. 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.
SV-46498r1_rule SRG-APP-000048-MAPP-NA CCI-000221 MEDIUM Applications must provide the ability to enforce security policies regarding information on interconnected systems. 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.
SV-46515r1_rule SRG-APP-000049-MAPP-00015 CCI-001376 MEDIUM 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. 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.
SV-46516r1_rule SRG-APP-000050-MAPP-00016 CCI-001377 MEDIUM 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. 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.
SV-46517r1_rule SRG-APP-000051-MAPP-NA CCI-001555 MEDIUM Applications must uniquely identify destination domains for information transfer. 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.
SV-46518r1_rule SRG-APP-000052-MAPP-NA CCI-000223 MEDIUM The application must bind security attributes to information to facilitate information flow policy enforcement. 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.
SV-46526r1_rule SRG-APP-000053-MAPP-NA CCI-000224 MEDIUM Applications providing information flow control must track problems associated with the binding of security attributes to data. 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.
SV-46529r1_rule SRG-APP-000054-MAPP-NA CCI-000026 MEDIUM Applications must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions. 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.
SV-46530r1_rule SRG-APP-000056-MAPP-NA CCI-000028 MEDIUM Applications must prevent encrypted data from bypassing content-checking mechanisms. 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.
SV-46531r1_rule SRG-APP-000057-MAPP-00017 LOW The mobile application must enforce organization defined limitations on the embedding of data types within other data types. 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.
SV-46532r1_rule SRG-APP-000058-MAPP-NA CCI-000030 MEDIUM Applications must enforce information flow control on metadata. 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.
SV-46533r1_rule SRG-APP-000059-MAPP-NA CCI-000032 MEDIUM Applications must use security policy filters as a basis for making information flow control decisions. 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.
SV-46534r1_rule SRG-APP-000060-MAPP-NA CCI-001556 MEDIUM Applications providing information flow control must uniquely authenticate destination domains when transferring information. 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.
SV-46535r1_rule SRG-APP-000061-MAPP-00018 CCI-001557 LOW 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. 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.
SV-46536r1_rule SRG-APP-000062-MAPP-NA CCI-000037 MEDIUM Applications must support organizational requirements to implement separation of duties through assigned information access authorizations. 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.
SV-46537r1_rule SRG-APP-000063-MAPP-NA CCI-000040 MEDIUM 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. 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.
SV-46538r1_rule SRG-APP-000064-MAPP-NA CCI-000226 MEDIUM Applications must be able to function within separate processing domains (virtualized systems), when specified, so as to enable finer-grained allocation of user privileges. 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.
SV-46539r1_rule SRG-APP-000065-MAPP-NA CCI-000044 MEDIUM 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. 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.
SV-46540r1_rule SRG-APP-000066-MAPP-NA CCI-001452 MEDIUM The application must enforce the organization-defined time period during which the limit of consecutive invalid access attempts by a user is counted. 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.
SV-46542r1_rule SRG-APP-000067-MAPP-NA CCI-000047 MEDIUM 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. 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.
SV-46543r1_rule SRG-APP-000068-MAPP-NA CCI-000048 MEDIUM Applications must display an approved system use notification message or banner before granting access to the system. 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.
SV-46545r1_rule SRG-APP-000070-MAPP-NA CCI-001384 MEDIUM Applications must display an approved system use notification message or banner before granting access to the system. 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.
SV-46546r1_rule SRG-APP-000071-MAPP-NA CCI-000138 MEDIUM Applications must configure their auditing to reduce the likelihood of storage capacity being exceeded. 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.
SV-46547r1_rule SRG-APP-000072-MAPP-NA CCI-000137 MEDIUM Applications must allocate audit record storage capacity. 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.
SV-46548r1_rule SRG-APP-000073-MAPP-NA CCI-000870 MEDIUM Applications scanning for malicious code must scan all media used for system maintenance prior to use. 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.
SV-46549r1_rule SRG-APP-000074-MAPP-00020 CCI-001687 HIGH The mobile application must not execute unsigned DoD Mobile Code Policy Category 1A or 2 mobile code. 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.
SV-46550r1_rule SRG-APP-000074-MAPP-00021 CCI-001687 HIGH The mobile application must validate the signature on DoD Mobile Code Policy Category 1A and 2 mobile code before executing such code. 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.
SV-46551r1_rule SRG-APP-000074-MAPP-00022 CCI-001687 HIGH The mobile application must not permit DoD Mobile Code Policy Category 2 mobile code to access any resource not dedicated to the mobile application. 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.
SV-46552r1_rule SRG-APP-000074-MAPP-00023 CCI-001687 HIGH The mobile application must not use mobile code technology that is not yet categorized in accordance with the DoD Mobile Code Policy. 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.
SV-46553r1_rule SRG-APP-000075-MAPP-NA CCI-000052 MEDIUM Applications upon successful logon, must display to the user the date and time of the last logon (access). 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.
SV-46554r1_rule SRG-APP-000076-MAPP-NA CCI-000053 MEDIUM 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. 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.
SV-46555r1_rule SRG-APP-000077-MAPP-NA CCI-001391 MEDIUM 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. 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.
SV-46556r1_rule SRG-APP-000078-MAPP-NA CCI-001392 MEDIUM The application must notify the user of the number of unsuccessful login/access attempts occurring during an organization-defined time period. 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.
SV-46557r1_rule SRG-APP-000079-MAPP-NA CCI-001395 MEDIUM Applications must notify users of organization-defined security-related changes to the users account occurring during the organization-defined time period. 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.
SV-46558r1_rule SRG-APP-000080-MAPP-NA CCI-000166 MEDIUM The application must protect against an individual falsely denying having performed a particular action. 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.
SV-46559r1_rule SRG-APP-000081-MAPP-00024 CCI-001338 LOW The digital signature on the mobile application installation code must identify the entity responsible for the application. 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.
SV-46560r1_rule SRG-APP-000082-MAPP-00025 CCI-001339 MEDIUM If the mobile application processes digitally signed data or code, then it must validate the digital signature. 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.
SV-46561r1_rule SRG-APP-000083-MAPP-NA CCI-001340 MEDIUM Applications must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released. 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.
SV-46562r1_rule SRG-APP-000084-MAPP-NA CCI-001341 MEDIUM 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. 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.
SV-46563r1_rule SRG-APP-000085-MAPP-NA CCI-001693 MEDIUM Applications utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights. 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.
SV-46564r1_rule SRG-APP-000086-MAPP-NA CCI-000174 MEDIUM 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. 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.
SV-46565r1_rule SRG-APP-000087-MAPP-NA CCI-001694 MEDIUM Applications that utilize Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user. 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.
SV-46566r1_rule SRG-APP-000088-MAPP-NA CCI-001353 MEDIUM The application must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format. 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.
SV-46567r1_rule SRG-APP-000089-MAPP-NA CCI-000169 MEDIUM The application must provide audit record generation capability for defined auditable events within defined application components. 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.
SV-46568r1_rule SRG-APP-000090-MAPP-NA CCI-000171 MEDIUM The application must allow designated organizational personnel to select which auditable events are to be audited by specific components of the system. 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.
SV-46569r1_rule SRG-APP-000091-MAPP-NA CCI-000172 MEDIUM Applications must generate audit records for the DoD selected list of auditable events. 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.
SV-46570r1_rule SRG-APP-000092-MAPP-NA CCI-001464 MEDIUM The application must initiate session auditing upon start up. 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.
SV-46571r1_rule SRG-APP-000093-MAPP-NA CCI-001462 MEDIUM The application must provide the capability to capture, record, and log all content related to a user session. 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.
SV-46572r1_rule SRG-APP-000094-MAPP-NA CCI-001463 MEDIUM The application must provide the capability to remotely view/hear all content related to an established user session in real time. 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.
SV-46573r1_rule SRG-APP-000095-MAPP-NA CCI-000130 MEDIUM The application must produce audit records containing sufficient information to establish what type of events occurred. 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.
SV-46574r1_rule SRG-APP-000096-MAPP-NA CCI-000131 MEDIUM The application must produce audit records containing sufficient information to establish when (date and time) the events occurred. 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.
SV-46575r1_rule SRG-APP-000097-MAPP-NA CCI-000132 MEDIUM The application must produce audit records containing sufficient information to establish where the events occurred. 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.
SV-46576r1_rule SRG-APP-000098-MAPP-NA CCI-000133 MEDIUM The application must produce audit records containing sufficient information to establish the sources of the events. 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.
SV-46577r1_rule SRG-APP-000099-MAPP-NA CCI-000134 MEDIUM The application must produce audit records that contain sufficient information to establish the outcome (success or failure) of the events. 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.
SV-46578r1_rule SRG-APP-000100-MAPP-NA CCI-001487 MEDIUM The application must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event. 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.
SV-46579r1_rule SRG-APP-000101-MAPP-NA CCI-000135 MEDIUM Applications must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. 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.
SV-46580r1_rule SRG-APP-000102-MAPP-NA CCI-000136 MEDIUM 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. 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.
SV-46581r1_rule SRG-APP-000103-MAPP-NA CCI-000143 MEDIUM 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. 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.
SV-46582r1_rule SRG-APP-000104-MAPP-NA CCI-000144 MEDIUM The application must provide a real-time alert when organization-defined audit failure events occur. 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.
SV-46583r1_rule SRG-APP-000105-MAPP-NA CCI-000145 MEDIUM The application must enforce configurable traffic volume thresholds representing auditing capacity for network traffic. 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.
SV-46584r1_rule SRG-APP-000106-MAPP-NA CCI-001574 MEDIUM The application must reject or delay, as defined by the organization, network traffic generated above configurable traffic volume thresholds. 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.
SV-46585r1_rule SRG-APP-000107-MAPP-NA CCI-001343 MEDIUM The application must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists. 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.
SV-46626r1_rule SRG-APP-000108-MAPP-NA CCI-000139 MEDIUM The application must alert designated organizational officials in the event of an audit processing failure. 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.
SV-46627r1_rule SRG-APP-000109-MAPP-NA CCI-000140 MEDIUM 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). 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.
SV-46632r1_rule SRG-APP-000110-MAPP-NA CCI-000152 MEDIUM 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. 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.
SV-46633r1_rule SRG-APP-000111-MAPP-NA CCI-000154 MEDIUM Applications must provide the capability to centralize the review and analysis of audit records from multiple components within the system. 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.
SV-46635r1_rule SRG-APP-000112-MAPP-00026 CCI-001695 HIGH The mobile application code must not include embedded interpreters for prohibited mobile code. 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.
SV-46636r1_rule SRG-APP-000113-MAPP-NA CCI-000156 MEDIUM The application must provide an audit reduction capability. 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.
SV-46637r1_rule SRG-APP-000114-MAPP-NA CCI-000157 MEDIUM Applications must provide a report generation capability for audit reduction data. 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.
SV-46638r1_rule SRG-APP-000115-MAPP-NA CCI-000158 MEDIUM Applications must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria. 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.
SV-46639r1_rule SRG-APP-000116-MAPP-NA CCI-000159 MEDIUM Applications must use internal system clocks to generate time stamps for audit records. 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.
SV-46640r1_rule SRG-APP-000117-MAPP-00027 CCI-000160 LOW The mobile application must use the mobile devices system time for its authoritative time source. 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.
SV-46641r1_rule SRG-APP-000118-MAPP-NA CCI-000162 MEDIUM The application must protect audit information from any type of unauthorized access. 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.
SV-46643r1_rule SRG-APP-000119-MAPP-NA CCI-000163 MEDIUM The application must protect audit information from unauthorized modification. 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.
SV-46644r1_rule SRG-APP-000120-MAPP-NA CCI-000164 MEDIUM The application must protect audit information from unauthorized deletion. 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.
SV-46646r1_rule SRG-APP-000121-MAPP-NA CCI-001493 MEDIUM The application must protect audit tools from unauthorized access. 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.
SV-46647r1_rule SRG-APP-000122-MAPP-NA CCI-001494 MEDIUM The application must protect audit tools from unauthorized modification. 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.
SV-46650r1_rule SRG-APP-000123-MAPP-NA CCI-001495 MEDIUM The application must protect audit tools from unauthorized deletion. 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.
SV-46651r1_rule SRG-APP-000124-MAPP-NA CCI-000165 MEDIUM The application must have the capability to produce audit records on hardware-enforced, write-once media. 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.
SV-46652r1_rule SRG-APP-000125-MAPP-NA CCI-001348 MEDIUM 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. 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.
SV-46654r1_rule SRG-APP-000127-MAPP-NA CCI-001352 MEDIUM The application must protect the audit records generated as a result of remote accesses to privileged accounts and the execution of privileged functions. 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.
SV-46656r1_rule SRG-APP-000128-MAPP-00028 CCI-000345 MEDIUM The mobile application must not change the file permissions of any files other than those dedicated to its own operation. 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.
SV-46657r1_rule SRG-APP-000129-MAPP-00029 CCI-000346 MEDIUM The mobile application must implement automated mechanisms to enforce access control restrictions which are not provided by the operating system 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.
SV-46659r1_rule SRG-APP-000130-MAPP-NA CCI-000347 MEDIUM The application must support the employment of automated mechanisms supporting the auditing of enforcement actions. 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.
SV-46661r1_rule SRG-APP-000131-MAPP-NA CCI-000352 MEDIUM 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. 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.
SV-46662r1_rule SRG-APP-000132-MAPP-NA CCI-000354 MEDIUM The application must support the enforcement of a two-person rule for changes to organization-defined application components and system-level information. 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.
SV-46664r1_rule SRG-APP-000133-MAPP-00030 CCI-001499 MEDIUM The mobile application must not enable other applications or non-privileged processes to modify software libraries. 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.
SV-46665r1_rule SRG-APP-000134-MAPP-NA CCI-001500 MEDIUM Applications must automatically implement organization-defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately. 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.
SV-46666r1_rule SRG-APP-000135-MAPP-NA CCI-000370 MEDIUM Configuration management applications must employ automated mechanisms to centrally manage configuration settings. 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.
SV-46669r1_rule SRG-APP-000136-MAPP-NA CCI-000371 MEDIUM Configuration management applications must employ automated mechanisms to centrally apply configuration settings. 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.
SV-46670r1_rule SRG-APP-000137-MAPP-NA CCI-000372 MEDIUM Configuration management applications must employ automated mechanisms to centrally verify configuration settings. 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.
SV-46672r1_rule SRG-APP-000138-MAPP-NA CCI-000374 MEDIUM Configuration management applications must employ automated mechanisms to centrally respond to unauthorized changes to configuration settings. 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.
SV-46673r1_rule SRG-APP-000139-MAPP-NA CCI-001589 MEDIUM Configuration management solutions must track unauthorized, security-relevant configuration changes. 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.
SV-46675r1_rule SRG-APP-000140-MAPP-NA CCI-000066 MEDIUM The application must enforce requirements for remote connections to the information system. 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.
SV-46678r1_rule SRG-APP-000141-MAPP-00031 CCI-000381 MEDIUM The mobile application must not include source code never invoked during operation, except for software components and libraries from approved third-party products. 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.
SV-46679r1_rule SRG-APP-000142-MAPP-00032 CCI-000382 MEDIUM The mobile application must not utilize ports or protocols in a manner inconsistent with DoD Ports and Protocols guidance. 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.
SV-46681r1_rule SRG-APP-000143-MAPP-NA CCI-000386 MEDIUM 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. 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.
SV-46683r1_rule SRG-APP-000144-MAPP-00033 CCI-000553 MEDIUM The mobile application must implement transaction recovery if it is transaction based. 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.
SV-46684r1_rule SRG-APP-000145-MAPP-NA CCI-000535 MEDIUM Backup / Disaster Recovery oriented applications must be capable of backing up user-level information per a defined frequency. 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.
SV-46685r1_rule SRG-APP-000146-MAPP-00034 CCI-000537 LOW 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. 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).
SV-46686r1_rule SRG-APP-000147-MAPP-NA CCI-000539 MEDIUM 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. 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.
SV-46688r1_rule SRG-APP-000148-MAPP-NA CCI-000764 MEDIUM The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). 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.
SV-46689r1_rule SRG-APP-000149-MAPP-NA CCI-000765 MEDIUM The application must use multifactor authentication for network access to privileged accounts. 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.
SV-46692r1_rule SRG-APP-000150-MAPP-NA CCI-000766 MEDIUM The application must use multifactor authentication for network access to non-privileged accounts. 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.
SV-46694r1_rule SRG-APP-000151-MAPP-NA CCI-000767 MEDIUM The application must use multifactor authentication for local access to privileged accounts. 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.
SV-46695r1_rule SRG-APP-000152-MAPP-NA CCI-000768 MEDIUM The application must use multifactor authentication for local access to non-privileged accounts. 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.
SV-46697r1_rule SRG-APP-000153-MAPP-NA CCI-000770 MEDIUM Applications authenticating users must ensure users are authenticated with an individual authenticator prior to using a group authenticator. 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.
SV-46698r1_rule SRG-APP-000154-MAPP-NA CCI-000771 MEDIUM 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. 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.
SV-46699r1_rule SRG-APP-000155-MAPP-NA CCI-000772 MEDIUM 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. 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.
SV-46700r1_rule SRG-APP-000156-MAPP-NA CCI-000774 MEDIUM The application must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts. 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.
SV-46701r1_rule SRG-APP-000157-MAPP-NA CCI-000776 MEDIUM The application must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts. 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.
SV-46703r1_rule SRG-APP-000158-MAPP-NA CCI-000778 MEDIUM 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. 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.
SV-46704r1_rule SRG-APP-000159-MAPP-NA CCI-000779 MEDIUM Applications managing devices must authenticate devices before establishing remote network connections using bidirectional authentication between devices that are cryptographically based. 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.
SV-46705r1_rule SRG-APP-000160-MAPP-00035 CCI-000780 MEDIUM The mobile application must authenticate devices using bidirectional cryptographic authentication if it manages wireless network connections for other devices. 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.
SV-46742r1_rule SRG-APP-000161-MAPP-NA CCI-000781 MEDIUM Applications managing network connectivity must have the capability to authenticate devices before establishing network connections by using bidirectional authentication that is cryptographically based. 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.
SV-46744r1_rule SRG-APP-000162-MAPP-NA CCI-000802 MEDIUM Web services applications establishing identities at run-time for previously unknown entities must dynamically manage identifiers, attributes, and associated access authorizations. 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.
SV-46745r1_rule SRG-APP-000163-MAPP-NA CCI-000795 MEDIUM Applications must support organizational requirements to disable user accounts after an organization-defined time period of inactivity. 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.
SV-46746r1_rule SRG-APP-000164-MAPP-NA CCI-000205 MEDIUM The application must support organizational requirements to enforce minimum password length. 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.
SV-46747r1_rule SRG-APP-000165-MAPP-NA CCI-000200 MEDIUM The application must support organizational requirements to prohibit password reuse for the organization-defined number of generations. 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.
SV-46749r1_rule SRG-APP-000166-MAPP-NA CCI-000192 MEDIUM The application must support organizational requirements to enforce password complexity by the number of upper case characters used. 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
SV-46752r1_rule SRG-APP-000167-MAPP-NA CCI-000193 MEDIUM The application must support organizational requirements to enforce password complexity by the number of lower case characters used. 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.
SV-46753r1_rule SRG-APP-000168-MAPP-NA CCI-000194 MEDIUM The application must support organizational requirements to enforce password complexity by the number of numeric characters used. 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.
SV-46754r1_rule SRG-APP-000169-MAPP-NA CCI-001619 MEDIUM The application must support organizational requirements to enforce password complexity by the number of special characters used. 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.
SV-46755r1_rule SRG-APP-000170-MAPP-NA CCI-000195 MEDIUM The application must support organizational requirements to enforce the number of characters that get changed when passwords are changed. 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.
SV-46756r1_rule SRG-APP-000171-MAPP-NA CCI-000196 MEDIUM The application must support organizational requirements to enforce password encryption for storage. 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
SV-46757r1_rule SRG-APP-000172-MAPP-NA CCI-000197 MEDIUM The application must support organizational requirements to enforce password encryption for transmission. 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.
SV-46758r1_rule SRG-APP-000173-MAPP-NA CCI-000198 MEDIUM Applications must enforce password minimum lifetime restrictions. 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.
SV-46759r1_rule SRG-APP-000174-MAPP-NA CCI-000199 MEDIUM Applications must enforce password maximum lifetime restrictions. 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.
SV-46760r1_rule SRG-APP-000175-MAPP-NA CCI-000185 MEDIUM The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor. 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.
SV-46761r1_rule SRG-APP-000176-MAPP-NA CCI-000186 MEDIUM The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key. 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.
SV-46762r1_rule SRG-APP-000177-MAPP-NA CCI-000187 MEDIUM Applications must ensure that PKI-based authentication maps the authenticated identity to the user account. 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.
SV-46791r1_rule SRG-APP-000178-MAPP-NA CCI-000206 MEDIUM The application must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. 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.
SV-46792r1_rule SRG-APP-000179-MAPP-NA CCI-000803 MEDIUM 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. 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.
SV-46793r1_rule SRG-APP-000180-MAPP-NA CCI-000804 MEDIUM The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). 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.
SV-46794r1_rule SRG-APP-000181-MAPP-NA CCI-000831 MEDIUM 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. When responding to a security incident a capability must exist allowing authorized personnel to disable a particular system if the system exhibits a security violation and the organization determines an action is warranted. Organizations shall define a list of security violations that warrant an immediate disabling of a system. Rationale for non-applicability: The MDM SRG covers the ability to disable a mobile device in the event of a security incident.
SV-46795r1_rule SRG-APP-000182-MAPP-NA CCI-000833 MEDIUM Applications related to incident tracking must support organizational requirements to employ automated mechanisms to assist in the tracking of security incidents. Incident tracking is a method of monitoring networks and systems for activity indicative of viral infection or system attack. Monitoring for this type of activity provides the organization with the capability to proactively detect and respond to attacks. Automated mechanisms for tracking security incidents and collecting/analyzing incident information include, the Einstein network monitoring device and monitoring online Computer Incident Response Centers (CIRCs) or other electronic databases of incidents. Rationale for non-applicability: The MDM SRG covers the centralized management of audit logs and alerts, which is closely integrated with tracking of security incidents.
SV-46796r1_rule SRG-APP-000183-MAPP-NA CCI-000884 MEDIUM Applications used for non-local maintenance sessions must protect those sessions through the use of a strong authenticator tightly bound to the user. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Identification and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions must be consistent with the network access requirements in IA-2. Strong authenticators include, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Examples of types of applications used for non-local maintenance and diagnostic activities are provided below. Use as an example does not imply compliance with policy requirements or approval for use. Examples include but are not limited to: - Terminal Services - Remote Desktop - Dameware - VNC (all variants). Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46797r1_rule SRG-APP-000184-MAPP-NA CCI-000888 MEDIUM The application must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information, and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46798r1_rule SRG-APP-000185-MAPP-NA CCI-000877 MEDIUM The application must employ strong identification and authentication techniques when establishing non-local maintenance and diagnostic sessions Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46799r1_rule SRG-APP-000186-MAPP-NA CCI-000879 MEDIUM The application must terminate all sessions and network connections when non-local maintenance is completed. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46800r1_rule SRG-APP-000187-MAPP-NA CCI-001009 MEDIUM Applications employed to write data to portable digital media must use cryptographic mechanisms to protect and restrict access to information on portable digital media. When data is written to portable digital media such as thumb drives, floppy diskettes, compact disks, magnetic tape etc, there is risk of data loss. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. When the organization has determined the risk warrants it, data written to portable digital media must be encrypted. Rationale for non-applicability: The MOS SRG requires this control. More specifically, it requires that the operating system cryptographically bind the removable media to the mobile device so data stored on the media card can only be read by that mobile device. In this context, further application controls would be redundant and could cause conflicts resulting in denial of service.
SV-46801r1_rule SRG-APP-000188-MAPP-NA CCI-001019 MEDIUM Applications must support organizational requirements to employ cryptographic mechanisms to protect information in storage. When data is written to digital media such as, hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and data compromise. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. Rationale for non applicability: Per the MOS SRG, the MOS must implement FIPS 140-2 validated cryptographic modules for protection of data. To the extent the mobile application uses cryptography not offered by the MOS, FIPS requirements are covered under SRG-APP-000196.
SV-46802r1_rule SRG-APP-000189-MAPP-NA CCI-001069 MEDIUM Application software used to detect the presence of unauthorized software must employ automated detection mechanisms and notify designated organizational officials in accordance with the organization-defined frequency. Scanning software is purpose built to check for vulnerabilities in the information system and hosted applications and is also used to enumerate platforms, software flaws, and improper configurations. Organizations are required to scan for vulnerabilities in information systems and hosted applications on an organization defined frequency and/or randomly in accordance with an organization defined process. Scanning software includes the capability to scan for specific functions, applications, ports, protocols, and services that should not be accessible to users or devices and for improperly configured or incorrectly operating information flow mechanisms. Rationale for non-applicability: The MDM SRG covers applications used to detect the presence of unauthorized software.
SV-46803r1_rule SRG-APP-000190-MAPP-00037 CCI-001133 LOW The mobile application must close opened network ports at the end of the application session or after an organization defined time period of inactivity. Ports that are not closed upon termination of an application or following a pre-defined period of inactivity leave the device vulnerable to exposure from attacks that exploit ports that remain open. As an example, wireless ports, such as Wi-Fi and Bluetooth, are both vulnerable to an adversary in a war driving scenario. In this event, the unauthorized user has the potential to access the device, compromising the security posture of the stored data. Applying this control assures that threat from malicious exploitation of open and unprotected ports that can lead to data integrity and confidentiality risks are mitigated.
SV-46804r1_rule SRG-APP-000191-MAPP-NA CCI-001135 MEDIUM The application must establish a trusted communications path between the user and organization-defined security functions within the information system. The application user interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. A trusted path shall be employed for high-confidence connections between the security functions of the information system and the user (e.g., for login). Rationale for non-applicability: This control is required in the MOS SRG. The operating system provides the only means to establish trusted communications paths internal to a mobile device because the operating system can always act as a man-in-the-middle to any application control.
SV-46805r1_rule SRG-APP-000192-MAPP-00038 CCI-001140 MEDIUM Mobile applications involved in the production, control, and distribution of symmetric cryptographic keys must use NIST approved or NSA approved key management technology and processes. Symmetric cryptographic keys must be managed according to approved processes using approved technology, to ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. If non-standard practices are applied to production, control, and distribution of symmetric cryptographic keys, then the DoD is potentially vulnerable to attack from adversaries who are able to exploit weak encryption keys that have been used by the application and system. This control assures DoD a much higher degree of assurance that intruders will not gain access to the network through weaknesses that are mitigated or eradicated through best and approved practices and key management technologies.
SV-46806r1_rule SRG-APP-000193-MAPP-00038 CCI-001141 MEDIUM Mobile applications involved in the production, control, and distribution of asymmetric cryptographic keys must use NIST approved or NSA approved key management technology and processes. Asymmetric cryptographic keys must be managed according to approved processes using approved technology, to ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. If non-standard practices are applied to production, control, and distribution of asymmetric cryptographic keys, then the DoD is potentially vulnerable to attack from adversaries who are able to exploit weak encryption keys that have been used by the application and system. In applying this control, the DoD can be assured of a much higher degree of assurance that intruders will not gain access to the network through weaknesses that are mitigated or eradicated through best and approved practices and key management technologies.
SV-46807r1_rule SRG-APP-000194-MAPP-00040 CCI-001142 MEDIUM Mobile applications involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 certificates or prepositioned keying material. Class 3 certificates are issued to individuals, organizations, servers, devices, and administrators for CAs and root authorities (RAs). Class 3 certificates undergo independent verification and checking of identity and authority which is performed by the issuing (CA). Networks and applications not using Class 3 Certificates are vulnerable to a multiple of malicious attacks that would essentially allow unauthorized access to and intrusion in a network. Similarly, using approved PKI class 3 certificates ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. In applying this control, the use of approved PKI Class 3 certificates will assure authentication, message, data and content integrity, and confidentiality encryption.
SV-46808r1_rule SRG-APP-000195-MAPP-00041 CCI-001143 MEDIUM Mobile applications involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 or class 4 certificates and hardware tokens that protect the users private key. Class 3 and 4 certificates are issued by individuals, organizations, servers, devices, and administrators for CAs and root authorities (RAs). A hardware token offers an additional layer of security in addition to a password. Networks and applications not using hardware tokens to protect the private Class 3 certificates are vulnerable to a multiple of malicious attacks that would essentially allow unauthorized access and intrusion in a network. Networks and applications not using Class 3 and 4 certificates and hardware tokens are vulnerable to a multiple of malicious attacks that would essentially allow unauthorized access to and intrusion in a network. Similarly, using approved PKI class 3/4 certificates and hardware tokens, ensure malicious intruders do not take advantage of any network resource exposure that may occur as a result of non-standard practices and tools being applied. Users of Class 3/4 certificates, as well as hardware tokens, will be assured of an extra level of security that will protect their certificates and the user's private key. DoD CAC is an example of a compliant solution.
SV-46809r1_rule SRG-APP-000196-MAPP-00042 CCI-001144 MEDIUM The mobile application must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Cryptographic protection assures all data at rest and in transit is protected from malicious intruders. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. The control assures the DoD that the data's integrity and privacy is maintained through use of a set of approved and proven cryptographic modules.
SV-46810r1_rule SRG-APP-000197-MAPP-NA CCI-001145 MEDIUM Applications must employ FIPS-validated cryptography to protect unclassified information. Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. Rationale for non-applicability: Per the MOS SRG, the MOS must implement FIPS 140-2 validated cryptographic modules for protection of data. To the extent the mobile application uses cryptography not offered by the MOS, FIPS requirements are covered under SRG-APP-000196.
SV-46811r1_rule SRG-APP-000198-MAPP-00043 CCI-001146 HIGH The mobile application must employ NSA-approved cryptography to protect classified information. Unclassified information is also at risk to exposure if no encryption is used, or if a non-NSA validated cryptography module is not used. NSA-compliant cryptography must be applied; unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. Additionally, it must be known that FIPS 140-2 validated encryption is not suitable for classified information. In applying this control, integrity and privacy of unclassified information is maintained. Organizations should contact their NSA liaison to determine what the available options are for cryptographic support.
SV-46812r1_rule SRG-APP-000199-MAPP-NA CCI-001147 MEDIUM Applications must employ FIPS-validated cryptography to protect unclassified information when such information must be separated from individuals who have the necessary clearances yet lack the necessary access approvals. Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data. FIPS 140-2 Security Requirements for Cryptographic Modules can be found at the following web site: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf. Although persons may have a security clearance, they may not have a "need to know" and are required to be separated from the information in question. Applications must employ FIPS validated cryptography to protect unclassified information from those individuals who have no "need to know". Rationale for non-applicability: This SRG applies to single-user applications. Therefore there is no need to separate data from other individuals.
SV-46813r1_rule SRG-APP-000200-MAPP-00044 CCI-001674 MEDIUM The mobile application must shut down or take an alternative organization defined action when it determines that one of its required security functions is unavailable. While mobile applications primarily rely on MOS security controls, a mobile application may contain security functions that enable the device and user to operate in a secure manner. For example, the mobile application may operate its own cryptographic modules for data at rest and data in transit. In the event a security function that would normally encrypt data at rest, data in motion or perform some other form of security measure is not present, then all data, the device and network are at risk to exposure and intrusion from a malicious, unauthorized user. This measure mitigates DoD risk and exposure from being compromised due to the security posture of the device being weakened as a result of failed or disabled security modules. When the application shuts down it must cease running and not just deny services to a user. Other organization defined response actions might include writing an entry to the audit log, notifying the user, or limiting access to particular application features, such as the ability to export data.
SV-46814r1_rule SRG-APP-000201-MAPP-NA CCI-001149 MEDIUM The application must protect the integrity and availability of publicly available information and applications. The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG. The mobile application does not serve publically available information to other users and therefore is not concerned with the integrity of publically available information.
SV-46815r1_rule SRG-APP-000202-MAPP-NA CCI-001150 MEDIUM Software and/or firmware used for collaborative computing devices must prohibit remote activation excluding the organization-defined exceptions where remote activation is to be allowed. Collaborative computing devices include, networked white boards, cameras, and microphones. Collaborative software examples include instant messaging or chat clients. Rationale for non-applicability: Remote activation requires the application to provide some form of server functionality even if only to listen for remote activation calls. Server applications are expressly excluded from the scope of this SRG. If the remote activation is achieved locally through an operating system command, then this control must be implemented by the operating system. In this case, the application has no reliable mechanism to detect that the activation is remote.
SV-46817r1_rule SRG-APP-000203-MAPP-00045 CCI-001157 MEDIUM The mobile application must associate security attributes with information exchanged between information systems. When data is exchanged between information systems, security attributes must be associated with this data. Security attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system, and used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy. Applying this control assures security attributes may be explicitly or implicitly associated with the information contained within the information system to support correct handling of the data according to its classification.
SV-46818r1_rule SRG-APP-000204-MAPP-00046 CCI-001158 HIGH The mobile application must provide integrity protection for the classification attributes bound to the transmitted data if it transmits classified data. Data classification attributes include the level of classification (e.g., Secret, Top Secret) and additional handling or program parameters if they exist. Data classification attributes are used to ensure classified data is properly handled when transmitted and correctly distributed and stored upon receipt. If integrity checks are not used to detect errors or manipulative action by intruders to data streams, there is no way to ensure the integrity of the application data as it traverses the network. This means the data classification attribute is also subject to manipulative action which could lead to incorrect handling and distribution upon receipt. This control assures the integrity of the transmitted data's classification attributes have been secured which will further mitigate any risks associated with further handling of the data.
SV-46823r1_rule SRG-APP-000205-MAPP-NA CCI-001159 MEDIUM Applications must support organizational requirements to issue public key certificates under an appropriate certificate policy or obtain public key certificates under an appropriate certificate policy from an approved service provider. For user certificates, each organization attains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice. This control focuses on certificates with a visibility external to the information system and does not include certificates related to internal system operations, for example, application-specific time services. Rationale for non-applicability: The issuance of public key certificates is a server function. Server applications are outside the scope of this SRG.
SV-46825r1_rule SRG-APP-000206-MAPP-NA CCI-001166 MEDIUM Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must implement detection and inspection mechanisms to identify unauthorized mobile code Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Policy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. Rationale for non-applicability: The MDM SRG addresses malware issues.
SV-46828r1_rule SRG-APP-000207-MAPP-NA CCI-001662 MEDIUM Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must take corrective actions, when unauthorized mobile code is identified. Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Policy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. Rationale for non-applicability: The MDM SRG addresses malware issues.
SV-46830r1_rule SRG-APP-000208-MAPP-NA CCI-001167 MEDIUM Applications utilizing mobile code must meet policy requirements regarding the acquisition, development, and/or use of mobile code. Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers, and mobile code downloaded and executed on individual workstations. DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. Rationale for non-applicability: SRG-APP-000208 is redundant with SRG-APP-000074. All applicable mobile code requirements are associated with SRG-APP-000074 rather than repeated here.
SV-46832r1_rule SRG-APP-000209-MAPP-NA CCI-001169 MEDIUM Applications designed to enforce policy pertaining to organizational use of mobile code must prevent the download and execution of prohibited mobile code. Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Rationale for non-applicability: The MOS SRG requires application sandboxing, which is core security architecture common to most commercial mobile OSs. In this environment, an application cannot enforce the behavior or actions of another application. Only the OS can effectively enforce mobile code requirements throughout the device. If an application were ever granted the privileges to perform such a function on a mobile device, the application would pose a significant IA risk to device integrity.
SV-46834r1_rule SRG-APP-000210-MAPP-NA CCI-001170 MEDIUM Applications designed to enforce policy pertaining to the use of mobile code must prevent the automatic execution of mobile code in organization-defined software applications and require organization-defined actions prior to executing the code. Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Organization-defined software may be a specific application, web site or web sites in general. Organization-defined actions include but are not limited to: alerts to the user, logging actions, a centralized alarm, or any combination thereof. Rationale for non-applicability: The MOS SRG requires application sandboxing, which is core security architecture common to most commercial mobile OSs. In this environment, an application cannot enforce the behavior or actions of another application. Only the OS can effectively enforce mobile code requirements throughout the device. If an application were ever granted the privileges to perform such a function on a mobile device, the application would pose a significant IA risk to device integrity.
SV-46835r1_rule SRG-APP-000211-MAPP-NA CCI-001082 MEDIUM The application must separate user functionality (including user interface services) from information system management functionality. Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. Rationale for non-applicability: The MDM SRG covers mobile applications that have information system management functionality. Mobile operating systems typically do not permit applications to perform information system management.
SV-46837r1_rule SRG-APP-000212-MAPP-NA CCI-001083 MEDIUM The application must prevent the presentation of information system management-related functionality at an interface utilized by general (i.e., non-privileged) users. Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. Rationale for non-applicability: The MDM SRG covers mobile applications that have information system management functionality. Mobile operating systems typically do not permit non-MDM applications to perform information system management.
SV-46838r1_rule SRG-APP-000213-MAPP-NA CCI-001178 MEDIUM The application must provide additional data origin and integrity artifacts along with the authoritative data the system returns in response to name/address resolution queries. This control enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. The DNS security controls are consistent with, and referenced from, OMB Memorandum 08-23. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
SV-46840r1_rule SRG-APP-000215-MAPP-NA CCI-001663 MEDIUM The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems. A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
SV-46842r1_rule SRG-APP-000216-MAPP-NA CCI-001180 MEDIUM The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems. A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
SV-46844r1_rule SRG-APP-000217-MAPP-NA CCI-001181 MEDIUM The application must perform data origin authentication and data integrity verification on all resolution responses received whether or not local client systems explicitly request this service. A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources owning DNS data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
SV-46845r1_rule SRG-APP-000218-MAPP-NA CCI-001183 MEDIUM Applications that collectively provide name/address resolution service for an organization must implement internal/external role separation. A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least two authoritative domain name system DNS servers, one configured as primary and the other as secondary. Additionally, the two servers are commonly located in two different network subnets and geographically separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an internal role, only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address ranges, explicit lists). Rationale for non-applicability: The mobile operating system is responsible for name/address resolution services. If a mobile application were granted the OS privileges necessary to provide name services to other applications, this would enable the name service application to launch a number of IA attacks against other applications.
SV-46847r1_rule SRG-APP-000219-MAPP-NA CCI-001184 MEDIUM Application must ensure authentication of both client and server during the entire session. An example of this is SSL Mutual Authentication. This control focuses on communications protection at the session, versus packet, level. At the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity. Proper use of session IDs addressed man-in-the-middle attacks including session hijacking or insertion of false information into a session. This control is only implemented where deemed necessary by the organization (e.g., sessions in service-oriented architectures providing web-based services). Rationale for non-applicability: The scope of the MAPP SRG concerns applications local to the mobile device. The SRG does not impose any requirements for local authentication. If the mobile application connects to a remote enterprise application, the remote application will enforce its authentication requirements. The mobile application can leverage SSL/TLS functionality of the operating system when required.
SV-46848r1_rule SRG-APP-000220-MAPP-NA CCI-001185 MEDIUM Applications must terminate user sessions upon user logout or any other organization or policy defined session termination events, such as idle time limit exceeded. This requirement focuses on communications protection at the application session, versus network packet level. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session so as to minimize the potential for an attacker to hijack that particular user session. Rationale for non-applicability: The MAPP SRG expressly excludes a requirement for user authentication because user authentication is already addressed in the MOS SRG. The MOS SRG also covers requirements related to lockout resulting from exceeding idle time limits. As a consequence of having no requirement to logon, there is no requirement to logout.
SV-46850r1_rule SRG-APP-000221-MAPP-NA CCI-001186 MEDIUM Applications providing a login capability must also provide a logout functionality to allow the user to manually terminate the session. An application that will not allow the user the ability to log out will leave the application and all stored data vulnerable to unauthorized access in the event an adversary is able to unlock the device and re-launch the application or continue the prior session. If a user cannot log out of a mobile application, an adversary could continue to use the previous user's session, access the stored data with malicious intent, and compromise the integrity and confidentiality of the data. This control provides the DoD greater assurance that the device and all stored data is less vulnerable to malicious action in the event a device is stolen or found. Rationale for non-applicability: The MAPP SRG does not require user authentication. Since there is no requirement for a login capability, there similarly is no requirement to provide a logout capability.
SV-46852r1_rule SRG-APP-000222-MAPP-NA CCI-001187 MEDIUM Applications must generate a unique session identifier for each session. This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. Rationale for non-applicability: Session identifiers are relevant for multi-user applications, typically involving network communication. The MAPP SRG covers single-user applications only. Even in the rare case in which a single user may have several sessions within the context of a single-user application, there is no risk of external breach of any of these sessions because they are all accessed locally. If a remote application to which the mobile application connects employs session identifiers, it is the responsibility of the remote application to enforce randomness requirements.
SV-46853r1_rule SRG-APP-000223-MAPP-NA CCI-001664 MEDIUM Applications must recognize only system-generated session identifiers. This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions Rationale for non-applicability: The scope of the MAPP SRG is limited to the mobile application and does not extend to components of the Information Server such as the remote server.
SV-46855r1_rule SRG-APP-000224-MAPP-NA CCI-001188 MEDIUM Applications must generate unique session identifiers with organization defined randomness requirements. This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. Organizations can define the randomness of unique session identifiers when deemed necessary (e.g., sessions in service-oriented architectures providing web-based services). Rationale for non-applicability: Session identifiers are relevant for multi-user applications, typically involving network communication. The MAPP SRG covers single-user applications only. Even in the rare case in which a single user may have several sessions within the context of a single-user application, there is no risk of external breach of any of these sessions because they are all accessed locally. If a remote application to which the mobile application connects employs session identifiers, it is the responsibility of the remote application to enforce randomness requirements.
SV-46857r1_rule SRG-APP-000225-MAPP-00047 CCI-001190 MEDIUM The mobile application must fail to an initial state when the application unexpectedly terminates, unless it maintains a secure state at all times. An application maintains a secure state when there is strong assurance that each of its state transitions is consistent with the application's security policy. For many mobile applications, the only state for which the state is known to be compliant is the initial state because it does not have a documented security policy regarding state transitions. An application could be compromised, providing an attack vector to the application and OS if initialization, shutdown, and aborts are not designed to keep the application in a secure state. If the application fails without closing or shutting down processes or open sessions; authentication and validation mechanisms are considered weak and do not provide sufficient protection against unauthorized access to the application and all stored data. In applying this control, the application can be secured to its initial level of security in the event the application crashes or terminates. This will mitigate the threat of an unauthorized user taking control of the device and accessing the application and stored data, compromising its integrity and confidentiality.
SV-46860r1_rule SRG-APP-000226-MAPP-00048 CCI-001665 LOW The mobile application must preserve organization-defined system state information in the event of an application failure. Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.
SV-46861r1_rule SRG-APP-000227-MAPP-NA CCI-000086 MEDIUM Applications must enforce requirements regarding the connection of mobile devices to organizational information systems. Applications designed to manage the connection of mobile devices to information systems must be able to enforce organizational connectivity requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). Organizational connectivity requirements may include usage restrictions and implementation guidance related to mobile devices. For example, the organization may require the device be part of the configuration management environment or may require mandatory protective software be installed prior to connecting to the infrastructure (e.g., malicious code detection or a firewall). Scanning devices for malicious code may be required prior to connecting, as well as updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). An example of information system functionality that may need to be disabled prior to connecting includes the capability for automatic execution of code, such as AutoRun and AutoPlay. Rationale for non-applicability: Requirements related to connections to remote organization information systems must be enforced by the remote information system and not the mobile application. If this control were enforced on mobile device instead of the remote organizational information system, it would make that system more rather than less vulnerable.
SV-46866r1_rule SRG-APP-000228-MAPP-NA CCI-000417 MEDIUM The application must disable network access by unauthorized components/devices or notify designated organizational officials. Maintaining system and network integrity requires all systems on the network are identified and accounted for. Without an accurate accounting of systems utilizing the network, the opportunity exists for the introduction of rogue systems. The significance of this manner of security compromise increases exponentially over time and could become a persistent threat. Therefore, organizations must employ automated mechanisms to detect the addition unauthorized devices. Information deemed to be necessary by the organization to achieve effective property accountability can include, for example, hardware inventory specifications (manufacturer, type, model, serial number, physical location), software license information, information system/component owner, and for a networked component/device, the machine name and network address. The monitoring for unauthorized components/devices on information system networks may be accomplished on an ongoing basis or by the periodic scanning of organizational networks for that purpose. Automated mechanisms can be implemented within the information system and/or in another separate information system or device. Applications that are designed as systems configuration management solutions or other solutions developed specifically to fill the role of identifying or managing systems in the enterprise must be able to either disable the identified device or notify the appropriate personnel when new systems have been introduced into the environment. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46868r1_rule SRG-APP-000229-MAPP-NA CCI-001196 MEDIUM Only a Honey Pot information system and/or application must include components that proactively seek to identify web-based malicious code. Honey Pot systems must be not be shared or used for any other purpose other than described. A Honey Pot is an organization designated information system and/or application that includes components specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting, and analyzing such attacks. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46870r1_rule SRG-APP-000230-MAPP-NA CCI-001132 MEDIUM Applications must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission. When transmitting data, applications need to leverage transmission protection mechanisms such as TLS, SSL VPN, or IPSEC tunnel. Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. Alternative physical protection measures include, protected distribution systems. Protective Distribution Systems (PDS) are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS. Rationale for non-applicability: This functionality is provided by the mobile operating system through numerous controls, including user authentication, application sandboxing, and encryption of data at rest and in transit. The mobile application must necessarily reveal data to the user of the application. Therefore, the application cannot maintain strict confidentiality during many packaging transactions.
SV-46872r1_rule SRG-APP-000231-MAPP-NA CCI-001199 MEDIUM Applications must take needed steps to protect data at rest and ensure confidentiality and integrity of application data. This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. User data generated, as well as, application specific configuration data needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. Rationale for non-applicability: This functionality is provided by the operating system, which is required to encrypt all data at rest using FIPS 140-2 validated cryptographic modules.
SV-46874r1_rule SRG-APP-000232-MAPP-NA CCI-001200 MEDIUM Applications handling data requiring data at rest protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information that is at rest unless otherwise protected by alternative physical measures. This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Alternative physical protection measures include, protected distribution systems. Rationale for non-applicability: This functionality is provided by the operating system, which is required to encrypt all data at rest using FIPS 140-2 validated cryptographic modules.
SV-46876r1_rule SRG-APP-000233-MAPP-NA CCI-001084 MEDIUM Applications must isolate security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. Security functions are defined as "the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based". Developers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles. Rationale for non-applicability: It is assumed that mobile applications leverage the security functions of the operating system and that the operating system provides the requisite isolation of security functions from other functions. If an application embeds additional security functionality, those security functions are protected from other applications via applications sandboxing. When the mobile application connects to remote enterprise application resources, the remote resources perform the required isolation.
SV-46878r1_rule SRG-APP-000234-MAPP-NA CCI-001682 MEDIUM The application must automatically terminate emergency accounts after an organization defined time period for each type of account. Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. In the event emergency application accounts are required, the application must ensure that accounts that are designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. The application must provide or utilize a mechanism to automatically terminate accounts that have been designated as temporary or emergency accounts after an organization defined time period. Rationale for non-applicability: This SRG applies to single-user applications. There is no possibility of emergency accounts in these applications.
SV-46879r1_rule SRG-APP-000235-MAPP-NA CCI-001086 MEDIUM Applications must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions. Application functionality is typically broken down into modules that perform various tasks or roles. Examples of non-privileged application functionality include, but are not limited to, application modules written for displaying data or printing reports. Application security functionality that performs security tasks such as enforcing access and information flow control requires additional system privilege and can have a large impact on the security of the application and its data. Rather than allowing the entire application access to this security functionality, application developers must isolate these critical functions from non-privileged application functions and other security functions. Rationale for non-applicability: It is assumed that mobile applications leverage the security functions of the operating system and that the operating system provides the requisite isolation of security functions from other functions. If an application embeds additional security functionality, those security functions are protected from other applications via applications sandboxing. When the mobile application connects to remote enterprise application resources, the remote resources perform the required isolation.
SV-46881r1_rule SRG-APP-000236-MAPP-NA CCI-001087 MEDIUM Applications must meet organizational requirements to implement an information system isolation boundary that minimizes the number of non-security functions included within the boundary containing security functions. The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process. Rationale for non-applicability: It is assumed that mobile applications leverage the security functions of the operating system and that the operating system provides the requisite isolation of security functions from other functions. If an application embeds additional security functionality, those security functions are protected from other applications via applications sandboxing. When the mobile application connects to remote enterprise application resources, the remote resources perform the required isolation.
SV-46884r1_rule SRG-APP-000237-MAPP-NA CCI-001274 MEDIUM The application must employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications. Applications will typically utilize logging mechanisms for maintaining a historical log of activity that occurs within the application. This information can then be used for diagnostic purposes, forensics purposes or other purposes relevant to ensuring the availability and integrity of the application. While it is important to log events identified as being critical and relevant to security, it is equally important to notify the appropriate personnel in a timely manner so they are able to respond to events as they occur. Solutions that include a manual notification procedure do not offer the reliability and speed of an automated notification solution. Applications must employ automated mechanisms to alert security personnel of inappropriate or unusual activities that have security implications. If this capability is not built directly into the application, the application must be able to integrate with existing security infrastructure that provides this capability. Rationale for non-applicability: Mobile applications should leverage the audit and alert functionality of the operating system and MDM. Stove-piped alert systems for particular mobile applications are likely to inhibit rather than facilitate proper incident response. If the mobile application connects to a remote enterprise resource, the enterprise application managing access to that resource would implement an appropriate alert mechanism.
SV-46916r1_rule SRG-APP-000238-MAPP-NA CCI-001089 MEDIUM Applications must meet organizational requirements to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process. Rationale for non-applicability: The mobile application exists at the highest security layer of the mobile device architecture. Therefore, it cannot depend on the functionality or correctness of higher layers.
SV-46918r1_rule SRG-APP-000239-MAPP-NA CCI-001209 MEDIUM The application must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission. Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the application take steps to validate and assure the integrity of data while at these stages of processing. For example, an application developer may determine based upon application requirements that various application data must accumulate in a processing queue where the application analyses, packages or transforms the data pending a data transfer. A window of time now exists where if an attacker were to gain access to the data residing in the application queue they could potentially compromise that data or alter results. The application must ensure the integrity of data that is pending transfer is maintained. If the application were to simply transmit aggregated, packaged or transformed data without ensuring the data was not manipulated during these processes, then the integrity of the data may be called into question. Rationale for non-applicability: Transformation of data inherently affects the integrity of the data inputs. Several operating system controls, including application sandboxing and white listing of applications, greatly mitigates the risk that any processes will be able to modify data in an unauthorized manner.
SV-46922r1_rule SRG-APP-000240-MAPP-NA CCI-001214 MEDIUM Applications required to be non-modifiable must support organizational requirements to provide components that contain no writeable storage capability. These components must be persistent across restart and/or power on/off. Organizations may require applications or application components to be non-modifiable or to be stored and executed on non-writeable storage. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion. Rationale for non-applicability: This control conflicts with a core requirement that mobile applications be modifiable. The primary means for updating the configuration of mobile applications is to replace the entire application.
SV-46925r1_rule SRG-APP-000241-MAPP-NA CCI-001210 MEDIUM Applications must, for organization-defined information system components, load and execute the operating environment from hardware-enforced, read-only media. Organizations may require the information system to load the operating environment from hardware enforced read-only media. The term operating environment is defined as the code upon which applications are hosted, for example, a monitor, executive, operating system, or application running directly on the hardware platform. Hardware-enforced, read-only media include, CD-R/DVD-R disk drives. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Rationale for non-applicability: Given the small form factor of mobile devices and the necessity to minimize the size and number of components, mobile devices are not expected to support read-only media for any application. Even in cases in which this requirement was enforced, it would be as a result of a policy requirement on specialized hardware. There is no technical means for an application to enforce this control as it has no control over the hardware on which it resides.
SV-46927r1_rule SRG-APP-000242-MAPP-NA CCI-001211 MEDIUM Applications must support organizationally-defined requirements to load and execute from hardware-enforced, read-only media. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Organizations may require the information system to load specified applications from hardware enforced read-only media. Hardware-enforced, read-only media include, CD-R/DVD-R disk drives. Rationale for non-applicability: Given the small form factor of mobile devices and the necessity to minimize the size and number of components, mobile devices are not expected to support read-only media for any application. Even in cases in which this requirement was enforced, it would be as a result of a policy requirement on specialized hardware. There is no technical means for an application to enforce this control as it has no control over the hardware on which it resides.
SV-46929r1_rule SRG-APP-000243-MAPP-00049 CCI-001090 MEDIUM The mobile application must not write data to persistent memory accessible to other applications. Persistent memory is memory that retains data even when the device is no longer powered on. It is often referred to as non-volatile memory and is typically used for file storage. If the application shares the same location of persistent memory with that used by other applications to include encrypted data, then the data is at great risk to exposure through being available to other applications after the application has shut down or a user session has terminated. Furthermore, even though the OS will always be able to read files, other applications that share the same persistent memory are potentially less secure and thus offer an accessible means for malicious intruders to retrieve this information through the other application. In many operating environments, assigning unique process IDs to each application facilitates their separation from one another. In applying this control, the user will be less susceptible to malicious intrusion and extrusion of data that resides in areas shared by other applications.
SV-46931r1_rule SRG-APP-000244-MAPP-NA CCI-001091 MEDIUM Applications must not share resources used to interface with systems operating at different security levels. The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Shared resources include memory, input/output queues, and network interface cards. Rationale for non-applicability: Mobile applications that interface with system operating at different security levels are outside the scope of the MAPP SRG.
SV-46933r1_rule SRG-APP-000245-MAPP-NA CCI-001092 MEDIUM Applications must protect against or limit the effects of the organization-defined or referenced types of Denial of Service (DoS) attacks. A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization's internal network from being directly affected by DoS attacks. Employing increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks. Rationale for non-applicability: Mobile applications are lightweight and are not expected to have embedded mechanisms to protect against DoS, most of which cannot be known prior to the exploited vulnerability. The mobile operating system has a variety of mechanisms, including application sandboxing and memory management, to protect against application-based DoS attacks.
SV-46935r1_rule SRG-APP-000246-MAPP-NA CCI-001094 MEDIUM Applications must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks. When it comes to DoS attacks most of the attention is paid to ensuring that systems and applications are not victims of these attacks. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by denial of service attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. Applications and application developers must take the steps needed to ensure that users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so that users are not able to generate unlimited network traffic via the application. The methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it. Rationale for non-applicability: Mobile applications are lightweight and are not expected to have embedded mechanisms to restrict users to launch DoS attacks. An MDM can disable devices that are determined to be the source of DoS attacks.
SV-46937r1_rule SRG-APP-000247-MAPP-NA CCI-001095 MEDIUM Applications must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks. In the case of application DoS attacks, care must be taken when designing the application so as to ensure that the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. The methods employed to meet this requirement will vary depending upon the technology the application utilizes. However, a variety of technologies exist to limit, or in some cases, eliminate the effects of application related DoS attacks. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS attacks. Rationale for non-applicability: This requirement is most appropriately targeted at server-based applications that can manage capacity or redundancy. Mobile applications are single-user applications that have very limited ability to either perform a DoS to other devices or to appreciably change the level of resources they employ.
SV-46938r1_rule SRG-APP-000248-MAPP-NA CCI-001096 MEDIUM Applications must limit the use of resources by priority and not impede the host from servicing processes designated as a higher-priority. Priority protection helps prevent a lower-priority process from delaying or interfering with the information system servicing any higher-priority process. This control does not apply to components in the information system for which there is only a single user/role. The application must limit the use of resources by priority. Rationale for non-applicability: Prioritization of access to device resources is a core operating system function. The operating system, and not the application, must set priorities. If a mobile application were granted the authority to affect resource prioritization, this would be a significant vulnerability to other processes running on the device.
SV-46940r1_rule SRG-APP-000249-MAPP-NA CCI-001117 MEDIUM Applications functioning in the capacity of a firewall must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination. In regards to boundary controls such as routers and firewalls, examples of restricting and prohibiting communications are: restricting external web traffic only to organizational web servers within managed interfaces and prohibiting external traffic that appears to be spoofing an internal address as the source. Rationale for non-applicability: The mobile operating system provides firewall functionality on mobile devices. The requirement for application sandboxing precludes applications from checking the inbound and outbound traffic of other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
SV-46942r1_rule SRG-APP-000250-MAPP-NA CCI-001118 MEDIUM The application must be capable of implementing host-based boundary protection mechanisms for servers, workstations, and mobile devices. A host-based boundary protection mechanism is a host-based firewall. Host-based boundary protection mechanisms are employed on mobile devices, such as notebook/laptop computers, and other types of mobile devices where such boundary protection mechanisms are available. Rationale for non-applicability: The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
SV-46943r1_rule SRG-APP-000251-MAPP-00051 CCI-001310 MEDIUM The mobile application must prevent XML injection. XML injection may result in an immediate loss of integrity of the data. Any vulnerability associated with a DoD Information system, the exploitation of which, by a risk factor, will directly and immediately result in loss of confidentiality, availability, or integrity of the system associated data. If a mobile application does not permit XML injection, then the risk of exploits from this form of attack is greatly reduced. Please refer to CWE 91 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
SV-46945r1_rule SRG-APP-000251-MAPP-00052 CCI-001310 MEDIUM The mobile application must validate the correctness of data inputs. Inputs may come from users or other processes. Absence of input validation opens an application to improper application functioning, the risk of manipulation of data by an adversary and the security risks associated with SQL script and integer overflow attacks. The lack of input validation can lead to immediate access to an application, denial of service, and malicious action on the stored data. In applying this control, the user is provided greater protection against malicious intruders, attempting to access the application or its remote server with data input that may allow access to the application or may cause unpredictable operation and corruption of data. Please refer to CWEs: 15, 20, 22, 73, 77, 78, 79, 80, 82, 83, 87, 88, 89, 90, 94, 95, 98, 99, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 117, 119, 120, 125, 126, 129, 131, 134, 170, 190, 193, 195, 197, 398 , 434, 466, 470, 501, 564, 566, 601, 639, 643, 692, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
SV-46947r1_rule SRG-APP-000251-MAPP-00053 CCI-001310 LOW The mobile application must define a character set for data inputs. Characters entered in an application's input fields that are undefined can lead to unpredictable results and leave the application's stored data vulnerable. By setting the character set for the application, the possibility of receiving unexpected input that uses other character set encodings could cause the application to operate unpredictably and allow an intruder access to the application through manipulation of certain characters that would allow access and privileges of authorized users. In defining character sets for input, users are assured of a greater security posture through use of a defined set of characters that are filtered for use with the application. Please refer to CWEs: 74, 78, and 88 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
SV-46952r1_rule SRG-APP-000251-MAPP-00054 CCI-001310 MEDIUM The mobile application must not contain format string vulnerabilities. Format string vulnerabilities usually occur when invalidated input is entered and is directly written into the format string used to format data in the print style family of C/C++ functions. If an attacker can manipulate a format string, this may result in a buffer overflow causing a denial of service for the application. Format string vulnerabilities may lead to information disclosure vulnerabilities. Format string vulnerabilities may be used to execute arbitrary code. If the application code does not contain format string vulnerabilities, then the risk of buffer overflows and other software exploits is significantly mitigated. Please refer to CWEs: 20, 74, 78, 88, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 251, 415, 560, 686, 733, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
SV-46953r1_rule SRG-APP-000251-MAPP-00055 CCI-001310 MEDIUM The mobile application must not be vulnerable to command injection. Format string vulnerabilities usually occur when invalidated input is entered and is directly written into the format string used to format data in the print style family of C/C++ functions. If an attacker can manipulate a format string, this may result in a buffer overflow causing a denial of service for the application. Format string vulnerabilities may lead to information disclosure vulnerabilities. Format string vulnerabilities may be used to execute arbitrary code. If the application code does not contain format string vulnerabilities, then the risk of buffer overflows and other software exploits is significantly mitigated. Please refer to CWEs: 20, 74, 78, 88, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 251, 415, 560, 686, 733, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
SV-46955r1_rule SRG-APP-000251-MAPP-00056 CCI-001310 MEDIUM The mobile application must prevent SQL injection. Format string vulnerabilities usually occur when invalidated input is entered and is directly written into the format string used to format data in the print style family of C/C++ functions. If an attacker can manipulate a format string, this may result in a buffer overflow causing a denial of service for the application. Format string vulnerabilities may lead to information disclosure vulnerabilities. Format string vulnerabilities may be used to execute arbitrary code. If the application code does not contain format string vulnerabilities, then the risk of buffer overflows and other software exploits is significantly mitigated. Please refer to CWEs: 20, 74, 78, 88, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 251, 415, 560, 686, 733, 787, and 805 for further information. Additional information on CWEs is found in the MAPP SRG Overview.
SV-46957r1_rule SRG-APP-000252-MAPP-NA CCI-001124 MEDIUM Boundary protection applications must prevent discovery of specific system components (or devices) composing a managed interface. Firewall control requirement for isolating and preventing the discovery of management interfaces. This control enhancement is intended to protect the network addresses of information system components that are part of the managed interface from discovery through common tools and techniques used to identify devices on a network. Rationale for non-applicability: The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
SV-46959r1_rule SRG-APP-000253-MAPP-NA CCI-001125 MEDIUM Applications designed to enforce protocol formats must employ automated mechanisms to enforce strict adherence to protocol format. Automated mechanisms used to enforce protocol formats include, deep packet inspection firewalls and XML gateways. These devices verify adherence to the protocol specification (e.g., IEEE) at the application layer and serve to identify significant vulnerabilities that cannot be detected by devices operating at the network or transport layer. It is impractical to expect protocol format inspection to be conducted manually. Rationale for non-applicability: Mobile applications often employ communications protocols but they do not enforce protocol formats for other applications. The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
SV-46960r1_rule SRG-APP-000254-MAPP-NA CCI-001126 MEDIUM Boundary protection applications must fail securely in the event of an operational failure. Fail secure is a condition achieved by the application of a set of information system mechanisms to ensure that in the event of an operational failure of a boundary protection device at a managed interface (e.g., router, firewall, guard, application gateway residing on a protected sub network commonly referred to as a demilitarized zone), the system does not enter into an unsecure state where intended security properties no longer hold. A failure of a boundary protection device cannot lead to, or cause information external to the boundary protection device to enter the device, nor can a failure permit unauthorized information release. Rationale for non-applicability: Mobile applications do not provide network services to other devices. Most mobile devices function outside the organization's security boundary and therefore are not positioned to provide boundary protection services in any case
SV-46962r1_rule SRG-APP-000255-MAPP-NA CCI-001100 MEDIUM Boundary protection applications must be capable of preventing public access into the organizations internal networks except as appropriately mediated by managed interfaces. Access into an organization's internal network and to key internal boundaries must be tightly controlled and managed. Applications monitoring and/or controlling communications at the external boundary of the system and at key internal boundaries must be capable of preventing public access into the organization's internal networks except as appropriately mediated by managed interfaces. Rationale for non-applicability: Mobile applications do not provide network services to other devices. Most mobile devices function outside the organization's security boundary and therefore are not positioned to provide boundary protection services in any case.
SV-46964r1_rule SRG-APP-000256-MAPP-NA CCI-001109 MEDIUM Any software application designed to function as a firewall must be capable employing a default deny all configuration. A firewall default deny is a firewall configuration setting that will force the administrator to explicitly allow network or application traffic rather than allowing all traffic by default. The purpose is to prevent unmanaged access into the internal network or in the case of an application firewall, to application content, features, or functionality. Rationale for non-applicability: Mobile applications do not provide network services to other devices. Most mobile devices function outside the organization's security boundary and therefore are not positioned to provide boundary protection services in any case.
SV-46975r1_rule SRG-APP-000257-MAPP-NA CCI-001111 MEDIUM Applications providing remote connectivity must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communications path with resources in external networks. This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings that are not configurable by the user of that device. An example of a non-remote communications path from a remote device is a virtual private network. When a non-remote connection is established using a virtual private network, the configuration settings prevent split-tunneling. Split-tunneling might otherwise be used by remote users to communicate with the information system as an extension of that system and to communicate with local resources such as, a printer or file server. Since the remote device, when connected by a non-remote connection, becomes an extension of the information system, allowing dual communications paths such as split-tunneling would be, in effect, allowing unauthorized external connections into the system. Rationale for non-applicability: Mobile applications that support remote access are not within the scope of this SRG.
SV-46977r1_rule SRG-APP-000258-MAPP-NA CCI-001112 MEDIUM Proxy applications must support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy applications must also be configurable with o External networks are networks outside the control of the organization. Proxy servers support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy servers are also configurable with organization-defined lists of authorized and unauthorized websites. Rationale for non-applicability: Mobile applications do not provide network services to other devices.
SV-46979r1_rule SRG-APP-000259-MAPP-NA CCI-001115 MEDIUM Applications performing extrusion detection must be capable of denying network traffic and auditing internal users (or malicious code) posing a threat to external information systems. Detecting internal actions that may pose a security threat to external information systems is sometimes termed extrusion detection. Extrusion detection at the information system boundary includes the analysis of network traffic (incoming as well as, outgoing) looking for indications of an internal threat to the security of external systems. Rationale for non-applicability: The requirement for application sandboxing precludes applications from providing extrusion detection for other applications. If an application were granted the ability to perform this function, the application could perform a man-in-the-middle attack on other applications running on the device.
SV-46980r1_rule SRG-APP-000260-MAPP-NA CCI-001306 MEDIUM Applications that serve to protect organizations and individuals from spam messages must incorporate update mechanisms updating protection mechanisms and signature updates when new application releases are available in accordance with organizational configuration management policies and procedures. Senders of spam messages are continually modifying their tactics and source email addresses in order to elude protection mechanisms. To stay up-to-date with the changing threat and to identify spam messages, it is critical that spam protection mechanisms are kept current. Rationale for non-applicability: Enterprise email server functionality is not within the scope of the Mobile Applications SRG, which applies to single-user applications that do not provide server functionality to other hosts.
SV-46981r1_rule SRG-APP-000261-MAPP-NA CCI-001308 MEDIUM Applications that are utilized to address the issue of spam and provide protection from spam must automatically update any and all spam protection measures including signature definitions. Originators of spam emails are constantly changing their source email addresses in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment which necessitates an automatic update capability. Rationale for non-applicability: Enterprise email server functionality is not within the scope of the Mobile Applications SRG, which applies to single-user applications that do not provide server functionality to other hosts.
SV-46983r1_rule SRG-APP-000262-MAPP-NA CCI-001297 MEDIUM Applications utilized for integrity verification must detect unauthorized changes to software and information. Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts. Rationale for non-applicability: The MDM SRG addresses integrity verification on mobile devices.
SV-46984r1_rule SRG-APP-000263-MAPP-NA CCI-001295 MEDIUM Applications must provide automated support for the management of distributed security testing. The need to verify security functionality applies to all security functions. For those security functions that are not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include: startup, restart, shutdown, and abort. Rationale for non-applicability: The MDM SRG addresses automated support for the management of distributed security testing.
SV-46985r1_rule SRG-APP-000264-MAPP-00057 CCI-001131 MEDIUM The mobile application must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission. Unencrypted sensitive application data could be intercepted in transit. Encryption of data in transit will protect the data from being extricated, modified or being used for malicious purposes. When the data is encrypted prior to transmission, the risk of unauthorized disclosure from interception and the subsequent use thereof is greatly reduced.
SV-46986r1_rule SRG-APP-000265-MAPP-00058 CCI-001311 MEDIUM The mobile application must identify potentially security-relevant error conditions. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. An error condition can occur when an attacker provides unexpected values at an input prompt, causing the mobile application to crash or force it to excessively consume resources, such as battery, memory and CPU. This can also expose the application to data confidentiality and integrity issues as a result of the attacker gaining control of the device. Applying this control assures that security-relevant issues arising from data input correctness are addressed.
SV-46987r1_rule SRG-APP-000266-MAPP-00059 CCI-001312 MEDIUM The mobile application must not include sensitive information in system logs not necessary for IA functions. The application must only generate messages that provide information necessary for corrective actions and without revealing organization defined sensitive or potentially harmful information. Any application providing too much information in system logs and in administrative messages to the screen risks compromising the data and security of the application and system. This control assures DoD is given greater protection against authentication credentials being exposed to both internal and malicious external users, when an error occurs. Please refer to CWE 388 for further information. The MAPP SRG Overview contains additional information on CWEs.
SV-46988r1_rule SRG-APP-000267-MAPP-00060 CCI-001314 LOW The mobile application must not transmit error messages to any entity other than authorized audit logs, the MDM, or the device display. Error messages that are transmitted outside of the application environment reveal weaknesses in the application that will offer the potential for exposure to malicious users. By default many error messages contain data pertaining to the session, the ports, and user and in some instances, their authentication credentials. Through this control, any issues that an application may have are restricted to the user and the personnel who have access to audit logs.
SV-46989r1_rule SRG-APP-000268-MAPP-00061 CCI-001328 LOW The mobile application must alert the MOS or MDM upon each instance of an application component failure An application that suffers a component failure is vulnerable to exposure that leaves the application, device, and stored data exposed to potential malicious activity. One component that may fail, yet leave the application operational is a security module that provides encryption of all data at rest or in transit. Similarly, a module that labels data with the appropriate classification attribute could also fail, yet allow the application to continue to function. In these instances, and with components that have failed, the application is no longer able to protect itself to the same level of security when fully operational. Alerts sent to the MOS provide information that can be used to initiate a fix or invoke incident response procedures.
SV-46990r1_rule SRG-APP-000269-MAPP-NA CCI-001232 MEDIUM Applications providing patch management capabilities must support the organizational requirements to install software updates automatically. Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously. Anytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability. Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates. Rationale for non-applicability: The MDM determines the state of information system components with respect to flaw remediation. This is outside the scope of this SRG. Moreover, typically mobile applications are not "patched" but are replaced with an updated version.
SV-46991r1_rule SRG-APP-000270-MAPP-NA CCI-001233 MEDIUM Applications serving to determine the state of information system components with regard to flaw remediation (patching) must use automated mechanisms to make that determination. The automation schedule must be determined on an organization-defined basis. Organizations are required to identify information systems containing software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws) and report this information to designated organizational officials with information security responsibilities (e.g., senior information security officers, information system security managers, information systems security officers). To support this requirement, an automated process or mechanism is required. This role is usually assigned to patch management software that is deployed in order to track the number of systems installed in the network, as well as, the types of software installed on these systems, the corresponding versions, and the related flaws that require patching. Rationale for non-applicability: The MDM determines the state of information system components with respect to flaw remediation. This is outside the scope of this SRG. Moreover, typically mobile applications are not "patched" but are replaced with an updated version.
SV-46992r1_rule SRG-APP-000271-MAPP-NA CCI-001237 MEDIUM The application must support organizational requirements to employ automated patch management tools to facilitate flaw remediation to organization-defined information system components. Patch management tools must be automated. The organization (including any contractor to the organization) shall promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, shall also be addressed expeditiously. Due to information system integrity and availability concerns, organizations shall give careful consideration to the methodology used to carry out automatic updates. Rationale for non-applicability: Automated updates of mobile application software is an MDM function and is therefore outside the scope of this SRG.
SV-46993r1_rule SRG-APP-000272-MAPP-NA CCI-001247 MEDIUM The application must automatically update malicious code protection mechanisms, including signature definitions. Examples include anti-virus signatures and malware data files employed to identify and/or block malicious software from executing. Anti-virus and malicious software detection applications utilize signature definitions in order to identify viruses and other malicious software. These signature definitions need to be constantly updated in order to identify the new threats that are discovered every day. All anti-virus and malware software shall come with an update mechanism that automatically updates these signatures. The organization (including any contractor to the organization) is required to promptly install security-relevant malicious code protection software updates (e.g., anti-virus signature updates and hot fixes). Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: The MDM SRG addresses white listing of applications, which is the primary mechanism for protecting mobile devices from malware.
SV-46994r1_rule SRG-APP-000273-MAPP-NA CCI-001248 MEDIUM The application must prevent non-privileged users from circumventing malicious code protection capabilities. Malicious code protection software must be protected so as to prevent a non-privileged user or malicious piece of software from disabling the protection mechanism. A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Examples include the capability for non-administrative user's to turn off or otherwise disable anti-virus. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-46995r1_rule SRG-APP-000274-MAPP-NA CCI-001249 MEDIUM Malicious code protection applications must update malicious code protection mechanisms only when directed by a privileged user. Malicious code protection software must be protected to prevent a non-privileged user or malicious piece of software from manipulating the protection update mechanism. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-46996r1_rule SRG-APP-000275-MAPP-00062 CCI-001294 MEDIUM The mobile application must provide notification of failed automated security tests. Automated security tests may include checking the cryptographic hash of key application files, and verifying the presence of critical MOS services, the presence of a VPN connection, correct file permission, or other security functionality. The need to verify security functionality applies to all security functions, and can be achieved through automated security tests of the application. When an application fails one of its automated security tests with security components unavailable or non-functional, the application is no longer able to protect itself to the same level of security were the security components functional. In applying this control, the application is able to activate an alarm and/or automatically notify the user a security test has failed and provides the user a greater level of security knowing that the application should stop being used. Logging the event is also an acceptable means of notification.
SV-46997r1_rule SRG-APP-000276-MAPP-NA CCI-001240 MEDIUM Applications providing malicious code protection must support organizational requirements to update malicious code protection mechanisms (including signature definitions) whenever new releases are available in accordance with organizational configuration Malicious code protection mechanisms include, but are not limited to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-46998r1_rule SRG-APP-000277-MAPP-NA CCI-001241 MEDIUM Applications scanning for malicious code must support organizational requirements to configure malicious code protection mechanisms to perform periodic scans of the information system on an organization-defined frequency. Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed. This software must periodically scan the system to search for malware on an organization defined frequency. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-46999r1_rule SRG-APP-000278-MAPP-NA CCI-001242 MEDIUM Applications providing malicious code protection must support organizational requirements to configure malicious code protection mechanisms to perform real-time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy. Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-47000r1_rule SRG-APP-000279-MAPP-NA CCI-001243 MEDIUM Applications providing malicious code protection must support organizational requirements to be configured to perform organization-defined action(s) in response to malicious code detection. Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Applications providing this capability must be able to perform actions in response to detected malware. Responses include, but are not limited to, quarantine, deletion, and alerting. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-47001r1_rule SRG-APP-000280-MAPP-NA CCI-001245 MEDIUM Applications providing malicious code protection must support organizational requirements to address the receipt of false positives during malicious code detection, eradication efforts, and the resulting potential impact on the availability of the information system. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Applications providing this capability must have an ability to address the issue of false alerts. False alerts can overwhelm reporting and administrative interfaces making it difficult to identify the true threat. A filtering capability that serves to identify and remove false positives is often employed to address this issue. Rationale for non-applicability: Malicious code protections are implemented by the mobile operating system in conjunction with an MDM. Mobile applications within the scope of the SRG have no relationship to this functionality.
SV-47002r1_rule SRG-APP-000281-MAPP-NA CCI-001259 MEDIUM Intrusion detection software must be able to interconnect using standard protocols to create a system wide intrusion detection system. When utilizing intrusion detection software, monitoring components are usually dispersed throughout the network, such as, when utilizing HIDS and multiple NIDS sensors. In order to leverage the capabilities of intrusion detection systems to get a complete overall view of network and host activity, these separate components must be able to report and react to activity they detect. Non-standard or custom communication protocols do not provide the reliability and veracity required of an enterprise class intrusion detection system. An example of a custom protocol includes, but is not limited to, vendor specific communication protocols that have not undergone IETF RFC evaluation and/or are not in common use throughout the Internet as a whole. Rationale for non-applicability: The MDM SRG addresses mechanisms that check the integrity of the mobile device.
SV-47004r1_rule SRG-APP-000282-MAPP-NA CCI-001272 MEDIUM For those instances where the organization requires encrypted traffic to be visible to information system monitoring tools, the application transmitting the encrypted traffic must make provisions to allow that traffic to be visible to specific system monitoring. There is a recognized need to balance encrypting traffic versus the need to have insight into the traffic from a monitoring perspective. For some organizations, the need to ensure the confidentiality of traffic is paramount; for others, the mission-assurance concerns are greater. Rationale for non-applicability: The mobile application resides at a network endpoint. If it performs end-to-end encryption, then network traffic will not be visible to intermediate devices. IF there is a requirement for monitoring of this traffic, keys must be shared with the intermediate device. Achieving this capability is outside the scope of the mobile application, as the necessary modifications must be made to the intermediate device, not the end points.
SV-47005r1_rule SRG-APP-000283-MAPP-NA CCI-001262 MEDIUM Applications providing malware and/or firewall protection must monitor inbound and outbound communications for unauthorized activities or conditions. Unusual/unauthorized activities or conditions include internal traffic indicating the presence of malicious code within an information system or propagating among system components, the unauthorized export of information, or signaling to an external information system. Evidence of malicious code is used to identify potentially compromised information systems or information system components. Examples of applications that provide monitoring capability for unusual/unauthorized activities include, but are not limited to, Intrusion Detection, Anti-Virus and Malware etc. Rationale for non-applicability: The requirement for application sandboxing precludes applications from serving as a security boundary for other applications. If an application were granted the ability to perform this function, the mobile application could perform a man-in-the-middle attack on other applications running on the device.
SV-47006r1_rule SRG-APP-000284-MAPP-NA CCI-001263 MEDIUM Applications that detect and alarm on security events such as Intrusion Detection, Firewalls, Anti-Virus, or Malware must provide near real-time alert notification. When an intrusion detection security event occurs it is imperative the application that has detected the event immediately notify the appropriate support personnel so they can respond accordingly. Lack of this capability increases the risk that attacks will go unnoticed or responses will be delayed. Rationale for non-applicability: The MDM SRG covers the mechanisms for security-related alerts. This SRG strongly encourages that mobile applications forward security-related events to the system audit logs accessible by the MDM centralized auditing solution.
SV-47007r1_rule SRG-APP-000285-MAPP-NA CCI-001265 MEDIUM Applications providing IDS and prevention capabilities must prevent non-privileged users from circumventing intrusion detection and prevention capabilities. Any application providing intrusion detection and prevention capabilities must be architected and implemented so as to prevent non-privileged users from circumventing such protections. This can be accomplished through the use of user roles, use of proper systems permissions, auditing, logging, etc. Rationale for non-applicability: The MDM SRG addresses mechanisms that check the integrity of the mobile device. The mobile operating system enforces controls that prevent circumvention of MDM capabilities.
SV-47009r1_rule SRG-APP-000286-MAPP-NA CCI-001266 MEDIUM Applications providing notifications regarding suspicious events must include the capability to notify an organization-defined list of response personnel who are identified by name and/or by role. Incident response applications are by their nature designed to monitor, detect, and alarm on defined events occurring on the system or on the network. A large part of their functionality is accurate and timely notification of events. Notifications can be made more efficient by the creation of notification groups containing members who would be responding to a particular alarm or event. Rationale for non-applicability: The MDM SRG covers the mechanisms for security related alerts.
SV-47010r1_rule SRG-APP-000287-MAPP-NA CCI-001670 LOW The mobile application must notify the user or MDM, or shut down if it fails an automated security test. System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action that the application takes to terminate suspicious events. A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system. Rationale for non-applicability: Security monitoring functions are out of scope, as they are primarily addressed through MOS and MDM controls.
SV-47012r1_rule SRG-APP-000288-MAPP-NA CCI-001269 MEDIUM The application must enforce organizational requirements to protect information obtained from intrusion monitoring tools from unauthorized access, modification, and deletion. Intrusion monitoring applications are by their nature designed to monitor and record network and system traffic and activity. They can accumulate a significant amount of sensitive data, examples of which could include user account information and application data not related to the intrusion monitoring application itself. Intrusion monitoring tools also obtain information that is critical to conducting forensic analysis on attacks occurring within the network. This data may be sensitive in nature. Information obtained by intrusion monitoring applications in the course of evaluating network and system security needs to be protected. Rationale for non-applicability: Intrusion monitoring tools are not within the scope of this SRG. The MDM SRG addresses mechanisms that check the integrity of the mobile device.
SV-47013r1_rule SRG-APP-000289-MAPP-NA CCI-001291 MEDIUM The application must either implement compensating security controls or the organization explicitly accepts the risk of not performing the verification as required. Application security functional testing involves testing the application for conformance to the applications security function specifications, as well as, for the underlying security model. The need to verify security functionality applies to all security functions. The conformance criteria state the conditions necessary for the application to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry. Organizations may define conditions requiring verification and the frequency in which such testing occurs. Security function testing usually occurs during the development phase and can in some instances occur in the production phase if the developer provides the security conformance criteria or if the conformance criteria can be established. There are application testing frameworks available that can perform functional testing on production systems however they are limited in their applicability and are language or product centric. Rationale for non-applicability: An assumption of this SRG is that the controls delineated in this SRG reduce risk to an acceptable level and that additional compensating controls are not required. Defense in depth is also provided by controls in the MOS SRG and MDM SRG.
SV-47015r1_rule SRG-APP-000290-MAPP-NA CCI-001496 MEDIUM The application must use cryptographic mechanisms to protect the integrity of audit tools Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced. An example is a checksum hash of the file or files. Applications that function as audit tools must use cryptographic mechanisms to protect the integrity of the tools or allow cryptographic protection mechanisms to be applied to their tools. All applications must not impede or hamper this requirement. Rationale for non-applicability: Mobile devices are not expected to have local audit tools. Instead, the mobile device will transfer logs to centralized audit tools for analysis and reporting.
SV-47016r1_rule SRG-APP-000291-MAPP-NA CCI-001683 MEDIUM The application must notify appropriate individuals when accounts are created. Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must support the requirement to notify appropriate individuals upon account creation. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
SV-47017r1_rule SRG-APP-000292-MAPP-NA CCI-001684 MEDIUM The application must notify appropriate individuals when accounts are modified. Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify or copy an existing account. Notification of account modification is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the modification of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created or modified and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must support the requirement to notify appropriate individuals when accounts are modified. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
SV-47018r1_rule SRG-APP-000293-MAPP-NA CCI-001685 MEDIUM The application must notify appropriate individuals when account disabling actions are taken. When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must audit account disabling actions and, as required, notify as required the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must notify, or leverage other mechanisms that notify, the appropriate individuals when accounts disabling actions are taken. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
SV-47019r1_rule SRG-APP-000294-MAPP-NA CCI-001686 MEDIUM The application must notify appropriate individuals when accounts are terminated. When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms that meet or exceed access control policy requirements. Examples include but are not limited to Active Directory and LDAP. The application must automatically notify the appropriate individuals when accounts are terminated. Rationale for non-applicability: This SRG applies to single-user applications. Therefore, account management requirements are not applicable.
SV-47033r1_rule SRG-APP-999999-MAPP-00064 CCI-000366 MEDIUM The mobile application code must not contain hardcoded references to resources external to the application. Hardcoded resources include URLs and path references to files outside of the application environment. If an adversary is aware of such references, they can attack the application by breaching the external resource it calls. In most cases, such references may be placed in configuration files that may be updated when the resource reference is no longer valid. This also makes such references more transparent than they would be if they remained embedded in application code.
SV-47034r1_rule SRG-APP-999999-MAPP-00065 CCI-000366 LOW The mobile application must remove temporary files when it terminates. Temporary files left on the system after an application has terminated may contain sensitive information. Such sensitive information includes authentication credentials or session identifiers that would enable an adversary to gain unauthorized access to other resources. Removing such files when an application terminates greatly mitigates the risk of this attack that would exploit these files and use them to re-launch the application, enjoy user privileges or to breach the confidentiality or integrity of the data stored on the device.
SV-47035r1_rule SRG-APP-999999-MAPP-00067 CCI-000366 MEDIUM The mobile application must clear or overwrite memory blocks used to process sensitive data. Sensitive data in memory should be cleared or overwritten to protect data that may be available to an attacker seeking ways to gain access to data that otherwise appears erased. Unless an application can overwrite memory blocks, the possibility exists for an attacker to cause the application to crash and analyze a memory dump of the application for sensitive information. Clearing memory will ensure the DoD the application can operate more securely, with greater protection applied to sensitive data that will be properly removed when no longer required. Additional overwriting requirements may be applicable to classified applications. Please refer to CWEs: 14, 226, 244, and 591 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.
SV-47036r1_rule SRG-APP-999999-MAPP-00066 CCI-000366 LOW The mobile application must remove cookies or information used to track a users identity when it terminates. If the application does not remove temporary data, such as authentication data, temporary files containing sensitive data, and cookies, the data can be used again if the device lost or stolen. Such information could also be used to track the user across application sessions or even across different applications, which poses an OPSEC risk. The temporary data could be used to re-authenticate the user or allow unauthorized access to sensitive data. Removing cookies assures DoD greater security from intruders and unauthorized users accessing the temporary data and using it to potentially access the system, accessing sensitive data and compromising sensitive data's integrity.
SV-47037r1_rule SRG-APP-999999-MAPP-00068 CCI-000366 MEDIUM The mobile application must not be vulnerable to integer arithmetic vulnerabilities. Integer overflows occur when an integer has not been properly checked and is used in memory allocation, copying, and concatenation. Also, when incrementing integers past their maximum possible value, it could potentially become a very small or negative number. Integer overflows can lead to infinite looping when loop index variables are compromised and cause a denial of service. If the integer is used in data references, the data can become corrupt. Also, using the integer in memory allocation can cause buffer overflows and a denial of service. Integers used in access control mechanisms can potentially trigger buffer overflows, which can be used to execute arbitrary code. Removing integer arithmetic vulnerabilities mitigates the risk of multiple vulnerabilities to include denial of service to the application and the execution of arbitrary code. Please refer to CWEs: 125, 126, 190, 195, 197, 398, 787, and 805 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.
SV-47038r1_rule SRG-APP-999999-MAPP-00069 CCI-000366 MEDIUM The mobile application must not call functions vulnerable to buffer overflows. Buffer overflow attacks occur when improperly validated input is passed to an application overwriting of memory. Buffer overflow errors stop execution of the application causing a minimum of denial of service and possibly a system call to a command shell giving an attacker access to the underlying operating system. An application that avoids buffer flow situations assures DoD greater availability of the application due to better security against DoS attacks. Please refer to CWEs: 20, 74, 78, 88, 117, 119, 120, 125, 129, 131, 134, 135, 170, 170, 176, 193, 195, 242, 249, 250, 251, 265, 415, 560, 686, 733, 787, and 805 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.
SV-47039r1_rule SRG-APP-999999-MAPP-00070 CCI-000366 MEDIUM The mobile application must not have canonical representation vulnerabilities. Canonical representation issues arise when the name of a resource is used to control resource access. There are multiple methods of representing resource names on a computer system. An application relying solely on a resource name to control access may incorrectly make an access control decision if the name is specified in an unrecognized format. Through this control, DoD can be assured of greater security from inadvertent or malicious use of resources on the device that could, if used, would compromise the device, user and sensitive on-board data. Please refer to CWEs: 22, 73, 94, 98, 99, and 601 for further information. The MAPP SRG Overview contains additional information on the use of CWEs.
SV-47040r1_rule SRG-APP-999999-MAPP-00071 CCI-000366 MEDIUM The mobile application must not be vulnerable to race conditions. A race condition occurs when an application receives two or more actions on the same resource in an unanticipated order which causes a conflict. Sometimes, the resource is locked by different users or functions within the application creating a deadlock situation. Racing can occur when the design uses global variables in place of local variables, multi-threaded application do not use thread safe functions when threads are accessing the same object or data as two examples. Applying this control, the DoD is protected against situations that would reduce the security posture of the application, device, data, and network as a result of security-related components not able to function as a result of the race condition. Furthermore, the user is also protected against access and availability issues that result from the application or certain components of the application from functioning correctly as a result of the race condition. Examples of race conditions vulnerabilities can be obtained from the OWASP website at https://www.owasp.org.
SV-47041r1_rule SRG-APP-999999-MAPP-00073 CCI-000366 MEDIUM The mobile application must initialize all parameter values on start up. An application could be compromised, providing an attack vector to it if the application initialization process is not designed to keep the application in both a secure and functional state. Any operating parameter in the application, such as variables and settings, must be reset and initialized to default values otherwise an adversary, in possession of the device could access the application with privileges. An application that re-initializes its parameters at start up is assured a more secure session since the application has initialized all functional components that allow it to operate properly and thus securely.
SV-47042r1_rule SRG-APP-999999-MAPP-00075 CCI-000366 HIGH The mobile application must not record or forward sensor data unless explicitly authorized to do so. Sensors include the GPS, gyroscope, accelerometer, camera, and microphone. When sensor data is either recorded locally or sent to a remote server, the potential exists for an adversary to obtain sensitive information that could be used to harm the user or compromise information systems. In particular, when location data is forwarded, the user may be physically targeted. User safety and mission assurance risks are mitigated when sensor data is only collected or forwarded when expressly authorized.
SV-47043r1_rule SRG-APP-999999-MAPP-00078 CCI-000366 MEDIUM The mobile application installation package must be digitally signed in accordance with FIPS 186-3. One of the biggest risks on a mobile device is that it will execute malware that will compromise sensitive data on the device or enable subsequent attacks on other DoD information systems. One of the most effective means for preventing malware execution is to authenticate that software comes from a trusted source before it is installed. Digital signatures on software can be used to authenticate that the software comes from a trusted source. Signing the software in accordance with FIPS 186-3 provides additional assurance that the signature was affixed properly.
SV-47087r1_rule SRG-APP-000055-MAPP-NA CCI-000027 MEDIUM Applications must enforce information flow using dynamic control based on policy that allows or disallows information flow based on changing conditions or operational considerations. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet, blocking outside traffic claiming to be from within the organization and not passing any web requests to the Internet that are not from the internal web proxy. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Flow control is also based on the characteristics of the information and/or the information path. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Rationale for non-applicability: Mobile applications that provide flow control or inter-domain communication are outside the scope of this SRG.
SV-47088r1_rule SRG-APP-999999-MAPP-00077 CCI-000366 HIGH The mobile application source code must not contain known malware. Malware will compromise the application data, device, and system to every possible compromising scenario. Under no circumstances will any code that is known to contain malware be used. The entire application ecosystem will operate at a higher security with much higher integrity than a system with known malware.