Securing SD-WAN: 5 Considerations

[Music] gartner predicts that by 2023 ninety-three percent of organizations will be doing some form of st Wayne for the win edge and the reason for this disruption are obvious save money by not being as reliant on private circuits better application performance with intelligent monitoring and steering and simplified management with orchestrators and zero-touch provisioning but with all of these moving parts come old and new security concerns I'm Andy with the Cecil perspective and today we're gonna look at five considerations for securing ST win first thing to realize is a not all SD win is created equal with the explosion of SD win over the last few years we're seeing more and more vendors incorporate SD win as a feature into their existing product offering that means that we have an influx of traditional networking when optimization and security vendors who are now competing with the pure-play Sdn vendors while this means more options for the consumer you also have an abundance of SD wine vendors to pick from with varying levels of proficiency the security offerings from the various vendors can't be grouped into three general categories cloud-based third party integrators or built-in security cloud-based security means ESD when device is not doing any local inspection and instead it offloads all the packets that require inspection to a cloud service that means that for every packet that needs to be inspected the SD one device is forwarding it off to a cloud for security inspection third party integration usually comes in the form of service chaining using VMs server shaming is an SDN terminology to describe multiple virtual services working together within a physical box in most cases Sdn would provide the networking service while the security vendor would provide the security services all this happening on the same physical box using a hypervisor and an SDN controller built in security offering means a security inspection is happening in the sd1 appliance itself these are generally traditional security devices like a UTM or next-gen firewall they have Sdn as a feature all three options have their pros and cons but from a security perspective there's one option Dacian only use as a last resort and that leads us to the first item on our list number one offer on premise security whenever possible from a security perspective on premise security is always preferred over the cloud for a number of reasons not only does it provide additional services that a cloud-based solution doesn't offer but it also lowers your bandwidth costs and increases performance at the edge for cloud inspection to work properly all branch internet traffic must be forwarded to the cloud through a GRE or an IPSec tunnel that means a regular user traffic needs to be forwarded to the nearest cloud datacenter inspected and then forward it off to the destination that means that if you have an SD win rule to route an application like office 365 directly out to the internet without going through the cloud inspection first it bypasses security altogether in other words everything needs to route through security cloud this removes almost all the benefit of implementing SD win in the first place it also means higher when usage which leads to higher costs particularly if you're using a 4G card as a backup link which charges per megabyte on Prem security can be accomplished with an SD one vendor that either provides security services natively on the box or through service chaining with a security vnf both options greatly increase the performance on traffic that require security inspection while also lowering the cost by reducing the amount of traffic that is sent off through the win not to mention the number of security services that cannot be performed in the cloud like segmentation access layer security intrabrand security inspection for example scanning malware on a file share at the branch breach containment quarantine and even local authentication has a lot of caveats if you're behind the net so look out for that and how that's being handled by the particular Sdn vendor ultimately cloud security services should only be used when on-premise security is simply not an option this seems to be the case with a lot of the more popular pure-play as the wine vendors who partner with cloud security vendors to provide that security number two application routing best practices if you ultimately decide to offload security inspection to the cloud and this point becomes all the more important in SD when we create rules that specify where to route application or groups of application so a question you'll have to ask yourself is what do I do with applications it may be a security risk before you get to that point you have to first identify the applications that are actually in use next identify which of these applications need to be back hauled to your cloud or data center these will be called known corporate applique for applications they use a direct internet connection let's call them known SAS applications for business continuity it's critical that these applications always work at all times through redundant paths the next group of applications can be a group called allowed application these can be applications that posed little to no security risk and are allowed out to the Internet to provide business functionality now we want to group the applications that pose a security risk and if you're choosing a nesting web product that does not have built-in security this part may be non-existent which is why you'll need to forward it off to a cloud security service for inspection again non-ideal SEO and products with built-in security will offer layer 7 identification of potentially risky application this category can include things like botnet activity security evasion software proxy avoidance and many more we'll also want to create an application group for applications that we know should never be used for example if your company is using an internal file share we can block all other forms of file sharing like Dropbox and Google Drive ultimately these unwanted categories should be blocked before ever leaving the site if your SD wind does not support blocking make sure it's being black cold or sent off to the security device for more inspection number 3 look out for network leakage MPLS broadband LTE and IPSec tunnel overlays are just a few of the interfaces that Sdn has to manage to simplify administration s deal and vendors will usually group these interfaces into a single interface to remove the complexity of having to manage rules and policies for each LAN interface in some cases this could lead to lessen desirable route to and from protected zones let's use a following example your MPLS link broadband and IPSec overlay are all part of your SD lan interface you receive default gateways from your MPLS and broadband provider which means users now have two routes to the data center from either the MPLS or the broadband link so you create a policy to allow internal users out to your Sdn interface which includes these multiple individual interfaces except internal users should never go out through the broadband link to your data center without routing through your IPSec tunnel overlay so you create an SD win rule that allows users to your data center through the IPSec tunnel in the event your MPLS link goes down here's a part you have to be careful with some vendors treat SD land rules like firewall policies with a generic catch-all in the bottom that routes everything it doesn't have a rule for and rules are sometimes only active as long as their health checks or SLA s are being met so in a scenario where your MPLS link is unavailable and your backup IPSec tunnel is underperforming your sd1 rule won't take into effect and you end up using the default catch-all which goes to your routing table and since we have default gateways through our broadband link we end up with internal users going out through the public Internet and leaking private IP information there's many examples and scenarios we could review but the takeaway is this analyze your network requirements and make sure your vendor gives you the flexibility to make individual interface decisions this can vary greatly by vendor so make sure you understand the different scenarios in which routing can be influenced by an SDN rule when not used properly the simplicity of Sdn can bring on unexpected security challenges that were not seen on traditional routers number four transport security as companies move away from private circuits and utilize the unsecure public internet to transport data into private resources strong encryption and your VPN tunnels become critical this means making sure you have strong VPN encryption settings and have it tunneled back to your data center or cloud services for starters you need to make sure you're utilizing a VPN anytime you're accessing private resources across a win this means both private circuits and direct internet access like broadband or LTE cards in a common scenario with one MPLS and one broadband connection this means having at least one IPSec tunnel through each wind port if your data center has we're done in ports or paths you'll also need we're done in IPSec tunnels to each port so you can see that even in this most basic setup we already have four IPSec tunnels and if you have a backup LTE or 4G card consider using an on-demand IPSec tunnel that will only come up when the other ports are down this is gonna save you on mobile data charges next let's talk about VPN best practices always always always use a secure protocol like IPSec if you have legacy requirements for GRE or l2tp make sure they write over that IPSec tunnel first these older protocols do not encrypt the data in transport so you should always write over a secure tunnel like IPSec this partner is especially critical if you're using cloud security which sometimes they recommend to use unsecure protocols for traffic floating like GRE or HTTP proxies when using IPSec consider the following best practices use certificates over pre-shared keys and if you need to use pre-shared keys make sure that they're longer than 20 characters in length use Ike version 2 whenever possible avoid weak encryption methods like des and Triple DES avoid weak hashing algorithms like md5 or sha-1 and avoid diffie-hellman groups 1 and 2 don't assume these basic requirements are a given on any modern sd1 vendor many of these vendors have actually simplified the deployment process to the point where basic IPSec changes are either impossible or difficult to do at scale number 5 Class B part of the appeal with Sdn is the ability for remote offices and branch locations to access their cloud applications directly without having to write back an expensive MPLS circuit to get there securely from a business perspective I mean want branch locations to only write that expensive MPLS circuit for services in my data center or cloud but use a cheaper broadband for couldn't direct the internet connection of my SAS applications this creates a massive problem for security admins as more and more organizations use cloud applications like Salesforce and office 365 to store sensitive data so how can we secure and control access to our SAS applications one way is to use Cosby in combination with our Sdn at the branch Cass B stands for cloud access security brokers and it enforces security and global policies for all of our cloud applications this means that we can have much greater visibility and policy enforcement to these applications that we couldn't otherwise get with the traditional security appliance with Cass B you can now see and control down to the file how your data is being used some common use cases could be a user downloading sensitive data to an unsanctioned device or a user moving PII data on or off a cloud service these are things that we would have been blind to without a Cosme solution but when working in conjunction with your sa wayne appliance you can now do global enforcement of all of these policies so if my organization is using office 365 cache B gives me control of what they can and cannot do with that particular application if Mike as me has an integration with SD when I can now do things like quarantine that user who started to move files suspiciously or cut that user off down to the access layer if we notice that malware is coming from the endpoint as the digital transformation moves more more services to servers that we cannot control Cosby is becoming as crucial to our security plan as a firewall once was in fact partner prediction by 2020 60% of all large enterprises are going to be using Cosby to govern cloud services well that does it for this video you guys and I hope you found it informative you can now visit me at the seaso perspective comm for my blog entries past video research questions and suggestions for future videos you can also reach me at the seaso perspective at gmail.com as always please comment hit like subscribe to stay on top of our latest releases here at the Cecil perspective

Channel: The CISO Perspective

Views: 5,502

Rating: 4.9436622 out of 5

Keywords: sd-wan, software defined wan, software defined networking, ztp, secure branch, sd-wan overview, versa, velocloud, viptella, fortinet, meraki, viptela, sdwan, ccna, security, cisco, what is sd-wan, what is sdwan, ccnp, ccie, comptia, security+, next gen firewall, Cisco Certifications, network chuck, overlay, certifications, palo alto, gartner, cybersecurity, firewall, utm, zero touch, mpls vs sd-wan, sdn, networking, riverbed, WAN edgeg, orchestrator, iwan, isr, silver peak, nuage, juniper, netscaler, cpe, vnf

Id: 5AN-sbxaN0w

Length: 11min 53sec (713 seconds)

Published: Wed Nov 20 2019

Reddit Comments

[u/Surge_89]

Great info! CASB is the future thanks to cloud services and SAAS...