Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

SDN Controller Security Requirements Guide

V1R2 · · · Released 24 Apr 2020 · 31 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Requirements 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.
Digest of Updates vs. V1R1 · 12 Jul 2018 +1 ✎ 4

Comparison against the immediately-prior release (V1R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 1

  • V-100101 Medium The SDN controller must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.

Content changes 4

  • V-80763 Medium checkfix The SDN controller must be configured to produce audit records containing information to establish where the events occurred.
  • V-80765 Medium checkfix The SDN controller must be configured to produce audit records containing information to establish the source of the events.
  • V-80779 Medium description The SDN controller must be configured to only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations.
  • V-80797 Medium description SDN controller must be configured to forward traffic based on security requirements.
Sort by
b
The SDN controller must be configured to enforce approved authorizations for access to system resources in accordance with applicable access control policies.
AC-3 - Medium - CCI-000213 - V-80755 - SV-95465r1_rule
RMF Control
AC-3
Severity
M
CCI
CCI-000213
Version
SRG-NET-000015-SDN-000010
Vuln IDs
  • V-80755
Rule IDs
  • SV-95465r1_rule
To mitigate the risk of unauthorized access to system resources within the SDN framework, 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. With a multi-tenant implementation, customers share the network infrastructure and services while they are logically isolated from each other. The controller can provide an abstract view of a virtual network that belongs to each tenant. Hence, a northbound multi-tenancy deployment provides tenants with means to manage and monitor their own virtual networks via a northbound API. The behavior of tenants and their end users should be strictly controlled according to pre-defined access policies. Role-based access control (RBAC) can be implemented to allow tenants to modify configuration and parameters of the SDN framework that they own and control, while prohibiting access to objects they do not own. Tenants have a self-service model by which they can perform configuration changes, read statistics, and monitor logs that apply only to them. To ensure tenant separation while preserving the integrity and stability of the SDN controller, it is imperative that tenant access to resources within the SDN framework is strictly controlled according to access control policies.
Checks: C-80491r1_chk

Review the SDN configuration and verify that RBAC rules have been implemented to control access to system resources within the SDN framework. If the SDN controller is not configured to enforce approved authorizations for access to system resources, this is a finding.

Fix: F-87609r1_fix

Configure the SDN controller to utilize RBAC rules to enforce approved authorizations for access to system resources.

b
The SDN controller must be configured to enforce approved authorizations for controlling the flow of traffic within the network based on organization-defined information flow control policies.
AC-4 - Medium - CCI-001368 - V-80757 - SV-95467r1_rule
RMF Control
AC-4
Severity
M
CCI
CCI-001368
Version
SRG-NET-000018-SDN-000015
Vuln IDs
  • V-80757
Rule IDs
  • SV-95467r1_rule
Unrestricted traffic may contain malicious traffic which poses a threat to an enclave or data center. Additionally, unrestricted traffic may transit a network consuming bandwidth and network node resources. Access control policies and access control lists implemented on routers and switches can control the flow of network traffic by ensuring that the flow of traffic is only allowed from authorized sources to authorized destinations. Furthermore, the SDN controller provides flow rules to the SDN-enabled routers and switches to populate their forwarding tables. SDN-enabled routers and switches will drop packets for flows that are not permitted by the controller. Also when reactive flow setup occurs (switch has no flow entry in the forwarding table for specific flow), the controller can respond to the switch to drop the packet or provide the device with a new flow entry. It is imperative that both proactive and reactive flow setup must be implemented based on organization-defined information flow control policies.
Checks: C-80493r1_chk

Review the SDN controller configuration to determine if it creates and distributes forwarding table flow entries based on organization-defined information flow control policies. The implementation could be driven by a service application via the northbound API that contains the flow control policy and forwarding rules. If the SDN controller is not configured to enforce approved authorizations for controlling the flow of traffic within the network based on organization-defined information flow control policies, this is a finding.

Fix: F-87611r1_fix

Configure the SDN controller to create and distribute forwarding table flow entries based on organization-defined information flow control policies. The implementation could be driven by a service application via the northbound API that contains the flow control policy and forwarding rules.

b
The SDN controller must be configured to produce audit records containing information to establish what type of events occurred.
AU-3 - Medium - CCI-000130 - V-80759 - SV-95469r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
SRG-NET-000074-SDN-000120
Vuln IDs
  • V-80759
Rule IDs
  • SV-95469r1_rule
Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the network element logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured network element.
Checks: C-80495r1_chk

Review the SDN controller configuration to determine if the audit records will note the type of event that is being logged. If the SDN controller is not configured to produce audit records containing information to establish what type of events occurred, this is a finding.

Fix: F-87613r1_fix

Configure the SDN controller to include the type of event in the log records.

b
The SDN controller must be configured to produce audit records containing information to establish when the events occurred.
AU-3 - Medium - CCI-000131 - V-80761 - SV-95471r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000131
Version
SRG-NET-000075-SDN-000125
Vuln IDs
  • V-80761
Rule IDs
  • SV-95471r1_rule
Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment, and provide forensic analysis of network traffic patterns, it is essential for security personnel to know when (i.e., date and time) flow control events occurred within the infrastructure.
Checks: C-80497r1_chk

Review the SDN controller configuration to determine if the audit records will note the date and time of the event that is being logged. If the SDN controller is not configured to produce audit records containing information to establish when (i.e., date and time) the events occurred, this is a finding.

Fix: F-87615r2_fix

Configure the SDN controller to include the date and time in the log records.

b
The SDN controller must be configured to produce audit records containing information to establish where the events occurred.
AU-3 - Medium - CCI-000132 - V-80763 - SV-95473r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000132
Version
SRG-NET-000076-SDN-000130
Vuln IDs
  • V-80763
Rule IDs
  • SV-95473r1_rule
Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know where (e.g., interface, node, source IP, etc.) events occurred. Associating information about where the event occurred within the network provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured network element.
Checks: C-80499r2_chk

Review the SDN controller configuration to determine if the audit records will note where (e.g., service, interface, node, link, etc.) the event that is being logged occurred. If the SDN controller is not configured to produce audit records containing information to establish where (e.g., service, interface, node, link, etc.) the events occurred, this is a finding.

Fix: F-87617r2_fix

Configure the SDN controller to include where (e.g., service, interface, node, link, etc.) the event occurred in the log records.

b
The SDN controller must be configured to produce audit records containing information to establish the source of the events.
AU-3 - Medium - CCI-000133 - V-80765 - SV-95475r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000133
Version
SRG-NET-000077-SDN-000135
Vuln IDs
  • V-80765
Rule IDs
  • SV-95475r1_rule
Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source (i.e. service, function, node name, IP address, etc.) of the event.
Checks: C-80501r2_chk

Review the SDN controller configuration to determine if the audit records will note the source (e.g., flow, API, IP address, etc.) the event that is being logged. If the SDN controller is not configured to produce audit records containing information to establish the source (e.g., flow, API, IP address, etc.) of the events, this is a finding.

Fix: F-87619r2_fix

Configure the SDN controller to include the source (e.g., flow, API, IP address, etc.) of the event in the log records.

b
The SDN controller must be configured to produce audit records containing information to establish the outcome of the events.
AU-3 - Medium - CCI-000134 - V-80767 - SV-95477r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000134
Version
SRG-NET-000078-SDN-000140
Vuln IDs
  • V-80767
Rule IDs
  • SV-95477r1_rule
Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the network. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the network after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.
Checks: C-80503r1_chk

Review the SDN controller configuration to determine if the audit records will note the outcome (i.e. packet allowed, packet dropped, link down, etc.) the event that is being logged. If the SDN controller is not configured to produce audit records containing information to establish the outcome (i.e. packet allowed, packet dropped, link down, etc.) of the events, this is a finding.

Fix: F-87621r1_fix

Configure the SDN controller to include the outcome (i.e. packet allowed, packet dropped, link down, etc.) of the event in the log records.

b
The SDN controller must be configured to generate audit records containing information that establishes the identity of any individual or process associated with the event.
AU-3 - Medium - CCI-001487 - V-80769 - SV-95479r1_rule
RMF Control
AU-3
Severity
M
CCI
CCI-001487
Version
SRG-NET-000079-SDN-000145
Vuln IDs
  • V-80769
Rule IDs
  • SV-95479r1_rule
Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event.
Checks: C-80505r1_chk

Review the SDN controller configuration to determine if the audit records will contain the identity of any individual or process associated with an event that is being logged. If the SDN controller is not configured to produce audit records containing the identity of any individual or process associated with an event being logged, this is a finding.

Fix: F-87623r1_fix

Configure the SDN controller to the identity of any individual or process associated with an event in the log records.

b
The SDN controller must be configured to disable non-essential capabilities.
CM-7 - Medium - CCI-000381 - V-80771 - SV-95481r1_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
SRG-NET-000131-SDN-000200
Vuln IDs
  • V-80771
Rule IDs
  • SV-95481r1_rule
It is detrimental for network elements to provide, or enable by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Some of the functions and services that could be enabled may not be necessary to support essential organizational operations.
Checks: C-80507r1_chk

Review the SDN controller configuration to determine if services or functions not required for SDN controller operation are enabled. If unnecessary services and functions are enabled on the SDN controller, this is a finding.

Fix: F-87625r1_fix

Remove unneeded services and functions from the SDN configuration. Removal is recommended because the service or function may be inadvertently enabled otherwise. However, if removal is not possible, disable the service or function.

b
The SDN controller must be configured to enforce a policy to manage bandwidth and to limit the effects of a packet-flooding Denial of Service (DoS) attack.
SC-5 - Medium - CCI-001095 - V-80773 - SV-95483r1_rule
RMF Control
SC-5
Severity
M
CCI
CCI-001095
Version
SRG-NET-000193-SDN-000285
Vuln IDs
  • V-80773
Rule IDs
  • SV-95483r1_rule
A network element experiencing a DoS attack will not be able to handle production traffic load. The high utilization and CPU caused by a DoS attack will also have an effect on control keep-alives and timers used for neighbor peering resulting in route flapping and will eventually black hole production traffic. The device must be configured to contain and limit a DoS attack's effect on the device's resource utilization. The use of redundant components and load balancing are examples of mitigating "flood type" DoS attacks through increased capacity.
Checks: C-80509r2_chk

Review the SDN controller configuration to verify that it is configured to enforce a policy to manage bandwidth and to limit the effects of a packet-flooding DoS attack. The implementation could be driven by a service application via the northbound API that contains the policy. If the SDN controller is not configured to enforce a policy to manage bandwidth and limit the effect of a packet-flooding DoS attack, this is a finding.

Fix: F-87627r1_fix

Configure the SDN controller to enforce a policy to manage bandwidth and to limit the effects of a packet-flooding Denial of Service (DoS) attack. This can be implemented via northbound API from a service application containing the policy.

b
The SDN controllers must be configured as a cluster in active/active or active/passive mode to preserve any information necessary to determine cause of a system failure and to maintain network operations with least disruption to workload processes and flows.
SC-24 - Medium - CCI-001665 - V-80775 - SV-95485r1_rule
RMF Control
SC-24
Severity
M
CCI
CCI-001665
Version
SRG-NET-000236-SDN-000365
Vuln IDs
  • V-80775
Rule IDs
  • SV-95485r1_rule
Failure in a known state can address safety or security in accordance with the mission needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the SDN controller. Preserving network element state information helps to facilitate continuous network operations minimal or no disruption to mission-essential workload processes and flows.
Checks: C-80511r1_chk

Review the SDN controller configuration to determine if it is configured to peer with one or more controllers in an active/active or active/passive failover mode. If the SDN controller is not configured to be deployed as a cluster in active/active or active/passive mode, this is a finding.

Fix: F-87629r1_fix

Configure the SDN controller to peer with one or more controllers in an active/active or active/passive failover mode.

b
The SDN controller must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by rate-limiting control-plane communications.
SC-5 - Medium - CCI-002385 - V-80777 - SV-95487r1_rule
RMF Control
SC-5
Severity
M
CCI
CCI-002385
Version
SRG-NET-000362-SDN-000720
Vuln IDs
  • V-80777
Rule IDs
  • SV-95487r1_rule
The SDN Controller is critical to all network operations because it is the component used to build all forwarding paths for the data plane via control-plane processes. It is also instrumental with network management and provisioning functions that keep the SDN-enabled network elements and links available for providing network services. Any disruption to the SDN Controller can result in mission-critical network outages. A DoS attack targeting the SDN Controller can result in excessive CPU and memory utilization. The SDN Controller must be configured to rate-limit control-plane traffic destined to itself to mitigate the risk of a DoS attack and ensure network stability.
Checks: C-80513r1_chk

Review the SDN controller configuration to determine if it is configured to rate-limit control-plane messages. If the SDN controller is not configured to rate-limit control-plane messages, this is a finding.

Fix: F-87631r1_fix

Configure the SDN controller to rate-limit control-plane messages.

b
The SDN controller must be configured to only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations.
SC-7 - Medium - CCI-002403 - V-80779 - SV-95489r1_rule
RMF Control
SC-7
Severity
M
CCI
CCI-002403
Version
SRG-NET-000364-SDN-000730
Vuln IDs
  • V-80779
Rule IDs
  • SV-95489r1_rule
Unrestricted traffic may contain malicious traffic which poses a threat to an enclave or data center. Additionally, unrestricted traffic may transit a network consuming bandwidth and network node resources. Access control policies and access control lists implemented on routers and switches can control the flow of network traffic by ensuring that the flow of traffic is only allowed from authorized sources to authorized destinations. Furthermore, the SDN controller provides flow rules to the SDN-enabled routers and switches to populate their forwarding tables. SDN-enabled routers and switches will drop packets for flows that are not permitted by the controller. Also when reactive flow setup occurs (switch has no flow entry in the forwarding table for specific flow), the controller can respond to the switch to drop the packet or provide the device with a new flow entry. It is imperative that the SDN controller enforces perimeter security by deploying strict flow entries to the SDN-enabled edge routers.
Checks: C-80515r1_chk

Review the SDN configuration to determine if it enforces perimeter security by deploying strict flow entries to the SDN-enabled edge routers to only allow incoming traffic that is authorized. If the SDN controller is not configured to only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations, this is a finding.

Fix: F-87633r1_fix

Configure the SDN controller to enforce perimeter security by deploying strict flow entries to the SDN-enabled edge routers to only allow incoming traffic that is authorized.

c
The SDN controller must be configured to authenticate southbound Application Program Interface (API) control-plane messages received from SDN-enabled network elements using a FIPS-approved message authentication code algorithm.
IA-7 - High - CCI-000803 - V-80781 - SV-95491r1_rule
RMF Control
IA-7
Severity
H
CCI
CCI-000803
Version
SRG-NET-000512-SDN-001020
Vuln IDs
  • V-80781
Rule IDs
  • SV-95491r1_rule
Southbound APIs such as OpenFlow provide the forwarding tables to network devices, such as switches and routers, both physical and virtual (hypervisor-based). The SDN controllers use the concept of flows to identify network traffic based on predefined rules that can be statically or dynamically programmed by the SDN control software, thereby determining how traffic should flow through network devices based on usage patterns, applications, and policy that can optimize traffic paths based on business requirements and not network infrastructure design. The SDN controller can receive control-plane messages from the SDN-enabled routers and switches to provide link state information or to require a flow table entry for a packet that does not map to any entries (i.e., reactive flow setup). To ensure the integrity and authenticity of these messages, it is imperative that they are authenticated prior to processing and taking any action.
Checks: C-80517r1_chk

Review the SDN configuration, verify that it is configured to authenticate received southbound API control-plane messages using a FIPS-approved message authentication code algorithm. FIPS-approved algorithms for authentication are the cipher-based message authentication code (CMAC) and the keyed-hash message authentication code (HMAC). AES and 3DES are NIST-approved CMAC algorithms. The following are NIST-approved HMAC algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. If the SDN controller is not configured to authenticate received southbound API control-plane messages using a FIPS-approved message authentication code algorithm, this is a finding.

Fix: F-87635r1_fix

Configure the SDN controller to authenticate southbound API control-plane messages using a FIPS-approved message authentication code algorithm. FIPS-approved algorithms for authentication are the CMAC and the HMAC. AES and 3DES are NIST-approved CMAC algorithms. The following are NIST-approved HMAC algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.

c
The SDN controller must be configured to authenticate northbound Application Program Interface (API) messages received from business applications and management systems using a FIPS-approved message authentication code algorithm.
IA-7 - High - CCI-000803 - V-80783 - SV-95493r1_rule
RMF Control
IA-7
Severity
H
CCI
CCI-000803
Version
SRG-NET-000512-SDN-001025
Vuln IDs
  • V-80783
Rule IDs
  • SV-95493r1_rule
The SDN controller determines how traffic should flow through physical and virtual network devices based on application profiles, network infrastructure resources, security policies, and business requirements that it receives via the northbound API. It also receives network service requests from orchestration and management systems to deploy and configure network elements via this API. In turn, the northbound API presents a network abstraction to these orchestration and management systems. If attackers could leverage a vulnerable northbound API, they would have control over the SDN infrastructure through the controller. If the SDN controller were to receive fictitious information from a rogue application or orchestration system, non-optimized network paths would be produced that could disrupt network operations, resulting in inefficient application and business processes. An attacker could also leverage these protocols and attempt to instantiate new flows that could be inadvertently pushed into network devices’ flow-table. The attacker would want to try to spoof new flows to permit specific types of traffic that should be disallowed across the network. If an attacker could create a flow that bypasses the traffic steering that forces traffic through a firewall, the attacker would have a decided advantage. If the attacker can steer traffic in their direction, they may try to leverage that capability to sniff traffic and perform a man-in-the-middle attack.
Checks: C-80519r1_chk

Review the SDN configuration verify that it is configured to authenticate received northbound API messages using a FIPS-approved message authentication code algorithm. FIPS-approved algorithms for authentication are the cipher-based message authentication code (CMAC) and the keyed-hash message authentication code (HMAC). AES and 3DES are NIST-approved CMAC algorithms. The following are NIST-approved HMAC algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. If the SDN controller is not configured to authenticate northbound API messages received from business applications and management systems using a FIPS-approved message authentication code algorithm, this is a finding.

Fix: F-87637r1_fix

Configure the SDN controller to authenticate received northbound API messages using a FIPS-approved message authentication code algorithm. FIPS-approved algorithms for authentication are the CMAC and the HMAC. AES and 3DES are NIST-approved CMAC algorithms. The following are NIST-approved HMAC algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.

c
The SDN controller must be configured to encrypt all southbound Application Program Interface (API) control-plane messages using a FIPS-validated cryptographic module.
AC-17 - High - CCI-000068 - V-80785 - SV-95495r1_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000512-SDN-001030
Vuln IDs
  • V-80785
Rule IDs
  • SV-95495r1_rule
Southbound APIs such as OpenFlow provide the forwarding tables to network devices, such as switches and routers, both physical and virtual (hypervisor-based). The SDN controllers use the concept of flows to identify network traffic based on predefined rules that can be statically or dynamically programmed by the SDN control software, thereby determining how traffic should flow through network devices based on usage patterns, applications, and policy that can optimize traffic paths based on business requirements and not network infrastructure design. An attacker could also leverage these protocols and attempt to instantiate new flows into a device’s flow-table. The attacker would want to try to spoof new flows to permit specific types of traffic that should be disallowed across the network. If an attacker could create a flow that bypasses the traffic steering that forces traffic through a firewall, the attacker would have a decided advantage. If an SDN-aware router or switch received erroneous forwarding information from a rogue controller, traffic could be black-holed or even forwarded to a malicious user to sniff traffic and perform a man-in-the-middle attack. Hence, it is imperative to secure flow table updates by encrypting all southbound API traffic or deploying an out-of-band network for this traffic to traverse.
Checks: C-80521r1_chk

Determine if the southbound API control-plane traffic traverses an out-of-band path. If not, review the SDN controller configuration to verify that southbound API management-plane traffic is encrypted using a using a FIPS-validated cryptographic module. If the southbound API control-plane traffic does not traverse an out-of-band path or is not encrypted using a using a FIPS-validated cryptographic module, this is a finding. Note: FIPS-validated cryptographic modules are listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.

Fix: F-87639r1_fix

Deploy an out-of-band network to provision paths between SDN controller and SDN-enabled devices as well as all hypervisor hosts that compose the SDN infrastructure to provide transport for southbound API control-plane traffic. An alternative is to configure the SDN controller to encrypt all southbound API control-plane traffic using a using a FIPS-validated cryptographic module. Implement a cryptographic module which has a validation certification and is listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.

c
The SDN controller must be configured to encrypt all northbound Application Program Interface (API) messages using a FIPS-validated cryptographic module.
AC-17 - High - CCI-000068 - V-80787 - SV-95497r1_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000512-SDN-001035
Vuln IDs
  • V-80787
Rule IDs
  • SV-95497r1_rule
The SDN controller receives network service requests from orchestration and management systems to deploy and configure network elements via the northbound API. In turn, the northbound API presents a network abstraction to these systems. If either the orchestration or management system were breached, a rogue user could make modifications to the business or security policy that could disrupt network operations, resulting in inefficient application and business processes and bypassing security controls. In addition, invalid network service requests could be processed that could exhaust compute, storage, and network resources, leaving no resources available for legitimate business requirements. Hence, it is imperative that all northbound API traffic is secured by encrypting the traffic or deploying an out-of-band network for this traffic to traverse.
Checks: C-80523r1_chk

Determine if the northbound API traffic traverses an out-of-band path. If not, review the SDN controller configuration to verify that northbound API traffic is encrypted using a using a FIPS-validated cryptographic module. If northbound API traffic does not traverse an out-of-band path and is not encrypted using a using a FIPS-validated cryptographic module, this is a finding. Note: FIPS-validated cryptographic modules are listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.

Fix: F-87641r1_fix

Deploy an out-of-band network to provision paths between the SDN controller and the SDN management/orchestration systems for providing transport for northbound API traffic. An alternative is to configure the SDN controller to encrypt all northbound API traffic using a FIPS-validated cryptographic module. Implement a cryptographic module which has a validation certification and is listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.

c
The SDN controller must be configured to authenticate received southbound Application Program Interface (API) management-plane messages using a FIPS-approved message authentication code algorithm.
IA-7 - High - CCI-000803 - V-80789 - SV-95499r1_rule
RMF Control
IA-7
Severity
H
CCI
CCI-000803
Version
SRG-NET-000512-SDN-001040
Vuln IDs
  • V-80789
Rule IDs
  • SV-95499r1_rule
The SDN controller can receive management-plane traffic from the SDN-enabled devices that it monitors and manages. The messages could be responses from SNMP get requests as well as SNMP notifications (i.e., traps and informs) provided to note changes in node or link state. NETCONF is also used by the SDN controller to configure SDN-enabled devices as well as to receive state and configuration information. Communication between the SDN controller and NETCONF-enabled devices is session based. A session is established for the purpose of exchanging data using remote procedure call (RPC) requests and replies. If the SDN controller were to receive messages from a rogue device using SNMP or NETCONF providing fraud state information or configuration data, the abstract view of the network topology could be altered thereby providing an attacker with the ability to force traffic to bypass security controls or be forwarded using non-optimized paths. To ensure the integrity and authenticity of these messages, it is imperative that they are authenticated prior to processing and taking any action.
Checks: C-80525r1_chk

Review the SDN configuration, verify that it is configured to authenticate received southbound API management-plane messages using a FIPS-approved message authentication code algorithm. FIPS-approved algorithms for authentication are the cipher-based message authentication code (CMAC) and the keyed-hash message authentication code (HMAC). AES and 3DES are NIST-approved CMAC algorithms. The following are NIST-approved HMAC algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. If the SDN controller is not configured to authenticate received southbound API management-plane messages using a FIPS-approved message authentication code algorithm, this is a finding.

Fix: F-87643r1_fix

Configure the SDN controller to authenticate southbound API management-plane messages using a FIPS-approved message authentication code algorithm. FIPS-approved algorithms for authentication are the CMAC and the HMAC. AES and 3DES are NIST-approved CMAC algorithms. The following are NIST-approved HMAC algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.

c
The SDN controller must be configured to encrypt all southbound Application Program Interface (API) management-plane messages using a FIPS-validated cryptographic module.
AC-17 - High - CCI-000068 - V-80791 - SV-95501r1_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
SRG-NET-000512-SDN-001045
Vuln IDs
  • V-80791
Rule IDs
  • SV-95501r1_rule
An SDN controller can manage and configure SDN-enabled devices using protocols such as SNMP and NETCONF. If an SDN-aware router or switch received erroneous configuration information that was altered by a malicious user, interfaces could be disabled, erroneous IP addresses configured, services removed—all resulting a network disruption or even an outage. Hence, it is imperative to secure the management plane by encrypting all southbound API management-plane traffic or deploying an out-of-band network for this traffic to traverse.
Checks: C-80527r2_chk

Determine if the southbound API management-plane traffic traverses an out-of-band path. If not, review the SDN controller configuration to verify that southbound API management-plane traffic is encrypted using a using a FIPS-validated cryptographic module. If the southbound API management-plane traffic does not traverse an out-of-band path and is not encrypted using a FIPS-validated cryptographic module, this is a finding. Note: FIPS-validated cryptographic modules are listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.

Fix: F-87645r1_fix

Deploy an out-of-band network to provision paths between SDN controller and SDN-enabled devices as well as all hypervisor hosts that compose the SDN infrastructure to provide transport for southbound API management-plane traffic. An alternative is to configure the SDN controller to encrypt all southbound API management-plane traffic using a FIPS-validated cryptographic module. Implement a cryptographic module which has a validation certification and is listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.

b
The SDN controller must be configured to be deployed as a cluster and on separate physical hosts.
CM-6 - Medium - CCI-000366 - V-80793 - SV-95503r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001050
Vuln IDs
  • V-80793
Rule IDs
  • SV-95503r1_rule
SDN relies heavily on control messages between a controller and the forwarding devices for network convergence. The controller uses node and link state discovery information to calculate and determine optimum pathing within the SDN network infrastructure based on application, business, and security policies. Operating in the proactive flow instantiation mode, the SDN controller populates forwarding tables to the SDN-aware forwarding devices. At times, the SDN controller must function in reactive flow instantiation mode; that is, when a forwarding device receives a packet for a flow not found in its forwarding table, it must send it to the controller to receive forwarding instructions. With total dependence on the SDN controller for determining forwarding decisions and path optimization within the SDN infrastructure for both proactive and reactive flow modes of operation, having a single point of failure is not acceptable. A controller failure with no failover backup leaves the network in an unmanaged state. Hence, it is imperative that the SDN controllers are deployed as clusters on separate physical hosts to guarantee network high availability.
Checks: C-80529r1_chk

Review the SDN controller configuration to determine if it is configured to peer with one or more controllers. Also verify that the controller resides on a different physical host than any of its peers. If the SDN controller is not configured to be deployed as a cluster and on separate physical hosts, this is a finding.

Fix: F-87647r1_fix

Deploy the SDN controller as a cluster using on a separate physical hosts to eliminate single point of failure. Configure the SDN controller to peer with one or more controllers.

b
The SDN Controller must be configured to notify the forwarding device to either drop the packet or make an entry in the flow table for a received packet that does not match any flow table entries.
CM-6 - Medium - CCI-000366 - V-80795 - SV-95505r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001055
Vuln IDs
  • V-80795
Rule IDs
  • SV-95505r1_rule
Reactive flow setup occurs when the SDN-aware switch receives a packet that does not match the flow table entries and hence the switch has to send the packet to the controller for processing. Once the controller decides how to process the flow that information is cached on the SDN-aware switch, and the SDN controller determines how long to keep the cache alive. In order to prevent packets from being dropped as a result of no flow table entry, it is imperative that the SDN Controller is configured to enable reactive flow setup.
Checks: C-80531r1_chk

Review the SDN controller configuration to determine if it is configured to enable reactive flow setup. If the SDN Controller is not configured to notify the forwarding device to either drop the packet or make an entry in the flow table for a received packet that does not match any flow table entries, this is a finding.

Fix: F-87649r1_fix

Configure the SDN controller to enable reactive flow setup so that the controller will notify a forwarding device to either drop the packet or make an entry in the flow table for a received packet that does not match any flow table entries.

b
SDN controller must be configured to forward traffic based on security requirements.
CM-6 - Medium - CCI-000366 - V-80797 - SV-95507r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001060
Vuln IDs
  • V-80797
Rule IDs
  • SV-95507r1_rule
For security reasons, an organization may choose to have traffic that is inbound to a server go through a specific firewall. In order not to consume the resources of the firewall with clean traffic, the organization may want to choose to redirect the traffic that is outbound from the server to not go through the firewall. Today, zero-trust models are being implemented within the data center; applications and workloads trust no other workload; hence, connectivity between them is not allowed unless explicitly authorized. Each application or workload can have its own security policies. With the advent of cloud networking and multi-tenancy, security policies have evolved to be more workload and application-centric (for example, what type of application, who the tenant is, and which tier of the application is being protected). The SDN Controller must enforce these policies by controlling the forwarding of packets to specific destinations for specific workloads based on the rules provided within the policies.
Checks: C-80533r1_chk

Review the SDN controller configuration to determine if it is configured to forward traffic based on security requirements that have been provided from a security service or policy engine via the northbound API. If the SDN Controller is not configured to forward traffic based on security requirements, this is a finding.

Fix: F-87651r1_fix

Configure the SDN controller to forward traffic based on security requirements.

b
The SDN controller must be configured to enable multi-tenant virtual networks to be fully isolated from one another.
CM-6 - Medium - CCI-000366 - V-80799 - SV-95509r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001065
Vuln IDs
  • V-80799
Rule IDs
  • SV-95509r1_rule
Network-as-a-Service (NaaS) is often implemented in a multi-tenant paradigm, where customers share network infrastructure and services while they are logically isolated from each other. SDN provides an approach to the orchestration and provisioning of virtual network services by the owners of the network infrastructures. This leads to various multi-tenancy deployments: on different layers, for different purposes, using different techniques—each of which provides different levels of control while requiring different types of isolation among users. For instance, implementation can be a southbound multi-tenancy with several guest controllers sharing the same data forwarding elements, or a northbound multi-tenancy with several guest applications sharing the entire SDN infrastructure including the SDN controller. Regardless of the implementation, it is imperative that the controller provides the necessary isolation and separation.
Checks: C-80535r1_chk

Review the SDN controller configuration to determine if it is configured to deploy dedicated instances of virtual networks and separate forwarding tables to the provisioned network elements belonging to each tenant. If the SDN Controller is not configured to enable multi-tenant virtual networks to be fully isolated from one another, this is a finding.

Fix: F-87653r1_fix

Configure the SDN controller to deploy dedicated instances of virtual networks and separate forwarding tables to the provisioned network elements belonging to each tenant.

b
The SDN controller must be configured to separate tenant functionality from system management functionality.
SC-2 - Medium - CCI-001082 - V-80801 - SV-95511r1_rule
RMF Control
SC-2
Severity
M
CCI
CCI-001082
Version
SRG-NET-000512-SDN-001070
Vuln IDs
  • V-80801
Rule IDs
  • SV-95511r1_rule
Network-as-a-Service (NaaS) is frequently offered in a multi-tenant paradigm, where customers share network infrastructure. SDN provides an approach to the provisioning of virtual network services by owners of the network infrastructures to third parties. This leads to various multi-tenancy deployments using different techniques, each of which provides different levels of control while requiring different types of isolation among users. For example, a southbound implementation allows multiple guest controllers sharing the same data forwarding elements; whereas a northbound implementation enables multiple guest applications sharing the whole SDN infrastructure including the SDN controller. To ensure stable network operations in a multi-tenant deployment, it is imperative that the SDN controller is configured to separate tenant functionality from system management functionality.
Checks: C-80537r1_chk

Review the SDN controller configuration to determine whether tenant functionality is separated from system management functionality using separated instances within the controller framework as well as Role-based access control (RBAC). If the SDN controller is not configured to separate tenant functionality from system management functionality, this is a finding.

Fix: F-87655r1_fix

Configure the SDN controller to have tenant functionality separated from system management functionality using separated instances within the controller framework as well as Role-based access control (RBAC).

b
The SDN controller must be configured to isolate security functions from non-security functions.
SC-3 - Medium - CCI-001084 - V-80803 - SV-95513r1_rule
RMF Control
SC-3
Severity
M
CCI
CCI-001084
Version
SRG-NET-000512-SDN-001075
Vuln IDs
  • V-80803
Rule IDs
  • SV-95513r1_rule
An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions. Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries. Applications restrict access to security functions through the use of access control mechanisms and by implementing least privilege capabilities.
Checks: C-80539r1_chk

Review the SDN controller configuration to determine whether objects and code implementing security functionality are isolated from non-security functionality objects and code. Role-based access control (RBAC) must also be configured to restrict access to all security functionality. If security-related objects and code are not kept separate and are not configured with RBAC access restriction, this is a finding.

Fix: F-87657r1_fix

Configure the SDN controller to isolate objects and code implementing RBAC to restrict access to security functionality from non-security functionality objects and code.

b
The SDN controller must be configured to generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
SI-11 - Medium - CCI-001312 - V-80805 - SV-95515r1_rule
RMF Control
SI-11
Severity
M
CCI
CCI-001312
Version
SRG-NET-000512-SDN-001080
Vuln IDs
  • V-80805
Rule IDs
  • SV-95515r1_rule
Providing too much information in error messages on the screen or printout risks compromising the data and security of the SDN controller. The structure and content of error messages need to be carefully considered by the organization. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-80541r1_chk

Review the SDN controller configuration to determine that error messages do not contain information beyond what is needed for troubleshooting controller and network problems. If the controller is not configured to generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries, this is a finding.

Fix: F-87659r1_fix

Configure the SDN controller to generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.

b
The SDN controller must be configured to notify the ISSO and ISSM of failed verification tests for organization-defined security functions.
SI-5 - Medium - CCI-002694 - V-80807 - SV-95517r1_rule
RMF Control
SI-5
Severity
M
CCI
CCI-002694
Version
SRG-NET-000512-SDN-001085
Vuln IDs
  • V-80807
Rule IDs
  • SV-95517r1_rule
If personnel are not notified of failed security verification tests, they will not be able to take corrective action and the unsecure condition(s) will remain. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. This requirement applies to applications performing security functions and the applications performing security function verification/testing.
Checks: C-80543r1_chk

Review the SDN controller configuration to determine if it is configured to notify the ISSO and ISSM of failed security verification tests. If the SDN controller is not configured to notify the ISSO and ISSM of failed security verification tests, this is a finding. Note: The organization defines the system transitional states when the SDN controller will verify correct operation of the security functions.

Fix: F-87661r1_fix

Configure the SDN controller to notify the ISSO and ISSM of failed security verification tests. Note: DoD activities should also notify the Regional Cyber Center (RCC). Note: The organization defines the system transitional states when the SDN controller will verify correct operation of the security functions.

b
The SDN controller must be configured to prohibit user installation of software without explicit privileged status.
CM-11 - Medium - CCI-001812 - V-80809 - SV-95519r1_rule
RMF Control
CM-11
Severity
M
CCI
CCI-001812
Version
SRG-NET-000512-SDN-001090
Vuln IDs
  • V-80809
Rule IDs
  • SV-95519r1_rule
Allowing regular users to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user. Application functionality will vary, and while users are not permitted to install unapproved applications, there may be instances where the organization allows the user to install approved software packages such as from an approved software repository. The application must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization. This requirement applies, for example, to applications that provide the ability to extend application functionality (e.g., plug-ins, add-ons) and software management applications.
Checks: C-80545r2_chk

Review documentation of non-administrative users who have been given access permissions to install, modify, or replace software modules within the SDN controller framework. Review the SDN controller configuration to determine that only authorized users have the permissions to install, modify, or replace software modules. If the SDN controller is not configured to revoke unauthorized attempts to install, modify, or replace software modules, this is a finding.

Fix: F-87663r2_fix

Document the approval for non-administrative users who require the ability to install, modify, or replace software modules within the SDN controller framework. Configure the SDN controller to revoke the installation of software modules by any unapproved permissions or access levels.

b
The SDN controller must be configured to enforce access restrictions associated with changes to the configuration.
CM-5 - Medium - CCI-001813 - V-80811 - SV-95521r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001813
Version
SRG-NET-000512-SDN-001095
Vuln IDs
  • V-80811
Rule IDs
  • SV-95521r1_rule
Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. Logical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).
Checks: C-80547r1_chk

Review the SDN controller configuration to determine if it is configured to restrict access to the configuration. If the SDN controller is not configured to enforce access restrictions associated with changes to the configuration, this is a finding.

Fix: F-87665r1_fix

Configure the SDN controller to restrict access to the configuration.

b
The SDN controller must be configured to audit the enforcement actions used to restrict access associated with changes to any application within the SDN framework.
CM-5 - Medium - CCI-001814 - V-80813 - SV-95523r1_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001814
Version
SRG-NET-000512-SDN-001100
Vuln IDs
  • V-80813
Rule IDs
  • SV-95523r1_rule
Without auditing the enforcement of access restrictions against changes to any application within the SDN framework, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.
Checks: C-80549r1_chk

Review the SDN controller configuration to determine if it is configured to audit enforcement actions used to restrict access associated with changes to any application. If the SDN controller is not configured to audit the enforcement actions used to restrict access associated with changes to any application within the SDN framework, this is a finding.

Fix: F-87667r1_fix

Configure the SDN controller to audit enforcement actions used to restrict access associated with changes to any application.

b
The SDN controller must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.
CM-6 - Medium - CCI-000366 - V-100101 - SV-109205r1_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
SRG-NET-000512-SDN-002000
Vuln IDs
  • V-100101
Rule IDs
  • SV-109205r1_rule
Configuring the network device to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network device. Security-related parameters are those parameters impacting the security state of the network device, including the parameters required to satisfy other security control requirements.
Checks: C-98953r1_chk

Determine if the SDN controller is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not configured in accordance with the designated security configuration settings, this is a finding.

Fix: F-105787r1_fix

Configure the SDN controller to be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.