Gunnar Assmy - Fotolia
Looking for something else?
Security for software-defined networking has been the source of both enormous potential and head-scratching challenges for technology vendors, but Kevin Walker believes the industry is on the verge of reaching the next level with SDN security.
Walker, Juniper Networks' security chief technology and strategy officer, spoke with SearchSecurity at RSA Conference 2017 about the evolution of SDN security and the role machine learning will play in that process. He discussed Juniper's Software-Defined Secure Network platform, which is the company's big bet to use an SDN approach to build an integrated, centralized and automated defense system for enterprise networks; while SDN architectures allow admins to dynamically manage and change network operations, the Software-Defined Secure Network platform is designed to allow the network to dynamically detect and respond to threats.
Walker also discussed how his company is looking to bring other security vendors onto the Software-Defined Secure Network platform through technology alliances and make it easier for disparate security products to work together in an SDN architecture. The objective, he said, is to build a cohesive network that can automatically detect threats and take action as a whole rather than an individual point product.
There is still a long way to go before the vision is fully realized, Walker confessed, but advancements in security analytics and machine learning are bringing it closer to reality. Here is part one of the conversation with Walker at RSA Conference. For the audio version of the interview, listen to this episode of the Risk & Repeat podcast.
What do you see happening with SDN security? Where is it today as opposed to when we were talking about SDN two or three years ago?
Kevin Walker: One of the apologies that I've made is that I wish we hadn't used the term 'SDSN' for Software-Defined Secure Networks originally because it's confused with 'SDN.' They're different. They're separate. Now, there's a play for SDN within the SDSN of architecture and framework, but they're separate. It makes the conversation a little bit more complicated sometimes. SDSN is a departure from what had been the conventional SDN security model or strategy, I should say. SDSN is a framework by which we are saying, 'We're going to bring every element to bear.' Physical, virtual, router switch firewall, edge, cloud -- every element in that ecosystem will be an active participant in security. That's the difference in the overall framing of the SDSN model.
But to do that, we have to be based on some core elements. You have to have some sort of intelligence -- and that's our Sky ATP [Advanced Threat Protection] analytics engine, which is multi-threat intelligence, multi-antivirus, machine learning, and curated with data science. So if you think about that as kind of the arbiter of what's considered to be bad or nefarious, then we can apply an action on any of those devices that we just said -- the router switch firewalls, physical, virtual, as well as edge and cloud. We can say to any of those devices that are able to listen, 'Here's the action to take,' from the sledgehammer approach, which is a block, all the way up to something more creative. For example, if the team says, "'I want to follow that traffic and see what's going to happen,' we can in real time carve out a VLAN, create a honeypot and follow that traffic and let it continue on. It just depends on the capabilities of that entity or that device.
That's the notion behind SDSN. And from our analytics, to our policy, and to the enforcement, it's an open API. We need to enable, as I said, the nuanced security features that are not our forte. So we need to partner with folks for that. The obvious question is, 'Well, this is a Juniper-only solution?' And the answer is, absolutely not.
It can't be Juniper-only anymore, right? That's just not realistic.
Walker: It cannot be. It's not practical. No. As much as some people would like it to be, it's just not realistic. That was a year ago that we made this announcement. A year since, we've met our promises that we set a year ago about this then-strategy, which is now execution and is in customers' hands. Sky ATP is now a year-plus. But then this week, we announced the TA partners -- the Technology Alliance Partnership. We've announced five companies [Aruba, Carbon Black, Netskope, CipherCloud and ForeScout] that are buying into and building into this open ecosystem. We've added endpoint security, we've added CASB, we've added Mac security and also, access control through ForeScout. We can gain access through other third-party switches, for example. That's the approach we're taking. It's an open strategy. Some of the APIs have already been published, and you can go for it.
What's the long-term strategy for the Software-Defined Secure Network platform? How big do you want this to scale? Does it become too complex at some point if you have too many pieces and vendors coming in?
Walker: The scale problem, I think, is one that I don't think is going to be an issue from the technology perspective. We may have some policy challenges, but it depends on the vantage point. If I'm an enterprise, I'm going to base it on either my domain's services or my business units or some other mechanism, which we do today. There's no real difference there. It doesn't have to be one view for your entire enterprise. You can have multiple views. On the policy management side, again, we don't think that's going be an issue at all. Frankly, we want to integrate into existing policy control mechanisms as well. We have the core engine that does the execution and decision-making, but what is the workflow, for example? We offer some of that, but we also recognize that it has to be done by a third party.
Kevin Walkersecurity chief technology and strategy officer, Juniper Networks
But, I think the part that I get excited about is where we, the industry, really need to go now that we have a framework such as SDSN. And that is, now the network can actually morph from a collection of components and boxes to the network being intelligent itself. For example, just imagine a future state where the network is an intelligent entity. So the network -- not the router, not the switch, not the firewall -- will make localized decisions.
The collective network, then?
Walker: The collective, exactly. The collective will make the decision, influenced of course, by our big data analytics. But then we can say, 'Oh, I'm noticing something that's just visible.' I hate the word to use 'behavior analytics' because it's an abused term, especially this week. But there's the notion that the network knows what's normal because, by definition, it sees everything -- including, by the way, the malicious activities. And so at the end of the day, I think we'll be in a position where the network itself has the ability to make localized, quick, high-speed decisions. And the goal, ultimately, would be for the network to do a cleansing mechanism onto itself for the well-known malware. I'm not saying by any stretch of the imagination that we're talking about 100% effectiveness. But at least that we can get to the point where the network is as clean as your AV engine. And you don't challenge your AV engine every time it makes a decision. You don't create a ticket. You just say, 'Okay, you found it. Let's go [quarantine it],' because we've built enough confidence in that ecosystem of malware detection to say that it's bad.
So the network can get rid of it automatically?
Walker: Yes. Just drop it. And yes, you can create a ticket and tell people we did it. But I think that's where I see the industry having to evolve to, and certainly, Juniper's leading the way through SDSN.
So not to go too sci-fi, but the network is basically a living, breathing thing that can make some decisions on its own?
Walker: Let's go full sci-fi.
Well, I don't want to get into Skynet ...
Walker: No, it's not Skynet. It's not breathing, and it's not living, but it's artificially living in the sense that it's just making the right localized machine-learned decisions for, in our case, looking for malicious activities. Right now we're file-based in Sky ATP. We're going to have to move more up to streams and then, ultimately, to packets.
So the idea is if Juniper can do those smaller decisions and the SDSN can get the low-hanging fruit, that takes a lot of the work off of a security team that has to look for the real serious stuff.
Walker: That's exactly it. You're putting the time back in their pockets. As I've said before, I've been a CISO multiple times. And the biggest challenge that I had was not technology. It's talent. And it's an acute problem worldwide. That's not going to change. Even if we start cloning new developers or engineers today, we've got 21 years before we can use them.
You mentioned machine learning. Where do you see it going in general in the security field? It seems like that's been a really big theme, not just at this year's RSA Conference but last year's as well.
Walker: Sure, but I think if you look and you think about, especially in the last few years, when you hear "machine learning," everybody's really doing map reduction. That's basically it. And that's fine. It's important. Remember, we have had SIEM [security information and event management] now for almost 20 years. But SIEMs are, basically, extremely crude, three-dimensional spreadsheets, frankly. And people, for years, have tried to apply analytics against that. And it's hit its limit.
The tools have improved, and the data science as a discipline has kind of emerged at about the right time when you can take a step back and say, 'Ah, that technique has run its course. Now let's do it through machine learning.' Most of this is map reduction. But if you don't apply data science to it, then it's not helpful. And this is something that happened to me when I brought in a data scientists. He said 'You know, your data is crap. What am I supposed to do with this?' And so, at the end of the day, he brought up a very good point -- as security practitioners, we're not data scientists. We talk about looking at our logs. Well, be careful what you ask for, because the quality of the data may not be such that you can make a good and reasonable decision from a security perspective.
So these are things that I think for machine learning are still in generation 1.5 from a security perspective. But there are some very good examples out there where they really have figured out right algorithms where you can just basically give this to machines, have them crunch like crazy and come back with not so much artifacts but indicators. And that's what we're looking for. It's a matured discipline, but it's still maturing within security.
Find out how to use DNS reverse mapping to scan IPv6 addresses
Read more on how to leverage big data frameworks for security
Discover how to embed security automation in the DevOps process