Overview
Security Technical Implementation Guides (STIGs) are critical for ensuring that organizational devices accessing the Department of Defense Information Networks (DODIN) meet stringent security requirements. The NQE STIG compliance check makes it easier to validate that device configurations are compliant with STIG standards and verify those configurations remain compliant with each snapshot. STIG compliance involves a comprehensive list of requirements ensuring proper configuration of authentication, logging, network time protocol (NTP), and management plane. These requirements can vary significantly depending on the device type and vendor, with different configurations needed for everything from backbone routers and campus layer switches, to VPN concentrators. Given the complexity and variety of these requirements, maintaining compliance can be a daunting task. This NQE solution provides comprehensive auditing capabilities for STIG compliance as well as extensibility to validate organizational directives.
Results
- The STIG compliance NQE and dashboard provides one place where users can quickly see compliance statuses and identify issues, making it easier to confirm compliance.
- It simplifies checks by confirming the presence of exact configuration lines in devices and offers guidance on more complex functional STIG requirements, helping not only ensure STIG compliance but offer additional flexibility for custom compliance requirements.
- Customers find immense value in this solution because it significantly reduces the manpower and resources needed for manual auditing and script creation. Moreover, it ensures that organizations stay up-to-date with the ever-evolving STIG standards by providing regular updates and compliance checks.
Solution
To address this challenge, we developed a comprehensive solution that aggregates high and medium severity STIG checks into an easily accessible platform. This NQE solution identifies compliance violations as defined by STIG standards, helping organizations establish controls and governance to secure their networks. Customization options allow users to input domain-specific information for functional checks, and a dashboard provides a clear overview of key performance indicators (KPIs) related to compliance. This includes both STIG guidelines and organizational directives. By offering precise, updated, and comprehensive STIG compliance checks, our solution helps organizations maintain high security standards with minimal effort. These NQEs currently support Cisco and Juniper devices.
Example dashboard view
Where to find the STIG Compliance NQEs?
You will find the STIG compliance check NQEs in the FWD.app NQE Library: Forward Library > Security > STIGs >
Sample STIG NQE:
/**
* @intent The Cisco ASA must be configured to filter outbound traffic, allowing only
authorized ports and services. Severity: high
* @description Information flow control regulates where information is allowed to travel within
a network and between interconnected networks. Blocking or restricting detected
harmful or suspicious communications between interconnected networks enforces
approved authorizations for controlling the flow of traffic.
The firewall that
filters traffic outbound to interconnected networks with different security
policies must be configured to permit or block traffic based on
organization-defined traffic authorizations.
*
* Severity: high
* Operating System: cisco_asa
* Device Type: NA
* Version/Revision: V1R4
* Group_Title: SRG-NET-000019-FW-000003
* Vulnerability ID: V-239852
* Rule ID: SV-239852r665842_rule
* Rule Version: CASA-FW-000010
* Legacy Vulnerabilities: b"CCI-001414"]
*/
import "Security/STIGs/Cisco/Utils";
// AUTO-GENERATED ABOVE HERE
patternIface = ```
interface
nameif {ifaceName:string}
security-level
ip address
```;
patternAccessGroup = ```
access-group {accessGroupName:string} in interface {ifaceName:string}
```;
patternAcl = ```
access-list {accessGroupName:string} {(!("eq" | "range")string)* } {"eq" | "range"} {string*}
```;
getIfaceNames(matches) =
foreach match in matches
select distinct match.data.ifaceName
;
haveInvalidAcl(config) =
length((foreach match in blockMatches(config, patternAccessGroup) select distinct match.data.accessGroupName)
- (foreach match in blockMatches(config, patternAcl) select distinct match.data.accessGroupName)) > 0;
isVulnerable(params, config) = length(getIfaceNames(blockMatches(config, patternIface)) -
getIfaceNames(blockMatches(config, patternAccessGroup))) > 0
|| haveInvalidAcl(config);
// AUTO-GENERATED BELOW HERE
checkContent = """
Review the ASA configuration to determine if it only permits outbound traffic
using authorized ports and services.
Step 1: Verify that an ingress ACL has
been applied to all internal interfaces as shown in the example below.
interface GigabitEthernet0/0
nameif INSIDE
security-level 100
ip address
10.1.11.1 255.255.255.0
…
…
…
access-group INSIDE _IN in interface INSIDE
Step
2: Verify that the ingress ACL only allows outbound traffic using authorized
ports and services as shown in the example below.
access-list INSIDE _IN
extended permit tcp any any eq www
access-list INSIDE _IN extended permit tcp
any any eq https
access-list INSIDE _IN extended permit tcp any any eq
…
access-list INSIDE _IN extended deny ip any any log
If the ASA is not
configured to only allow outbound traffic using authorized ports and services,
this is a finding.
""";
fixText = """
Step 1: Configure the ingress ACL similar to the example below.
ASA(config)#
access-list INSIDE_INextended permit tcp any any eq https
ASA(config)#
access-list INSIDE_INextended permit tcp any any eq http
ASA(config)#
access-list INSIDE_INextended permit tcp any any eq …
ASA(config)# access-list
INSIDE_INextended deny ip any any log
Step 2: Apply the ACL inbound on
all internal interfaces as shown in the example below.
ASA(config)#
access-group INSIDE_IN in interface INSIDE
ASA(config)# end
""";
intent = """
The Cisco ASA must be configured to filter outbound traffic, allowing only
authorized ports and services.
""";
description = """
Information flow control regulates where information is allowed to travel within
a network and between interconnected networks. Blocking or restricting detected
harmful or suspicious communications between interconnected networks enforces
approved authorizations for controlling the flow of traffic.
The firewall that
filters traffic outbound to interconnected networks with different security
policies must be configured to permit or block traffic based on
organization-defined traffic authorizations.
""";
ruleData =
{ severity: "1 - high",
intent,
description,
checkContent,
fixText,
ruleVersion: "CASA-FW-000010",
vulnerabilityId: "V-239852",
skipped: false,
};
export ruleDataV239852 = ruleData;
export isVulnerableV239852(config: List<ConfigLine>) = isVulnerable({}, config);
f(params) =
foreach device in network.devices
where isPresent(device.files.config)
where device.platform.os == OS.ASA
select {
violation: isVulnerable(params, device.files.config),
Device: device.name,
OS_Version: device.platform.osVersion,
Model: device.platform.model,
Mgmt_IPs: device.platform.managementIps,
};
// AUTO GENERATED ABOVE HERE
g() = f({});
g()
