For a refresher, read Part 1.
As legacy network architectures change with the adoption of new technologies such as SDN, so too do security architectures. SDN is enabling the world to move towards the era of embedded security.
Protecting against attacks with embedded security
Embedded security isn’t a new concept. A few years ago, the Jericho Forum was started with a view to developing a way of stopping network attacks against application infrastructure. The drive for setting up the forum was the rise in cyber attacks such as phishing, SQL and distributed denial of service (DDoS) attacks that give attackers access to internal systems.
One such technology is the Software Defined Perimeter (SDP). This technology re-architects the perimeter to provide advanced identity and application-specific access control. It is a far superior security model, and is particularly valuable for companies active in cloud-based environments.
25% of all data breaches remain undiscovered by the victim for weeks
Here’s another benefit: having to manage and secure increasing amounts of data means that full network visibility and transparency are essential. The network automation and orchestration gained via SDN and SDP delivers more data that can itself deliver valuable, timely alerts, enabling IT executives to perform security analytics. When you consider that 25% of all data breaches remain undiscovered by the victim for weeks (or even months), the importance of this becomes obvious.
So armed with all this information, how do you even start to think about transforming your network?
First and most obvious, you need to clearly define your objectives.
Understand and document what you want to achieve through the implementation of SDN, so that you can measure its success. Remember that while the reporting the financial success of any implementation is important, IT teams may lack the skills to effectively describe business benefits. Don’t let the hardware/software vendors lead your discussions, as they may have vested interests. Look at open systems and tools where available and understand how these can be supported and used across the organization.
You also need to consider SDN’s impact on your support structure. Explore how process and workflow can be improved, as this can often lead to a change in the support structure for operational teams. Instead of having compute, network and application teams, it is now quite common for organisations to move to an application-centric support model that includes staff with skills in server and network technologies. Tooling may need aligning to this support structure, and it’s important to identify these systems up front. A good configuration management database (CMDB) really can help to understand enterprise applications, the uses and value of these and the critical components in their delivery.
In conclusion, SDN really is here to stay. CIO evangelists tell us that SDN enables them to design their network to flex on demand to meet the demands of their business, rather than design to peak - with the added layer of security a bonus. Perhaps most compelling is the fact that, with these new technologies, the time of deployment can in some cases be reduced from 500 days to as few as 65. And this is why very early adopters have tended to include companies undergoing mergers and acquisitions, as SDN allows them to integrate acquisitions onboard faster.
Fast, secure, flexible. What’s not to like?
About the author(s): Lee Field is Associate Director for Solution Architecture, Asia, at Verizon.