Juniper’s Software Defined Secure Networks (SDSN) platform can now work with Cisco switches and ForeScout’s CounterAct NAC software to automatically respond to compromised computers connected to the corporate network.
If malicious files or programs are detected, automated responses include blocking or quarantining compromised computers, alerting administrators, or simply logging the malware notification.
The SDSN platform combines several Juniper products:
Sky ATP: A cloud-based malware detection and analysis service
Security Director: Premises-based software for centralized configuration and management of security policies
Policy Enforcer: A component of Security Director that can automatically distribute security policies to Juniper EX and QFX switches, Juniper’s virtual and physical SRX firewalls, and now to Cisco switches and ForeScout software.
Putting It All Together
If Sky ATP detects malware on an end point connected to the corporate network, it communicates with Security Director. Security Director resides on premises and is the central repository for security device configuration, so it has a view of network topology. Using this information, it can determine which switch or firewall can be used to take a policy action against a compromised host.
Organizations can configure automatic responses. As mentioned, those responses include blocking, quarantining, or just triggering an alert.
To block or quarantine a host, the Policy Enforcer component of Security Director will send the appropriate ACL to a Juniper network device to enforce the desired policy.
In addition, the latest update to Policy Enforcer now includes APIs to communicate with Cisco’s Identity Services Engine (ISE) and ForeScout CounterAct. Either of these products can then implement the ACL in the appropriate switch or AP to apply the policy.
Drew’s View: Don’t Forget Workflows
There’s a lot of moving parts to Juniper’s SDSN platform. That means complexity, even in an all-Juniper environment. The integration of of third party products via APIs increases that complexity.
Then again, the whole point of “Software Defined” whatever is to create software-driven abstractions that knit together disparate systems to achieve a goal.
So let’s assume Juniper has gotten its knitting right and SDSN functions as advertised (after some degree of integration work and testing on the customer’s part).
Then let’s imagine that a user unwittingly downloads a file that contains malicious code. That file gets detected and the SDSN machine whirs to life. Hey presto, based on pre-defined policies, that user gets knocked off the network.
Except that the user now calls the help desk to say “Hey, the network is broken.” If that user is an executive, and that executive was in the middle of a Webex conference with a sales prospect when he or she got kicked off the network, the call is not going to be very polite.
The help desk then cranks up its own machinery to see what the hell is going on. Of course the network isn’t broken—it’s doing exactly what it was told to do.
But does the help desk team know that? Do they also know someone’s device has malware and has to be cleaned up?
I think you can see where I’m going. No action happens in a vacuum, and whatever action you take will affect someone else somewhere down the line.
This doesn’t invalidate SDSN or other automated policy and security platforms. But it would be great to see a complete integration that touches all the various workflows, procedures, and personnel involved in an action so that the right parties know what’s happening and how it’s going to get fixed.