How Can SD WAN Help Cybersecurity: A Podcast with Fortinet’s John Maddison
In this edition of the Designing Enterprise Platforms Podcast for Early Adopter Research (EAR), EAR’s Dan Woods spoke with John Maddison, the EVP of products for Fortinet, a leading cybersecurity company. Designing Enterprise Platforms focuses on how to use products and other technology to create a platform to solve a problem. In this case, the research mission this podcast is related to is creating a balanced cybersecurity portfolio. In this podcast, Woods and Maddison talk about three topics, starting with SD WAN technology, which is helping companies solve problems that are related to zero trust and perimeterless issues. They also cover security-driven networking, and end with the arrival of the edge and how companies are going to secure both what they have in data centers and in the cloud, but also what is increasingly becoming an important part of almost every company’s infrastructure, which are edge devices and IoT devices.
* 3:00 – What is SD WAN Technology?
* 13:00 – How do you understand risk level in cybersecurity?
* 22:45 – How can you provide the right security for a perimeterless environment?
Woods: Can you explain your role at Fortinet?
Maddison: I’ve been at Fortinet for about seven years, based in Sunnyvale, in the heart of Silicon Valley. I’m the head of products and solutions and my responsibility is to make sure a lot of customer requirements are coming into the development teams and the PM teams, and that we make sure that’s correct and ready for our customers and our channel partners.
SD WAN means software-defined wide area network and it’s technology that’s been around four or five years, but it’s become much more popular recently. What is it and why has it become more popular?
If you look at wide area networking, there were really two main markets or different use cases. There was what I’d call the distributed enterprise made up of many thousands of retail outlets. We have one customer, for example, with 15,000 outlets or small branches. And they’ve always said they want the cheapest transport mechanism back — therefore they needed security. And then there was another marketplace called the branch office which has a smaller number of branches, but what they did was to bring everything back to the data center where all the applications were. So you had these two marketplaces. One was UTM and one was routing. So what happened is that these marketplaces have started to merge, in that the branch office wanted to make sure they had more flexibility in where those applications go. As enterprises roll out public cloud and SaaS applications, the applications weren’t always going back to the data center. They were going to different places. The same for the retail and UTM marketplace. The other thing that both of those marketplaces wanted was a bit more flexibility in the transport mechanism. Do I want to use DSL or cable, do I want to use a higher quality MPLS service? Those were the two main use case drivers: I want to be able to have more flexibility in how the applications go and where they go because my workloads are moving around a lot of different places, and then I want choice on what transport I use inside the wide area network.
There’s a great example that I think made this much clearer for me and it came from Brian Talbert of Alaska Airlines. He explained that their entire staff at all airports is mobile and so everybody’s using a mobile device, no matter what they do, whether they’re servicing the planes or checking people in. And then they have lounges where the pilots and the flight attendants hang out, where they want to watch Netflix and stuff like that. He said that the SD-WAN technology allows them to create a connection to a mobile device, determine if it’s a pilot who is wanting to watch Netflix, in which case they route them over a public Internet connection and allow them to watch their Netflix without having that bandwidth interrupt the traffic for the applications. If it turns out it’s a flight attendant checking somebody in or answering a question or somebody doing aircraft maintenance, the SD-WAN router will realize that and then send them over the MPLS with a dedicated network back to the branch office so that they can get the service they need.
That’s a great use case. I mentioned the applications being in different locations so you want to use different transport mechanisms. But what you can also apply, through the SD-WAN controller, which sits there and looks at the applications, where they come from, who it is, where they need to go and makes the decision based on a policy you can apply. What you can also then apply is a quality of service. So for example, for airlines, they want to make sure people get booked in. When attendants arrive on planes, they immediately log in their handsets to make sure payments process straightaway. Those are very important applications that need to have a better quality of service or higher priority than anything else.
I didn’t realize that existing routers have the ability to decide that a route will change from one path to the other, but usually it’s only if that path fails. What’s interesting about SD-WAN is that there’s other metadata that can be used to make that routing choice.
Routers are IP-based. They don’t really know who’s on the other end. They’re at a lower level in the routing stack and so they just decide based on some conditions. The SD-WAN controller knows who’s attaching. They know what application it is. They know where the applications are.
Fortinet’s SD-WAN controller and your SD-WAN technology has security built in. What’s the difference between an SD-WAN system that has security and one that doesn’t?
A lot of the original SD-WAN vendors were focused on the routing stack. A lot of them forgot that when you open up that wide area network—not only to DSL and cable; eventually it’s 4G and 5G—you’re then creating an edge, and this edge then becomes something you need to protect. So you need to have a higher grade of security built into that SD-WAN controller. We manufacture some of our own, for example, ASICs, and we announced our SD-WAN ASIC here at Accelerate 2019. That allows us to run not only the SD-WAN stack, but also an enterprise-grade security stack in the same appliance.
SD-WAN is an instance of a technology that is flexible and allows you to make decisions about where you want to route things. It’s very useful when you have a branch office or a distributed office and you want to send some traffic over the public Internet or send some traffic to SaaS applications. But now, the choices that you’re making are about quality of service, security, and the metadata that you have available to make those choices is much larger. I want to touch on a concept called security-driven networking. That’s like popping SD-WAN up to a much more abstract layer and saying, wait, if we have all this metadata, if we know a lot more about the network, if we understand more about our applications and our users, can we make routing and networking decisions that are much more intelligent, rather than just having the path minimized or the speed of the connection maximized? Security-driven networking seems to be saying let’s make decisions about networking by taking advantage of a greater amount of information. Is that it or is there more to it?
That’s it, plus a bit more. We believe that networking and security should be integrated and combined. That’s why we have a huge investment in building out what we call security processing units and ASICs to make sure that can happen. When you build networks, the networking team will make sure connectivity and availability are their first goals. Then what happens is people decide which applications need to be available for which users. Then what happens is another layer goes on top of that which says we need to make sure it’s secure. We’re going to put some security here in the data center or in the cloud and some security on the endpoint or I’m going to put some security over here. But those are all three different teams. When you need to make a change and you have to go to the first team and then the second team and the third team, it slows things down. Our security-driven networking means that you have one integrated device that does networking and security. But as you said, what we also do is take advantage of the additional data. We can see who’s attaching, we can see what devices, we can apply policy end to end from the customer premise through the WAN into the cloud, into the data center. It’s a holistic concept instead of a layered concept of making sure you can connect applications securely to users.
It’s using data that companies are not used to getting as well. In order to do that, though, you have to have an understanding of what parts of the Internet are safe and what parts are polluted. How is that all going to happen?
I refer to that as the risk level. What’s going to create these edges going forward is the different risk on either side of the interface creating the edge. The edges will appear throughout that WAN. It may not just be your CP, your branch office and then your data center. Within that wide area network, you may decide different risk levels of different transport mechanisms or going through different ISPs and different connections. So once you have that information, you can apply that to the policy, which then makes decisions based on which applications need to go where.
There’s a service called ThousandEyes that allows you to understand the routes in the public network because they put sensors all over the public network and can see if there’s a problem. The impression I had was that you would actually have data telling us what parts of the public network are dangerous. What are the elements that would help you with networking?
ISPs have rankings around security. Even if it’s not an encrypted link, some of the ISPs do some of their own security. Definitely, you can employ encryption for certain companies. So it’s a lot of data we bring in at a global level through our FortiGuard services and apply that back into our SD-WAN controller. So it’s not just one factor. It’s a number of different factors that we can apply through that.
How soon do you think people will start doing security-driven networking on a larger scale?
SD-WAN is already an example of security-driven networking. Another example that started five or six years ago is next-gen firewalls, where you would take an existing staple firewall and add some intelligence on it. The reason for that was because the content was getting richer and richer and we had to inspect that content. In the future, we’ll see examples applied to the cloud, 5G. All those edges will need that security-driven networking.
Now let’s move to the edge. It’s interesting to see how the conversation about what’s called the edge and what’s called the perimeter has become so confusing. Because sometimes people talk about the perimeter as if it’s an edge and then they talk about the edge as if it’s a class of computing devices. We’re going to set the terms right now. When we’re talking about a boundary between one domain of computing and another, we’re going to call that a perimeter, and we’re going to call the edge all of the devices that are emerging now, the IoT in general. In the past, you had security on servers and then you had virtualization and now security on clouds, and you had to have threat intelligence and security around that. Now a huge new domain has opened up, which is the edge and devices operating all over the place. I was interested recently because I read a whitepaper from a Gartner analyst about CARTA, their exposition of the zero trust concept. One of the things they said that I thought was correct was that it’s not a perimeterless world. It’s actually a perimeter-filled world we live in. We’re going to have so many perimeters, it’s going to drive people crazy. So it’s not that we need to forget about perimeters. Actually, we need to get really good at managing those perimeters and creating them. So it seems to me that if you were able to get skilled at defending that, you’d go a long way to being able to have good security for the edge, the IoT world.
It’s all a matter of trust. If you go back not so long ago, the perimeter was pretty small. It was in the data center. In fact, even a big global organization would have just a couple of data centers designated as the internet connection and that was the perimeter for customers. The other side of the perimeter they had was endpoints, and those endpoints would go offline, go home, connect into other places. So those were the two pieces of the perimeter. You’re right; people say the perimeters are disappearing because now you’ve got cloud and I’ve got IP-enabled devices in my factory and I’ve got more flexibility on the WAN. We think it’s the opposite. What we’ve called perimeters are becoming edges, in our opinion. And the edge is something where you go from one trust level to another trust level. I don’t really like that zero trust terminology. I always ask people, “Would you ever connect something to zero trust?” They say, no, it’s not what they want to do. I do like the Gartner analogy around CARTA. But I also think that you’ve got to be very aware of the edges. You’ve got to know where they’re appearing. You need that visibility across your network to make sure you see that. One of the edges that is appearing, a new edge in the branch office, they used to connect that back to the data center and that was it. Now you’re opening up different transport mechanisms. That becomes what we call the WAN edge. When you think about a factory where you’re starting to put IP-enabled devices, that’s creating an OT edge or a factory edge.
And when you’re sitting in Starbucks on your laptop and you’re trying to connect to central resources, you’ve now got your access edge.
Yes. So these edges are going to appear all over the place. Security-driven networking is a concept of bringing security and networking together, but you’re going to need many different types of security, not just appliances, not just virtual machines, not just agents and software. You’re going to need containers in the cloud. Probably the one that’s going to be very relevant over the next five years in certain areas will be API. You need to be able to see it, so in a SaaS application, you can’t take your security inside there. These edges are going to be secure. 5G is another one. When you start rolling out compute not only from in your data center but in clouds, but also in edge compute for certain applications, that creates additional edges there as well.
If you’re going to do a good job at this, you have to have an opinion about how you’re going to provide the right security for the edge, how you’re going to provide the right security for the cloud. One of the points that Fortinet has made for quite some time is that if you’re going to expect rich content, the amount of processing power it takes to expect that content is 100 to 200 times the amount it takes to deal with the routing issues. You’ve made a strategic architectural decision that the best way to deal with that is to create special-purpose chips, security processing units that allow you to do that at the firewall level. Let’s assume that you’re right and that that is required for top-level security and if you don’t do that you’re going to get serious performance degradation. So that means that at the edge, where a lot of the data is being created, you’re going to have to be able to push down that capability into the IoT at some level. One way to do it is to push it down into the device. Another way to do it is to push it down into local controllers that are attaching to a bunch of devices, like gateways. In the cloud, you’re going to have the same problem, how am I going to deliver security in the cloud properly? If you’re going to get the right performance for a next generation firewall in the cloud, you’re going to need a cloud instance of a secure computer that can spin up a firewall that has in it, underneath that virtual concept, a security processing unit. It seems that the future of security is going to become more embedded than it was. The IoT device manufacturers are going to have to embrace embedding specific security capabilities inside their ecosystems, if not inside their devices. The cloud providers are going to have to do the same thing. Do you agree?
You’re right. If you look at it from an OT perspective, or even IoT, you’re going to see two places. One of the places you could do some of that security is through the gateway. The issue, depending on how far the gateway is, you’ve got a lot of lateral movement that can go on between devices, which could be an issue. On the other hand, it’s sometimes a price performance issue. If these IoT devices are only $20 dollars, there’s not much you can do in terms of putting any computer power there to do anything inside them. You can embed stuff, but then it makes it more expensive. So there’s a balance on the IoT devices in where you put the security. I think it’s going to be sitting more in gateways or sitting more in access control. For OT, it’s a different matter. For OT, you’re talking very complex systems. Problematic in that area is that a lot of them are proprietary, almost unknown. It’s almost been their defense mechanism over the years that no one has a clue really what they are and how they work. But as you start to apply IP addresses to them, they become open, and as theyscale to some of those situations, we’re going to start to see more embedded architectures where we take some of our security processes and pop them inside some of those devices, which could be millions of devices, and start to provide that security there and then. What you don’t want is one device getting compromised and being able to spread instantly and attack some really critical infrastructure inside there. If you move all the way up into the cloud, one of the key requirements of the cloud is flexibility. So often inside the cloud, they’ll trade off performance for flexibility. Because in their minds, there’s plenty of compute power there. I’ll just trade off some of the compute power to make sure I can provide flexibility and I can move things around and get commonality across there.
However, what we are seeing in the last few years is a lot of the cloud vendors are starting to build their own hardware. Because at some point, specific ASICs can do things hundreds of thousands times more efficient than a standard compute. And security is a really good example of that as well.
When we look at the future of cloud security spending, cloud spending is maybe 9 or 10%, and a huge amount is still being spent on cybersecurity software and appliances. You guys are making the bet that that transition to the cloud will be gradual and that the bulk of the spending will stay on what’s being spent now and gradually more and more will be spent on the cloud, but it will be a long transition, one or two decades. While other vendors are saying all cloud all the time, that’s where we want to put our innovation, that’s where we want to put our emphasis. Why do you think your bet is correct?
We speak to a lot of customers who are moving to the cloud — either they’re migrating to the cloud, they’re building from scratch in the cloud. They’re already consuming cloud. There’s no doubt that cloud will be a large portion of the compute out there. We’re also seeing customers who still are building out new data centers of their own. In the next few years, a lot of enterprises will start to enable edge compute as well. We believe in a hybrid world. We believe there will be cloud compute, we believe there will be on premises data center compute, there will be compute in the edge through 5G, there will be compute in devices still. It’s not that we’re saying that the cloud is not going to happen. It absolutely is going to happen and you need a different security model depending on how you’re going there. What we’re saying, though, is that what’s important is that you understand that it’s going to be hybrid for a long time, if not forever. So you need different types of technology and security. You need appliances, you need virtual machines, you need APIs and containers. But most importantly, you need to be able to coordinate the policy across all of those things.