SDN Security Benefits

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 59 minutes
Video Transcription
in this video will focus on the security benefits of software defined networks.
We've talked about. How s Deion's work? But we didn't spend much time talking about their security benefits. For starters, isolation in an ESPN is a whole heck of a lot easier.
This means isolating between and within tenants. You can apply strategies like micro segmentation, or you can create two completely different networks that use the same I p address.
And by doing this, you established I p overlapping. And this completely prevents routing of network traffic between resource is on these two networks. And if you take this hardline strategy, just make sure there's not gonna be a future need to integrate. The resource is running on those two isolated networks.
When discussing virtual appliances, I alluded to many of the next generation firewalls. However, few of these solutions work natively with software defined networks. But the good news is large cloud providers have these capabilities. For example, a WS has security groups and network Ackles.
Azar has concepts of network security groups and applications security groups
and Google Cloud includes firewall rules. These paradigms allow you to define certain policies with respect to the incoming and outgoing traffic for the specific cloud. Resource is
these policies are defined regardless of location and are tied to the logical resource is which is a good thing because they're not bound to specific I p addresses. And in the dynamic nature of the cloud where things are coming and going, you're creating machines, destroying machines on a very rapid basis. It makes it much more manageable and maintainable.
And since these concepts are so integrated with cloud providers,
they work well with the orchestration AP eyes to allow you granular and dynamic management of the policies. Keep in mind the policies themselves are not managed within the cloud resource. Rather, they're logically bound to the cloud resource. So I'll give you an example. In a traditional sense. You have a virtual machine, and you would define a firewall on that virtual machine.
In the cloud paradigm, you don't define the firewall rules on the virtual machine.
If the virtual machine word for some reason to be compromised, the attacker could disable the firewall that you've created on the virtual machine. But when we're talking STN native firewalls, were you defining these policies?
The policies are enforced at the STN layer completely outside of the virtual machine review to find some very tight rules around outbound traffic, ensuring the egress. Onley ghost specific Other resource is in specific girls, and the attacker would have somehow compromise this machine,
and then they wanted to expel trait. A bunch of information.
Those rules themselves. They're managed outside the machine so they would continue to be enforced. And the attacker would have a lot of problems trying to get the data off the machine to their own sites and their own locations. Because the egress rules have restricted such traffic
de centralized control and design, the Dev ops movement places a lot of emphasis on team autonomy, giving smart people a clear mission and enabling them to move forward with certain guardrails.
And by decentralizing the control of these various firewall rules, preventing an organizational scenario where you have a bottleneck and a single firewall team that needs to review an implement each and every change to a firewall
and SD in networks are typically denied by default for everything. If you don't establish a rule or policy that explicitly allows traffic between two cloud resource is, then the STN is going to drop the packets. For example, every network security group in Azar comes with the default deny rule.
It's the lowest priority rule so you can override it.
But you have to make an expressed action to create an allow rule that is at a higher priority than the default deny rule. So it's very important you take a good look at the firewall capabilities of your own cloud provider because they're going to be highly integrated with their own software defined network and provide you with a lot of these advantages.
All of this isn't to say SD ends or 100% secure, but they are immune from a lot of the traditional network attacks. As you recall, the way the packets and data frames travel within STN, they go straight from the source to the destination. The techniques, like packet sniffing, they don't work
other attacks like ARP spoofing. This is when you tell a machine on the network
that traffic should go to a device that it probably shouldn't also aren't applicable because the SD and manages the traffic between the cloud resources so tightly.
We took a deep dive into the security benefits of software to find networks covered isolation being easier,
reviewed various benefits of STN native firewalls and covered some of the many traditional attacks that in STN is immune from.
Up Next