Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

Symantec ProxySG NDM Security Technical Implementation Guide

  • Version/Release: V1R2
  • Published: 2019-12-20
  • 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.
c
Symantec ProxySG must enable Attack Detection.
SC-5 - High - CCI-002385 - V-94413 - SV-104305r2_rule
RMF Control
SC-5
Severity
High
CCI
CCI-002385
Version
SYMP-NM-000320
Vuln IDs
  • V-94413
Rule IDs
  • SV-104305r2_rule
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Symantec ProxySG Attack Detection prevents or limits the effects of denial of service (DoS) and distributed-DoS (DDoS) attacks by limiting the number of simultaneous TCP connections and/or excessive repeated requests from each client IP address that can be established within a specified time frame. Configure attack detection for both clients and servers or server groups. The client attack-detection configuration is used to control the behavior of attacking sources. The server attack-detection configuration is used when an administrator wants to prevent a server from becoming overloaded by limiting the number of outstanding requests that are allowed. The default settings should work in most environments, but can be fine tuned to prevent impact on the site's traffic flow. Organizations should also take into consideration the capabilities and configuration of adjacent network devices (e.g., firewalls performing packet filtering to block DoS attacks). The default settings should work in most environments, but can be fine-tuned to prevent impact on the site's traffic flow. Organizations should also take into consideration the capabilities and configuration of adjacent network devices (e.g., firewalls performing packet filtering to block DoS attacks). Default settings for client DDoS settings on the ProxySG are as follows. To view Default settings for client DDoS settings on the ProxySG, type the following command at the command line interface. ProxySG#(config attack-detection)show attack-detection client Client limits enabled: false Client interval: 20 minutes Default client limits: Client concurrent request limit: unlimited Client connection limit: 100 Client failure limit: 50 Client request limit: unlimited Client warning limit: 10 Blocked client action: Drop Client connection unblock time: unlimited Monitor only mode: disabled
Checks: C-93599r1_chk

Verify Attack Detection is enabled. 1. SSH into the ProxySG console, type "enable". 2. Enter the correct password, type "configure terminal". 3. Press "Enter", type "show attack-detection configuration". 4. Confirm that "client limits enabled" equals "true". If Attack Detection is not enabled, this is a finding.

Fix: F-100529r1_fix

Enable the Attack Detection function for the default settings or fine tune needed by site environment. 1. SSH into the ProxySG console, type "enable". 2. Enter the correct password, type "configure terminal". 3. Press "Enter", and then type "attack-detection". 4. Type "client" and press "Enter", type "enable-limits" and press "Enter". See "Chapter 73: Preventing Denial of Service Attacks" in the ProxySG Administration Guide to understand the functionality before proceeding. Fine tune the default client limits if there is an operational impact.

b
Symantec ProxySG must be configured with only one local account that is used as the account of last resort.
AC-2 - Medium - CCI-001358 - V-94653 - SV-104483r1_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001358
Version
SYMP-NM-000010
Vuln IDs
  • V-94653
Rule IDs
  • SV-104483r1_rule
Authentication for administrative (privileged level) access to the device is required at all times. An account can be created on the device's local database for use when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary. The account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions.
Checks: C-93843r1_chk

Verify local accounts besides the account of last resort do not exist. Show security local-user-list View "Users:" list If any users show in the "Users" configuration list other than the default admin user, this is a finding.

Fix: F-100771r1_fix

Remove local accounts that are not the account of last resort. 1. Log on to the Web Management Console. 2. Click "Local". 3. If a local realm exists on the list, delete the realm.

c
Symantec ProxySG must be configured to enforce user authorization to implement least privilege.
AC-3 - High - CCI-000213 - V-94655 - SV-104485r1_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
SYMP-NM-000020
Vuln IDs
  • V-94655
Rule IDs
  • SV-104485r1_rule
To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Network devices use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the network device to control access between administrators (or processes acting on behalf of administrators) and objects (e.g., device commands, files, records, processes) in the network device.
Checks: C-93845r1_chk

Obtain a list of authorized personnel or host IP addresses and associated roles/privileges. Verify there are no unauthorized users/host IP addresses. Verify there are no users or host IP addresses with excess privileges. 1. Log on to the Web Management Console. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click the "Launch" button. 4. Click the "Admin Access" layer. Verify that any users, hosts, and groups listed in the "source" field of each rule that have an action of "Allow" are authorized administrators with read-write, read-only, or deny. If users or hosts are configured for excess privileges, this is a finding.

Fix: F-100773r1_fix

Obtain a list of authorized personnel or host IP addresses and associated roles/privileges. Remove any unauthorized users or excess privileges. 1. Log on to the Web Management Console. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click the "Launch" button. 4. Click the "Admin Access" layer. 5. Delete unauthorized users or host IP addresses and adjust or correct user authorizations for "allow read-only" or "allow read-write".

c
Symantec ProxySG must configure Web Management Console access restrictions to authorized IP address/ranges.
AC-3 - High - CCI-000213 - V-94657 - SV-104487r1_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
SYMP-NM-000030
Vuln IDs
  • V-94657
Rule IDs
  • SV-104487r1_rule
It is important that administrative access (SSH, web) to an appliance using the account of last resort be able to be restricted to only the appropriate networks/subnets in order to reduce the likelihood of unauthorized access.
Checks: C-93847r1_chk

Verify console access using the account of last resort has been restricted to specific networks/subnets. 1. Log on to the Web Management Console. 2. Click >> Configuration >> Authentication >> Console Access. 3. Confirm that the correct networks/subnets are specified in the list. If there are no entries in the list, this is a finding.

Fix: F-100775r1_fix

Configure console access using the account of last resort to specific networks/subnets. 1. Log on to the Web Management Console. 2. Click Configuration >> Authentication >> Console Access. 3. Click "New". 4. Enter the IP address and subnet mask for the desired network and click "OK". 5. Repeat step 4 until all desired networks have been added. 6. Click "Apply".

b
Symantec ProxySG must be configured to enforce assigned privilege levels for approved administrators when accessing the management console, SSH, and the command line interface (CLI).
AC-4 - Medium - CCI-001368 - V-94659 - SV-104489r1_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
SYMP-NM-000040
Vuln IDs
  • V-94659
Rule IDs
  • SV-104489r1_rule
A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If management information flow is not enforced based on approved authorizations, the network device may become compromised. Information flow control regulates where management information is allowed to travel within a network device. The flow of all management information must be monitored and controlled so it does not introduce any unacceptable risk to the network device or data. Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of management information within the system in accordance with applicable policy.
Checks: C-93849r1_chk

1. Obtain a list of authorized personnel and IP addresses that should have access to the Web Management Console or CLI. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click the "Launch button". 4. Click the "Admin Access" layer. 5. Verify any users and/or groups listed in the "source" field of each rule have the appropriate Action of either "Allow Read/Write access" or "Allow Read-only Access" per the user/group’s assigned privileges. 6. Verify that the users and/or groups have the Service set to "SSH-Console", "HTTPS-Console", or both, depending on the user/group’s assigned privileges. 7. Ensure the account of last resort is not allowed access via the "SSH-Console" or the "HTTPS-Console", but only via the local console port and CLI. If the Symantec ProxySG is not configured to enforce assigned privilege levels for approved administrators when accessing the Management Console and the CLI, this is a finding.

Fix: F-100777r1_fix

1. Obtain a list of authorized personnel and IP addresses that should have access to the Web Management Console or CLI. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click the "Launch" button. 4. Click the "Admin Access" layer. 5. For every user and/or group listed in the "source" field of each rule, set the Action to either "Allow Read/Write access" or "Allow Read-only Access" per the user/group’s assigned privileges. 6. For every user/group, also set the Service to "SSH-Console", "HTTPS-Console", or both, per the user/group’s assigned privileges. 7. Configure the account of last resort to disallow access via the "SSH-Console" and the "HTTPS-Console". Access is only allowed via the local console port and CLI. Note that DoD requires users to be assigned to groups rather than assigned privileges to individual users whenever possible.

b
Symantec ProxySG must be configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.
AC-7 - Medium - CCI-000044 - V-94661 - SV-104491r1_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-000044
Version
SYMP-NM-000050
Vuln IDs
  • V-94661
Rule IDs
  • SV-104491r1_rule
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced.
Checks: C-93851r2_chk

Verify the lockout policy is configured. 1. SSH into the ProxySG console, type "enable", press "Enter". 2. Enter the appropriate password, type "config", press "Enter". 3. Type "show security local-user-list", press "Enter". This should return a value of "3" for the "Max failed attempts" and "900" for the value of both the "lockout duration" and "reset interval" fields. If Symantec ProxySG is not configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period, this is a finding.

Fix: F-100779r1_fix

The lockout policy may be configured for both SSH and Web Management Console sessions. 1. SSH into the ProxySG console, type "enable", press "Enter". 2. Enter the appropriate password, type "config", press "Enter". 3. Type "security local-user-list edit local_user_database", press "Enter". 4. Type "lockout-duration 900", type "max-failed-attempts 3", press "Enter".

a
Symantec ProxySG must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the device.
AC-8 - Low - CCI-000048 - V-94663 - SV-104493r1_rule
RMF Control
AC-8
Severity
Low
CCI
CCI-000048
Version
SYMP-NM-000060
Vuln IDs
  • V-94663
Rule IDs
  • SV-104493r1_rule
Display of the DoD-approved use notification before granting access to the network device 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. Configuration of the notice banner on for logon to the management console requires the configuration of a reverse proxy service and a policy associated with this service. Refer to the detailed documentation for information on configuration. https://origin-symwisedownload.symantec.com//resources/webguides/proxysg/certification/notice_consent_webguide/Notice_Consent_Banner.htm#Topics/create_banner.htm and click on "Create a Banner for the Management Console" or search for "Symantec Notice and Consent Banner Configuration Webguide" in Google and click on "Create the Notice and Consent Banner". The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage 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-93853r1_chk

Verify the Standard DoD Banner is displayed: 1. Log on to the Web Management Console of the Symantec ProxySG and confirm that a banner is displayed that complies with the DoD requirement. 2. SSH into the command line interface of the Symantec ProxySG and confirm that a banner is displayed that complies with the DoD requirement. 3. Connect a computer to the serial port of the appliance and confirm that the DoD banner is displayed. If Symantec ProxySG does not display the Standard Mandatory DoD Notice and Consent Banner before granting access to the device, this is a finding.

Fix: F-100781r1_fix

Configure the Symantec ProxySG Management Console, SSH, and serial port to display the Standard Mandatory DoD Notice and Consent Banner in accordance with DoD policy before granting access to the device. 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." To create an SSH logon banner: 1. Log on to the ProxySG Web Management Console, click "Configuration," then "Authentication," then "SSH Inbound Connections". 2. Enter the desired banner text into the "SSHv2 Welcome Banner" field, click "Apply". To create a web user interface banner: 1. Log on to the ProxySG Management Console. 2. Create a reverse proxy service for the Notice and Consent banner. 3. Create the banner policy for the reverse proxy service realm using Visual Policy Manager. To create a banner for the serial port: 1. Log on to the Command Line Interface (CLI). 2. Enter privileged mode. 3. Enter the following commands: #(config)serial-console #(config serial-console)inline pre-authentication-terms EOF <Add the banner line by line exactly as stated with no changes.> EOF

b
Symantec ProxySG must enable event access logging.
AU-12 - Medium - CCI-000169 - V-94665 - SV-104495r1_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
SYMP-NM-000070
Vuln IDs
  • V-94665
Rule IDs
  • SV-104495r1_rule
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the network device (e.g., process, module). Certain specific device functionalities may be audited as well. 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. DoD has defined the list of events for which the device will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. ProxySG generates the required logs both automatically and with additional configuration. See the check section for more details. Logs are written locally up to the allowed log size and overwrite the oldest log entries first when the log size limit is reached. The retention of logs written to remote syslog systems are governed by those remote systems.
Checks: C-93855r1_chk

Verify event access logging is enabled. 1. Log on to the Web Management Console. 2. Click Maintenance &gt;&gt; Event Logging and ensure that the log level is set to at least "Configuration Events". If event access logging is not enabled, this is a finding.

Fix: F-100783r1_fix

Event access logging is enabled by default. In order to enable audit logging, both "Event Logging" and "Admin Access Layer" logging must be configured. All information is always logged, but a display filter can be set to view a subset of the information. 1. Log on to the Web Management Console. 2. Click Maintenance >> Event Logging and ensure that the log level is set to at least "Configuration Events".

b
Symantec ProxySG must be configured to support centralized management and configuration of the audit log.
AU-4 - Medium - CCI-001851 - V-94667 - SV-104497r1_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
SYMP-NM-000080
Vuln IDs
  • V-94667
Rule IDs
  • SV-104497r1_rule
Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The DoD requires centralized management of all network component audit record content. Network components requiring centralized audit log management must have the capability to support centralized management. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Ensure at least one Syslog server and local files are configured to support requirements. However, the Syslog itself must also be configured to filter event records so it is not overwhelmed.
Checks: C-93857r1_chk

Verify event logging to a syslog server is enabled. 1. Log on to the Web Management Console. 2. Click Maintenance &gt;&gt; Event Logging &gt;&gt; Syslog. 3. Ensure that the "Enable Syslog" checkbox is checked and that one or more "syslog loghosts" are specified. If Symantec ProxySG does not off-load audit records onto a different system or media than the system being audited, this is a finding.

Fix: F-100785r1_fix

Configure event logging to a remote events server to ensure that event logs are recorded on a different system. To configure Syslog: 1. Log on to the Web Management Console. 2. Click Maintenance >> Event Logging >> Syslog. 3. Enter the IP address or name of a syslog server, click "OK". 4. Repeat step 3 for any additional syslog servers. 5. Click "Apply".

a
Symantec ProxySG must generate an alert to the console when a log processing failure is detected such as loss of communications with the Central Log Server or log records are no longer being sent.
AU-5 - Low - CCI-001858 - V-94669 - SV-104499r1_rule
RMF Control
AU-5
Severity
Low
CCI
CCI-001858
Version
SYMP-NM-000090
Vuln IDs
  • V-94669
Rule IDs
  • SV-104499r1_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 an alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Alerts provide organizations with urgent messages.
Checks: C-93859r1_chk

Verify the Symantec ProxySG is configured to send alerts when event logging fails. 1. Log on to the Web Management Console. 2. Click Maintenance &gt;&gt; Events Logging. 3. Confirm that "Severe" is checked. 4. Select the "Mail" tab and confirm an email address of an administrator is entered. If Symantec ProxySG does not generate an alert to the console when a log processing failure is detected such as loss of communications with the Central Log Server or log records are no longer being sent, this is a finding.

Fix: F-100787r1_fix

Configure the ProxySG to send notifications. 1. Log on to the Web Management Console. 2. Click Maintenance >> Events Logging. 3. Select "Severe". 4. Select the "Mail" tab and enter the email address to receive the email alert. 5. Click "Apply".

b
Symantec ProxySG must compare internal information system clocks at least every 24 hours with an authoritative time server.
AU-8 - Medium - CCI-001891 - V-94671 - SV-104501r1_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
SYMP-NM-000100
Vuln IDs
  • V-94671
Rule IDs
  • SV-104501r1_rule
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside of the configured acceptable allowance (drift) may be inaccurate. Additionally, unnecessary synchronization may have an adverse impact on system performance and may indicate malicious activity. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.
Checks: C-93861r1_chk

Verify the Symantec ProxySG is configured to use authoritative NTP servers (the NTP protocol itself enforces periodic checks at least every 24 hours). 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; General &gt;&gt; Clock. 3. Confirm that the value of the "Query interval (minutes)" field is at least 1440 (24 hours in minutes). 4. Click "NTP", and confirm that the desired authoritative time servers are present. If Symantec ProxySG does not compare internal information system clocks at least every 24 hours with an authoritative time server, this is a finding.

Fix: F-100789r1_fix

Configure the Symantec ProxySG to use authoritative NTP servers (the NTP protocol itself enforces periodic checks at least every 24 hours). 1. Log on to the Web Management Console. 2. Select "Configuration", then "General", then "Clock". 3. Enter the desired time sync period into the "Query interval (minutes) field and click Apply. 4. Click "NTP", then "New", then "Add" and enter each desired authoritative time server. 5. Click "Apply".

b
Symantec ProxySG must be configured to synchronize internal information system clocks with the primary and secondary time sources located in different geographic regions using redundant authoritative time sources.
CM-6 - Medium - CCI-000366 - V-94673 - SV-104503r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000110
Vuln IDs
  • V-94673
Rule IDs
  • SV-104503r1_rule
The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions. Multiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must utilize an authoritative time server and/or be configured to use redundant authoritative time sources. This requirement is related to the comparison done in CCI-001891. DoD-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DoD network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source.
Checks: C-93863r1_chk

Verify the Symantec ProxySG is configured to use authoritative NTP servers. 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; General &gt;&gt; Clock. 3. Click "NTP", and confirm that the desired authoritative time servers are present. If Symantec ProxySG does not be configured to synchronize internal information system clocks with the primary and secondary time sources located in different geographic regions using redundant authoritative time sources, this is a finding.

Fix: F-100791r1_fix

Configure the ProxySG is configured to use authoritative NTP servers. 1. Log on to the Web Management Console. 2. Click Configuration >> General >> Clock. 3. Click "NTP", click "New", click "Add" and enter each desired authoritative time server. 4. Click "Apply".

b
Symantec ProxySG must protect the Web Management Console, SSH, and command line interface (CLI) from unauthorized modification.
AU-9 - Medium - CCI-001494 - V-94675 - SV-104505r1_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001494
Version
SYMP-NM-000120
Vuln IDs
  • V-94675
Rule IDs
  • SV-104505r1_rule
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Network devices providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-93865r1_chk

1. Obtain a list of authorized personnel and IP addresses that should have access to the Web Management Console or CLI. 2. Log on to the Web Management Console. 3. Click Configuration &gt;&gt; Policy &gt;&gt; Visual Policy Manager. 4. Click "Launch", select the "Admin Access" layer. 5. Verify any users and/or groups listed in the "source" field of each rule have the appropriate "Action" of either "Allow Read/Write access" or "Allow Read-only Access" per the user/group’s assigned privileges. 6. Verify that the users and/or groups have the "Service" set to "SSH-Console", "HTTPS-Console", or both, depending on the user/group’s assigned privileges. If the Symantec ProxySG is not configured to protect the Web Management Console, SSH, and CLI from unauthorized modification, this is a finding.

Fix: F-100793r1_fix

1. Obtain a list of authorized personnel and IP addresses that should have access to the Web Management Console or CLI. 2. Log on to the Web Management Console. 3. Click Configuration >> Policy >> Visual Policy Manager. 4. Click "Launch", select the "Admin Access" layer. 5. For every user and/or group listed in the "source" field of each rule, set the "Action" to either "Allow Read/Write access" or "Allow Read-only Access" per the user/group’s assigned privileges. 6. For every user/group, also set the "Service" to "SSH-Console", "HTTPS-Console", or both, per the user/group’s assigned privileges. Note that DoD requires users to be assigned to groups rather than assigned privileges to individual users whenever possible.

b
Symantec ProxySG must protect the Web Management Console, SSH, and command line interface (CLI) from unauthorized access.
AU-9 - Medium - CCI-001493 - V-94677 - SV-104507r1_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
SYMP-NM-000130
Vuln IDs
  • V-94677
Rule IDs
  • SV-104507r1_rule
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Network devices providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-93867r1_chk

1. Obtain a list of authorized personnel and IP addresses that should have access to the Web Management Console, SSH, or CLI. 2. Log on to the Web Management Console. 3. Click Configuration &gt;&gt; Policy &gt;&gt; Visual Policy Manager. 4. Click "Launch", select the "Admin Access" layer. 5. Verify any users and/or groups listed in the "source" field of each rule have the appropriate "Action" of either "Allow Read/Write access" or "Allow Read-only Access" per the user/group’s assigned privileges. 6. Verify that the users and/or groups have the "Service" set to "SSH-Console", "HTTPS-Console", or both, depending on the user/group’s assigned privileges. If the Symantec ProxySG is not configured to protect the Web Management Console, SSH, and CLI from unauthorized access, this is a finding.

Fix: F-100795r1_fix

1. Obtain a list of authorized personnel and IP addresses that should have access to the Web Management Console or CLI. 2. Log on to the Web Management Console. 3. Click Configuration >> Policy >> Visual Policy Manager. 4. Click "Launch", select the "Admin Access" layer. 5. For every user and/or group listed in the "source" field of each rule, set the "Action" to either "Allow Read/Write access" or "Allow Read-only Access" per the user/group’s assigned privileges. 6. For every user/group, also set the "Service" to "SSH-Console", "HTTPS-Console", or both, per the user/group’s assigned privileges. Note that DoD requires users to be assigned to groups rather than assigned privileges to individual users whenever possible.

b
Symantec ProxySG must back up event logs onto a different system or system component than the system or component being audited.
AU-9 - Medium - CCI-001348 - V-94679 - SV-104509r1_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001348
Version
SYMP-NM-000140
Vuln IDs
  • V-94679
Rule IDs
  • SV-104509r1_rule
Protection of log data includes assuring log data is not accidentally lost or deleted. Regularly backing up audit records to a different system or onto separate media than the system being audited 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.
Checks: C-93869r1_chk

Verify event logging to a remote events collection server is configured in order to send event logs to a different system. 1. Log on to the Web Management Console. 2. Click Maintenance &gt;&gt; Event Logging &gt;&gt; Syslog. 3. Confirm that "Syslog" is "Enabled" and a syslog server is specified. If Symantec ProxySG does not back up event logs onto a different system or system component than the system or component being audited, this is a finding.

Fix: F-100797r1_fix

Configure event logging to a remote events server to ensure that event logs are recorded on a different system. To configure Syslog: 1. Log on to the Web Management Console. 2. Click Maintenance >> Event Logging >> Syslog. 3. Enter the IP address or name of a syslog server, click "OK". 4. Repeat step 3 for any additional syslog servers. 5. Click "Apply".

b
Symantec ProxySG must employ automated mechanisms to centrally verify authentication settings.
CM-6 - Medium - CCI-000366 - V-94681 - SV-104511r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000150
Vuln IDs
  • V-94681
Rule IDs
  • SV-104511r1_rule
The use of authentication servers or other centralized management servers for providing centralized authentication services is required for network device management. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. Without centralized management, it is likely that credentials for some network devices will be forgotten, leading to delays in administration, which itself leads to delays in remediating production problems and in addressing compromises in a timely fashion.
Checks: C-93871r1_chk

Verify a AAA server is used for access by system administrators as required in DoD. 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; Authentication &gt;&gt; RADIUS. 3. Confirm that a RADIUS realm has been configured. 4. Click Configuration &gt;&gt; Policy &gt;&gt; Visual Policy Manager. 5. Click "Launch", select the "Admin Authentication" layer. 6. Confirm the "Action" in each rule references the RADIUS realm in step 3. If Symantec ProxySG does not employ automated mechanisms to centrally verify authentication settings, this is a finding.

Fix: F-100799r1_fix

Configure the Symantec ProxySG to use a centrally administered AAA server. 1. Log on to the Web Management Console. 2. Click Configuration >> Authentication >> RADIUS. 3. Click "New" then enter a Realm name. 4. Under "Realm configuration" enter the IP address for the primary RADIUS server and modify port (if necessary). 5. Enter a Secret pre-shared key, and enter the same Secret pre-shred key for confirmation, click "OK". 6. Click Radius Servers. 7. Enter an IP address for the Alternate Server and modify port (if necessary). 8. Click "Apply". 9. Click Configuration >> Policy >> Visual Policy Manager. 10. Click "Launch", select the "Admin Authentication" layer. 11. Right-click the "Action" in each rule and click "Set". 12. Click "New", then "Authenticate", and choose the RADIUS realm configured in step 3. 13. Click "File", click "Install Policy on SG Appliance".

b
Accounts for device management must be configured on the authentication server and not on Symantec ProxySG itself, except for the account of last resort.
CM-6 - Medium - CCI-000366 - V-94683 - SV-104513r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000160
Vuln IDs
  • V-94683
Rule IDs
  • SV-104513r1_rule
Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is particularly important protection against the insider threat. With robust centralized management, audit records for administrator account access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device.
Checks: C-93873r1_chk

Verify that the Symantec ProxySG uses a centrally administered AAA server (LDAP to Active Directory). 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; Authentication &gt;&gt; LDAP. 3. Click through the "LDAP Realms", "LDAP DN", "LDAP Search &amp; Groups", "LDAP Objectclasses", and "LDAP General" tabs and ensure that the settings are appropriate for your organization. If accounts for device management are not configured on the authentication server or are on the Symantec ProxySG itself, except for the account of last resort, this is a finding.

Fix: F-100801r1_fix

In order to configure the ProxySG to use a centrally administered AAA server (LDAP to Active Directory): 1. Log on to the Web Management Console. 2. Click Configuration >> Authentication >> LDAP. 3. Click "New", provide a name for the realm. 4. Change the "Type of LDAP server" to be "Microsoft Active Directory". 5. Provide an IP address or FQDN for the "Primary Server host" and change the port to 636 for LDAP over TLS. 6. Change the "User attribute type" if your organization uses a different attribute than the sAMAccountName, click "OK". 7. Click on the "LDAP Servers" tab, select "Enable SSL", and confirm the other settings per your organization. 8. Click through the "LDAP DN", "LDAP Search & Groups", "LDAP Objectclasses", and "LDAP General" tabs and ensure that the settings are appropriate for your organization. 9. Click "Apply". 10. To test the configuration, click the "Test Configuration" button under "LDAP Servers", and provide a valid username and password. 11. Still within the "Configuration" tab, click on "Policy", then "Visual Policy Editor" and click "Launch". 12. Click "Policy" and choose "Add Admin Authentication Layer". 13. Give it a name and click "OK". 14. Right-click the "Action" cell and choose "Set". 15. With "AdminAuthenticate1" highlighted, click "Edit". 16. Choose the "Realm" that was created on step 3, and click "OK", click "OK" again. 17. Click "Policy" and choose "Add Admin Access Layer". 18. Give it a name and click "OK". 19. Right-click the "Source" field and click "Set". 20. If a "local realm" exists in the list, highlight it and click "Remove". 21. Click "New", and choose either "User" or "Group" depending on what you wish to accomplish. 22. Provide the user or group name, and ensure that the Authentication Realm from step 3 is selected, and populate the Group/User Base DN and "Full Name" fields as appropriate for your organization. 23. If you wish to restrict this user/group to specific management services, right-click the "Service" Field, and select "Set", click "New", click "Service Name" then choose the appropriate service name. Repeat for any other specific services you would like to grant access for. Then click "OK". 24. Right-click the "Action" cell, and either choose "read-only" or "read/write" access. 25. Click "File" and choose "Install Policy on SG Appliance".

b
Symantec ProxySG must use Role-Based Access Control (RBAC) to assign privileges to users for access to files and functions.
CM-6 - Medium - CCI-000366 - V-94685 - SV-104515r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000170
Vuln IDs
  • V-94685
Rule IDs
  • SV-104515r1_rule
Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organization-defined roles. When administrators are assigned to the organizational roles, they inherit the authorizations or privileges defined for those roles. RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every administrator (which can be a significant number of individuals for mid- to large-size organizations) but are instead acquired through role assignments. RBAC can be implemented either as a mandatory or discretionary form of access control. The RBAC policies and the subjects and objects are defined uniquely for each network device, so they cannot be specified in the requirement.
Checks: C-93875r1_chk

Confirm that role-based access control is configured. 1. Log on to the Management Console. 2. Click Configuration &gt;&gt; Policy &gt;&gt; Visual Policy Manager. 3. Click "Launch", select "Admin Access Layer" verify that at least one rule has been defined, and that each rule does not have "Any" or a single user defined in the "Source" field. Instead, each rule should have a user group specified in the "Source" field. 4. Confirm with the ProxySG administrator that each rule has the appropriate permission for the user or group specified in the rule (Action set to "Allow Read-Only Access" or "Allow Read-Write Access"). If Symantec ProxySG does not use Role-Based Access Control (RBAC) to assign privileges to users for access to files and functions, this is a finding.

Fix: F-100803r1_fix

Configure the ProxySG for role-based group access. 1. Log on to the Web Management Console. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click "Launch", select "Admin Access Layer". 4. For each rule that does not have an Action of "None" or "Deny" that also does not have a user group set in the "Source" field, right-click the "Source" field and click "Set". 5. Click each "Source Object" that represents a specific user (vs a user group) and click "Remove". 6. Click "New" and select "Group" from the menu. Enter the correct information for the desired user group which should have access to the ProxySG and click "OK", then "OK" again. Repeat for each rule in the Admin Access layer. 7. Click the "Install Policy" button to commit the changes to the Symantec ProxySG.

b
Symantec ProxySG must employ automated mechanisms to centrally apply authentication settings.
CM-6 - Medium - CCI-000366 - V-94687 - SV-104517r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000180
Vuln IDs
  • V-94687
Rule IDs
  • SV-104517r1_rule
The use of authentication servers or other centralized management servers for providing centralized authentication services is required for network device management. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. Without centralized management, it is likely that credentials for some network devices will be forgotten, leading to delays in administration, which itself leads to delays in remediating production problems and in addressing compromises in a timely fashion.
Checks: C-93877r1_chk

Verify a AAA server is used for access by system administrators as required in DoD. 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; Authentication &gt;&gt; RADIUS, confirm that a RADIUS realm has been configured. 3. Click Policy &gt;&gt; Visual Policy Manager. 4. Click "Launch", select the "Admin Authentication" layer and confirm that the "Action" in each rule references the RADIUS realm in step 2. If Symantec ProxySG does not employ automated mechanisms to centrally apply authentication settings, this is a finding.

Fix: F-100805r1_fix

Configure the Symantec ProxySG to use a centrally administered AAA server. 1. Log on to the Web Management Console. 2. Click Configuration >> Authentication >> RADIUS. 3. Click "New" then enter a Realm name. 4. Under "Realm configuration", enter the IP address for the primary RADIUS server and modify port (if necessary). 5. Enter a Secret pre-shared key, and enter the same Secret pre-shared key for confirmation, and click "OK". 6. Click "Radius Servers". 7. Enter an IP address for the Alternate Server and modify port (if necessary). 8. Click "Apply". 9. Click Policy >> Visual Policy Manager. 10. Click "Launch", select the "Admin Authentication" Layer, right-click the Action in each rule, and click "Set". 11. Click "New", click "Authenticate", and choose the RADIUS realm configured in step 2. 12. Click "File" and then "Install Policy on SG Appliance".

b
Symantec ProxySG must support organizational requirements to conduct backups of system level information contained in the ProxySG when changes occur or weekly, whichever is sooner.
CM-6 - Medium - CCI-000366 - V-94689 - SV-104519r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000190
Vuln IDs
  • V-94689
Rule IDs
  • SV-104519r1_rule
System-level information includes default and customized settings and security attributes, including ACLs that relate to the network device configuration, as well as software required for the execution and operation of the device. Information system backup is a critical step in ensuring system integrity and availability. If the system fails and there is no backup of the system-level information, a denial of service condition is possible for all who utilize this critical network component. This control requires the network device to support the organizational central backup process for system-level information associated with the network device. This function may be provided by the network device itself; however, the preferred best practice is a centralized backup rather than each network device performing discrete backups.
Checks: C-93879r1_chk

Symantec ProxySG supports backups natively. Verify that backups are being stored remotely. 1. Check with the Symantec ProxySG administrator to determine what their strategy is for backups. 2. Log on to the Web Management Console. 3. Click Configuration &gt;&gt; General &gt;&gt; Archive &gt;&gt; Archive Storage. 4. Confirm that there are entries in the "Remote Upload" fields (Host, Path, Username). If Symantec ProxySG does not support organizational requirements to conduct backups of system level information contained in the Symantec ProxySG when changes occur or weekly, whichever is sooner, this is a finding.

Fix: F-100807r1_fix

Configure backups for remote storage as follows. 1. Log on to the Web Management Console. 2. Click Configuration >> General >> Archive >> Archive Storage. 3. Provide the correct entries in the "Remote Upload" fields for an available remote backup storage server (Protocol, Host, Path, Username). 4. Click "Apply". Note: Please see Chapter 5: Backing Up the Configuration in the ProxySG Administration Guide for complete details.

b
Symantec ProxySG must obtain its public key certificates from an appropriate certificate policy through an approved service provider.
CM-6 - Medium - CCI-000366 - V-94691 - SV-104521r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000200
Vuln IDs
  • V-94691
Rule IDs
  • SV-104521r1_rule
For user certificates, each organization obtains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice.
Checks: C-93881r1_chk

Verify all management certificates are issued by an appropriate certificate authority. 1. Log on to the Web Management Console. 2. Click Services &gt;&gt; Management Services, click on HTTPS-Console and click "Edit". 3. Note the name of the "keyring" assigned. 4. Click Configuration &gt;&gt; SSL &gt;&gt; Keyrings. 5. Select the keyring that was noted above, click "View Certificate". 6. Confirm that the certificate is issued by the appropriate certificate authority. If Symantec ProxySG does not obtain its public key certificates from an appropriate certificate policy through an approved service provider, this is a finding.

Fix: F-100809r1_fix

Assign an appropriately signed certificate to the management interface. 1. Log on to the Web Management Console. 2. Click Configuration >> SSL >> Keyrings. 3. Click "Create", provide a name and bit size, click "OK". 4. Select the newly created keyring, click "Edit". 5. Click "Create" under "Certificate Signing Request" and enter the appropriate information, click "OK", click "Close", click "Apply". 6. Select the newly created keyring, click "Edit". 7. Copy the text in the "Certificate Signing Request" field and submit to your appropriate Certificate Authority. 8. Once the certificate has been issued, paste it into the "Certificate" field, click "Close", click "Apply". 9. Click Services >> Management Services, click on "HTTPS-Console", click "Edit". 10. Change the "Keyring" value to the newly created keyring, click "OK", click "Apply".

b
Symantec ProxySG must configure the maintenance and health monitoring to send an alarm when a critical condition occurs for a component.
CM-6 - Medium - CCI-000366 - V-94693 - SV-104523r1_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SYMP-NM-000210
Vuln IDs
  • V-94693
Rule IDs
  • SV-104523r1_rule
Predictable failure prevention requires organizational planning to address device failure issues. If components key to maintaining the device's security fail to function, the device could continue operating in an insecure state. If appropriate actions are not taken when a network device failure occurs, a denial of service condition may occur which could result in mission failure since the network would be operating without a critical security monitoring and prevention function. Upon detecting a failure of network device security components, the network device must activate a system alert message or send an alarm. The type of alarm should ensure that an administrator is made aware of the situation within a period specified in the site's SSP based on mission impact. Alarms may be a message send to an events server, SNMP server, email/text, or a monitored console. The following alarms are required for ProxySG devices used in DoD. General * CPU utilization * Memory utilization * Interface(s) utilization Licensing * User license utilization * Base license expiration Status * Disk * Sensor Count Status * Reboot
Checks: C-93883r1_chk

Verify the Symantec ProxySG is configured to send system health notifications. 1. Log on to Web Management Console. 2. Click Maintenance &gt;&gt; Health Monitoring, select the "General" tab. 3. Confirm that the Notification methods are correct for each metric (Log, Trap, and/or Email). If the Symantec ProxySG is not configured to send system health notifications, this is a finding.

Fix: F-100811r1_fix

Configure the Symantec ProxySG to send system health notifications. 1. Log on to the Web Management Console. 2. Click Maintenance >> Health Monitoring, select the "General" tab. 3. Click on each metric, click "Edit" and set the desired thresholds and notification types (Log, Trap, and/or Email). 4. Click "Apply". Configure the following alarms at a minimum. General * CPU utilization * Memory utilization * Interface(s) utilization Licensing * User license utilization * Base license expiration Status * Disk * Sensor Count Status * Reboot

c
Symantec ProxySG must use only approved management services protocols.
CM-7 - High - CCI-000382 - V-94695 - SV-104525r1_rule
RMF Control
CM-7
Severity
High
CCI
CCI-000382
Version
SYMP-NM-000220
Vuln IDs
  • V-94695
Rule IDs
  • SV-104525r1_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 unused or unnecessary physical and logical ports/protocols on information systems. Network devices 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. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the network device must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved. Some network devices have capabilities enabled by default; if these capabilities are not necessary, they must be disabled. If a particular capability is used, then it must be documented and approved.
Checks: C-93885r1_chk

Verify unauthorized management protocols are not used on the Symantec ProxySG. 1. Log on to Web Management Console. 2. Click Configuration &gt;&gt; Services &gt;&gt; Management Services. 3. Ensure that only approved management services are enabled. "HTTP-Console", in general, should be disabled. If Symantec ProxySG does not use only approved management services protocols, this is a finding.

Fix: F-100813r1_fix

By default, Symantec ProxySG has only HTTPS and SSH enabled for management services. SNMP may also be enabled if needed to support the architecture. "HTTP-Console" is not approved for use in DoD. 1. Log on to Web Management Console. 2. Click Configuration >> Services >> Management Services. 3. Uncheck "enabled" next to unapproved management services such as "HTTP-Console". 4. Click "Apply".

b
Symantec ProxySG must implement HTTPS-console to provide replay-resistant authentication mechanisms for network access to privileged accounts.
IA-2 - Medium - CCI-001941 - V-94697 - SV-104527r1_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001941
Version
SYMP-NM-000230
Vuln IDs
  • V-94697
Rule IDs
  • SV-104527r1_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. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.
Checks: C-93887r1_chk

Verify only TLS management services are enabled. 1. Log on to Web Management Console. 2. Click Configuration &gt;&gt; Services &gt;&gt; Management Services. 3. Verify "HTTP-Console" is not enabled and that "HTTPS-Console" is enabled. If Symantec ProxySG does not implement HTTPS-console, this is a finding.

Fix: F-100815r1_fix

Enable TLS management services. 1. Log on to Web Management Console. 2. Click Configuration >> Services >> Management Services. 3. Make sure that "HTTPS-Console" is "Enabled". 4. Uncheck "Enabled" next to that "HTTP-Console". 5. Click "Apply".

b
Symantec ProxySG must configure SNMPv3 so that cryptographically-based bidirectional authentication is used.
IA-3 - Medium - CCI-001967 - V-94699 - SV-104529r1_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001967
Version
SYMP-NM-000240
Vuln IDs
  • V-94699
Rule IDs
  • SV-104529r1_rule
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. 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, 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 only apply the requirement to those limited number (and type) of devices that truly need to support this capability.
Checks: C-93889r1_chk

Verify only SNMPv3 (which supports authentication) is configured on the Symantec ProxySG. 1. Log on to the Web Management Console. 2. Click Maintenance &gt;&gt; SNMP. 3. Ensure that only "Enable SNMPv3" is checked. 4. Click on "SNMPv3 Users" and ensure that a user exists in the list. If SNMPv3 (which supports authentication) is not configured or is not the only one configured on the Symantec ProxySG, this is a finding.

Fix: F-100817r1_fix

Enable only SNMPv3 (which supports authentication) on the Symantec ProxySG. 1. Log on to the Web Management Console. 2. Click Maintenance >> SNMP. 3. Uncheck "Enable SNMPv1" and "Enable SNMPv2c" and check "Enable SNMPv3". 4. Click on "SNMPv3 Users", click "New" and enter the desired username, credentials, and authorization settings, click "OK". 5. Click "SNMPv3 Traps", click "New", enter the IP address/FQDN for the SNMP receiver. 6. Click "OK", click "Apply".

b
Symantec ProxySG must be configured to enforce a minimum 15-character password length for local accounts.
IA-5 - Medium - CCI-000205 - V-94701 - SV-104531r1_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000205
Version
SYMP-NM-000250
Vuln IDs
  • V-94701
Rule IDs
  • SV-104531r1_rule
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.
Checks: C-93891r1_chk

Verify the minimum password length is set to at least 15 characters. At the CLI, type: Show Security Look for value of the "Minimum Password Length:". If Symantec ProxySG is not configured to enforce a minimum 15-character password length for local accounts, this is a finding.

Fix: F-100819r1_fix

In order to set the minimum password length 15 characters. 1. Log on to the Symantec ProxySG SSH CLI. 2. Type "enable", enter the enable password. 3. Type "configure" and press "Enter". 4. Type "security password-min-len 15" and press "Enter".

c
Symantec ProxySG must transmit only encrypted representations of passwords.
IA-5 - High - CCI-000197 - V-94703 - SV-104533r1_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000197
Version
SYMP-NM-000260
Vuln IDs
  • V-94703
Rule IDs
  • SV-104533r1_rule
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 (i.e., clear text) and easily compromised. Network devices can accomplish this by making direct function calls to encryption modules or by leveraging operating system encryption capabilities.
Checks: C-93893r1_chk

Verify only TLS management services are enabled. 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; Services &gt;&gt; Management Services. 3. Ensure that "HTTP-Console" is not enabled and that "HTTPS-Console" is enabled. If Symantec ProxySG does not transmit only encrypted representations of passwords, this is a finding.

Fix: F-100821r1_fix

Enable TLS management services. 1. Log on to the Web Management Console. 2. Click Configuration >> Services >> Management Services. 3. Ensure "HTTPS-Console" is already enabled. 4. Ensure "HTTP-Console" is not enabled. 5. Click "Apply".

b
Symantec ProxySG must not have a default manufacturer passwords when deployed.
IA-5 - Medium - CCI-002041 - V-94705 - SV-104535r1_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002041
Version
SYMP-NM-000270
Vuln IDs
  • V-94705
Rule IDs
  • SV-104535r1_rule
Network devices not protected with strong password schemes provide the opportunity for anyone to crack the password and gain access to the device, which can result in loss of availability, confidentiality, or integrity of network traffic. Many default vendor passwords are well known or are easily guessed; therefore, not removing them prior to deploying the network device into production provides an opportunity for a malicious user to gain unauthorized access to the device.
Checks: C-93895r1_chk

Verify the initial configuration has been set. Attempt to logon to an SSH session using the default user name of "Admin". Verify that there is a prompt for a password. If Symantec ProxySG does not prompt for a password when logon is attempted, this is a finding.

Fix: F-100823r1_fix

Passwords are set during initial configuration of the Symantec ProxySG. In order to perform this action on a new appliance: 1. Connect to the Symantec ProxySG via a serial console, choose "Manual Setup", and follow the prompts to set system parameters, including local account passwords. 2. Once the system has been configured, local passwords can be changed from the Web Management Console, click Configuration >> Authentication >> Console Access >> Change Password.

c
Symantec ProxySG must be configured to use only FIPS 140-2 approved algorithms for authentication to a cryptographic module with any application or protocol.
IA-7 - High - CCI-000803 - V-94707 - SV-104537r1_rule
RMF Control
IA-7
Severity
High
CCI
CCI-000803
Version
SYMP-NM-000280
Vuln IDs
  • V-94707
Rule IDs
  • SV-104537r1_rule
Unapproved mechanisms that are used for authentication to the cryptographic module are not validated and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. The Symantec ProxySG can be configured in FIPS-mode, but this is not recommended by the vendor or DoD. Instead, ensure that FIPS-compliant mechanisms are used for authenticating to cryptographic modules when not in FIPS-mode. This is true by default, but must be verified to prevent misconfiguration by an administrator. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. However, authentication algorithms must configure security processes to use only FIPS-approved and NIST-recommended authentication algorithms. 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-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. Applications also include HMAC, KDFs, Random Bit Generation, and hash-only applications (e.g., hashing passwords and using SHA-1 or higher to compute a checksum). For digital signature verification, SP800-131Ar1 allows SHA-1 for legacy use where needed. Currently, the AES block cipher algorithm is approved for use in DoD for both applying cryptographic protection (e.g., encryption) and removing or verifying the protection that was previously applied (e.g., decryption). NTP devices use MD5 authentication keys. The MD5 algorithm is not specified in either the FIPS or NIST recommendation; thus, a CAT 1 finding if used. However, MD5 is preferred to no authentication at all.
Checks: C-93897r1_chk

Verify only FIPS 140-2 approved algorithms are used. 1. Log on to the CLI via SSH. 2. Type "show management services", press "Enter". 3. Ensure that the "Cipher Suite" attribute contains only FIPS 140-2 approved algorithms. If Symantec ProxySG is not configured to use FIPS 140-2 approved algorithms for authentication to a cryptographic module for any protocol or application, this is a finding.

Fix: F-100825r1_fix

Configure the ProxySG to use only FIPS 140-2 approved algorithms. 1. Log on to the CLI via SSH. 2. Type "enable", press "Enter". 3. Type "configure", press "Enter". 4. Type "management services", press "Enter". 5. Type "edit https-console", press "Enter". 6. Type "attribute cipher-suite", press "Enter". 7. From the list displayed, enter a list of cipher numbers (comma separated) that correspond to only FIPS 140-2 approved algorithms.

c
The Symantec ProxySG Web Management Console and SSH sessions must implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications.
MA-4 - High - CCI-003123 - V-94709 - SV-104539r1_rule
RMF Control
MA-4
Severity
High
CCI
CCI-003123
Version
SYMP-NM-000290
Vuln IDs
  • V-94709
Rule IDs
  • SV-104539r1_rule
This requirement requires the use of secure protocols instead of their unsecured counterparts, such as SSH instead of telnet, SCP instead of FTP, and HTTPS instead of HTTP. If unsecured protocols (lacking cryptographic mechanisms) are used for sessions, the contents of those sessions will be susceptible to eavesdropping, potentially putting sensitive data (including administrator passwords) at risk of compromise and potentially allowing hijacking of maintenance sessions.
Checks: C-93899r1_chk

Verify only AES ciphers are used for nonlocal maintenance and diagnostic communications. 1. Log on to the CLI via SSH. 2. Type "enable", enter the enable password. 3. Type "configure terminal", press "Enter". 4. Type "show management services" and confirm that the Cipher Suite parameter contains only ciphers that use AES. If Web Management Console and SSH sessions does not implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, this is a finding.

Fix: F-100827r1_fix

Configure the Symantec ProxySG to use only AES ciphers for nonlocal maintenance and diagnostic communications. 1. Log on to the CLI via SSH. 2. Type "enable", enter the enable password. 3. Type "configure terminal" and press "Enter". 4. Type "management-services" and press "Enter", type "edit HTTPS-Console" and press "Enter". 5. Type "view" to display the list of configured cipher suites. 6. Type "attribute cipher-suite" followed by a space-delimited list of only cipher suites from step 5 containing AES and press "Enter".

c
The Symantec ProxySG must use FIPS-validated Keyed-Hash Message Authentication Code (HMAC) to protect the integrity of nonlocal maintenance and diagnostic communications.
MA-4 - High - CCI-002890 - V-94711 - SV-104541r1_rule
RMF Control
MA-4
Severity
High
CCI
CCI-002890
Version
SYMP-NM-000300
Vuln IDs
  • V-94711
Rule IDs
  • SV-104541r1_rule
Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Currently, HMAC is the only FIPS-approved algorithm for generating and verifying message/data authentication codes in accordance with FIPS 198-1. Products that are FIPS 140-2 validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used for authentication to cryptographic modules. Separate requirements for configuring applications and protocols used by each application (e.g., SNMPv3, SSHv2, NTP, HTTPS, and other protocols and applications that require server/client authentication) are required to implement this requirement. Where SSH is used, the SSHv2 protocol suite is required because it includes Layer 7 protocols such as SCP and SFTP, which can be used for secure file transfers.
Checks: C-93901r1_chk

Verify only FIPS compliant HMAC algorithms are in use. 1. Log on to the CLI via SSH. 2. Type "show management services", press "Enter". 3. Ensure that the "Cipher Suite" attribute lists only cipher suites which use FIPS compliant HMAC algorithms. If any cipher suites are listed that use non-FIPS compliant HMAC algorithms, this is a finding.

Fix: F-100829r1_fix

Configure the ProxySG to use only FIPS compliant HMAC algorithms. 1. Log on to the CLI via SSH. 2. Type "enable", enter the enable password. 3. Type "configure terminal" and press "Enter". 4. Type "management-services" and press "Enter", type "edit HTTPS-Console" and press "Enter". 5. Type "view" to display the list of configured cipher suites. 6. Type "attribute cipher-suite" followed by a space-delimited list of only cipher suites from step 5 which use FIPS compliant HMAC algorithms and press "Enter".

c
Symantec ProxySG must terminate all network connections associated with a device management session at the end of the session, or the session must be terminated after 10 minutes of inactivity except to fulfill documented and validated mission requirements.
SC-10 - High - CCI-001133 - V-94713 - SV-104543r1_rule
RMF Control
SC-10
Severity
High
CCI
CCI-001133
Version
SYMP-NM-000310
Vuln IDs
  • V-94713
Rule IDs
  • SV-104543r1_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 Symantec ProxySG. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. By default, when a user logs off of the session all session attributes are terminated. For abruptly terminated sessions, the Keep-alive default is 2 minutes and then the session is terminated and cleans up. This is inherent to the system and cannot be misconfigured.
Checks: C-93903r1_chk

If there is a documented and validated mission requirement which allows the inactivity period to exceed "10" minutes, this is not a finding. Verify the device management session inactivity timeouts are set to "10" minutes. 1. Log on to the Web Management Console. 2. Click Configuration &gt;&gt; Authentication &gt;&gt; Console Access &gt;&gt; Console Account. 3. Confirm that the "Enforce Web auto-logout" and "Enforce CLI auto-logout" options are set to "10" minutes. If Symantec ProxySG is not configured to terminate the management session after "10" minutes of inactivity, this is a finding.

Fix: F-100831r1_fix

Configure the device management session inactivity timeouts to "10" minutes. 1. Log on to the Web Management Console. 2. Click Configuration >> Authentication >> Console Access >> Console Account. 3. Set "Enforce Web auto-logout" and "Enforce CLI auto-logout" to "10" minutes.