{
"stig": {
"date": "2017-03-01",
"description": "This Security Technical Implementation 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.",
"findings": {
"V-73073": {
"checkid": "C-73207r1_chk",
"checktext": "Review the components within the SDN framework that send and receive southbound API messages and verify that the messages are authenticated using a FIPS-approved message authentication code algorithm. \n\nFIPS-approved algorithms for authentication are the cipher-based message authentication code (CMAC) and the keyed-hash message authentication code (HMAC). \n\nAES 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. \n\nIf the SDN controller or SDN-enabled network elements do not authenticate received southbound API messages using a FIPS-approved message authentication code algorithm, this is a finding.",
"description": "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. \n\nIf 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 that mutual authentication is enabled between the SDN controller and the SDN-aware network elements for all southbound API traffic.",
"fixid": "F-79519r1_fix",
"fixtext": "Ensure that all components within the SDN framework authenticate southbound API messages using a FIPS-approved message authentication code algorithm. \n\nFIPS-approved algorithms for authentication are the CMAC and the HMAC. \n\nAES 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.",
"iacontrols": null,
"id": "V-73073",
"ruleID": "SV-87725r1_rule",
"severity": "high",
"title": "Southbound API control plane traffic between the SDN controller and SDN-enabled network elements must be mutually authenticated using a FIPS-approved message authentication code algorithm.",
"version": "NET-SDN-001"
},
"V-73075": {
"checkid": "C-73209r1_chk",
"checktext": "Review the configuration of the SDN controllers and verify that the northbound API messages received are authenticated using a FIPS-approved message authentication code algorithm. \n\nFIPS-approved algorithms for authentication are the cipher-based message authentication code (CMAC) and the keyed-hash message authentication code (HMAC). \n\nAES 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. \n\nIf the SDN controllers do not authenticate received northbound API messages using a FIPS-approved message authentication code algorithm, this is a finding.",
"description": "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. \n\nIf attackers could leverage a vulnerable northbound API, they would have control over the SDN infrastructure through the controller by inserting polices. 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. Hence, it is imperative that all northbound API traffic received by the SDN controller is authenticated.",
"fixid": "F-79521r1_fix",
"fixtext": "Configure all SDN controllers to authenticate received northbound API messages using a FIPS-approved message authentication code algorithm. \n\nFIPS-approved algorithms for authentication are the CMAC and the HMAC. \n\nAES 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.",
"iacontrols": null,
"id": "V-73075",
"ruleID": "SV-87727r1_rule",
"severity": "high",
"title": "Northbound API traffic received by the SDN controller must be authenticated using a FIPS-approved message authentication code algorithm.",
"version": "NET-SDN-002"
},
"V-73077": {
"checkid": "C-73211r1_chk",
"checktext": "Review all management and orchestration systems within the SDN framework and verify that access to these components requires DOD PKI certificate-based authentication. \n\nIf access to the SDN management and orchestration systems does not require DOD PKI certificate-based authentication, this is a finding.",
"description": "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 as well as bypassing security controls. \n\nIn addition, invalid network service requests could be processed that could exhaust compute, storage, and network resources, leaving no resources available for legitimate business requirements.",
"fixid": "F-79523r1_fix",
"fixtext": "Configure all management and orchestration systems within the SDN framework to require DOD PKI certificate-based authentication for access.",
"iacontrols": null,
"id": "V-73077",
"ruleID": "SV-87729r1_rule",
"severity": "medium",
"title": "Access to the SDN management and orchestration systems must be authenticated using a FIPS-approved message authentication code algorithm.",
"version": "NET-SDN-003"
},
"V-73079": {
"checkid": "C-73213r1_chk",
"checktext": "Determine if the southbound API control plane traffic between the SDN controllers and the SDN-enabled network elements traverses an out-of-band path. \n\nIf not, verify that the southbound API traffic is encrypted using a FIPS-validated cryptographic module.\n\nIf the southbound API traffic does not traverse an out-of-band path or is not encrypted using a FIPS-validated cryptographic module, this is a finding.\n\nNote: An out-of-band path would be a path between two nodes that traverses one or more links on an out-of-band network; that is, a dedicated layer 2 infrastructure separate from a production network.",
"description": "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. \n\nIf 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.",
"fixid": "F-79525r1_fix",
"fixtext": "Deploy an out-of-band network to provision paths between the SDN controllers and the SDN-enabled network elements for providing transport for southbound API control plane traffic.\n\nAn alternative is to encrypt all southbound API control 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.",
"iacontrols": null,
"id": "V-73079",
"ruleID": "SV-87731r1_rule",
"severity": "high",
"title": "Southbound API control plane traffic must traverse an out-of-band path or be encrypted using a FIPS-validated cryptographic module.",
"version": "NET-SDN-004"
},
"V-73081": {
"checkid": "C-73215r1_chk",
"checktext": "Determine if the northbound API traffic between the SDN controllers and the SDN management/orchestration systems traverses an out-of-band path. \n\nIf not, verify that the northbound API traffic is encrypted using a FIPS-validated cryptographic module.\n\nIf the northbound API traffic does not traverse an out-of-band path or is not encrypted using a FIPS-validated cryptographic module, this is a finding.\n\nNote: An out-of-band path would be a path between two nodes that traverses one or more links on an out-of-band network; that is, a dedicated layer 2 infrastructure separate from a production network.",
"description": "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. \n\nIn 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 southbound API traffic is secured by encrypting the traffic or deploying an out-of-band network for this traffic to traverse.",
"fixid": "F-79527r1_fix",
"fixtext": "Deploy an out-of-band network to provision paths between the SDN controllers and the SDN management/orchestration systems for providing transport for northbound API traffic. \n\nAn alternative is 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.",
"iacontrols": null,
"id": "V-73081",
"ruleID": "SV-87733r1_rule",
"severity": "high",
"title": "Northbound API traffic must traverse an out-of-band path or be encrypted using a FIPS-validated cryptographic module.",
"version": "NET-SDN-005"
},
"V-73083": {
"checkid": "C-73217r1_chk",
"checktext": "Verify that all southbound API management plane traffic is authenticated using a FIPS-approved message authentication code algorithm.\n\nReview SDN management and orchestration systems, as well as all hypervisor hosts that compose the NVP framework, to determine if a FIPS-approved message authentication code algorithm is used to ensure the authenticity and integrity of messages used to deploy and configure software-defined network elements. \n\nIf southbound API management plane traffic is not authenticated using a FIPS-approved message authentication code algorithm, this is a finding.",
"description": "Management and orchestration systems within the SDN framework instantiate, deploy, and configure virtual network elements. These systems also define the virtual network topology by specifying the connectivity between the network elements and the workloads, both virtual and physical.\n\nIf a hypervisor host within the SDN infrastructure were to receive fictitious information from a rogue management or orchestration system as a result of no authentication, the virtual network topology could be altered by deploying rogue network elements to create non-optimized network paths, resulting in inefficient application and business processes. By altering the network topology, the attacker would have the ability force traffic to bypass security controls.",
"fixid": "F-79529r1_fix",
"fixtext": "Configure these components to use a FIPS-approved message authentication code algorithm to authenticate southbound API management messages.",
"iacontrols": null,
"id": "V-73083",
"ruleID": "SV-87735r1_rule",
"severity": "medium",
"title": "Southbound API management plane traffic for provisioning and configuring virtual network elements within the SDN infrastructure must be authenticated using a FIPS-approved message authentication code algorithm.",
"version": "NET-SDN-006"
},
"V-73085": {
"checkid": "C-73219r1_chk",
"checktext": "Determine if the southbound API management plane traffic traverses an out-of-band path. \n\nIf not, verify that the southbound API management plane traffic is encrypted using a using a FIPS-validated cryptographic module.\n\nIf the southbound API management 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.",
"description": "Management and orchestration systems within the SDN framework instantiate, deploy, and configure network elements within the SDN infrastructure. These systems also define the virtual network topology by specifying the connectivity between the network elements and the workloads, both virtual and physical.\n\nIf a hypervisor host within the SDN infrastructure were to receive fictitious information from a rogue management or orchestration system, the virtual network topology could be altered by deploying rogue network elements to create non-optimized network paths, resulting in inefficient application and business processes. By altering the network topology, the attacker would have the ability to force traffic to bypass security controls. \n\nSpoofed management plane traffic generated by a rogue management system could result in a denial-of-service attack on the hypervisor hosts, exhausting the computing resources and disrupting workload processing or even creating a network outage. Hence, it is imperative that all SDN management plane traffic is secured by encrypting the traffic or deploying an out-of-band network for this traffic to traverse.",
"fixid": "F-79531r1_fix",
"fixtext": "Deploy an out-of-band network to provision paths between management systems, orchestrations systems, and all hypervisor hosts that compose the SDN infrastructure to provide transport for southbound API management plane traffic. \n\nAn alternative is to encrypt all southbound API management plane traffic using a FIPS-validated cryptographic module. Implement a cryptographic module that has a validation certification and is listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.",
"iacontrols": null,
"id": "V-73085",
"ruleID": "SV-87737r1_rule",
"severity": "medium",
"title": "Southbound API management plane traffic for provisioning and configuring virtual network elements within the SDN infrastructure must traverse an out-of-band path or be encrypted using a using a FIPS-validated cryptographic module.",
"version": "NET-SDN-007"
},
"V-73087": {
"checkid": "C-73221r1_chk",
"checktext": "Review both management and orchestration systems, as well as all SDN controllers and physical SDN-enabled network elements that compose the network virtualization platform (NVP), to determine if certificate-based authentication is used to ensure the authenticity and integrity of southbound API management messages. If southbound API management plane traffic is not authenticated using DOD PKI certificates, this is a finding.",
"description": "Physical SDN-enabled switches are dependent on the SDN controller for their forwarding tables as well as their configuration and service parameters. This information is provided to the switches via SDN management plane protocols such as Network Configuration Protocol (NETCONF) and Open vSwitch Database Management Protocol (OVSDB). The latter provides configuration support for OpenFlow-enabled switches such as Open vSwitch, as well as many vendor switches.\n\nWithout authenticating management packets, physical switches within the SDN infrastructure could receive fictitious information from a rogue management system that could shut down interfaces, thereby altering the physical network topology. By altering the network topology, the attacker would have the ability to force traffic to bypass security controls. Legitimate traffic could be dropped by deploying access control lists to active interfaces. Spoofed management plane traffic generated by a rogue management system could result in a denial-of-service attack on the switches, resulting in a network outage.",
"fixid": "F-79533r1_fix",
"fixtext": "Deploy DOD PKI certificates to all orchestration systems, management systems, and physical SDN-enabled network elements. \n\nConfigure these components to use the certificates to authenticate southbound API management messages.",
"iacontrols": null,
"id": "V-73087",
"ruleID": "SV-87739r1_rule",
"severity": "medium",
"title": "Southbound API management plane traffic for configuring SDN parameters on physical network elements must be authenticated using DOD PKI certificate-based authentication.",
"version": "NET-SDN-008"
},
"V-73089": {
"checkid": "C-73223r1_chk",
"checktext": "Determine if the southbound API management plane traffic is encrypted using a FIPS-validated cryptographic module. If the Southbound API management plane traffic is not encrypted using a FIPS-validated cryptographic module, this is a finding.",
"description": "Physical SDN-enabled switches are dependent on the SDN controller for their forwarding tables, as well as their configuration and service parameters. This information is provided to the switches via SDN management plane protocols such as Network Configuration Protocol (NETCONF) and Open vSwitch Database Management Protocol (OVSDB). The latter provides configuration support for OpenFlow-enabled switches such as Open vSwitch, as well as many vendor switches.\n\nIf a switch within the SDN infrastructure were to receive fictitious information from a rogue management system, the physical network topology could be altered by shutting down interfaces. Legitimate traffic could be dropped by deploying access control lists to active interfaces. By altering the network topology, the attacker would have the ability to force traffic to bypass security controls. Spoofed management plane traffic generated by a rogue management system could result in a denial-of-service attack on the switches, resulting in a network outage. Hence, it is imperative that all SDN management plane traffic is secured by encrypting the traffic using a FIPS-validated cryptographic module.",
"fixid": "F-79535r1_fix",
"fixtext": "Encrypt all southbound API management plane traffic using a using a FIPS-validated cryptographic module. Implement a cryptographic module that has a validation certification and is listed on the NIST Cryptographic Module Validation Program's (CMVP) validation list.",
"iacontrols": null,
"id": "V-73089",
"ruleID": "SV-87741r1_rule",
"severity": "medium",
"title": "Southbound API management plane traffic for configuring SDN parameters on physical network elements must be encrypted using a FIPS-validated cryptographic module.",
"version": "NET-SDN-009"
},
"V-73091": {
"checkid": "C-73225r1_chk",
"checktext": "Review the SDN infrastructure topology to verify that the all physical SDN controllers, management appliances, and servers hosting SDN applications reside within the management network that has multiple paths and is also secured by a firewall. \n\nIf these physical NVP components do not reside within the management network with multiple paths, and are not secured by a firewall, this is a finding. \n\nNote: If the SDN physical components reside within an out-of-band network, this requirement would not be applicable.",
"description": "Management and orchestration systems deploy and configure network devices such as switches and routers, both physical and virtual. SDN controllers are made aware of the deployments and are able to define the network topology through abstraction. The controllers are then able to provide forwarding table information to each router or switch instance within the SDN infrastructure. \n\nIf 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 to perform a man-in-the-middle attack.\n\nIf attackers could leverage a vulnerable northbound API, they would have control over the SDN infrastructure through the controller by creating their own polices. If the SDN controller were to receive fictitious information from a rogue application, non-optimized network paths would be produced that could disrupt network operations, resulting in inefficient application and business processes.\n\nIf either the orchestration or management system were breached, invalid network service requests could be processed that could exhaust compute, storage, and network resources, leaving no resources available for legitimate business requirements.",
"fixid": "F-79537r1_fix",
"fixtext": "Deploy all physical controllers, management appliances, and servers hosting SDN applications into the management network with multiple paths that are secured by a firewall inspecting all ingress traffic.",
"iacontrols": null,
"id": "V-73091",
"ruleID": "SV-87743r1_rule",
"severity": "medium",
"title": "Physical SDN controllers and servers hosting SDN applications must reside within the management network with multiple paths that are secured by a firewall to inspect all ingress traffic.",
"version": "NET-SDN-010"
},
"V-73093": {
"checkid": "C-73227r1_chk",
"checktext": "Review the configurations for all SDN-enabled routers and switches and verify that link state information is provided to the SDN controllers. \n\nIf the SDN-enabled routers and switches do not provide link state information to the SDN controllers, this is a finding.\n\nNote: This requirement is not applicable if the SDN deployment model does not rely on the controller for network forwarding or convergence.",
"description": "Southbound APIs such as OpenFlow provide the forwarding tables to network devices such as switches and routers. SDN controllers have an abstraction of the network topology based on discovery and provisioning information provided by management and orchestration systems. \n\nThe 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. With the network topology abstraction, they are able to determine how traffic should flow through network devices based on application data, business policy, bandwidth, and path availability. If the SDN-enabled network elements do not provide updated link state information, the SDN controller is not able to reconverge the network to verify there is reachability to all destinations.",
"fixid": "F-79539r2_fix",
"fixtext": "Configure all SDN-enabled routers and switches to send link state information to the SDN controllers.",
"iacontrols": null,
"id": "V-73093",
"ruleID": "SV-87745r1_rule",
"severity": "low",
"title": "SDN-enabled routers and switches must provide link state information to the SDN controller to create new forwarding decisions for the network elements.",
"version": "NET-SDN-011"
},
"V-73095": {
"checkid": "C-73229r3_chk",
"checktext": "Note: This requirement will not be applicable if an out-of-band network is used to transport SDN control and management plane traffic.\n\nReview the router and multilayer switch configurations to verify that SDN control and management plane packets are receiving the appropriate amount of priority to ensure this traffic has preference over normal production traffic. \n\nIf not all routers and multilayer switches impose preferred treatment for SDN control and management plane traffic during periods of congestion, this is a finding.",
"description": "With the network topology abstraction, the SDN controllers are able to determine how traffic should flow through network devices based on application data, business policy, bandwidth, and path availability. When updated link state information is provided by the network elements, the SDN controller must recalculate the optimized paths for network reconvergence and provide the new forwarding tables to the network elements. \n\nWhen network congestion occurs, all traffic has an equal chance of being dropped. QoS provisioning categorizes network traffic, prioritizes it according to its relative importance, and provides preferential treatment using various priority queuing techniques. Prioritization of both link state updates and control plane traffic must be implemented to verify that during periods of severe network congestion, the network can converge.",
"fixid": "F-79541r1_fix",
"fixtext": "Determine the paths in which SDN control and management plane traffic will flow between the SDN controllers and SDN-enabled switches and routers. \n\nConfigure each router and multilayer switch to impose preferred treatment for this traffic so it has priority over normal production traffic during periods of congestion.",
"iacontrols": null,
"id": "V-73095",
"ruleID": "SV-87747r1_rule",
"severity": "low",
"title": "Quality of service (QoS) must be implemented on the underlying IP network to provide preferred treatment for traffic between the SDN controllers and SDN-enabled switches and hypervisors.",
"version": "NET-SDN-012"
},
"V-73097": {
"checkid": "C-73231r1_chk",
"checktext": "Review the network virtualization platform topology and the SDN configuration to verify that SDN controllers have been deployed as clusters on separate physical hosts. \n\nIf the SDN controllers have not been deployed as clusters on separate physical hosts, this is a finding.",
"description": "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.\n\nWith 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.",
"fixid": "F-79543r1_fix",
"fixtext": "Deploy SDN controllers as clusters on separate physical hosts to eliminate single point of failure.",
"iacontrols": null,
"id": "V-73097",
"ruleID": "SV-87749r1_rule",
"severity": "medium",
"title": "SDN controllers must be deployed as clusters and on separate physical hosts to eliminate single point of failure.",
"version": "NET-SDN-013"
},
"V-73099": {
"checkid": "C-73233r1_chk",
"checktext": "Review the network topology as well as the physical connection between the physical device hosting an SDN controller and the switches. \n\nThe device must have NIC teaming enabled and must be dual homed, with each upstream link connected to a different switch. \n\nIf the physical device hosting an SDN controller is not connected to two switches using NIC teaming, this is a finding.",
"description": "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.\n\nWith 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. Hence, it is imperative that all physical devices hosting an SDN controller are connected to two switches using NIC teaming to guarantee network high availability.",
"fixid": "F-79545r1_fix",
"fixtext": "Enable NIC teaming on the device hosting an SDN controller in either Link Aggregation Control Protocol (LACP) or switch-independent mode. \n\nConnect each interface to a different access switch.",
"iacontrols": null,
"id": "V-73099",
"ruleID": "SV-87751r1_rule",
"severity": "low",
"title": "Physical devices hosting an SDN controller must be connected to two switches for high-availability.",
"version": "NET-SDN-014"
},
"V-73101": {
"checkid": "C-73235r1_chk",
"checktext": "Review the parameters provided by the SDN manager or controller when deploying router or switch instances to determine if they set a threshold on the number of unknown data plane packets that are allowed to be punted by a virtual router or switch to the controller within a specific amount of time. \n\nReview the configuration of all physical SDN-enabled switches and routers and verify that packet-in messages are rate limited. \n\nIf SDN-enabled routers and switches do not rate limit the amount of unknown data plane packets that are punted to the SDN controller, this is a finding.",
"description": "SDN-enabled forwarding devices are dependent on the SDN controller for their forwarding tables as well as their configuration and service parameters. 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 pre-populates forwarding tables to the forwarding devices. \n\nAt 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 or punt it to the controller to receive forwarding instructions. Upon receiving the punted packet, the controller must determine how to forward the packet, create a rule, and populate a new forwarding table to the forwarding device. High rates of punted packets result in excessive controller CPU and memory utilization. Hence, a denial-of-serve attack targeting the SDN controller can be perpetrated either inadvertently or maliciously, involving high rates of packets for new flows that must be punted to the controller.",
"fixid": "F-79547r1_fix",
"fixtext": "Configure the SDN manager or controller to set a threshold on the number of unknown data plane packets that are allowed to be punted by a virtual router or switch to the controller within a specific amount of time. \n\nConfigure all physical SDN-enabled switches and routers to rate limit the amount of packets that are punted to the SDN controller.",
"iacontrols": null,
"id": "V-73101",
"ruleID": "SV-87753r1_rule",
"severity": "low",
"title": "SDN-enabled routers and switches must rate limit the amount of unknown data plane packets that are punted to the SDN controller.",
"version": "NET-SDN-015"
},
"V-73103": {
"checkid": "C-73237r1_chk",
"checktext": "Review all servers hosting an SDN controller and verify that logging has been enabled. \n\nIf logging is not enabled on all servers hosting an SDN controller, this is a finding.",
"description": "It is critical for both network and security personnel to be aware of the state of the SDN infrastructure to maintain network stability. Associating logged events that have occurred within the SDN controller as well as network state information provided by the SDN-enabled components is essential to compile an accurate risk assessment and troubleshoot network outages.",
"fixid": "F-79549r1_fix",
"fixtext": "Enable logging on all servers hosting an SDN controller.",
"iacontrols": null,
"id": "V-73103",
"ruleID": "SV-87755r1_rule",
"severity": "medium",
"title": "Servers hosting SDN controllers must have logging enabled.",
"version": "NET-SDN-016"
},
"V-73105": {
"checkid": "C-73239r1_chk",
"checktext": "Review all servers hosting an SDN controller and verify that an HIDS has been installed and enabled.\n\nIf an HIDS has not been installed and enabled on all servers hosting an SDN controller, this is a finding.",
"description": "The SDN controller is the backbone of the SDN infrastructure. If the server hosting the SDN controller is breached or if unauthorized changes are made to the device, the SDN controller may not have the appropriate resources to function properly or may even be disabled. A host intrusion detection system (HIDS) can monitor and report system configuration changes and prevent malicious or anomalous activity.",
"fixid": "F-79551r1_fix",
"fixtext": "Install and enable an HIDS on all servers hosting an SDN controller.",
"iacontrols": null,
"id": "V-73105",
"ruleID": "SV-87757r1_rule",
"severity": "medium",
"title": "Servers hosting SDN controllers must have an HIDS implemented to detect unauthorized changes.",
"version": "NET-SDN-018"
},
"V-73107": {
"checkid": "C-73241r1_chk",
"checktext": "Review the VXLAN topology and documentation for the SDN deployment that identifies each VXLAN segment and distributed logical switch. \n\nReview the configuration of all physical VXLAN-enabled switches to verify that the applicable VNIs are defined. \n\nIf the applicable VNIs have not been defined on all VXLAN-enabled switches, this is a finding.\n\nNote: This requirement is applicable to the implementation of technologies similar to VXLAN (e.g., NVGRE, STT) for the purpose of transporting traffic between virtual machines residing on different physical hosts.",
"description": "VXLAN is a Layer 2 network that overlays a Layer 3 network; that is, it creates a Layer 2 adjacency across a routed IP fabric. Each Layer 2 overlay network is known as a VXLAN segment and is identified by a unique segment ID called a VXLAN Network Identifier (VNI). \n\nThe VXLAN network enables virtual machines with the same VNI deployed on different hosts to communicate with each other. Virtual machines are identified uniquely by the combination of the MAC addresses of their virtual network interface card (NIC) and VNI. Hence, it is possible to have duplicate MAC addresses within the SDN infrastructure while in different VXLAN segments. Within the VXLAN architecture, virtual tunnel endpoints (VTEPs) perform the encapsulation and de-encapsulation of the layer-2 traffic. The VXLAN segments are independent of the underlying network topology; conversely, the underlying IP network between VTEPs is independent of the VXLAN overlay. It routes the encapsulated packets based on the outer IP address header, which has the initiating VTEP as the source IP address and the terminating VTEP as the destination IP address. \n\nThe VTEP must be configured with the appropriate VNIs to enable the VTEP to build forwarding tables for active VXLAN segments (Layer 2 domains) by learning MAC addresses per VNI packet flows.",
"fixid": "F-79553r1_fix",
"fixtext": "Define all applicable member VNIs on each VXLAN-enabled switch.",
"iacontrols": null,
"id": "V-73107",
"ruleID": "SV-87759r1_rule",
"severity": "medium",
"title": "All Virtual Extensible Local Area Network (VXLAN) enabled switches must be configured with the appropriate VXLAN network identifier (VNI) to ensure VMs can send and receive all associated traffic for their Layer 2 domain.",
"version": "NET-SDN-020"
},
"V-73109": {
"checkid": "C-73243r1_chk",
"checktext": "Review the VXLAN topology and documentation for the SDN deployment that identifies each VXLAN segment via VNI, VLAN membership, and the VLAN-to-VNI mapping to be implemented. \n\nReview the VTEP configuration of all physical VXLAN-enabled switches to verify that the appropriate VLAN-to-VNI mapping has been defined. \n\nIf the correct VLAN-to-VNI mapping has not been configured on all VXLAN-enabled switches, this is a finding.\n\nNote: This requirement is only applicable to VNIs that must be defined on each VXLAN-enabled switch. In addition, this requirement is applicable to the implementation of technologies similar to VXLAN (e.g., NVGRE, STT) for the purpose of transporting traffic between virtual machines residing on different physical hosts.",
"description": "VXLAN is a Layer 2 network that overlays a Layer 3 network; that is, it creates a Layer 2 adjacency across a routed IP fabric. Each Layer 2 overlay network is known as a VXLAN segment and is identified by a unique segment ID called a VXLAN Network Identifier (VNI). \n\nThe VXLAN network enables virtual machines with the same VNI deployed on different hosts to communicate with each other. Virtual machines are identified uniquely by the combination of the MAC addresses of their virtual network interface card (NIC) and VNI. Hence, it is possible to have duplicate MAC addresses within the SDN infrastructure while in different VXLAN segments. Within the VXLAN architecture, virtual tunnel endpoints (VTEPs) perform the encapsulation and de-encapsulation of the layer-2 traffic. The VXLAN segments are independent of the underlying network topology; conversely, the underlying IP network between VTEPs is independent of the VXLAN overlay. It routes the encapsulated packets based on the outer IP address header, which has the initiating VTEP as the source IP address and the terminating VTEP as the destination IP address.\n\nVTEP-enabled switches will determine the VNI to insert into the VXLAN header based on the 802.1Q VLAN tag of each frame received from the hypervisor host connected via trunk link or the VLAN assignment of an access switchport. The mapping of VLAN to VNI is configured on the switch. Since the VNI is used to segregate all Layer 2 domains, the correct mapping is critical to ensure all traffic for each Layer 2 domain within the SDN infrastructure is forwarded correctly and that broadcast and multicast traffic does not leak into the wrong domain.",
"fixid": "F-79555r1_fix",
"fixtext": "Configure the appropriate VLAN-to-VNI mapping on all VXLAN-enabled switches.",
"iacontrols": null,
"id": "V-73109",
"ruleID": "SV-87761r1_rule",
"severity": "medium",
"title": "Virtual Extensible Local Area Network (VXLAN) identifiers must be mapped to the appropriate VLAN identifiers.",
"version": "NET-SDN-021"
},
"V-73111": {
"checkid": "C-73245r1_chk",
"checktext": "Review the VXLAN topology as well as documentation for the SDN deployment that identifies each VXLAN segment via VNI and the associated multicast groups. \n\nReview the VTEP configuration of all physical VXLAN-enabled switches to verify that the appropriate multicast group is defined for each VNI. \n\nIf the appropriate multicast group is not configured for each member VNI, this is a finding.\n\nNote: This requirement is only applicable to VNIs that must be defined on each VXLAN-enabled switch. In addition, this requirement is applicable to the implementation of technologies similar to VXLAN (e.g., NVGRE, STT) for the purpose of transporting traffic between virtual machines residing on different physical hosts.",
"description": "VXLAN is a Layer 2 network that overlays a Layer 3 network; that is, it creates a Layer 2 adjacency across a routed IP fabric. Each Layer 2 overlay network is known as a VXLAN segment and is identified by a unique segment ID called a VXLAN Network Identifier (VNI). \n\nThe VXLAN network enables virtual machines with the same VNI deployed on different hosts to communicate with each other. Virtual machines are identified uniquely by the combination of the MAC addresses of their virtual network interface card (NIC) and VNI. Hence, it is possible to have duplicate MAC addresses within the SDN infrastructure while in different VXLAN segments. Within the VXLAN architecture, VTEPs perform the encapsulation and de-encapsulation of the layer-2 traffic. The VXLAN segments are independent of the underlying network topology; conversely, the underlying IP network between VTEPs is independent of the VXLAN overlay. It routes the encapsulated packets based on the outer IP address header, which has the initiating VTEP as the source IP address and the terminating VTEP as the destination IP address.\n\nEach VXLAN segment is mapped to an IP multicast group in the transport IP network. Hence, VTEPs join IP multicast groups based on VNI membership. This is the method by which VTEPs can discover other VTEPs belonging to the same VXLAN segment. Each VTEP-enabled switch is configured to join the applicable multicast group for each VNI through Internet Group Management Protocol (IGMP). The IGMP joins will trigger Protocol Independent Multicast (PIM) joins, thereby signaling a multicast distribution tree for each group through the transport network based on the locations of participating VTEPs.\nThe multicast group is used to transmit broadcast, unknown unicast, and multicast traffic through the IP network for each VXLAN segment, limiting all Layer 2 flooding to those switches that have end systems participating in the same VXLAN segment.\n\nBecause the VNI is used to segregate all Layer 2 domains via the VXLAN header encapsulation by the VTEPs, and discovery of each VTEP member is dependent on a specific multicast group, it is imperative that the correct mapping of multicast groups to VNI is configured.",
"fixid": "F-79557r1_fix",
"fixtext": "Configure the appropriate multicast group that is assigned to each VNI on all VXLAN-enabled switches.",
"iacontrols": null,
"id": "V-73111",
"ruleID": "SV-87763r1_rule",
"severity": "medium",
"title": "The proper multicast group for each Virtual Extensible Local Area Network (VXLAN) identifier must be mapped to the appropriate virtual tunnel endpoint (VTEP) so the VTEP will join the associated multicast groups.",
"version": "NET-SDN-022"
},
"V-73113": {
"checkid": "C-73247r1_chk",
"checktext": "Review the VXLAN topology and the configuration of all hypervisor hosts and VXLAN-enabled switches to verify that every VTEP is dual-homed to two physical network nodes. \n\nIf any VTEPs are not dual-homed to two physical network nodes, this is a finding.\n\nNote: This requirement is only applicable to VNIs that must be defined on each VXLAN-enabled switch. In addition, this requirement is applicable to the implementation of technologies similar to VXLAN (e.g., NVGRE, STT) for the purpose of transporting traffic between virtual machines residing on different physical hosts.",
"description": "If uplink connectivity for the VTEP to the Virtual Extensible Local Area Network (VXLAN) transport network fails, traffic to and from the VM servers resident on the affected hypervisor host is dropped. Whether it is a hardware (VXLAN-enabled switch) or software (hypervisor resident) VTEP, dedicating a pair of physical uplinks from the VTEP to two separate network nodes adds high availability and resiliency to the VXLAN implementation. If either an uplink or one of the attached network nodes fails, the VTEP would still have connectivity to the underlying IP network for VXLAN traffic.",
"fixid": "F-79559r1_fix",
"fixtext": "Configure all hypervisor hosts and VXLAN-enabled switches so the VTEP will be dual-homed to two physical network nodes. \n\nIn the case of the VXLAN-enabled switch, the VTEP will be the loopback interface; hence, dual-homing can be achieved by having two links going upstream to two switches or to two routers. \n\nThe hypervisor can use network interface card (NIC) teaming for the VTEP interface, with each link connected to an access switch.",
"iacontrols": null,
"id": "V-73113",
"ruleID": "SV-87765r1_rule",
"severity": "low",
"title": "The virtual tunnel endpoint (VTEP) must be dual-homed to two physical network nodes.",
"version": "NET-SDN-024"
},
"V-73115": {
"checkid": "C-73249r1_chk",
"checktext": "Review the VXLAN topology to determine if any hypervisor hosts are dual-homed to two VXLAN-enabled switches deployed as multi-chassis configuration (e.g., vPC domain, MLAG, MCLAG, etc.) to function as a single VTEP. \n\nFor VXLAN-enabled switches deployed as a multi-chassis configuration, review the configuration to verify that a secondary IP address has been defined for the VTEP loopback interface. \n\nIf a secondary IP address has not been configured for the VTEP, this is a finding.",
"description": "A multi-chassis configuration (i.e., vPC domain, MLAG, MCLAG, etc.) can be used to attach a hypervisor host to a pair of VXLAN-enabled switches. For example, a vPC consists of two vPC peer switches connected by a vPC peer link. A vPC domain is formed by the two switches; one switch is primary and the other is secondary. A switch can only be part of one vPC domain, and only two switches can make up a vPC domain.\n\nA vPC allows links that are physically connected to two different switches to appear as a single port channel to a third device, which can be another switch or a server that supports Link Aggregation Control Protocol (LACP) as defined in IEEE 802.1AX, 802.1aq, and 802.3ad. With vPC deployment, the loopback interface that is acting as the source-interface for the VTEP will use the secondary IP address to function as the anycast IP address if the hypervisor host is dual-attached through the vPC. When a host is single-attached (orphan port), the VXLAN-encapsulated traffic will be sent using the loopback\u2019s primary address.",
"fixid": "F-79561r1_fix",
"fixtext": "Configure a secondary IP address for all VTEP loopback interfaces for VXLAN-enabled switches deployed as a multi-chassis configuration to function as a single VTEP for dual-homed attached hypervisor hosts.",
"iacontrols": null,
"id": "V-73115",
"ruleID": "SV-87767r1_rule",
"severity": "low",
"title": "A secondary IP address must be specified for the virtual tunnel endpoint (VTEP) loopback interface when Virtual Extensible Local Area Network (VXLAN) enabled switches are deployed as a multi-chassis configuration.",
"version": "NET-SDN-025"
},
"V-73117": {
"checkid": "C-73251r1_chk",
"checktext": "Review the network topology diagram for both the physical infrastructure and the NVP to determine if two or more edge gateways have been deployed between the virtual and physical networks. \n\nIf two or more edge gateways connecting the NVP and the physical network have not been deployed, this is a finding.\n\nNote: This requirement is not applicable if hardware switches are deployed as VTEP devices that also function as gateways between VXLANs and between VXLAN and non-VXLAN infrastructures.",
"description": "An edge gateway is deployed to allow north-south traffic to flow between the virtualized network and the physical network, including destinations outside of the data center or enclave boundaries. The gateway establishes routing adjacencies between the virtual routers and physical routers. The gateway can also filter the north-south traffic to enforce security policies for communication between the physical and virtual workloads. Deploying two or more edge gateways eliminates the risk of a single point of failure, thereby ensuring there is always reachability between virtual machines and the physical network infrastructure and reducing the risk of black-holing north-south traffic.",
"fixid": "F-79563r1_fix",
"fixtext": "Deploy two or more edge gateways connecting the network virtualization platform and the physical network.",
"iacontrols": null,
"id": "V-73117",
"ruleID": "SV-87769r1_rule",
"severity": "low",
"title": "Two or more edge gateways must be deployed connecting the network virtualization platform (NVP) and the physical network.",
"version": "NET-SDN-027"
},
"V-73119": {
"checkid": "C-73253r1_chk",
"checktext": "Review the network virtualization platform topology and the SDN manager to verify that each virtual edge gateway has been deployed across multiple hypervisor hosts. \n\nIf each virtual edge gateway has not been deployed across multiple hypervisor hosts, this is a finding.",
"description": "An edge gateway is deployed to allow north-south traffic to flow between the virtualized network and the physical network, including destinations outside of the data center or enclave boundaries. The gateway can also filter the north-south traffic to enforce security policies for communication between the physical and virtual workloads. If the edge gateways deployed as virtual machines are resident on the same host, the host becomes a single point of failure for all communication between the virtual workload and the physical network infrastructure. Deploying the edge gateways across multiple hypervisor hosts eliminates the risk of a single point of failure, thereby ensuring there is always reachability between virtual machines and the physical network infrastructure and reducing the risk of black-holing north-south traffic.",
"fixid": "F-79565r1_fix",
"fixtext": "Deploy each virtual edge gateway across multiple hypervisor hosts.",
"iacontrols": null,
"id": "V-73119",
"ruleID": "SV-87771r1_rule",
"severity": "low",
"title": "Virtual edge gateways must be deployed across multiple hypervisor hosts.",
"version": "NET-SDN-028"
},
"V-73121": {
"checkid": "C-73255r1_chk",
"checktext": "Review the network topology diagram for both the physical infrastructure and the network virtualization platform (NVP) to determine if the virtual edge gateways have routing adjacencies with two or more physical routers. In addition, verify that the router adjacencies are established by having the administrator enter the appropriate commands that will show the neighbor relationship between the edge gateway and upstream routers. \n\nIf the virtual edge gateway does not have routing adjacencies established with two or more physical routers, this is a finding.",
"description": "An edge gateway is deployed to allow north-south traffic to flow between the virtualized network and the physical network, including destinations outside of the data center or enclave boundaries. The gateway establishes routing adjacencies between the virtual routers and physical routers. The gateway can also filter the north-south traffic to enforce security policies for communication between the physical and virtual workloads. \n\nImplementing the edge gateway in either active/standby or equal-cost multipath (ECMP) mode ensures there is always a virtual router to forward north-south traffic, assuming there is always a routing adjacency with a router in the physical network infrastructure. Having an adjacency with only one physical router creates a single point of failure regardless of the number of links deployed, there would be no connectivity between the virtual and physical workloads if a node failure occurred. Hence, it is imperative that each edge gateway is deployed with connectivity to two physical routers.",
"fixid": "F-79567r1_fix",
"fixtext": "Configure the virtual edge gateways to have routing adjacencies established with two or more physical routers.",
"iacontrols": null,
"id": "V-73121",
"ruleID": "SV-87773r1_rule",
"severity": "low",
"title": "The virtual edge gateways must be deployed with routing adjacencies established with two or more physical routers.",
"version": "NET-SDN-029"
}
},
"profiles": {
"MAC-1_Classified": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-1_Classified",
"title": "I - Mission Critical Classified"
},
"MAC-1_Public": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-1_Public",
"title": "I - Mission Critical Public"
},
"MAC-1_Sensitive": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-1_Sensitive",
"title": "I - Mission Critical Sensitive"
},
"MAC-2_Classified": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-2_Classified",
"title": "II - Mission Support Classified"
},
"MAC-2_Public": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-2_Public",
"title": "II - Mission Support Public"
},
"MAC-2_Sensitive": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-2_Sensitive",
"title": "II - Mission Support Sensitive"
},
"MAC-3_Classified": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-3_Classified",
"title": "III - Administrative Classified"
},
"MAC-3_Public": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-3_Public",
"title": "III - Administrative Public"
},
"MAC-3_Sensitive": {
"description": "",
"findings": {
"V-73073": "true",
"V-73075": "true",
"V-73077": "true",
"V-73079": "true",
"V-73081": "true",
"V-73083": "true",
"V-73085": "true",
"V-73087": "true",
"V-73089": "true",
"V-73091": "true",
"V-73093": "true",
"V-73095": "true",
"V-73097": "true",
"V-73099": "true",
"V-73101": "true",
"V-73103": "true",
"V-73105": "true",
"V-73107": "true",
"V-73109": "true",
"V-73111": "true",
"V-73113": "true",
"V-73115": "true",
"V-73117": "true",
"V-73119": "true",
"V-73121": "true"
},
"id": "MAC-3_Sensitive",
"title": "III - Administrative Sensitive"
}
},
"slug": "sdn_using_nv",
"title": "SDN Using NV Security Technical Implementation Guide",
"version": "1"
}
}