What changed in Fortinet FortiGate Firewall STIG V1R5V1R5 changes

Check text

If FortiGate is not configured to support VPN access, this requirement is Not Applicable. Log in to the FortiGate GUI with Super- or Firewall Policy-Admin privilege. 1. Click "Policy and Objects". 2. Click "IPv4 or IPv6 Policy". 3. Verify all VPN-related policies are configured with organization-defined filtering rules. 4. For each VPN-related policy, verify the logging option is configured to log All Sessions (for most verbose logging). If there are no VPN policies configured with organization-defined filtering rules, this is a finding.

Fix text

This fix can be performed on the FortiGate GUI or on the CLI. Log in to the FortiGate GUI with Super- or Firewall Policy-Admin privilege. 1. Click "Policy and Objects". 2. Click "IPv4 or IPv6 Policy". 3. Click "+Create New" to configure new ingress and egress SSL-VPN- or IPSec-VPN-related policies that meet the organization-defined filtering rules. 4. Configure Logging Options to log All Sessions (for most verbose logging). 5. Confirm each created Policy is Enabled. 6. Click "OK". or 1. Open a CLI console, via SSH or available from the GUI. 2. Run the following command: # config firewall policy # edit 0 # set srcintf {vpn_interface} # set dstintf {interface_1} # set srcaddr {address_a} # set dstaddr {address_b} # set schedule {always} # set service {services required by site policy} # set action {accept} # set logtraffic enable # next # end 3. Create opposite (ingress or egress) policy as required. The {} indicate the object is defined by the organization policy.

Discussion

Remote access devices (such as those providing remote access to network devices and information systems) that lack automated capabilities increase risk and make remote user access management difficult at best. Remote access is access to DoDDoW non-public information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network. Automated monitoring of remote access sessions allows organizations to detect cyberattacks and ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities from a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets).

V-234134 in V1R5

Check text

Verify at least two logging options are configured. It can be any combination of local and/or remote logging. Via the GUI: LoginLog in via the FortiGate GUI with super-admin privileges. -1. Navigate to "Log and Report". -2. Navigate to "Log Settings". -3. Verify the FortiGate Local Log disk settings. -4. Verify the Remote and Archiving settings. or Via the CLI: Open a CLI console via SSH or from the "CLI Console" button in the GUI. Run the following commands to verify which logging settings are enabled: # show full-configuration log disk setting | grep -i 'status1|diskfull' - The output should indicate enabled. # show full-configuration log fortianalyzer setting | grep -i 'status1|server' # show full-configuration log fortianalyzer2 setting | grep -i 'status1|server' # show full-configuration log fortianalyzer3 setting | grep -i 'status1|server' # show full-configuration log syslogd setting | grep -i 'status1|server' # show full-configuration log syslogd2 setting | grep -i 'status1|server' # show full-configuration log syslogd3 setting | grep -i 'status1|server' # show full-configuration log syslogd4 setting | grep -i 'status1|server' - The output should indicate enabled and an IP address. If the FortiGate is not logging to at least two locations (local and remote OR remote(x2) only), this is a finding.

Fix text

For audit log resilience, it is required to log to the local FortiGate disk and a central audit server, or two central audit servers. To do this, log in to the FortiGate GUI with Super-Admin privilege. 1. Click "Log and Report". 2. Click "Log Settings". 3. For Local Log setting options, toggle the Disk setting to right. To add a syslog server: 51. For Remote Logging and Archiving, toggle the Send logs to syslog setting and enter the appropriate IP address. 62. Click "Apply" to save the settings. or 1. Open a CLI console, via SSH or available from the GUI. 2. Run the following command: # config log disk setting # set status enable # set diskfull overwrite # end # config log syslogd setting # set status enable # set server {IP Address} # set mode reliable # end

Discussion

It is critical that when the network element is at risk of failing to process traffic logs as required, it takes action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend on the nature of the failure mode. In accordance with DoDDoW policy, the traffic log must be sent to a central audit server. When logging functions are lost, system processing cannot be shut down because firewall availability is an overriding concern given the role of the firewall in the enterprise. The system should either be configured to log events to an alternative server or queue log records locally. Upon restoration of the connection to the central audit server, action should be taken to synchronize the local log data with the central audit server. If the central audit server uses User Datagram Protocol (UDP) communications instead of a connection-oriented protocol such as TCP, a method for detecting a lost connection must be implemented.

V-234140 in V1R5

Check text

Log in to the FortiGate GUI with Super-Admin privilege. 1. Click "Log and Report". 2. Click "Log Settings". 3. Under Remote Logging and Archiving, verify FortiAnalyzer and/or syslog settings are enabled and configured with IP addresses of central FortiAnalyzer or Syslog server(s). or Log in to the FortiGate GUI with Super-Admin privilege. 1. Open a CLI console, via SSH or available from the GUI. 2. Run the following command: # show full-configuration log syslogd setting | grep -i status Check output for: set status enable 3. Run the following command: # show full-configuration log fortianalyzer setting | grep -i status check output for: set status enable If the FortiGate is not configured to send traffic logs to a central audit server, this is a finding.

Fix text

Log in to the FortiGate GUI with Super-Admin privilege. 1. Click "Log and Report". 2. Click "Log Settings". 3. Go to Remote Logging and Archiving. If using FortiAnalyzer: 41. Toggle Send logs to FortiAnalyzer/FortiManager to the right. 52. Configure FortiAnalyzer/FortiManager with designated IP address. 63. Configure Upload Option, SSL encrypt log transmission and Allow access to FortiGate REST API per the organizational requirement. If using a central syslog server: 71. Toggle Send logs to syslog to the right. 82. Configure syslog settings with designated IP Address/FQDN. 93. Click "Apply". or Log in to the FortiGate GUI with Super-Admin privilege. Open a CLI console, via SSH or available from the GUI. If using FortiAnalyzer, run the following command: # config log fortianalyzer setting # set status enable # set server {IP address} # end If using central syslog Server, run the following command: # config log syslogd setting # set status enable # set server {IP address} # end

Discussion

Without the ability to centrally manage the content captured in the traffic log entries, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The DoDDoW requires centralized management of all network component audit record content. Network components requiring centralized traffic log management must have the ability to support centralized management. The content captured in traffic log entries must be managed from a central location (necessitating automation). Centralized management of traffic log 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 is configured on the firewall. If the product inherently has the ability to store log records locally, the local log must also be secured. However, this requirement is not met since it calls for a use of a central audit server.

V-234149 in V1R5

Discussion

Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. The firewall generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs), which require real-time alerts. These messages should include a severity-level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoDDoW has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The firewall must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

V-234158 in V1R5