This was an introductory talk around Software Defined Networking (SDN) and some of it’s security implications.
What is it?
- Decoupling the control pane from the data plane and centralising logical controls
- Communication between network devices and SDN controllers is with both open and proprietary protocols currently – no single standard..
- SDN controller supports open interface to allow external programability of the environment
– Controller tells each node how to route, vs. current where each node makes it’s own routing decisions.
How do I enforce network security in an SDN environment?
- Switch as the Policy enforcement point
- Switch tells controller it’s seen traffic with certain flow characteristics, Flow controller tells it what to do with the flow, and this information is cached in the local flow table for a specified time. Another flow arrives and this one is not permitted, so the controller tells the switch to just drop the packets – switch effectively becomes a stageful firewall.
- Existing controls such as DLP, Firewalls, Proxy servers etc. can all be used with SDN –
- e.g. someone tries to connect to the internet – flow controller instructs switch to send traffic to the firewall / IPS / DLP server etc.
- e.g. sending email – no matter where it’s going flow says first point is DLP, then firewall, then onto destination
- This means devices no longer need to be inline – they can be anywhere on the network. Flow controller just needs to know where to send certain traffic types!
- Incoming flows can be treated in the same way
- Something changes – such that it looks like DDoS – traffic can be routed to the DDoS protection device(s)
What risks does SDN introduce?
- Risk is aggregated in the controller
- Malicious or accidental changes could remove some or all of the security protections
- Integrity of of the Flow Tables must be maintained
- Switches etc must be managed from controller, not locally
- Input from applications must be managed and prioritised
- Application APIs are non standard
- Who gets precedence?
- Load balancer vs. security tools when defining traffic flows?
SDN products do exist now.
- Standards do exist
- OpenFlow – maintained by Open Networking Foundation
- Network devices (early days)
- Open vSwitch
- Some products from Brocade, Cisco, HP, IBM
- Controllers (limited maturity)
- Floodlight (open source)
- Products from Big Switch Networks, Cisco, HP, NEC, NTT Data, VMware
- Applications (often tied to specific controllers)
- Radware and HP produce some security applications
- Do not overreact to SDN hype
- Combine IT disciplines when implementing SDN
- Don’t forget security!!
- Determine how existing control requirements can be met with SDN
- Examine how SDN impacts separation of duties
- Some similar issues to vitalisation
- Discuss SDN with your existing security vendors
- Deploy SDN in a lab or test environment
- PoC and understand fully before deploying
Overall this was an informative and fast paced talk. As per the speakers recommendations, SDN is a very interesting technology, although it is still in the emerging phase with the majority of deployments currently being in testing or academia. I wouldn’t yet recommend it for production Datacentre deployments, but I would recommend you become familiar with it, especially if you work in the networking or security fields.