Juniper Networks Software Defined Secure Network

What if your whole network was a security enforcement tool? Network as a firewall? Is it even possible?

Read what Sławek Balcerzak, BlueChipTek Sr. Solutions Architect has to say about SDSN technology introduced by Juniper Networks.


We are living in the world where almost every day brings innovations, new online services, and technologies. More and more data is stored in public or private clouds and SaaS approach causes that corporate and personal information is traversing between different parts of enterprise network and the Internet.

Obviously, cyber criminals don’t have vacations and weekends because getting access to all this information is too attractive vision to stop coming up with new techniques and methods to infiltrate systems.

In old days, corporate IT had clear demarcation lines. The whole environment could be divided into:

  • WE – everything that we know, internal systems, located in the office or own datacenter, proprietary information that doesn’t even leave the fenced area,
  • THEM – bad world outside, with cybercrime, the wild Internet, websites
  • MIDDLE GROUND – everything that we want to make available to remote workers or partners via the Internet, very limited set of services.

Such a simple model and the fact that most of the services could have been identified with TCP/UDP ports and IP addresses allowed uncomplicated stateful packet filtering firewalls sitting on the perimeter of the organization to provide relatively good protection.

Today’s reality is not that easy:

  • A great number of applications is based on HTTP/S protocol and ports 80/443, so security appliances need to look at the higher layers in protocol stack to distinguish one from another
  • Elements of corporate systems are both in the office and in the cloud, and communications between them need to be controlled, because of the limited trust
  • Data is stored both on and off premises, so not only protocols have to be controlled but also files that are being sent back and forth and file extraction from the flow and their analysis is necessary
  • Malicious activities or data can be hidden in seemingly harmless application traffic
  • Malware campaigns frequently have a very short time span, so with traditional approach, without any automation, security teams may be able to see the results of it until after the fact instead of preventing the propagation
  • Continuously changing techniques and attack signatures require nonstop updates of firewall databases to detect them

Typical Scenario and Remedy

Modern, usually referred to as next-generation firewalls, are designed to detect malicious traffic and files that are passing through them and block it. Therefore, when any endpoint (could be a personal computer, mobile phone, tablet, IoT device or anything with a network connectivity) from internal network tries to reach a malicious site, tries to download file that contains malware, or sends/receives traffic which seems like potential exploit of vulnerability, FW is supposed to detect it and do a predefined preventive action (block, alarm, log, etc.) How well firewalls are doing it depends on the quality of the database they are using for intelligence and how frequently information there is updated.

However, even the best firewall with the world-class, frequently updated intelligence sources is not able to do anything with the traffic that is not flowing through it. So, if the endpoint got infected outside the network and was brought in, FW is not able block east-west traffic unless it is routed through it. Depending on the type of malware that device may freely infect others located in the same network, unless there are means to control the traffic.

One possible remedy commonly used is to apply no-trust policy organization-wide, and to make security zones as small as possible, so as much east-west traffic goes via FW. Unfortunately, this doesn’t provide 100% protection, as it is not very scalable approach – it’s impossible to separate each endpoint from all others with the FW.

Juniper Networks approach is different – detection is still left at the FW level with the intelligence sourced at external sources like SkyATP, but the enforcement goes to the first point where the endpoint interfaces the network – either a switch, wireless access point, or virtual environment. It is assumed that compromised endpoint at some point will try to contact the adversary’s system somewhere on the Internet (e.g. command and control), which will allow the FW to detect that this particular element has been infected, and inform the control part about it for further enforcement.

Why Juniper Networks?

Juniper Networks unlike their competitors on the market have in their portfolio not only the security products, but also switching and routing. Because of that, it’s easier for their teams to build such an integrated solution than for any others who would have to interact with their external partners. Using the experience gained on their own products, Juniper Networks could extrapolate the behavior to 3rd party equipment, not to force their customers for vendor lock-in. But, it also simplifies innovation within the solution itself – adding new functionality in future will be easier if they can do it on the enforcement and control part at the same time.

They selected Junos Space as an enablement part of this framework. It has been on the market for many years and has gone and is continuously going through improvement, innovation and development cycles. Any organization that already uses Juniper Networks equipment (security, switching or routing), most probably is also using Junos Space to manage it, and most probably it is already well established and stable tool within their network. Therefore, enabling SDSN is just a matter of adding additional module(s) to it – no need of deployment of completely new systems.

Finally, Juniper Networks has SkyATP – their own cloud based intelligence platform with sandbox functionality that helps to detect threats, so SDSN also in that area is independent of any other vendor.

Solution Components

Image Source: Juniper Networks
Image Source: Juniper Networks

Juniper Networks Software Defined Secure Network solution is formed from three main elements: 

  1. Control and Management. This is the brain of the overall setup. Typical Juniper network deployments usually involve management plane, and Junos Space Network Management Platform fulfills that function together with various applications that are available, for example Network Director for managing switching and routing or Security Director for unified security policy control and analytics in case of Juniper SRX platform. For full SDNS functionality, Security Director is complemented with additional module – Policy Enforcer, which role is to push respective actions to the network in case the threat is detected. So, three elements are needed:
    • Junos Space Network Management Platform
    • Junos Space Security Director
    • Junos Space Policy Enforcer

  2. Threat Detection. This function can be provided by multiple mechanisms, but quite often it is Juniper’s Sky Advanced Threat Prevention, which role is to determine whether a particular artifact is a malware or not. It is done by either receiving database updates from SkyATP or by submitting file for analysis and receiving the verdict. SRX devices send the files for analysis to SkyATP cloud.

  3. Enforcement. This is the part where actual protection and prevention happens. In traditional models, enforcement occurs on the security device which is located either on the perimeter of the network or separates various segments of it. In case of SDSN, the whole network is the enforcement point. When threat is detected, Policy Enforcer communicates with proper network element via API to quarantine affected endpoint (for example by relocating it to special VLAN, to enable additional control for east-west traffic). Enforcement points could be Juniper SRX firewall devices, EX and QFX series switching products, MX routers, could be virtual devices inside private or public networks or even 3rd party elements of various kinds – switches, Wi-Fi access points etc. 

Who Can Benefit?

Obviously, there are no solutions that fit all. Juniper Networks SDSN would bring most benefits to medium and large enterprise environments.

Small organizations neither have enough internal users, nor internal resources to protect, nor enough enforcement devices that would justify investment.

Data centers might not be a good application for it either, as SDSN may not be able to add much of the value. Usually the applications that are running there are much better known, there is less variety of them, and not so much changes, so it is much easier to control what is allowed and where. Also, automatic quarantine of the endpoint may bring additional issues in data center environment.

Medium and large enterprises will benefit most from Juniper Network SDSN because:

  • Multiple locations and large number of devices on the network calls for automation if threat is detected
  • Mobile users, who either work outside of corporate network, or bring their own devices, potentially can get infected there and bring malware inside
  • Equipment of multiple vendors, and both physical and cloud based network devices can be the enforcement points
  • They don’t have enough human force to react manually to all the threats but they have enough to remediate possible false positive actions – it’s better and easier to re-enable user if they are found innocent than stop the malware already propagating in the network.

Further Reading

Software Defined Secure Network Solution Description
SDSN in Action. Solution Brief