draftApple iOS 5 Security Technical Implementation Guide (STIG)This STIG contains technical security controls required for the use of Apple iOS 5 devices (iPhone and iPad) in the DoD environment when managed by an approved mobile management server.DISA, Field Security OperationsSTIG.DOD.MILRelease: 0.1 Benchmark Date: 20 Jul 20121I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>I - Mission Critical Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>Remote access VPN - FIPS 140-2<GroupDescription></GroupDescription>WIR-MOS-iOS-034-01The VPN client on wireless clients (PDAs, smartphones) used for remote access to DoD networks must be FIPS 140-2 validated. <VulnDiscussion>DoD data could be compromised if transmitted data is not secured with a compliant VPN. FIPS validation provides a level of assurance that the encryption of the device has been securely implemented.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Install a FIPS 140-2 validated VPN client. This check is not applicable if the installed VPN client is not used for remote access to DoD networks.
Interview the IAO and/or site wireless device administrator and inspect a sample (3-4) of site devices. Review VPN client specification sheets and FIPS 140-2 certificate. Verify the VPN client is FIPS 140-2 validated. Check the NIST certificate for the mobile OS or VPN client. Mark as a finding if the VPN is not FIPS 140-2 validated.
Remote access VPN - AES encryption<GroupDescription></GroupDescription>WIR-MOS-iOS-034-02All wireless PDA clients used for remote access to DoD networks must have a VPN supporting AES encryption. <VulnDiscussion>DoD data could be compromised if transmitted data is not secured with a compliant VPN.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Install an AES Encrypted VPN client. This check is not applicable if the installed VPN client is not used for remote access to DoD networks.
Interview the IAO and/or site wireless device administrator and inspect a sample (3-4) of site devices. Review VPN client specification sheets and the configuration of the VPN client. Verify the VPN client supports AES encryption. Verify the VPN client is configured to required AES. Mark as a finding if the VPN does not support AES or is not configured to require AES.Remote access VPN - CAC authentication<GroupDescription></GroupDescription>WIR-MOS-iOS-034-03All wireless PDA clients used for remote access to DoD networks must have a VPN supporting CAC authentication. <VulnDiscussion>DoD data could be compromised if transmitted data is not secured with a compliant VPN.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Install a VPN client that supports CAC authentication.This check is not applicable if the installed VPN client is not used for remote access to DoD networks.
Interview the IAO and/or site wireless device administrator and inspect a sample (3-4) of site devices. Review VPN client specification sheets and verify the VPN client support CAC authentication. Mark as a finding if the VPN does not support CAC authentication.
Remote access VPN - split tunneling<GroupDescription></GroupDescription>WIR-MOS-iOS-034-04All wireless PDA client VPNs must have split tunneling disabled. <VulnDiscussion>DoD data could be compromised if transmitted data is not secured with a compliant VPN. Split tunneling could allow connections from non-secure Internet sites to access data on the DoD network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable split tunneling on VPN client. This check is not applicable if the installed VPN client is not used for remote access to DoD networks.
Interview the IAO and/or site wireless device administrator and inspect a sample (3-4) of site devices. Review VPN client specification sheets and verify the VPN client supports disabling split tunneling. Verify the VPN client is configured disable split tunneling. Mark as a finding if the VPN does not support disabling split tunneling or it is not disabled on the client.
Use approved SCR software version<GroupDescription></GroupDescription>WIR-MOS-iOS-002Smart Card Readers (SCRs) used with smartphones must have required software version installed.<VulnDiscussion>Required security features are not available in earlier software versions. In addition, there may be known vulnerabilities in earlier versions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Install required SCR software version. Detailed Policy Requirements:
If a Bluetooth smart card reader is used only the following models and firmware versions should be used:
SCR: Biometric Associates, LP (BAL) baiMobile BAL-3000MP Bluetooth Smart Card Reader. Firmware version v2.01.00 or later should be used (version v2.02.00 is recommended).
Bluetooth adapter: Biometric Associates, LP (BAL) baiMobile BAL-BTA001 Bluetooth Adapter. Firmware version 2.01.00 or later should be used (version v2.02.00 is recommended).
Check Procedures:
SCR: The version of the reader firmware is displayed when the user presses and holds the Action button for a couple of seconds.
Bluetooth adapter: Model and firmware are printed on the label attached to the adapter.
For wired smart card readers, check to see if the vendor has completed JITC PKI interoperability testing. Ask to see a copy of the JITC certification. The firmware version should be the same as listed in the JITC certification (or later version).
Mark as a finding if the firmware version on the SCR and adapter are not the approved versions.S/MIME installed on smartphone<GroupDescription></GroupDescription>WIR-MOS-iOS-003S/MIME must be installed on mobile device, so users can sign/encrypt email<VulnDiscussion>S/MIME provides the capability for users to send and receive S/MIME email messages from wireless email devices. S/MIME and digital signatures provide assurance the message is authentic and is required by DoD policy. Without S/MIME users will not be able to read encrypted email and will not be able to encrypt email with sensitive information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Provision the mobile email client with S/MIME so users can digitally sign and encrypt emergency and/or critical email notifications.Launch the mobile email client and verify S/MIME is installed in the client. The exact procedures will depend on which mobile email product is being used. Mark as a finding if not compliant.User auto-signature on email<GroupDescription></GroupDescription>WIR-MOS-iOS-004If mobile device email auto signatures are used, the signature message must not disclose the email originated from a smartphone (e.g., Sent From My Wireless Handheld).
<VulnDiscussion>The disclaimer message may give information which may key an attacker in on the device. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the iOS email auto-signature message so it does not disclose the email originated from the iOS device (e.g., Sent From My Wireless Handheld).
Launch the mobile email client and verify the email auto signature feature is set and it is complaint with the requirement. The exact procedures will depend on which mobile email product is being used. Mark as a finding if not compliant.Use DoD Internet proxy<GroupDescription></GroupDescription>WIR-MOS-iOS-005The browser must direct all traffic to a DoD Internet proxy gateway.
<VulnDiscussion>When using the DoD Internet proxy for iOS device Internet connections, enclave Internet security controls will filter and monitor iOS device Internet connections and reduce the risk that malware could be downloaded on the mobile device.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Use a compliant browser implementation on the iOS device.
There are two acceptable implementations for this requirement.
1. The device uses a mobile VPN to route all data traffic to the DoD enclave, which forces all browser traffic to the DoD Internet gateway.
2. The device browser is installed inside an iOS security container and the security container provides the capability to route all browser traffic to the MDM server where it will be routed to the DoD Internet gateway.
Using a browser without a mobile VPN and installed outside the iOS device security container is not an approved implementation.
Verify one of the approved browser implementations is used. Talk to the user and review 3-4 sample devices.
Mark as a finding if a required browser is not used.Allow only approved mobile OS versions<GroupDescription></GroupDescription>WIR-MOS-iOS-030-01Mobile devices must have required operating system software version installed.
<VulnDiscussion>Unapproved OS versions do not support required security features.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Install required OS version.
This is an iOS security policy set check. Recommend all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
The exact procedures will vary based on the MDM product used. For the Good server, verify the following:
-Verify a compliance rule has been set up defining required iOS 5 versions.
-Launch the Good Mobile Control Web console and click on the Policies tab.
-Select a policy set to review and click on the policy.
-On the left tab, select Compliance Manager.
-Verify “OS Version Verification” rule is listed. (Note that the rule title does not have to be exact.)
-Open the rule by checking the box next to the rule and then click on Edit.
-Verify the following are set:
Platform: iPhone
Check to Run: OS Version Verification
-Verify the following are checked:
5.1.1 or later.
-Verify “Failure Action” is set to “Quit Good for Enterprise”.
-Verify “Check Every” is set to “1 hour”.
Mark as a finding if the “OS Version Verification” rule has not been set up or is not configured as required.Require password to remove profile<GroupDescription></GroupDescription>WIR-MOS-iOS-G-009iOS devices must be configured to require a password to remove the iOS configuration profile, if a configuration profile is used.
<VulnDiscussion>Sensitive DoD data could be compromised if a security profile is not installed on DoD iPhone/iPad/iPod Touch devices. The profile should only be removed by the system administrator.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWN-1, IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set smartphone to require a password to remove the device configuration profile if a non-MDM profile is used. Passwords must meet CYBERCOM CTO 07-15Rev1 requirements for admin passwords and not be given to the user.
This requirement only applies if a non-MDM profile is used on an iOS device. An example would be if the Fixmo MDM profile is used to implement iOS security and a Good profile is used to provide email services. In this case, the Good profile would be a non-MDM profile.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
The profile password will meet CYBERCOM CTO 07-15Rev1 requirements for admin passwords and not be given to the user.
-Verify “Require password to remove profile” is checked and a complex Super User password is set.
Mark as a finding if not configured as required.Require device unlock password/passcode<GroupDescription></GroupDescription>WIR-MOS-iOS-G-010Mobile devices must be configured to require a password/passcode for device unlock.
<VulnDiscussion>Sensitive DoD data could be compromised if a device unlock passcode is not set up on a DoD iOS device.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWN-1, IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the iOS device to require a passcode for device unlock.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Require passcode” is checked.
Mark as a finding if configuration is not set as required.Maximum password/passcode age<GroupDescription></GroupDescription>WIR-MOS-iOS-G-013Maximum passcode age must be set.<VulnDiscussion>Sensitive DoD data could be compromised if a strong device unlock passcode is not set up on a DoD iPOS device and the passcode is not changed periodically.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWN-1, IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set maximum passcode age as required.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Maximum passcode age” is checked and set to 120 days or less.
Mark as a finding if configuration is not set as required.Smartphone inactivity timeout<GroupDescription></GroupDescription>WIR-MOS-iOS-G-016The mobile device must be set to lock the device after a set period of user inactivity. <VulnDiscussion>Sensitive DoD data could be compromised if the smartphone does not automatically lock after 15 minutes of inactivity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set the smartphone inactivity timeout to required value. This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Grace period” is checked and set to 15 minutes or less.
Mark as a finding if configuration is not set as required.Password/passcode maximum failed attempts<GroupDescription></GroupDescription>WIR-MOS-iOS-G-017Passcode maximum failed attempts must be set to required value.<VulnDiscussion>A hacker with unlimited attempts can determine the password of an iOS device within a few minutes using password hacking tools, which could lead to unauthorized access to the iOS device and exposure to sensitive DoD data.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set password/passcode maximum failed attempts to required value.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Maximum failed attempts” is checked and set to 10 or less.
Mark as a finding if configuration is not set as required.Public application store<GroupDescription></GroupDescription>WIR-MOS-iOS-G-019Access to public application stores must be disabled.<VulnDiscussion>Strong configuration management of all applications installed on DoD device is required to ensure the security baseline of the system is maintained. Otherwise, sensitive DoD data could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1, ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable access to public application stores.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow use of iTunes Music Store” is unchecked.
Mark as a finding if configuration is not set as required.Smartphone application installation<GroupDescription></GroupDescription>WIR-MOS-iOS-G-020Users must enable iOS application download.
<VulnDiscussion>Application download must be enabled so iOS updates can be installed over-the-air (OTA) and security updates will be installed as soon as possible. This is a key feature of the security baseline for DoD iOS devices. The MAM server will be responsible for scanning the device periodically and alert if the user has downloaded unapproved applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECLP-1, ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215On the MDM server, set “Allow installing apps” to enabled. This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow installing apps” is enabled or checked.
Mark as a finding if configuration is not set as required.
Note: With this setting and check WIR-MOS-iOS-G-023, users will be able browse the application store but not purchase and download applications from the store. If a user finds a way to “sideload” an unauthorized iOS application without using the app store, the MAM server will alert that an unauthorized application has been identified on the device.
Smartphone camera<GroupDescription></GroupDescription>WIR-MOS-iOS-G-021Mobile device cameras must be used only if documented approval is in the site physical security policy.
<VulnDiscussion>This is an operational security issue. DoD sensitive information could be compromised if cameras are allowed in areas not authorized by the site physical security plan.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><Responsibility>Designated Approving Authority</Responsibility><Responsibility>Information Assurance Manager</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Allow use of smartphone camera only if documented approval exists in the site physical security policy. Note: The site has the ability to disable the camera by using the iPhone profile if camera use is not approved or allow the use of the camera and if use is approved and documented in the site physical security policy. Also, the site can state in the site physical security policy that camera use outside the facility is approved, but the camera must be disabled on the phone when brought into the facility. In this case, “Allow use of camera” would not be checked.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Determine if “Allow use of camera” is unchecked or checked.
If checked, verify the site physical security policy allows the use of smartphone cameras.
Mark as a finding if “Allow use of camera” is checked and the site physical security policy does not allow the use of smartphone cameras.iPhone screen capture<GroupDescription></GroupDescription>WIR-MOS-iOS-G-022Mobile device screen capture must not be allowed.
<VulnDiscussion>Sensitive data, including FOUO data displayed on the screen, could be saved in unsecure memory on the device.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Do not allow iPhone screen capture.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow screen capture” is unchecked.
Mark as a finding if not set as required.Minimum password/passcode length<GroupDescription></GroupDescription>WIR-MOS-iOS-G-011The device minimum password/passcode length must be set. <VulnDiscussion>Sensitive DoD data could be compromised if a device unlock password/passcode is not set to required length on a DoD smartphones. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWN-1, IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set the smartphone minimum password/passcode length as required. This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify any non compliant policy sets and STIG/STIG compliant policy sets on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Click the Passcode tab.
-Verify “Minimum length of" is set to 4 or more in the iOS security policy.
Mark as a finding if configuration is not set as required.Smartphone Auto-Lock<GroupDescription></GroupDescription>WIR-MOS-iOS-G-014Apple iOS Auto-Lock must be set.<VulnDiscussion>Sensitive DoD data could be compromised if the iOS device does not automatically lock after a set period of inactivity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set the smartphone Auto-Lock as required.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Auto-lock” is set to 5 minutes or less.
Mark as a finding if configuration is not set as required.
Smartphone passcode/password history<GroupDescription></GroupDescription>WIR-MOS-iOS-G-015The smartphone passcode history setting must be set.<VulnDiscussion>The passcode would be more susceptible to compromise if the user can select frequently used passcodes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Set the smartphone passcode history setting as required. This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify Passcode history is set to 3 or more.
Mark as a finding if configuration is not set as required.Smartphone Wi-Fi Control<GroupDescription></GroupDescription>WIR-MOS-iOS-041The mobile device Wi-Fi radio must be disabled as the default setting and is enabled only when Wi-Fi connectivity is required.
<VulnDiscussion>The Wi-Fi radio can be used by a hacker to connect to the smartphone without the knowledge of the user. Sensitive DoD data could be exposed and the hacker could use the device to attack the enclave.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Train user to disable the smartphone Wi-Fi radio unless Wi-Fi connectivity is required.
This is a User Based Enforcement (UBE) setting.
On a sample of site-managed iOS devices (pick 3-4 random devices), check that the Wi-Fi radio is turned off.
-Have the user turn on and log into the device.
-Go to Settings > Wi-Fi. Wi-Fi should be turned off.
Mark as a finding if configuration is not set as required.Required logon banner<GroupDescription></GroupDescription>WIR-MOS-iOS-007All mobile devices must display the required banner during device unlock/logon.
<VulnDiscussion>DoD CIO memo requires all PDAs, BlackBerrys, and smartphones to have a consent banner displayed during logon/device unlock to ensure users understand their responsibilities to safeguard DoD data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWM-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Display the required banner during device unlock/logon. The following banner is required:
“I've read & consent to terms in IS user agreem't.”
Check Procedure:
On the iOS device, complete the following:
Check a sample of devices (3-4). The procedure will vary, depending on the MDM server used. For iOS, the banner is only displayed when logging into the security container.
The banner must exactly match the required phrase.
If the Good server is used, complete the following:
1. Make a list of all Good security policy sets assigned to smartphone user accounts on the Good server using the following procedure:
-Have the SA identify any non STIG/ISCG-compliant policy sets and STIG/ISCG-compliant policy sets on the server.
--Log into the Good Mobile Control console.
--Click on the Policies tab.
--View all policy sets on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each policy set users are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the Good Mobile Control Web console and click on the Policies tab.
-Select a policy set to review and click on the policy.
-On the left tab, select Compliance Manager.
-Verify a "Custom" or "iOS DoD Login Banner" rule is listed. (Note the rule title does not have to be exact.)
-Open the rule by checking the box next to the rule and then click Edit.
-Verify "Failure Action" is set to "Quit Good for Enterprise".
-Verify "Check Every" is set to "1 hour".
-Verify Rule File = disclaimer.xml
Mark as a finding if configuration is not set as required.iOS Safari<GroupDescription></GroupDescription>WIR-MOS-iOS-G-018-01iOS Safari must be disabled.
<VulnDiscussion>The Safari browser does not support FIPS 140-2 validated encryption and CAC authentication to DoD web sites. FIPS validation provides a level of assurance that encrypted sensitive data will not be compromised.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1, ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable iOS Safari in all iOS security policies.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow use of Safari” is not checked.
Mark as a finding if not set as required.Wi-Fi - Ask to Join Networks<GroupDescription></GroupDescription>WIR-iOS-005The iOS device Wi-Fi setting Ask to Join Networks must be set to On at all times (User Based Enforcement (UBE)).
<VulnDiscussion>The risk of a DoD mobile device being attacked via a rogue Wi-Fi access point is higher than for a rogue cellular access point. Therefore, the mobile device should be configured so it does not automatically connect to a Wi-Fi access point. The user should acknowledge and approve the connection to any Wi-Fi access point to minimize the risk of sensitive data on the device being exposed.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215The iOS device Wi-Fi setting "Ask to Join Networks" must be set to "On" at all times.
On a sample of site-managed iOS devices (pick 3-4 random devices), have the user turn on and log into the device.
-Go to Settings > Wi-Fi.
-Touch Wi-Fi.
-Check the setting of "Ask to Join Networks".
Verify it is set to off (not selected).
Mark as a finding if not checked.
Disable online application purchase<GroupDescription></GroupDescription>WIR-MOS-iOS-G-023Access to online application purchases must be disabled.<VulnDiscussion>Strong configuration management of all applications installed on DoD devise is required to ensure the security baseline of the system is maintained. Otherwise, sensitive DoD data could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCCB-1, DCCB-2</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable access to online application purchases.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow In-App Purchases” is unchecked.
Mark as a finding if not set as required.Encrypted smartphone backups<GroupDescription></GroupDescription>WIR-MOS-iOS-G-024Encrypted smartphone backups must be enabled.<VulnDiscussion>The act of connecting an iOS device to a PC can put it at risk of attack if the PC is compromised. The iOS device should sync to a minimum number of approved machines. It should not sync to laptops that travel with the device and it should always use encrypted backups.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>CODB-3</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Encrypted smartphone backups will be enabled.This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Require iTunes backups to be encrypted” is checked.
Mark as a finding if not set as required.Enable remote full device wipe<GroupDescription></GroupDescription>WIR-MOS-iOS-G-008Remote full device wipe must be enabled.<VulnDiscussion>Sensitive DoD data could be compromised if mobile OS device data could not be wiped when directed by the system administrator.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCR-1, ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Enable remote full device wipe on iOS devices.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify "Enable remote full device wipe" is checked.
(Note: “Device Wipe” will wipe all data and non-core applications off the iOS device.)
Mark as a finding if configuration is not set as required.iOS Siri application<GroupDescription></GroupDescription>WIR-MOS-iOS-50-02iOS Siri application must be disabled.
<VulnDiscussion>The Siri application connects to Apple servers and stores information about the device and user inquiries on those servers. The use of Siri could lead to the compromise of sensitive DoD information.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable Siri in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow Siri" is not checked.
Mark as a finding if not set as required.iOS multiplayer gaming<GroupDescription></GroupDescription>WIR-MOS-iOS-50-03iOS Multiplayer Gaming must be disabled.
<VulnDiscussion>The game function connects to Apple servers and allows the transfer of device data to other iOS devices. The use of the game function could lead to the compromise of sensitive DoD information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable multiplayer gaming in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow multiplayer gaming" is not checked.
Mark as a finding if not set as required.iOS game center<GroupDescription></GroupDescription>WIR-MOS-iOS-50-04Adding Game Center Friends must be disabled.
<VulnDiscussion>The game function connects to Apple servers and allows the transfer of device data to other iOS devices. The use of the game function could lead to the compromise of sensitive DoD information.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable Adding Game Center Friends in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Adding Game Center Friends" is not checked.
Mark as a finding if not set as required.iOS iCloud backup<GroupDescription></GroupDescription>WIR-MOS-iOS-50-05Allow iCloud Backup must be disabled.
<VulnDiscussion>The iCloud feature (and associated iCloud setting in iOS) stores iOS device data on Apple controlled servers. Sensitive DoD data saved on the iOS device could be compromised when it is stored on the Apple servers.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable iCloud Backup in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow iCloud Backup" is not checked.
Mark as a finding if not set as required.iOS iCloud document syncing<GroupDescription></GroupDescription>WIR-MOS-iOS-50-06Allow Document Syncing must be disabled.
<VulnDiscussion>The iCloud feature (and associated iCloud setting in iOS) stores iOS device data on Apple controlled servers. Sensitive DoD data saved on the iOS device could be compromised when it is stored on the Apple servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable Document Syncing in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow Document Syncing" is not checked.
Mark as a finding if not set as required.iOS iCloud photo stream<GroupDescription></GroupDescription>WIR-MOS-iOS-50-07Allow Photo Stream must be disabled.
<VulnDiscussion>The iCloud feature (and associated iCloud setting in iOS) stores iOS device data on Apple controlled servers. Sensitive DoD data saved on the iOS device could be compromised when it is stored on the Apple servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable Photo Stream in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow Photo Stream" is not checked.
Mark as a finding if not set as required.iOS diagnostic data<GroupDescription></GroupDescription>WIR-MOS-iOS-50-08Allow Diagnostic Data to be Sent to Apple must be disabled.
<VulnDiscussion>Sensitive DoD information could be compromised if this setting is not implemented. DoD mobile device diagnostic data could be considered sensitive data and should not be sent to Apple and reside on Apple servers.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWM-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable Diagnostic Data to be Sent to Apple in the iOS security policy.
This is an iOS security policy set check. Recommend that all checks related to iOS security policy set rules be reviewed using the following procedure.
1. Make a list of all iOS security policies listed on the MDM server that have been assigned to iOS devices and review each policy using the following procedure:
-Have the SA identify STIG compliant and non-compliant policies on the server.
--Log into the MDM server console.
--Click on the Policies tab.
--View all iOS security policies on the server.
-Note: STIG-compliant policy sets should be identified as such in the policy title. An example is STIG_iOS_Policy_Set. It is recommended that all non-STIG/ISCG policy sets be deleted.
2. Select each iOS security policy iOS devices are assigned to, and in turn, verify the required settings are in the policy set.
-Note: If there is a finding, note the name of the non STIG/ISCG-compliant policy set in the Findings Details section in VMS/Component Provided Tracking Database.
-Launch the MDM console and click on the Policies tab.
-Select the iOS security policy.
-Verify “Allow Diagnostic Data to be Sent to Apple" is not checked.
Mark as a finding if not set as required.VPN timeout<GroupDescription></GroupDescription>WIR-MOS-iOS-034-05All wireless PDA client VPNs must timeout an inactive session after a set period of inactivity.
<VulnDiscussion>The data on a DoD iOS device most likely contains sensitive DoD information, therefore, when device data is backed up to a local, approved laptop, the data should be encrypted to prevent compromise of data.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the VPN client to timeout a session after 4 hours of inactivity.This check is not applicable if the installed VPN client is not used for remote access to DoD networks. Interview the IAO and/or site wireless device administrator and inspect a sample (3-4) of site devices. Review VPN client specification sheets. Verify the VPN client is configured to timeout an inactive session after a set period of inactivity. The check procedures will vary depending on the VPN client used.
Mark as a finding if the VPN client is not configured to timeout after 4 hours.VPN credential cache<GroupDescription></GroupDescription>WIR-MOS-iOS-034-06All wireless PDA client VPN authentication credential cache timeout must be set to 2 hours or less.
<VulnDiscussion>DoD data could be compromised if transmitted data is not secured with a compliant VPN. User authentication credentials (CAC PIN) may be compromised if a hacker credential cache is not wiped on a periodic basis.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the VPN client to timeout an inactive session of 2 hours or less.
This check is not applicable if the installed VPN client is not used for remote access to DoD networks. Interview the IAO and/or site wireless device administrator and inspect a sample (3-4) of site devices. Review VPN client specification sheets. Verify the VPN client is inactive session timeout has been set to 2 hours or less.
Mark as a finding if the timeout period is not set as required.
iOS management agents<GroupDescription></GroupDescription>WIR-MOS-60MDM, MAM, and integrity validation agent(s) must be installed and operate at all times on the mobile OS device.
<VulnDiscussion>The MDM, MAM, and integrity scanning agents all perform various security management functions on the iOS devices (some products integrate all three functions into one agent). If these agents are not on the mobile device, key security controls may not be enforced, which could lead to the compromise of sensitive DoD data.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Install the missing management agents on the iOS device.
Check the list of applications on a sample of 2-3 iOS devices. Verify an MDM, MAM, and integrity validation agent are installed on the device.
Note that one or more agents may be used. Some agents may perform one or more of these functions. Ask the site for the name of the product(s) used. Mark as a finding if the required agent(s) are not installed.iOS security policy<GroupDescription></GroupDescription>WIR-MOS-iOS-65-01The 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>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the operating system to prohibit a user from disabling or modifying the security policy or enforcement mechanisms on the device or to wipe the security container if detects the security policy has been deleted, disabled, or modified.Review system documentation, operating system configuration, and other IA information resources to determine how the operating system prevents the user from modifying the security policy and related enforcement mechanisms. Items to look for include mandatory access controls, permissions on related operating system files, and authentication for super user access. Examine the operating system configuration. If it is easy to turn off security settings or stop security-related applications from running, this is a finding.
An alternate and acceptable approach is for the security container agent to wipe the container if it detects the security policy has been deleted, disabled, or modified.Authentication<GroupDescription></GroupDescription>WIR-MOS-iOS-65-02The 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>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.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the operating system to authenticate the provisioning server prior to accepting provisioned software.
Review the loading process to determine if it meets the necessary assurance for mutual authentication. If the trusted loading process does not meet the criteria, this is a finding.
OTA provisioning<GroupDescription></GroupDescription>WIR-MOS-iOS-65-03The mobile operating system must protect the confidentiality of the provisioning data downloaded to the handheld device during a trusted over-the-air (OTA) provisioning session.
<VulnDiscussion>Provisioning data 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.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure 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.
OTA provisioning data integrity<GroupDescription></GroupDescription>WIR-MOS-iOS-65-04The mobile operating system must protect the integrity of the provisioning data downloaded to the handheld device during a trusted over-the-air (OTA) provisioning session.
<VulnDiscussion>Provisioning data may be sensitive and therefore must be adequately protected. 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>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure 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.
Disable OTA provisioning<GroupDescription></GroupDescription>WIR-MOS-iOS-65-05The 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 secure 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>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable OTA provisioning if threat conditions warrant this action. 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.
DAR encryption<GroupDescription></GroupDescription>WIR-MOS-iOS-65-06The 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>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure 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.
PKI certificate store<GroupDescription></GroupDescription>WIR-MOS-iOS-65-07The 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.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the operating system 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.
Data in transit encryption<GroupDescription></GroupDescription>WIR-MOS-iOS-65-08The 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 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>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Stop using the operating system until the vendor has obtained FIPS validation or install a third party product that contains a security container with a FIPS validated cryptographic module.Review system documentation to identify the FIPS 140 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 operating system cryptographic module is not currently FIPS validated or a third party application that provides a security module protected by a FIPS 140-2 validated encryption module is not used on the mobile device, this is a finding.DAR encryption<GroupDescription></GroupDescription>WIR-MOS-iOS-65-09The 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.
</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Stop using the operating system until the vendor has obtained FIPS validation or install a third party product that contains a FIPS validated cryptographic module providing the same services in the operating system’s non-FIPS validated implementation of cryptography.
Review system documentation to identify the FIPS 140 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.
PKI certificate store encryption<GroupDescription></GroupDescription>WIR-MOS-iOS-65-10The cryptographic module supporting encryption of the certificate store 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>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Stop using the operating system until the vendor has obtained FIPS validation or install a third party product that contains a FIPS validated cryptographic module providing the same services in the operating system’s non-FIPS validated implementation of cryptography.
Review system documentation to identify the FIPS 140 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.
Browser configuration<GroupDescription></GroupDescription>WIR-MOS-iOS-65-11The 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 that 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>ECWN-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Disable 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.
DAR encryption - AES<GroupDescription></GroupDescription>WIR-MOS-iOS-65-12The 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>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure 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. Validate this includes data on removable memory, such as SD cards. 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.
Device unlock password<GroupDescription></GroupDescription>WIR-MOS-iOS-65-13The 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), then 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>IAIA-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the operating system to require a valid password be successfully entered before the mobile device data is unencrypted.
On a sample of devices known to encrypt information resident on the devices, attempt to access an encrypted file and verify the operating system prompts for a password. 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 some point when using the device, this is a finding.
DAR encryption configuration<GroupDescription></GroupDescription>WIR-MOS-iOS-65-14The mobile operating system must re-encrypt all device data when the device is locked.
<VulnDiscussion>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 data 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>DCNR-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the operating system to re-encrypt all device data in memory when the device is locked. If the operating system does not support this capability, a permanent finding must be assigned to the asset running the operating system.
Review system documentation and other IA information resources to determine how the operating system treats data in memory upon the lock of the device. The operating system may enforce this requirement in a variety of means. The reviewer should focus on the fact that the data is encrypted when the device has been shut down suddenly and 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.
Malware controls<GroupDescription></GroupDescription>WIR-MOS-iOS-65-15The mobile operating system must employ a DoD approved anti-virus application or otherwise prevent a malware application 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>ECVP-1</IAControls>VMS Target Apple iOS 5DISA FSOVMS TargetApple iOS 52215Configure the operating system to prevent a malware application from installing and executing.
Review system documentation to determine the approach to malware prevention. This may include secure operating system architectures, mandatory access controls, and high-assurance authentication of code. Inspect the operating system to validate the approach has been implemented as claimed. If the approach has not been implemented, or if the implementation is inadequate, this is a finding.