Software Defined Networks (SDN) Need to be Defined by the Business

Post date: Jan 24, 2013 2:21:37 AM

Juniper has just joined the ranks of companies that have announced a software http://goo.gl/7dGg6. defined network strategy. Their strategy is centered on the idea of service chaining. A service chain is a list of services such as firewalls, load balances and other network services thru which data flows to go from one location to another. A service change might start all the way out in a branch office where the chain will ultimately lead to a data center and service inside a data center that meets the specific requirements of a client application. This service chaining is a very simple and powerful concept.

I think this vision make sense and will extend the reach of SDN beyond the datacenter and all the way out to the remote branch. This vision would help address many of the security and network segmentation problems I have worked with customer to address.

The problem that is does not address is how to assure that this SDN complies with all the business and regulator requirements often placed on a network. One example, that comes up on a regular basis is assuring that customer data does not enter a specific regulatory justification, specially European customers to not want their data to enter the US.

This is one example of the types of business requirements that are imposed on the design of a network. Other include things like PCI, HIPPA, SOX and GLBA in the US. There may be other reasons for specific requirements to be put on the network and the locations of data such as legal discovery and lawful data intercept. These are business requirements that define the network.

In a hardware defined network these types of business requirements are baked into the physical design of the network. The PCI data is stored and processed inside an isolated enclave inside a ring of firewall security controls. This type of secured network design is an important part of satisfying the security and audit requirements of PCI. In an enclave design the firewalls are just import for controlling the scope of an audit as they are for satisfying the requirements of an audit. Firewalls control the movement of data and network connections and the scope of audits.

When networks are software defined there needs to be a mechanism to assure that the orchestration layer implementing the network puts together service chains that meet the compliance requirements of the network. These meta requirements need to have an audit capability that shows the network and applications have been in compliance over time. This requires either additional functionality in the SDN orchestration software or upper layer process that defines and monitoring the compliance processes in a network. This abstraction of network and data compliance from the SDN orchestration can allow this process to both run across multiple vendors SDN platforms. The framework of a well defined network compliance requirements and methods to monitor that compliance would also be something that work help with physically defined and virtualized networks as we get to software defined networks.

Software Defined Network (SDN) is not a magic bullet to solve all our problems. In fact they may add more complexity and moving parts to a network that need to be tracked and controlled to assure that business risks are managed and the business processes running on the SDN are well supported. Business needs to define the network even as software is being used to implement that network definition.

This is going to be an on-going topic for this blog. Please add to the discussion.