Software-Defined Secure Networks: An Interview with Ken O’Kelly, Consulting Engineer, Juniper Networks

KEN O’KELLY HAS BEEN A KEY CONSULTANT IN JUNIPER NETWORKS; UK AND IRELAND SECURITY BUSINESS FOR THE PAST FOUR AND A HALF YEARS. HE PREVIOUSLY HELD VARIOUS ROLES (LATTERLY AS A SECURITY ARCHITECT) DURING A 14 YEAR STINT WITH IMTECH ICT.

KEN TELLS AXIANS ABOUT JUNIPER’S LATEST SOFTWARE DEFINED SECURITY NETWORK (SDSN) SOLUTION AND HOW IT WILL MAKE LIFE EASIER FOR  IT DEPARTMENTS TASKED WITH CONTROLLING NETWORK ACCESS FOR THOUSANDS OF USERS.

Q: WHAT IS JUNIPER’S SOFTWARE DEFINED SECURITY NETWORK (SDSN)?

SDSN is all about changing how you build the network. Traditionally organisations have tended to build security into the perimeter and everything outside that perimeter is untrusted and everything inside it is trusted. That is a bit of a challenge these days given that we all take our laptops and smartphones outside of that trusted barrier when we go home, where malware can infect them and vulnerabilities can be compromised. We then bring the device back inside the network perimeter and now it is trusted again and that gives any threat carte blanche to get around the network.

SDSN doesn’t just put enforcement around the perimeter, but puts it right down to the ports inside the network. Not just the switches, but the routers, the WAN infrastructure and the firewalls too.

Q: HOW DOES SDSN CO-ORDINATE EFFECTIVE NETWORK SECURITY?

One of the key SDSN components is the policy enforcer, which ties all those firewalls, switches and routers together into a secure fabric. So if I am a user and I browse a website where I encounter malware, it comes through on the firewall which routes it onto the anti-malware service to get checked.

Q: SO HOW DOES THE ANTI MALWARE WORK?

The anti-malware service has a number of steps. It looks to see if it has seen that threat before, and if it has it will send it back to the firewall to block it. If it is a threat it has not seen before it will send it off for more detailed analysis. The malware goes into what is effectively a sandbox, but in our sandbox we perform some provocation and interception techniques to try and fool that malware into executing.

Obviously that takes a bit of time, so what happens then is that if we identify the piece of software as malware we will send a message to the policy enforcer which will decide based on the policy the IT department has set up on what actions to take.

Q: HOW WILL THE SDSN SOLUTION DEVELOP OVER THE NEXT 12 MONTHS?

Though it is not in its first version, the Policy Enforcer will effectively become an ecosystem that allows other vendors to plug into it. We have partnerships with a number of specialist malware detection companies for example, one being ATTIVIO. The ATTIVIO platform can tell the Policy Enforcer it has detected malware coming from a specific machine and gives it the choice again of pushing the policy out onto the switches, the firewalls and/or the routers and either taking that machine or the traffic off the network.

In the second phase of SDSN we will be able to talk to VMware NSX and Juniper Contrail network virtualisation platforms and be able to effect policies within the SDN overlay. So maybe if a virtual machine (VM) is being compromised or is sending out bad traffic, again we can effect policies to move those VMs out or even if necessary spin up containerised or virtual firewall to redirect traffic through isolated parts of network and create a micro-segmented environment.

Q: HOW IS SDSN DEPLOYED WITHIN THE NETWORK?

The Policy Enforcer works in conjunction with our Junos Space network management platform and Security Director application to manage Juniper routers, switches and firewalls. Security Director is specifically the application for managing firewalls and that will have the Policy Enforcer components as part of it. It will talk to the firewalls using Security Director, to the switches using a switching micro service and it will have a similar setup for talking to the routers in the near future too. Junos Space can be deployed on a piece of hardware from Juniper or you could try it on a VM.

Most or our beta customers do apply it as a VM, they don’t tend to go for the hardware these days.

Q: DOES SDSN FAVOUR NETWORKS BUILT ON JUNIPER HARDWARE?

The first iteration of SDSN is geared very much towards Juniper products – SRX firewalls and EX/QFX switches now and MX routers later. But it is very much the vision to support third party products in the future – branded equipment from other leading manufacturers in the market. In reality not everybody is an end to end Juniper customer, most are a blend of Juniper and other vendors so we would need to be able to support those vendors. It is becoming easier to do that because most of them support open frameworks like the Yang data modelling language. Using Yang models makes it much easier to communicate with third party equipment. The challenge is that Yang tends to be rolling out on newer network equipment and how many third party vendors we can support will depend on how many of those newer devices are out. We want to make sure it works on our own products first because it is easier to test that way, and worry about third parties at a later stage once we have fully baked the solution.

Q: WHAT INDUSTRY SECTORS DO YOU SEE POTENTIAL DEMAND FOR SDSN?

We are not limiting ourselves to one particular area. SDSN is very much applicable to campus and branch networks and enterprise and communication service provider networks. If I was to pick one specifically campus and branch would probably be seen as the sweet spot. We have also discussed the solution with network and content service providers who want to protect their own network, so if suddenly they find customers are downloading massive amounts of malware they may be able to action and isolate routes on their network to control that on a dynamic basis.