acceptedMobile Operating System Security Requirements GuideThe Mobile OS 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 SP 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil.DISA, Field Security OperationsSTIG.DOD.MILRelease: 3 Benchmark Date: 26 Jul 20131I - Mission Critial Classified<ProfileDescription></ProfileDescription>I - Mission Critial Public<ProfileDescription></ProfileDescription>I - Mission Critial Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-OS-000001-NA<GroupDescription></GroupDescription>SRG-OS-000001-NAThe operating system must provide automated support for account management functions.<VulnDiscussion>A comprehensive account management process that includes automation helps to ensure the 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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000015The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000002-NA<GroupDescription></GroupDescription>SRG-OS-000002-NAThe operating system must automatically terminate temporary accounts after an organization defined time period for each type of account.<VulnDiscussion>When temporary and emergency accounts are created, there is a risk the temporary account may remain in place and active after the need for the account no longer exists.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000016The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000003-NA<GroupDescription></GroupDescription>SRG-OS-000003-NAThe operating system must automatically disable inactive accounts after an organization defined time period.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000017The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000004-NA<GroupDescription></GroupDescription>SRG-OS-000004-NAThe operating system must support the requirement to automatically audit on account creation.<VulnDiscussion>Auditing of account creation is a method and best practice for mitigating the risk of an attacker creating a persistent method of re-establishing access. A comprehensive account management process will ensure an audit trail which documents the creation of accounts and if required notifies administrators. Such a process greatly reduces the risk of accounts being created outside the normal approval process and provides logging that can be used for forensic purposes. Additionally, the audit records of account creation can be compared to the known approved account creation list.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000018The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000005-NA<GroupDescription></GroupDescription>SRG-OS-000005-NAThe operating system must dynamically manage user privileges and associated access authorizations.<VulnDiscussion>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. The operating system needs to be able to dynamically manage user privileges and access authorization decisions.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000020The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000006-NA<GroupDescription></GroupDescription>SRG-OS-000006-NAThe operating system must enforce dual authorization, based on organizational policies and procedures for organization defined privileged commands.<VulnDiscussion>Dual authorization mechanisms require two distinct approving authorities to approve the use of the command prior to it being invoked. An organization may determine certain commands or configuration changes require dual-authorization before being activated. The operating system must have the ability to enforce this dual authorization.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000021The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000007-MOS-000001<GroupDescription></GroupDescription>SRG-OS-000007-MOS-000001The mobile operating system must enforce a mandatory access control (MAC) policy that prohibits any application, user, or process from modifying software in the trusted computing base with the exception of protected processes dedicated to performing updates to particular trusted computing base components.<VulnDiscussion>The trusted computing base includes the OS, device drivers, system and security configuration files, and key material. OS functions include audit and security policy enforcement mechanisms. In the context of this requirement, an update process is protected if is not modifiable by other processes and requires cryptographic authentication before performing updates. When access control to trusted computing base components is discretionary, a malicious user or program who obtains the necessarily privileges can circumvent security controls on the device. This likely enables the malicious user or process to obtain sensitive data and launch attacks on other systems. Privilege elevation on discretionary access control (DAC) systems can occur in a variety of ways that cannot be detected by the operating system or intrusion detection software. MAC systems preclude the possibility of this sort of privilege elevation by design and therefore greatly reduce the risk of system security breaches.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000022Configure the mobile operating system to enforce mandatory access controls (MAC) prohibiting any application, user, or process from modifying software in the trusted computing base with the exception of protected processes dedicated to performing updates to particular trusted computing base components.Review OS documentation to determine if the OS supports MAC and to determine the scope of the trusted computing base. Review the MAC policy to determine if it prevents any application, user, or process from modifying software in the trusted computing base. Verify update processes are the only processes permitted to perform updates. Also, verify each update process is dedicated to the component it updates and does not update other components or perform functions other than software update. If the OS does not support MAC, or the MAC policy does not prevent unauthorized modification of software in the trusted computing base, or the software update process is not compliant, this is a finding.SRG-OS-000007-MOS-000002<GroupDescription></GroupDescription>SRG-OS-000007-MOS-000002The mobile operating system must enforce a mandatory access control (MAC) policy that prohibits any application from having both write and execute permissions to a file on the device.<VulnDiscussion>System integrity is dependent on properly controlling what software is executable. When programs are permitted to create or modify files and then subsequently execute those same files, this enables these programs to circumvent controls on the system designed to prevent malicious code execution. A rogue application that has the ability to both write and execute a file can perform a variety of unauthorized actions that could not have been anticipated when the application was authorized for installation. Such actions might include the ability to exfiltrate sensitive data on the device and to perform attacks on other systems. Preventing this behavior through the implementation of an appropriate MAC policy greatly mitigates the risk of this attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000022Configure the mobile operating system to enforce mandatory access controls (MAC) prohibiting any application from having both write and execute permissions to a file on the device.Review OS documentation to determine if the OS supports MAC related to write and execute functions. Review the MAC policy to ascertain whether programs may have both write and execute permissions to files. If the OS does not support MAC, or if it is possible for an application to both write and execute a file, this is a finding.SRG-OS-000007-MOS-000003<GroupDescription></GroupDescription>SRG-OS-000007-MOS-000003The mobile operating system must enforce a mandatory access control (MAC) policy that prohibits any application from accessing the data or code of another application unless such data or code has been expressly allowed by the policy to be a shared resource.<VulnDiscussion>When an application has the ability to access the data and code of another application, it may use that access improperly to obtain sensitive DoD data or perform unauthorized functions, including attacks on the mobile device and possibly remote systems as well. Most malware depends on this type of unauthorized access to carry out its malicious objectives. MAC-based application sandboxing or isolation greatly reduces the ability of malware to compromise system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000022Configure the mobile operating system to enforce mandatory access controls (MAC) prohibiting any application from accessing the data or code of another application unless such data or code has been expressly allowed by the policy to be a shared resource.Review OS documentation to determine if the OS supports MAC related to application sandboxing or isolation. Review the MAC policy to ascertain whether programs have the potential to access the data or code of another application. If the OS does not support MAC, or it is possible for an application to access the data or code of other non-shared applications, this is a finding.SRG-OS-000008-NA<GroupDescription></GroupDescription>SRG-OS-000008-NAThe operating system must prevent access to organization defined security-relevant information except during secure, non-operable system states.<VulnDiscussion>Security-relevant information is any information within the information system potentially impacting the operation of security functions in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Organizations may define specific security relevant information requiring protection.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000024The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000009-NA<GroupDescription></GroupDescription>SRG-OS-000009-NAThe operating system must enforce information flow control using explicit security attributes on information, source, and destination objects as a basis for flow control decisions.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000025The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000010-NA<GroupDescription></GroupDescription>SRG-OS-000010-NAThe operating system must enforce information flow control using protected processing domains (e.g., domain type enforcement) as a basis for flow control decisions.<VulnDiscussion>Protected processing domains can be used to separate different data types. The operating system must enforce information flow control to ensure information does not pass into domains that are not authorized to process it.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000026The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000011-NA<GroupDescription></GroupDescription>SRG-OS-000011-NAThe operating system must enforce dynamic information flow control based on policy that must allow or disallow information flows based upon changing conditions or operational considerations.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000027The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000012-NA<GroupDescription></GroupDescription>SRG-OS-000012-NAThe operating system must prevent encrypted data from bypassing content checking mechanisms.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000028The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000013-NA<GroupDescription></GroupDescription>SRG-OS-000013-NAThe operating system must enforce organization defined limitations on the embedding of data types within other data types.<VulnDiscussion>The operating system must enforce organization defined limitations on the embedding of data types within other data types.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000029The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000014-NA<GroupDescription></GroupDescription>SRG-OS-000014-NAThe operating system must enforce information flow control on metadata.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000030The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000015-NA<GroupDescription></GroupDescription>SRG-OS-000015-NAThe operating system must support organization defined one-way flows using hardware mechanisms.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000031The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000016-NA<GroupDescription></GroupDescription>SRG-OS-000016-NAThe operating system must enforce information flow control using organization defined security policy filters as a basis for flow control decisions.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000032The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000017-NA<GroupDescription></GroupDescription>SRG-OS-000017-NAThe operating system must provide the capability for a privileged administrator to enable/disable organization defined security policy filters.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000034The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000018-NA<GroupDescription></GroupDescription>SRG-OS-000018-NAThe operating system must provide the capability for a privileged administrator to configure the organization defined security policy filters to support different security policies.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000035The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000019-NA<GroupDescription></GroupDescription>SRG-OS-000019-NAThe operating system must implement separation of duties through assigned information system access authorizations.<VulnDiscussion>Separation of duties is a prevalent Information Technology control 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 the person accountable for approving an action is not the same person who is tasked with implementing or carrying out the action.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000037The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000020-NA<GroupDescription></GroupDescription>SRG-OS-000020-NAThe mobile operating system must audit any use of privileged accounts, or roles, with access to organization defined security functions or security relevant information, when accessing other system functions.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000040The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000021-NA<GroupDescription></GroupDescription>SRG-OS-000021-NAThe operating system must enforce the organization defined limit of consecutive invalid access attempts by a user during the organization defined time period.<VulnDiscussion>Anytime an authentication method is exposed, allowing for the utilization of an operating system, there is a risk that attempts will be made to obtain unauthorized access.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001383, which requires purging information from the device after multiple unsuccessful unlock attempts to the mobile device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000044The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000022-NA<GroupDescription></GroupDescription>SRG-OS-000022-NAThe operating system, when the maximum number of unsuccessful attempts is exceeded, must automatically lock the account for an organization defined time period or must lock the account until released by an administrator IAW organizational policy.<VulnDiscussion>Anytime an authentication method is exposed to allow for the utilization of an operating system, there is a risk that attempts will be made to obtain unauthorized access.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001383, which requires purging information from the device after multiple unsuccessful unlock attempts to the mobile device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000047The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000023-MOS-000004<GroupDescription></GroupDescription>SRG-OS-000023-MOS-000004The mobile operating system must display the DoD warning banner exactly as specified at startup device unlock.<VulnDiscussion>The operating system is required to display the DoD approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met.
System use notification messages can be displayed when individuals log in to the information system. The approved DoD text must be used as specified in the DoD CIO memorandum dated 9 May 2008 (see the check text for required wording).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000048Implement a banner at startup device unlock with text matching the required wording.Verify the mobile device displays the specific banner text (as designated below) at startup device unlock. If the mobile device is not capable of supporting a banner at startup device unlock, this is a finding. If there is no banner, or if the banner's wording does not match the approved wording, this is a finding.
[Use this banner for devices accommodating banners of 1300 characters.]
"DOD NOTICE AND CONSENT BANNER
You are accessing a U.S. Government (USG) information system (IS) that is provided for USG-authorized use only.
By using this IS, you consent to the following conditions:
-The USG routinely monitors communications occurring on this IS, and any device attached to this IS, for purposes including, but not limited to, penetration testing, COMSEC monitoring, network defense, quality control, and employee misconduct, law enforcement, and counterintelligence investigations.
-At any time, the USG may inspect and/or seize data stored on this IS and any device attached to this IS.
-Communications occurring on or data stored on this IS, or any device attached to this IS, are not private. They are subject to routine monitoring and search.
-Any communications occurring on or data stored on this IS, or any device attached to this IS, may be disclosed or used for any USG-authorized purpose.
-Security protections may be utilized on this IS to protect certain interests that are important to the USG. For example, passwords, access cards, encryption or biometric access controls provide security for the benefit of the USG. These protections are not provided for your benefit or privacy and may be modified or eliminated at the USG's discretion."
[For Blackberries and other PDAs/PEDs with severe character limitations.]
"I've read & consent to terms in IS user agreem't."SRG-OS-000024-MOS-000005<GroupDescription></GroupDescription>SRG-OS-000024-MOS-000005The mobile operating system must retain the notification message or banner on the screen preventing further activity until the user executes a positive action to manifest agreement by selecting a box indicating acceptance.<VulnDiscussion>To establish acceptance of system usage policy, a click-through banner at startup device unlock is required. The banner must prevent further activity on the application unless and until the user executes a positive action to manifest agreement by clicking the indicated acceptance. By preventing access to the system until the user accepts the conditions, legal requirements are met to protect the DoD and to remind users the device is designed and implemented for business use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000050Modify the startup unlock process to require the banner text remain on the screen and prevent further activity until the user executes a positive action to manifest agreement by selecting a box indicating acceptance.Examine the mobile operating system configuration for preventing further activity on the mobile device until the user executes a positive action to manifest agreement by selecting a box indicating acceptance. If the startup unlock process does not explicitly require the user manifest agreement by selecting a box indicating acceptance, this is a finding.SRG-OS-000025-MOS-000006<GroupDescription></GroupDescription>SRG-OS-000025-MOS-000006The mobile operating system, upon successful startup unlock, must display to the user the date and time of the last successful unlock or access.<VulnDiscussion>Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the date and time of their last successful startup unlock allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000052Configure the mobile operating system to display the date and time of the last successful unlock or access.Examine the mobile operating system configuration for displaying the date and time of the last successful startup unlock. If the mobile operating system does not display the last successful startup unlock attempt, this is a finding.SRG-OS-000026-MOS-000007<GroupDescription></GroupDescription>SRG-OS-000026-MOS-000007The mobile operating system, upon successful unlock, must display to the user the number of unsuccessful unlock attempts since the last successful device unlock.<VulnDiscussion>Users need to be aware of activity that occurs regarding their mobile device. Providing users with information regarding the number of unsuccessful attempts that were 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-000053Configure the mobile operating system to display, upon successful unlock, the number of unsuccessful unlock attempts since the last successful device unlock.Examine the mobile operating system configuration for displaying the number of unsuccessful unlock attempts since the last successful device unlock. If the mobile operating system does not display the number of unsuccessful unlock attempts, this is a finding.SRG-OS-000027-NA<GroupDescription></GroupDescription>SRG-OS-000027-NAThe operating system must limit the number of concurrent sessions for each account to an organization defined number of sessions.<VulnDiscussion>Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. The organization may define the maximum number of concurrent sessions for an information system account globally, by account type, by account, or a combination thereof.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000054The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000028-MOS-000008<GroupDescription></GroupDescription>SRG-OS-000028-MOS-000008The mobile operating system must retain the device lock until the user reestablishes access using established identification and authentication procedures.<VulnDiscussion>The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.
A device lock is a temporary action taken when a user stops work but does not want to log out because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.
The operating system must enforce a device lock function. This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information. The identification and authentication procedure configuration must be set by a Mobile Device Management (MDM) service and be sufficiently complex to protect sensitive data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000056Configure the mobile operating system to implement the device lock function and to retain the device lock until the user reestablishes access using established identification and authentication procedures.Examine the mobile operating system to determine if it retains the device lock until the user reestablishes access using established identification and authentication procedures. If the device cannot be locked, this is a finding. If the device lock is not retained until the user reestablishes access using established identification and authentication procedures, this is a finding.SRG-OS-000029-MOS-000009<GroupDescription></GroupDescription>SRG-OS-000029-MOS-000009The mobile operating system must lock the device following a minimum, organizationally-defined period of inactivity.<VulnDiscussion>The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.
A device lock is a temporary action taken when a user stops work but does not want to shut down because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.
The operating system must lock the device after the organizationally-defined time period. This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information. A device lock mitigates the risk that an adversary can access data on an unattended mobile device but only after the minimum, organizationally-defined period of inactivity.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000057Configure the mobile operating system to lock the device after a minimum, organizationally-defined period of inactivity. Inspect the mobile operating system for the feature to device lock after an organizationally-defined period of inactivity. If the mobile operating system cannot be configured to lock the device after a specific time period or does not perform this function, this is a finding. SRG-OS-000030-MOS-000010<GroupDescription></GroupDescription>SRG-OS-000030-MOS-000010The mobile operating system must permit the user to directly initiate device lock.<VulnDiscussion>The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.
A device lock is a temporary action taken when a user stops work but does not want to log out because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.
The operating system must lock the device when the user determines it necessary (e.g., the device will temporarily be outside of the user's possession). This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000058Configure the mobile operating system to permit the user feature to directly initiate device lock.Examine the mobile operating system for the user feature to directly initiate device lock. If the mobile operating system cannot be configured for a user to directly initiate device lock, this is a finding.SRG-OS-000031-MOS-000011<GroupDescription></GroupDescription>SRG-OS-000031-MOS-000011The mobile operating system device lock, when activated on a device, must place a publicly viewable pattern onto the associated display, hiding what was previously visible on the screen.<VulnDiscussion>The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.
A device lock is a temporary action taken when a user stops work but does not want to log out because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.
The operating system must lock the device with a publicly viewable pattern visible on the associated display, hiding what was previously visible on the screen. This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information. Publicly viewable patterns can include screen saver patterns, photographic images, solid colors, or a blank screen, so long as none of those patterns convey sensitive information. Non-sensitive device information, such as battery life, signal strength, and time/date, may be viewable as part of a publically viewable pattern. However, system notifications, user or contact information must not be viewable because they may reveal owner or organizational information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000060Modify the configuration of the mobile operating system to place a publicly viewable pattern on the associated display, hiding what was previously visible on the screen when the device lock function is engaged.Review the mobile operating system for the device lock function to place a publicly viewable pattern on the associated display, hiding what was previously visible on the screen. If the mobile operating system cannot display a publicly viewable pattern on device lock, this is a finding. If the publicly viewable pattern does not hide the entire screen, this is a finding.
NOTE:
Allowable features as part of the publicly viewable patterns, so long as none of those patterns convey sensitive information, include:
- screen saver patterns
- photographic images
- solid colors (including a blank screen)
- battery life
- signal strength
- time/date
- phone number to call if found
Disallowed features as part of the publicly viewable patterns include:
- system notifications
- user or owner information (PII)
- contact list informationSRG-OS-000032-NA<GroupDescription></GroupDescription>SRG-OS-000032-NAThe operating system must employ automated mechanisms to facilitate the monitoring and control of remote access methods.<VulnDiscussion>Remote network access is accomplished by leveraging common communication protocols to establish a remote connection.
Rationale for non-applicability: When the mobile OS is performing remote access to a DoD network, remote access limitations are enforced at the enclave boundary, not on the mobile OS. In some cases, the mobile OS will support remote access of other devices to the device running the mobile OS (e.g., the personal hotspot use case, and USB tethering). SRG-OS-000229-MOS-000117 (corresponding to CCI-000370) better addresses this case. Automated mechanisms to monitor these special cases of remote access are not necessary given authentication requirements and the highly localized nature of the remote access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000067The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000033-NA<GroupDescription></GroupDescription>SRG-OS-000033-NAThe mobile operating system must use cryptography to protect the confidentiality of remote access sessions.<VulnDiscussion>Remote network access is accomplished by leveraging common communication protocols to establish a remote connection. These connections typically will occur over the public Internet.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000068The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000034-NA<GroupDescription></GroupDescription>SRG-OS-000034-NAThe operating system must monitor for unauthorized connections of mobile devices to organizational information systems.<VulnDiscussion>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, audio recording devices).
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000085The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000035-MOS-000012<GroupDescription></GroupDescription>SRG-OS-000035-MOS-000012The mobile operating system must not automatically execute applications without user direction.<VulnDiscussion>Auto execution vulnerabilities can result in malicious programs being automatically executed. Examples of information system functionality providing the capability for automatic execution of code are Auto Run and Auto Play. Auto Run and Auto Play are components of the Microsoft Windows operating system that dictate what actions the system takes when a drive is mounted. This requirement is designed to address vulnerabilities that arise when mobile devices are automatically mounted and applications are automatically invoked without user knowledge or acceptance.
Applications that can be executed without user (or mobile device management) direction may be used to access sensitive information or otherwise compromise system integrity to launch subsequent attacks. Requiring the user take action to permit the execution of an application makes it more likely that malware will be identified and kept off of mobile devices.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000087Modify the operating system configuration to disable automatic execution of applications on the device without user or mobile device management direction.Review the mobile operating system configuration to determine if automatic execution is disabled. If applications are able to execute without user or mobile device management direction, this is a finding.SRG-OS-000036-NA<GroupDescription></GroupDescription>SRG-OS-000036-NAThe operating system must employ automated mechanisms to enable authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared.<VulnDiscussion>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: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000099The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000037-MOS-000013<GroupDescription></GroupDescription>SRG-OS-000037-MOS-000013The mobile operating system must produce audit records containing the severity level of each recorded event.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Without sufficient information establishing what type of audit events occurred, investigation into the severity of events is severely hindered. As defined in RFC 5424 "The Syslog Protocol", event severity levels allow system administrators and IA personnel to more easily identify critical system issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000130Modify the audit configuration to include the severity level of events in audit records.Review the audit logs for entries for the severity level of each recorded event. If any event in the log does not have an event severity level, this is a finding.SRG-OS-000038-MOS-000014<GroupDescription></GroupDescription>SRG-OS-000038-MOS-000014The mobile operating system must produce audit records containing date and timestamps (to one second resolution) for every event.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Without sufficient information establishing when the audit events occurred, investigation into the cause of events is severely hindered. The inclusion of timestamps enables correlation of events across disparate systems, which can be critical to isolating IA incidents and developing appropriate countermeasures. Date and timestamp should be from a global time reference format to ensure geographic changes do not distort records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000131Modify the audit configuration to include timestamps for audit entries using a global time reference.Review the audit logs for timestamps with a resolution of at least one second (i.e., the entry shows the date and time to the second it occurred) using a global time reference. If any log entry does not have a timestamp with a resolution of at least one second, this is a finding.SRG-OS-000039-MOS-000015<GroupDescription></GroupDescription>SRG-OS-000039-MOS-000015The mobile operating system must include the software component (e.g., user application, or operating system security module) that generated each event in audit logs.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names 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. The inclusion of software component generating each event in the audit logs enables system administrators and IA personnel to identify where the audit events occurred.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000132Modify the audit configuration to include the software component that generated the event for each entry in the audit logs.Review the audit logs to determine if the entries include the software component that generated the event. If an entry does not provide information regarding the source of the event, this is a finding.SRG-OS-000040-NA<GroupDescription></GroupDescription>SRG-OS-000040-NAThe operating system must produce audit records containing sufficient information to establish the sources of the events.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000132, which is functionally indistinguishable from CCI-000133.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000133The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000041-MOS-000016<GroupDescription></GroupDescription>SRG-OS-000041-MOS-000016The mobile operating system must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000134Modify the audit configuration to include the outcome (success or failure) of the event.Review the audit logs for entries that contain sufficient information to establish the outcome (success or failure) of the event. If an entry does not provide information regarding the outcome of the event, this is a finding.SRG-OS-000042-MOS-NA<GroupDescription></GroupDescription>SRG-OS-000042-MOS-000017The mobile operating system must include organization defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.<VulnDiscussion>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 timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
The audit configuration must be adaptable to include organization defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. Examples of this information include VPN state, communications interface, and duration of event.
Rationale for non-applicability: The DoD value of full-text recording of privileged commands or the individual identities of group account users is written primarily for traditional OS (particularly UNIX systems) and typically does not apply in the mobility context where shell commands and group accounts might not be available. Furthermore, this requirement is adequately covered by the following three requirements:
SRG-OS-000037-MOS-000013
SRG-OS-000049-MOS-000015
SRG-OS-000041-MOS-000016
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000135The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000043-MOS-000018<GroupDescription></GroupDescription>SRG-OS-000043-MOS-000018The mobile operating system must transfer audit logs to remote log or management servers.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Centralized management of audit records and logs provides for efficiency in maintenance of records, as well as, the backup and archiving of those records. When organizations define application components that require requiring centralized audit log management, operating systems need to support the requirement.
The ability to transfer audit records from the mobile device to a remote log or management server protects their integrity and provides a centralized location to analyze their contents.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000136Configure the operating system to transfer audit logs to remote log or management servers.Verify the audit logs are being transferred from the mobile device to a remote log or management server. If audit logs are not being transferred on request or on a period schedule, this is a finding.SRG-OS-000044-MOS-000019<GroupDescription></GroupDescription>SRG-OS-000044-MOS-000019The mobile operating system must allocate sufficient audit record storage capacity for 24 hours of operation.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
It is imperative the operating system configured, allocate storage capacity to contain audit records. Without adequate storage for audit records, there is the potential that critical audit records will be lost or overwritten. An adversary may be able to take advantage of lack of audit storage capacity to avoid detection. Allocating sufficient audit record storage capacity for 24 hours allows the device to capture critical events even if it is unable to reach the MDM for a full day, such as when an employee may be temporarily in a remote location. The mobile operating system must be capable of allocating sufficient record storage capacity for mission needs. Make sure that the reserved audit capacity is greater than the log size for the day with the greatest log activity. It is advised that the allocated storage capacity be at least 150% of that needed for the most active day observed. Also use other available information resources (e.g., vendor documentation) to determine appropriate required capability based on industry norms.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000137Configure the mobile operating system to allocate sufficient audit record storage capacity for 24 hours of operation.Review the mobile operating system configuration for allocating sufficient audit record storage capacity for 24 hours of operation. The logs may need to be ported to another device to parse and measure the entries for each day. If the reserved storage for the audit records is less than indicated by these guidelines, this is a finding.SRG-OS-000045-MOS-000020<GroupDescription></GroupDescription>SRG-OS-000045-MOS-000020The mobile operating system must send alerts to the mobile device management server when the audit log size reaches an organization defined critical percentage of capacity and full capacity.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Care must be taken to evaluate that the audit records being produced do not exceed the storage capacity. Alerting the mobile device management server when audit log size thresholds are exceeded helps appropriate personnel to respond to heavy activity in a timely manner. Failure to alert increases the probability that an adversary's actions will go undetected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000138Configure the mobile operating system to send alerts to the mobile device management server when the audit log size reaches an organization defined critical percentage of capacity and full capacity.Verify the auditing system can alert the mobile device management server when the audit log size reaches an organization defined critical percentage of capacity and full capacity. If the auditing system cannot alert the mobile device management server when the audit log size reaches an organization defined critical percentage of capacity and full capacity or is not configured to do so, this is a finding.SRG-OS-000046-MOS-000021<GroupDescription></GroupDescription>SRG-OS-000046-MOS-000021The mobile operating system must alert the mobile device management server in the event of an audit processing failure.<VulnDiscussion>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.
When an audit process failure occurs, it is imperative for the mobile device management (MDM) server to be notified, which can direct this information to the appropriate person or process.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000139Configure the auditing system to alert the mobile device management server in the event of an audit processing failure.Verify the auditing system can alert the mobile device management server in the event of an audit processing failure. If the auditing system cannot alert the mobile device management server in the event of an audit processing failure or is not configured to do so, this is a finding.SRG-OS-000047-MOS-000022<GroupDescription></GroupDescription>SRG-OS-000047-MOS-000022The mobile operating system must overwrite the oldest audit log entries when audit logs reach capacity.<VulnDiscussion>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. Overwriting the oldest audit log entries is the best course of action in the context of the limited resources available on a mobile device that may not have network connectivity.
The mobile operating system must continue generating audit records while overwriting the oldest audit records in a first-in, first-out manner in the event the audit service failure was caused by the lack of audit record storage capacity. Mobile devices send event audit records to remote log or management servers. Should communications with this server be lost or the server fails, the mobile operating system must queue audit records locally until communications is restored or until the audit records are retrieved manually.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000140Configure the operating system to overwrite the oldest audit log entries when audit logs reach capacity.Review the configuration settings to determine if the audit system is configured to overwrite the oldest audit log entries when audit logs reach capacity. If this capability is not apparent from the configuration files or vendor documentation, then take action to fill the audit logs and verify the oldest entries are overwritten when the log is full. If the oldest entries are not overwritten, this is a finding.SRG-OS-000048-MOS-000023<GroupDescription></GroupDescription>SRG-OS-000048-MOS-000023The mobile operating system must provide a warning to the mobile device management server when allocated audit record storage volume reaches an organization defined percentage of maximum audit record storage capacity.<VulnDiscussion>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 that subsequently occur will not be recorded. By warning the mobile device management server that storage space for audit records has reached or exceeded the organizationally defined percentage, appropriate personnel and processes can take corrective action. The mobile operating system should also notify the user in the event intermittent network connectivity is causing the queued audit records to exceed local storage space.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000143Configure the mobile operating system to provide a warning to the mobile device management server when the audit log size reaches an organization defined percentage of maximum audit record storage capacity.Verify the auditing system can provide a warning to the mobile device management server when the audit log size reaches an organization defined percentage of maximum audit record storage capacity. If the auditing system cannot provide a warning to the mobile device management server when the audit log size reaches an organization defined percentage of maximum audit record storage capacity or is not configured to do so, this is a finding.SRG-OS-000049-MOS-000024<GroupDescription></GroupDescription>SRG-OS-000049-MOS-000024The mobile operating system must provide a real-time alert to the mobile device management server when organization defined audit failure events occur.<VulnDiscussion>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 must define audit failure events requiring an alarm. When those defined events occur, the mobile operating system must provide a real-time alert to the mobile device management server. By warning the mobile device management server that an audit failure event occurred, appropriate personnel and processes can take corrective action. The mobile operating system should also notify the user in the event intermittent network connectivity is causing the audit failure event.
Rationale for non-applicability: a Mobile Operating System does not have a persistent connection; some parts of the Operating System are not always active, and thus cannot perform real-time checks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000144The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000051-NA<GroupDescription></GroupDescription>SRG-OS-000051-NAThe operating system must support the capability to centralize the review and analysis of audit records from multiple components within the system.<VulnDiscussion>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.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000136, which deals with central log management for the remote log or management server to combine the records, not the mobile device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000154The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000052-NA<GroupDescription></GroupDescription>SRG-OS-000052-NAThe operating system must support an audit reduction capability.<VulnDiscussion>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.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000136, which covers this on central log management because log servers will perform report generation and audit reduction.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000156The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000053-NA<GroupDescription></GroupDescription>SRG-OS-000053-NAThe operating system audit records must be able to be used by a report generation capability.<VulnDiscussion>Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify a network element that has been configured improperly. In order to determine what is happening within the network infrastructure or to resolve and trace an attack, it is imperative to correlate the log data from multiple network elements to acquire a clear understanding as to what happened or is happening.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000136, which implicitly covers this on central log management because log servers will reformat log data as required to generate reports.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000157The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000054-NA<GroupDescription></GroupDescription>SRG-OS-000054-NAThe operating system must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria.<VulnDiscussion>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.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000136, which covers this on central log management because log servers will perform report generation and audit reduction.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000158The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000055-MOS-000025<GroupDescription></GroupDescription>SRG-OS-000055-MOS-000025The mobile operating system must use internal system clocks to generate timestamps for audit records.<VulnDiscussion>Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events.
Timestamps 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. The internal system clock is an acceptable source to ensure consistency of time across functions that use time to generate audit records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000159Configure the operating system to use internal system clocks to generate timestamps for audit records.Examine the mobile operating system configuration to determine if the internal system clock is used to generate timestamps for audit records. If the internal system clock is not used to generate timestamps for audit records, this is a finding.SRG-OS-000056-MOS-000026<GroupDescription></GroupDescription>SRG-OS-000056-MOS-000026The mobile operating system must synchronize the internal clock on an organizationally-defined periodic basis with an authoritative time server or the Global Positioning System.<VulnDiscussion>Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events.
Periodically synchronizing internal clocks with an authoritative time source is needed in order to correctly correlate the timing of events that occur across the enterprise. The two authoritative time sources for mobile operating systems are an authoritative time server which is synchronized with redundant United States Naval Observatory (USNO) time servers as designated for the appropriate DoD network (NIPRNet or SIPRNet) or the Global Positioning System (GPS).
Timestamps generated by the audit system in mobile operating systems 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000160Configure the mobile operating system to synchronize the internal clock on an organizationally-defined periodic basis with an authoritative time server or the Global Positioning System. Examine the mobile operating system configuration to determine if the internal clock can be synchronized on a user-defined periodic basis with an authoritative time server or the Global Positioning System. If the mobile operating system does not synchronize the internal clock on a user-defined periodic basis under normal operating conditions, this is a finding. If the mobile operating system is not synchronizing the internal clock with an authoritative time server or the GPS, this is a finding.SRG-OS-000057-MOS-000027<GroupDescription></GroupDescription>SRG-OS-000057-MOS-000027The mobile operating system must protect audit information from unauthorized read access.<VulnDiscussion>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.
To ensure the veracity of audit data the mobile operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location.
Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity. Mobile device users will need read access to audit log records for troubleshooting and all records must be sent to a remote log or management server. Audit records must be protected from unauthorized read access through device interfaces.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000162Configure the mobile operating system to protect audit information from unauthorized read access.Verify the mobile operating system protects audit information from unauthorized read access. If the mobile operating system does not protect audit information from unauthorized read access, this is a finding.SRG-OS-000058-MOS-000028<GroupDescription></GroupDescription>SRG-OS-000058-MOS-000028The mobile operating system must protect audit information from unauthorized modification.<VulnDiscussion>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.
To ensure the veracity of audit data the mobile operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location.
Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity. Mobile device users must not have modification rights to audit information and all records must be sent to a remote log or management server. Audit records must be protected from unauthorized modification access through device interfaces.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000163Configure the mobile operating system to protect audit information from unauthorized modification.Verify the mobile operating system protects audit information from unauthorized modification. If the mobile operating system does not protect audit information from unauthorized modification, this is a finding.SRG-OS-000059-MOS-000029<GroupDescription></GroupDescription>SRG-OS-000059-MOS-000029The mobile operating system must protect audit information from unauthorized deletion.<VulnDiscussion>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.
To ensure the veracity of audit data the mobile operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location.
Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity. Mobile device users must not delete audit log records and all records must be sent to a remote log or management server. Audit records must be protected from unauthorized deletion.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000164Configure the mobile operating system to protect audit information from unauthorized deletion.Verify the mobile operating system protects audit information from unauthorized deletion. If the mobile operating system does not protect audit information from unauthorized deletion, this is a finding.SRG-OS-000060-NA<GroupDescription></GroupDescription>SRG-OS-000060-NAThe operating system must produce audit records on hardware-enforced, write-once media.<VulnDiscussion>The protection of audit records from unauthorized or accidental deletion or modification requires the operating system produce audit records on hardware-enforced write-once media.
Rationale for non-applicability: Mobile devices operate outside of enclave boundary. They do not have access to hardware-based audit solutions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000165The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000061-NA<GroupDescription></GroupDescription>SRG-OS-000061-NAThe operating system must protect against an individual falsely denying having performed a particular action.<VulnDiscussion>Non-repudiation of actions taken is required in order to maintain integrity.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account, which obviates the need for non-repudiation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000166The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000062-MOS-000030<GroupDescription></GroupDescription>SRG-OS-000062-MOS-000030The mobile operating system must provide audit record generation capability for the auditable events defined at the organizational level for the mobile device.<VulnDiscussion>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) for example, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Mobile operating systems must produce audit records for the events defined at the organizational level. Specifically, at a minimum, audit records must be produced for these events:
- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) by processes other than the operating system
- Successful and unsuccessful unlock attempts
- Privileged activities or other system level access
- Starting and ending time for user access to the system
- All application initiations
- All application installation and removal
- All account creations, modifications, disabling, and terminations
- All kernel module load, unload, and restart</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000169Configure the mobile operating system for audit record generation capability for the auditable events defined at the organizational level.Examine the mobile operating system configuration to determine if audit record generation capability exists for the auditable events defined at the organizational level. If audit records generation capability does not exist for the auditable events defined at the organizational level, this is a finding.SRG-OS-000063-MOS-000031<GroupDescription></GroupDescription>SRG-OS-000063-MOS-000031The mobile operating system must allow organizational personnel through mobile device management services to select which auditable events are to be audited by the mobile operating system.<VulnDiscussion>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).
Organizations will define the organizational personal accountable for selecting auditable events. The mobile operating system must allow the designated personnel to select the items to be audited through mobile device management services.
Rationale for non-applicability: It is unnecessary for the mobile operating system to perform this function because all the necessary selections and filtering can be performed by the MDM or audit system that retrieves the logs from the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000171The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.
SRG-OS-000064-MOS-000032<GroupDescription></GroupDescription>SRG-OS-000064-MOS-000032The mobile operating system must generate audit records for the DoD-required auditable events.<VulnDiscussion>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) for example, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Mobile operating systems must produce audit records for the events defined at the organizational level. Specifically, at a minimum, audit records must be produced for these events:
- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) by processes other than the operating system
- Successful and unsuccessful unlock attempts
- Privileged activities or other system level access
- Starting and ending time for user access to the system
- All application initiations
- All application installation and removal
- All account creations, modifications, disabling, and terminations
- All kernel module load, unload, and restart</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000172The mobile operating system must generate audit records for the DoD-required auditable events.Examine the mobile operating system configuration to determine if DoD-required auditable events are generated. If the DoD-required auditable events are not generated, this is a finding.SRG-OS-000065-NA<GroupDescription></GroupDescription>SRG-OS-000065-NAThe operating system must support 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.<VulnDiscussion>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).
Rationale for non-applicability: This vulnerability is better addressed by CCI-000136, which deals with central log management. An MDM or log tool will combine the records, not the mobile device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000174The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000066-MOS-000033<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000033The mobile operating system, for PKI-based authentication must validate certificates by querying the certification authority for revocation status of the certificate.<VulnDiscussion>Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Failure to verify a certificate's revocation status can result in the system accepting a revoked or otherwise unauthorized certificate resulting in installation of unauthorized software or connection to rogue networks. Querying for certificate revocation mitigates the risk that the system will accept an unauthorized certificate.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the mobile operating system to validate certificates by querying the certification authority for revocation status of the certificate.Inspect the mobile operating system configuration for validation of certificates used for PKI-based authentication. Confirm queries to the certification authority are performed for revocation status of certificates. If queries are not performed for revocation status of certificates, this is a finding.SRG-OS-000066-MOS-000034<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000034The mobile operating system must notify the user if it cannot verify the revocation status of the certificate.<VulnDiscussion>If the user is aware that the revocation status of a certificate could not be verified, the user is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence makes it more likely that an adversary can use revoked certificates without detection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the mobile operating system to notify the user if it cannot verify the revocation status of the certificate.Inspect the mobile operating system configuration for notifying the user if it cannot verify the revocation status of the certificate. If the mobile operating system does not notify the user it cannot verify the revocation status of the certificate, this is a finding.SRG-OS-000066-MOS-000035<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000035The mobile operating system must give the user the option to deny acceptance of a certificate if it cannot verify the certificates revocation status.<VulnDiscussion>When additional assurance is required, the system should deny acceptance of a certificate if it cannot verify its revocation status. Otherwise, there is the potential that it is accepting the credentials of an unauthorized system. Allowing the operating system or user to deny certificates with unverified revocation status mitigates the risk associated with the acceptance of such certificates.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the mobile operating system to give the user the option to deny acceptance of a certificate if it cannot verify the certificate's revocation status.Inspect the mobile operating system configuration for providing the user the option to deny acceptance of a certificate if it cannot verify the certificate's revocation status. If the mobile operating system is configured to deny certificates whenever it cannot determine its revocation status without providing them an option to override the denial, this is a compliant configuration and not a finding. On the other hand, if the mobile operating system allows users to accept such certificates and if the operating system does not allow the user to reject the certificate when it cannot validate the certificate's revocation status, this is a finding.SRG-OS-000066-MOS-000036<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000036The mobile operating system must alert the user when it receives a public-key certificate issued from an untrusted certificate authority.<VulnDiscussion>If the user is aware that a certificate has been issued from an untrusted certificate authority, the user can opt not to proceed or, alternatively, is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence each time it occurs makes it more likely that an adversary can launch an attack from an untrusted system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the operating system to alert the user if it receives a public-key certificate issued from an untrusted certificate authority.Inspect the mobile operating system configuration for alerting the user when it has received a public-key certificate issued from an untrusted certificate authority. If the mobile operating system does not alert the user when it receives a certificate from an untrusted certificate authority, this is a finding.SRG-OS-000066-MOS-000037<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000037The mobile operating system must give the user the option to deny acceptance of a certificate if the certificate was issued by an untrusted certificate authority.<VulnDiscussion>When the operating system accepts the use of certificates issued from an untrusted certificate authority, there is the potential that the system presenting the certificate is malicious, and can compromise sensitive information or system integrity. Allowing the operating system or user to deny certificates from an untrusted certificate authority mitigates the risk associated with the acceptance of such certificates.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the mobile operating system to give the user the option to deny acceptance of a certificate if it from an untrusted certificate authority.Inspect the mobile operating system configuration for the user option to deny acceptance of a certificate if the certificate was issued by an untrusted certificate authority. If the operating system does not allow the user to reject a certificate issued from an untrusted certificate authority, this is a finding.SRG-OS-000066-MOS-000038<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000038The mobile operating system must alert the user if it receives an invalid public-key certificate.<VulnDiscussion>If the user is aware that a certificate is invalid, the user can opt not to proceed or, alternatively, is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence each time it occurs makes it more likely that an adversary can launch an attack from an untrusted system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the operating system to alert the user if it receives an invalid public-key certificate.Inspect the mobile operating system configuration for alerting the user when it has received an invalid public-key certificate. If the system does not alert the user when it receives an invalid public-key certificate, this is a finding.SRG-OS-000066-MOS-000039<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000039The mobile operating system must give the user the option to deny acceptance of a certificate if the mobile operating system determines that the certificate is invalid.<VulnDiscussion>If the user is aware that a certificate is invalid, the user can opt not to proceed or, alternatively, is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence makes it more likely that an adversary can launch an attack from an untrusted system. If the mobile operating system accepts the use of invalid certificates, the potential exists the system presenting the certificate is malicious, and can compromise sensitive information or system integrity. Allowing the operating system or user to deny invalid certificates mitigates the risk associated with the acceptance of such certificates.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the mobile operating system to give the user the option to deny acceptance of a certificate if the mobile operating system determines that the certificate is invalid.Inspect the mobile operating system configuration for providing the user the option to deny acceptance of a certificate if the mobile operating system determines that the certificate is invalid. If the operating system does not give the user the option to reject the certificate when it is invalid, this is a finding.SRG-OS-000066-MOS-000040<GroupDescription></GroupDescription>SRG-OS-000066-MOS-000040The mobile operating system must not accept certificate revocation information without verifying its authenticity.<VulnDiscussion>If the operating system does not verify the authenticity of revocation information, there is the potential that an authorized system is providing false information. Acceptance of the false information could result in the installation of unauthorized software or connection to rogue networks, depending on the use for which the certificate is intended. Verifying the authenticity of revocation information mitigates this risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000185Configure the operating system to not accept certificate revocation information without verifying its authenticity.Inspect the mobile operating system configuration to not accept certificate revocation information without verifying its authenticity. The system should be able to detect that the revocation status information is not authentic. If the mobile operating system does not verify the authenticity of revocation information, this is a finding.SRG-OS-000067-MOS-000041<GroupDescription></GroupDescription>SRG-OS-000067-MOS-000041The mobile operating system must require authentication to access private keys saved in the key certificate store.<VulnDiscussion>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.
Allowing unauthenticated access to private keys can enable an adversary in possession of the device to decrypt messages encrypted with the public key and to digitally sign data, thereby potentially enabling an adversary to impersonate the user in any application that uses that private key for user authentication. Requiring authentication to access keys saved in the certificate store mitigates the risk of unauthorized access. The passcode must be entered upon each access of the key store, although passcodes may be cached for a period of up to two hours.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000186Configure the mobile operating system to require authentication to access private keys saved in the key certificate store.Examine the mobile operating system for requiring authentication to access private keys saved in the key certificate store. If the mobile operating system does not require authentication to access private keys saved in the key certificate store, this is a finding.SRG-OS-000067-MOS-000042<GroupDescription></GroupDescription>SRG-OS-000067-MOS-000042The mobile operating system must enforce complexity requirements for the authentication to access private keys saved in the key certificate stores.<VulnDiscussion>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 impersonate the authorized user.
Allowing unauthenticated access to private keys can enable an adversary in possession of the device to decrypt messages encrypted with the public key and to digitally sign data, thereby potentially enabling an adversary to impersonate the user in any application that uses that private key for user authentication. Requiring complexity requirements for the authentication to access keys saved in the certificate store protects sensitive information. A weak password may enable an adversary to crack it, and give it the ability to use the private key to decrypt sensitive information or improperly impersonate the user of the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000186Configure the mobile operating system to enforce complexity requirements for the authentication to access private keys saved in the key certificate stores.Examine the mobile operating system for complexity requirements for the authentication to access private keys saved in the key certificate stores. If the mobile operating system does not enforce complexity requirements to access private keys, this is a finding.
NOTE: These complexity requirements must be met.
- 1 = minimum number of upper case alphabetic characters
- 1 = minimum number of lower case alphabetic characters
- 1 = minimum number of numeric characters
- 8 = minimum length of password
- disallow more than two sequential numbers (e.g., 456)
Other requirements may be organizationally defined.SRG-OS-000068-MOS-000043<GroupDescription></GroupDescription>SRG-OS-000068-MOS-000043The mobile operating system browser must support public-key certificate-based authentication to remote information systems.<VulnDiscussion>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. The authenticated identity must be mapped to an account for access and authorization decisions.
This capability strengthens authentication to remote information systems and thus makes it less likely that such systems will be compromised. Mobile devices without default PKI authentication capability in the browser may mitigate this through the use of authorized third-party browsers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000187Configure the operating system browser to support public-key certificate-based authentication to remote information systems.Inspect the mobile operating system configuration for a browser to support public-key certificate-based authentication to remote information systems. If the default system browser does not meet this requirement, an authorized third-party browser may be used for compliance. If no browser supports public-key certificate-based authentication to remote information systems or unauthorized browsers are used for authentication, this is a finding.SRG-OS-000069-MOS-000044<GroupDescription></GroupDescription>SRG-OS-000069-MOS-000044The mobile operating system must disallow the device unlock password from containing less than an organizationally-defined minimum number of upper case alphabetic characters.<VulnDiscussion>Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Setting minimum numbers of certain types of characters increases password complexity, and therefore makes it more difficult for an adversary to discover the password. In the DoD, the expectation is that the setting will range from a minimum of 1 to 2 upper case alphabetic characters in the device unlock password. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000192Configure the mobile operating system to prohibit the device unlock password from containing fewer than an organizationally-defined minimum number of upper case alphabetic characters. Review the mobile operating system password complexity configuration settings to determine if the device unlock password requires an organizationally-defined minimum number of upper case alphabetic characters. If password complexity configuration settings do not require the device unlock password to have this minimum number of upper case alphabetic characters, this is a finding.SRG-OS-000070-MOS-000045<GroupDescription></GroupDescription>SRG-OS-000070-MOS-000045The mobile operating system must disallow the device unlock password from containing an organizationally-defined minimum number of lower case alphabetic characters.<VulnDiscussion>Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Setting minimum numbers of certain types of characters increases password complexity, and therefore makes it more difficult for an adversary to discover the password. In the DoD, the expectation is that the setting will range from a minimum of 1 to 2 lower case characters in the device unlock password. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000193Configure the mobile operating system to disallow the device unlock password from containing fewer than an organizationally-defined minimum number of lower case alphabetic characters. Review the mobile operating system password complexity configuration settings to determine if the device unlock password requires an organizationally-defined minimum number of lower case alphabetic characters. If password complexity configuration settings do not require the device unlock password to have an organizationally-defined minimum number of lower case alphabetic characters, this is a finding.SRG-OS-000071-MOS-000046<GroupDescription></GroupDescription>SRG-OS-000071-MOS-000046The mobile operating system must disallow the device unlock password from containing an organizationally-defined minimum number of numeric characters.<VulnDiscussion>Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Setting minimum numbers of certain types of characters increases password complexity, and therefore makes it more difficult for an adversary to discover the password. In the DoD, the expectation is that the setting will range from a minimum of 1 to 2 numeric characters in the device unlock password. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000194Configure the mobile operating system to disallow the device unlock password from containing less than an organizationally-defined minimum number of numeric characters. Review the mobile operating system password complexity configuration settings to determine if the device unlock password requires an organizationally-defined minimum number of numeric characters. If password complexity configuration settings do not require the device unlock password to have an organizationally-defined minimum number of numeric characters, this is a finding.SRG-OS-000072-MOS-000047<GroupDescription></GroupDescription>SRG-OS-000072-MOS-000047The mobile operating system must force the user to change an organizationally-defined minimum number of characters of the device unlock password whenever the passcode is changed.<VulnDiscussion>If an adversary learns part or all of a password, the adversary can use this information to more easily crack a user's subsequent passwords if the passwords do not differ significantly from one to the next. Requiring a user to change a specified minimum of characters in the password is an effective way of preserving the protection provided by password complexity in this context.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000195Configure the mobile operating system to enforce an organizationally-defined minimum number of characters to be changed when the device unlock password is changed. Review the mobile operating system password complexity configuration settings to determine if the device unlock password requires an organizationally-defined minimum number of characters to be modified whenever the passcode is changed. If password complexity configuration settings do not require an organizationally-defined minimum number of characters to be changed, this is a finding.SRG-OS-000073-MOS-000048<GroupDescription></GroupDescription>SRG-OS-000073-MOS-000048The mobile operating system must encrypt passwords stored on the mobile device.<VulnDiscussion>Passwords need to be protected at all times and encryption is the standard method for protecting passwords while in storage so unauthorized users/processes cannot gain access. If an adversary obtains a password, the adversary can use it to compromise sensitive information. Encrypting passwords stored on the device mitigates the risk that the passwords will be compromised. Encryption methodologies such as secure hashing are suitable for DoD password encryption and are compliant with FIPS 140-2 security requirements. Super user access is typically required to access the password database. If a system administrator is able to obtain this level of privilege on the device, have the system administrator display the contents of the password database, often a simple file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000196Configure the mobile operating system to encrypt passwords stored on the mobile device.Verify the mobile operating system configuration enforces the passwords contained in the database are encrypted. If the passwords stored on the device are not encrypted, this is a finding.SRG-OS-000074-MOS-000049<GroupDescription></GroupDescription>SRG-OS-000074-MOS-000049The mobile operating system must not transmit passwords in clear text.<VulnDiscussion>Transmission of passwords in clear text reveals the password to any adversary who can successfully eavesdrop on the communication. In the case of wireless communication, the ability to eavesdrop is available to anyone within the range of the device's radio signal, which in some cases can be miles. Once an adversary has obtained a password, the adversary may be able to use it to compromise sensitive DoD information or other DoD information systems. Using methods that avoid the transmission of passwords in clear text mitigates the risk of this attack. The OS may be reliant on an external function or that present in the OS’ browser to enforce the password encryption function.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000197Configure the mobile operating system to prohibit transmitting passwords in clear text.Review the mobile operating system configuration to determine if it is possible to transmit passwords in clear text. If the mobile operating system transmits passwords in clear text, this is a finding.SRG-OS-000075-NA<GroupDescription></GroupDescription>SRG-OS-000075-NAThe operating system must enforce minimum password lifetime restrictions.<VulnDiscussion>Passwords need to be changed at specific policy based intervals, however if the information system or application allows the user to immediately and continually change their password then the password could be repeatedly changed in a short period of time defeating the organization's policy regarding password reuse.
Rationale for non-applicability: Risk environment for mobility does not require minimum password age in the field.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000198The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000076-NA<GroupDescription></GroupDescription>SRG-OS-000076-NAThe operating system must enforce maximum password lifetime restrictions.<VulnDiscussion>Passwords need to be changed at specific policy based intervals. Any password no matter how complex can eventually be cracked.
Rationale for non-applicability: Changing passwords regularly prevents an attacker who has compromised the password from re-using it to regain access. This is an unlikely scenario on a mobile device because these devices do not have a remote logon capability that would facilitate either stealth use of the device or a brute force or dictionary password attack. Wiping the device after 10 unsuccessful logon attempts mitigates the risk of a password attack more effectively than a password rotation scheme. Additionally, NSA guidance for CMDs no longer requires password aging and password history settings. NSA guidance for CMDs no longer requires password aging and password history settings.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000199Configure the mobile operating system to have an organizationally-defined maximum lifetime for the device unlock password. Review the mobile operating system configuration for an organizationally-defined maximum password age setting. If the mobile device does not contain or access sensitive or classified information, this requirement does not apply. If the mobile operating system does not enforce an organizationally-defined maximum password age, this is a finding.
NOTE: The IA control only needs to be enforced in product level STIGs if there is a need for such rotation based on the expected operational use of the device.
SRG-OS-000077-NA<GroupDescription></GroupDescription>SRG-OS-000077-NAThe operating system must prohibit password reuse for the organization-defined number of generations.<VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute force attacks. The mobile operating system must prohibit a user from reusing any of the last five previously used device unlock passwords.
Rationale for non-applicability: Changing passwords regularly prevents an attacker who has compromised the password from re-using it to regain access. This is an unlikely scenario on a mobile device because these devices do not have a remote logon capability that would facilitate either stealth use of the device or a brute force or dictionary password attack. Wiping the device after 10 unsuccessful logon attempts mitigates the risk of a password attack far more effectively than a password rotation scheme. Additionally, NSA guidance for CMDs no longer requires password aging and password history settings. NSA guidance for CMDs no longer requires password aging and password history settings.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000200Configure the mobile operating system to prohibit a user from reusing an organizationally-defined number of previously used device unlock passwords. Review the mobile operating system configuration for prohibiting a user from reusing any of the last five previously used device unlock passwords. If the mobile operating system allows a user from reusing an organizationally-defined number of previously used device unlock passwords, this is a finding.SRG-OS-000078-MOS-000052<GroupDescription></GroupDescription>SRG-OS-000078-MOS-000052The mobile operating system must enforce a minimum length for the device unlock password.<VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute force attacks. The ability to crack a password is a function of how many attempts an adversary is permitted, how quickly an adversary can do each attempt, and the size of the password space. The longer the minimum length of the password is, the larger the password space.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000205Configure the mobile operating system to enforce a minimum length for the device unlock password. Where a security container application is used in lieu of mobile operating system protections, configure the security container application to enforce a minimum length password for entry into the application. Review the mobile operating system configuration to determine if the device enforces a minimum length for the device unlock password. For device unlock on mobile operating systems with no access to sensitive or classified information, the requirement is a minimum of 4 numbers. For access mobile devices with sensitive information, the minimum length is 8. If the mobile device places sensitive information or security functions in “security container” applications only, then a compliant configuration is to require a 8-character or longer password to enter the container application, and a 4-digit or longer password to unlock the device. If the device does not enforce a minimum length for the device unlock password or, where applicable, the security container, this is a finding.SRG-OS-000080-NA<GroupDescription></GroupDescription>SRG-OS-000080-NAThe operating system must enforce approved authorizations for logical access to the system in accordance with applicable policy.<VulnDiscussion>Strong access controls are critical to securing data. 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) must be employed by the operating system when applicable to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the operating system.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000213The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000081-NA<GroupDescription></GroupDescription>SRG-OS-000081-NAThe operating system, when transferring information between different security domains, must identify information flows by data type specification and usage.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000218The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000082-NA<GroupDescription></GroupDescription>SRG-OS-000082-NAThe operating system, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000219The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000083-NA<GroupDescription></GroupDescription>SRG-OS-000083-NAThe operating system must enforce security policies regarding information on interconnected systems.<VulnDiscussion>The operating system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000221The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000084-MOS-000054<GroupDescription></GroupDescription>SRG-OS-000084-MOS-000054The mobile operating system must notify mobile device management services of certificate failures related to digital signatures on software applications or components.<VulnDiscussion>A certificate failure related to a digital signature on software applications or components is strong evidence of a system breach. Notifying mobile device management services of such an occurrence allows the enterprise to assess the situation, contain the breach if one exists, and possibly invoke incident response procedures.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000223Configure the mobile operating system to notify mobile device management services of certificate failures related to digital signatures on software applications or components.Review the mobile operating system configuration for notification of certificate failures related to digital signatures on software applications or components to mobile device management services. If the mobile operating system does not notify the mobile device management services of certificate failures related to digital signatures on software applications or components, this is a finding.SRG-OS-000085-MOS-000055<GroupDescription></GroupDescription>SRG-OS-000085-MOS-000055The mobile operating system must notify the user of certificate failures related to digital signatures on software applications or components.<VulnDiscussion>A certificate failure related to a digital signature on software applications or components is strong evidence of a system breach. Notifying the user of such an occurrence allows the user to notify the user's technical support personnel and IAO, as well as proceed with caution regarding activities performed on the device. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000224Configure the mobile operating system to notify the user of certificate failures related to digital signatures on software applications or components.Review the mobile operating system configuration for notification of certificate failures related to digital signatures on software applications or components to the user. If the mobile operating system does not notify the user of certificate failures related to digital signatures on software applications or components, this is a finding.SRG-OS-000086-NA<GroupDescription></GroupDescription>SRG-OS-000086-NAThe operating system must provide the capability for a privileged administrator to configure organization defined security policy filters to support different security policies.<VulnDiscussion>In order to control changes in policy, a privileged administrator must be able to change policy filters to support different security policies.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000370, which deals with central management of security settings.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000226The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000087-MOS-000056<GroupDescription></GroupDescription>SRG-OS-000087-MOS-000056The mobile operating system must provide mutual authentication between the provisioning server and the provisioned device during a trusted over-the-air (OTA) provisioning session.<VulnDiscussion>Provisioning data includes operating system configuration, key material, and other initialization data. It may be sensitive and therefore must be adequately protected. An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place. Proper use of cryptography provides strong assurance that provisioning data is protected against confidentiality attacks.
When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system. Mutual authentication ensures both that the device is authorized for provisioning and that a rogue provisioning server is not used to obtain software. In this context, provisioning refers to configuration elements specific to the organization and user, and not installation of the base mobile OS. One way to ensure authentication of the server is to require that the MOS point to a specified URL for the provisioning process, and authenticate the URL-specified server using SSL/TLS.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000345Configure the mobile operating system to mutually authenticate between the provisioning server and the provisioned device during a trusted over-the-air (OTA) provisioning session and prior to accepting provisioned software.Review system documentation and operating system configuration to determine if there is mutual authentication between the provisioning server and the provisioned device. If additional assurance is required, validate the provisioning server will not provision software and data to an unauthorized device and that an authorized device will not connect to an unauthorized provisioning server (e.g., a valid provisioning server with its credentials temporarily removed for the test). If either the device does not authenticate the provisioning infrastructure, or vice versa, this is a finding.SRG-OS-000087-MOS-000057<GroupDescription></GroupDescription>SRG-OS-000087-MOS-000057The mobile operating system must protect the confidentiality of the provisioning data while downloading to the mobile device during a trusted over-the-air (OTA) provisioning session.<VulnDiscussion>Provisioning data includes operating system configuration, key material, and other initialization data. It may be sensitive and therefore must be adequately protected. An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place.
An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place. Proper use of cryptography provides strong assurance that provisioning data is protected against confidentiality attacks.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000345Configure the operating system to use cryptography providing confidentiality for provisioning downloads.Review system documentation and operating system configuration to determine if there is appropriate cryptography protecting the confidentiality of OTA provisioning. If the provisioning data is not protected by cryptographic means during an OTA provisioning procedure, this is a finding.SRG-OS-000087-MOS-000058<GroupDescription></GroupDescription>SRG-OS-000087-MOS-000058The mobile operating system must protect the integrity of the provisioning data while downloading to the mobile device during a trusted over-the-air (OTA) provisioning session.<VulnDiscussion>Provisioning data includes operating system configuration, key material, and other initialization data. It may be sensitive and therefore must be adequately protected. An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place.
It may be possible for an adversary within the general proximity of the mobile device to hijack provisioning sessions and modify data transmitted during the provisioning process. Proper use of cryptography provides strong assurance that provisioning data is protected against integrity attacks.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000345Configure the operating system to use cryptography providing integrity for provisioning downloads.Review system documentation and operating system configuration to determine if there are appropriate integrity mechanisms protecting the confidentiality of OTA provisioning. Appropriate integrity mechanisms generally involve the use of FIPS validated cryptographic modules implementing algorithms that provide integrity services. If there are no such mechanisms present, this is a finding.SRG-OS-000087-MOS-000059<GroupDescription></GroupDescription>SRG-OS-000087-MOS-000059The mobile operating system must support the capability for the system administrator to disable over-the-air (OTA) provisioning.<VulnDiscussion>In some environments, the risk of OTA provisioning may outweigh any convenience benefit it offers. In such cases, the administrator should have the ability to disable OTA provisioning to ensure security breaches do not occur from use of this technique.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000345Configure the mobile operating system permit the system administrator to disable over-the-air (OTA) provisioning.Review system documentation and operating system configuration to determine if the system administrator has the ability to disable OTA provisioning. If the operating system does not support OTA provisioning, this also meets the requirement. If the operating system supports OTA but there is no means for the SA to disable that capability, this is a finding.SRG-OS-000088-NA<GroupDescription></GroupDescription>SRG-OS-000088-NAThe operating system must employ automated mechanisms to enforce access restrictions.<VulnDiscussion>When dealing with access restrictions pertaining to change control, it should be noted that, 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.
Rationale for non-applicability: This vulnerability is better addressed by implementing CCI-000370, which states the mobile operating system must employ the capability of a Mobile Device Manager (MDM) to centrally manage configuration settings, including security policies. These security policies include policy related to discretionary access controls.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000346The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000089-NA<GroupDescription></GroupDescription>SRG-OS-000089-NAThe operating system must employ automated mechanisms to support auditing of the enforcement actions.<VulnDiscussion>Some operating system features, including security enforcement, may only be modified when the operating system is not running. Logging startup events provides valuable information on system problems and potential OS integrity issues.
Rationale for non-applicability: This IA control requirement is better addressed by CCI-000172, which includes audit functionality related to configuration management.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000347The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000090-MOS-000060<GroupDescription></GroupDescription>SRG-OS-000090-MOS-000060The mobile operating system must prevent the installation of applications that are not digitally signed with a DoD approved private key.<VulnDiscussion>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. Digital signatures on code provide assurance that the code comes from a known source and has not been modified.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000352Configure the operating system to prevent the installation of applications that are not digitally signed with a DoD approved private key.Review the mobile operating system configuration for preventing installation of applications that are not digitally signed with a DoD approved private key. If the mobile operating system does not prevent the installation of applications that are not digitally signed with a DoD approved private key, this is a finding.SRG-OS-000091-NA<GroupDescription></GroupDescription>SRG-OS-000091-NAThe operating system must enforce a two-person rule for changes to organization defined information system components and system-level information.<VulnDiscussion>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 operating system can potentially have significant effects on the overall security of the system.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. In this context, a two-person rule is not relevant. Changes resulting from MDM control of the device are within the scope of the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000354The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000092-NA<GroupDescription></GroupDescription>SRG-OS-000092-NAThe operating system must employ automated mechanisms to centrally apply configuration settings.<VulnDiscussion>Configuration settings are the configurable security-related parameters of operating system.
Rationale for non-applicability: This vulnerability is better addressed by implementing CCI-000370, which states the mobile operating system must employ the capability of a Mobile Device Manager (MDM) to centrally manage configuration settings, including security policies. These security policies include policy related to discretionary access controls.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000371The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000093-NA<GroupDescription></GroupDescription>SRG-OS-000093-NAThe operating system must employ automated mechanisms to centrally verify configuration settings.<VulnDiscussion>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.
Rationale for non-applicability: This vulnerability is better addressed by implementing CCI-000370, which states the mobile operating system must employ the capability of a Mobile Device Manager (MDM) to centrally manage configuration settings, including security policies. These security policies include policy related to discretionary access controls.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000372The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000094-NA<GroupDescription></GroupDescription>SRG-OS-000094-NAThe operating system must employ automated mechanisms to respond to unauthorized changes to organization defined configuration settings.<VulnDiscussion>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.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001297, which addresses responding to unauthorized changes to software and data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000374The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000095-MOS-000061<GroupDescription></GroupDescription>SRG-OS-000095-MOS-000061The mobile operating system must not permit a user to remove organizationally required applications.<VulnDiscussion>Organizationally required applications are present on the device because they support the organization's mission. Therefore, their absence degrades mission performance. Preventing the removal of such applications provides mission assurance. The primary focus of this control concerns IA applications that monitor the integrity of software on the mobile device and enforce configuration controls. Removal of these applications would significantly degrade the IA posture of the device. Therefore, not permitting a user to remove them is critical to IA. In cases in which such applications cannot be removed, an acceptable alternative to mitigate risk is to prevent access to DoD resources when the required applications are not present.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000381Configure the operating system to prevent users from removing organizationally required applications or configure the operating system to disable access to DoD information resources when such applications are removed.Review the mobile operating system configuration to determine if the operating system permits a user to remove organizationally required applications. Identify the list of organizationally required applications and attempt to delete a sample of them to determine if the control is being enforced. If it is possible to remove the application, check that the removal disables access to DoD information resources. If a required application can be removed by a user or if removal does not disable further access to DoD resources, this is a finding.SRG-OS-000095-MOS-000062<GroupDescription></GroupDescription>SRG-OS-000095-MOS-000062The mobile operating system must not permit mobile service carriers to have privileged access to the operating system or perform any function not directed by the user.<VulnDiscussion>Permitting mobile service carriers access to the mobile operating system leaves the device vulnerable to breach from rogue elements within the carrier infrastructure. Mobile service carriers are not subject to the same personnel, operational, and technical controls as DoD organizations. For example, its employees in most cases do not have active DoD clearances. When a mobile service carrier must update software or configuration on a mobile device, these updates must come from a DoD approved source, which in many cases is the vendor of the MOS software. Preventing mobile service carrier access to mobile operating systems greatly mitigates the risk associated with this vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000381Configure the mobile operating system to disallow mobile service carrier access to the device.Review MOS documentation, IA information resources, and mobile service contracts to determine if the mobile service carrier requires or expects privileged access to the mobile operating system or any other access that is not directed by the user. If such access is present, this is a finding.SRG-OS-000096-NA<GroupDescription></GroupDescription>SRG-OS-000096-NAThe operating system must configure the information system to specifically prohibit or restrict the use of organization defined functions, ports, protocols, and/or services.<VulnDiscussion>Operating 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) or may present unacceptable risk into the information system environment.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001118, which refers to mobile device boundary protection, specifically with respect to the filtering of inbound and outbound traffic based on IP address and UDP/TCP port.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000382The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000097-MOS-000063<GroupDescription></GroupDescription>SRG-OS-000097-MOS-000063The mobile operating system must verify the integrity of application software before each instance of its execution.<VulnDiscussion>A common method to compromise system security is to modify application software to perform malicious functions that will execute when the user runs the application. Verifying the integrity of the software before execution protects against such an attack. This is typically accomplished by checking cryptographic hashes or digital signatures on software program files.
Rationale for non-applicability: the feature as described is more suited for a Mobile Device Manager (MDM) to implement as opposed to an OS. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000386Configure the mobile operating system to verify the integrity of application software before each instance of its execution.Review the mobile operating system configuration for the operating system to verify the integrity of program software before each instance of its execution. If the mobile operating system does not perform the verification, this is a finding.SRG-OS-000098-MOS-000064<GroupDescription></GroupDescription>SRG-OS-000098-MOS-000064The mobile operating system must detect the addition of unauthorized hardware components and peripherals at start up and when they are attached.<VulnDiscussion>Unauthorized hardware components and peripherals include memory cards, SIM cards, and USB attachments. If the user or an adversary is able to add or attach unauthorized components to a device, then those components may be used to compromise other components or perform prohibited functions. The addition of the unauthorized component may also cause the system to behave in unintended ways, perhaps degrading the performance of mission-critical applications. Detecting the addition of unauthorized components allows for roll-back to the previous state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000416Remove unauthorized components and configure the mobile operating system to detect the addition of unauthorized hardware components and peripherals at start up and when they are attached.Inspect the mobile operating system configuration to detect the addition of unauthorized hardware components and peripherals at start up and when they are attached. If the mobile operating system does not detect unauthorized hardware components or peripherals, this is a finding.SRG-OS-000099-NA<GroupDescription></GroupDescription>SRG-OS-000099-NAThe operating system must conduct backups of user-level information contained in the operating system per organization defined frequency to conduct backups consistent with recovery time and recovery point objectives.<VulnDiscussion>Operating system backup is a critical step in maintaining data assurance and availability.
Rationale for non-applicability: Similar to user workstations and laptops, mobile devices are not expected to have backup of user-level data. On some mobile OS, backup is infeasible for anything other than shared data because applications are not permitted to access the data of other applications. Applications that require backup can include backup functionality within the application or use cloud-based storages solutions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000535The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000100-NA<GroupDescription></GroupDescription>SRG-OS-000100-NAThe operating system must conduct backups of system-level information contained in the information system per organization defined frequency to conduct backups that are consistent with recovery time and recovery point objectives.<VulnDiscussion>Operating system backup is a critical step in maintaining data assurance and availability.
Rationale for non-applicability: Mobile devices do not have assured network connectivity. This type of documentation is readily available elsewhere.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000537The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000101-NA<GroupDescription></GroupDescription>SRG-OS-000101-NAThe operating system must conduct backups of operating system documentation including security-related documentation per organization defined frequency to conduct backups that is consistent with recovery time and recovery point objectives.<VulnDiscussion>Operating system backup is a critical step in maintaining data assurance and availability.
Rationale for non-applicability: Mobile devices do not have assured network connectivity. This type of documentation is readily available elsewhere.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000539The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000102-NA<GroupDescription></GroupDescription>SRG-OS-000102-NAThe operating system must implement transaction recovery for transaction-based systems.<VulnDiscussion>Recovery and reconstitution constitutes executing an operating system contingency plan comprised of activities to restore essential missions and business functions.
Rationale for non-applicability: A mobile OS typically is not transaction based.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000553The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000103-MOS-000065<GroupDescription></GroupDescription>SRG-OS-000103-MOS-000065The mobile operating system must prevent a user from installing unapproved applications.<VulnDiscussion>The operating system must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization. The installation and execution of unauthorized software on an operating system may allow the application to obtain sensitive information or further compromise the system. Preventing a user from installing unapproved applications mitigates this risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000663Configure the mobile operating system to prevent a user from installing unapproved applications.Review the mobile operating system configuration to determine if controls prevent a user from installing unapproved applications. If controls are not present to prevent a user from installing unapproved applications, this is a finding.SRG-OS-000103-MOS-000066<GroupDescription></GroupDescription>SRG-OS-000103-MOS-000066The mobile operating system must only permit download of software from a DoD approved source (e.g., DoD operated mobile device application store or MDM server).<VulnDiscussion>The mobile operating system must only permit download of software from a DoD approved source (e.g., DoD operated mobile device application store or MDM server).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000663Configure the operating system so it only permits download of software from a DoD approved source.Examine the mobile operating system configuration for it to only permit download of software from a DoD approved source. If the mobile operating system allows download of software from unapproved sources, this is a finding. If the mobile operating system is configured to restrict the source of software but still allows download from an unapproved site, this is a finding.SRG-OS-000104-NA<GroupDescription></GroupDescription>SRG-OS-000104-NAThe operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users).<VulnDiscussion>To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. In this context, there is no need to uniquely identify the user. Unique identification of application processes is inherent in other IA controls for application sandboxing under CCI-000022.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000764The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000106-NA<GroupDescription></GroupDescription>SRG-OS-000106-NAThe operating system must use multifactor authentication for network access to non-privileged accounts.<VulnDiscussion>Multifactor authentication is defined as using two or more factors to achieve authentication.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000766The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000107-NA<GroupDescription></GroupDescription>SRG-OS-000107-NAThe operating system must use multifactor authentication for local access to privileged accounts.<VulnDiscussion>Multifactor authentication is defined as using two or more factors to achieve authentication.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000767The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000108-NA<GroupDescription></GroupDescription>SRG-OS-000108-NAThe operating system must use multifactor authentication for local access to non-privileged accounts.<VulnDiscussion>Multifactor authentication is defined as using two or more factors to achieve authentication.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000768The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000109-NA<GroupDescription></GroupDescription>SRG-OS-000109-NAThe operating system must require individuals to be authenticated with an individual authenticator prior to using a group authenticator.<VulnDiscussion>To assure individual accountability and prevent unauthorized access, organizational users shall be individually identified and authenticated.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. In this context, the user would not have to use a group authenticator. This lone device user would not have pertinent organizational context on the device itself.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000770The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000110-NA<GroupDescription></GroupDescription>SRG-OS-000110-NAThe operating system must use multifactor authentication for network access to privileged accounts where one of the factors is provided by a device separate from the information system being accessed.<VulnDiscussion>Multifactor authentication is defined as using two or more factors to achieve authentication.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system does not support remote network access to the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000771The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000111-NA<GroupDescription></GroupDescription>SRG-OS-000111-NAThe operating system must use multifactor authentication for network access to non-privileged accounts where one of the factors is provided by a device separate from the operating system being accessed.<VulnDiscussion>Multifactor authentication is defined as using two or more factors to achieve authentication.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system does not support remote network access to the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000772The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000112-NA<GroupDescription></GroupDescription>SRG-OS-000112-NAThe operating system must use organization defined replay-resistant authentication mechanisms for network access to privileged accounts.<VulnDiscussion>An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000774The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000113-NA<GroupDescription></GroupDescription>SRG-OS-000113-NAThe operating system must use organization defined replay-resistant authentication mechanisms for network access to non-privileged accounts.<VulnDiscussion>An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000776The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000114-MOS-000067<GroupDescription></GroupDescription>SRG-OS-000114-MOS-000067The mobile operating systems Bluetooth module must enforce pairing using a randomly generated passkey size of at least 6 digits.<VulnDiscussion>When done properly, Bluetooth pairing prevents rogue devices from communicating with the operating system. If a rogue device is paired with the mobile device, then there is the potential for the rogue device to obtain sensitive information. Short passkeys make the pairing process vulnerable to brute force attacks. The use of known fixed passkeys makes the device even more vulnerable. The use of Bluetooth 2.1EDR or later technology greatly mitigates the risk of this attack because it relies on certificates in addition to the PIN to generate a secure pairing key. If device pairing is accomplished with a randomly generated 6-digit passkey, this greatly mitigates the risk of unauthorized pairing in all cases.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000778Configure the operating system to support Bluetooth passkeys of at least 6 digits.Review the mobile operating system configuration to determine if the Bluetooth stack enforces passkeys of 6 digits or more. If greater assurance is required, attempt to pair the device with another Bluetooth device using an 6 digit passkey. If the Bluetooth stack does not enforce pairing using a randomly generated passkey size of at least 6 digits, this is a finding.SRG-OS-000114-MOS-000068<GroupDescription></GroupDescription>SRG-OS-000114-MOS-000068The mobile operating systems Bluetooth module must not permit any data transfer between devices prior to Bluetooth mutual authentication.<VulnDiscussion>Bluetooth mutual authentication provides assurance that both the mobile device and Bluetooth peripheral are legitimate. If the authentication does not occur immediately before permitting a network connection, there is the potential for a man-in-the-middle attack in which a third device intercepts the traffic between the two legitimate devices. Mutual authentication prevents this from occurring.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000778Configure the operating system's Bluetooth stack to prohibit data transfer between devices prior to Bluetooth mutual authentication.The local Bluetooth stack either supports this functionality or it does not. Review the system documentation to determine if the functionality is supported. If the Bluetooth stack permits any data transfer between devices prior to Bluetooth mutual authentication, this is a finding.SRG-OS-000115-NA<GroupDescription></GroupDescription>SRG-OS-000115-NAThe operating system must authenticate devices before establishing remote network connections using bidirectional cryptographically based authentication between devices.<VulnDiscussion>Device authentication is a solution enabling an organization to manage devices.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000780, which is very similar but directly addresses wireless devices.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000779The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000116-MOS-000069<GroupDescription></GroupDescription>SRG-OS-000116-MOS-000069The mobile operating systems Wi-Fi module must be WPA2 certified (enterprise and personal).<VulnDiscussion>WPA2 is a Wi-Fi certification managed by the Wi-Fi Alliance, a trade association promoting technology based on the IEEE 802.11 communications standard. A product that has received WPA2 certification has demonstrated that it is compliant with the 802.11i amendment defining robust security networks. Products that have not received this certification are significantly more likely to have vulnerabilities associated with user and device authentication and the confidentiality and integrity of user data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-000780Configure the mobile operating system's Wi-Fi module to use a WPA2 certified (enterprise and personal) version.Review the mobile operating system configuration for the Wi-Fi module to be WPA2 certified. If the Wi-Fi module is not WPA2 certified for both enterprise and personal, this is a finding.SRG-OS-000116-MOS-000070<GroupDescription></GroupDescription>SRG-OS-000116-MOS-000070The mobile operating systems Wi-Fi module must use EAP-TLS authentication when authenticating to DoD WLAN authentication servers.<VulnDiscussion>Without strong mutual authentication a mobile device may connect to an unauthorized network. In many cases, the user may falsely believe that the device is connected to an authorized network and then provide authentication credentials and other sensitive information. EAP-TLS is strong mutual authentication leveraging a public key infrastructure. Its use greatly mitigates risk associated with authentication transactions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-000780Configure the mobile operating system's Wi-Fi module to use EAP-TLS authentication when authenticating to DoD WLAN authentication servers.Verify the mobile operating system configuration supports EAP-TLS. Support for non-TLS authentication methods, such as EAP-PEAP or EAP-SIM, does not meet the requirement. If the operating system does not support EAP-TLS when authenticating to DoD WLAN authentication servers, this is a finding.SRG-OS-000116-MOS-000071<GroupDescription></GroupDescription>SRG-OS-000116-MOS-000071The mobile operating system must authenticate devices before establishing remote network (e.g., VPN) connections using bidirectional cryptographically based authentication between devices.<VulnDiscussion>Without strong mutual authentication a mobile device may connect to an unauthorized network. In many cases, the user may falsely believe that the device is connected to an authorized network and then provide authentication credentials and other sensitive information. A strong bidirectional cryptographically based authentication method mitigates this risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-000780Configure the operating system to authenticate devices before establishing remote connections.Identify the network interfaces over which authentication may occur. For each of these, review the system documentation and operating system configuration to determine if the device authenticates devices prior to establishing a network connection. Note: This requirement also applies to a private VPN connection from the carrier's network to the DoD network that is designed to route all mobile device traffic directly to the DoD network. If the operating system does not perform this authentication, this is a finding.SRG-OS-000116-MOS-000072<GroupDescription></GroupDescription>SRG-OS-000116-MOS-000072The mobile operating system and mobile device management services must mutually authenticate each other using bi-directional PKI-based cryptographic authentication methods.<VulnDiscussion>Without strong mutual (bi-directional) authentication a mobile device may connect to an unauthorized mobile device management (MDM) server and obtain improper security policies or configuration commands from that server. This could, in turn, make the device vulnerable to a wide variety of other attacks that could reveal sensitive information and enable an adversary to obtain full control of the device. Cryptographic mutual authentication greatly mitigates this risk. Shared secret methods are an acceptable alternative to PKI-based authentication. The authentication need not be performed synchronously, but methods using asynchronous messages must still employ mutual authentication. For example, the MDM may digitally sign a configuration message encrypted with the mobile device's public key. This would, in effect, authenticate the mobile device because no other device would be able to access the configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-000780Configure the mobile operating system to require mutual authentication with mobile device management services using bi-directional PKI-based cryptographic authentication methods.Review system documentation and operating system configuration to determine if there is mutual authentication between the device and the mobile device management services. Both certificate-based and shared secret methods are acceptable. If there is not cryptographic mutual authentication, this is a finding.SRG-OS-000116-MOS-000073<GroupDescription></GroupDescription>SRG-OS-000116-MOS-000073The mobile operating system VPN client must employ DoD PKI approved mechanisms for authentication when connecting to DoD networks.<VulnDiscussion>VPNs are vulnerable to attack if they are not supported by strong authentication. An adversary may be able gain access to network resources and sensitive information if they can compromise the authentication process. Common Access Card (CAC) authentication is a strong cryptographic two-factor authentication that greatly mitigates the risk of VPN authentication breaches. Other DoD approved PKI mechanisms provide similar levels of assurance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-000780Configure the mobile operating system VPN client to employ DoD PKI approved mechanisms for authentication when connecting to DoD networks.Examine the mobile operating system VPN client for employing DoD approved PKI mechanisms for authentication when connecting to DoD networks and servers. Note: This requirement also applies to a private VPN connection from the carrier's network to the DoD network that is designed to route all mobile device traffic directly to the DoD network. If the VPN client does not require DoD approved PKI for authentication, this is a finding. SRG-OS-000117-NA<GroupDescription></GroupDescription>SRG-OS-000117-NAThe operating system must authenticate devices before establishing network connections using bidirectional cryptographically based authentication between devices.<VulnDiscussion>Device authentication is a solution enabling an organization to manage both users and devices.
Rationale for non-applicability: This vulnerability is better addressed by CCI-000780, which directly relates to wireless technology.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000781The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000118-NA<GroupDescription></GroupDescription>SRG-OS-000118-NAThe operating system must manage information system identifiers for users and devices by disabling the user identifier after an organization defined time period of inactivity.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account, whose identifier would never be disabled. Some mobile operating systems also assign identifiers to applications, in which case there is a similar need for persistence regardless of usage patterns.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000795The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000119-NA<GroupDescription></GroupDescription>SRG-OS-000119-NAThe operating system must dynamically manage identifiers, attributes, and associated access authorizations.<VulnDiscussion>Dynamic management 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: NIST SP 800-53 IA-4 states that this control applies when service-oriented architectures establish identities at run time for entities that were previously unknown. Per the scope of the MOS SRG, mobile devices do not provide services to remote users and therefore do not provide identities for unknown entities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000802The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000120-NA<GroupDescription></GroupDescription>SRG-OS-000120-NAThe operating system must use mechanisms for authentication to a cryptographic module meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.<VulnDiscussion>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.
Rationale for non-applicability: This IA control is better addressed by CCI-001141 and CCI-001145, which focus on FIPS and NSA requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000803The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000121-NA<GroupDescription></GroupDescription>SRG-OS-000121-NAThe operating system must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).<VulnDiscussion>Non-organizational users include all operating system users other than organizational users which include employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations).
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. The only process acting on behalf of a non-organizational user would be one of the carrier or OS vendor. In this case, CCI-00877 addresses the requirement for authentication of such processes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000804The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000122-NA<GroupDescription></GroupDescription>SRG-OS-000122-NAThe operating system must implement a configurable capability to automatically disable the operating system if any of the organization defined lists of security violations are detected.<VulnDiscussion>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 such an action is warranted.
Rationale for non-applicability: This CCI is not appropriate for a mobile device. Automatic disabling of devices poses a safety risk to mobile users who may have no other means of communication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000831The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000123-NA<GroupDescription></GroupDescription>SRG-OS-000123-NAThe operating system must automatically terminate emergency accounts after an organization defined time period for each type of account.<VulnDiscussion>When emergency accounts are created, there is a risk that the emergency account may remain in place and active after the need for the account no longer exists. To address this, in the event emergency accounts are required, accounts that are designated as temporary in nature must be automatically terminated after an organization defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Therefore, additional user accounts are not created for system administrators in emergencies.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001682The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000124-NA<GroupDescription></GroupDescription>SRG-OS-000124-NAThe operating system must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only.<VulnDiscussion>The intent of this control is to address the security-related issues arising from the software brought into the operating system specifically for diagnostic and repair actions (e.g., a software packet sniffer introduced for the purpose of a particular maintenance activity).
Rationale for non-applicability: A mobile operating system typically does not have local audit or maintenance tools. The IA control corresponding to CCI-001803 addresses restricting users from performing system management functions. In many cases, diagnostic tools on mobile devices are accessible to anyone in possession of the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000872The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000125-NA<GroupDescription></GroupDescription>SRG-OS-000125-NAThe operating system must employ strong identification and authentication techniques in the establishment of non-local maintenance and diagnostic sessions.<VulnDiscussion>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.
Rationale for non-applicability: A general assumption of the MOS SRG is that the MOS must not support non-local maintenance and diagnostic sessions. Therefore, this control is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000877The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000126-NA<GroupDescription></GroupDescription>SRG-OS-000126-NAThe operating system must terminate all sessions and network connections when non-local maintenance is completed.<VulnDiscussion>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.
Rationale for non-applicability: A general assumption of the MOS SRG is that the MOS must not support non-local maintenance and diagnostic sessions. Therefore, this control is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000879The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000127-NA<GroupDescription></GroupDescription>SRG-OS-000127-NAThe operating system must audit non-local maintenance and diagnostic sessions.<VulnDiscussion>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, in order to conduct system diagnostics.
Rationale for non-applicability: A general assumption of the MOS SRG is that the MOS must not support non-local maintenance and diagnostic sessions. Therefore, this control is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000880The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000128-NA<GroupDescription></GroupDescription>SRG-OS-000128-NAThe operating system must protect non-local maintenance sessions through the use of a strong authenticator tightly bound to the user.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. "Maintenance" is typically automated and is not associated with a human user account. Additionally, the IA control corresponding to CCI-000877 more clearly articulates the intent of this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000884The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000129-NA<GroupDescription></GroupDescription>SRG-OS-000129-NAThe operating system must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.<VulnDiscussion>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. To protect the integrity and confidentiality of non-local maintenance and diagnostics, all packets associated with these sessions must be encrypted.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. "Maintenance" is typically automated and is not associated with a human user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000888The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000130-MOS-000074<GroupDescription></GroupDescription>SRG-OS-000130-MOS-000074The mobile operating system must cryptographically bind the removable media to the mobile device so data stored on the removable media can only be read by that mobile device.<VulnDiscussion>When data is written to portable digital media, such as thumb drives, floppy diskettes, compact disks, and magnetic tape, etc., there is risk of data loss. Cryptographically binding the removable media to the mobile device renders the media useless when it is separated from the device. This greatly reduces the risk associated with removable media.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001009Configure the mobile operating system to cryptographically bind the removable media to the mobile device so data stored on the removable media can only be read by that mobile device.Review the mobile operating system configuration to determine if removable media is cryptographically bound to the mobile device so data stored on the removable media can only be read by that mobile device. If the removable media is not bound or can be read on other devices, this is a finding.SRG-OS-000131-NA<GroupDescription></GroupDescription>SRG-OS-000131-NAThe operating system must employ cryptographic mechanisms to protect information in storage.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001019The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000132-NA<GroupDescription></GroupDescription>SRG-OS-000132-NAThe operating system must separate user functionality (including user interface services) from operating system management functionality.<VulnDiscussion>Operating system management functionality includes functions necessary to administer machine, network components, workstations, or servers, and typically requires privileged user access.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. This requirement is based on SC-2 with is application partitioning, a function of enterprise software.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001082The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000133-MOS-000075<GroupDescription></GroupDescription>SRG-OS-000133-MOS-000075The mobile operating system must prevent the user of the device from directly administering UIDs, file permissions, and system configuration files, and from starting and stopping system processes.<VulnDiscussion>If the user of the device can perform management functions, the user could modify the device configuration to degrade the IA posture of the device. Preventing such activity mitigates the risk of this vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001083Configure the mobile operating system to prevent the user of the device from directly administering UIDs, file permissions, and system configuration files, and from starting and stopping system processes.Navigate the mobile operating system and applications to determine if it is possible to directly administer UIDs, file permissions, and system configuration files. Also do this to determine if it is possible to start or stop system processes. The presence of applications that launch a command line shell is an indicator that this may be possible. If any of the listed management functions can be performed, this is a finding.SRG-OS-000134-NA<GroupDescription></GroupDescription>SRG-OS-000134-NAThe operating system must isolate security functions from non-security functions.<VulnDiscussion>Operating system management functionality includes functions necessary to administer the operating, network components, workstations, or servers, and typically requires privileged user access.
Rationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001084The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000135-NA<GroupDescription></GroupDescription>SRG-OS-000135-NAThe operating system must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions.<VulnDiscussion>The operating 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.
Rationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001086The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000136-NA<GroupDescription></GroupDescription>SRG-OS-000136-NAThe operating system must implement an information system isolation boundary to minimize the number of non-security functions included within the boundary containing security functions.<VulnDiscussion>The operating 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 operating system maintains a separate execution domain (e.g., address space) for each executing process.
Rationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001087The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000137-NA<GroupDescription></GroupDescription>SRG-OS-000137-NAThe operating system must 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.<VulnDiscussion>The operating 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: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001089The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000138-MOS-000076<GroupDescription></GroupDescription>SRG-OS-000138-MOS-000076The mobile operating system must prevent DoD applications from accessing non-DoD data when the device supports multiple user environments (e.g., work and personal) if such access has not been approved.<VulnDiscussion>When a device is used for more than one purpose (e.g., work and personal) there is the potential for information from one environment to migrate inappropriately over into another environment. Therefore it is critical for DoD applications and information be restricted from non-DoD applications and information. In many cases, the presence of non-DoD data on DoD information systems violates either local or department guidelines.
In the context of this IA control, a DoD application is an application that processes DoD data. The characteristics of being distributed through a DoD application store, or digitally signed or repackaged by a DoD entity do not by themselves make the application a DoD application. For example, a weather or map application signed and distributed from a DoD application store would not be a DoD application unless the weather, map, or other data was considered DoD data.
The mobile operating system must prevent this occurrence using appropriate technical controls to mitigate the risk of compromise of sensitive data. The objective is to provide appropriate separation between each environment on the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001090Configure the operating system and applications to prevent DoD applications from inappropriately accessing non-DoD data.Review the mobile operating system configuration to determine if the device supports multiple user environments. If it does, verify the operating system has controls preventing DoD applications from accessing non-DoD data. If non-DoD data can be accessed from a DoD application and there is no approval for such access, this is a finding.SRG-OS-000138-MOS-000077<GroupDescription></GroupDescription>SRG-OS-000138-MOS-000077The mobile operating system must prevent non-DoD applications from accessing DoD data when the device supports multiple user environments (e.g., work and personal).<VulnDiscussion>When a device is used for more than one purpose (e.g., work and personal) there is the potential for information from one environment to migrate inappropriately over into another environment. Therefore, it is critical for DoD applications and information be restricted from non-DoD applications and information. In many cases, the presence of non-DoD data on DoD information systems violates either local or department guidelines.
In the context of this IA control, a DoD application is an application that processes DoD data. The characteristics of being distributed through a DoD application store, or digitally signed or repacked by a DoD entity do not by themselves make the application a DoD application. For example, a weather or map application signed and distributed from a DoD application store would not be a DoD application unless the weather, map, or other data was considered DoD data.
The mobile operating system must prevent this occurrence using appropriate technical controls to mitigate the risk of data leakage. The objective is to provide appropriate separation between each environment on the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001090Configure the operating system and applications to prevent non-DoD applications from accessing DoD data.Review the mobile operating system configuration to determine if the device supports multiple user environments. If it does, verify the operating system has controls for preventing non-DoD applications from accessing DoD data. If non-DoD applications can access DoD data, this is a finding.SRG-OS-000139-NA<GroupDescription></GroupDescription>SRG-OS-000139-NAThe operating system must not share resources used to interface with systems operating at different security levels.<VulnDiscussion>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) obtaining access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the operating system. Shared resources include memory, input/output queues, and network interface cards.
Rationale for non-applicability: For the purposes of this SRG, a mobile OS is assumed to support a single security domain. There is no interface to systems at a different security level.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001091The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000140-NA<GroupDescription></GroupDescription>SRG-OS-000140-NAThe operating system must protect against or must limit the effects of the organization defined or referenced types of Denial of Service attacks.<VulnDiscussion>A variety of technologies exist to limit, or in some cases, eliminate the effects of Denial of Service (DoS) attacks. When it comes to DoS attacks, most attention is paid to ensuring the systems and applications are not victims of these attacks.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Carriers are in a much better position to mitigate the risk of and respond to DoS attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001092The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000141-NA<GroupDescription></GroupDescription>SRG-OS-000141-NAThe operating system must restrict the ability of users to launch Denial of Service attacks against other information systems or networks.<VulnDiscussion>When it comes to Denial of Service (DoS) attacks, most of the attention is paid to ensuring the systems and applications are not victims of these attacks.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Carriers are in a much better position to mitigate the risk of and respond to DoS attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001094The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000142-NA<GroupDescription></GroupDescription>SRG-OS-000142-NAThe operating system must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service attacks.<VulnDiscussion>In the case of Denial of Service attacks, care must be taken when designing the operating system so as to ensure the operating system makes the best use of system resources.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001095The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000143-NA<GroupDescription></GroupDescription>SRG-OS-000143-NAThe operating system must limit the use of resources by priority.<VulnDiscussion>Priority protection helps prevent a lower-priority process from delaying or interfering with the operating system servicing any higher-priority process. Operating systems must limit potential high volume usage resources to protect against a Denial of Service.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001096The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000144-NA<GroupDescription></GroupDescription>SRG-OS-000144-NAThe operating system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.<VulnDiscussion>The operating system must monitor and control communications at the boundary of the operating system.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001118, which refers to mobile device boundary protection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001097The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000145-NA<GroupDescription></GroupDescription>SRG-OS-000145-NAThe operating system must connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.<VulnDiscussion>The operating system must ensure traffic flows through only managed interfaces. For operating systems on the perimeter of the network (e.g., laptops connecting remotely) this helps protect the data on the endpoint.
Rationale for non-applicability: Mobile devices operate outside of enclave boundary. The arrangement of boundary protection devices is outside the scope of their control. The boundary protection devices will enforce strong authentication for VPN and other network connections.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001098The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000149-NA<GroupDescription></GroupDescription>SRG-OS-000149-NAThe operating system must route organization defined internal communications traffic to organization defined external networks through authenticated proxy servers within the managed interfaces of boundary protection devices.<VulnDiscussion>A proxy server is designed to hide the identity of the client when making a connection to a server outside of its network. This prevents any hackers on the outside of learning IP addresses within the private network. With a proxy acting as the mediator, the client does not interact directly with the servers it is connecting to; the proxy server is in the middle handling both sides of the session.
Rationale for non-applicability: Routing of this type of traffic is enforced by the network infrastructure and not the mobile device. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001112The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000150-NA<GroupDescription></GroupDescription>SRG-OS-000150-NAThe operating system, at managed interfaces, must deny network traffic and must audit internal users (or malicious code) posing a threat to external information systems.<VulnDiscussion>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: Mobile devices operate outside of enclave boundary. The arrangement of boundary protection devices is outside the scope of their control. The boundary protection devices will enforce strong authentication for VPN and other network connections.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001115The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000151-NA<GroupDescription></GroupDescription>SRG-OS-000151-NAThe operating system must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination.<VulnDiscussion>In the case of the operating system, the boundary may be the workstation on the public internet.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001117The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000152-MOS-000079<GroupDescription></GroupDescription>SRG-OS-000152-MOS-000079The mobile operating system must be able to filter both inbound and outbound traffic based on IP address and UDP/TCP port.<VulnDiscussion>Open ports provide an attack surface that an adversary can then potentially use to breach system security. If an adversary can communicate with the mobile device from any IP address, then the device may be open to any other device on the Internet. Reducing the attack surface through IP address and port restrictions mitigates this risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001118Configure the mobile operating system to filter both inbound and outbound traffic based on IP address and UDP/TCP port.Review the system documentation and operating system configuration to determine if the operating system is able to filter both inbound and outbound traffic based on IP address and TCP/UDP port. If the operating system cannot support this functionality, this is a finding.SRG-OS-000153-NA<GroupDescription></GroupDescription>SRG-OS-000153-NAThe operating system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.<VulnDiscussion>Managed interfaces employing boundary protection must be used for operating systems when using privileged accesses.
Rationale for non-applicability: Mobile devices do not have dedicated management interfaces.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001123The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000154-NA<GroupDescription></GroupDescription>SRG-OS-000154-NAThe operating system must prevent discovery of specific system components (or devices) composing a managed interface.<VulnDiscussion>Allowing discovery of operating system resources, names, or components can lead to giving information to an attacker that may be used as an attack vector.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001124The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000155-NA<GroupDescription></GroupDescription>SRG-OS-000155-NAThe operating system must employ automated mechanisms to enforce strict adherence to protocol format.<VulnDiscussion>Crafted packets not conforming to IEEE standards can be used by malicious people to exploit a host's protocol stack to create a Denial of Service or force a device reset.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001125The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000156-NA<GroupDescription></GroupDescription>SRG-OS-000156-NAThe operating system must fail securely in the event of an operational failure of a boundary protection device.<VulnDiscussion>Fail secure is a condition achieved by the operating system employing a set of information system mechanisms to ensure, in the event of an operational failure of a boundary protection device at a managed interface, the system does not enter into an unsecure state where security properties no longer hold.
Rationale for non-applicability: Mobile devices operate outside of enclave boundary. Therefore, they are not protected by boundary protection devices.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001126The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000157-NA<GroupDescription></GroupDescription>SRG-OS-000157-NAThe operating system must protect the integrity of transmitted information.<VulnDiscussion>Ensuring the integrity of transmitted information requires the operating system take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks.
Rationale for non-applicability: This vulnerability is better addressed by another CCI. Methods for confidentiality also address integrity. The control implemented for CCI-001130 will also apply here.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001127The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000105-NA<GroupDescription></GroupDescription>SRG-OS-000105-NAThe operating system must use multifactor authentication for network access to privileged accounts.<VulnDiscussion>Multifactor authentication is defined as using two or more factors to achieve authentication.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. While network access to privileged UID may be supported for carrier maintenance purposes, such access is automated and does not require two-factors. Two-factor authentication is more appropriate when authenticating human users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000765The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000158-NA<GroupDescription></GroupDescription>SRG-OS-000158-NAThe operating system must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures.<VulnDiscussion>Ensuring the integrity of transmitted information requires operating systems take measures to employ some form of cryptographic mechanism in order to recognize changes to information. This is usually achieved through the use of checksums, cryptographic hash, or message authentication.
Rationale for non-applicability: This vulnerability is better addressed by another CCI. Methods for confidentiality also address integrity. The control implemented for CCI-001130 will also apply here.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001128The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000159-NA<GroupDescription></GroupDescription>SRG-OS-000159-NAThe operating system must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission.<VulnDiscussion>Ensuring the confidentiality of transmitted information requires the operating system take measures in preparing information for transmission. This can be accomplished via access control or encryption.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001129The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000160-MOS-000080<GroupDescription></GroupDescription>SRG-OS-000160-MOS-000080The mobile operating systems VPN client must use either IPSec or SSL/TLS when connecting to DoD networks.<VulnDiscussion>Use of non-standard communications protocols can affect both the availability and confidentiality of communications. IPSec and SSL/TLS are both well-known and tested protocols that provide strong assurance with respect to both IA and interoperability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001130Configure the mobile operating system's VPN client to use IPSec or SSL/TLS when connecting to a DoD network.Review system documentation and operating system configuration to verify the VPN client uses IPSec or SSL/TLS when connecting to DoD networks. Note: This requirement also applies to a private VPN connection from the carrier's network to the DoD network that is designed to route all mobile device traffic directly to the DoD network. If it does not support either of these protocols, or does not use them when establishing a VPN connection to a DoD network, this is a finding.SRG-OS-000160-MOS-000081<GroupDescription></GroupDescription>SRG-OS-000160-MOS-000081The mobile operating systems Bluetooth stack must use 128-bit Bluetooth encryption when performing data communications with other Bluetooth devices.<VulnDiscussion>If data traffic is sent unencrypted, an adversary may be able to read it to obtain sensitive information. 128-bit Bluetooth encryption for data communications mitigates the risk of unauthorized eavesdropping. DoD has determined that FIPS 140-2 validated encryption is not required for voice communications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001130Configure the mobile operating system's Bluetooth stack to use 128-bit encryption.Review system documentation and operating system configuration to verify the device's Bluetooth stack supports 128-bit Bluetooth encryption and uses it for all data connections. If the Bluetooth module does not support 128-bit Bluetooth encryption or does not use it when connecting with other devices for data communications, this is a finding.SRG-OS-000160-MOS-000082<GroupDescription></GroupDescription>SRG-OS-000160-MOS-000082The mobile operating systems Wi-Fi module must use AES-CCMP encryption when connecting to a DoD network.<VulnDiscussion>If data traffic is sent unencrypted, an adversary may be able to read it to obtain sensitive information. Some WPA2 certified Wi-Fi implementations use Temporal Key Integrity Protocol (TKIP), which is not authorized for use in DoD. There are no publicly known breaches of AES-CCMP, which greatly mitigates the risk of unauthorized eavesdropping.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001130Configure the operating system's Wi-Fi client to use AES-CCMP when connecting to DoD networks.Review system documentation to verify the product is WPA2 certified. If it is, the device supports AES-CCMP encryption. If it is not WPA2 certified, it is very unlikely to support AES-CCMP encryption but the site may provide evidence to the contrary in the possible event that the manufacturer implemented AES-CCMP without obtaining the WPA2 certification. Verify DoD network connections use AES-CCMP and not TKIP or another protocol. If any other data link layer encryption protocol is used besides AES-CCMP to connect to a DoD network, this is a finding.SRG-OS-000160-MOS-000083<GroupDescription></GroupDescription>SRG-OS-000160-MOS-000083The mobile operating system must encrypt all data in transit using AES encryption when communicating with DoD information resources (128-bit key length is the minimum requirement; 256-bit desired).<VulnDiscussion>If data traffic is sent unencrypted, an adversary may be able to read it to obtain sensitive information. AES encryption with 128-bit (or longer) keys mitigates the risk of unauthorized eavesdropping. This requirement applies to both VPN connections and DoD messaging connections (email and authorized instant messaging applications).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001130Configure the VPN client, email client, and other applications that communicate with DoD information resources to use AES encryption with 128-bit (or longer) keys.Review the operating system documentation and configuration (and possibly application configuration) to determine if the system uses AES encryption with at least 128-bit keys. If it does not use AES encryption with the required key length, this is a finding.SRG-OS-000161-NA<GroupDescription></GroupDescription>SRG-OS-000161-NAThe operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures.<VulnDiscussion>Ensuring the confidentiality of transmitted information requires operating systems take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001130, which deals with confidentiality in transit.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001131The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000162-NA<GroupDescription></GroupDescription>SRG-OS-000162-NAThe operating system must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission.<VulnDiscussion>Confidentiality of the data must be maintained to ensure unauthorized users or processes do not have access to it. This can be accomplished via access control mechanisms or encryption.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001132The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000163-MOS-000084<GroupDescription></GroupDescription>SRG-OS-000163-MOS-000084The mobile operating system must terminate the network connection when an application requests termination, or after an organization defined time period of inactivity.<VulnDiscussion>If communications sessions remain open for extended periods of time even when unused, there is the potential for an adversary to highjack the session and use it to gain access to the device or networks to which it is attached. Terminating sessions after a certain period of inactivity is a method for mitigating the risk of this vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001133Configure the mobile operating system to terminate the network connection when an application requests termination, or after an organization defined time period of inactivity.Review the mobile operating system configuration to verify the operating system terminates network connections after an organization defined time period of inactivity. The session is inactive when there is either no longer a listening port or the port does not respond to requests. If communications are not terminated after an organization defined time period of inactivity, this is a finding.SRG-OS-000164-NA<GroupDescription></GroupDescription>SRG-OS-000164-NAThe operating system must establish a trusted communications path between the user and organization defined security functions within the operating system.<VulnDiscussion>The 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: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001135The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000165-MOS-000085<GroupDescription></GroupDescription>SRG-OS-000165-MOS-000085The mobile operating system must produce, control, and distribute cryptographic keys using NIST-approved or NSA-approved key management technology and processes if it produces, controls, or distributes cryptographic keys.<VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. NIST technology and processes must be used for unclassified applications and data. NSA technology and processes must be used for classified applications and data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001140Configure the operating system to use NIST and NSA approved cryptographic key management processes.Check that the operating system uses NIST and NSA approved cryptographic key management technology and processes if it produces, controls, or distributes cryptographic keys.SRG-OS-000166-NA<GroupDescription></GroupDescription>SRG-OS-000166-NAThe operating system must produce, control, and distribute symmetric and asymmetric cryptographic keys using NSA approved key management technology and processes.<VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures.
Rationale for non-applicability: This control is being addressed by the control corresponding to CCI-1140.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001141The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000167-MOS-000087<GroupDescription></GroupDescription>SRG-OS-000167-MOS-000087The mobile operating system PKI certificate store must encrypt contents using AES encryption (AES 128 bit encryption key length is the minimum requirement; AES 256 desired).<VulnDiscussion>If an adversary can access the key store, it may be able to use the keys to perform a variety of unauthorized transactions. It may also be able to modify public keys in a way that it can trick the operating system into accepting invalid certificates. Encrypting the key store protects the integrity and confidentiality of keys. AES encryption with adequate key lengths provides assurance that the protection is strong. The electronic code book mode of AES is the most appropriate mode for encryption of the key store, but the implemented may select other AES modes if they are more appropriate in the given environment.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001142Configure the mobile operating system (or selected third party application) to encrypt the contents of the key with AES encryption using 128-bit or longer keys.Review system documentation and operating system configuration to determine if the operating system uses AES encryption with 128-bit or longer keys to encrypt the contents of the key store. If the key store is not encrypted or does not use AES encryption, this is a finding.SRG-OS-000167-MOS-000088<GroupDescription></GroupDescription>SRG-OS-000167-MOS-000088The mobile operating system must support both software-based and hardware-based asymmetric key technology (e.g., CAC/PIV).<VulnDiscussion>Software-based certificates are required to authenticate many web sites. Hardware-based tokens are embedded in the DoD Common Access Card (CAC). Without both software and hardware-based asymmetric key technology, there is the potential that critical authentication transactions cannot occur. This will either hinder performance of the mission or degrade the IA posture of one or more applications. If the operating system can support both software and hardware-based asymmetric key technology, this provides assurance that all required certificate-based transactions are supported.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001142Configure the mobile operating system (or selected third party application) to support both software-based and hardware-based asymmetric key technology.Review the mobile operating system configuration to verify both software-based and hardware-based asymmetric key technology is supported. If the system supports a hardware token method other than the DoD CAC, this is acceptable for the purposes of this control, but may result in non-compliance for other controls requiring DoD CAC. If the mobile operating system fails to support either software-based or hardware-based asymmetric key technology, this is a finding.SRG-OS-000168-NA<GroupDescription></GroupDescription>SRG-OS-000168-NAThe operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the users private key.<VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures.
Rationale for non-applicability: This control is primarily intended for systems that act as a certificate authority or server. Mobile operating systems are not intended for this role. Aspects of certificate control that are handled by a mobile device are addressed by other controls in the MOS SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001143The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000169-NA<GroupDescription></GroupDescription>SRG-OS-000169-NAThe operating system must implement required cryptographic protections using cryptographic modules that comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.<VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms that are employed to encrypt the data.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001145, which focuses on FIPS validation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001144The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000170-MOS-000089<GroupDescription></GroupDescription>SRG-OS-000170-MOS-000089The cryptographic module supporting encryption of data in transit (including email and attachments) must be FIPS 140-2 validated.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140-2 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS 140-2 validation is also a strict requirement for use of cryptography in the Federal Government. This general IA control is applicable to all wireless interfaces but is primarily targeted at interfaces other than Wi-Fi or Bluetooth, which have their own controls. STIGs for devices that have wireless interfaces other than Wi-Fi or Bluetooth only may use those controls in lieu of this one. For other wireless interfaces, this control must be applied.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001145Configure the mobile operating system's cryptographic module to encrypt data in transit (including email and attachments) using FIPS 140-2 validated modules.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. If the module is not currently FIPS validated, this is a finding. If the cryptographic module is not operating in FIPS mode, this is a finding.SRG-OS-000170-MOS-000090<GroupDescription></GroupDescription>SRG-OS-000170-MOS-000090The cryptographic module supporting encryption of data at rest must be FIPS 140-2 validated.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.
This general IA control is applicable to all wireless interfaces but is primarily targeted at interfaces other than Wi-Fi or Bluetooth, which have their own controls. Guidance for mobile devices, which has wireless interfaces other than Wi-Fi or Bluetooth only, may use those controls in lieu of this one. For other wireless interfaces, this control must be applied.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001145Configure the mobile operating system's cryptographic module to encrypt data at rest using FIPS 140-2 validated modules.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. If the module is not currently FIPS validated, this is a finding. If the cryptographic module is not operating in FIPS mode, this is a finding.SRG-OS-000170-MOS-000091<GroupDescription></GroupDescription>SRG-OS-000170-MOS-000091The cryptographic module supporting the VPN client security functions must be FIPS 140-2 validated.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001145Configure the mobile operating system's cryptographic module supporting the VPN client security functions to encrypt using FIPS 140-2 validated modules.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. If the module is not currently FIPS validated, this is a finding. Note: This requirement also applies to a private VPN connection from the carrier's network to the DoD network that is designed to route all mobile device traffic directly to the DoD network. If the cryptographic module is not operating in FIPS mode, this is a finding.SRG-OS-000170-MOS-000092<GroupDescription></GroupDescription>SRG-OS-000170-MOS-000092The mobile operating system PKI certificate store must be FIPS 140-2 validated.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140-2 validation provides assurance that the relevant cryptography has been implemented correctly. This particular control concerns the need for a strong password to be enforced on the actual certificate store in addition to the unlock code on the device. FIPS 140-2 validation is also a strict requirement for use of cryptography in the Federal Government.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001145Configure the mobile operating system PKI certificate store to be FIPS 140-2 validated.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. A mobile operating system may satisfy this requirement if the certificate store is encrypted with a FIPS 140-2 validated cryptographic module that also encrypts other data at rest beyond the certificate store. If the module is not currently FIPS validated, this is a finding. If the cryptographic module is not operating in FIPS mode, this is a finding. If the device unlock password also unlocks the certificate store, this is a finding.SRG-OS-000170-MOS-000093<GroupDescription></GroupDescription>SRG-OS-000170-MOS-000093The cryptographic module supporting Bluetooth data communications must be FIPS 140-2 validated.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.
Note: Bluetooth standards are being revised to specify cryptographic algorithms for which it is possible to obtain FIPS 140-2 validation for implementations of those algorithms. However, mobile devices are currently required to use Bluetooth modules that are FIPS 140-2 validated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001145Configure the mobile operating system's cryptographic module supporting Bluetooth data communications to be FIPS 140-2 validated.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. If the module is not currently FIPS validated, this is a finding. If the cryptographic module is not operating in FIPS mode, this is a finding.SRG-OS-000170-MOS-000094<GroupDescription></GroupDescription>SRG-OS-000170-MOS-000094The cryptographic module supporting Wi-Fi security functions must be FIPS 140-2 validated.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001145Configure the mobile operating system's cryptographic module supporting Wi-Fi security functions to be FIPS 140-2 validated.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. If the module is not currently FIPS validated, this is a finding. If the cryptographic module is not operating in FIPS mode, this is a finding.SRG-OS-000171-MOS-000095<GroupDescription></GroupDescription>SRG-OS-000171-MOS-000095The mobile operating system must employ NSA approved cryptography to protect classified information.<VulnDiscussion>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.
The most common vulnerabilities with cryptographic modules are those associated with poor implementation. NSA approval is required for cryptography for classified data and applications and provides assurance that the implementation is adequately protected against attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001146Configure the mobile operating system to employ NSA approved cryptography to protect classified information.Review system documentation to identify that NSA has approved the cryptography used to protect classified data and applications resident on the device. If NSA has not approved the cryptography for classified data and applications, this is a finding.SRG-OS-000172-NA<GroupDescription></GroupDescription>SRG-OS-000172-NAThe operating system must employ FIPS validated cryptography to protect information when it must be separated from individuals who have the necessary clearances, yet lack the necessary access approvals.<VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. How that user obtains information without having the proper access approvals is an OPSEC concern, not a technical control on a mobile device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001147The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000173-MOS-000096<GroupDescription></GroupDescription>SRG-OS-000173-MOS-000096The mobile operating system must employ FIPS validated or NSA approved cryptography to implement digital signatures.<VulnDiscussion>The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation and NSA approval provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government. Similarly, NSA approval of cryptography for classified data and applications is a strict requirement. The objective is to validate the implementation of the cryptography, not the cryptographic algorithm or mode.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001148Configure the mobile operating system to employ FIPS validated or NSA approved cryptography for implementing digital signatures.Review system documentation to identify the FIPS 140-2 certificate for the cryptographic module. Visit the NIST web site http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm to verify the certificate is still valid. If the module is not currently FIPS validated, this is a finding. If the cryptographic module is not operating in FIPS mode, this is a finding. Similarly, if NSA approved cryptography is not used to implement digital signatures for classified systems operating in an approved mode, this is a finding.SRG-OS-000174-NA<GroupDescription></GroupDescription>SRG-OS-000174-NAThe operating system must protect the integrity and availability of publicly available information and applications.<VulnDiscussion>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: This control primarily applies to public web servers. A mobile OS typically does not host publically accessible data or services.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001149The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000175-MOS-000097<GroupDescription></GroupDescription>SRG-OS-000175-MOS-000097The mobile operating system must prohibit remote activation of collaborative computing functions, including microphones, cameras, and networked white boards without user concurrence.<VulnDiscussion>If an adversary can remotely activate collaborative computing functions, the adversary may be able to listen to the user's conversations, obtain visual data about the user's surroundings, or read sensitive information on the display of the user's device. To mitigate these risks, only a user in immediate possession of the device should be able to activate these functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001150Configure the operating system and relevant applications to prohibit remote activation of collaborative computing functions.Review system documentation and both operating system and application configuration to determine if it is possible to remotely activate collaborative computing functions. Also, review IA information resources to determine if such vulnerabilities have been reported on devices running this operating system. If it is possible to remotely activate a collaborative computing function, this is a finding.SRG-OS-000176-MOS-000098<GroupDescription></GroupDescription>SRG-OS-000176-MOS-000098The Mobile OS must block both the inbound and outbound traffic between instant messaging clients that are independently configured by end users and external service providers or other unapproved DoD systems. <VulnDiscussion>Many instant messaging systems have known vulnerabilities, some of which allow an adversary to install malware on the device. This malware can then be used to obtain sensitive information or further compromise DoD information systems. Restricting IM traffic to DoD authorized IM systems mitigates the risk of using IM technology.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001154Remove non-DoD authorized IM applications from the device.Inspect the mobile operating system configuration for prohibiting the use of non-DoD authorized instant messaging (IM) systems. If non-DoD authorized IM clients pass either inbound or outbound traffic, this is a finding.SRG-OS-000177-MOS-000099<GroupDescription></GroupDescription>SRG-OS-000177-MOS-000099The mobile operating system must grant a downloaded application only the permissions that DoD has authorized for that application.<VulnDiscussion>Mobile operating system applications that are able to perform unintended functions may be able to obtain sensitive information or otherwise compromise system security. The permissions that an application requires to perform its function may be delineated in a permissions manifest or in entitlements that are either bound to the application or embedded in its code. Enforcing these permissions limitations is necessary to ensure the application is not permitted to perform unintended functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001157Configure the mobile operating system to only grant an application those permissions that DoD has authorized for that application.Review IA information resources to determine if the operating system enforces privileges as advertised. Use an integrity tool to determine if an application is permitted to perform restricted functions. If it is determined that the authorized permissions are not enforced, this is a finding.SRG-OS-000178-MOS-000100<GroupDescription></GroupDescription>SRG-OS-000178-MOS-000100The mobile operating system must validate the integrity of a downloaded applications manifest before granting the application permissions on the device, if the operating system uses a manifest or similar mechanism external to application code to grant application permissions.<VulnDiscussion>If an adversary can modify an application's manifest (when the mobile OS supports this approach), then the adversary can add additional permissions that would enable it to perform unauthorized functions. These functions could enable the adversary to obtain sensitive information or compromise other aspects of system security. Validating the integrity of the manifest or similar technology mitigates the risk that an adversary has modified its contents. The SHA-1, SHA-224, SHA-256, and SHA-512 secure hash algorithms are acceptable mechanisms for verifying integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001158Configure the mobile operating system to validate the integrity of mechanisms to grant application permissions to applications.Review system documentation, operating system configuration, and other IA information resources to determine if the operating system validates the integrity of any permissions related information that is associated with an application but not embedded in application code. The SHA-1, SHA-224, SHA-256, and SHA-512 secure hash algorithms are acceptable mechanisms for verifying integrity. If it is determined that the integrity check is not occurring, this is a finding.SRG-OS-000179-MOS-000101<GroupDescription></GroupDescription>SRG-OS-000179-MOS-000101Only DoD PKI issued or DoD approved software authentication certificates may be installed on DoD mobile operating system devices.<VulnDiscussion>If unauthorized software authentication certificates are installed on the device, then the operating system would not block malware signed by the entity that published these certificates. Such malware could be used to obtain sensitive DoD information or to further breach system security. Eliminating unapproved software authentication certificates greatly mitigates the risk of malware passing authentication controls.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001159Remove unapproved software authentication certificates from the device.Review the mobile operating system certificate store for the software authentication certificates. In some cases, the certificates may not be visible. In this situation, consult system documentation to determine what certificates are installed on the device. Match the certificates present against a list of approved certificates. Verify there are no unapproved certificates present. If there are unapproved software authentication certificates installed on the device, this is a finding.SRG-OS-000179-MOS-000102<GroupDescription></GroupDescription>SRG-OS-000179-MOS-000102Only DoD PKI issued or DoD approved server authentication certificates must be installed on DoD mobile operating system devices.<VulnDiscussion>If unauthorized device authentication certificates are installed on the device, there is the potential that the device may connect to a rogue device or network. Rogue devices can mimic the behavior of authorized equipment to trick the user into providing authentication credentials, which could then in turn be used to compromise DoD information and networks. Restricting device authentication certificates to an authorized list mitigates the risk of attaching to rogue devices and networks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001159Remove unapproved software authentication certificates from the device.Review the mobile operating system certificate store for the device authentication certificates. In some cases, the certificates may not be visible. In this situation, consult system documentation to determine what certificates are installed on the device. Match the certificates present against a list of approved certificates. Verify there are no unapproved certificates present. If there are unapproved device authentication certificates installed on the device, this is a finding.SRG-OS-000180-NA<GroupDescription></GroupDescription>SRG-OS-000180-NAThe operating system must implement detection and inspection mechanisms to identify unauthorized mobile code.<VulnDiscussion>Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously.
Rationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001166The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000181-NA<GroupDescription></GroupDescription>SRG-OS-000181-NAThe operating system must prevent the execution of prohibited mobile code.<VulnDiscussion>Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously.
Rationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001695The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000182-NA<GroupDescription></GroupDescription>SRG-OS-000182-NAThe operating system must prevent the download of prohibited mobile code.<VulnDiscussion>Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously.
Rationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG. Proxy servers also provide a layer of defense against malicious mobile code.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001169The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000183-NA<GroupDescription></GroupDescription>SRG-OS-000183-NAThe operating system must prevent the automatic execution of mobile code in organization defined software applications and must require organization defined actions prior to executing the code.<VulnDiscussion>Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously.
Rationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001170The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000184-NA<GroupDescription></GroupDescription>SRG-OS-000184-NAThe operating system must fail to an organization defined known state for organization defined types of failures.<VulnDiscussion>Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. It 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 system state information facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes.
Rationale for non-applicability: As per the MOS SRG IA control corresponding to CCI-001383, the mobile operating system must wipe the device after an organization defined number of incorrect passcode attempts. No other failure states are defined at this time. The applicability of this control may be reconsidered at a future date if it is determined that certain failure conditions require failure to specific known states.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001190The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000185-NA<GroupDescription></GroupDescription>SRG-OS-000185-NAThe operating system must protect the confidentiality and integrity of information at rest.<VulnDiscussion>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). The operating system must ensure the data being written to these devices is protected. In most cases, this is done via encryption.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001200, which includes cryptographic mechanisms to protect confidential and integrity of data at rest.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001199The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000186-NA<GroupDescription></GroupDescription>SRG-OS-000186-NAThe operating system must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission.<VulnDiscussion>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 operating system take steps to validate and assure the integrity of data while at these stages of processing.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001209The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000187-NA<GroupDescription></GroupDescription>SRG-OS-000187-NAThe operating system at organization defined information system components must load and execute the operating environment from hardware-enforced, read-only media.<VulnDiscussion>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 includes 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: Mobile OS devices must be flash upgradable in order to implement patches to vulnerabilities. The small form factor of a mobile device does not easily allow for multiple forms of storage. Therefore, the persistent memory on a mobile device must be writeable and cannot support this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001210The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000189-NA<GroupDescription></GroupDescription>SRG-OS-000189-NAThe operating system must employ organization defined information system components with no writeable storage that are persistent across component restart or power on/off.<VulnDiscussion>Organizations may require operating systems to be non-modifiable or to be stored and executed on non-writeable storage (e.g., there are no CD-ROM drives common on PCs). Use of non-modifiable storage ensures the integrity of the program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion.
Rationale for non-applicability: Mobile OS devices must be flash upgradable in order to implement patches to vulnerabilities. The small form factor of a mobile device does not easily allow for multiple forms of storage. Therefore, the persistent memory on a mobile device must be writeable and cannot support this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001214The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000190-NA<GroupDescription></GroupDescription>SRG-OS-000190-NAThe operating system must install software updates automatically.<VulnDiscussion>Security faults with software applications and operating systems are discovered daily and 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, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously.
Rationale for non-applicability: This IA control conflicts with another IA requirement that users must accept software updates, thereby precluding full automation. In some instances, software updates must be downloaded directly from vendors without DoD evaluation. In this environment, fully automated updates pose an IA risk because the updates could contain malware that circumvents other IA controls. In the mobility context, the mechanism for enforcing currency of IA-related patches is to prohibit a mobile device from accessing DoD information resources if it does not have DoD-required security updates. This capability would typically be implemented using automated MDM features and enables DoD to decide which security updates are mandatory independently from the release schedule of patches from mobile OS vendors.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001232The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000191-MOS-000103<GroupDescription></GroupDescription>SRG-OS-000191-MOS-000103The mobile operating system must detect and report the version of the operating system, device drivers, and application software when queried by an authorized entity.<VulnDiscussion>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 an MDM system or other system with similar functionality. To support this requirement, an automated process or mechanism is required.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001233Configure the operating system such that it can detect and report the version of the operating system, device drivers, and application software.Examine the mobile operating system configuration for detecting and reporting the version of the operating system, device drivers, and application software when queried by an authorized entity. Determine if the version of the operating system, selected device drivers, and at least one software application are correctly detected and reported to the MDM. If any such information cannot be obtained, this is a finding.SRG-OS-000192-MOS-000104<GroupDescription></GroupDescription>SRG-OS-000192-MOS-000104The mobile operating system must support automated patch management tools to facilitate flaw remediation of all software components on the device.<VulnDiscussion>The organization (including any contractor to the organization) must promptly install security relevant software updates (e.g., patches, service packs, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed. Left un-patched, software may be vulnerable to a variety of exploits that could disclose sensitive information or lead to subsequent security breaches. An automated patch management system can mitigate this risk.
In the context of this IA control, automation is interpreted broadly and covers patch management systems that involve user acknowledgement of patches or user initiated patches after automatic notification of the availability of a patch. Automation is from the perspective of the commercial mobile device (CMD) user; system administrators may still need to perform several manual steps to prepare patches for distribution and modify CMD configuration to be able to receive patches.
However, patch systems that require CMD users to take additional steps beyond a one-step acknowledgment or request for the patch in order to locate, download, install, or verify the patch are not considered automated.
Some user involvement in the patch process is a defense-in-depth measure to protect CMD and DoD networks. In particular, it mitigates the risk of carrier-initiated patches that have been known to include malware.
Mobile device management (MDM) systems also mitigate the risk of un-patched CMD. If a user does not install a required patch for whatever reason, the MDM system may deny the CMD access to DoD networks and, when the risk warrants it, remotely disable the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001237Implement automated patch management tools on the mobile operating system to facilitate flaw remediation of all software components on the device.Verify the mobile operating system supports automated patch management tools to facilitate flaw remediation of all software components on the device. Identify which elements of the system are automated and which require human intervention.
Verify installation of a patch does not require the user to do more than acknowledge the patch or request the patch after receiving a notification of its availability. Some patches may require the user to restart the system to complete installation of the patch, but the patch system may still be considered automated in this case. The patch system may also be considered automated if patches are distributed on removable media used to load the operating system so long as this is the routine established method for loading the operating system and applications, patches cannot be installed through other means, and the user is not required to perform additional steps beyond user authentication and acceptance of the updates.
If the mobile operating system does not support automated patching of all software components on the device, or does not support patching at all, this is a finding.SRG-OS-000193-NA<GroupDescription></GroupDescription>SRG-OS-000193-NAThe operating system must have malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.<VulnDiscussion>In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated prior to entering protected enclaves via operating system entry and exit points.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001668, which corresponds to NIST Special Publication 800-53 control SI-3, specifically mentions mobile devices.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001239The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000194-MOS-000105<GroupDescription></GroupDescription>SRG-OS-000194-MOS-000105The mobile operating system must prevent non-privileged users from circumventing malicious code protection capabilities.<VulnDiscussion>A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it, which enables subsequent attacks. If malicious code protection is itself protected, then it will prevent a non-privileged user or malicious software from disabling the protection mechanism. Ensuring that any security feature is protected against bypass, tampering, or disablement is best met by a mandatory access control mechanism in the mobile OS.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001248Configure the malicious code protection capability so it cannot be circumvented.Review the system documentation to determine if the malicious code protection capabilities are adequate. In particular, the protection mechanisms must load during the boot process and must not be able to be disabled. Reboot a device and verify the protection mechanisms are active after the boot cycle. Attempt to kill the protection process if it is identifiable. If the reviewer can disable the malicious code protection capabilities, this is a finding.SRG-OS-000195-NA<GroupDescription></GroupDescription>SRG-OS-000195-NAThe operating system must not allow users to introduce removable media into the information system.<VulnDiscussion>Malicious code is known to propagate via removable media such as floppy disks, USB or flash drives, and removable hard drives.
Rationale for non-applicability: Mobile OS devices use removable media (i.e., SD cards) for many storage purposes and may be required for operation in some cases. This precludes a prohibition on removable media. However, to help ensure proper use of the removable media, the MOS SRG requires that removable media be cryptographically bound to the operating system and that all data on the removable media be encrypted. This prevents the removable media from being used on another device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001250The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000196-NA<GroupDescription></GroupDescription>SRG-OS-000196-NAThe operating system must provide a near real-time alert when any of the organization defined list of compromise or potential compromise indicators occurs.<VulnDiscussion>When an intrusion detection security event occurs it is imperative the operating system that has detected the event immediately notify the appropriate support personnel so they can respond accordingly.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001274, which addresses alerts in case of integrity check failure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001263The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000197-MOS-000106<GroupDescription></GroupDescription>SRG-OS-000197-MOS-000106The mobile operating system must prevent non-privileged users from circumventing intrusion detection and prevention capabilities.<VulnDiscussion>Intrusion detection and prevention capabilities must be architected and implemented to prevent non-privileged users from circumventing such protections. Ensuring that any security feature is protected against bypass, tampering, or disablement is best met by a mandatory access control mechanism. However, limited protection may also be accomplished through the use of user roles and systems permissions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001265Configure the operating system and its intrusion detection and prevention capabilities so they cannot be circumvented by a non-privileged user.Review system documentation, operating system configuration, and other IA information resources to determine if a non-privileged user can circumvent intrusion detection and prevention capabilities. Determine if a non-privileged user can terminate processes for the intrusion detection and prevention functionality. If a non-privileged user can circumvent this functionality, this is a finding.SRG-OS-000197-MOS-000107<GroupDescription></GroupDescription>SRG-OS-000197-MOS-000107The mobile operating system must prevent a user from using a browser that does not direct its traffic to a DoD proxy server.<VulnDiscussion>Proxy servers can inspect traffic for malware and other signs of a security attack. Allowing a mobile device to access the public Internet without proxy server inspection, forgoes the protection the proxy server would otherwise provide. Malware downloaded onto the device could have a wide variety of malicious consequences, including loss of sensitive DoD information. Forcing traffic to flow through a proxy server greatly mitigates the risk of access to public Internet resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001265Disable browsers that do not support a feature to direct all traffic to a designated proxy server. Configure browsers that support this functionality to direct all traffic to a designated proxy server.Review the operating system and browser configuration to determine if traffic is forced through DoD proxy servers. If greater assurance is required, access a number of Internet web sites and verify traffic flows through a DoD proxy server by viewing the traffic using a network protocol analyzer or by communicating with personnel that manage the proxy server. If the device accesses any internet resource without being directed through a DoD proxy server, this is a finding.SRG-OS-000198-MOS-000108<GroupDescription></GroupDescription>SRG-OS-000198-MOS-000108The mobile operating system must protect information obtained from intrusion and integrity monitoring tools from unauthorized access, modification, and deletion.<VulnDiscussion>If an adversary can modify or delete information obtained from intrusion and integrity tools, then the adversary can hide evidence of an attack. Mechanisms to protect such data are necessary to mitigate the risk of these attacks and ensure they are detected in a timely manner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001269Configure the operating system and intrusion and integrity monitoring tools to protect data generated by such tools.Review system documentation and operating system configuration to verify data collected by intrusion and integrity monitoring tools is either encrypted or sufficiently protected with file permissions not available to processes running user applications. If the reviewer has obtained evidence that modification or deletion of such data is possible, or if the reviewer can modify such data directly, this is a finding.SRG-OS-000199-NA<GroupDescription></GroupDescription>SRG-OS-000199-NAThe operating system must verify the correct operation of security functions in accordance with organization defined conditions and in accordance with organization defined frequency (if periodic verification).<VulnDiscussion>Security functional testing involves testing the operating system for conformance to the operating system 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 operating system to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Additionally, the IA control corresponding to CCI-1297 requires that the integrity of the security enforcement mechanisms be validated at startup and every six hours thereafter. This provides reasonable assurance that security functions are performing properly even the functions themselves are not tested at these times.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001291The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000200-MOS-000109<GroupDescription></GroupDescription>SRG-OS-000200-MOS-000109The operating system must provide notification to an external device and halt the boot cycle if the OS detects tampering or fails operating system security tests.<VulnDiscussion>Automated security tests performed by the mobile operating system are critical in the detection of IA attacks. Such checks include verification of the integrity of operating system files, device drivers, and security enforcement mechanisms by the operating system or third-party applications. However, users and systems administrators can only benefit from the security tests if they are notified in case of failure. A notification mechanism reduces the risk that a security breach will go undetected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001294Configure the operating system to provide notification of failed automated security tests and to halt the boot cycle if tampering of the OS has been detected.Review the mobile operating system configuration to determine how the operating system responds in the event of a failed automated security test and tampering of the OS files. If the device is integrated with mobile device management (MDM) able to access device logs, then review system logs to determine if the operating system has provided notification of a failed automated security test. Otherwise, determine if there is some form of beaconing or alerting that could be detectable by an MDM or other network management system, or if the OS will terminate the boot cycle should the integrity of the OS files be compromised. If higher assurance is required, perform an action that would cause the device to fail an automated security test (e.g., insert unknown removable media), and verify the operating system provides notification of the failure. If there are any known security tests for which notification does not occur, this is a finding.SRG-OS-000201-NA<GroupDescription></GroupDescription>SRG-OS-000201-NAThe operating system must provide automated support for the management of distributed security testing.<VulnDiscussion>The need to verify security functionality applies to all security functions.
Rationale for non-applicability: This requirement is better addressed by CCI-001294, which states the requirement to report the results of security test failures. The requirement for distributed security testing is within the scope of the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001295The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000202-MOS-000110<GroupDescription></GroupDescription>SRG-OS-000202-MOS-000110The mobile operating system must conduct a device integrity scan on a minimum organizationally-defined periodic basis.<VulnDiscussion>Unauthorized changes to the operating system software or information on the system can possibly result in integrity or availability concerns. In order to quickly react to this situation, the operating system must detect these changes. One aspect of detection is the frequency at which the scans occur. The ability to set an appropriate frequency mitigates the risk that an attack will go without detection longer than the scanning interval.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001297Configure the mobile operating system to scan the device on a minimum, organizationally-defined periodic basis. Review the operating system and MDM agent software settings to verify the device integrity validation scan frequency is configurable to a minimum, organizationally-defined period. If it is not, this is a findingSRG-OS-000202-MOS-000111<GroupDescription></GroupDescription>SRG-OS-000202-MOS-000111The mobile operating system must verify the integrity of all operating system files, device drivers, and security enforcement mechanisms at startup and at least every six hours thereafter using one or more DoD approved cryptographic mechanisms that compare attributes of the operating system configuration to a known good baseline.<VulnDiscussion>One of the most significant indicators of an IA attack is modification of operating system files, device drivers, or security enforcement mechanisms. An integrity verification capability or tool detects unauthorized modifications to files or permissions and either prevents further operation or reports its findings so an appropriate response can occur.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001297If the operating system does not have a native integrity checking capability, install a DoD approved system integrity scanning capability or tool.Review system documentation, operating system configuration, and other IA information resources to determine if the mobile operating system verifies the integrity of all operating system files, device drivers, and security enforcement mechanisms at startup and periodically thereafter using one or more DoD approved cryptographic mechanisms that compare attributes of the operating system configuration to a known good baseline. If such a capability is not embedded in the operating system, then the device must integrate a DoD approved tool providing this functionality. Inspect the device to determine if an active system scanning integrity capability or tool is resident on the device.
Validate the capability has been deemed acceptable for use within DoD. If the capability is not present or is inadequate, this is a finding.SRG-OS-000203-NA<GroupDescription></GroupDescription>SRG-OS-000203-NAThe operating system must check the validity of information inputs.<VulnDiscussion>Invalid user input occurs when a user inserts data or characters the system is unprepared to process. This results in unanticipated behavior that could lead to a compromise.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Additionally, several more specific input controls are included in the Mobile Applications SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001310The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000204-NA<GroupDescription></GroupDescription>SRG-OS-000204-NAThe operating system must identify potentially security relevant error conditions.<VulnDiscussion>The structure and content of error messages need to be carefully considered by the organization. The extent to which the operating system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001274, which more directly addresses specific alerts to be sent to mobile device management.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001311The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000205-NA<GroupDescription></GroupDescription>SRG-OS-000205-NAThe mobile operating system must not include authentication credentials or other sensitive information in audit records.<VulnDiscussion>Any operating system providing too much information in error logs and in administrative messages to the screen, risks compromising the data and security of the structure and content of error messages needs to be carefully considered by the organization.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001312The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000206-NA<GroupDescription></GroupDescription>SRG-OS-000206-NAThe operating system must reveal error messages to authorized personnel only.<VulnDiscussion>If the operating system provides too much information in error logs and administrative messages to the screen, it could lead to compromise. The structure and content of error messages need to be carefully considered by the organization.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. The user requires access to error messages when disconnected from the enterprise network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001314The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000207-NA<GroupDescription></GroupDescription>SRG-OS-000207-NAThe operating system must support the requirement that organizations, if an information system component failure is detected, must activate an organization defined alarm and/or automatically shuts down the operating system.<VulnDiscussion>Predictable failure prevention requires organizational planning to address system failure issues. If a subsystem of the operating system, hardware, or the operating system itself, is key to maintaining systems and security fails to function, the system could continue operating in an insecure state. The organization must be prepared for and the operating system must support capability that alarms for such conditions and/or automatically shuts down the operating system or the subsystem of the operating system.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001328The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000208-NA<GroupDescription></GroupDescription>SRG-OS-000208-NAThe operating system must associate the identity of the information producer with the information.<VulnDiscussion>Non-repudiation supports audit requirements to provide the appropriate organizational officials the means to identify who produced specific information in the event of an information transfer.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001338The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000209-MOS-000112<GroupDescription></GroupDescription>SRG-OS-000209-MOS-000112The mobile operating system must validate the digital signature on signed software components or applications.<VulnDiscussion>Digital signatures on software components and applications are primary means to determine that the code comes from a trusted source and has not been modified. If the operating system does not validate these digital signatures, then there is the potential for malware to infiltrate the device. Validating digital signatures assures that the digital signature control properly mitigates the risk that malware will be installed or execute on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001339Configure the operating system to validate the digital signature on signed software components or applications.Review system documentation and operating system configuration to determine if the digital signatures on software components and applications are being validated. If higher assurance is required, provide the operating system with a software application that has an invalid signature to verify the operating system can detect the invalid signature. If the system fails this test or documentation or configuration shows that the capability is not present, this is a finding.SRG-OS-000210-NA<GroupDescription></GroupDescription>SRG-OS-000210-NAThe operating system must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released.<VulnDiscussion>When it comes to data review and data release, there must be a correlation between the reviewed data 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 operating system associates the identity of the reviewer of the information to be released with the information and the information label.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Therefore, the chain of custody is not relevant to activities on the device itself. Chain of custody is critical to the handling of audit records in the context of the enterprise audit logging system. The Mobile Device Management SRG addresses enterprise logging requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001340The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000211-NA<GroupDescription></GroupDescription>SRG-OS-000211-NAThe operating system 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.<VulnDiscussion>This non-repudiation control enhancement is intended to mitigate the risk that information could be modified between review and transfer/release particularly when the transfer is occurring between security domains.
Rationale for non-applicability: For the purposes of this SRG, a mobile OS is assumed to support a single security domain and a single user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001341The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000213-NA<GroupDescription></GroupDescription>SRG-OS-000213-NAThe operating system must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists.<VulnDiscussion>It is critical when an operating 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.
Rationale for non-applicability: This CCI is not appropriate for a mobile device. Automatic disabling of devices poses a safety risk to mobile users who may have no other means of communication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001343The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000214-MOS-000113<GroupDescription></GroupDescription>SRG-OS-000214-MOS-000113The mobile operating system must alert the Mobile Device Management or Intrusion Detection and Prevention System when it detects integrity check failures.<VulnDiscussion>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. Alerting the Mobile Device Management (MDM) or Intrusion Detection and Prevention System (IDPS) mitigates the potential for attacks triggering integrity failures to have further consequences to the enterprise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001274Configure the operating system to alert the MDM or IDPS when it has detected integrity check failures.Review system documentation and operating system configuration to determine if the operating system alerts an MDM or IDPS when it has detected an integrity check failure. Review MDM and IDPS logs to verify such reporting is occurring, perhaps forcing an integrity failure if one does not appear in the audit record. If the operating system is not configured to alert an MDM or IDPS in the event of an integrity failure, this is a finding.SRG-OS-000215-NA<GroupDescription></GroupDescription>SRG-OS-000215-NAThe operating system must back up audit records on an organization defined frequency onto a different system or media than the system being audited.<VulnDiscussion>Protection of log data includes assuring the 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: Combined consideration of storage resource constraints and the required relationship between auditing, logging, and back-end MDM servers this functionality is more appropriately required of the back-end MDM server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001348The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000218-NA<GroupDescription></GroupDescription>SRG-OS-000218-NAThe operating system must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format.<VulnDiscussion>Audits records can be generated from various components within the operating 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: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001353The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000219-NA<GroupDescription></GroupDescription>SRG-OS-000219-NAThe operating system must monitor for atypical usage of operating system accounts.<VulnDiscussion>Atypical account usage is behavior that is not part of normal usage cycles, e.g., accounts logging in after hours or on weekends.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account that may use the device at any time without a predictable usage pattern. Usage will vary depending on the mission and may change whenever the mission requires a rapid response.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001356The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000220-NA<GroupDescription></GroupDescription>SRG-OS-000220-NAThe operating system must enforce an organization defined Discretionary Access Control (DAC) policy that must allow users to specify and control sharing by named individuals or groups of individuals, or by both.<VulnDiscussion>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) in the operating system.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. This single human user on the device does not need to set up sharing with other users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001362The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000221-NA<GroupDescription></GroupDescription>SRG-OS-000221-NAThe operating system must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001368The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000222-NA<GroupDescription></GroupDescription>SRG-OS-000222-NAThe operating system, when transferring information between different security domains, must implement policy filters constraining data structure and content to organization defined information security policy requirements.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001372The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000223-NA<GroupDescription></GroupDescription>SRG-OS-000223-NAThe operating system, when transferring information between different security domains, must detect unsanctioned information.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001373The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000224-NA<GroupDescription></GroupDescription>SRG-OS-000224-NAThe operating system, when transferring information between different security domains, must prohibit the transfer of unsanctioned information in accordance with the security policy.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an operating system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001374The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000225-NA<GroupDescription></GroupDescription>SRG-OS-000225-NAThe operating system must uniquely identify source domains for information transfer.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001376The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000226-NA<GroupDescription></GroupDescription>SRG-OS-000226-NAThe operating system must uniquely authenticate source domains for information transfer.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001377The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000227-MOS-000114<GroupDescription></GroupDescription>SRG-OS-000227-MOS-000114The mobile operating system must wipe all storage media after an organization defined number of consecutive, unsuccessful attempts to unlock the mobile device.<VulnDiscussion>Mobile devices present additional risks related to attempted unauthorized access. If they are lost, stolen, or misplaced, attempts can be made to unlock the device by guessing the password. Once unlocked, an adversary may be able to obtain sensitive data on the device. Wiping storage media renders all such data permanently inaccessible.
There are two acceptable methods to wipe the device. The first is to overwrite the data on the media several times, so it is not longer recoverable. In this case, the device should implement DoD 5220.22-M (E) (3pass), in which the media is overwritten three times. The second is to delete the locally stored encryption key on a device that encrypts all data stored on the device. In this case, the key must be wiped using a method complying with DoD 5220.22-M (ECE) (7 pass), in which all storage sectors containing the key are overwritten seven times. When the mobile device employs flash media, alternative methods consistent with those described in NIST SP 800-88 (as revised) are acceptable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001383Configure the operating system to wipe the mobile device after an organization defined number of consecutive, unsuccessful attempts to unlock it.Review mobile operating system configuration to determine if the system wipes all storage media after an organization defined number of consecutive, unsuccessful attempts to unlock the mobile device. Check if the chosen wipe method is compliant with DoD 5220.22-M, using at least three passes for data and at least 7 for keys, or an alternative method described in NIST SP 800-88 (as revised). If feasible, on a spare device, test if the control is enforced by entering the requisite number of incorrect passwords. The device should be inoperable after the wipe process. If the system is not configured for the device wipe functionality, this is a finding.SRG-OS-000227-MOS-000115<GroupDescription></GroupDescription>SRG-OS-000227-MOS-000115The mobile operating system must wipe data on both embedded storage and removable media when performing a data wipe function.<VulnDiscussion>Sensitive data may be resident on both embedded and removable memory. If the operating system only performs the wipe function on one type of memory, then this will leave the other vulnerable. Ensuring the wipe occurs on both embedded and removable memory mitigates this risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001383Configure the operating system to wipe data on both internal memory and removable media when performing a data wipe function.Review system documentation and operating system configuration to determine if mobile operating system wipes data on both embedded and removable memory when performing a data wipe function. If feasible, on a spare device, test that the control is enforced by entering the requisite number of incorrect passwords. If the system is not configured to wipe both embedded and removable memory, this is a finding.SRG-OS-000227-MOS-000116<GroupDescription></GroupDescription>SRG-OS-000227-MOS-000116The mobile operating system maximum number of consecutive unsuccessful unlock attempts must be configurable within a range from 5 to 10.<VulnDiscussion>The recommended setting for the maximum number of consecutive unsuccessful unlock attempts is 10. In some environments, a lower number may be needed to provide greater protection of sensitive information. Allowing for configuration enables the local command to enforce greater protection when it is deemed necessary. If the limit is not configurable, then it is permissible for a site to procure and deploy devices that enforce the limit specified by the organization, so long as that limit does not exceed 10.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001383Configure the mobile operating system maximum number of consecutive unsuccessful unlock attempts to be between 5 and 10.Review system documentation and operating system configuration to determine if the maximum number of consecutive unsuccessful unlock attempts is configurable within a range from 3 to 10. If this operating system parameter is not configurable, check that the operating system nonetheless supports the limit specified by the organization, which is an acceptable alternative. If the limit is not configurable and is not compliant with the organization defined limit or the limit exceeds 10, this is a finding.SRG-OS-000228-NA<GroupDescription></GroupDescription>SRG-OS-000228-NAThe operating system for publicly accessible systems must display the system use information when appropriate, before granting further access.<VulnDiscussion>Requirement applies to publicly accessible systems. 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.
Rationale for non-applicability: A mobile OS typically does not host publically accessible data or services.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001384The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000229-MOS-000117<GroupDescription></GroupDescription>SRG-OS-000229-MOS-000117The mobile operating system must employ mobile device management services to centrally manage security relevant configuration and policy settings.<VulnDiscussion>Security related parameters are those parameters impacting the security state of the system and include parameters related to the implementation of other IA controls. If these controls are not implemented, the system may be vulnerable to a variety of attacks. The use of mobile device management (MDM) allows an organization to assign values to security related parameters across all the devices it manages. This provides assurance that the required mobile OS security controls are being enforced, and that the device user or an adversary has not modified or disabled the controls. It also greatly increases efficiency and manageability of devices in a large scale environment relative to an environment in which each device must be configured separately. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000370Implement an MDM system to centrally manage configuration settings.Inspect a sample of mobile devices and the MDM to verify the MDM is being used to centrally manage the devices. Ask a system administrator to push a temporary configuration setting to one of the devices to validate the MDM configuration capability is operational.
The mobile OS must support the ability of an MDM to enable or disable the following device interfaces:
- Wi-Fi
- Bluetooth
- Global Positioning System (GPS) receiver
- Near-field communications
- Infrared port
- Microphone
- Camera
- Memory card port
- USB port
The mobile OS must further support the ability of an MDM to restrict how these interfaces are used when they are enabled. Required managed functions include the ability to enable or disable:
- Over the air provisioning
- USB tethering
- Automatic connection to known Wi-Fi sites
- Personal hotspot functionality
- Bluetooth profiles other than the serial port, headset, hands free, or phone book profiles
- Bluetooth discoverable mode
- VPN split tunneling functionality
- Audio recording functionality
- Video recording functionality
- Location services
- Short message service (SMS)
- Multimedia messaging service (MMS)
- USB mass storage mode
- Availability of contact database information when device is locked
- Contact database fields available outside the contact application
The mobile OS also must support the ability of an MDM to enforce the following security related configuration parameters:
- Device unlock password
- Device unlock password complexity
- Duration of inactivity before device lock
- Encryption of data on storage media
- Encryption of data in transit
- Permitted applications (application white list)
- Prohibited web sites (web site blacklist)
- Web proxy URL
Finally, the mobile operating system must enforce the ability of the MDM agent application to scan the device for security policy compliance at a periodic interval configured on the agent, and initiate commands to wipe storage media.
If the MDM does not manage any of the required settings listed above, this is a finding.SRG-OS-000230-MOS-000118<GroupDescription></GroupDescription>SRG-OS-000230-MOS-000118The mobile operating system must encrypt all data on the mobile device using AES encryption (AES 128 bit encryption key length is the minimum requirement; AES 256 desired).<VulnDiscussion>If data at rest is unencrypted, it is vulnerable to disclosure. Even if the operating system enforces permissions on data access, an adversary can remove non-volatile memory and read it directly, thereby circumventing operating system controls. Encrypting the data ensures that confidentiality is protected even when the operating system is not running. AES encryption with appropriate key lengths provides assurance that the cryptography is adequate.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001200Configure the operating system to encrypt all data on the mobile device using AES encryption.Review system documentation and operating system configuration to verify the operating system encrypts all data using AES encryption. All data includes data on removable memory, such as SD cards. Any NIST-approved mode of AES is acceptable. If the operating system does not encrypt data at rest, or does so only selectively, or does so using an encryption algorithm other than AES (for unclassified data), this is a finding.SRG-OS-000230-MOS-000119<GroupDescription></GroupDescription>SRG-OS-000230-MOS-000119The mobile operating system must require a valid password be successfully entered before the mobile device data is unencrypted.<VulnDiscussion>Encryption is only effective if the decryption procedure is protected. If an adversary can easily access the private key (either directly or through a software application), sensitive DoD data is likely to be disclosed. Password protection is one method to reduce the likelihood of such an occurrence.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001200Configure the operating system to require a valid password be successfully entered before the mobile device data is unencrypted.Verify the mobile operating system configuration is set to prompt for a password prior to unencrypting data on the mobile device. In many cases, the transaction may involve the entry of a CAC PIN, which still satisfies the requirement. If data is accessible without entering a password at any point when using the device, this is a finding.SRG-OS-000230-MOS-000120<GroupDescription></GroupDescription>SRG-OS-000230-MOS-000120The mobile operating system must re-encrypt all device data when the device is locked.<VulnDiscussion>Data at rest refers to all stored data on a mobile device that will include the address book and other PII, data created by a user when using some applications, as well as data received, such as emails. If data is not encrypted upon the lock of the device, there is the potential for an adversary to remove non-volatile memory from the device and read it directly using tools for that purpose. This attack would render other operating system controls useless. Encrypting all data at rest provides assurance that it will be protected even when memory is physically removed from the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001200Configure the operating system to re-encrypt all device data in memory when the device is locked or unexpectedly shuts down.Review system documentation and other IA information resources to determine how the operating system treats data in memory upon locking the device. The operating system may enforce this requirement through a variety of means. The reviewer should focus on the fact that the data is encrypted when the device has been locked or unexpectedly shuts down - not on the timing of the encryption, much of which might occur prior to device lock. If it is determined that unencrypted data still resides on the device after device lock, this is a finding.SRG-OS-000231-MOS-000121<GroupDescription></GroupDescription>SRG-OS-000231-MOS-000121The mobile operating system must prohibit wireless remote access connections except for personal hotspot service.<VulnDiscussion>The device acts as a personal hotspot when it accepts remote connections on a local area network interface for the purposes of routing traffic to a wide area network interface. The most common implementation is to accept local area Wi-Fi connections to reach ISP service provided by a cellular data carrier. The objective is to ensure the remote devices are not able to access any applications, data, or other operating system functionality on the device. A core assumption of the MOS SRG is that mobile devices do not serve applications to remote devices. This control concerns remote access to the devices OS; if remote access to applications and data were feasible, this would open up a wide variety of vulnerabilities in which an adversary with a remote wireless capability could breach system security. Precluding this possibility greatly mitigates the risk of such an attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000066Configure the operating system to prohibit remote access connections for anything other than personal hotspot service.Review the mobile operating system configuration to assess how the mobile OS handles remote connections. Establish a remote connection to the device over its local area network interface. Determine if applications or data are accessible. If either an application or data is accessible, this is a finding.SRG-OS-000231-MOS-000122<GroupDescription></GroupDescription>SRG-OS-000231-MOS-000122The mobile operating system must authenticate tethered connections to the device.<VulnDiscussion>Authentication may occur either by reentry of the device unlock passcode at the time of connection, through another passcode with the same or stronger complexity, or through PKI certificates. Authentication mitigates the risk that an adversary who obtains physical possession of the device is not able to use the tethered connection to access sensitive data on the device or otherwise tamper with its operating system or applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000066Configure the operating system to require authentication of tethered connections.Review the mobile operating system configuration to assess how the mobile OS handles tethered connections. Determine if authentication is required to establish a tethered connection. If authentication is not required, this is a finding.SRG-OS-000232-MOS-000123<GroupDescription></GroupDescription>SRG-OS-000232-MOS-000123The mobile operating system must use automated mechanisms to detect the presence of unauthorized software on organizational information systems and notify designated organizational officials in accordance with the organization defined frequency.<VulnDiscussion>Unauthorized software poses a risk to the device because it could potentially perform malicious functions, including but not limited to gathering sensitive information, searching for other system vulnerabilities, or modifying log entries. A mechanism to detect unauthorized software and notify officials of its presence assists in the task of removing such software to eliminate the risks it poses to the device and the networks to which the device attaches.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001069Configure the operating system to detect the presence of unauthorized applications and report this information to designated organizational officials.Review system documentation and operating system configuration to determine whether and how the operating system detects and reports the presence of unauthorized software. If feasible, install a test application that is authorized for such purpose, but which the system does not recognize as authorized. Verify the operating system detects the test application and reports it. If the operating system either fails to detect an authorized application or fails to report this (or both), this is a finding.SRG-OS-000233-NA<GroupDescription></GroupDescription>SRG-OS-000233-NAThe operating system must notify the user of the number of successful logins/accesses that occur during the organization defined time period.<VulnDiscussion>Users need to be aware of activity that occurs regarding their 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.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001391The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000234-NA<GroupDescription></GroupDescription>SRG-OS-000234-NAThe operating system must notify the user of the number of unsuccessful login/access attempts that occur during organization defined time period.<VulnDiscussion>Users need to be aware of activity that occurs regarding their 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.
Rationale for non-applicability: This control is better addressed by CCI-000053, which also covers notification to users of unsuccessful logon attempts. CCI-001392 incorporates the notion of a time period that is not utilized in mobile OS.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001392The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000235-NA<GroupDescription></GroupDescription>SRG-OS-000235-NAThe operating system must notify the user of organization defined security-related changes to the users account that occur during the organization defined time period.<VulnDiscussion>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 that requires the user be notified. In those instances where organizations define such events, the operating system must notify the affected user or users.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001395The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000236-MOS-000124<GroupDescription></GroupDescription>SRG-OS-000236-MOS-000124The mobile operating system must maintain the binding of digital signatures on software components and applications in storage.<VulnDiscussion>Digital signatures enable the system to verify the integrity of the signed object and authenticate the object's signatory. Failure to maintain the binding of digital signatures on software components and applications in storage makes it more likely that an adversary could modify or replace those objects. Conversely, the bindings enable the operating system to verify the software's integrity and source with a high degree of assurance whenever necessary.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001399Configure the operating system to maintain the binding of digital signatures on software components and applications in storage.Review the mobile operating system configuration for maintaining binding of digital signatures to software objects when those objects are stored after installation. If these bindings are not maintained in storage, this is a finding.SRG-OS-000237-MOS-000125<GroupDescription></GroupDescription>SRG-OS-000237-MOS-000125The mobile operating system must maintain the binding of digital signatures on software components and applications in process.<VulnDiscussion>Digital signatures enable the system to verify the integrity of the signed object and authenticate the object's signatory. Failure to maintain the binding of digital signatures on software components and applications in process makes it more likely that an adversary could modify or replace those objects when the software is executed. The bindings enable the operating system to verify the software's integrity and source just before the execution process.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001400Configure the operating system to maintain the binding of digital signatures on software components and applications in process.Review the mobile operating system configuration for maintaining binding of digital signatures to software objects when those objects are in process. If these bindings are not maintained during processing, this is a finding.SRG-OS-000238-NA<GroupDescription></GroupDescription>SRG-OS-000238-NAThe operating system must support and maintain the binding of organization defined security attributes to information in transmission.<VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system 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 information security policy.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001401The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000239-NA<GroupDescription></GroupDescription>SRG-OS-000239-NAThe operating system must automatically audit account modification.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Traditional auditing of account management functions is not required in this context.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001403The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000240-NA<GroupDescription></GroupDescription>SRG-OS-000240-NAThe operating system must automatically audit account disabling actions.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Traditional auditing of account management functions is not required in this context.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001404The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000241-NA<GroupDescription></GroupDescription>SRG-OS-000241-NAThe operating system must automatically audit account termination.<VulnDiscussion>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.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Traditional auditing of account management functions is not required in this context.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001405The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000242-NA<GroupDescription></GroupDescription>SRG-OS-000242-NAThe operating system must enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001414The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000243-NA<GroupDescription></GroupDescription>SRG-OS-000243-NAThe operating system must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined.<VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data 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 information security policy.
Rationale for non-applicability: Digitally signed attributes on software objects are never modified.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001424The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000244-NA<GroupDescription></GroupDescription>SRG-OS-000244-NAThe operating system must only allow authorized entities to change security attributes.<VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the system 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 information security policy.
Rationale for non-applicability: Digitally signed attributes on software objects are never modified.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001425The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000245-NA<GroupDescription></GroupDescription>SRG-OS-000245-NAThe operating system maintains the binding of security attributes to information with sufficient assurance that the information attribute association can be used as the basis for automated policy actions.<VulnDiscussion>The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as: the means used to associate a set of security attributes with a specific information object as part of the data structure for that object.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001426The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000246-NA<GroupDescription></GroupDescription>SRG-OS-000246-NAThe operating system must only allow authorized users to associate security attributes with information.<VulnDiscussion>The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for that object.
Rationale for non-applicability: Digitally signed attributes on software objects are never modified.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001427The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000247-NA<GroupDescription></GroupDescription>SRG-OS-000247-NAThe operating system must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization identified set of special dissemination, handling, or distribution instructions using organization identified human-readable, standard naming conventions.<VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the information system 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 information security policy.
Rationale for non-applicability: Security attributes will not be displayed to a user of a mobile device outside of a mobile application. The Mobile Application SRG includes this IA control.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001428The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000248-NA<GroupDescription></GroupDescription>SRG-OS-000248-NAThe operating system must disable the use of organization defined networking protocols within the operating system deemed to be nonsecure except for explicitly identified components in support of specific operational requirements.<VulnDiscussion>Some networking protocols may not meet security requirements to protect data and components. The organization can either make a determination as to the relative security of the networking protocol or base the security decision on the assessment of other entities. Based on that assessment some may be deemed to be nonsecure except for explicitly identified components in support of specific operational requirements.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001118, which requires host-based firewall with same functionality as described here.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001436The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000249-NA<GroupDescription></GroupDescription>SRG-OS-000249-NAThe operating system must enforce the organization defined time period during which the limit of consecutive invalid access attempts by a user is counted.<VulnDiscussion>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 devices are more likely to be lost or stolen, and therefore more likely to be subjected to a slow password attack. Therefore, users will not be permitted to engage in further attempts after a defined time period. Per CCI 1383, if the user cannot successfully authenticate within an organization defined number of attempts, the mobile device is wiped regardless of the time period. In effect, the required time period is infinite.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001452The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000250-NA<GroupDescription></GroupDescription>SRG-OS-000250-NAThe operating system must use cryptography to protect the integrity of remote access sessions.<VulnDiscussion>Remote access is any access to an organizational operating system by a user (or an information system) communicating through an external, non-organization-controlled network.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001145, which addresses general remote access requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001453The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000251-MOS-000126<GroupDescription></GroupDescription>SRG-OS-000251-MOS-000126The mobile operating system must log an audit event for each instance when a remote process uses MDM mechanisms for accessing the device security configuration settings.<VulnDiscussion>Mobile device management (MDM) provides IA services to mobile devices but it also represents a threat to those devices. If an adversary were able to take control of the MDM or masquerade as the MDM, then it could use that ability to relax IA controls and breach the mobile device. Logging MDM events enables better traceability to mistaken or unauthorized MDM transactions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001454Configure the operating system to log an audit event for each instance when a remote process uses MDM mechanisms for accessing the device security configuration settings.Use the MDM to perform a temporary and relatively innocuous security configuration change on a small sample of devices. Verify the operating system logged this event. If there is a not an audit entry for this event, this is a finding.SRG-OS-000252-NA<GroupDescription></GroupDescription>SRG-OS-000252-NAThe operating system must provide the capability to capture/record and log all content related to a user session.<VulnDiscussion>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: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001462The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000253-NA<GroupDescription></GroupDescription>SRG-OS-000253-NAThe operating system must enforce a Discretionary Access Control (DAC) policy that includes or excludes access to the granularity of a single user.<VulnDiscussion>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) in the operating system.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001694The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000254-MOS-000127<GroupDescription></GroupDescription>SRG-OS-000254-MOS-000127The operating system must initiate security auditing at system start-up.<VulnDiscussion>The audit capability is most effective if it is running at all times. Otherwise there may be time gaps in the audit logs in which an adversary can hide malicious behavior. Initiating security auditing at system start-up mitigates the risk that there will be time periods in which auditing is not active.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001464Configure the operating system to initiate security auditing at system start-up.Verify the mobile operating system configuration initiates auditing at system startup. Access to the audit logs may only be possible through mobile device management services. If security auditing is not operational after system start-up, this is a finding.SRG-OS-000255-MOS-000128<GroupDescription></GroupDescription>SRG-OS-000255-MOS-000128The mobile operating system must produce audit records containing sufficient information to establish the identity of any user or subject associated with the event.<VulnDiscussion>Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
Without sufficient information establishing what type of audit events occurred, investigation into the severity of events is severely hindered. As defined in RFC 5424 "The Syslog Protocol", event severity levels allow system administrators and IA personnel to more easily identify critical system issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001487Configure the mobile operating system to produce audit records containing sufficient information to establish the identity of any user or subject associated with the event.Examine the mobile operating system configuration for producing audit records containing sufficient information to establish the identity of any user or subject associated with the event. If the audit records do not contain sufficient information to establish identity, this is a finding.SRG-OS-000256-NA<GroupDescription></GroupDescription>SRG-OS-000256-NAThe operating system must protect audit tools from unauthorized access.<VulnDiscussion>Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.
Rationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001493The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000257-NA<GroupDescription></GroupDescription>SRG-OS-000257-NAThe operating system must protect audit tools from unauthorized modification.<VulnDiscussion>Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.
Rationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001494The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000258-NA<GroupDescription></GroupDescription>SRG-OS-000258-NAThe operating system must protect audit tools from unauthorized deletion.<VulnDiscussion>Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.
Rationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001495The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000259-MOS-000129<GroupDescription></GroupDescription>SRG-OS-000259-MOS-000129The mobile operating system must prohibit modifications to software libraries unless performed as part of a software installation or update from a trusted source.<VulnDiscussion>When dealing with change control issues, it should be noted that any changes to the hardware, software, and/or firmware components of the operating system can potentially have significant effects on the overall security of the system.
Only authorized individuals must be allowed to obtain access to mobile device components for purposes of initiating changes, including upgrades and modifications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001499Configure the mobile operating system to prohibit modifications to software libraries unless performed as part of a software installation or update from a trusted source.Examine the mobile operating system configuration for prohibiting modifications to software libraries unless performed as part of a software installation or update from a trusted source. If modifications are allowed to software libraries outside of software installation or update, this is a finding.SRG-OS-000260-MOS-000130<GroupDescription></GroupDescription>SRG-OS-000260-MOS-000130The mobile operating system must disable the mobile device upon the MDM agents instruction, permitting someone in possession of the device to make emergency 911 calls only.<VulnDiscussion>Under some conditions, a compromised device represents a threat to other computing resources on the network. For example, a compromised device may attempt to conduct a denial of service attack on other devices, or may be executing a mechanism to spread malware before a countermeasure has been put in place. In these situations, it is critical that mobile device management (MDM) be able to disable the device to protect other network resources. Disabling the device means disabling all user functionality with the exception of making emergency 911 calls. Disabling the device may, but needs not, render the device or resident data permanently inaccessible. For example, the MDM may lock the device such that it cannot be unlocked without an additional MDM instruction, but preserve data and applications if the device is later unlocked. Actions to restore the device to factory defaults still permit user functionality and therefore do not qualify as disabling the device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001500Configure the mobile operating system and MDM such that an MDM can disable the device.Verify the mobile operating system configuration can disable the mobile device upon the MDM agent's instruction, while still permitting someone in possession of the device to make emergency 911 calls. The site may provide log evidence for mobile devices that have been disabled in the past. If the mobile operating system does not allow the MDM agent to disable the mobile device, this is a finding.SRG-OS-000261-NA<GroupDescription></GroupDescription>SRG-OS-000261-NAThe operating system uniquely must identify destination domains for information transfer.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross domain solutions and are not within the scope of the Mobile Operating System SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001555The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000262-NA<GroupDescription></GroupDescription>SRG-OS-000262-NAThe operating system uniquely must authenticate destination domains for information transfer.<VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that the information.
Rationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross domain solutions and are not within the scope of the Mobile OS SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001556The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000263-NA<GroupDescription></GroupDescription>SRG-OS-000263-NAThe operating system must track problems associated with the information transfer.<VulnDiscussion>When an operating system transfers data, there is the chance an error or problem with the data transfer may occur. The operating system needs to track failures and any problems encountered when performing data transfers, so problems can be identified and remediated.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001557The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000264-NA<GroupDescription></GroupDescription>SRG-OS-000264-NAThe operating system must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights.<VulnDiscussion>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) in the operating system.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001693The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000265-NA<GroupDescription></GroupDescription>SRG-OS-000265-NAThe operating system must ensure unauthorized, security relevant configuration changes detected are tracked.<VulnDiscussion>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.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001297, which deals with detection of unauthorized changes to software and data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001589The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000266-NA<GroupDescription></GroupDescription>SRG-OS-000266-NAThe operating system must enforce password complexity by the number of special characters used.<VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute force attacks. Requiring a minimum number of special characters is one way to increase the complexity of the password and make it less likely that it will be compromised. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.
Rationale for non-applicability: Given the inconvenience of entering special characters on some keyboards of mobile devices, a risk assessment determined that it would be acceptable to have device unlock passwords without special characters.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001619The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000267-NA<GroupDescription></GroupDescription>SRG-OS-000267-NAThe operating system must protect non-local maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths or logically separated communications paths.<VulnDiscussion>This is a requirement that maintenance needs to be done on a separate interface or encrypted channel to segment maintenance activity from regular usage. When performing non-local maintenance, there is a possibility of the session being monitored and replayed to gain unauthorized access into a system.
Rationale for non-applicability: Authentication requirements for device connections and software updates provide adequate IA in this context. The existence of out of band connections is not particularly meaningful in the context of a wireless communications device where all wireless interfaces share the same medium of the electromagnetic spectrum. Management of the mobile device does not occur over a separate physical or virtual network. If management sessions are authenticated and protected by cryptography, separating the session into a separate virtual network is unnecessary.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001632The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000268-NA<GroupDescription></GroupDescription>SRG-OS-000268-NAThe operating system must take corrective actions, when unauthorized mobile code is identified.<VulnDiscussion>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.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation. The handling of unauthorized mobile code is within the scope of the Mobile Application SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001662The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000269-NA<GroupDescription></GroupDescription>SRG-OS-000269-NAThe operating system must preserve organization defined system state information in the event of a system failure.<VulnDiscussion>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 operating system or a component of the system.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001665The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000270-MOS-000132<GroupDescription></GroupDescription>SRG-OS-000270-MOS-000132The mobile operating system must employ malicious code protection mechanisms to detect and eradicate malicious code from installing and executing.<VulnDiscussion>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. Malicious code can result in the disclosure of sensitive information or cause a denial of service. Anti-virus applications are not common on mobile operating systems but one or more methods to mitigate the risk of malware must be in place to protect DoD information and networks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-001668Configure the mobile operating system to employ malicious code protection mechanisms to detect and eradicate malicious code from installing and executing.Review the mobile operating system configuration for employing malicious code protection mechanisms to detect and eradicate malicious code from installing and executing. If malicious code protection is missing or inadequate, this is a finding.SRG-OS-000271-NA<GroupDescription></GroupDescription>SRG-OS-000271-NAThe operating system must take organization defined list of least disruptive actions to terminate suspicious events.<VulnDiscussion>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 the operating system takes to terminate suspicious events. The least disruptive actions may include initiating a request for human response.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001274, which defines "least disruptive" response in this context.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001670The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000272-NA<GroupDescription></GroupDescription>SRG-OS-000272-NAThe operating system must respond to security function anomalies in accordance with organization defined responses and alternative action(s).<VulnDiscussion>The need to verify security functionality applies to all security functions.
Rationale for non-applicability: This vulnerability is better addressed by CCI-001297, which addresses responding to unauthorized changes to software and data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001674The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000273-NA<GroupDescription></GroupDescription>SRG-OS-000273-NAThe operating system must enforce requirements for the connection of mobile devices to operating systems.<VulnDiscussion>Wireless access introduces security risks which must be addressed through implementation of strict controls and procedures, such as authentication, encryption, and defining what resources that can be accessed. The organization will define the requirements for connection of mobile devices. In order to ensure the connection provides adequate integrity and confidentiality of the connection, the operating system must enforce these requirements.
Rationale for non-applicability: A mobile OS typically does not serve applications to remote clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-000086The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000274-NA<GroupDescription></GroupDescription>SRG-OS-000274-NAThe operating system must notify, as required, appropriate individuals when accounts are created.<VulnDiscussion>Monitoring account creation is critical to ensure only appropriate personnel have access to the operating system. This reduces the possibility a rogue account will be created. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is created.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001683The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000275-NA<GroupDescription></GroupDescription>SRG-OS-000275-NAThe operating system must notify, as required, appropriate individuals when accounts are modified.<VulnDiscussion>Monitoring account modification is critical to ensure only appropriate personnel have access to the operating system. This reduces the possibility that an account will be given more access than is intended. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is modified.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001684The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000276-NA<GroupDescription></GroupDescription>SRG-OS-000276-NAThe operating system must notify, as required, appropriate individuals when an account is disabled.<VulnDiscussion>Monitoring account disabling is critical to ensure a denial of service situation does not exist on the operating system. An unexpected account deletion can also be a sign that there is a rogue administrator account that may be deleting traces of activity. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is disabled.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001685The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000277-NA<GroupDescription></GroupDescription>SRG-OS-000277-NAThe operating system must notify, as required, appropriate individuals for account termination.<VulnDiscussion>Monitoring account termination is critical to ensure a denial of service situation does not exist on the operating system. An unexpected account termination can also be a sign that there is a rogue administrator account that may be deleting traces of activity. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is terminated.
Rationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001686The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000278-NA<GroupDescription></GroupDescription>SRG-OS-000278-NAThe operating system must use cryptographic mechanisms to protect the integrity of audit tools.<VulnDiscussion>Auditing and logging are key components of any security architecture. It is essential security personnel know what is being done, what attempted to be done, where it was done, when it was done, and by whom in order to compile an accurate risk assessment. Cryptographic mechanisms must be used to protect the integrity of the audit tools used for audit reduction and reporting.
Rationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools. Audit tool functionality is required in the MDM SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001496The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-999999-MOS-000133<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000133The mobile operating system must disallow more than an organizationally-defined quantity of sequential numbers (e.g., 456) in the device unlock password.<VulnDiscussion>Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Passwords with sequential numbers (e.g., 456 or 987) are considered easier to crack than random patterns. Therefore, disallowing sequential numbers makes it more difficult for an adversary to discover the password.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the mobile operating system to disallow more than an organizationally-defined quantity of sequential numbers in the device unlock password. Review the mobile operating system password complexity configuration settings to determine if the device unlock password disallows more than an organizationally-defined quantity of sequential numbers (e.g., 456). If password complexity configuration settings do not require the device unlock password to disallow more than the organizationally-defined quantity of sequential numbers, this is a finding.SRG-OS-999999-MOS-000134<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000134The mobile operating system must not permit a user to disable the password-protected lock feature on the device.<VulnDiscussion>If the user is able to disable the password-protected lock feature, the user can change the configuration of the device to allow access without a password. The modified configuration would enable an adversary with access to the device to obtain DoD information and possibly other information resources on other systems. An operating system that does not allow a user to disable this feature mitigates the risk of this attack. In cases in which the mobile operating system relies on another application for protected data storage (e.g., if FIPS 140-2 validated encryption for unclassified use is not native to the device), then this requirement applies to both the device lock password and the password to the data storage application.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the operating system to prohibit a user from disabling the password-protected lock feature.Review the mobile operating system configuration for prohibiting a user to disable the password-protected lock feature on the device. If the mobile operating system allows the user to disable the password-protected lock feature, this is a finding.SRG-OS-999999-MOS-000135<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000135The mobile operating system must not permit a user to disable or modify the security policy or enforcement mechanisms on the device.<VulnDiscussion>The integrity of the security policy and enforcement mechanisms is critical to the IA posture of the operating system. If a user can modify a device's security policy or enforcement mechanisms, then a wide range of subsequent attacks are possible, including unauthorized access to information and networks. Access controls that prevent a user from making modifications, such as these, mitigate the risk of operating system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the operating system to prohibit a user from disabling or modifying the security policy or enforcement mechanisms on the device.Review the mobile operating system configuration for prohibiting the user from modifying the security policy and related enforcement mechanisms. If the mobile operating system allows the user to modify the security policy and related enforcement mechanisms on the mobile device, this is a finding.SRG-OS-999999-MOS-000136<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000136The mobile operating system must not cache smartcard or certificate store passwords for more than an organizationally-defined time period.<VulnDiscussion>The longer passwords remain in the cache, the more likely it is that malware or other mechanisms will discover them. Once an adversary has obtained a password from the cache, the adversary can further compromise the device and networks to which the device is attached. Minimizing the time passwords are stored in the cache mitigates the risk of this attack. The absence of caching altogether eliminates the risk. If caching is available, the caching period should be configurable with organizations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the operating system to prohibit caching of smartcard and certificate store passwords for longer than an organizationally-defined time period.Review the operating system configuration to verify smartcard and certificate store passwords are not cached for longer than an organizationally-defined time period. If this is not apparent from the configuration, perform a transaction requiring CAC. After entering the CAC PIN, perform another transaction to check that the system does not prompt for re-entry of the PIN. If it does not prompt for the PIN, caching is active. Then wait the organization defined time limit and perform the same transaction. If the system does not prompt for a PIN, then the system is caching credentials in excess of the time limit. Repeat this process for another service requiring access to the certificate store (e.g., web site using password protected soft certificate authentication). If the caching period is longer than organization defined time limit for either the smart card or the certificate store, this is finding.SRG-OS-999999-MOS-000137<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000137The mobile operating system must wipe the device upon the MDM agents instruction.<VulnDiscussion>If a system has been known to have been lost or stolen, there is increased risk that an adversary could obtain DoD data residing on the device. Similarly, in some cases system administrators may know or strongly suspect that a device contains malware or is compromised in a manner that poses a significant threat to the enterprise network. In such circumstances, the IAO may determine that the safest course of action is to have a systems administrator remotely issue a command to wipe all data on the device. This action would render the device inoperable and prevent anyone from accessing the data stored on it.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the operating system and MDM agent to permit the agent to wipe the device upon the appropriate command.Review system documentation and operating system configuration to determine if a systems administrator has the capability to remotely wipe all storage media on the device. If feasible, on a spare device, test that the control in enforced by using the remote mechanism to wipe the device. The device should be inoperable after the wipe process. If the system is not configured for the device wipe functionality, this is a finding.SRG-OS-999999-MOS-000138<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000138The mobile operating system must disable access to the devices contact database when the device is locked.<VulnDiscussion>On some devices, users can access the device's contact database to obtain phone numbers and other information using voice-activated Bluetooth peripherals even when the mobile device is locked. Often this information is personally identifiable information (PII), which is considered sensitive. It could also be used by an adversary to profile the user or engage in social engineering to obtain further information from other unsuspecting users. Disabling access to the contact database in these situations mitigates the risk of this attack. The DAA may waive this requirement with written notice if the operational environment requires this capability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the operating system to disable access to the device's contact database when the device is locked.Review the mobile operating system configuration to determine the ways in which someone can access the contact database, focusing on ways without viewing the display (e.g., voice commands or Bluetooth peripherals). If there are no such methods, there is no finding. If there are such methods, verify the effectiveness of the control. If the data can be accessed, this is a finding.
Exception:
Certain fields can be made accessible outside of the security container such as name, phone number, and pager number, etc. This exception will allow such capability as displaying a caller’s phone number when the device is locked or allowing a user to make a call from the contact list without unlocking the security container.SRG-OS-999999-MOS-000139<GroupDescription></GroupDescription>SRG-OS-999999-MOS-000139The mobile operating system must enable a system administrator to (i) select which data fields will be available to applications outside of the contact database application and (ii) limit the number of contact database fields accessible outside of a work persona in the case of dual persona phones.<VulnDiscussion>The contact database often contains a significant amount of information beyond each person's name and phone number. The records may contain addresses and other identifying or sensitive information that should not be revealed. There may be cases in which an organization has determined that it is an acceptable risk to distribute parts of person's contact record but not others. Enabling the system administrator to select which fields are available outside the contact database application (or to applications outside the work persona in the case of a dual persona device) assists with management of the risk.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000366Configure the operating system to enable a system administrator to select which data fields will be available to (i) applications outside of the contact database application and (ii) the work persona in the case of a dual persona phone. Review system documentation to determine if this capability is present. If it is not, this is a finding. If the capability is alleged to be present, ask the systems administrator to disable access to one of the fields in the contact database (e.g., organization name). This may be accomplished using an MDM system. Find an application that can access the contact database and verify the blocked field is inaccessible. If the phone is dual persona, repeat the prior test and attempt to access the contact database from an application external to the work persona. If it is accessible, this is a finding.SRG-OS-000146-NA<GroupDescription></GroupDescription>SRG-OS-000146-NAThe operating system must prevent public access into an organizations internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices.<VulnDiscussion>Access into an organization's internal network and to key internal boundaries must be tightly controlled and managed. In the case of the operating system, the key boundary may be the workstation on the public internet.
Rationale for non-applicability: Mobile devices operate outside of enclave boundary. The arrangement of boundary protection devices is outside the scope of their control. The boundary protection devices will enforce strong authentication for VPN and other network connections.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001100The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000147-MOS-000078<GroupDescription></GroupDescription>SRG-OS-000147-MOS-000078The mobile operating systems Bluetooth module must support the capability for a system administrator to create a non-user-modifiable white list of Bluetooth devices that are authorized to pair to the mobile device.<VulnDiscussion>If a rogue device can connect to the mobile device, there is the potential for the rogue device to obtain sensitive information. One mechanism for preventing this occurrence is to enforce a white list of devices that are permitted to pair to the mobile device. Devices not on the white list will not be able to pair with the mobile device and therefore cannot communicate with it or obtain sensitive information from it.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001109Configure the mobile operating system's Bluetooth module to support the capability for a system administrator to create a non-user-modifiable white list of Bluetooth devices that are authorized to pair to the mobile device.Examine the operating system configuration to verify the presence of a white list of Bluetooth devices authorized to pair to the mobile device. If the operating system does not support this functionality, this is a finding. If the operating system supports the white list functionality, attempt to pair a test Bluetooth device not on the white list with the mobile device. If it successfully pairs, this is a finding.SRG-OS-000148-NA<GroupDescription></GroupDescription>SRG-OS-000148-NAThe operating system must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communication path with resources in external networks.<VulnDiscussion>This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings not configurable by the user of the device. An example of a non-remote communications path from a remote device is a virtual private network (VPN). When a non-remote connection is established using a VPN, 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 the 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, in effect allowing unauthorized external connections into the system. This is a split-tunneling requirement that can be controlled via the operating system by disabling interfaces.
Rationale for non-applicability: The use of commercial mobile devices as personal hotspots to connect to DoD networks is a critical user functionality. This configuration enables routing between the VPN traffic on one interface and authenticated client device access on another interface. A prohibition on split-tunneling would disable this feature. Strong authentication of remote network connections mitigates the risk that an unauthorized process on the non-VPN interface will be able to access the VPN interface.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001111The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000167-MOS-000086<GroupDescription></GroupDescription>SRG-OS-000167-MOS-000086The mobile device operating system must have access to DoD root and intermediate PKI certificates when performing DoD PKI related transactions.<VulnDiscussion>DoD root and intermediate PKI certificates are used to verify the authenticity of PKI certificates of users and web services. If the root and intermediate certificates are not available, an adversary could falsely sign a certificate in such a way that it could not be detected. Providing access to the DoD root and intermediate PKI certificates greatly diminishes the risk of this attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NSDISA FSOVMS TargetSRG-OS-MOS-NS2272CCI-001142Install DoD root and intermediate certificates on the device.Review the mobile operating system configuration to determine if the root and intermediate certificates are present. In some cases, their presence may not be detected by user inspection, in which case the reviewer should review system documentation to determine whether they are present. If the certificate is accepted, the operating system is likely not performing the required check of root and intermediate certificates. If the DoD root and intermediate certificates are not present, this is a finding.SRG-OS-000188-NA<GroupDescription></GroupDescription>SRG-OS-000188-NAThe operating system at organization defined information system components must load and execute organization defined applications from hardware-enforced, read-only media.<VulnDiscussion>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 includes CD-R/DVD-R disk drives.
Rationale for non-applicability: Mobile OS devices must be flash upgradable in order to implement patches to vulnerabilities. The small form factor of a mobile device does not easily allow for multiple forms of storage. Therefore, the persistent memory on a mobile device must be writeable and cannot support this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001211The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000216-NA<GroupDescription></GroupDescription>SRG-OS-000216-NAThe operating system must use cryptographic mechanisms to protect the integrity of audit information.<VulnDiscussion>Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data.
Rationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001350The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000217-NA<GroupDescription></GroupDescription>SRG-OS-000217-NAThe operating system must protect the audit records resulting from non-local accesses to privileged accounts and the execution of privileged functions.<VulnDiscussion>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 operating 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.
Rationale for non-applicability: This control is better addressed by another CCI. CCI-000162 and CCI-00163 together protect the audit logs from unauthorized access and modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOS-NADISA FSOVMS TargetSRG-OS-MOS-NA2271CCI-001352The requirement is NA. No fix is required.This requirement is NA for the Mobile OS SRG.SRG-OS-000079-MOS-000053<GroupDescription></GroupDescription>SRG-OS-000079-MOS-000053The mobile operating system must obscure passwords on the devices display when they are entered on the device.<VulnDiscussion>To prevent the compromise of authentication information, such as passwords during the authentication process, the feedback from the operating system shall not provide any information allowing an unauthorized user to compromise the authentication mechanism. Otherwise, someone nearby the user (a.k.a., "shoulder surfer") may be able to obtain the password through visual observation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>VMS Target SRG-OS-MOSDISA FSOVMS TargetSRG-OS-MOS2270CCI-000206Configure the mobile operating system to obscure passwords on the device's display when they are entered on the device.Review the mobile operating system configuration for obscuring passwords on the device's display when entered on the device. If the mobile operating system does not obscure passwords during entry, this is a finding.