What changed in Google Android 16 COPE STIG V1R4V1R4 changes

Title

Google Android 16 must be configured to enforce an application installation policy by specifying one or more authorized application repositories, including [selection: DODDoW-approved commercial app repository, MDM server, mobile application store].

Check text

Review managed Google Android 16 device configuration settings to determine if the mobile device has only approved application repositories (DODDoW-approved commercial app repository, EMM server, and/or mobile application store). This validation procedure is performed on both the EMM Administration Console and the managed Google Android 16 device. On the EMM console: COBO and COPE: 1. Open "Set user restrictions". 2. Verify that "Disallow install unknown sources" is toggled to "ON". 3. Verify that "Disallow installs from unknown sources globally" is toggled to "ON". On the Google Android 16 device: COBO and COPE: 1. Open Settings >> Apps >> Special app access. 2. Open "Install unknown apps". 3. Ensure the list of apps is blank, or if an app is on the list, "Disabled by admin" is listed under the app name. If the EMM console device policy is not set to allow connections to only approved application repositories, or on the managed Google Android 16 device the device policy is not set to allow connections to only approved application repositories, this is a finding.

Discussion

Forcing all applications to be installed from authorized application repositories can prevent unauthorized and malicious applications from being installed and executed on mobile devices. Allowing such installations and executions could cause a compromise of DODDoW data accessible by these unauthorized/malicious applications. SFR ID: FMT_SMF.1.1 #8

V-276855 in V1R4

Discussion

The application allowlist, in addition to controlling the installation of applications on the MD, must control user access/execution of all core and preinstalled applications, or the mobile device (MD) must provide an alternate method of restricting user access/execution to core and preinstalled applications. Core application: Any application integrated into the operating system (OS) by the OS or MD vendors. Preinstalled application: Additional noncore applications included in the OS build by the OS vendor, MD vendor, or wireless carrier. Requiring all authorized applications to be in an application allowlist prevents the execution of any applications (e.g., unauthorized, malicious) that are not part of the allowlist. Failure to configure an application allowlist properly could allow unauthorized and malicious applications to be downloaded, installed, and executed on the mobile device, causing a compromise of DODDoW data accessible by these applications. The application allowlist, in addition to controlling the installation of applications on the MD, must control user access/execution of all core applications (included in the OS by the OS vendor) and preinstalled applications (provided by the MD vendor and wireless carrier), or the MD must provide an alternate method of restricting user access/execution to core and preinstalled applications. SFR ID: FMT_SMF.1.1 #8

V-276856 in V1R4

Title

Google Android 16 allowlist must be configured to not include applications with the following characteristics: - Backs up mobile device (MD) data to non-DODDoW cloud servers (including user and application access to cloud backup services); - Transmits MD diagnostic data to non-DODDoW servers; - Voice assistant application if available when MD is locked; - Voice dialing application if available when MD is locked; - Allows synchronization of data or applications between devices associated with user; - Payment processing; - Allows unencrypted (or encrypted but not FIPS 140-2/140-3 validated) data sharing with other MDs or printers; - Backs up own data to a remote system; - Renders TV shows and movies.

Check text

Review managed Google Android 16 device configuration settings to determine if the mobile device has an application allowlist configured and that the application allowlist does not include applications with the following characteristics: - Backs up MD data to non-DODDoW cloud servers (including user and application access to cloud backup services); - Transmits MD diagnostic data to non-DODDoW servers; - Voice assistant application (if available) when MD is locked; - Voice dialing application (if available) when MD is locked; - Allows synchronization of data or applications between devices associated with user; - Payment processing; - Allows unencrypted (or encrypted but not FIPS 140-2/140-3 validated) data sharing with other MDs, display screens (screen mirroring), or printers; - Backs up own data to a remote system. - Renders TV shows and movies. This validation procedure is performed only on the EMM Administration Console. On the EMM console: 1. Review the list of selected Managed Google Play apps. 2. Review the details and privacy policy of each selected app to ensure the app does not include prohibited characteristics. If the EMM console device policy includes applications with unauthorized characteristics, this is a finding.

Fix text

Configure the Google Android 16 device application allowlist to exclude applications with the following characteristics: - Backs up MD data to non-DODDoW cloud servers (including user and application access to cloud backup services); - Transmits MD diagnostic data to non-DODDoW servers; - Voice assistant application (if available) when MD is locked; - Voice dialing application (if available) when MD is locked; - Allows synchronization of data or applications between devices associated with user; - Payment processing; - Allows unencrypted (or encrypted but not FIPS 140-2/140-3 validated) data sharing with other MDs, display screens (screen mirroring), or printers; - Backs up own data to a remote system; - Renders TV shows and movies. On the EMM console: 1. Go to the Android app catalog for managed Google Play. 2. Before selecting an app, review the app details and privacy policy to ensure the app does not include prohibited characteristics. Managed Google Play is always an allowlisted App Store.

Discussion

Requiring all authorized applications to be in an application allowlist prevents the execution of any applications (e.g., unauthorized, malicious) that are not part of the allowlist. Failure to configure an application allowlist properly could allow unauthorized and malicious applications to be downloaded, installed, and executed on the mobile device, causing a compromise of DODDoW data accessible by these applications. Applications with the listed characteristics have features that can cause the compromise of sensitive DODDoW data or have features with no known application in the DODDoW environment. Application note: The application allowlist, in addition to controlling the installation of applications on the MD, must control user access/execution of all core and preinstalled applications, or the MD must provide an alternate method of restricting user access/execution to core and preinstalled applications. Core application: Any application integrated into the operating system (OS) by the OS or MD vendors. Preinstalled application: Additional noncore applications included in the OS build by the OS vendor, MD vendor, or wireless carrier. SFR ID: FMT_SMF.1.1 #8

V-276857 in V1R4

Discussion

Sensitive DODoW data could be exposed when an AI app processes device data in the cloud. SFR ID: FMT_SMF.1.1 #8

V-276858 in V1R4

Discussion

Trust agents allow a user to unlock a mobile device without entering a passcode when the mobile device is, for example, connected to a user-selected Bluetooth device or in a user-selected location. This technology would allow unauthorized users to have access to DODDoW sensitive data if compromised. By not permitting the use of nonpassword authentication mechanisms, users are forced to use passcodes that meet DODDoW passcode requirements. SFR ID: FMT_SMF.1.1 #22, FIA_UAU.5.1

V-276860 in V1R4

Discussion

Developer modes expose features of the mobile operating system that are not available during standard operation. An adversary may leverage a vulnerability inherent in a developer mode to compromise the confidentiality, integrity, and availability of DODDoW sensitive information. Disabling developer modes mitigates this risk. SFR ID: FMT_SMF.1.1 #26

V-276861 in V1R4

Title

Google Android 16 must be configured to display the DODoW advisory warning message at startup or each time the user unlocks the device.

Check text

The DODDoW warning banner can be displayed by either of the following methods (required text is found in the Discussion): 1. By placing the DODDoW warning banner text in the user agreement signed by each managed Android 16 device user (preferred method). 2. By configuring the warning banner text on the EMM console and installing the banner on each managed Android 16 mobile device. Determine which method is used at the Google Android 16 device site and follow the appropriate validation procedure below. Validation Procedure for Method #1: Review the signed user agreements for several Google Android 16 device users and verify that the agreement includes the required DODDoW warning banner text. Validation Procedure for Method #2: On the EMM console: COBO: 1. Open "Lock screen restrictions". 2. Select "Lock screen message". 3. Verify the message. COPE: 1. Open "Lock screen restrictions". 2. Select "Personal Profile". 3. Select "Lock screen message". 4. Verify the message. If, for Method #1, the required warning banner text is not on all signed user agreements reviewed; or for Method #2, the EMM console device policy is not set to display a warning banner with the appropriate designated wording; or on the managed Google Android 16 device, the device policy is not set to display a warning banner with the appropriate designated wording, this is a finding.

Fix text

Configure the DODDoW warning banner by either of the following methods (required text is found in the Discussion): 1. By placing the DODDoW warning banner text in the user agreement signed by each Google Android 16 device user (preferred method). 2. By configuring the warning banner text on the EMM console and installing the banner on each Google Android 16 mobile device. On the EMM console: COBO: 1. Open "Lock screen restrictions". 2. Select "Lock screen message". 3. Enter the message. COPE: 1. Open "Lock screen restrictions". 2. Select "Personal Profile". 3. Select "Lock screen message". 4. Enter the message. Configuration API: setDeviceOwnerLockScreenInfo

Discussion

Before granting access to the system, the mobile operating system is required to display the DODDoW-approved system use notification message or banner that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Required banners help ensure that DODDoW can audit and monitor the activities of mobile device users without legal restriction. System use notification messages can be displayed when individuals first access or unlock the mobile device. The banner must be implemented as a "click-through" banner at device unlock (to the extent permitted by the operating system). A "click-through" banner prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating "OK." The approved DODDoW text must be used exactly as required in the Knowledge Service referenced in DODI 8500.01. For devices accommodating banners of 1300 characters, the banner text is: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. For devices with severe character limitations, the banner text is: I've read & consent to terms in IS user agreem't. The administrator must configure the banner text exactly as written without any changes. SFR ID: FMT_SMF.1.1 #36

V-276862 in V1R4

Check text

Review managed Google Android 16 device configuration settings to determine if the mobile device has a USB mass storage mode and whether it has been disabled. This validation procedure is performed on both the EMM Administration Console and the managed Google Android 16 device. On the EMM console: COBO: 1. Open "User restrictions". 2. Open "Set user restrictions". 3. Verify that "Disallow USB file transfer" is toggled to "ON". COPE: 1. Open "User restrictions". 2. Open "Set user restrictions on parent". 3. Verify that "Disallow USB file transfer" is toggled to "ON". ______________________________ On the managed Google Android 16 device: 1. Plug a USB cable into the managed Google Android 16 device and connect to a non-DODDoW network-managed PC. 2. Go to Settings >> Connected devices >> USB. 3. Verify that "No data transfer" is selected. If the EMM console device policy is not set to disable USB mass storage mode, or on the managed Google Android 16 device the device policy is not set to disable USB mass storage mode, this is a finding.

V-276864 in V1R4

Discussion

Backups to remote systems (including cloud backup) can leave data vulnerable to breach on the external systems, which often offer less protection than the mobile operating system. Where the remote backup involves a cloud-based solution, the backup capability is often used to synchronize data across multiple devices. In this case, DODDoW devices may synchronize DODDoW sensitive information to a user's personal device or other unauthorized computers that are vulnerable to breach. Disallowing remote backup mitigates this risk. SFR ID: FMT_SMF.1.1 #40

V-276866 in V1R4

Check text

This is a User-Based Enforcement (UBE) control. Check a sample of Pixel phones at the site and verify that the Wi-Fi hotspot preshared key (password) is set to "WPA2/WPA3-Personal" or "WPA3-Personal". 1. Go to Settings >> Network & Internet >> Hotspot & tethering. 2. Enable "Wi-Fi hotspot". 3. On the left of the slide, tap on "Wi-Fi Hotspot" to bring up the configuration options. 4. Click on the "Security" link and verify that either "WPA2/WPA3-Personal" or "WPA3-Personal" is selected. If the Wi-Fi hotspot security is not set to "WPA2/WPA3-Personal" or "WPA3-Personal", this is a finding.

Fix text

This is a UBE control. Train users to not change the default Wi-Fi hotspot security setting: 15-character complex Wi-Fi hotspot preshared key (password) ("WPA2/WPA3-Personal" or WPA3-Personal"). (GOOG-16-009800) If the required preshared key is not set up, train users to use the following procedure to configure the required setting: 1. Go to Settings >> Network & Internet >> Hotspot & tethering. 2. Enable "Wi-Fi hotspot". 3. On the left of the slide, tap on "Wi-Fi Hotspot" to bring up the configuration options. 4. Click on the "Security" link and select either "WPA2/WPA3-Personal" or "WPA3-Personal".

V-276867 in V1R4

Discussion

App data sharing gives apps the ability to access the data of other apps for enhanced user functionality. However, sharing also poses a significant risk that unauthorized users or apps will obtain access to DODDoW sensitive information. To mitigate this risk, there are data sharing restrictions, primarily from sharing data from personal (unmanaged) apps and work (managed) apps. If a user is allowed to make exceptions to the data sharing restriction policy, the user could enable unauthorized sharing of data, leaving it vulnerable to breach. Limiting the granting of exceptions to either the administrator or common application developer mitigates this risk. Copy/paste of data between applications in different application processes or groups of application processes is considered an exception to the access control policy and therefore, the administrator must be able to enable/disable the feature. Other exceptions include allowing any data or application sharing between process groups. SFR ID: FMT_SMF.1.1 #42, FDP_ACF_EXT.1.2

V-276868 in V1R4

Discussion

Multiuser mode allows multiple users to share a mobile device by providing a degree of separation between user data. To date, no mobile device with multiuser mode features meets DODDoW requirements for access control, data separation, and nonrepudiation for user accounts. In addition, the MDFPP does not include design requirements for multiuser account services. Disabling multiuser mode mitigates the risk of not meeting DODDoW multiuser account security policies. SFR ID: FMT_SMF.1.1 #47a

V-276869 in V1R4

Discussion

Some Bluetooth profiles provide the capability for remote transfer of sensitive DODDoW data without encryption or otherwise do not meet DODDoW IT security policies and therefore must be disabled. SFR ID: FMT_SMF_EXT.1.1/BLUETOOTH BT-8

V-276870 in V1R4

Discussion

Ad hoc wireless client-to-client connections allow mobile devices to communicate with each other directly, circumventing network security policies and making the traffic invisible. This could allow the exposure of sensitive DODDoW data and increase the risk of downloading and installing malware on the DODDoW mobile device. SFR ID: FMT_SMF_EXT.1.1/WLAN

V-276871 in V1R4

Fix text

All Google Android 16 device users must complete training on the following training topics (users must acknowledge that they have reviewed training via a signed User Agreement or similar written record): - Operational security concerns introduced by unmanaged applications/unmanaged personal space, including applications using global positioning system (GPS) tracking. - Need to ensure no DODDoW data is saved to the personal space or transmitted from a personal app (for example, from personal email). - If the Purebred key management app is used, users are responsible for maintaining positive control of their credentialed device at all times. The DODDoW PKI certificate policy requires subscribers to maintain positive control of the devices that contain private keys and report any loss of control so the credentials can be revoked. Upon device retirement, turn-in, or reassignment, ensure that a factory data reset is performed prior to device handoff. Follow mobility service provider decommissioning procedures as applicable. - How to configure the following UBE controls (users must configure the control) on the Google device: **Secure use of Calendar Alarm. **Local screen mirroring and mirroring procedures (authorized/not authorized for use). **Do not upload DODDoW contacts via smart call and caller ID services. **Do not configure a DODDoW network (work) VPN profile on any third-party VPN client installed in the personal space. **If Bluetooth connections are approved for mobile device, types of allowed connections (for example, car hands-free but not Bluetooth wireless keyboard). **How to perform a full device wipe. **Use default Wi-Fi hotspot password: 15-character complex Wi-Fi hotspot preshared password enabled ("WPA2/WPA3-personal") - AO guidance on acceptable use and restrictions, if any, on downloading and installing personal apps and data (music, photos, etc.) in the Google device personal space.

Discussion

The security posture of Google devices requires the device user to configure several required policy rules on their device. User-Based Enforcement (UBE) is required for these controls. In addition, if the authorizing official (AO) has approved the use of an unmanaged personal space, the user must receive training on risks. If a user is not aware of their responsibilities and does not comply with UBE requirements, the security posture of the Google mobile device may become compromised, and DODDoW sensitive data may become compromised. SFR ID: NA

V-276872 in V1R4

Fix text

Disable hotspot functions on the DODDoW phone if not approved by the AO. On the EMM console: COBO: 1. Open "Set user restrictions". 2. Toggle "Disallow config tethering" to "ON". COPE: 1. Open "Set user restrictions on parent". 2. Toggle "Disallow config tethering" to "ON". If the AO has approved the use of Wi-Fi and Bluetooth hotspots, train the user to not change the default hotspot password (refer to GOOG-16-009800). By default, when Wi-Fi Hotspot is enabled, a 15-character complex password is automatically configured for the hotspot. Configuration API: DISALLOW_CONFIG_TETHERING

Discussion

Wi-Fi and Bluetooth hotspot use may increase the risk for exposing sensitive DODDoW data for some use cases; therefore, it should be disabled unless approved by the AO. When a DODDoW mobile phone is used as a Wi-Fi or Bluetooth hotspot, a hotspot password must be enabled; otherwise, unauthorized devices could connect to the DODDoW hotspot, which may increase the risk of exposure of sensitive DODDoW data and/or a performance degradation of the DODDoW mobile phone. SFR ID: FMT_SMF_EXT.1.1 / WLAN #3

V-276874 in V1R4

Title

Google Android 16 must have the DODoW root and intermediate PKI certificates installed.

Check text

Review device configuration settings to confirm that the DODDoW root and intermediate PKI certificates are installed. This procedure is performed on both the EMM Administration Console and the managed Google Android 16 device. The current DODDoW root and intermediate PKI certificates may be obtained in self-extracting zip files at http://cyber.mil/pki-pke (for NIPRNet). On the EMM console, verify that the DODDoW root and intermediate certificates are part of a device and/or work profile that is being pushed down to the devices. On the managed Google Android 16 device: 1. Open Settings. 2. Tap "Security & privacy". 3. Tap "Advanced". 4. Tap "More security & privacy". 5. Tap "Encryption & credentials". 6. Tap "Trusted credentials". 7. Verify that DODDoW root and intermediate PKI certificates are listed under the User tab in the Work section. If on the EMM console the DODDoW root and intermediate certificates are not listed in a profile, or the managed Android 16 device does not list the DODDoW root and intermediate certificates under the user tab, this is a finding.

Fix text

Configure the Google Android 16 device to install DODDoW root and intermediate certificates. On the EMM console, upload DODDoW root and intermediate certificates as part of a device and/or work profile. The current DODDoW root and intermediate PKI certificates may be obtained in self-extracting zip files at http://cyber.mil/pki-pke (for NIPRNet). Configuration API: installCaCert()

Discussion

DODDoW root and intermediate PKI certificates are used to verify the authenticity of PKI certificates of users and web services. If the root and intermediate certificates are not available, an adversary could falsely sign a certificate in such a way that it could not be detected. Providing access to the DODDoW root and intermediate PKI certificates greatly diminishes the risk of this attack. SFR ID: FMT_SMF.1.1 #11

V-276875 in V1R4

Discussion

If the user is able to add a personal email account (POP3, IMAP, EAS) to the work email app, it could be used to forward sensitive DODDoW data to unauthorized recipients. Restricting email account addition to the administrator or restricting email account addition to allowlisted accounts mitigates this vulnerability. SFR ID: FMT_SMF.1.1 #47

V-276876 in V1R4

Discussion

The system application disable list controls user access to/execution of all core and preinstalled applications. Core application: Any application integrated into Google Android 16 by Google. Preinstalled application: Additional noncore applications included in the Google Android 16 build by Google or the wireless carrier. Some system applications can compromise DODDoW data or upload users' information to non-DODDoW-approved servers. A user must be blocked from using such applications that exhibit behavior that can result in compromise of DODDoW data or DODDoW user information. The site administrator must analyze all preinstalled applications on the device and disable all applications not approved for DODDoW use by configuring the system application disable list. SFR ID: FMT_SMF.1.1 #47

V-276877 in V1R4

Discussion

Wi-Fi Aware allows direct connections between nearby devices for fast data transfer, video streaming, and multiplayer gaming. It allows full peer-to-peer device discovery and communication where two or more devices are publishing and/or subscribing to the same known service name. There is risk that sensitive DODDoW information could be transferred from a DODDoW mobile device to a non-DODDoW device or from Work Profile apps on a DODDoW device to Personal Profile apps on a non-DODDoW device.

V-276880 in V1R4

Discussion

If a user is able to configure the security setting, the user could inadvertently or maliciously set it to a value that poses unacceptable risk to DODDoW information systems. An adversary could exploit vulnerabilities created by the weaker configuration to compromise DODDoW sensitive information. SFR ID: FMT_MOF_EXT.1.2 #24

V-276885 in V1R4

Title

Google Android 16 must allow only the administrator (EMM) to install/remove DODoW root and intermediate PKI certificates.

Check text

Review the device configuration to confirm that the user is unable to remove DODDoW root and intermediate PKI certificates. On the EMM console: 1. Open "Set user restrictions". 2. Verify that "Disallow config credentials" is toggled to "ON". On the Google Android 16 device: 1. Open Settings. 2. Tap "Security & privacy". 3. Tap "More security & privacy". 4. Tap "Encryption & credentials". 5. Tap "Trusted credentials". 6. Verify that the user is unable to untrust or remove any work certificates. If on the Google Android 16 device the user is able to remove certificates, this is a finding.

Fix text

Configure Google Android 16 device to prevent a user from removing DODDoW root and intermediate PKI certificates. On the EMM console: 1. Open "Set user restrictions". 2. Toggle "Disallow config credentials" to "ON". Configuration API: DISALLOW_CONFIG_CREDENTIALS

Discussion

DODDoW root and intermediate PKI certificates are used to verify the authenticity of PKI certificates of users and web services. If the user is allowed to remove root and intermediate certificates, the user could allow an adversary to falsely sign a certificate in such a way that it could not be detected. Restricting the ability to remove DODDoW root and intermediate PKI certificates to the administrator mitigates this risk. SFR ID: FMT_MOF_EXT.1.2 #47

V-276886 in V1R4

Check text

Review the EMM configuration to confirm phone hub has been disabled. On the management tool: 1. Open "Nearby notification streaming policy". 2. Verify that "Nearby notification streaming policy" is set to "Disabled". 3. Open "Nearby app streaming policy". 4. Verify that "Nearby app streaming policy" is set to "Disabled". If on the management tool the "Nearby Streaming Policy" is not set to "Disabled" and "Nearby app streaming policy" is not set to "Disabled", this is a finding. Note: From a Chromebook, if a device is connected to the Phone Hub, try to set up the Notifications. It will fail to connect to the device to complete the setup if Phone Hub has been disabled on the DODDoW Android device.

Discussion

It may be possible to transfer work profile data on a DODDoW Android device to an unauthorized Chromebook if the user has the same Google Account set up on the Chromebook and in the work profile on the Android device. This may result in the exposure of sensitive DODDoW data. SFR ID: FMT_MOF_EXT.1.2 #47

V-276887 in V1R4

Discussion

Private Space is an Android feature that provides a separate encrypted container on the mobile device. Apps in Private Space show up in a separate container in the launcher and are hidden from the "Recents" view, notifications, settings, and other apps when the private space is locked. In addition, an MDM server allowlist or blocklist cannot control the installation of apps into Private Space. Malware and other unauthorized apps could be installed on a DODDoW mobile device, which could lead to the compromise of DODDoW sensitive information or to an attack on the DODDoW network. SFR ID: FMT_MOF_EXT.1.2 #47

V-276888 in V1R4

Discussion

This feature must be disabled to comply with DODDoW electronic records retention requirements for mobile devices. Otherwise, mobile device users could wipe the device, which would violate DODDoW policy. SFR ID: FMT_MOF_EXT.1.2 #47

V-276889 in V1R4

Discussion

Wireless printing allows the printing of sensitive DODDoW documents to non-DODDoW controlled printers, which may lead to the exposure of sensitive DODDoW information. SFR ID: FMT_MOF_EXT.1.2 #47

V-276891 in V1R4

Discussion

The screen capture feature could lead to the exposure of sensitive DODoW information. SFR ID: FMT_MOF_EXT.1.2 #47

V-276892 in V1R4

Discussion

DODDoW mobile devices are in constant risk of cyber threats. MTD apps mitigate these risks by providing real-time threat detection, malware prevention, and vulnerability analysis. SFR ID: FMT_MOF_EXT.1.2 #47

V-276893 in V1R4

Discussion

Authorizing official (AO) approval is required before the mobile device camera can be enabled for a specific user or group of users, based on a risk assessment of the operational environment. Camera use may lead to the exposure of sensitive DODDoW information in some operational environments. SFR ID: FMT_MOF_EXT.1.2 #47

V-276894 in V1R4