{"stig":{"title":"Symantec Edge SWG ALG Security Technical Implementation Guide","version":"1","release":"1"},"checks":[{"vulnId":"V-279166","ruleId":"SV-279166r1170654_rule","severity":"medium","ruleTitle":"The ALG providing user authentication intermediary services must uniquely identify and authenticate nonorganizational users (or processes acting on behalf of nonorganizational users).","description":"Before continuing, the site must follow the configuration steps for adding Common Access Card (CAC) and LDAPS authentication realms and the SSH Console CAC items under SYME-ND-000190.\n\nLack of authentication enables anyone to gain access to the network or possibly a network element that provides opportunity for intruders to compromise resources within the network infrastructure. By identifying and authenticating nonorganizational users, their access to network resources can be restricted accordingly.\n\nNonorganizational users will be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access. Authorization requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of user identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multifactor authentication, some combination thereof.\n\nThis control applies to application layer gateways that provide content filtering and proxy services on network segments (e.g., DMZ) that allow access by nonorganizational users. This requirement focuses on authentication requests to the proxied application for access to destination resources and policy filtering decisions rather than administrator and management functions.\n\nSatisfies: SRG-NET-000169-ALG-000102, SRG-NET-000015-ALG-000016, SRG-NET-000138-ALG-000063, SRG-NET-000138-ALG-000088, SRG-NET-000138-ALG-000089, SRG-NET-000140-ALG-000094, SRG-NET-000147-ALG-000095, SRG-NET-000164-ALG-000100, SRG-NET-000166-ALG-000101, SRG-NET-000018-ALG-000017, SRG-NET-000019-ALG-000018, SRG-NET-000019-ALG-000019, SRG-NET-000400-ALG-000097","checkContent":"In the Edge SWG Web UI, navigate to the Visual Policy Manager (VPM).\n\nIf there is not a Web Access Layer, and the authorization has not been configured on this layer for the proxy users based on the CAC/LDAP authentication realm, this is a finding.\n\nIf there are not specific services restricted to each group, this is a finding.\n\nEnsure there is a CPL layer that includes a client certificate requirement rule; otherwise, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the VPM.\n2. Add a web access layer called \"Web Access Layer\".\n3. Click \"Add a rule.\" \n4. Under \"Source\", left-click and select \"Set\".\n5. Click \"Add a new object\" and select \"Group\".\n6. Enter the full DN of the LDAP group. For example: CN=broadcom.proxyusers.gsg,OU=BROADCOM,DC=dod,DC=mil\n7. Under \"Authentication Realm\", select the CAC Certificate.\n8. Click \"Apply\" and then click \"Set\".\n9. Click \"Service\" and then click \"Set\".\n10. Click \"Add a new object\".\n11. Click \"Client Protocol\", select \"HTTP\", and then click \"Apply and set\".\n12. Under \"Action\", left-click and set to \"Allow\".\n13. Under \"Track\", left-click \"Add a new Object\".\n14. Click \"Event Log\".\n15. Under \"Details\", add the following text: \"$(appliance.name)$(appliance.primary_address)$(c-ip)$(c-port)$(c-uri)$(c-uri-address)$(c-uri-cookie-domain)$(c-uri-extension)$(c-uri-host)$(c-uri-hostname)$(c-uri-path)$(c-ur-pathquery)$(client.address)$(client.certificate.subject)$(client.host)$(client.public_address)$(cs-auth-group)$(cs-categories-policy)$(date)$(user.name)$(user.x509.subject)\"\n16. Under \"Category\", select \"All\".\n17. Under \"Display options\", select \"Both\".\n18. Click \"Apply and set\".\n19. Repeat the above procedure for each service/protocol being proxied with authorization enforcement. For example, ensure HTTPS is selected when doing HTTPS and not HTTP.\n20. Click \"Apply Policy\".\n\n1. Navigate to the top of the VPM and add a new layer. It must be a CPL layer.\n2. Include the following in the layer text:\n<Proxy>\n url.regex=\"ssl://\" authenticate(no)\n\n<Proxy>client.certificate.require(yes)\n     service.name=!(CAC-MC-Notify,HTTPS-Console) authenticate(CAC) authenticate.force(no) authenticate.mode(auto)\n\nNote: The CAC-MC-Notify and HTTPS-Console must match a proxy or reverse service in use. The authenticate(CAC) must represent the Certificate Authentication Realm previously configured.\n\n3. Click \"Apply Policy\".","ccis":["CCI-000804","CCI-000213","CCI-000764","CCI-000766","CCI-001941","CCI-000185","CCI-000187","CCI-001368","CCI-001414","CCI-000197"]},{"vulnId":"V-279167","ruleId":"SV-279167r1170656_rule","severity":"medium","ruleTitle":"The Edge SWG must implement multifactor authentication for remote access to nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access.","description":"For remote access to nonprivileged accounts, one factor of multifactor authentication must be provided by a device separate from the information system gaining access to reduce the likelihood of compromising authentication credentials stored on the system.\n\nBefore continuing, ensure that the Edge SWG was implemented for SYME-ND-000190.\n\nMultifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DOD common access card (CAC).\n\nA privileged account is defined as an information system account with authorizations of a privileged user.\n\nRemote access is access to DOD-nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.\n\nAn example of compliance with this requirement is the use of a one-time password token and PIN coupled with a password; or the use of a CAC/PIV card and PIN coupled with a password.\n\nSatisfies: SRG-NET-000339-ALG-000090, SRG-NET-000500-ALG-000035, SRG-NET-000340-ALG-000091, SRG-NET-000355-ALG-000117, SRG-NET-000370-ALG-000125, SRG-NET-000494-ALG-000029, SRG-NET-000495-ALG-000030, SRG-NET-000496-ALG-000031, SRG-NET-000497-ALG-000032, SRG-NET-000498-ALG-000033, SRG-NET-000499-ALG-000034, SRG-NET-000501-ALG-000036, SRG-NET-000502-ALG-000037, SRG-NET-000503-ALG-000038, SRG-NET-000505-ALG-000039","checkContent":"In the Edge SWG Web UI, navigate to the Visual Policy Manager (VPM).\n\nUnder the configured Web Access Layer, if there are not allow rules for at least HTTP and HTTPS, this is a finding.\n\nIf the allow rules do not have a specific LDAPS group used in the source column, this is a finding.\n\nIf the rule does not have the Track column set to log all access logs, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the VPM.\n2. Under the configured Web Access Layer, add a rule.\n3. Under \"Source\", left-click then click \"Set\".\n4. Click \"Add new object\".\n5. Select \"Group\".\n6. Enter the full Distinguished Name (DN) of the LDAPS group. For example: \"CN=broadcom.proxyusers.gsg,OU=BROADCOM,DC=dod,DC=mil\"\n7. Under \"Authentication Realm\", select the CAC/certificate realm.\n8. Click \"Apply\".\n9. Under \"Service\", left-click then click \"Set\".\n10. Select the \"All HTTPS client\" protocol.\n11. Click \"Apply\".\n12. Under Action, left-click then click \"Set\".\n13. Click \"Allow\", then click \"Apply\".\n14. Under \"Track\", left-click then click \"Set\".\n15. Select the event log that was created previously.\n16. Click \"Apply\".\n17. Repeat the above steps for HTTP instead of HTTPS and add any additional protocols that need to be proxied.\n18. Click \"Apply policy\".","ccis":["CCI-004046","CCI-000172","CCI-002470","CCI-002400"]},{"vulnId":"V-279168","ruleId":"SV-279168r1170614_rule","severity":"medium","ruleTitle":"The Edge SWG must deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).","description":"Ensure a Web Access Policy (under SYME-00-002500) has been created for allow rules or all proxy access will be denied.\n\nA deny-all, permit-by-exception network communications traffic policy ensures only those connections that are essential and approved are allowed.\n\nAs a managed interface, the ALG must block all inbound and outbound network communications traffic to the application being managed and controlled unless a policy filter is installed to explicitly allow the traffic. The allow policy filters must comply with the site's security policy. A deny all, permit by exception network communications traffic policy ensures that only those connections that are essential and approved, are allowed.\n\nThis requirement applies to both inbound and outbound network communications traffic. All inbound and outbound traffic for which the ALG is acting as an intermediary or proxy must be denied by default.","checkContent":"1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Select \"Policy and Policy Settings\".\n\nIf the Default Proxy Policy is set to \"Allow\", this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Select \"Policy and Policy Settings\".\n3. Set the Default Proxy Policy to \"Deny\".\n4. Click \"Apply\", then \"Save\".","ccis":["CCI-001109"]},{"vulnId":"V-279175","ruleId":"SV-279175r1170658_rule","severity":"medium","ruleTitle":"The Edge SWG must display the standard mandatory DOD-approved notice and consent banner before granting access to the network.","description":"Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element.\n\nThe banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-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.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-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.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-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.\"\n \nUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:\n\n\"I've read & consent to terms in IS user agreem't.\"\n\nThis policy only applies to ALGs (e.g., identity management or authentication gateways) that provide user account services as part of the intermediary services.\n\nSatisfies: SRG-NET-000041-ALG-000022, SRG-NET-000042-ALG-000023, SRG-NET-000043-ALG-000024","checkContent":"In the Edge SWG Web UI, navigate to the Visual Policy Manager (VPM).\n\nCheck if there is a CPL layer named \"ProxyTrafficLoginBanner\" and verify it has the correct login banner text; otherwise, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the VPM.\n2. Navigate to the Symantec site: https://knowledge.broadcom.com/external/article/388134.\n3. Download the file \"ProxyTrafficLoginBanner.txt\".\n4. Copy and paste the text into this CPL layer.\n5. Find line 426 as shown below, and replace the hostname of the current Edge SWG being configured.\n\n\"<Proxy> condition=!__is_notify_internal_proxy url.domain=!\"tditwbcsg001.dod.mil\"  ; Guard Rule\"\n\n6. In line 414, replace the service name being used for the HTTPS-console name. By default, it should be \"HTTPS-Console\" and not \"H2-Console\".\n\n[rule] service.name=!H2-Console\n\n7. Click \"Apply Policy\".","ccis":["CCI-000048","CCI-000050","CCI-001384","CCI-001385","CCI-001386","CCI-001387","CCI-001388"]},{"vulnId":"V-279176","ruleId":"SV-279176r1170660_rule","severity":"medium","ruleTitle":"The Edge SWG must limit the number of concurrent sessions to an organization-defined number for all accounts and/or account types.","description":"Network element management includes the ability to control the number of users and user sessions that utilize a network element. Limiting the number of current sessions per user is helpful in limiting risks related to denial-of-service (DoS) attacks.\n\nThis 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 must be the same as the requirements specified for the application for which it serves as intermediary.\n\nThis policy only applies to application gateways/firewalls (e.g., identity management or authentication gateways) that provide user account services as part of the intermediary services.","checkContent":"1. In the Edge SWG Web UI, navigate to the Visual Policy Manager (VPM).\n2. Navigate to the Proxy Auth CPL Layer.\n\nUnder a <Proxy> section, if there is no text that contains a user.login.count, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the VPM.\n2. Navigate to the Proxy Auth CPL Layer.\n3. Under a new <Proxy> section, add the following line. Ensure it is indented:\n    FORCE_DENY user.login.count=4.. user.login.log_out(yes)\n\nNote: Login count is organizationally defined, so \"4\" can be changed to what the site requires.","ccis":["CCI-000054","CCI-001094","CCI-002385","CCI-004866"]},{"vulnId":"V-279177","ruleId":"SV-279177r1170662_rule","severity":"medium","ruleTitle":"The Edge SWG must ensure inbound and outbound traffic is monitored for compliance with remote access security policies.","description":"Automated monitoring of remote access traffic allows organizations to detect cyberattacks and ensure ongoing compliance with remote access policies by inspecting connection activities of remote access capabilities.\n\nRemote access methods include both unencrypted and encrypted traffic (e.g., web portals, web content filter, TLS and webmail). With inbound TLS inspection, the traffic must be inspected prior to being allowed on the enclave's web servers hosting TLS or HTTPS applications. With outbound traffic inspection, traffic must be inspected prior to being forwarded to destinations outside of the enclave, such as external email traffic.\n\nSatisfies: SRG-NET-000061-ALG-000009, SRG-NET-000074-ALG-000043, SRG-NET-000075-ALG-000044, SRG-NET-000076-ALG-000045, SRG-NET-000077-ALG-000046, SRG-NET-000078-ALG-000047, SRG-NET-000079-ALG-000048, SRG-NET-000331-ALG-000041, SRG-NET-000334-ALG-000050, SRG-NET-000402-ALG-000130, SRG-NET-000492-ALG-000027, SRG-NET-000511-ALG-000051, SRG-NET-000513-ALG-000026","checkContent":"1. In the Edge SWG Web UI, navigate to the Visual Policy Manager (VPM).\n2. Navigate to \"Administration and Event Logging\".\n3. Scroll down to \"Syslog Loghosts\".\n\nIf there is no Web Access Layer this is a finding.\n\nIf there is a Web Access Layer, but the Track is not set or not configured, this is a finding.\n\nIf no log hosts are configured, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the VPM.\n2. Select the Web Access Layer.\n3. Click the first block or allow rule.\n4. Left-click \"Track\".\n5. Click \"Set\".\n6. Click \"Add New Object\".\n7. Click \"Event Log\".\n8. Under \"Details\" add the following:\n$(appliance.name)$(appliance.primary_address)$(c-ip)$(c-port)$(c-uri)$(c-uri-address)$(c-uri-cookie-domain)$(c-uri-extension)$(c-uri-host)$(c-uri-hostname)$(c-uri-path)$(c-uri-pathquery)$(client.address)$(client.certificate.subject)$(client.host)$(client.public_address)$(cs-auth-group)$(cs-categories-policy)$(date)$(user.name)$(user.x509.subject)\n\n9. Under \"Category\", click \"All\".\n10. Under \"Display Options\", click \"Both\".\n11. Click \"Apply\".\n12. Repeat these steps for each rule under the Web Access Layer.\n13. Click \"Apply Policy\".\n\n1. In the Edge SWG Web UI, navigate to the Administration tab.\n2. Go to \"Logging and Event Logging\".\n3. Scroll down to \"syslog loghosts\".\n4. Click \"Add Loghost\".\n5. Select \"TLS\".\n6. Enter the hostname of the syslog server.\n7. Enter the port. For TLS, it is normally 6514.\n8. Select the SSL Device Profile that will be used. (Note: The SSL device profile must include the CA certificate chain that signed the certificate of the syslog server if it is different from the ones that signed the web server certificate).","ccis":["CCI-000067","CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-001487","CCI-001919","CCI-001851","CCI-001314","CCI-000172"]},{"vulnId":"V-279178","ruleId":"SV-279178r1170664_rule","severity":"medium","ruleTitle":"The Edge SWG must be configured to comply with the required TLS settings in NIST SP 800-52.","description":"NIST SP 800-52 provides guidance on using the most secure version and configuration of the TLS/SSL protocol. Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks, which exploit vulnerabilities in this protocol.\n\nThis requirement applies to TLS gateways (also known as SSL gateways) and is not applicable to VPN devices. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol, thus are in scope for this requirement. \n\nNIST SP 800-52 sets TLS version 1.1 as a minimum version, thus all versions of SSL are not allowed (including for client negotiation) either on DOD-only or on public-facing servers.","checkContent":"1. In the Edge SWG Web UI, navigate to Configuration and SSL.\n2. Select \"SSL Proxy Settings\".\n3. Scroll down to \"SSL Version Controls\".\n\nIf the Minimum Client Control and Server Control are not set to TLS 1.2, this is a finding.\n\nIf the Maximum Client Control and Server Control are not set to TLS 1.3, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to Configuration and SSL.\n2. Select \"SSL Proxy Settings\".\n3. Scroll down to \"SSL Version Controls\".\n4. Under Client Connection, set the minimum version to \"TLS 1.2\" and maximum version to \"TLS 1.3\".\n5. Under Server Connection, set the minimum version to \"TLS 1.2\" and maximum version to \"TLS 1.3\".\n6. Click \"Save and Apply\".","ccis":["CCI-000068"]},{"vulnId":"V-279180","ruleId":"SV-279180r1170629_rule","severity":"medium","ruleTitle":"The Edge SWG must be configured to remove or disable unrelated or unneeded application proxy services.","description":"Unrelated or unneeded proxy services increase the attack vector and add excessive complexity to the securing of the ALG. Multiple application proxies can be installed on many ALGs. However, proxy types must be limited to related functions. At a minimum, the web and email gateway represent different security domains/trust levels. Organizations should also consider separation of gateways that service the DMZ and the trusted network.\n\nSatisfies: SRG-NET-000131-ALG-000086, SRG-NET-000384-ALG-000136","checkContent":"1. In the Edge SWG Web UI, navigate to Configuration.\n2. Go to \"Services and Proxy Services\".\n\nUnder \"Proxy Services\", if there are more than HTTP, HTTPS, CAC-Mc-Notify, and any other required reverse proxy (e.g. HTTP/2 reverse proxy like H2-Console), this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to Configuration.\n2. Go to \"Services and Proxy Services\".\n3. Under \"Proxy Services\", remove all services like FTP, etc., other than HTTP, HTTPS, CAC-Mc-Notify, and any other required reverse proxy (e.g., HTTP/2 reverse proxy like H2-Console).\n4. Only authorized proxy service must be configured for Intercept, and any service not in use must be removed, not just set to Bypass.","ccis":["CCI-000381","CCI-002683"]},{"vulnId":"V-279187","ruleId":"SV-279187r1170651_rule","severity":"medium","ruleTitle":"In the event of a system failure of the ALG function, the Edge SWG must save diagnostic information, log system messages, and load the most current security policies, rules, and signatures when restarted.","description":"Failure in a secure state can address safety or security in accordance with the mission needs of the organization. Failure to a secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving state information helps to facilitate the restart of the ALG application and a return to the operational mode with less disruption.\n\nThis requirement applies to a failure of the ALG function rather than the device or operating system as a whole, which is addressed in the Network Device Management SRG.\n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.","checkContent":"1. In the Edge SWG Web UI, navigate to the Administration tab.\n2. Go to \"Logging and Access Logging\".\n3. Scroll down to \"Logs\" and click \"Edit\" on the Main log.\n\nIf there is no upload client configured, this is a finding.\n\nUnder upload schedule, if the is a schedule for \"Periodically\" is not selected, then this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the Administration tab.\n2. Go to \"Logging and Access Logging\".\n3. Scroll down to \"Logs\" and click \"Edit\" on the Main log.\n4. Under \"Upload Client\", select \"SCP\".\n5. Click \"Open Settings\" and configure the following variables: host, port, full path, username, and password.\n6. Click \"Apply and Test Upload\". If there are connection issues, fix these before continuing.\n7. Under \"Transmission Parameters\", select a signing certificate. This signing certificate must be the certificate used for SSL Proxying issued by the DOD WCF Certificate Authority (CA).\n8. Check \"Text File\".\n9. Under \"Upload Schedule\" select \"Periodically\".\n10. Then, choose 5 seconds between connect attempts.\n11. Select the \"Daily interval\" and select a time that works for the site SCP server.\n12. Click \"Upload Now\" to test if the upload works. If there are connection issues, fix these before continuing.\n13. Click \"Apply and Save\".","ccis":["CCI-001665"]},{"vulnId":"V-279194","ruleId":"SV-279194r1170667_rule","severity":"medium","ruleTitle":"The Edge SWG must generate error messages that provide the information necessary for corrective actions without revealing information that could be exploited by adversaries.","description":"Providing too much information in error messages risks compromising the data and security of the application and system.\n\nOrganizations carefully consider the structure/content of error messages. The required information within error messages will vary based on the protocol and error condition. Information that could be exploited by adversaries includes, for example, ICMP messages that reveal the use of firewalls or access-control lists.","checkContent":"1. Log in to the Edge SWG SSH CLI. \n2. Enter \"enable\".\n3. Enter \"show exceptions\". \n\nIf there are no user-define d exceptions, this is finding.\n\nIn the Edge SWG Web UI, navigate to the VPM. \n\nUnder the Web Access Layer, for the Action on disallowed content, if there is no User-Defined exception implemented, this is a finding.","fixText":"These procedures will create a user-defined exception page that will show only necessary errors to the proxy user with specific contact information.\n1. Log in to the Edge SWG SSH CLI.\n2. Enter \"enable\" and \"configure terminal\".\n3. Enter \"exceptions\".\n4. Enter \"create DOD-BLOCKS\".\n5. Enter \"edit DOD-BLOCKS\".\n6. Enter \"inline format EOF\".\n7. Copy and paste the data below exactly as it appears and edit items such as Organization, email addresses, etc.:\n\n<!DOCTYPE html>\n<html> \n<head>\n<title>Denied Access Policy </title>\n<meta name= \"author\" content = \"SAMPLE ORGANIZATION\" >\n<meta name=\"description\" content = \"Denied Access Policy\" >\n<meta name=\"category\" content = \"$(exception.category)\">\n</head>\n<body>\n<center>\n<p>\n<font face = \"Arial, Helvetica, sans-serif\" size = \"4\" color = \"Red\" ><b>You have reached a website that is currently being blocked due to malicious activity and/or current acceptable use policies.</font><br>\n<font face= \"Arial, Helvetica, sans-serif\" size = \"4\" color = \"Red\">INTERNET USAGE IS MONITORED AND LOGGED.</font><br>\n<font face = \"Arial, Helvetica, sans-serif\" size = \"3\" color = \"Red\"><b>Your IP address: $(client.address) <br>Your username:  $(user.name) <br> Banned Website: $(url) <br> Website IP address: $(url.address)<br>Banned Category: $(category) <br> Rule Name: $(exception.id)</b></font><br>\n<br>\n<font face = \"Arial, Helvetica, sans-serif\" size = \"4\" color = \"red\" > This has been reported by:  $(proxy.name)<font><br>\n<A href='mailto:email@mail.mil?subject=Barred web page $(url),IP address: $(client.address)&body=IP address:$(client.address)%0DYour username:$(user.name)%0DBanned Website:$(url)%0DWebsite IP address:$(url.address)%0DBanned Category:$(category)%0DRule Name:$(exception.id)' > If you have further questions or require assistance click here to send an email <br> to your Information Management Office (IMO) or ORGANIZATION Cyber Security & Risk Management</a></font></a></font>\n</p>\n</center>\n</body>\n</html>\nEOF\n\n8. After the EOF, click \"Enter\".\n9. Enter \"http-code 403\".\n\n1. In the Edge SWG Web UI, navigate to the VPM.\n2. Under the Web Access Layer for the Action on disallowed content, click \"Set and Add New Object\".\n3. Select \"Return Exception\".\n4. Enter a name and select \"User-defined exception\".\n5. Select the previously created user-defined exception.\n6. Check the box for \"Force exception even if later policy would allow request\".\n7. Click \"Set\" and repeat steps for other services being proxied.\n8. Click \"Apply Policy\".","ccis":["CCI-001312"]},{"vulnId":"V-279203","ruleId":"SV-279203r1170670_rule","severity":"medium","ruleTitle":"The Edge SWG must control remote access methods.","description":"Remote access devices, such as those providing remote access to network devices and information systems, lack automated control capabilities, increase risk and make remote user access management difficult. \n\nRemote access is access to DOD-nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include broadband and wireless connections, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies).\n\nThis requirement applies to ALGs providing remote access proxy services as part of its intermediary services (e.g., OWA or TLS gateway). ALGs that proxy remote access must be capable of taking enforcement action (i.e., blocking, restricting, or forwarding to an enforcement mechanism) if traffic monitoring reveals unauthorized activity.\n\nSatisfies: SRG-NET-000313-ALG-000010, SRG-NET-000319-ALG-000153, SRG-NET-000364-ALG-000122, SRG-NET-000383-ALG-000135, SRG-NET-000385-ALG-000137, SRG-NET-000385-ALG-000138, SRG-NET-000390-ALG-000139, SRG-NET-000391-ALG-000140, SRG-NET-000392-ALG-000141, SRG-NET-000392-ALG-000142, SRG-NET-000392-ALG-000143, SRG-NET-000392-ALG-000147, SRG-NET-000392-ALG-000148","checkContent":"1. In the Edge SWG Web UI, navigate to the Administration tab.\n2. Click \"Data and Cloud Services\", then \"Content Filtering\".\n3. If BlueCoat Content Filtering is disabled, this is a finding.\n4. Click \"BlueCoat\". \n\nIf the Lookup Mode is not set to \"Always\", this is a finding.\n\n1. In the Edge SWG Web UI, navigate to the VPM.\n2. Go to the Web Access Layer.\n\nIf there are no URL filtering rules created, this is a finding.\n\nIf there is a URL filtering list and no categories are selected, this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the Administration tab.\n2. Click \"Data and Cloud Services\", then \"Content Filtering\".\n3. Enable BlueCoat Content Filtering.\n4. Click \"BlueCoat\" and check the box for \"Always\" under \"Lookup Mode\".\n5. Test the download. If the URL cannot be reached, troubleshoot before proceeding to determine if there are networking, reachability, or routing issues.\n\n1. In the Edge SWG Web UI, navigate to the VPM.\n2. Go to the Web Access Layer.\n3. Create a URL filter list rule if one has not been created, click \"Add Rule\".\n4. For source use \"Any\".\n5. Under \"Destination\", left-click and then click \"Set\".\n6. Click \"Add new Object and Request URL Category\".\n7. Enter a name and click the \"BlueCoat\" area.\n8. Click each category that users will be blocked from accessing, then click \"Apply and Set\".\n9. Under Service, click the \"All HTTP\" client protocol.\n10. Click \"Set\".\n11. Under \"Action\", click the \"DOD-BLOCK\" exception page previously created.\n12. Under \"Track\", click the EventLog tracking previously created.\n13. Repeat these steps for all other client protocol services for which forward proxying for users will be completed.\n14. Click \"Apply Policy\".","ccis":["CCI-002314","CCI-002347","CCI-002403","CCI-002656","CCI-002684","CCI-002661","CCI-002662","CCI-002664"]},{"vulnId":"V-279216","ruleId":"SV-279216r1170672_rule","severity":"medium","ruleTitle":"The Edge SWG providing user authentication intermediary services must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.","description":"Without reauthentication, users may access resources or perform tasks for which they do not have authorization.\n\nIn addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances: \n- When authenticators change.\n- When roles change.\n- When security categories of information systems change.\n- When the execution of privileged functions occurs.\n- After a fixed period of time.\n- Periodically.\n\nWithin the DOD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.\n\nThis requirement only applies to components for which this is specific to the function of the device or has the concept of user authentication (e.g., VPN or ALG capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management).\n\nSatisfies: SRG-NET-000337-ALG-000096, SRG-NET-000344-ALG-000098","checkContent":"1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Go to \"Authentication Reams and Domains\".\n3. Select the \"CAC/Certificate\" realm.\n4. Under \"Advanced Setting\", click \"Show\".\n\nIf the setting \"Use the same refresh time for all\" is not checked, this is a finding.\n\nIf it is checked, and the \"Surrogate refresh time\" is not set to at least \"600 seconds\", this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Go to \"Authentication Reams and Domains\".\n3. Select the \"CAC/Certificate\" realm.\n4. Under \"Advanced Setting\", click \"Show\".\n5. Check the setting \"Use the same refresh time for all\".\n6. Under \"Surrogate refresh time\" set it to at least \"600 seconds\", but the site policies may require less.\n7. Click \"Apply and Save\".","ccis":["CCI-002038","CCI-002007"]},{"vulnId":"V-279217","ruleId":"SV-279217r1170674_rule","severity":"medium","ruleTitle":"The Edge SWG using PKI-based user authentication must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.","description":"Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).\n\nThe intent of this requirement is to require support for a secondary certificate validation method using a locally cached revocation data, such as Certificate Revocation List (CRL), in case access to OCSP (required by CCI-000185) is not available. Based on a risk assessment, an alternate mitigation is to configure the system to deny access when revocation data is unavailable. \n\nThis requirement applies to ALGs that provide user authentication intermediary services (e.g., authentication gateway or TLS gateway). This does not apply to authentication for the purpose of configuring the device itself (device management).","checkContent":"1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Navigate to SSL and OCSP.\n\nIf a responder is not configured, this is a finding.\n\nIf a responder is configured, but the \"Response Cache TTL\" is set to \"0\", this is a finding.\n\nIf there are any items checked under \"Ignore Settings\", this is a finding.","fixText":"1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Go to SSL and OCSP.\n3. Click \"Add a Responder\".\n4. Under URL either set it to \"from certificate\" if routing to the DODIN is allowed, or if it is not, click the other items and add the local site's URL.\n5. Under \"Issuer CCL\", select the one that includes all DOD ID CAs.\n6. Under the \"Response Cache TTL\" is set it to either \"from OCSP response\" or to a value of 1 or more.\n7. Ensure there are no Ignore Settings checked or enabled.","ccis":["CCI-004068"]},{"vulnId":"V-279219","ruleId":"SV-279219r1170647_rule","severity":"medium","ruleTitle":"The Edge must implement load balancing to limit the effects of known and unknown types of denial-of-service (DoS) attacks.","description":"If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Load balancing provides service redundancy, which reduces the susceptibility of the ALG to many DoS attacks.\n\nThe ALG must be configured to prevent or mitigate the impact on network availability and traffic flow of DoS attacks that have occurred or are ongoing.\n\nThis requirement applies to the network traffic functionality of the device as it pertains to handling network traffic. Some types of attacks may be specialized to certain network technologies, functions, or services. For each technology, known and potential DoS attacks must be identified and solutions for each type implemented.","checkContent":"Implementation of multiple Edge SWG nodes must be done in a transparent proxy using an ethernet bridge. This is done using the Symantec Integrates Secure Gateway (ISG).\n\n1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Go to \"Network and Adapters\".\n3. Scroll down to the \"Bridge\" section, if a bridge is not configured, this is a finding.\n\nIf a bridge is configured but the two network interfaces on the ISG are not added, this is a finding.","fixText":"Implementation of multiple Edge SWG nodes must be done in a transparent proxy using an ethernet bridge. This is done using the Symantec Integrates Secure Gateway (ISG).\n\n1. Log in to the ISG SSH CLI.\n2. Enter \"enable\" and \"configure terminal\".\n3. Enter \"bridge view\". There should be no interfaces added to a bridge.\n4. Enter \"bridge edit passthru-2:0 mode fail-closed\".\n5. Create the network definition and type \"network-definition create <NAME>\".\n6. Add the bridge to the network definition and type \"network-definition edit <NAME> add mode reserved bridges passthru-2:0\".\n7. Add the definition to the Edge SWG image by typing: \"applications edit <SWG NAME> network-definition <NAME>\".\n8. Start the image by entering the command \"applications start<SWG NAME>\".\n9. Repeat these steps for any other Edge SWGs being added for high availability. \n\n1. In the Edge SWG Web UI, navigate to the Configuration tab.\n2. Go to \"Network and Adapters\".\n3. Scroll down to the Bridge section and click the \"pass-through-2:0\" bridge.\n4. Click \"Add Interface\".\n5. Find the two interfaces being used and add them.\n6. Click \"Apply and Save\".","ccis":["CCI-002385"]},{"vulnId":"V-279222","ruleId":"SV-279222r1170676_rule","severity":"medium","ruleTitle":"The Edge SWG must fail securely in the event of an operational failure.","description":"If a boundary protection device fails in an unsecure manner (open), information external to the boundary protection device may enter, or the device may permit unauthorized information release.\n\nSecure failure ensures when a boundary control device fails, all traffic will be subsequently denied.\n\nFail secure is a condition achieved by employing information system mechanisms to ensure, in the event of operational failures of boundary protection devices at managed interfaces (e.g., routers, firewalls, guards, and application gateways residing on protected subnetworks commonly referred to as demilitarized zones), information systems do not enter into unsecure states where intended security properties no longer hold.","checkContent":"1. Log in to the Integrated Secure Gateway (ISG) SSH CLI.\n2. Enter \"enable\" and \"configure terminal\".\n3. Enter \"bridge view\".\n\nIf the mode for the bridge in use does not state \"fail-closed\", this is a finding.","fixText":"1. Log in to the Integrated Secure Gateway (ISG) SSH CLI.\n2. Enter \"enable\" and \"configure terminal\".\n3. Enter \"bridge view\".\n4. Find the bridge in use for the Edge SWG, e.g., \"passthru-2:0\".\n5. Enter \"bridge edit passthru-2:0 mode fail-closed\".","ccis":["CCI-001126"]}]}