search

commoncriteria / sdn-controller

Protection Profile for Software Defined Networking Controllers
The Unlicense
3 stars 0 forks source link

Distributed TOE requirements, cPP vs PP-mod, and vND vs pND use case #20

Open kenlasoski opened 7 months ago

kenlasoski commented 7 months ago

Does the threat model of an SDN controller differ substantially from that of a management server that is part of a distributed TOE?
Would the SDN controller be expected to satisfy the entire set of robustness requirements (e.g. must it enforce ALL of the base NDcPP requirements?).

In SDN architecture, an SDN controller manages multiple network devices deployed in various geolocations. The SDN controller normally sits inside of a secure enclave alongside a management server/orchestrator (commonly called a "headend"). The management server presents the primary Admin interface for an SDN solution. There is typically no outside access from the secure enclave except for the interface of the controller which is assigned to the WAN side which is used to create the secure overlay between the controller and distributed NDs.

It would be my opinion that an SDN controller should not be expected to satisfy the entire set of NDcPP requirements (if part of a distributed TOE), and can be joined to a "management server" as described in Section 3 case 2 of NDcPP. If it happens to be able to support the requirements by itself, that's great and should also be an allowed use case as well.

I am thinking there is a need for this distributed TOE use case where the management server can satisfy some of the requirements is for the following reasons:

  1. Some SDN products are designed to work with a management server and some may not be, so both cases should be considered. In the former case, it is common that the "SDN controller" runs the same exact firmware as the network device be it a firewall, IDS, gateway, etc, it is just performing a different role than the network device. In some cases, network devices simply cannot meet the NDcPP requirements as a standalone TOE (whether it be due to limitations of audit storage, performance reasons, reducing the attack surface by limiting the interfaces and functionality exposed, or other reasons). Since this is acceptable for a network device I would feel that it should also be acceptable for an SDN controller.
  2. Even if the controller device is able to support all the network device requirements as a standalone, there are very valid reasons why you would want to further reduce its attack surface by turning off services on its OOBM interface, and letting it instead be managed by the management server through a dedicated Ipsec tunnel or using another secure protocol. The remote management in this case would all be handled by the management server in the secure enclave and there wouldn't be a requirement to leave the OOBM interface of the device exposed (perhaps maybe the threat model needs to consider the varying levels of trust in terms of the networks attached to the device, even those attached to its dedicated management ports, and whether they need to be attached or not).

Next, I think we should consider if there is a need to modify the vND allowances from the base NDcPP to consider allowing two VMs (controller and management server) to co-exist on the same hypervisor, or if the current language fits the needs of the SDN PP. This of course ties into the PP vs PP-mod question, as I'm sure it would be more challenging if this use case is not already supported by NDcPP. (Kristy would be the expert on this question :)

This depends on whether you can define a collective of VMs running on a single host a "Network Device" per the definitions in the PP, or how you interpret the last bullet of vND Case 2:

"There are no other guest VMs on the physical platform providing non-network device functionality".

If we say the management server is indeed an ND then I think this can be satisfied. But this statement is specific to evaluating a vND as a pND. I myself am not clear on what applies in Case 1, whether or not this same restriction applies or whether you can have multiple VMs that are part of the TOE on a single hypervisor. I want to say I've encountered successful examples of this use case before but am unable to point to anything recent.

And then there's the argument, if the VMs are to be co-hosted on the same physical device, there maybe isn't as strong a need to secure the internal connections between the two headend VMs (while it would be nice if you could), but there may be limitations in that area as Jenn raised on the call.

I agree that the PP-mod is the most sensible route but to me the crux of it lies with how we address the above use cases and whether that creates any conflicts with the base PP.

One more point in favor of PP-mod, is that like FW, IPS/IDS, and VPN, like mentioned before, the SDN capability in many cases is simply a role or personality that you enable on an existing network device image, just like you would enable or disable FW and other roles, so it seems like creating a standalone PP would feel much like we are re-inventing the wheel. But this is admittedly an entirely subjective argument, not based in the actual mechanics of defining a PP vs PP-mod.

heimannrj commented 4 months ago

This is a really interesting analysis and I agree with the points made here. A couple of comments to add to the discussion: For the distributed use cases, I would be interested in unerstanding more if the SFRs governing intra-TOE comms (FTP_ITC, FTP_TRP, etc) can or should be further refined in a resulting pp-module to help harden the connections. For example, insisting IPsec be used vs TLS or HTTPS.

My understanding of vNDs is that multiple VMs can reside on one hypervisor if they are part of the distributed TOE. It is a little bit lost on me why this is bound to Use Case 2 (vND as a pND) but the exception is there: From the NDcPP p13:

There is only one vND instance for each physical hardware platform. The exception being a where components of the distributed TOE run inside more than one virtual machine (VM) on a single VS.

Regardless, I would advocate for maintaining the highest assurance of intra-TOE comms whether they be co-mingled within a hypervisor or not. There is an assumption in the PP:

4.2.11 A.VS_ISOLATON (applies to vNDs only) For vNDs, it is assumed that the VS provides, and is configured to provide sufficient isolation between software running in VMs on the same physical platform. Furthermore, it is assumed that the VS adequately protects itself from software running inside VMs on the same physical platform.

But there is also a threat about untrusted communication channels:

4.1.1.3 T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the Network Device itself.

Need to ensure that threat is mitigated the best we can.