 Okay, so what I would like to do is tell you a little bit of an application story. And that is using the tools and the virtualization that is provided through OpenStack and Open Daylight. Redware took those tools and used it to create a cyber control plan or a cyber defense network. And I'll explain a little bit further what that means and we can have a conversation about that. So the first reason is why? Well, if you look at what's happening in the security industry right now, what we're seeing is we're seeing more and more continuous attacks. So as opposed to a few years ago, where it was relatively rare, we're now seeing in 2014, 19% or about one in five attacks are being called constant. And so in this environment, we're seeing about half of all respondents and this is the respondents of our enterprise customer base, saying that they could only fight the campaign for one day or less. And so we've seen more recently, we are seeing customers that are under attack from a cybersecurity standpoint for days or weeks or even months, particularly when it comes to banks and foreign governments. And so there's a need for a more comprehensive type of solution. The second piece is especially when we get into carrier networks, which is driving a lot of the NFV and SDN development. The service provider networks are being affected in two realms. One, they're being affected themselves. We're seeing them as targets of attack. And you can see some of the logos of some of the different companies that have been affected by these attacks. And the second piece is the enterprise customers themselves are turning to them as their connectivity provider to provide them the kind of security that they require through their network. And so what we're seeing is in the case of BT, BT is seeing about 60% of their customers saying that these attacks are becoming harder and harder to stop. The second piece is we're seeing a rise in multi-vector attacks. And what we mean by multi-vector attacks is the first generation of DDoS security attacks was around volumetric attacks. So this was sending 10 gig of traffic down a one gig pipe and try to knock over your router. And now what we're seeing is we're seeing multi-vector attacks where I'm not only going after the physical pipe with a volumetric attack, but I'm also using the protocols that you're using, whether that's web or SIP or whatever applications you're running to actually attack those application servers and try to take those application servers down as well. And so the shift from volumetric to application again requires a much more comprehensive look at the network. The third piece of this then is mobility. And as carriers are now moving from 3G to 4G networks, 4G is an LTE-based network, very flat, all IP-based. And now all of my smartphone devices are IP-addressable devices. And that creates two things. Number one, that means all of those can be addressed and therefore attacked. And number two, it also means that I can have a handset that roams onto my network and now can be a rogue handset that is used then to launch attacks either at a carrier's infrastructure or again at the carrier's enterprise customers. So all of these then are combining for a need for much more comprehensive, much more holistic approach. So if you look at this then, this is some of the research from some of the most recent studies that we've done looking at what are the different elements in the chain that are being attacked. And what you can see is there's no longer any single element that's taking the brunt of most of these attacks. You can see a third of them are going after the internet pipe but also a third of them are going after the server and the applications that are being used. And so what we see here is this starts to get into this notion from an SDN and an Open Daylight controller standpoint of wanting to use the entire network and all of the telemetry and all of the different elements to look at different attack telemetry and determine what's the best place to fight the attack because there is no single device and therefore no single box that's gonna be able to combat the attack. So if you look at this in general you can see several key themes that are coming up. One is that the security threats are becoming much, much more aggressive and much, much more sophisticated. You've got these multi-vector attacks going after layer four through seven. The networks themselves are getting more complicated as enterprise customers not only have on-premise devices but now they have cloud devices that they wanna protect as well. The second piece of that is we're also seeing a rise in encrypted attacks where carriers and enterprise customers are seeing now the need to go after, are seeing the need to not only look at clear channel or unencrypted attacks, unencrypted traffic but also encrypted traffic as well. And so the countermeasures are getting much more complicated. So there's a need to not only do challenges on certain requests to see if those requests are legitimate or those bots but also then to decrypt traffic and look inside and determine is there an a various act that's trying to be committed within this encrypted tunnel. And then the third piece of it is if I look at SDN and if you look at Open Daylight one of the things that provides is this network wide view and this is extremely important when it comes to carriers because from a carrier perspective the macro level problem that they're seeing is although the revenues are rising their profits are flat. And the reason for that is because of their huge operational costs. So as the revenues rise so much of their different operations and procedures basically manually scale with revenue and therefore they aren't seeing any growth in profits. And so one of the big opportunities here around NFV and SDN is to really change that dynamic and change that equation and show them some significant savings from an operational standpoint. So the need then is to come up with a network wide security control plane and that's really what Radware has been working on to provide that to get a much more end to end holistic view to act and mitigate these cybersecurity threats. So if you look at what we did we basically leverage three different elements. One is NFV. So we took our different security elements and we virtualized those and we virtualized those either in an NFV environment or in an OpenStack environment. And so we created both physical hardware as well as virtual instances of these different security elements. The second piece is SDN and that was leveraged using an open daylight controller and what we did is we built our software on that SDN open daylight controller to basically take telemetry from multiple different points in the network. So be able to look at everything from the network feeds that were coming directly off the router from layer two and layer three and layer four as well as looking at application level feeds coming from the servers, looking at DPI, DPEC and inspection data that would come off the DPI appliances. So what you get is you get a much richer set of data from which to correlate and then look at make a decisions. And then the last piece is wrapped that completely in the orchestration and cloud nature of OpenStack and orchestration. And so this is really the tool set that we use to build the application that we're gonna talk about. So one of the things that we did is we built it on an open daylight controller. So the reason we did that is because when we look at carrier networks, carrier networks today are really leveraged around building these islands of SDN. And so in these islands of SDN they've got a virtualized software defined data center at layer two and layer three and maybe they're multiple geographically dispersed. And then also a layer three WAN that they're using and this could be virtualized using Cisco, using Juniper, using Octelucent, whatever the router vendor may be. And what we were able to do then is by taking the flexibility of open daylight in being able to take multiple different types of telemetry and multiple different network feeds, we were able to then combine and correlate all of the different information coming not only from the software defined data center and the elements there, but also from the WAN elements itself. And then by collecting that data we were able to use our behavioral engine which sits over the top and basically create an overall baseline for normality within the network. So what we do is we look at multiple different parameters within the network, establish that baseline and then look for anomalies against that profile. And then when we see anomalies against that profile, we can then determine and again using some of the flexibility in the open daylight controller determine where is the best place in the path to actually provide the mitigation to stop the threat. So let's walk through an example. So let's say we have an attack going through one of our carrier customers to an enterprise data center. So in this case, the attack is detected and telemetry is sent then from a virtual instance and this could be an instance running OpenStack, this could be an NFE instance at the enterprise data center. And basically at that point then the attack is characterized using about 34 different parameters that look at the different aspects of the attack, the vectors that are being used, et cetera. And this runs in real time in about 18 seconds. So over that 18 second time period it collects all the telemetry, determines the different vectors in the attack and sends that then to the open daylight controller where our application which is called defense flow sits over the top. So our application on top of open daylight then looks at those 18 parameters, determines what's the best place in the network then to block that attack. Let's say in this case, it's at a scrubbing center that a carrier is using that's somewhere in a different geographical location. So what it would do then is it would take that telemetry and that information and specifically the signature that is required to block that attack. And it takes that signature and that signature that is pushed down to that scrubbing center and then the open flow routers are used then to redirect the attack. And so that redirected flow is then sent through the scrubbing center, it's cleaned there and then sent on to the enterprise data customer. And that's just one example but obviously the rules could be whatever the carrier or enterprise customer decides they want to use as their policy rules. So if they wanted to block the attack using a particular ACL, they could do it that way. If it needed to be redirected, let's say not to a scrubbing center but it was more of a web application type of attack and wanted to go to a web application firewall, that could be done as well or if it needed to be decrypted because it was an SSL attack, multiple different ways to mitigate the attack but it would go to the proper network element either hardware or virtual. And so what you have here is you have here now a cyber control plane basically that's built on top of the open daylight controller that's taking telemetry from the entire network correlating it and providing a much richer set of information then to make decisions and then based on the policy that's put in place on the application and on the controller then determine where in the network to provide the best mitigation and providing this multiple layers of network defense. So we think this really becomes kind of a killer application for SDN and the reason for this is because there's kind of this virtuous cycle that can happen here and this is where if I start the circle over on the left side, I program the network, I collect the telemetry, I get flow visibility from the open flow open daylight controller APIs and I get all of the information then around of the network. That then flows up to my SDN application that I built on top of open daylight and as we talked about a little bit previously I then take that information, I build all my baselines and determine what is normal traffic within this network and then against that I can look at any type of anomaly and determine what degree of membership does that have with normal behavior and basically then either pass it as normal behavior and allow this traffic to go through, say that this is suspect behavior in which case then I can provide either automated or manual challenges from a security operation center to challenge that flow and see if it's legitimate traffic or not or if it's clearly out of membership with the norm I can determine that it is definitely nefarious behavior and then go through whatever policy rules to block. So I do that real-time attack characterization and again that's done looking at all the different factors and parameters in about 18 seconds and then I move into the war room which is really the policy-based room of the application where based on the policy rules that are set within the application it determines again what is the right element and what is the right place within the network to block the attack and basically sets all the policies in place so that it can be fully automated and in a carrier environment could be done completely without the interference or the mediation of the security operation center. So let's look at a specific example. So here's an example of a carrier that's running an NFV-based orchestration system and wants to offer a DDoS-based security service. So the customer says I want to have the service and so how do I deploy? Well first of all I use the virtual infrastructure manager and I set up all of the virtual instances on-prem and this can be done again using OpenStack and I set up all my virtual instances and now I want to deploy then the service configuration. So in our case then what we do is we have VDirect which is a plugin which basically then programs the VM sitting on the customer-prem that sets up the virtual instance for the security element and then the DDoS policy is set. So again the rules based on when it sees an anomaly what should be done, those rules then are pushed down into that virtual element running OpenStack for example. Now once that's done the ongoing maintenance basically it's a provision once and run forever type of service so there is no ongoing maintenance once that initial policy is set unless there's some type of real-time update to rules or policy or something like that that needs to be done. So once that is done then if I do that I can now leverage that and I can do that as well in an SDN type of environment so I can have that same type of functionality but now instead of using that plugin to provide the policy I can use this OpenDay like controller that can see network-wide and use that then to push down information to the virtual instance. So now let's take an example where I see an attack coming in through to the enterprise the attack gets characterized by that enterprise device that telemetry is then pushed up to the defense flow application that's running on the OpenDay like controller based on the policies that are then set the application sitting on the OpenDay like controller then makes the determination where to redirect the traffic and basically based on that then it can determine whether there are other instances in the network that would be the best to divert to or should have put an ACL in place from some perimeter based router in the Layer 3 WAN or whatever the policy rules of that carrier basically would determine. So what we're left with then is we're left with this cross-domain anti-DOS that focuses on the entire network so it gives the ability using OpenDaylight and using OpenStack to basically provision instances of our security algorithm anywhere around the network collect telemetry from it and other applications and then determine where is the right position of the network to mitigate that attack. So basically in conclusion what this application allows us to do is it allows us to basically take what today is a federally manual procedure where a security operation system would basically see an attack coming in assign a security engineer a security engineer would then troubleshoot the attack use BGP or some other equivalent routing protocol then to manually divert the traffic clean it and then use BGP again to send it back on its way to the enterprise to take that very manual carrier process and use OpenStack and OpenDaylight to basically completely automate it and offer virtual detection where I can take telemetry from OpenFlow from OpenFlow enabled elements from NetFlow enabled elements from third party elements as well feed that into my analytics engine then have my war room where I've set up all of my dynamic policies basically replacing a lot of the functionality and the manual troubleshooting that a security engineer would do and basically set up rules in place by which depending on what type of application or what type of attack I see what are the rules to deal with that automatically push those rules or ACLs down into the network and then program it to act so that when it sees it it's automatically rerouted sent to the proper device scrubbed or cleaned and then sent on its merry way and with that I'll be happy to take any questions all the communications from telemetry to analytics engine to war room and then on to the mitigation points where in all those communication points are they restful and or restful APIs that you might plan on opening up where are they proprietary? So they are done through open restful APIs all of those interfaces any other questions? Yes sir well first of all the flexibility of Open Daylight and the fact that by the way the interfaces are defined that I can take multiple different types of telemetry I can take snippy I can take inputs from snippy from net flow from open flow so the first piece is the flexibility upon which that was built is probably the primary reason and then the second piece is just from a market acceptance standpoint we're seeing more and more specifically speaking from a carrier or a large cloud enterprise customers we're seeing more and more more and more of our customer base that want to see these types of applications built on an open source open daylight controller the enterprise device as opposed to the carrier device so the answer there is it really depends on how the carrier wants to deploy so let's say that first of all a typical carrier deployment today will be an out of path deployment where they're using some type of a scrubbing center and so in this case they're not seeing all of the traffic because the traffic is not always flowing through the scrubbing center at any one time and what they're using is they're using some type of either open flow or net flow statistic collection from the perimeter routers to signal for an attack okay and basically that's a typical carrier that's a typical carrier deployment model and what you get there is you're able to detect all sorts of volumetric attacks as well as layer 4 attacks and things but because you're not in the path you're not always going to see let's say an HTTP web-based attack and so the on-prem device which is an always-on 100% of the traffic is going through that is going to see that type of an attack where unless the carrier is running an always-on type of service themselves which more and more carriers are moving to if they're not running that type of deployment model then the value of the CPE device is to look for those type of application attacks that the scrubbing center wouldn't see could we use the mic at the back of the room for questions and answers or you could just repeat the question any other questions okay if not thank you all very much I appreciate your time