Ivanti Sentry 9.x ALG Security Technical Implementation Guide

  • Version/Release: V3R1
  • Published: 2024-09-25
  • Released: 2024-10-24
  • Expand All:
  • Severity:
  • Sort:
Compare

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

View

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

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
b
The Sentry must enforce approved authorizations for logical access to information and system resources by enabling identity-based, role-based, and/or attribute-based security policies. These controls are enabled in MobileIron UEM (MobileIron Core) and applied by the Sentry for conditional access enforcement.
AC-3 - Medium - CCI-000213 - V-251008 - SV-251008r1028171_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
MOIS-AL-000010
Vuln IDs
  • V-251008
Rule IDs
  • SV-251008r1028171_rule
Successful authentication through Sentry must not automatically give an entity access to resources behind Sentry. The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. All DoD systems must be properly configured to incorporate access control methods that do not rely solely on authentication for authorized access.
Checks: C-54443r1004751_chk

Verify the Sentry is configured to enforce approved authorizations for logical access to information and system resources by employing identity-based, role-based, and attribute-based security policies. The Sentry system configured for ActiveSync, AppTunnel, and/or as a Kerberos Proxy ensures only authenticated and authorized apps and managed devices have access to backend resources. Refer to the Sentry 9.8.0 Guide for Core pages 20-21 for more information. 1. Log in to the Core Admin Portal. 2. Go to Service >> Sentry. 3. Verify the Sentry is configured with one or all the of the applicable services (ActiveSync, AppTunnel, or Kerberos Proxy). If no services are applied, this is a finding. 4. If Sentry is being used as an ActiveSync Proxy or AppTunnel, verify an Identity Certificate is configured for the Device Authentication Configuration in the Sentry Configuration and that CRL is enabled. If not, this is a finding. Refer to the Sentry 9.8.0 Guide on how to configure the specific Sentry Services. ActiveSync: Standalone Sentry for ActiveSync Email Section, AppTunnel: Standalone Sentry for AppTunnel Section Kerberos Proxy: Standalone Sentry for KKDCP Section. MobileIron UEM applies security, privacy, lockdown, and sync policies to registered devices. These policies ensure that devices can connect only if they comply to an organization’s security requirements. Standalone Sentry gets device posture and compliance information from MobileIron UEM, and allows access to Email via ActiveSync or backend systems based on the device posture. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Policies. 3. Verify the appropriate Lockdown and Security Policies are applied to the devices accessing systems behind the Sentry. If no policies are applied, this is a finding. By default, Sentry allows unregistered devices to access the ActiveSync server. Use this setting to change Sentry’s behavior to block unregistered devices from access if configuring Sentry for ActiveSync. 1. Log in to the Core Admin Portal. 2. Go to Services >> Sentry >> Preferences. 3. Verify "Yes" for Auto Block Unregistered Devices is applied. If not applied, this is a finding.

Fix: F-54397r1004752_fix

Configure the Sentry to enforce approved authorizations for logical access to information and system resources by employing identity-based, role-based, and/or attribute-based security policies. 1. Log in to the Core Admin Portal. 2. Go to Services >> Sentry. 3. Create one or all of the applicable Sentry Services: ActiveSync, AppTunnel, or Kerberos Proxy based on the Sentry use case. (Refer to the Sentry Guide on how to configure the specific Sentry Services. ActiveSync: Page 43; AppTunnel: Page 64; Kerberos Proxy: Page 92.) 4. If Sentry is being used as an ActiveSync Proxy or AppTunnel, configure an Identity Certificate for the Device Authentication Configuration in the Sentry Configuration and enable the CRL checkbox. 5. Save the Sentry configuration. MobileIron UEM applies security, privacy, lockdown, and sync policies to registered devices. These policies ensure that devices can connect only if they comply to an organization’s security requirements. Standalone Sentry gets device posture and compliance information from MobileIron UEM and allows access to email via ActiveSync or backend systems based on the device posture. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Policies. 3. Create or edit the Lockdown and Security Policies. 4. Ensure the policies are applied to devices accessing systems behind a Sentry if configuring Sentry for ActiveSync. By default, Sentry allows unregistered devices to access the ActiveSync server. Use this setting to change Sentry’s behavior to block unregistered devices from access if configuring Sentry for ActiveSync. 1. Log in to the Core Admin Portal. 2. Go to Services >> Sentry >> Preferences. 3. Change the Auto Block Unregistered Devices setting to "Yes". 4. Click "Save".

b
The Sentry must enforce approved authorizations for controlling the flow of information within the network based on attribute-based inspection of the source, destination, and headers, of the communications traffic.
AC-4 - Medium - CCI-001368 - V-251009 - SV-251009r1028172_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
MOIS-AL-000020
Vuln IDs
  • V-251009
Rule IDs
  • SV-251009r1028172_rule
Information flow control regulates where information is allowed to travel within a network. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Sentry enforces approved authorizations by employing security policy and/or rules configured in MobileIron UEM that restrict information system services capability based on header or protocol information.
Checks: C-54444r802247_chk

Verify the Sentry and MobileIron UEM is configured to enforce approved authorizations for controlling the flow of information within the network based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic. MobileIron UEM applies Configurations to devices/users based on manual or dynamic labels. Verify that Configurations that leverage Sentry such as Email, VPN, Docs@Work, or any backend service which leverage Sentry as a gateway are applied to the appropriate user groups via the configurable labels. If not, this is a finding. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Configurations. 3. Verify the Sentry related Configurations are applied to the devices accessing systems behind the Sentry. If Configurations are misassigned to the wrong label/user groups, this is a finding.

Fix: F-54398r802248_fix

Configure the Sentry to enforce approved authorizations for controlling the flow of information within the network based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic via MI Core labels. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Configurations. 3. For Active Sync email use cases with Sentry, apply the Exchange or mail app configurations using the Sentry to devices via a label. 4. For App Tunnel use cases, apply app configurations using the Sentry to device via a label.

b
The Sentry must restrict or block harmful or suspicious communications traffic by controlling the flow of information between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.
AC-4 - Medium - CCI-001414 - V-251010 - SV-251010r1028173_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001414
Version
MOIS-AL-000030
Vuln IDs
  • V-251010
Rule IDs
  • SV-251010r1028173_rule
Information flow control regulates where information is allowed to travel within a network and between interconnected networks. Blocking or restricting detected harmful or suspicious communications between interconnected networks enforces approved authorizations for controlling the flow of traffic. This requirement applies to the flow of information between the Sentry when used as a gateway or boundary device which allows traffic flow between interconnected networks of differing security policies. The Sentry and MobileIron UEM must be configured with policy filters (e.g., security policy and compliance rules) that restrict or block information system services.
Checks: C-54445r1004754_chk

Verify the Sentry restricts or blocks harmful or suspicious communications traffic by controlling the flow of information between interconnected networks based on mobile device security posture reported by the MobileIron UEM. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Policies. 3. Verify the appropriate Security Policies are applied to the devices accessing systems behind the Sentry. 4. Click "Edit". 5. In the Access Control section of the policy, verify the Block Email and AppConnect apps compliance action is selected for the "when a compromised device is detected" control for the iOS and Android device operating systems sections. 6. Click "Cancel". If "when a compromised device is detected" control for the iOS and Android device operating systems is not selected in the Access control section, this is a finding.

Fix: F-54399r1004755_fix

Configure the Sentry to restrict or block harmful or suspicious communications traffic by controlling the flow of information between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Policies. 3. Ensure the appropriate Security Policies are applied to the devices accessing systems behind the Sentry. 4. Click "Edit". 5. In the Access Control section of the policy, select the Block Email and AppConnect apps compliance for the “when a compromised device is detected” control for the iOS and Android device operating systems sections. 6. Click "Save". Refer to the Sentry 9.8.0 Guide on how to configure the specific Sentry Services.

b
The Sentry providing intermediary services for remote access communications traffic must use encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions.
AC-17 - Medium - CCI-000068 - V-251011 - SV-251011r1028175_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
MOIS-AL-000160
Vuln IDs
  • V-251011
Rule IDs
  • SV-251011r1028175_rule
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). Encryption provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection, thereby providing a degree of confidentiality. The encryption strength of the mechanism is selected based on the security categorization of the information. This requirement applies to ALGs providing remote access proxy services as part of its intermediary services (e.g., OWA or TLS gateway).
Checks: C-54446r1004757_chk

Verify the Sentry uses encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions. On the Sentry CLI console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials established when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "show FIPS". 6. Verify "FIPS 140 mode is enabled" is displayed. If the Sentry Server does not report that FIPS mode is "enabled", this is a finding.

Fix: F-54400r1028174_fix

Configure the Sentry Server to use a FIPS 140-2-validated cryptographic module. On the Sentry console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials established when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "configure terminal". 6. Enter the following command to enable FIPS: FIPS 7. Enter the following command to proceed with the necessary reload: do reload 8. Enter "Yes" at save configuration modified prompt. 9. Enter "Yes" at proceed do reload.

b
If Sentry stores secret or private keys, it must use FIPS-approved key management technology and processes in the production and control of private/secret cryptographic keys.
AC-17 - Medium - CCI-000068 - V-251012 - SV-251012r1028177_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
MOIS-AL-000170
Vuln IDs
  • V-251012
Rule IDs
  • SV-251012r1028177_rule
Private key data is used to prove that the entity presenting a public key certificate is the certificate's rightful owner. Compromise of private key data allows an adversary to impersonate the key holder.
Checks: C-54447r1004760_chk

Verify the Sentry uses encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions. On the Sentry CLI console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "show FIPS". 6. Verify "FIPS 140 mode is enabled" is displayed. If the Sentry Server does not report that FIPS mode is "enabled", this is a finding.

Fix: F-54401r1028176_fix

Configure the Sentry Server to use a FIPS 140-2-validated cryptographic module. On the Sentry console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "configure terminal". 6. Enter the following command to enable FIPS: FIPS 7. Enter the following command to proceed with the necessary reload: do reload 8. Enter "Yes" at save configuration modified prompt. 9. Enter "Yes" at proceed do reload.

b
The Sentry that provides intermediary services for TLS must be configured to comply with the required TLS settings in NIST SP 800-52.
AC-17 - Medium - CCI-000068 - V-251013 - SV-251013r1028178_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
MOIS-AL-000180
Vuln IDs
  • V-251013
Rule IDs
  • SV-251013r1028178_rule
SP 800-52 provides guidance on using the most secure version and configuration of the TLS/SSL protocol. Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks which exploit vulnerabilities in this protocol.
Checks: C-54448r1004763_chk

Verify the Sentry is configured to implement the applicable required TLS settings in NIST PUB SP 800-52. 1. Log in to Sentry. 2. Go to Settings >> Services >> Sentry. 3. For each of the following configurations, follow the step 4 procedure: a. Incoming SSL configuration b. Outgoing SSL configuration c. UEM SSL configuration d. Access SSL configuration 4. Verify only TLS 1.2 is selected. If any other protocol is selected, this is a finding. For more information, go to the "Sentry 9.8.0 guide for Core" and refer the main section "Standalone Sentry Settings", which includes subsections on how TLS 1.2 is set as the default protocol: 1. Incoming SSL configuration 2. Outgoing SSL configuration 3. UEM SSL configuration 4. Access SSL configuration Sentry conforms to the NIST SP 800-52 TLS settings by setting TLS 1.2 by default.

Fix: F-54402r1004764_fix

Configure the Sentry to comply with applicable required TLS settings in NIST PUB SP 800-52. 1. Log in to Sentry. 2. Go to Settings >> Services >> Sentry. 3. For each of the following configurations, follow the step 4 procedure: a. Incoming SSL configuration b. Outgoing SSL configuration c. UEM SSL configuration d. Access SSL configuration 4. Select only TLS 1.2 and remove others if selected. 5. Click "Apply".

b
The Sentry providing intermediary services for remote access communications traffic must use NIST FIPS-validated cryptography to protect the integrity of remote access sessions.
AC-17 - Medium - CCI-001453 - V-251014 - SV-251014r1028180_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
MOIS-AL-000190
Vuln IDs
  • V-251014
Rule IDs
  • SV-251014r1028180_rule
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access is access to DoD-nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. This requirement applies to ALGs providing remote access proxy services as part of its intermediary services (e.g., OWA or TLS gateway).
Checks: C-54449r1004766_chk

Verify the Sentry uses encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions. On the Sentry CLI console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "show FIPS". 6. Verify "FIPS 140 mode is enabled" is displayed. If the Sentry Server does not report that FIPS mode is "enabled", this is a finding.

Fix: F-54403r1028179_fix

Configure the Sentry Server to use a FIPS 140-2-validated cryptographic module. On the Sentry console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "configure terminal". 6. Enter the following command to enable FIPS: FIPS 7. Enter the following command to proceed with the necessary reload: do reload 8. Enter "Yes" at save configuration modified prompt. 9. Enter "Yes" at proceed do reload.

a
The Sentry must produce audit records containing information to establish what type of events occurred.
AU-3 - Low - CCI-000130 - V-251015 - SV-251015r1028181_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000130
Version
MOIS-AL-000200
Vuln IDs
  • V-251015
Rule IDs
  • SV-251015r1028181_rule
Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the gateway logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element. This requirement does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54450r1004769_chk

Verify the Sentry produces audit records containing information to establish what type of events occurred. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If the syslog server is not configured or "Audit" is not selected under "Modify Syslog", this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is date and timestamp, the source of the event, the location of the event, and the result of the action whether a success or failure.

Fix: F-54404r1004770_fix

Configure the Sentry to produce audit records containing information to establish what type of events occurred. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". 5. Set the Admin State to "Enable". 6. Click "Apply".

a
The Sentry must produce audit records containing information to establish when (date and time) the events occurred.
AU-3 - Low - CCI-000131 - V-251016 - SV-251016r1028182_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000131
Version
MOIS-AL-000210
Vuln IDs
  • V-251016
Rule IDs
  • SV-251016r1028182_rule
Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment, and provide forensic analysis of network traffic patterns, it is essential for security personnel to know when flow control events occurred within the infrastructure. Associating event types with detected events in the network audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element. This requirement does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54451r1004772_chk

Verify the Sentry produces audit records containing information to establish when (date and time) the events occurred. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If the syslog server is not configured or "Audit" is not selected under "Modify Syslog", this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is the date and timestamp, the source of the event, the location of the event, and the result of the action whether a success/failure.

Fix: F-54405r1004773_fix

Configure the Sentry to produce audit records containing information to establish when (date and time) the events occurred. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". 5. Set the Admin State to "Enable". 6. Click "Apply".

a
The Sentry must produce audit records containing information to establish where the events occurred.
AU-3 - Low - CCI-000132 - V-251017 - SV-251017r1028183_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000132
Version
MOIS-AL-000220
Vuln IDs
  • V-251017
Rule IDs
  • SV-251017r1028183_rule
Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know where events occurred, such as network element components, modules, device identifiers, node names, and functionality. Associating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element. This requirement does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54452r1004775_chk

Verify the Sentry produces audit records containing information to establish where the events occurred. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If the syslog server is not configured or "Audit" is not selected under "Modify Syslog", this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is the date and timestamp, the source of the event, the location of the event, the result of the action whether a success or failure.

Fix: F-54406r1004776_fix

Configure the Sentry to produce audit records containing information to establish where the events occurred. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit" . 5. Set the Admin State to "Enable". 6. Click "Apply".

a
The Sentry must produce audit records containing information to establish the source of the events.
AU-3 - Low - CCI-000133 - V-251018 - SV-251018r1028184_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000133
Version
MOIS-AL-000230
Vuln IDs
  • V-251018
Rule IDs
  • SV-251018r1028184_rule
Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.
Checks: C-54453r1004778_chk

Verify the Sentry produces audit records containing information to establish the source of the events. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If the syslog server is not configured or "Audit" is not selected under "Modify Syslog", this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is date and timestamp, the source of the event, the location of the event, and the result of the action whether a success or failure.

Fix: F-54407r1004779_fix

Configure the Sentry to produce audit records containing information to establish the source of the events. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". 5. Set the Admin State to "Enable". 6. Click "Apply".

a
The Sentry must produce audit records containing information to establish the outcome of the events.
AU-3 - Low - CCI-000134 - V-251019 - SV-251019r1028185_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000134
Version
MOIS-AL-000240
Vuln IDs
  • V-251019
Rule IDs
  • SV-251019r1028185_rule
Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the network. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the network after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. This requirement does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54454r1004781_chk

Verify the Sentry produces audit records containing information to establish the outcome of the events. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If the syslog server is not configured or if "Audit" is not selected under "Modify Syslog", this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer the following main section "Standalone Sentry Settings" under which there is a sub-section detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is the date and timestamp, the source of the event, the location of the event, and the result of the action whether a success/failure.

Fix: F-54408r1004782_fix

Configure the Sentry to produce audit records containing information to establish the outcome of the events. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". 5. Set the Admin State to "Enable". 6. Click "Apply".

a
The Sentry must generate audit records containing information to establish the identity of any individual or process associated with the event.
AU-3 - Low - CCI-001487 - V-251020 - SV-251020r1028186_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-001487
Version
MOIS-AL-000250
Vuln IDs
  • V-251020
Rule IDs
  • SV-251020r1028186_rule
Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. Associating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element. This requirement does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54455r1004784_chk

Verify the Sentry produces audit records containing information to establish the outcome of the events. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If the syslog server is not configured or "Audit" is not selected under "Modify Syslog", this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is date and timestamp, the source of the event, the location of the event, and the result of the action whether a success/failure.

Fix: F-54409r1004785_fix

1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". 5. Set the Admin State to "Enable". 6. Click "Apply".

a
The Sentry must send an alert to, at a minimum, the ISSO and SCA when an audit processing failure occurs.
AU-5 - Low - CCI-000139 - V-251021 - SV-251021r1028187_rule
RMF Control
AU-5
Severity
Low
CCI
CCI-000139
Version
MOIS-AL-000260
Vuln IDs
  • V-251021
Rule IDs
  • SV-251021r1028187_rule
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Possible audit processing failures also include the inability of Sentry to write to the central audit log. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations, (i.e., all audit data storage repositories combined), or both. This does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54456r1004787_chk

Verify the Sentry sends an alert to, at a minimum, the ISSO and SCA when an audit processing failure occurs. 1. Log in to Sentry. 2. Go to Monitoring >> Alert Configuration. 3. Verify "Send Notifications" is enabled. 4. Verify an email list containing the ISSM and SCA is input in the Email List. 5. Verify "Alert Notification Management" section is set to meet organizational requirements. If the "Alert Notification Management" section is not set to meet organizational requirements, this is a finding.

Fix: F-54410r1004788_fix

Configure the Sentry to send an alert to, at a minimum, the ISSO and SCA when an audit processing failure occurs. 1. Log in to Sentry. 2. Go to Monitoring >> Alert Configuration. 3. Configure "Send Notifications" to enabled. 4. Configure an email list containing the ISSM and SCA in the Email List. 5. Configure "Alert Notification Management" section is set to meet organizational requirements. Refer to the Sentry 9.8.0 Guide "Configuring Sentry alert notifications" section for more information.

b
The Sentry must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.
CM-6 - Medium - CCI-000366 - V-251022 - SV-251022r1028188_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
MOIS-AL-000360
Vuln IDs
  • V-251022
Rule IDs
  • SV-251022r1028188_rule
In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types); organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. ALGs are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. DoD continually assesses the ports, protocols, and services that can be used for network communications. Some ports, protocols or services have known exploits or security weaknesses. Network traffic using these ports, protocols, and services must be prohibited or restricted in accordance with DoD policy. The ALG is a key network element for preventing these non-compliant ports, protocols, and services from causing harm to DoD information systems. The network ALG must be configured to prevent or restrict the use of prohibited ports, protocols, and services throughout the network by filtering the network traffic and disallowing or redirecting traffic as necessary. Default and updated policy filters from the vendors will disallow older version of protocols and applications and will address most known non-secure ports, protocols, and/or services. However, sources for further policy filters are the IAVMs and the PPSM requirements. Satisfies: SRG-NET-000132-ALG-000087, SRG-NET-000512-ALG-000062
Checks: C-54457r1004790_chk

View the configuration and vendor documentation of the Sentry application to find the minimum ports, protocols, and services required for Sentry operation. 1. Log in to Sentry System Manager. 2. Go to Security >> Access Control Lists >> ACLs. 3. Check all the ACLs to determine if the service restricted has an ACL already available. If it does not, this is a finding.

Fix: F-54411r802287_fix

Disable ports, protocols, and/or services not required for Sentry operation. 1. Log in to the Standalone Sentry System Manager. 2. Go to Security >> Access Control Lists >> ACLs. 3. Check all the ACLs to determine if the service restricted has an ACL already available. If it does not, click "Add". 4. In the "Name" field, enter a name to identify the ACL. 5. In the "Description" field, enter text to clarify the purpose of the ACL. 6. Click "Save". 7. Select the new ACL created and click it, which should open a "Modify ACL" dialog box. 8. Click "Add" to add an access control entry (ACE) to the ACL. Each ACE consists of a combination of the network hosts and services configured for use in ACLs. 9. Use the following guidelines to complete the form: Source Network Destination Network Service Action - Select Permit or Deny from the drop-down list. Connections Per Minute 10. Click "Apply".

b
The Sentry providing mobile device access control intermediary services must be configured with a pre-established trust relationship and mechanisms with appropriate authorities (e.g., Active Directory or AAA server) which validate mobile device account access authorizations and privileges.
IA-2 - Medium - CCI-000764 - V-251023 - SV-251023r1028189_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
MOIS-AL-000380
Vuln IDs
  • V-251023
Rule IDs
  • SV-251023r1028189_rule
User account and privilege validation must be centralized in order to prevent unauthorized access using changed or revoked privileges. ALGs can implement functions such as traffic filtering, authentication, access, and authorization functions based on computer and user privileges. However, the directory service (e.g., Active Directory or LDAP) must not be installed on the ALG, particularly if the gateway resides on the untrusted zone of the Enclave.
Checks: C-54458r1004792_chk

Verify the MobileIron Core configured with the Sentry is enabled with Active Directory or LDAP server. 1. Log in to the MobileIron Core MIFS portal. 2. Go to Services >> LDAP. 3. Verify an LDAP server is configured and enabled. If an LDAP server is not configured and enabled, this is a finding.

Fix: F-54412r1004793_fix

Ensure the MobileIron Core configured with the Sentry is enabled with Active Directory or LDAP server. 1. Log in to the MobileIron Core MIFS portal. 2. Go to Services >> LDAP. 3. Click "Add New". 4. Follow LDAP Configuration Wizard Prompts to enable an LDAP server (refer to the "Configuring LDAP Servers" section of the "Getting Started with MobileIron Core Guide" for more information). 5. Click "Save".

b
The Sentry providing mobile device authentication intermediary services must restrict mobile device authentication traffic to specific authentication server(s).
IA-2 - Medium - CCI-000764 - V-251024 - SV-251024r1028190_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
MOIS-AL-000390
Vuln IDs
  • V-251024
Rule IDs
  • SV-251024r1028190_rule
User authentication can be used as part of the policy filtering rule sets. Some URLs or network resources can be restricted to authenticated users only. Users are prompted by the application or browser for credentials. Authentication service may be provided by the ALG as an intermediary for the application; however, the authentication credential must be stored in the site's directory services server. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., proxy capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management).
Checks: C-54459r802292_chk

If the Sentry does not provide user authentication intermediary services, this is not applicable. Verify the Sentry is configured with a preestablished trust relationship and mechanisms with appropriate authorities that validate each user access authorization and privileges. If Sentry provides user authentication intermediary services for ActiveSync, verify them as follows: 1. In the MobileIron Core Admin Portal, go to Services >> Sentry. 2. Click the "Edit" icon next to Sentry, which opens the "Edit Standalone Sentry" dialog. 3. Determine if the fields in the form are configured for ActiveSync. 4. Look under "ActiveSync Server(s)". 5. Verify only the ActiveSync Servers' end users are on this list. If ActiveSync Servers' end users are not the only entities on this list, this is a finding. If Sentry provides user authentication intermediary services for AppTunnel, verify only the Servers that users should be authenticating to are specified in the Services list. 1. In the MobileIron Core Admin Portal, go to Services >> Sentry. 2. Select the "Edit" icon for an existing Standalone Sentry entry. 3. Review the Approved AppTunnel Services and verify only the Servers that users should be authenticating to are specified in the services list. If end users are able to access AppTunnel services they should not be accessing, this is a finding.

Fix: F-54413r802293_fix

If user authentication intermediary services are provided, configure the Sentry to use a specific authentication server(s). For ActiveSync services: 1. In the MobileIron Core Admin Portal, go to Services >> Sentry. 2. Select Add New >> Standalone Sentry or click the "Edit" icon for an existing Standalone Sentry entry. 3. Complete the fields in the form for ActiveSync Configuration. 4. Configure approved ActiveSync servers. 5. Click "Save". For AppTunnel services: 1. In the MobileIron Core Admin Portal, go to Services >> Sentry. 2. Select Add New >> Standalone Sentry or click the "Edit" icon for an existing Standalone Sentry entry. 3. Complete the fields in the form for AppTunnel Configuration. 4. Configure approved AppTunnel services. 5. Click "Save".

b
The Sentry providing mobile device authentication intermediary services must use multifactor authentication for network access to non-privileged accounts.
IA-2 - Medium - CCI-000766 - V-251025 - SV-251025r1028191_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000766
Version
MOIS-AL-000400
Vuln IDs
  • V-251025
Rule IDs
  • SV-251025r1028191_rule
To ensure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: 1. Something you know (e.g., password/PIN) 2. Something you have (e.g., cryptographic, identification device, token) 3. Something you are (e.g., biometric) Non-privileged accounts are not authorized access to the network element regardless of access method. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Authenticating with a PKI credential and entering the associated PIN is an example of multifactor authentication. This requirement applies to ALGs that provide user authentication intermediary services.
Checks: C-54460r802295_chk

Verify the MobileIron Core has a device-level password policy enforcing password or biometric and is applied to managed devices. This should be done by default. Verify the Sentry is configured for certificate based authentication. Verify the Sentry is set up to provide user authentication intermediary services. 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, select an option appropriate for this implementation. 4. Depending on the option selected, follow the instructions in one of the following sections to complete the configuration: - Group Certificate - Identity Certificate - Identity Certificate with Kerberos constrained delegation If Sentry is not configured for certificate-based authentication, this is a finding.

Fix: F-54414r1004795_fix

If user authentication intermediary services are provided, configure the Sentry to use multifactor authentication for network access to non-privileged accounts. 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, select an option appropriate for this implementation. 4. Depending on the option selected, follow the instructions in one of the following sections to complete the configuration: - Group Certificate Refer to "Configuring authentication using a group certificate" for next steps. - Identity Certificate Refer to "Configuring authentication using an identity certificate and Pass Through" for next steps. OR Refer to "Configuring authentication using an identity certificate and Kerberos constrained delegation" for next steps. For more information, in the "Sentry 9.8.0 Guide for Core" refer to the section "Device and Server Authentication", which includes the subsection "Configuring device and server authentication".

b
The Sentry providing mobile device authentication intermediary services must implement replay-resistant authentication mechanisms for network access to nonprivileged accounts.
IA-2 - Medium - CCI-001941 - V-251026 - SV-251026r1029565_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001941
Version
MOIS-AL-000410
Vuln IDs
  • V-251026
Rule IDs
  • SV-251026r1029565_rule
A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A nonprivileged account is any account with the authorizations of a non-privileged user. Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. Security relevant roles include key management, account management, network and system administration, database administration, and web administration. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS). Additional techniques include time-synchronous or challenge-response one-time authenticators. This requirement applies to ALGs that provide user authentication intermediary services.
Checks: C-54461r1004797_chk

The Sentry is configured with TLS by default. The Sentry enables TLS 1.2 by default. To check the status: 1. Log in to Sentry. 2. Go to Settings >> Services >> Sentry. 3. For each of the following configurations, follow step 4: a. Incoming SSL configuration b. Outgoing SSL configuration c. UEM SSL configuration d. Access SSL configuration 4. In Protocols, verify TLS 1.2 is enabled. If TLS 1.2 is not enabled for each configuration, this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes subsections on how TLS 1.2 is set as the default protocol: 1. Incoming SSL configuration 2. Outgoing SSL configuration 3. UEM SSL configuration 4. Access SSL configuration Sentry conforms to the NIST SP 800-52 TLS settings by setting TLS 1.2 by default.

Fix: F-54415r1004798_fix

The Sentry is configured with TLS by default. To configure the Sentry with TLS 1.2: 1. Log in to Sentry. 2. Go to Settings >> Services >> Sentry. 3. Select each of the configurations listed below and follow steps 4 and 5: a. Incoming SSL configuration b. Outgoing SSL configuration c. UEM SSL Configuration d. Access SSL Configuration 4. In protocols, make TLS 1.2 enabled. 5. Apply the configuration and click "Save" in the top right corner.

b
The Sentry that provides intermediary services for TLS must validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation.
IA-5 - Medium - CCI-000185 - V-251027 - SV-251027r1028193_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000185
Version
MOIS-AL-000420
Vuln IDs
  • V-251027
Rule IDs
  • SV-251027r1028193_rule
A certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses.
Checks: C-54462r1004800_chk

The Sentry is configured with TLS by default. The Sentry enables TLS 1.2 by default. To check the status: 1. Log in to Sentry. 2. Go to Settings >> Services >> Sentry. 3. For each of the following configurations, follow step 4: a. Incoming SSL configuration b. Outgoing SSL configuration c. UEM SSL configuration d. Access SSL configuration 4. In Protocols, verify TLS 1.2 is enabled. If TLS 1.2 is not enabled for each configuration, this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes subsections on how TLS 1.2 is set as the default protocol: 1. Incoming SSL configuration 2. Outgoing SSL configuration 3. UEM SSL configuration 4. Access SSL configuration Sentry conforms to the NIST SP 800-52 TLS settings by setting TLS 1.2 by default.

Fix: F-54416r1004801_fix

The Sentry is configured with TLS by default. To configure the Sentry with TLS 1.2: 1. Log in to Sentry. 2. Go to Settings >> Services >> Sentry. 3. Select each of the configurations listed below and follow steps 4 and 5: a. Incoming SSL configuration b. Outgoing SSL configuration c. UEM SSL Configuration d. Access SSL Configuration 4. In protocols, make TLS 1.2 enabled. 5. Apply the configuration and click "Save" in the top right corner.

b
The Sentry providing PKI-based mobile device authentication intermediary services must map authenticated identities to the mobile device account.
IA-5 - Medium - CCI-000187 - V-251028 - SV-251028r1028194_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000187
Version
MOIS-AL-000430
Vuln IDs
  • V-251028
Rule IDs
  • SV-251028r1028194_rule
Authorization for access to any network element requires an approved and assigned individual account identifier. To ensure only the assigned individual is using the account, the account must be bound to a user certificate when PKI-based authentication is implemented. This requirement applies to ALGs that provide user authentication intermediary services (e.g., authentication gateway or TLS gateway). This does not apply to authentication for the purpose of configuring the device itself (device management).
Checks: C-54463r802304_chk

Verify the Sentry is configured with certificate-based authentication with the appropriate certificate field user mappings. 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, verify certificate mappings are configured in the "certificate mapping" field. If Sentry is not configured to map authenticated identities to the user accounts, this is a finding.

Fix: F-54417r802305_fix

If PKI-based user authentication intermediary services are provided, configure the Sentry to map the authenticated identities to the user account. 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, configure certificate mappings in the "certificate mapping" field (i.e., User UPN = Subject Alternative Name: NT Principal Name). 4. Click "Save".

b
The Sentry must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity; and for mobile device sessions (non-privileged session), the session must be terminated after 15 minutes of inactivity.
SC-10 - Medium - CCI-001133 - V-251029 - SV-251029r1028195_rule
RMF Control
SC-10
Severity
Medium
CCI
CCI-001133
Version
MOIS-AL-000470
Vuln IDs
  • V-251029
Rule IDs
  • SV-251029r1028195_rule
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system level network connection. ALGs may provide session control functionality as part of content filtering, load balancing, or proxy services.
Checks: C-54464r802307_chk

1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Configurations. 3. Click on existing VPN Configuration for MobileIron Tunnel; verify "Connection Type" is set to "MobileIron Tunnel". 4. Go to "Custom Data" section at the bottom and find the following Key Value pair: "TcpIdleTmoMs" The default idle timeout for the session is 1 hour. Therefore, if the key value pair is missing, this is a finding. If the key value pair is present, verify the value is no greater than 900000 millisec (15 min). If key value pair is not present or is set to a value greater than 900000, this is a finding.

Fix: F-54418r802308_fix

Configure Sentry to terminate all network connections associated with a communication session at 15 minutes of inactivity. 1. Log in to the Core Admin Portal. 2. Go to Policies and Configurations >> Configurations. 3. Click on existing VPN Configuration for MobileIron Tunnel; ensure "Connection Type" is set to "MobileIron Tunnel". 4. Go to "Custom Data" section at the bottom and find the following Key Value pair: "TcpIdleTmoMs" If the key value pair is present, set the value to 900000 millisec (15 min).

a
The Sentry must offload audit records onto a centralized log server.
AU-4 - Low - CCI-001851 - V-251030 - SV-251030r1028196_rule
RMF Control
AU-4
Severity
Low
CCI
CCI-001851
Version
MOIS-AL-000870
Vuln IDs
  • V-251030
Rule IDs
  • SV-251030r1028196_rule
Without the capability to select a user session to capture or view, investigations into suspicious or harmful events would be hampered by the volume of information captured. The intent of this requirement is to ensure the capability to select specific sessions to capture is available in order to support general auditing/incident investigation, or to validate suspected misuse by a specific user. Examples of session events that may be captured include, port mirroring, tracking websites visited, and recording information and/or file transfers.
Checks: C-54465r1004803_chk

Verify Sentry offloads audit records onto a centralized log server. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. If it is not configured, this is a finding. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If Sentry is not configured to offload audit records, this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is date and timestamp, the source of the event, the location of the event, and the result of the action whether success/failure.

Fix: F-54419r1004804_fix

Configure the ALG to offload audit records onto a centralized log server. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is date and timestamp, the source of the event, the location of the event, and the result of the action whether a success/failure.

b
The Sentry providing mobile device authentication intermediary services must implement multifactor authentication for remote access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access.
- Medium - CCI-004046 - V-251031 - SV-251031r1029566_rule
RMF Control
Severity
Medium
CCI
CCI-004046
Version
MOIS-AL-000900
Vuln IDs
  • V-251031
Rule IDs
  • SV-251031r1029566_rule
For remote access to nonprivileged accounts, the purpose of requiring a device that is separate from the information system gaining access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authentication credentials stored on the system. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DOD common access card. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. An example of compliance with this requirement is the use of a one-time password token and PIN coupled with a password; or the use of a CAC/PIV card and PIN coupled with a password.
Checks: C-54466r985830_chk

If the Sentry does not provide user authentication intermediary services, this is not applicable. Verify the Sentry implements multifactor authentication for remote access to nonprivileged accounts. Verify the MobileIron Core has a device-level password policy enforcing password or biometric and is applied to managed devices. This should be done by default. Verify the Sentry is configured for certificate-based authentication. If the Sentry is set up as an intermediary service for backend resources: 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, select an option appropriate for this implementation. 4. Depending on the option selected, follow the instructions in one of the following sections to verify the configuration is correct: - Group Certificate - Identity Certificate - Identity Certificate with Kerberos constrained delegation If the "Device Authentication Configuration" is not set up correctly, this is a finding.

Fix: F-54420r1004806_fix

If user authentication intermediary services are provided, configure the Sentry to implement multifactor authentication for remote access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access. 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, select an option appropriate for this implementation. 4. Depending on the option selected, follow the instructions in one of the following section to complete the configuration: - Group Certificate Refer to "Configuring authentication using a group certificate" for next steps. - Identity Certificate Refer to "Configuring authentication using an identity certificate and Pass Through" for next steps. OR Refer to "Configuring authentication using an identity certificate and Kerberos constrained delegation" for next steps. For more information, in the "Sentry 9.8.0 Guide for Core", refer to the main section "Device and Server Authentication", which contains the subsection "Configuring device and server authentication".

b
The Sentry providing mobile device authentication intermediary services using PKI-based mobile device authentication must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of protected sessions.
SC-23 - Medium - CCI-002470 - V-251032 - SV-251032r1028198_rule
RMF Control
SC-23
Severity
Medium
CCI
CCI-002470
Version
MOIS-AL-000950
Vuln IDs
  • V-251032
Rule IDs
  • SV-251032r1028198_rule
Non-DoD-approved PKIs have not been evaluated to ensure they have security controls and identity vetting procedures in place that are sufficient for DoD systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DoD-approved PKIs is published at https://cyber.mil/pki-pke/interoperability. DoD-approved PKI CAs may include Category I, II, and III certificates. Category I DoD-approved External PKIs are PIV issuers. Category II DoD-approved External PKIs are Non-Federal Agency PKIs cross-certified with the Federal Bridge Certification Authority (FBCA). Category III DoD-approved External PKIs are Foreign, Allied, or Coalition Partner PKIs. Deploying the ALG with TLS enabled will require the installation of DoD and/or DoD-approved CA certificates in the trusted root certificate store of each proxy to be used for TLS traffic. This requirement focuses on communications protection for the application session rather than for the network packet.
Checks: C-54467r802316_chk

Verify Sentry only accepts end entity certificates issued by DoD PKI or DoD-approved PKI CAs for the establishment of protected sessions. Verify the MobileIron Core has a device-level password policy enforcing password or biometric and is applied to managed devices. This should be done by default. Verify the Sentry is configured for certificate-based authentication: Verify the Sentry is set up to provide user authentication intermediary services: 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, select an option appropriate for this implementation. 4. Depending on the option selected, follow the instructions in one of the following sections to complete the configuration: - Group Certificate - Identity Certificate - Identity Certificate with Kerberos constrained delegation 5. Select "View Certificate" and verify DoD and/or DoD-approved CA certificates are presented. If non-DoD-approved certificates are used, this is a finding.

Fix: F-54421r1004808_fix

If PKI-based user authentication intermediary services are provided, configure Sentry to only accept end entity certificates issued by DoD PKI or DoD-approved PKI CAs for the establishment of protected sessions. 1. In the MobileIron Core Portal, select Services >> Sentry. 2. Click the "Edit" icon for the Standalone Sentry entry. 3. In the "Device Authentication Configuration" section, select an option appropriate for your implementation. 4. Depending on the option selected, follow the instructions in one of the following sections to complete the configuration: - Group Certificate Refer to "Configuring authentication using a group certificate" for next steps. - Identity Certificate Refer to "Configuring authentication using an identity certificate and Pass Through" for next steps. OR Refer to "Configuring authentication using an identity certificate and Kerberos constrained delegation" for next steps. For more information, in the "Sentry 9.8.0 Guide for Core", refer to the main section "Device and Server Authentication", which contains the subsection "Configuring device and server authentication". 5. From the "Upload Certificate" option, load the DoD and/or DoD-approved CA certificates.

a
The Sentry must implement load balancing to limit the effects of known and unknown types of Denial-of-Service (DoS) attacks.
SC-5 - Low - CCI-002385 - V-251033 - SV-251033r1028199_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
MOIS-AL-000970
Vuln IDs
  • V-251033
Rule IDs
  • SV-251033r1028199_rule
If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Load balancing provides service redundancy; which service redundancy reduces the susceptibility of the ALG to many DoS attacks. The ALG must be configured to prevent or mitigate the impact on network availability and traffic flow of DoS attacks that have occurred or are ongoing. This requirement applies to the network traffic functionality of the device as it pertains to handling network traffic. Some types of attacks may be specialized to certain network technologies, functions, or services. For each technology, known and potential DoS attacks must be identified and solutions for each type implemented.
Checks: C-54468r802319_chk

Verify the Sentry is implemented behind a load balancer to limit the effects of known and unknown types of DoS attacks. If the device is not implemented behind a load balancer to limit the effects of known and unknown types of DoS attacks, this is a finding.

Fix: F-54422r802320_fix

Configure the Sentry to be implemented behind a load balancer to limit the effects of known and unknown types of DoS attacks.

b
The Sentry must only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations.
SC-7 - Medium - CCI-002403 - V-251034 - SV-251034r1028200_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
MOIS-AL-001000
Vuln IDs
  • V-251034
Rule IDs
  • SV-251034r1028200_rule
Unrestricted traffic may contain malicious traffic which poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources. Access control policies and access control lists implemented on devices that control the flow of network traffic (e.g., application level firewalls and Web content filters), ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the internet or CDS) must be kept separate.
Checks: C-54469r802322_chk

Verify only approved network routes are added to the Sentry. 1. Log in to Sentry System Manager. 2. Go to Settings >> Network >> Routes. 3. Verify only approved network routes are configured. If non-approved network routes are configured, this is a finding.

Fix: F-54423r802323_fix

Configure only approved network routes on the Sentry. 1. Log in to Sentry System Manager. 2. Go to Settings >> Routes. 3. Select any unauthorized network routes in the list and click "Delete". 4. Click "Add" to add approved routes.

a
The Sentry must reveal error messages only to the ISSO, ISSM, and SCA.
SI-11 - Low - CCI-001314 - V-251035 - SV-251035r1028201_rule
RMF Control
SI-11
Severity
Low
CCI
CCI-001314
Version
MOIS-AL-001200
Vuln IDs
  • V-251035
Rule IDs
  • SV-251035r1028201_rule
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can give configuration details about the network element. Limiting access to system logs and administrative consoles to authorized personnel will help to mitigate this risk. However, user feedback and error messages should also be restricted by type and content in accordance with security best practices (e.g., ICMP messages).
Checks: C-54470r1004810_chk

Verify the Sentry reveals error messages only to the ISSO, ISSM, and SCA. 1. Log in to Sentry. 2. Go to Monitoring >> Alert Configuration. 3. Verify "Send Notifications" is enabled. 4. Verify an email list containing the ISSO, ISSM, and SCA is input in the Email List. 5. Verify the "Alert Notification Management" section is set to meet organizational requirements. If Sentry is not configured to reveal error messages only to the ISSO, ISSM, and SCA, this is a finding.

Fix: F-54424r1004811_fix

Configure the Sentry to reveal error messages only to the ISSO, ISSM, and SCA. 1. Log in to Sentry. 2. Go to Monitoring >> Alert Configuration. 3. Enable "Send Notifications". 4. Configure an email list containing the ISSO, ISSM, and SCA in the Email List. 5. Configure the "Alert Notification Management" section to meet organizational requirements.

b
The Sentry providing encryption intermediary services must implement NIST FIPS-validated cryptography to generate cryptographic hashes.
SC-13 - Medium - CCI-002450 - V-251036 - SV-251036r1028203_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
MOIS-AL-001340
Vuln IDs
  • V-251036
Rule IDs
  • SV-251036r1028203_rule
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Checks: C-54471r1004813_chk

Verify the Sentry uses encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions. On the Sentry CLI console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "show FIPS". 6. Verify "FIPS 140 mode is enabled" is displayed. If the Sentry Server does not report that FIPS mode is "enabled", this is a finding.

Fix: F-54425r1028202_fix

Configure the Sentry Server to use a FIPS 140-2 validated cryptographic module. On the Sentry console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "configure terminal". 6. Enter the following command to enable FIPS: FIPS 7. Enter the following command to proceed with the necessary reload: do reload 8. Enter "Yes" at saved configuration modified prompt. 9. Enter "Yes" at proceed do reload.

b
The Sentry providing encryption intermediary services must implement NIST FIPS-validated cryptography for digital signatures.
SC-13 - Medium - CCI-002450 - V-251037 - SV-251037r1028205_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
MOIS-AL-001350
Vuln IDs
  • V-251037
Rule IDs
  • SV-251037r1028205_rule
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Checks: C-54472r1004816_chk

Verify the Sentry uses encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions. On the Sentry CLI console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "show FIPS". 6. Verify "FIPS 140 mode is enabled" is displayed. If the Sentry Server does not report that FIPS mode is "enabled", this is a finding.

Fix: F-54426r1028204_fix

Configure the Sentry Server to use a FIPS 140-2-validated cryptographic module. On the Sentry console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "configure terminal". 6. Enter the following command to enable FIPS: FIPS 7. Enter the following command to proceed with the necessary reload: do reload 8. Enter "Yes" at saved configuration modified prompt. 9. Enter "Yes" at proceed do reload.

b
The Sentry providing encryption intermediary services must use NIST FIPS-validated cryptography to implement encryption services.
SC-13 - Medium - CCI-002450 - V-251038 - SV-251038r1028207_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
MOIS-AL-001360
Vuln IDs
  • V-251038
Rule IDs
  • SV-251038r1028207_rule
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Checks: C-54473r1004819_chk

Verify the Sentry uses encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions. On the Sentry CLI console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "show FIPS". 6. Verify "FIPS 140 mode is enabled" is displayed. If the Sentry Server does not report that FIPS mode is "enabled", this is a finding.

Fix: F-54427r1028206_fix

Configure the Sentry Server to use a FIPS 140-2-validated cryptographic module. On the Sentry console, do the following: 1. SSH to Sentry Server from any SSH client. 2. Enter the administrator credentials set when Sentry was installed. 3. Enter "enable". 4. When prompted, enter the "enable secret" set when Sentry was installed. 5. Enter "configure terminal". 6. Enter the following command to enable FIPS: FIPS 7. Enter the following command to proceed with the necessary reload: do reload 8. Enter "Yes" at saved configuration modified prompt. 9. Enter "Yes" at proceed do reload.

a
The Sentry must offload audit records onto a centralized log server in real time.
AU-4 - Low - CCI-001851 - V-251039 - SV-251039r1028208_rule
RMF Control
AU-4
Severity
Low
CCI
CCI-001851
Version
MOIS-AL-001370
Vuln IDs
  • V-251039
Rule IDs
  • SV-251039r1028208_rule
Offloading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised. Offloading is a common process in information systems with limited audit storage capacity. The audit storage on the ALG is used only in a transitory fashion until the system can communicate with the centralized log server designated for storing the audit records, at which point the information is transferred. However, DoD requires that the log be transferred in real time which indicates that the time from event detection to offloading is seconds or less. This does not apply to audit logs generated on behalf of the device itself (management).
Checks: C-54474r1004822_chk

Verify the Sentry produces audit records onto a centralized log server in real time. 1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Verify a syslog server is configured. If it is not configured, this is a finding. 4. Click on the syslog server(s) and in the "Modify Syslog" pop-up dialog, under the "Facility Type", verify the checkbox for "Audit" is selected. If it is not selected, this is a finding. For more information, go to the "Sentry 9.8.0 Guide for Core" and refer to the main section "Standalone Sentry Settings", which includes a subsection detailing the log representation format in "Audit log representation and format". The audit logs contain additional information on the type of events that occurred. Also included is date and timestamp, the source of the event, the location of the event, and the result of the action whether a success/failure.

Fix: F-54428r1004823_fix

1. Log in to Sentry. 2. Go to Settings >> Syslog. 3. Configure a new Syslog Server if not already added. 4. Click on the syslog server(s) and in the "Modify Syslog"/"Add Syslog" pop-up dialog, under the "Facility Type", click the checkbox for "Audit". 5. Set the Admin State to "Enable". 6. Click "Apply".