How SDNs Change Cyber Security – Part II
Software defined networks (SDNs) reimagined how companies build networks. Now SDNs will force a major change in how companies secure those networks. To better understand the security implications of SDNs, we caught up with two of the co-chairs for ONUG’s Software-Defined Security Services (SDSS) Working Group. In How SDNs Change Cyber Security – Part I last month, we were able to get Adam Forch of FedEx’s reaction. Today, in the second installment, we hear Mike’s thoughts on the challenges facing SDN security.
There are a lot of ONUG Working Groups, why get involved with this one?
Security is often uncharted when considering centralized control. We can manage business rules centrally, but how the rules impact data flow largely remains undeveloped from an end-to-end security perspective. The biggest benefit that SDN brings is the removal of per-device policies. If we apply the same principles in security, we can centralize policy and we will be able to synchronize the state of each individual security device, making it a centrally controlled and fully distributed system. More times than not, security is an afterthought for new solutions and protocols, whereas the business value (direct and in-direct benefits) outweighs the risk consideration. New threat vectors and vulnerabilities aren’t typically exposed until the industry hits a specific adoption rate. We need to think and align security at the onset and across all dimensions of these emerging solutions. We need to accept that many applications may have different security needs, while consistent enforcement is a must to maintain a strong security posture.
What threats do you see specific to SDN? Which of those does the SDSS working group address?
Control plane and data flows within the enterprise are changing in the data center as well as the WAN. In the data center, we are moving away from old monolithic device based models that protected workflows in a static environment. Since the environment was static, the policies were static and distributed. In the new environment, we are moving to elastic cloud-based data centers where we need to build on-demand capacity and capabilities with distributed assets. The enterprise policies should follow, but how can we validate the security controls?
High scale encryption for these east-west traffic flows between machines without blinding our detection tools will be critical, while enabling packet captures from any point within the overlay and underlay. Your security controls should be as agile as your applications and remain consistent. For that, we again need a centralized policy definition with distributed enforcement and validation.
For the WAN, the change is even more pronounced. Earlier the data flowed only towards the data center and the exit points were well defined. We had a network with a hard edge and a soft center. New connectivity models require a virtual parameter. Although the hard parameter still exits, it is a lot more distributed compared to the central demilitarized zone (DMZ) model. Optimal user experience for cloud services needs the WAN’s egress point closest to cloud service. In addition, for users and devices inside the network, the concept of a soft center with hard parameter cannot provide strong security to deflect insider threats. Again, a proper security policy model will require centralized policies that adapt based on some level of behavioral anomaly detection.
What SDN components need to be secured?
All SDN components and entities need to be secured, including the controllers, programmed hardware, management platforms and interfaces. The integrity of the data path is critical, as is verifying authenticity and confidentiality of applications and interfaces to other tools. All communications need to be encrypted with seamless key management by the data custodian. We can’t afford vendors continuing to release privileged access vulnerabilities into customer production environments – patching tends to be an afterthought for many vendors.
What kind of tools do you see having to be developed to support SDSS?
More than tools, architecturally the SDSS approach must change. We need a model where both architect and operations interact with the entire network instead of individual nodes (the DevOps model). All of this has to be done without compromising authenticity, confidentiality, and integrity.
Why can’t we just use traditional security tools?
You need an architectural shift. You need to create a security system that is capable of self-healing by having different tools with a feedback loop to the controllers instead of individual devices. Evolving to an identity based network and making path and quarantine selection mid-stream can change the way we prevent and or detect anomalous behavior with data science built into the overall management platforms.
In some cases, traditional tools will be used – especially during migration. We need to build APIs and communication paths so information can be sent to the traditional tools and allow the tools to communicate bi-directionally with one another or with the controller. The network should respond and automate actions to best secure the data flow – data aware protection and path selection.
Finally, what are your bold predictions for the next 12 months?
I’ll give you two. First, the industry will offer a fully distributed security model with centralized policy. This will be a simple trust model; that is, once you are inside the network you are secure in terms of integrity and confidentiality. We will ensure access is tightly controlled based on location, application, device, and user. It’s about securing application services end-to-end not just in the intermediate points of the network.
Second, IoT will drive new business and connectivity models, such as cloud based service offerings. To support these new models, the enterprise will require new branch services to completely isolate not just segment.