Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

SDN Controller Security Requirements Guide

  • Version/Release: V2R1
  • Published: 2024-05-28
  • Released: 2024-07-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

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.
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-206715 - SV-206715r382729_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
SRG-NET-000015-SDN-000010
Vuln IDs
  • V-206715
  • V-80755
Rule IDs
  • SV-206715r382729_rule
  • SV-95465
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-6972r363083_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-6972r363084_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-206716 - SV-206716r382732_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
SRG-NET-000018-SDN-000015
Vuln IDs
  • V-206716
  • V-80757
Rule IDs
  • SV-206716r382732_rule
  • SV-95467
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-6973r363086_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-6973r363087_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-206717 - SV-206717r382855_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
SRG-NET-000074-SDN-000120
Vuln IDs
  • V-206717
  • V-80759
Rule IDs
  • SV-206717r382855_rule
  • SV-95469
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-6974r363089_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-6974r363090_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-206718 - SV-206718r382858_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000131
Version
SRG-NET-000075-SDN-000125
Vuln IDs
  • V-206718
  • V-80761
Rule IDs
  • SV-206718r382858_rule
  • SV-95471
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-6975r363092_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-6975r363093_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-206719 - SV-206719r382861_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000132
Version
SRG-NET-000076-SDN-000130
Vuln IDs
  • V-206719
  • V-80763
Rule IDs
  • SV-206719r382861_rule
  • SV-95473
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-6976r363095_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-6976r363096_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-206720 - SV-206720r382864_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000133
Version
SRG-NET-000077-SDN-000135
Vuln IDs
  • V-206720
  • V-80765
Rule IDs
  • SV-206720r382864_rule
  • SV-95475
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-6977r363098_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-6977r363099_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-206721 - SV-206721r382867_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000134
Version
SRG-NET-000078-SDN-000140
Vuln IDs
  • V-206721
  • V-80767
Rule IDs
  • SV-206721r382867_rule
  • SV-95477
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-6978r363101_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-6978r363102_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-206722 - SV-206722r382870_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-001487
Version
SRG-NET-000079-SDN-000145
Vuln IDs
  • V-206722
  • V-80769
Rule IDs
  • SV-206722r382870_rule
  • SV-95479
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-6979r363104_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-6979r363105_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-206723 - SV-206723r382903_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
SRG-NET-000131-SDN-000200
Vuln IDs
  • V-206723
  • V-80771
Rule IDs
  • SV-206723r382903_rule
  • SV-95481
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-6980r363107_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-6980r363108_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-206724 - SV-206724r385534_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
SRG-NET-000193-SDN-000285
Vuln IDs
  • V-206724
  • V-80773
Rule IDs
  • SV-206724r385534_rule
  • SV-95483
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-6981r363110_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-6981r363111_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-206725 - SV-206725r539658_rule
RMF Control
SC-24
Severity
Medium
CCI
CCI-001665
Version
SRG-NET-000236-SDN-000365
Vuln IDs
  • V-206725
  • V-80775
Rule IDs
  • SV-206725r539658_rule
  • SV-95485
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-6982r363113_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-6982r363114_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-206726 - SV-206726r856676_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
SRG-NET-000362-SDN-000720
Vuln IDs
  • V-206726
  • V-80777
Rule IDs
  • SV-206726r856676_rule
  • SV-95487
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-6983r363116_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-6983r363117_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-206727 - SV-206727r856677_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
SRG-NET-000364-SDN-000730
Vuln IDs
  • V-206727
  • V-80779
Rule IDs
  • SV-206727r856677_rule
  • SV-95489
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-6984r363119_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-6984r363120_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-206728 - SV-206728r385561_rule
RMF Control
IA-7
Severity
High
CCI
CCI-000803
Version
SRG-NET-000512-SDN-001020
Vuln IDs
  • V-206728
  • V-80781
Rule IDs
  • SV-206728r385561_rule
  • SV-95491
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-6985r363122_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-6985r363123_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-206729 - SV-206729r385561_rule
RMF Control
IA-7
Severity
High
CCI
CCI-000803
Version
SRG-NET-000512-SDN-001025
Vuln IDs
  • V-206729
  • V-80783
Rule IDs
  • SV-206729r385561_rule
  • SV-95493
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-6986r363125_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-6986r363126_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-206730 - SV-206730r385561_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
SRG-NET-000512-SDN-001030
Vuln IDs
  • V-206730
  • V-80785
Rule IDs
  • SV-206730r385561_rule
  • SV-95495
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-6987r363128_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-6987r363129_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-206731 - SV-206731r385561_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
SRG-NET-000512-SDN-001035
Vuln IDs
  • V-206731
  • V-80787
Rule IDs
  • SV-206731r385561_rule
  • SV-95497
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-6988r363131_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-6988r363132_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-206732 - SV-206732r385561_rule
RMF Control
IA-7
Severity
High
CCI
CCI-000803
Version
SRG-NET-000512-SDN-001040
Vuln IDs
  • V-206732
  • V-80789
Rule IDs
  • SV-206732r385561_rule
  • SV-95499
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-6989r363134_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-6989r363135_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-206733 - SV-206733r385561_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
SRG-NET-000512-SDN-001045
Vuln IDs
  • V-206733
  • V-80791
Rule IDs
  • SV-206733r385561_rule
  • SV-95501
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-6990r363137_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-6990r363138_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-206734 - SV-206734r385561_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001050
Vuln IDs
  • V-206734
  • V-80793
Rule IDs
  • SV-206734r385561_rule
  • SV-95503
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-6991r363140_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-6991r363141_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-206735 - SV-206735r385561_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001055
Vuln IDs
  • V-206735
  • V-80795
Rule IDs
  • SV-206735r385561_rule
  • SV-95505
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-6992r363143_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-6992r363144_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-206736 - SV-206736r385561_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001060
Vuln IDs
  • V-206736
  • V-80797
Rule IDs
  • SV-206736r385561_rule
  • SV-95507
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-6993r363146_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-6993r363147_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-206737 - SV-206737r385561_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SRG-NET-000512-SDN-001065
Vuln IDs
  • V-206737
  • V-80799
Rule IDs
  • SV-206737r385561_rule
  • SV-95509
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-6994r363149_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-6994r363150_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-206738 - SV-206738r385561_rule
RMF Control
SC-2
Severity
Medium
CCI
CCI-001082
Version
SRG-NET-000512-SDN-001070
Vuln IDs
  • V-206738
  • V-80801
Rule IDs
  • SV-206738r385561_rule
  • SV-95511
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-6995r363152_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-6995r363153_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-206739 - SV-206739r385561_rule
RMF Control
SC-3
Severity
Medium
CCI
CCI-001084
Version
SRG-NET-000512-SDN-001075
Vuln IDs
  • V-206739
  • V-80803
Rule IDs
  • SV-206739r385561_rule
  • SV-95513
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-6996r363155_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-6996r363156_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-206740 - SV-206740r385561_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001312
Version
SRG-NET-000512-SDN-001080
Vuln IDs
  • V-206740
  • V-80805
Rule IDs
  • SV-206740r385561_rule
  • SV-95515
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-6997r363158_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-6997r363159_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-206741 - SV-206741r856678_rule
RMF Control
SI-5
Severity
Medium
CCI
CCI-002694
Version
SRG-NET-000512-SDN-001085
Vuln IDs
  • V-206741
  • V-80807
Rule IDs
  • SV-206741r856678_rule
  • SV-95517
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-6998r363161_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-6998r363162_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.
- Medium - CCI-003980 - V-206742 - SV-206742r984177_rule
RMF Control
Severity
Medium
CCI
CCI-003980
Version
SRG-NET-000512-SDN-001090
Vuln IDs
  • V-206742
  • V-80809
Rule IDs
  • SV-206742r984177_rule
  • SV-95519
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-6999r984175_chk

Review documentation of nonadministrative 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-6999r984176_fix

Document the approval for nonadministrative 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-206743 - SV-206743r856680_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001813
Version
SRG-NET-000512-SDN-001095
Vuln IDs
  • V-206743
  • V-80811
Rule IDs
  • SV-206743r856680_rule
  • SV-95521
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-7000r363167_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-7000r363168_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.
- Medium - CCI-003938 - V-206744 - SV-206744r984178_rule
RMF Control
Severity
Medium
CCI
CCI-003938
Version
SRG-NET-000512-SDN-001100
Vuln IDs
  • V-206744
  • V-80813
Rule IDs
  • SV-206744r984178_rule
  • SV-95523
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-7001r363170_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-7001r363171_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-216509 - SV-216509r385561_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
SRG-NET-000512-SDN-002000
Vuln IDs
  • V-216509
  • V-100101
Rule IDs
  • SV-216509r385561_rule
  • SV-109205
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-17744r363173_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-17741r363174_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.

b
The SDN controller must be configured to employ organization-defined controls by type of denial of service (DoS) to achieve the DoS objective.
- Medium - CCI-004866 - V-264312 - SV-264312r984181_rule
RMF Control
Severity
Medium
CCI
CCI-004866
Version
SRG-NET-000705-SDN-000110
Vuln IDs
  • V-264312
Rule IDs
  • SV-264312r984181_rule
DoS events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of DoS events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of DoS attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to DoS events.
Checks: C-68225r984179_chk

Verify the SDN controller is configured to employ organization-defined controls by type of DoS to achieve the DoS objective. If the SDN controller is not configured to employ organization-defined controls by type of DoS to achieve the DoS objective, this is a finding.

Fix: F-68133r984180_fix

Configure the SDN controller to employ organization-defined controls by type of DoS to achieve the DoS objective.

b
The SDN controller must be configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.
- Medium - CCI-004891 - V-264313 - SV-264313r984184_rule
RMF Control
Severity
Medium
CCI
CCI-004891
Version
SRG-NET-000715-SDN-000120
Vuln IDs
  • V-264313
Rule IDs
  • SV-264313r984184_rule
Separating critical system components and functions from other noncritical system components and functions through separate subnetworks may be necessary to reduce susceptibility to a catastrophic or debilitating breach or compromise that results in system failure. For example, physically separating the command and control function from the in-flight entertainment function through separate subnetworks in a commercial aircraft provides an increased level of assurance in the trustworthiness of critical system functions.
Checks: C-68226r984182_chk

Verify the SDN controller is configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. If the SDN controller is not configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions, this is a finding.

Fix: F-68134r984183_fix

Configure the SDN controller to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.

b
The SDN controller must be configured to establish organization-defined alternate communications paths for system operations organizational command and control.
- Medium - CCI-004931 - V-264314 - SV-264314r984187_rule
RMF Control
Severity
Medium
CCI
CCI-004931
Version
SRG-NET-000760-SDN-000160
Vuln IDs
  • V-264314
Rule IDs
  • SV-264314r984187_rule
An incident, whether adversarial- or nonadversarial-based, can disrupt established communications paths used for system operations and organizational command and control. Alternate communications paths reduce the risk of all communications paths being affected by the same incident. To compound the problem, the inability of organizational officials to obtain timely information about disruptions or to provide timely direction to operational elements after a communications path incident, can impact the ability of the organization to respond to such incidents in a timely manner. Establishing alternate communications paths for command and control purposes, including designating alternative decision makers if primary decision makers are unavailable and establishing the extent and limitations of their actions, can greatly facilitate the organization's ability to continue to operate and take appropriate actions during an incident.
Checks: C-68227r984185_chk

Verify the SDN controller is configured to establish organization-defined alternate communications paths for system operations organizational command and control. If the SDN controller is not configured to establish organization-defined alternate communications paths for system operations organizational command and control, this is a finding.

Fix: F-68135r984186_fix

Configure the SDN controller to establish organization-defined alternate communications paths for system operations organizational command and control.