Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

ISEC7 Sphere Security Technical Implementation Guide

V3R1 · · · Released 24 Oct 2024 · 34 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

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.
Digest of Updates vs. V2R1 · 23 Oct 2020 −1 ✎ 34

Comparison against the immediately-prior release (V2R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Removed rules 1

  • V-224787 Medium The version number of Apache Tomcat must be removed from the CATALINA_HOME/lib/catalina.jar file.

Content changes 34

  • V-224760 Medium descriptioncheckfix The ISEC7 SPHERE must limit the number of concurrent sessions to an organization-defined number for all accounts and/or account types.
  • V-224761 Medium checkfix The ISEC7 SPHERE must initiate a session lock after a 15-minute period of inactivity.
  • V-224762 Medium descriptioncheckfix The ISEC7 SPHERE must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during electronic dissemination using remote access.
  • V-224763 Medium descriptioncheckfix The ISEC7 SPHERE must display the Standard Mandatory DOD Notice and Consent Banner before granting access to the ISEC7 SPHERE.
  • V-224764 Medium checkfix The ISEC7 SPHERE server must be configured to have at least one user in the following Administrator roles: Security Administrator, Site Administrator, and Help Desk User.
  • V-224765 Medium checkfix The ISEC7 SPHERE must alert the information system security officer (ISSO) and system administrator (SA) (at a minimum) in the event of an audit processing failure.
  • V-224766 Medium checkfix The ISEC7 SPHERE must back up audit records at least every seven days onto a different system or system component than the system or component being audited, provide centralized management and configuration of the content to be captured in audit records generated by all ISEC7 SPHERE components, and offload audit records onto a different system or media than the system being audited.
  • V-224767 High descriptioncheckfix ISEC7 SPHERE must disable or delete local account created during application installation and configuration.
  • V-224768 Medium descriptioncheckfix When using PKI-based authentication for user access, the ISEC7 SPHERE must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
  • V-224769 Low descriptioncheckfix The ISEC7 SPHERE must accept Personal Identity Verification (PIV) credentials.
  • V-224770 Medium descriptioncheckfix Before establishing a local, remote, and/or network connection with any endpoint device, the ISEC7 SPHERE must use a bidirectional authentication mechanism configured with a FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to authenticate with the device.
  • V-224771 Medium descriptioncheckfix The ISEC7 SPHERE must allow the use of DOD PKI established certificate authorities for verification of the establishment of protected sessions.
  • V-224772 Medium descriptioncheckfix The ISEC7 SPHERE must protect the confidentiality and integrity of transmitted information during preparation for transmission and during reception using cryptographic mechanisms.
  • V-224773 Medium checkfix The ISEC7 SPHERE must be configured to leverage the enterprise directory service accounts and groups for ISEC7 SPHERE server admin identification and authentication.
  • V-224774 Medium checkfix The ISEC7 SPHERE must configure the timeout for the console to be 15 minutes or less.
  • V-224775 Medium checkfix The ISEC7 SPHERE, Tomcat installation, and ISEC7 Suite monitor must be configured to use the Windows Trust Store for the storage of digital certificates and keys.
  • V-224776 Medium descriptioncheckfix If cipher suites using pre-shared keys are used for device authentication, the ISEC7 SPHERE must have a minimum security strength of 112 bits or higher, must only be used in networks where both the client and server are government systems, must prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0 and must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithm for transmission.
  • V-224777 Medium checkfix The ISEC7 SPHERE must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (nonlegacy use).
  • V-224778 Medium descriptioncheckfix The ISEC7 SPHERE must use a FIPS-validated cryptographic module to provision digital signatures.
  • V-224779 Medium descriptioncheckfix The ISEC7 SPHERE must use a FIPS 140-2-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality, generate cryptographic hashes, and to configure web management tools with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.
  • V-224780 Medium descriptioncheckfix The Apache Tomcat Manager Web app password must be cryptographically hashed with a DOD-approved algorithm.
  • V-224781 Medium descriptioncheckfix All Web applications included with Apache Tomcat that are not required must be removed.
  • V-224782 Medium descriptioncheckfix LockOutRealm must not be removed from Apache Tomcat.
  • V-224783 Medium descriptioncheckfix The LockOutRealm must be configured with a login failure count of 3.
  • V-224784 Medium descriptioncheckfix The LockOutRealm must be configured with a login lockout time of 15 minutes.
  • V-224785 Medium checkfix The Manager Web app password must be configured as follows: -15 or more characters. -at least one lower case letter. -at least one upper case letter. -at least one number. -at least one special character.
  • V-224786 Medium descriptioncheckfix The ISEC7 SPHERE must configure Enable HTTPS to use HTTP over SSL in Apache Tomcat.
  • V-224788 Medium descriptioncheckfix Stack tracing must be disabled in Apache Tomcat.
  • V-224789 Medium descriptioncheckfix The Apache Tomcat shutdown port must be disabled.
  • V-224790 Medium descriptioncheckfix The ISEC7 SPHERE must remove any unnecessary users or groups that have permissions to the server.xml file in Apache Tomcat.
  • V-224791 Medium checkfix A manager role must be assigned to the Apache Tomcat Web apps (Manager, Host-Manager).
  • V-224792 Medium descriptioncheckfix SSL must be enabled on Apache Tomcat.
  • V-224793 Medium descriptioncheckfix Tomcat SSL must be restricted except for ISEC7 SPHERE tasks.
  • V-225096 High description The ISEC7 Sphere server must be maintained at a supported version.
Sort by
b
The ISEC7 SPHERE must limit the number of concurrent sessions to an organization-defined number for all accounts and/or account types.
AC-10 - Medium - CCI-000054 - V-224760 - SV-224760r1013798_rule
RMF Control
AC-10
Severity
M
CCI
CCI-000054
Version
ISEC-06-000010
Vuln IDs
  • V-224760
  • V-97303
Rule IDs
  • SV-224760r1013798_rule
  • SV-106407
Application management includes the ability to control the number of users and user sessions that utilize an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to denial-of-service (DoS) attacks. This requirement may be met via the application or by utilizing information system session control provided by a web server with specialized session management capabilities. If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.
Checks: C-26451r1004897_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify the maxConnections setting is set according to organizational guidelines. Verify the maxThreads setting is set according to organizational guidelines. If the maxConnections setting is not set according to organizational guidelines or the maxThreads setting is not set according to organizational guidelines, this is a finding.

Fix: F-26439r1004898_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the maxConnections setting according to organizational guidelines. Set the maxThreads setting according to organizational guidelines. Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must initiate a session lock after a 15-minute period of inactivity.
AC-11 - Medium - CCI-000057 - V-224761 - SV-224761r1013800_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000057
Version
ISEC-06-000030
Vuln IDs
  • V-224761
  • V-97385
Rule IDs
  • SV-224761r1013800_rule
  • SV-106489
A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system, but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their application session prior to vacating the vicinity, applications need to be able to identify when a user's application session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled. This is typically at the operating system-level and results in a system lock, but may be at the application-level where the application interface window is secured instead.
Checks: C-26452r1013799_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Validate the session timeout has been set to the correct value. Alternatively, allow the console to sit for 15 minutes and confirm the user is prompted to login again when attempting to navigate to a new screen. If the SPHERE Console timeout has not been set for 15 minutes or less, this is a finding.

Fix: F-26440r1004901_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the session timeout to the correct value of 15 minutes or less.

b
The ISEC7 SPHERE must use TLS 1.2, at a minimum, to protect the confidentiality of sensitive data during electronic dissemination using remote access.
AC-17 - Medium - CCI-000068 - V-224762 - SV-224762r1013803_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
ISEC-06-000060
Vuln IDs
  • V-224762
  • V-97387
Rule IDs
  • SV-224762r1013803_rule
  • SV-106491
Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to Transport Layer Security (TLS) gateways (also known as Secure Sockets Layer [SSL] gateways), web servers, and web applications and is not applicable to virtual private network (VPN) devices. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance for client negotiation on either DOD-only or on public-facing servers.
Checks: C-26453r1013801_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify "protocols" is set to +TLSv1.2, +TLSv1.3. If "protocols" is not set to +TLSv1.2 or higher, this is a finding.

Fix: F-26441r1013802_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Using the dropdown menu for protocols, select +TLSv1.2, +TLSv1.3. Click "Update". Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must display the Standard Mandatory DOD Notice and Consent Banner before granting access to the ISEC7 SPHERE.
AC-8 - Medium - CCI-000048 - V-224763 - SV-224763r1013805_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ISEC-06-000200
Vuln IDs
  • V-224763
  • V-97389
Rule IDs
  • SV-224763r1013805_rule
  • SV-106493
Display of the DOD-approved use notification before granting access to the application ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for applications that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."
Checks: C-26454r1013804_chk

Log in to the ISEC7 SPHERE Console. Note if the appropriate Standard mandatory DOD Notice and Consent Banner is displayed. Alternatively, if already logged in to the ISEC7 SPHERE Console, navigate to Administration >> User Self Service >> Page Customizations. Verify that a Page Customization exists to display the Standard mandatory DOD Notice and Consent Banner. If a Page Customization does not exist, or it does not contain the required DOD banner, this is a finding.

Fix: F-26442r1004907_fix

Set the session timeout to the correct value of 15 minutes or less.

b
The ISEC7 SPHERE server must be configured to have at least one user in the following Administrator roles: Security Administrator, Site Administrator, and Help Desk User.
AU-12 - Medium - CCI-000171 - V-224764 - SV-224764r1013808_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000171
Version
ISEC-06-000270
Vuln IDs
  • V-224764
  • V-97391
Rule IDs
  • SV-224764r1013808_rule
  • SV-106495
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
Checks: C-26455r1013806_chk

Log in to the ISEC7 SPHERE console. Navigate to Administration >> Configuration >> Access Permissions. Verify for each Role (Security Administrator, Site Administrator, and Help Desk User) that at least one user or AD group has been assigned. If for each Role (Security Administrator, Site Administrator, Help Desk User) there is not at least one user (or AD group) assigned, this is a finding.

Fix: F-26443r1013807_fix

Log in to the ISEC7 SPHERE console. Navigate to Administration >> Configuration >> Access Permissions. Assign at least one user or AD group to each of the following roles: Security Administrator, Site Administrator, and Help Desk User.

b
The ISEC7 SPHERE must alert the information system security officer (ISSO) and system administrator (SA) (at a minimum) in the event of an audit processing failure.
AU-5 - Medium - CCI-000139 - V-224765 - SV-224765r1013811_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000139
Version
ISEC-06-000380
Vuln IDs
  • V-224765
  • V-97393
Rule IDs
  • SV-224765r1013811_rule
  • SV-106497
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. 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.
Checks: C-26456r1013809_chk

Log in to the ISEC7 SPHERE console. Navigate to Administration >> Configuration >> Notifications >> Recipient Lists. Select "Edit" next to the Systems Notifications. Verify the email address or distribution list has been added. If a recipient email address or distribution list has not been added to System Notifications, this is a finding.

Fix: F-26444r1013810_fix

Log in to the ISEC7 SPHERE console. Navigate to Administration >> Configuration >> Notifications >> Recipient Lists. Select "Edit" next to the Systems Notifications. Under Add recipient, select "Email" as the Type and enter the correct email address of recipients. Select "Add".

b
The ISEC7 SPHERE must back up audit records at least every seven days onto a different system or system component than the system or component being audited, provide centralized management and configuration of the content to be captured in audit records generated by all ISEC7 SPHERE components, and offload audit records onto a different system or media than the system being audited.
AU-9 - Medium - CCI-001348 - V-224766 - SV-224766r1013812_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001348
Version
ISEC-06-000500
Vuln IDs
  • V-224766
  • V-97407
Rule IDs
  • SV-224766r1013812_rule
  • SV-106511
Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained. This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records. This requirement only applies to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions. Satisfies: SRG-APP-000125, SRG-APP-000356, SRG-APP-000358
Checks: C-26457r1004915_chk

Open the central log repository and verify the ISEC7 logs have been written to the location of the log server. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify that the log directory path is set to the desired location. Alternatively: On the ISEC7 SPHERE server, browse to the install directory. Default is %Install Drive%/Program Files/ISEC7 SPHERE. Select the conf folder. Open config.properties and verify the logPath is set to the desired location. If ISEC7 SPHERE logs are not written to an audit log management server, this is a finding.

Fix: F-26445r1004916_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the log directory path to the desired location. Alternatively: On the ISEC7 SPHERE server, browse to the install directory. Default is %Install Drive%/Program Files/ISEC7 SPHERE. Select the conf folder. Open config.properties and set the logPath to the desired location of the log server.

c
ISEC7 SPHERE must disable or delete local account created during application installation and configuration.
IA-2 - High - CCI-000764 - V-224767 - SV-224767r1013815_rule
RMF Control
IA-2
Severity
H
CCI
CCI-000764
Version
ISEC-06-000660
Vuln IDs
  • V-224767
  • V-97249
Rule IDs
  • SV-224767r1013815_rule
  • SV-106373
The ISEC7 local account password complexity controls do not meet DOD requirements; therefore, admins have the capability to configure the account out of compliance, which could allow attacker to gain unauthorized access to the server and access to command MDM servers.
Checks: C-26458r1013813_chk

Log in to the ISEC7 SPHERE console. Navigate to Administration >> Configuration >> Account Management >> Users. Select "Edit" next to the local account Admin. Verify "Log in disabled" has been selected. If "Log in disabled" has not been selected, this is a finding.

Fix: F-26446r1013814_fix

Log in to the ISEC7 SPHERE console. Navigate to Administration >> Configuration >> Account Management >> Users. Select "Edit" next to the local account Admin. Check "Log in disabled" for the account. Click "Save".

b
When using PKI-based authentication for user access, the ISEC7 SPHERE must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
IA-5 - Medium - CCI-000185 - V-224768 - SV-224768r1013818_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000185
Version
ISEC-06-000780
Vuln IDs
  • V-224768
  • V-97395
Rule IDs
  • SV-224768r1013818_rule
  • SV-106499
Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. To meet this requirement, the information system must create trusted channels between itself and remote trusted authorized IT product (e.g., syslog server) entities that protect the confidentiality and integrity of communications. The information system must create trusted paths between itself and remote administrators and users that protect the confidentiality and integrity of communications. A trust anchor is an authoritative entity represented via a public key and associated data. It is most often used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. However, applications that do not use a trusted path are not approved for nonlocal and remote management of DOD information systems. Use of SSHv2 to establish a trusted channel is approved. Use of FTP, TELNET, HTTP, and SNMPV1 is not approved since they violate the trusted channel rule set. Use of web management tools that are not validated by common criteria my also violate trusted channel rule set. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.
Checks: C-26459r1013816_chk

Log in to the server(s) hosting the ISEC7 SPHERE application. Open the Microsoft Management Console and add the Local Computer Certificates snap-in. Open the Trusted Root Certification Authorities >> Certificates. Verify the DOD Root PKI Certificates Authorities have been added to the server. If the DOD Root PKI Certificates Authorities have not been added to the server, this is a finding.

Fix: F-26447r1013817_fix

Log in to the server(s) hosting the ISEC7 SPHERE application. Open the Microsoft Management Console and add the Local Computer Certificates snap-in. Open the Trusted Root Certification Authorities >> Certificates. Install the DOD Root PKI Certificates Authorities to the server.

a
The ISEC7 SPHERE must accept Personal Identity Verification (PIV) credentials.
IA-2 - Low - CCI-001953 - V-224769 - SV-224769r1013821_rule
RMF Control
IA-2
Severity
L
CCI
CCI-001953
Version
ISEC-06-001730
Vuln IDs
  • V-224769
  • V-97397
Rule IDs
  • SV-224769r1013821_rule
  • SV-106501
The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DOD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.
Checks: C-26460r1013819_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Settings. Verify the CAC login box has been checked. On the ISEC7 SPHERE server, browse to the install directory. Default is %Install Drive%/Program Files/ISEC7 SPHERE Select the conf folder. Open config.properties and confirm the following lines exist: cacUserUIDRegex=^CN=[^0-9]*\\.([0-9]+), cacUserUIDProperty=UserPrincipalName Browse to %Install Drive%/Program Files >> ISEC7 SPHERE >> Tomcat >> conf Confirm the server.xml file has clientAuth="required" under the Connection. If the required commands do not exist in config.properties or if clientAuth does not ="required" in the server.xml file, this is a finding.

Fix: F-26448r1013820_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> LDAP. Check "Also enable user certificate logins. e.g. from smart cards (CAC)". Check "Only allow certificates with extended key usage for smartcard logon (1.3.6.1.4.1.311.20.2.2)". Browse to %Install Drive%/Program Files >> ISEC7 SPHERE >> Tomcat >> conf. Open the server.xml file and add clientAuth="required" under the Connection.

b
Before establishing a local, remote, and/or network connection with any endpoint device, the ISEC7 SPHERE must use a bidirectional authentication mechanism configured with a FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to authenticate with the device.
IA-3 - Medium - CCI-001967 - V-224770 - SV-224770r1013824_rule
RMF Control
IA-3
Severity
M
CCI
CCI-001967
Version
ISEC-06-001760
Vuln IDs
  • V-224770
  • V-97399
Rule IDs
  • SV-224770r1013824_rule
  • SV-106503
Without device-to-device authentication, communications with malicious devices may be established. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. Currently, DOD requires the use of AES for bidirectional authentication since it is the only FIPS-validated AES cipher block algorithm. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of authentication claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide authentication decisions (as opposed to the actual authenticators) to the services that need to act on those decisions. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network; the internet). A remote connection is any connection with a device communicating through an external network (e.g., the internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to apply the requirement only to those limited number (and type) of devices that truly need to support this capability.
Checks: C-26461r1013822_chk

Log in to the ISEC7 SPHERE Console. Confirm that the browser session is secured using a DOD issued certificate. Internet Explorer: Click the Padlock icon at the end of the url field. Select "View Certificates". Confirm that the Issued By is a valid DOD Certificate Authority. Google Chrome: Click the Padlock icon at the front of the url field. Select "Certificate". Confirm that the Issued By is a valid DOD Certificate Authority. Alternately, log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Identify which type of Keystore is being used. Windows MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Verify the certificate is issued by a DOD Trusted Certificate Authority. JavaKeystore PKCS12: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Open the installed certificate and verify it was issued by a DOD Trusted Certificate Authority. If certificates used by the server are not DOD-issued certificates, this is a finding.

Fix: F-26449r1013823_fix

Submit a CSR for a DOD-issued certificate with the private key. Retrieve the approved certificate from the issuing Certificate Authority. Set the friendly name on the certificate to https. Windows-MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Import the certificate with Private key. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the Keystore Type to Windows-MY. Restart the ISEC7 SPHERE Web service. JavaKeystore: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE Suite keystore. Enter the Keystore password when prompted. Delete the self-signed certificate in the keystore. Import the DOD-issued certificate with the private key. Enter the key password when prompted. Enter the certificate alias as "https" when prompted. Save the keystore with the same keystore password. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify the Keystore type is set to JavaKeystore PKCS12. Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must allow the use of DOD PKI established certificate authorities for verification of the establishment of protected sessions.
SC-23 - Medium - CCI-002470 - V-224771 - SV-224771r1013827_rule
RMF Control
SC-23
Severity
M
CCI
CCI-002470
Version
ISEC-06-001960
Vuln IDs
  • V-224771
  • V-97401
Rule IDs
  • SV-224771r1013827_rule
  • SV-106505
Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DOD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DOD-approved CA, trust of this CA has not been established. The DOD will only accept PKI certificates obtained from a DOD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of TLS certificates. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to applications that utilize communications sessions. This includes, but is not limited to, web-based applications and Service-Oriented Architectures (SOA).
Checks: C-26462r1013825_chk

Log in to the ISEC7 SPHERE Server. Navigate to %Install Drive%/Program Files/ISEC7 SPHERE/tomcat/bin. Run tomcat9w.bat and select the JAVA tab in the window that opens. Under "Java options" verify "-Djavax.net.ssl.trustStoreType=Windows-ROOT" is listed. If "-Djavax.net.ssl.trustStoreType=Windows-ROOT" is not listed, this is a finding.

Fix: F-26450r1013826_fix

Log in to the ISEC7 SPHERE Server. Navigate to %Install Drive%/Program Files/ISEC7 SPHERE/tomcat/bin. Run tomcat9w.bat and select the JAVA tab in the window that opens. Under "Java options" add "-Djavax.net.ssl.trustStoreType=Windows-ROOT" and select "OK". Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must protect the confidentiality and integrity of transmitted information during preparation for transmission and during reception using cryptographic mechanisms.
SC-8 - Medium - CCI-002418 - V-224772 - SV-224772r1013830_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ISEC-06-002030
Vuln IDs
  • V-224772
  • V-97409
Rule IDs
  • SV-224772r1013830_rule
  • SV-106513
Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPSEC. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Satisfies: SRG-APP-000439, SRG-APP-000440, SRG-APP-000441, SRG-APP-000442
Checks: C-26463r1013828_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify protocols is set to +TLSv1.2, +TLSv1.3. If protocols is not set to +TLSv1.2 or higher, this is a finding.

Fix: F-26451r1013829_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Using the drop-down menu for protocols, select +TLSv1.2, +TLSv1.3. Click "Update". Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must be configured to leverage the enterprise directory service accounts and groups for ISEC7 SPHERE server admin identification and authentication.
CM-6 - Medium - CCI-000366 - V-224773 - SV-224773r1013833_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ISEC-06-002510
Vuln IDs
  • V-224773
  • V-97261
Rule IDs
  • SV-224773r1013833_rule
  • SV-106375
A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. If an attacker compromises an account, the entire infrastructure is at risk. Providing automated support functions for the management of accounts will ensure only active accounts will be granted access with the proper authorization levels. These objectives are best achieved by configuring the server to leverage an enterprise authentication mechanism (e.g., Microsoft Active Directory Kerberos).
Checks: C-26464r1013831_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> LDAP. Verify that a LDAP entry has been configured to the enterprise. Select "Edit" and confirm the "Use for Login" check box has been selected. Navigate to Administration >> Configuration >> Settings. Verify that Log in using (Default) has been set to the enterprise connection. If a LDAP entry has not been configured to the enterprise or Log in using (Default) has not been set to the enterprise connection, this is a finding.

Fix: F-26452r1013832_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> LDAP. Select "Add new LDAP". Provide the connection information for the enterprise LDAP connection. Check the box "Use for Login". Navigate to Administration >> Configuration >> Settings. Set Log in using (Default) to the enterprise connection.

b
The ISEC7 SPHERE must configure the timeout for the console to be 15 minutes or less.
CM-6 - Medium - CCI-000366 - V-224774 - SV-224774r1013835_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ISEC-06-002520
Vuln IDs
  • V-224774
  • V-97263
Rule IDs
  • SV-224774r1013835_rule
  • SV-106377
A session time-out lock is a temporary action taken when a user (MDM system administrator) stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their application session prior to vacating the vicinity, applications need to be able to identify when a user's application session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled. This is typically at the operating system level and results in a system lock but may be at the application level where the application interface window is secured instead.
Checks: C-26465r1013834_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Validate the session timeout has been set to the correct value. Alternatively, allow the console to sit for 15 minutes and confirm that the user is prompted to log in once again when attempting to navigate to a new screen. If the SPHERE Console timeout has not been set for 15 minutes or less, this is a finding.

Fix: F-26453r1004940_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the session timeout to the correct value of 15 minutes or less.

b
The ISEC7 SPHERE, Tomcat installation, and ISEC7 Suite monitor must be configured to use the Windows Trust Store for the storage of digital certificates and keys.
CM-6 - Medium - CCI-000366 - V-224775 - SV-224775r1013838_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ISEC-06-002530
Vuln IDs
  • V-224775
  • V-97265
Rule IDs
  • SV-224775r1013838_rule
  • SV-106379
A trust store provides requisite encryption and access control to protect digital certificates from unauthorized access.
Checks: C-26466r1013836_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify that the type of Keystore being used is: Windows-MY If the type of Keystore being used is not Windows-MY, this is a finding.

Fix: F-26454r1013837_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Select the type of Keystore to be used as: Windows-MY Restart the ISEC7 SPHERE Web service.

b
If cipher suites using pre-shared keys are used for device authentication, the ISEC7 SPHERE must have a minimum security strength of 112 bits or higher, must only be used in networks where both the client and server are government systems, must prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0 and must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithm for transmission.
CM-7 - Medium - CCI-000382 - V-224776 - SV-224776r1013841_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
ISEC-06-002620
Vuln IDs
  • V-224776
  • V-97411
Rule IDs
  • SV-224776r1013841_rule
  • SV-106515
Pre-shared keys are symmetric keys that are already in place prior to the initiation of a Transport Layer Security (TLS) session (e.g., as the result of a manual distribution). In general, pre-shared keys should not be used. However, the use of pre-shared keys may be appropriate for some closed environments that have stung key management best practices. Pre-shared keys may be appropriate for constrained environments with limited processing, memory, or power. If pre-shared keys are appropriate and supported, the following additional guidelines must be followed. Consult 800-52 for recommended pre-shared key cipher suites for pre-shared keys. Pre-shared keys must be distributed in a secure manner, such as a secure manual distribution or using a key establishment certificate. These cipher suites employ a pre-shared key for device authentication (for both the server and the client) and may also use RSA or ephemeral Diffie-Hellman (DHE) algorithms for key establishment. Because these cipher suites require pre-shared keys, these suites are not generally applicable to classic secure website applications and are not expected to be widely supported in TLS clients or TLS servers. NIST suggests that these suites be considered in particular for infrastructure applications, particularly if frequent authentication of the network entities is required. These cipher suites may be used with TLS versions 1.1 or 1.2. Note that cipher suites using GCM, SHA-256, or SHA-384 are only available in TLS 1.2. Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to Transport Layer Security (TLS) gateways (also known as Secure Sockets Layer [SSL] gateways), web servers, and web applications. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance for client negotiation, either on DOD-only or on public-facing servers. If unsecured protocols (lacking cryptographic mechanisms) are used for sessions, the contents of those sessions will be susceptible to manipulation, potentially allowing alteration and hijacking of maintenance sessions. Satisfies: SRG-APP-000585, SRG-APP-000590, SRG-APP-000560, SRG-APP-000645
Checks: C-26467r1013839_chk

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify protocols is set to +TLSv1.2, +TLSv1.3. If protocols is not set to +TLSv1.2 or higher, this is a finding.

Fix: F-26455r1013840_fix

Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Using the dropdown menu for protocols, select +TLSv1.2, +TLSv1.3. Click "Update". Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (nonlegacy use).
IA-7 - Medium - CCI-000803 - V-224777 - SV-224777r1013844_rule
RMF Control
IA-7
Severity
M
CCI
CCI-000803
Version
ISEC-06-002660
Vuln IDs
  • V-224777
  • V-97403
Rule IDs
  • SV-224777r1013844_rule
  • SV-106507
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. To protect the integrity of the authenticator and authentication mechanism used for the cryptographic module used by the network device, the application, operating system, or protocol must be configured to use one of the following hash functions for hashing the password or other authenticator in accordance with SP 800-131Ar1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. For digital signature verification, SP800-131Ar1 allows SHA-1 for legacy use where needed.
Checks: C-26468r1013842_chk

Log in to the ISEC7 SPHERE Console. Confirm that the browser session is secured using a DOD issued certificate. Alternately, log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Identify which type of Keystore is being used. Windows MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Verify the certificate is issued by a DOD Trusted Certificate Authority. JavaKeystore PKCS12: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Open the installed certificate and verify it was issued by a DOD Trusted Certificate Authority. If certificates used by the server are not DOD issued certificates, this is a finding.

Fix: F-26456r1013843_fix

Submit a CSR for a DOD Issued Certificate with the private key. Retrieve the approved certificate from the issuing Certificate Authority. Set the friendly name on the certificate to https. Windows-MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Import the certificate with Private key. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the Keystore Type to Windows-MY. Restart the ISEC7 SPHERE Web service. JavaKeystore: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Delete the self-signed certificate in the keystore. Import the DOD issued certificate with the private key. Enter the key password when prompted. Enter the certificate alias as https when prompted. Save the keystore with the same keystore password. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify the Keystore type is set to JavaKeystore PKCS12. Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must use a FIPS-validated cryptographic module to provision digital signatures.
SC-13 - Medium - CCI-002450 - V-224778 - SV-224778r1013847_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
ISEC-06-002690
Vuln IDs
  • V-224778
  • V-97413
Rule IDs
  • SV-224778r1013847_rule
  • SV-106517
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. FIPS 140-2 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard. The cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the product being evaluated. SPHERE is using the standard JCE module coming with OpenJDK 17 (included in installer) or Oracle JRE either legacy 1.8 or latest release (see https://openjdk.java.net/groups/security/). There are two module providers, IBM and RSA. The check/fix are written assuming the RSA module is used. Any FIPS 140-2 compliant JCE module (.jar) can be replaced and configured and used with SPHERE. Satisfies: SRG-APP-000630, SRG-APP-000412, SRG-APP-000514
Checks: C-26469r1013845_chk

Log in to the ISEC7 SPHERE Console. Confirm that the browser session is secured using a DOD issued certificate. Alternately, log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Identify which type of Keystore is being used. Windows MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Verify the certificate is issued by a DOD Trusted Certificate Authority. JavaKeystore PKCS12: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Open the installed certificate and verify it was issued by a DOD Trusted Certificate Authority. If certificates used by the server are not DOD issued certificates, this is a finding.

Fix: F-26457r1013846_fix

Submit a CSR for a DOD Issued Certificate with the private key. Retrieve the approved certificate from the issuing Certificate Authority. Set the friendly name on the certificate to https. Windows-MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Import the certificate with Private key. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the Keystore Type to Windows-MY. Restart the ISEC7 SPHERE Web service. JavaKeystore: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Delete the self-signed certificate in the keystore. Import the DOD-issued certificate with the private key. Enter the key password when prompted. Enter the certificate alias as https when prompted. Save the keystore with the same keystore password. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify the Keystore type is set to JavaKeystore PKCS12. Restart the ISEC7 SPHERE Web service.

b
The ISEC7 SPHERE must use a FIPS 140-2-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality, generate cryptographic hashes, and to configure web management tools with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.
SC-13 - Medium - CCI-002450 - V-224779 - SV-224779r1013850_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
ISEC-06-002700
Vuln IDs
  • V-224779
  • V-97405
Rule IDs
  • SV-224779r1013850_rule
  • SV-106509
FIPS 140-2 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard. The cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the product being evaluated. SPHERE is using the standard JCE module coming with OpenJDK 17 (included in installer) or Oracle JRE either legacy 1.8 or latest release. see https://openjdk.java.net/groups/security/ There are two module providers, IBM and RSA. The check/fix are written assuming the RSA module is used. Any FIPS 140-2 compliant JCE module (.jar) can be replaced and configured and used with SPHERE.
Checks: C-26470r1013848_chk

Log in to the ISEC7 SPHERE Console. Confirm that the browser session is secured using a DOD issued certificate. Alternately, log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Identify which type of Keystore is being used. Windows MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Verify the certificate is issued by a DOD Trusted Certificate Authority. JavaKeystore PKCS12: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Open the installed certificate and verify it was issued by a DOD Trusted Certificate Authority. If certificates used by the server are not DOD issued certificates, this is a finding.

Fix: F-26458r1013849_fix

Submit a CSR for a DOD Issued Certificate with the private key. Retrieve the approved certificate from the issuing Certificate Authority. Set the friendly name on the certificate to https. Windows-MY: Open the Microsoft Management Console. Add the Certificates Snap-In for the ISEC7 Service Account. Navigate to the Personal Certificates Store. Import the certificate with Private key. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Set the Keystore Type to Windows-MY. Restart the ISEC7 SPHERE Web service. JavaKeystore: Using a Keystore browser such as Portecle, open the ISEC7 SPHERE keystore. Enter the Keystore password when prompted. Delete the self-signed certificate in the keystore. Import the DOD issued certificate with the private key. Enter the key password when prompted. Enter the certificate alias as https when prompted. Save the keystore with the same keystore password. Log in to the ISEC7 SPHERE Console. Navigate to Administration >> Configuration >> Apache Tomcat Settings. Verify the Keystore type is set to JavaKeystore PKCS12. Restart the ISEC7 SPHERE Web service.

b
The Apache Tomcat Manager Web app password must be cryptographically hashed with a DOD-approved algorithm.
Medium - CCI-004062 - V-224780 - SV-224780r1013853_rule
RMF Control
Severity
M
CCI
CCI-004062
Version
ISEC-06-550150
Vuln IDs
  • V-224780
  • V-97275
Rule IDs
  • SV-224780r1013853_rule
  • SV-106381
The Apache Tomcat Manager Web app password is stored in plain text in CATALINA_HOME/conf/tomcat-users.xml and should be encrypted so it is not visible to an intruder. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include: - When the user does not use a CAC and is not a current DOD employee, member of the military, or DOD contractor. - When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. If the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security. Verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) In the above, "n" is a cryptographically-strong random [*3] number. "Hn" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares "Hn" with the stored "Hn". A salt is essentially a fixed-length cryptographically strong random value. Another method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. This requirement applies to all accounts including authentication server, AAA, and local account, including the root account and the account of last resort.
Checks: C-26471r1013851_chk

Verify the Apache Tomcat Manager Web app password is hashed using SHA-256 (or SHA-512). Log in to the ISEC7 SPHERE server. Navigate to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\ Open tomcat-users.xml and verify the user password has been hashed with an obfuscated password. ex: <user password="310c55aa3d5b42217e7f0e80ce30467d$100000$529cceb1fbc80f4f461fc1bd56219d79d9c94d4a8fc46abad0646f27e753ff9e" roles="manager-gui,manager-script" username="admin"/> Open <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\server.xml with Notepad.exe. Select Edit >> Find and search for CredentialHandler. Confirm the text: <CredentialHandler algorithm="PBKDF2WithHmacSHA512" keyLength="256" /> Close the file. If the Apache Tomcat Manager Web app password is not hashed using SHA-256 (or SHA-512), this is a finding.

Fix: F-26459r1013852_fix

To encrypt the Tomcat Manager Web app password, run the ISEC7 integrated installer or use the following manual procedure. Note: The ISEC7 integrated installer will configure SHA-512 as the hash algorithm, which is not available with the manual procedure. The manual procedure will configure SHA-256. Both are DOD approved. Log in to the ISEC7 SPHERE server. Browse to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf and open Tomcat-Users.xml Open the Command Prompt and CD to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\bin Execute the following command: digest -a SHA-256 -h org.apache.catalina.realm.MessageDigestCredentialHandler * * Where password is the 15 character password designated for the account. Copy the output, which is the SHA-256 hashed digest password. In Tomcat-Users.xml, add in the password for the user with the obfuscated output. ex: <user password="310c55aa3d5b42217e7f0e80ce30467d$100000$529cceb1fbc80f4f461fc1bd56219d79d9c94d4a8fc46abad0646f27e753ff9e" roles="manager-gui,manager-script" username="admin"/> Save the file. Open <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\server.xml with Notepad.exe. Select Edit >> Find and search for CredentialHandler. Replace the text with: <CredentialHandler className="org.apache.catalina.realm.MessageDigestCredentialHandler" algorithm="SHA-256" /> Save the file. Restart the ISEC7 SPHERE Web service.

b
All Web applications included with Apache Tomcat that are not required must be removed.
CM-7 - Medium - CCI-001762 - V-224781 - SV-224781r1013855_rule
RMF Control
CM-7
Severity
M
CCI
CCI-001762
Version
ISEC-06-550200
Vuln IDs
  • V-224781
  • V-97277
Rule IDs
  • SV-224781r1013855_rule
  • SV-106383
Removal of unneeded or nonsecure functions, ports, protocols, and services mitigate the risk of unauthorized connection of devices, unauthorized transfer of information, or other exploitation of these resources. The organization must perform a periodic scan/review of the application (as required by CCI-000384) and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure.
Checks: C-26472r1004960_chk

Verify CATALINA_HOME/webapps Tomcat administrative tool has been configured to remove all Web applications that are not required. Log in to the ISEC7 SPHERE server. Browse to &lt;Drive&gt;:\Program Files\ISEC7 SPHERE\Tomcat\webapps\ Confirm all folders in the directory with the exception of Manager and Host-Manager have been removed. If the CATALINA_HOME/webapps Tomcat administrative tool has not been configured to remove all Web applications that are not required, this is a finding.

Fix: F-26460r1013854_fix

To configure the CATALINA_HOME/webapps Tomcat administrative tool to remove all Web applications that are not required, run the ISEC7 integrated installer or use the following manual procedure: Log in to the ISEC7 SPHERE server. Browse to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\webapps\ Remove all folders in the directory with the exception of Manager and Host-Manager.

b
LockOutRealm must not be removed from Apache Tomcat.
CM-7 - Medium - CCI-001762 - V-224782 - SV-224782r1013858_rule
RMF Control
CM-7
Severity
M
CCI
CCI-001762
Version
ISEC-06-550300
Vuln IDs
  • V-224782
  • V-97279
Rule IDs
  • SV-224782r1013858_rule
  • SV-106385
LockOutRealm prevents brute force attacks against user passwords. Removal of unneeded or nonsecure functions, ports, protocols, and services mitigate the risk of unauthorized connection of devices, unauthorized transfer of information, or other exploitation of these resources. The organization must perform a periodic scan/review of the application (as required by CCI-000384) and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure.
Checks: C-26473r1013856_chk

Log in to the ISEC7 SPHERE server. Navigate to &lt;Drive&gt;:\Program Files\Isec7 SPHERE\Tomcat\Config Open the server.xml file with Notepad. Select Edit &gt;&gt; Find and search for LockOutRealm. Confirm the following line is in the server.xml file: &lt;Realm className="org.apache.catalina.realm.LockOutRealm"&gt; If it is not found or has been commented out, this is a finding. If the LockOutRealm has been removed and cannot be used, this is a finding.

Fix: F-26461r1013857_fix

Log in to the ISEC7 SPHERE server. Navigate to <Drive>:\Program Files\Isec7 SPHERE\Tomcat\Config Open the server.xml file with Notepad. Select Edit >> Find and search for LockOutRealm. Add the following line is in the server.xml file: <Realm className="org.apache.catalina.realm.LockOutRealm"> Restart the ISEC7 SPHERE Web service in the services.msc.

b
The LockOutRealm must be configured with a login failure count of 3.
AC-7 - Medium - CCI-000044 - V-224783 - SV-224783r1013861_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000044
Version
ISEC-06-550305
Vuln IDs
  • V-224783
  • V-97281
Rule IDs
  • SV-224783r1013861_rule
  • SV-106387
LockOutRealm prevents brute force attacks against user passwords. Removal of unneeded or nonsecure functions, ports, protocols, and services mitigate the risk of unauthorized connection of devices, unauthorized transfer of information, or other exploitation of these resources. Access to LockOutRealm must be configured to control login attempts by local accounts. The organization must perform a periodic scan/review of the application (as required by CCI-000384) and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure.
Checks: C-26474r1013859_chk

Verify the failureCount parameter is set to 3 in the LockOutRealm configuration. Log in to the ISEC7 SPHERE server. Navigate to &lt;Drive&gt;:\Program Files\Isec7 SPHERE\Tomcat\Config. Open the server.xml file with Notepad. Select Edit &gt;&gt; Find and search for LockOutRealm. Verify the failureCount parameter is set to 3 in the following file: &lt;Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="3" lockOutTime="900" &gt; If the failureCount parameter is not set to 3 in the LockOutRealm configuration, this is a finding.

Fix: F-26462r1013860_fix

Add failureCount parameter to the LockOutRealm configuration: Log in to the ISEC7 SPHERE server. Navigate to <Drive>:\Program Files\Isec7 SPHERE\Tomcat\Config. Open the server.xml file with Notepad. Select Edit >> Find and search for LockOutRealm. Add the following line is in the server.xml file: <Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="3" lockOutTime="900" > Restart the ISEC7 SPHERE Web service in the services.msc.

b
The LockOutRealm must be configured with a login lockout time of 15 minutes.
CM-6 - Medium - CCI-000366 - V-224784 - SV-224784r1013864_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ISEC-06-550310
Vuln IDs
  • V-224784
  • V-97283
Rule IDs
  • SV-224784r1013864_rule
  • SV-106389
LockOutRealm prevents brute force attacks against user passwords. Removal of unneeded or nonsecure functions, ports, protocols, and services mitigate the risk of unauthorized connection of devices, unauthorized transfer of information, or other exploitation of these resources. Access to LockOutRealm must be configured to control login attempts by local accounts. The organization must perform a periodic scan/review of the application (as required by CCI-000384) and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure.
Checks: C-26475r1013862_chk

Verify the lockOutTime parameter is set to 900 in the LockOutRealm configuration. Log in to the ISEC7 SPHERE server. Navigate to &lt;Drive&gt;:\Program Files\Isec7 SPHERE\Tomcat\Config. Open the server.xml file with Notepad. Select Edit &gt;&gt; Find and search for LockOutRealm. Verify the lockOutTime parameter is set to 900 in the following file: &lt;Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="3" lockOutTime="900" &gt; If the lockOutTime parameter is not set to 900 in the LockOutRealm configuration, this is a finding.

Fix: F-26463r1013863_fix

Add lockOutTime parameter to the LockOutRealm configuration: Log in to the ISEC7 SPHERE server. Navigate to <Drive>:\Program Files\Isec7 SPHERE\Tomcat\Config. Open the server.xml file with Notepad. Select Edit>Find and search for LockOutRealm. Add the following line in the server.xml file: <Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="3" lockOutTime="900" > Restart the ISEC7 SPHERE Web service in the services.msc.

b
The Manager Web app password must be configured as follows: -15 or more characters. -at least one lower case letter. -at least one upper case letter. -at least one number. -at least one special character.
Medium - CCI-004066 - V-224785 - SV-224785r1013867_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
ISEC-06-550700
Vuln IDs
  • V-224785
  • V-97415
Rule IDs
  • SV-224785r1013867_rule
  • SV-106519
The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. Satisfies: SRG-APP-000164, SRG-APP-000166, SRG-APP-000169
Checks: C-26476r1013865_chk

Verify the Manager Web app password has been configured as follows: -15 or more characters. -at least one lower case letter. -at least one upper case letter. -at least one number. -at least one special character. Log in to the ISEC7 SPHERE server. Open a Web browser and go to https://localhost/manager/html. Log in with the custom administrator login and password. Verify password entered meets complexity requirements. If the Manager Web app password has not been configured as required, this is a finding.

Fix: F-26464r1013866_fix

To set a strong password on the Manager Web app, run the ISEC7 integrated installer or use the following manual procedure: Log in to the ISEC7 SPHERE server. Browse to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf and open Tomcat-Users.xml. Open the Command Prompt and CD to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\bin. Execute the following using sha command: digest –a sha password* *Where password is the 15 character password designated for the account. Copy the output, which is the hashed digest password. In Tomcat-Users.xml, add in the password for the user with the obfuscated output at <user password="**", where ** is the obfuscated password. example: <user password="310c55aa3d5b42217e7f0e80ce30467d$100000$529cceb1fbc80f4f461fc1bd56219d79d9c94d4a8fc46abad0646f27e753ff9e" roles="manager-gui,manager-script" username="admin"/> Save the file. Open <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\server.xml with Notepad.exe. Enter: <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" digest=”sha”/> Save the file. Restart the ISEC7 SPHERE Web service using the services.msc. Note: the password must meet the following complexity requirements: -15 or more characters. -at least one lower case letter. -at least one upper case letter. -at least one number. -at least one special character.

b
The ISEC7 SPHERE must configure Enable HTTPS to use HTTP over SSL in Apache Tomcat.
SC-8 - Medium - CCI-002418 - V-224786 - SV-224786r1013870_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ISEC-06-550800
Vuln IDs
  • V-224786
  • V-97287
Rule IDs
  • SV-224786r1013870_rule
  • SV-106391
Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPSEC. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.
Checks: C-26477r1013868_chk

Verify Enable HTTPS has been configured to use HTTP over SSL: Open a web browser that is able to reach the ISEC7 SPHERE console. Verify that the address used has a prefix of "https://". Alternately: Log in to the ISEC7 SPHERE server. Open the server.xml file located at &lt;Drive&gt;:\Program Files\ISEC7 SPHERE\Tomcat\conf with Notepad.exe. Select Edit &gt;&gt; Find and search for port="443". Confirm the connector is present and not commented out: If Enable HTTPS has not been configured to use HTTP over SSL, this is a finding.

Fix: F-26465r1013869_fix

To enable HTTPS to use HTTP over SSL, run the ISEC7 integrated installer or use the following manual procedure: Log in to the ISEC7 SPHERE server. Open the server.xml file located at <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf with Notepad.exe. Select Edit >> Find and search for port="443". If the connector is not present add: ex: <Connector SSLEnabled="true" maxParameterCount="1000" maxThreads="200" port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"> <SSLHostConfig certificateVerification="false" ciphers="HIGH:!aNULL:!MD5:!3DES:!ARIA:!SHA:!CAMELLIA:!AES128-CCM8:!AES128-CCM:!AES256-CCM8:!AES256-CCM:!DHE" honorCipherOrder="true" protocols="+TLSv1.2,+TLSv1.3"> <Certificate certificateKeyAlias="https" certificateKeystoreFile="" certificateKeystoreType="Windows-MY"/> </SSLHostConfig> </Connector> Modifying the certificateKeystoreFile path and certificateKeystorePassword as needed or leveraging the Windows-MY certificateKeystoreType instead. If the connector has been commented out, remove the comment characters. Save the file. Restart the ISEC7 SPHERE Web service.

b
Stack tracing must be disabled in Apache Tomcat.
CM-7 - Medium - CCI-001762 - V-224788 - SV-224788r1013873_rule
RMF Control
CM-7
Severity
M
CCI
CCI-001762
Version
ISEC-06-551200
Vuln IDs
  • V-224788
  • V-97291
Rule IDs
  • SV-224788r1013873_rule
  • SV-106395
The default error page shows a full stack trace, which is a disclosure of sensitive information. Removal of unneeded or nonsecure functions, ports, protocols, and services mitigate the risk of unauthorized connection of devices, unauthorized transfer of information, or other exploitation of these resources. The organization must perform a periodic scan/review of the application (as required by CCI-000384) and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure.
Checks: C-26479r1013871_chk

Verify stack tracing has been disabled in Apache Tomcat. Navigate to the ISEC7 SPHERE installation directory: &lt;Drive&gt;:\Program Files\ISEC7 SPHERE\web\WEB-INF. Open web.xml with Notepad.exe. Scroll to the end of the file. Confirm there are no comment tags &lt;!--" and "--&gt; and the following exists without comment tags: &lt;error-page&gt; &lt;exception-type&gt;java.lang.Exception&lt;/exception-type&gt; &lt;location&gt;/exception.jsp&lt;/location&gt; &lt;/error-page&gt; If stack tracing has not been disabled in Apache Tomcat, this is a finding.

Fix: F-26467r1013872_fix

Remove the default error page by updating the web application web.xml file. Navigate to the ISEC7 SPHERE installation directory: <Drive>:\Program Files\ISEC7 SPHERE\web\WEB-INF. Open web.xml with Notepad.exe. Scroll to the end of the file. Remove the comment tags <!--" and "-->. <!-- <error-page> <exception-type>java.lang.Exception</exception-type> <location>/exception.jsp</location> </error-page> --> Save the changes. This will acknowledge to the user that an exception occurred without showing any trace or source information.

b
The Apache Tomcat shutdown port must be disabled.
CM-5 - Medium - CCI-001813 - V-224789 - SV-224789r1013876_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001813
Version
ISEC-06-551300
Vuln IDs
  • V-224789
  • V-97293
Rule IDs
  • SV-224789r1013876_rule
  • SV-106397
Tomcat uses a port (defaults to 8005) as a shutdown port. Someone could Telnet to the machine using this port and send the default command SHUTDOWN. Tomcat and all web apps would shut down in that case, which is a denial-of-service attack and would cause an unwanted service interruption.
Checks: C-26480r1013874_chk

Verify the shutdown port is disabled. Log in to the SPHERE server. Browse to Program Files\Isec7 SPHERE\Tomcat\Conf. Open the server.xml with Notepad.exe. Select Edit &gt;&gt; Find, and then search for "Shutdown". Verify that the shutdown port has been disabled with entry below: shutdown="-1" If the shutdown port has not been disabled, this is a finding.

Fix: F-26468r1013875_fix

Log in to the SPHERE server. Browse to Program Files\Isec7 SPHERE\Tomcat\Conf. Open the server.xml with Notepad.exe. Select Edit >> Find, and then search for "Shutdown". Change the shutdown to "-1". example: shutdown=-1 Save the file and restart the Isec7 SPHERE Web service with the services.msc.

b
The ISEC7 SPHERE must remove any unnecessary users or groups that have permissions to the server.xml file in Apache Tomcat.
CM-5 - Medium - CCI-001813 - V-224790 - SV-224790r1013879_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001813
Version
ISEC-06-551310
Vuln IDs
  • V-224790
  • V-97295
Rule IDs
  • SV-224790r1013879_rule
  • SV-106399
Tomcat uses a port (defaults to 8005) as a shutdown port. Someone could Telnet to the machine using this port and send the default command SHUTDOWN. Tomcat and all web apps would shut down in that case, which is a denial-of-service attack and would cause an unwanted service interruption.
Checks: C-26481r1013877_chk

Verify unnecessary users or groups that have permissions to the Server.xml file in Apache Tomcat have been removed. Browse to ProgramFiles\Isec7 SPHERE\Tomcat\Conf and select "Server.xml". Right-click and select "Properties". Select the security tab and verify no unnecessary account or groups have been granted permissions to the file. Verify no unnecessary users or groups have permissions to the file. If unnecessary users or groups that have permissions to the Server.xml file in Apache Tomcat have not been removed, this is a finding.

Fix: F-26469r1013878_fix

Log in to the ISEC7 SPHERE server. Browse to ProgramFiles\Isec7 SPHERE\Tomcat\Conf and select Server.xml. Right-click and select "Properties". Select the security tab and remove unnecessary accounts or groups that have been granted permissions to the Server.xml file.

b
A manager role must be assigned to the Apache Tomcat Web apps (Manager, Host-Manager).
AU-12 - Medium - CCI-000171 - V-224791 - SV-224791r1013882_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000171
Version
ISEC-06-551400
Vuln IDs
  • V-224791
  • V-97297
Rule IDs
  • SV-224791r1013882_rule
  • SV-106401
If a manager role is not assigned to the Apache Tomcat web apps, the system administrator will not be able to manage and configure the web apps and security setting may not be configured correctly, with could leave the Apache Tomcat susceptible to attack by an intruder.
Checks: C-26482r1013880_chk

Verify a manager role has been assigned to the Apache Tomcat Web apps (Manager, Host-Manager). Log in to the ISEC7 SPHERE server. Navigate to &lt;Drive&gt;:\Program Files\ISEC7 SPHERE\Tomcat\conf\. Confirm a user with the manager role to &lt;Drive&gt;:\Program Files\ISEC7 SPHERE\Tomcat\conf\tomcat-users.xml exists. example: &lt;user username="admin" roles="manager-gui,manager-script" ..../&gt; If a manager role has not been assigned to the Apache Tomcat Web apps, this is a finding.

Fix: F-26470r1013881_fix

To add a manager role to the Apache Tomcat Web apps (Manager, Host-Manager), run the ISEC7 integrated installer or use the following manual procedure: By default there are no users with the manager role assigned. To make use of the manager webapp, add a new role and user into the <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\tomcat-users.xml file. Log in to the ISEC7 SPHERE server. Navigate to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\. Add a user with the manager role to <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf\tomcat-users.xml. example: <user username="admin" roles="manager-gui,manager-script" ..../> Save the file.

b
SSL must be enabled on Apache Tomcat.
SC-8 - Medium - CCI-002418 - V-224792 - SV-224792r1013885_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ISEC-06-551600
Vuln IDs
  • V-224792
  • V-97299
Rule IDs
  • SV-224792r1013885_rule
  • SV-106403
Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPSEC. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.
Checks: C-26483r1013883_chk

To configure SSL support on Tomcat, run the ISEC7 integrated installer or use the following manual procedure: Log in to the ISEC7 SPHERE server. Open the server.xml file located at &lt;Drive&gt;:\Program Files\ISEC7 SPHERE\Tomcat\conf with Notepad.exe. Select Edit &gt;&gt; Find and search for port="443". If the connector is not present add: ex: &lt;Connector SSLEnabled="true" maxParameterCount="1000" maxThreads="200" port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"&gt; &lt;SSLHostConfig certificateVerification="false" ciphers="HIGH:!aNULL:!MD5:!3DES:!ARIA:!SHA:!CAMELLIA:!AES128-CCM8:!AES128-CCM:!AES256-CCM8:!AES256-CCM:!DHE" honorCipherOrder="true" protocols="+TLSv1.2,+TLSv1.3"&gt; &lt;Certificate certificateKeyAlias="https" certificateKeystoreFile="" certificateKeystoreType="Windows-MY"/&gt; &lt;/SSLHostConfig&gt; &lt;/Connector&gt; Modifying the certificateKeystoreFile path and certificateKeystorePassword as needed or leveraging the Windows-MY certificateKeystoreType instead. If the connector has been commented out, remove the comment characters. Save the file. Restart the ISEC7 SPHERE Web service.

Fix: F-26471r1013884_fix

To configure SSL support on Tomcat, run the ISEC7 integrated installer or use the following manual procedure: Log in to the ISEC7 SPHERE server. Open the server.xml file located at <Drive>:\Program Files\ISEC7 SPHERE\Tomcat\conf with Notepad.exe. Select Edit >> Find and search for port="443". If the connector is not present add: ex: <Connector SSLEnabled="true" maxParameterCount="1000" maxThreads="200" port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"> <SSLHostConfig certificateVerification="false" ciphers="HIGH:!aNULL:!MD5:!3DES:!ARIA:!SHA:!CAMELLIA:!AES128-CCM8:!AES128-CCM:!AES256-CCM8:!AES256-CCM:!DHE" honorCipherOrder="true" protocols="+TLSv1.2,+TLSv1.3"> <Certificate certificateKeyAlias="https" certificateKeystoreFile="" certificateKeystoreType="Windows-MY"/> </SSLHostConfig> </Connector> Modifying the certificateKeystoreFile path and certificateKeystorePassword as needed or leveraging the Windows-MY certificateKeystoreType instead. If the connector has been commented out, remove the comment characters. Save the file. Restart the ISEC7 SPHERE Web service.

b
Tomcat SSL must be restricted except for ISEC7 SPHERE tasks.
SC-8 - Medium - CCI-002418 - V-224793 - SV-224793r1013888_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ISEC-06-551700
Vuln IDs
  • V-224793
  • V-97301
Rule IDs
  • SV-224793r1013888_rule
  • SV-106405
Restricting the use of SSL helps ensure only authorized users and processes have access to Tomcat Web apps and reduces the attack surface of the ISEC7 EMM Suite. Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPSEC. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.
Checks: C-26484r1013886_chk

Verify Tomcat SSL is restricted to only ISEC7 SPHERE tasks. Log in to the ISEC7 SPHERE server. Navigate to &lt;Drive&gt;:\ProgramFiles\ISEC7 SPHERE\Tomcat\conf\. Edit the web.xml file with Notepad.exe. Verify the following entries are present: &lt;security-constraint&gt; &lt;web-resource-collection&gt; &lt;web-resource-name&gt;Unsecure&lt;/web-resource-name&gt; &lt;!-- Agent --&gt; &lt;url-pattern&gt;/BNator/agent/*&lt;/url-pattern&gt; &lt;url-pattern&gt;/app/agent/*&lt;/url-pattern&gt; &lt;url-pattern&gt;/app/admin/agentinstaller.jnlp&lt;/url-pattern&gt; &lt;!-- Client --&gt; &lt;url-pattern&gt;/app/clients/*&lt;/url-pattern&gt; &lt;url-pattern&gt;/app/data/*&lt;/url-pattern&gt; &lt;!-- Remote Control --&gt; &lt;url-pattern&gt;/rc/*&lt;/url-pattern&gt; &lt;!-- Traffic Push --&gt; &lt;url-pattern&gt;/BNator/uss/trafficinfo/*&lt;/url-pattern&gt; &lt;url-pattern&gt;/BNator/data/mds/trafficpush&lt;/url-pattern&gt; &lt;url-pattern&gt;/BNator/favorites/*&lt;/url-pattern&gt; &lt;url-pattern&gt;/app/resource/*&lt;/url-pattern&gt; &lt;/web-resource-collection&gt; &lt;/security-constraint&gt; &lt;security-constraint&gt; &lt;web-resource-collection&gt; &lt;web-resource-name&gt;Secure&lt;/web-resource-name&gt; &lt;url-pattern&gt;/*&lt;/url-pattern&gt; &lt;/web-resource-collection&gt; &lt;user-data-constraint&gt; &lt;transport-guarantee&gt;CONFIDENTIAL&lt;/transport-guarantee&gt; &lt;/user-data-constraint&gt; &lt;/security-constraint&gt; If Tomcat SSL is not restricted to only ISEC7 SPHERE tasks, this is a finding.

Fix: F-26472r1013887_fix

To restrict Tomcat SSL to only ISEC7 SPHERE tasks, run the ISEC7 integrated installer or use the following manual procedure: To restrict SSL for all users except for agent task, the user needs to add a security constraint tag to <Drive>:\ProgramFiles\ISEC7 SPHERE\Tomcat\conf\web.xml. Log in to the ISEC7 SPHERE server. Navigate to <Drive>:\ProgramFiles\ISEC7 SPHERE\Tomcat\conf\. Edit the web.xml file with Notepad.exe. Add the following entry: <security-constraint> <web-resource-collection> <web-resource-name>Unsecure</web-resource-name> <!-- Agent --> <url-pattern>/BNator/agent/*</url-pattern> <url-pattern>/app/agent/*</url-pattern> <url-pattern>/app/admin/agentinstaller.jnlp</url-pattern> <!-- Client --> <url-pattern>/app/clients/*</url-pattern> <url-pattern>/app/data/*</url-pattern> <!-- Remote Control --> <url-pattern>/rc/*</url-pattern> <!-- Traffic Push --> <url-pattern>/BNator/uss/trafficinfo/*</url-pattern> <url-pattern>/BNator/data/mds/trafficpush</url-pattern> <url-pattern>/BNator/favorites/*</url-pattern> <url-pattern>/app/resource/*</url-pattern> </web-resource-collection> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Secure</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>

c
The ISEC7 Sphere server must be maintained at a supported version.
SI-2 - High - CCI-002605 - V-225096 - SV-225096r1013891_rule
RMF Control
SI-2
Severity
H
CCI
CCI-002605
Version
ISEC-00-000100
Vuln IDs
  • V-225096
Rule IDs
  • SV-225096r1013891_rule
Versions of ISEC7 Sphere server are maintained by ISEC7 for specific periods of time. Unsupported versions will not receive security updates for new vulnerabilities which leaves them subject to exploitation. A list of supported ISEC7 Sphere server versions is maintained by ISEC7 here: https://www.isec7-us.com/emm-suite-mobile-monitoring.
Checks: C-26788r1013889_chk

Review the ISEC7 Sphere server version after logging into the console. Correlate the version with the latest supported version of ISEC7 Sphere server. If the installed version of ISEC7 Sphere server is not a supported version, this is a finding.

Fix: F-26776r1013890_fix

The administrator must check https://www.isec7-us.com/emm-suite-mobile-monitoring for the latest supported and unsupported versions of software. Once confirmed, the administrator must update ISEC7 Sphere server to the latest supported version.