STIGViewer Support

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.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-279187SYME-00-005900SV-279187r1170651_ruleCCI-001665medium
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. This 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. Since 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.
STIGDate
Symantec Edge SWG ALG Security Technical Implementation Guide2025-12-16

Related Frameworks

1 mapping across 4 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (9) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

BCD-01Business Continuity Management System (BCMS)
1.00
CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
DCH-01Data Protection
1.00
IAC-21Least Privilege
1.00
SEA-01Secure Engineering Principles
1.00
SEA-01.2Achieving Resilience Requirements
1.00
SEA-02Alignment With Enterprise Architecture
1.00
SEA-07.2Fail Secure
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (11) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AU-12Audit Record Generation
1.00
AU-12(3)Changes by Authorized Individuals
1.00
AU-14(1)System Start-up
1.00
AU-3Content of Audit Records
1.00
AU-3(1)Additional Audit Information
1.00
AU-6(4)Central Review and Analysis
1.00
CM-7(2)Prevent Program Execution
1.00
SC-24Fail in Known State
1.00
SC-7Boundary Protection
1.00
SC-7(5)Deny by Default — Allow by Exception
1.00

+1 more (top 10 by confidence shown)

CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

13 NICE work roles and 8 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-279187r1170651_chk)

1. In the Edge SWG Web UI, navigate to the Administration tab. 2. Go to "Logging and Access Logging". 3. Scroll down to "Logs" and click "Edit" on the Main log. If there is no upload client configured, this is a finding. Under upload schedule, if the is a schedule for "Periodically" is not selected, then this is a finding.

Fix Text (F-83640r1170631_fix)

1. In the Edge SWG Web UI, navigate to the Administration tab. 2. Go to "Logging and Access Logging". 3. Scroll down to "Logs" and click "Edit" on the Main log. 4. Under "Upload Client", select "SCP". 5. Click "Open Settings" and configure the following variables: host, port, full path, username, and password. 6. Click "Apply and Test Upload". If there are connection issues, fix these before continuing. 7. 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). 8. Check "Text File". 9. Under "Upload Schedule" select "Periodically". 10. Then, choose 5 seconds between connect attempts. 11. Select the "Daily interval" and select a time that works for the site SCP server. 12. Click "Upload Now" to test if the upload works. If there are connection issues, fix these before continuing. 13. Click "Apply and Save".