 My name is Brad Woodberg. This is a talk about network application firewalls. I'm with Juniper Networks. I'm a security engineer on the high-end SRX product team. But first, let me thank you all for coming out, especially on this Sunday, matinee afternoon. Sorry if I have a little bit of a Vegas accent because it's been a long con, but it's been awesome. So once again, thank you very much for coming. So what we're going to talk a little bit about here is we're going to start with what exactly network application firewalls are. We're going to go into some description of basically what they can and can't do, vulnerabilities, and deploying them right. One thing that I've noticed when it comes to network application firewalls, many vendors have them now. It's really something that's really picking up steam. A lot of products are integrating it. But very few, if really I haven't heard really any explanation from the different documentation, marketing, literature, whatever, of what these actually do, how they function more importantly and what potential vulnerabilities they have. And I think that that makes a really big difference. It is very important to understand what the limitations are, and that really hasn't been discussed. So basically, kind of the key issues that you can think about when we're going through the talk is basically that these new network application firewalls, they're not going to change anything in terms of the need for traditional layer three, layer four, stateful firewalls and IPS. Basically, there's limitations both in the technology and also there's certain vendor-specific implementation limitations that they could have. So if you're looking at deploying this technology, it's definitely something that you want to check out, make sure that they're not cutting any corners. And basically, I'm going to just talk briefly then just about getting it right so that you guys can actually take away and have some practical knowledge for this. So basically, let's talk about the evolution of kind of network security. First, we had stateless packet filters known as ACLs or accessless. These were kind of some of the first generation of kind of access control on networks when it came to the actual network layer. They were traditionally implemented at routers and also they could be done on switches as well. But they were quite limited. I mean, they could function very fast. They could be done in hardware, but they were quite limited. They didn't have any other knowledge. They didn't take the bigger picture of a connection in the mind when it came to the actual packet processing. It was just, does this individual packet match these characteristics and do I permit or deny it? So that had a lot of limitations, especially in the early days when there was many vulnerabilities being discovered in the actual TCP IP network stacks. So then we got stateful firewall. And that tried to assist to, first off, fully categorize a connection in a flow or a session that also gave us more capabilities when it came to network address translation as well. And it also took into account the statefulness of the actual layer four protocol. So like TCP, you couldn't just spoof flags and pass those through. You actually had to have a full connection. It was set up and it was torn down. Then we got full IPS, or well, originally it was IDS, but we got full IPS. And basically that took a lot of the limitations when it came to stateful firewalling into account because part of the issue with stateful firewalling is while it did do a good job of restricting actual traffic, it didn't do anything to be able to block exploits, be able to look deeper into the flows and determine what the actual application behavior was and so forth. So we got full IPS to basically handle the limitations of stateful firewalls and access lists. And now we have application firewalls. And you'll see, and this will be part of the talk, they cover a lot less than what full, stateful, I'm sorry, what full IPS did. We'll see a little bit more of that. So really what's new here? What kind of differentiates this network application technology? And again, don't think that it's not necessarily that it's a separate box. A lot of it is just integrated into some of the current generations of firewall products. But what's new? First off, we have something called app ID. Now actually app ID isn't new at all, but the application of it into a firewall is slightly new. And basically what it's going to do is it's going to actually look deeper into the actual connection itself. It's not just going to stop at the layer three, layer four level of inspection. It's actually going to look a little bit further to determine what the actual application is itself. As I mentioned, app ID, its purpose is to detect applications, not exploits. And really it's been around for quite a while. I mean it's been used in traditional IPS products so that they could do port agnostic detection. So you could have HTTP running over port 493 or any port. And it would still be able to apply the detection, basically the protocol decoders and the parsers could still be applied regardless of what port it was on. And this technology has also been used for URL filtering and network AV products as well. So it's not anything that's new, but it's something that's been extended and put into kind of a new application. So in terms of how app ID does pattern matching, there's different algorithms and we're not going to go into those in much detail. A lot of it is really the same types of pattern matching techniques that have been used in traditional IPS products. And also as I mentioned, different layer seven service products like URL filtering and AV. Basically what typically has to happen is first the firewall is going to premier deny the traffic. There's some pre-processing, which we're going to go into in more detail. And then we actually do the pattern matching. There's different string matching algorithms like Boymore, Ahokrasek and Ribbon Carp. There's DFA based state machine matching. And then of course there's also hardware which is being leveraged more and more to actually do the pattern matching. Now there's one thing that I wanted to call out when it comes to the actual application matching is kind of an interesting new topic which is nested application detection. Because if you think about it, nowadays HEP is almost like the new TCP in a way. Most applications that are being developed are being developed on web interfaces and there's several reasons for that of course. I mean you guys know most clients have web browsers, the server technology is freely available and it's very mature, works great. There's lots of toolkits and underlying technology especially with things like JavaScript and all the HTML5 and everything to really give the applications more color. So they've been developing more and more applications on top of HDP and HDP is just an example of what a nested application could be. So if we just stopped at that real application level at layer seven, we said this is HDP, we wouldn't know what the actual, we'd be pretty limited because obviously there's different applications like YouTube or Pandora that folks might not want versus Outlook or Google Docs or something like that. So keep in mind that there's also the concept of taking it to another level with nest applications. Now I just wanted to show what an example of an app ID signature may be. Basically these are pretty similar to IPS signatures as I mentioned. We have both a layer seven application and also a nested application. So looking on the left side, basically we're looking for a DFA pattern and we're doing so in both directions in this specific implementation. And that's really actually quite important as you'll see later. If you only look in one direction which I've seen vendors do, different implementations do, typically for performance, you're basically, there's a good chance that you could be pretty easily evaded and I'll go into some more details on what that could look like. So basically we're looking for specific patterns in the client to server direction and the server to client direction. In the case of a layer seven match, basically we've already identified what the parent application, in most cases it's HTTP, it could be other applications as well. And then we identify, we're looking for more information once we've actually identified the parent protocol. So we're looking in this case, we're looking at looking for Facebook, we're checking the header host information and the URL in this case to be able to identify that this is Facebook running on top of HTTP rather than something else. Now what's really critical to understand in addition to just the underlying technology itself is that app ID is being used to feed a lot of different technologies that are being integrated into these firewalls. So for instance, the information that's gleaned from app ID can be used for application firewalling which is kind of the core thing here whether we permit or deny the applications, it can be leveraged by the IPS engine for detecting what application's running so it knows what type of inspection to do. Antivirus, URL filtering, different applications, QOS, there's a lot of things that are relying on the information being gleaned from the app ID engine to be able to make effective decisions. And because of that, that also means that if you can potentially trick the app ID engine then you can potentially bypass these other layer seven services as well. One relatively new technique is called application caching and we'll talk a little bit more about some of the limitations of it. Basically doing app ID is expensive or at least it's a lot more expensive than doing just your traditional layer three, layer four forwarding, stateful firewall. Not as expensive as IPS but typically you still are gonna have to do a lot of pre-processing and then you have to do the pattern matching. And in the case of good applications, what's gonna happen is typically if you go to a web server on TCP port 80, it shouldn't be changing applications at any time. It should be HTTP every time that really shouldn't be changing. So sometimes application caching is turned on. It's not that it's a bad thing but it's an important thing to understand the limitations because basically if you're doing application caching it's something that a malicious attacker could potentially leverage. And while I was writing the presentation, I was watching Aliens so I was really hyped up so I put some Aliens quotes in there. So let's talk about the pre-processing. We've already discussed a high level of what the actual application identification is. It's doing the pattern matching but before we can actually do any pattern matching, there's quite a bit of pre-processing that has to be done. And if you guys are doing any kind of evaluations or you're checking out this technology, this is a really, really important point to think about. I'm not gonna name names but especially in some older routing code where they're doing pattern matching, they were doing no pre-processing. So if you just fragmented the traffic or used TCP segments or any kind of evasion, it wouldn't detect the application because it was just doing a simple dumb pattern match on the actual application traffic. So it was just looking for HTTP. And here's an example. Basically, just in the case of fragmentation, if you were looking for, let's say, get an HTTP as the pattern for the application, if it was just in a single packet, that could be fine. But basically if you did any kind of fragmentation, if it was looking for that pattern of get, the HTTP and the get in an individual packet and it didn't reassemble it, then you'd be able to pass this right through. The hosts on either side obviously will handle the fragmentation just fine and they'll reassemble it and you can potentially get the traffic through. So just basically you have to do all the same things that a host is going to do to ensure the fidelity of the traffic. Any kind of reassembly is gonna be quite important. Ordering is actually gonna be another thing as well because kind of for the same issues with the case of fragmentation, naturally packets can get out of order. That's well known and also an attacker could try to use this to their benefit as well. So if you don't match the packets in order and you don't reassemble, then you can potentially get stuff by as well. So again, this is kind of why doing the actual app ID is more expensive than doing just simple firewalling because there's a lot more that has to go in it, more memory required to hold onto the packets in the stream for the entire window, et cetera. And of course, doing the proper reassembly is also critical. All the same evasions that we've seen for IPSs with TCP segment overlaps and underlaps and fragmentation, it all has to do with the same stuff. So when it comes to application firewalling. So in this example here, if you were to send two segment threes and one was HTTP, one was SIP, how is the app ID engine gonna know which one, if you want to allow HTTP but deny everything else, potentially you could get SIP through by also just kind of piggybacking that packet at the same time if the pre-processing wasn't being done properly. And of course, our friend the Ghostbusters, they got it right too. Can't cross the stream, so. So what we're gonna actually do is we're gonna dig into some examples now and look at this in kind of practical real world application. So one thing that I didn't really emphasize yet, but that's really important to, well I guess I subtly implied it, but it's really important is unlike firewalls, which know exactly what decision to make on that very first packet, right? They know if it's gonna be denied or permitted. Network application firewall may not. I mean obviously you can still have the same layer three, layer four stateful inspection and it can do basically you can make decisions at the layer three, layer four level, but if that traffic is permitted, and let's say you wanna allow HTTP through but you wanna block SMTP or something else, you won't know until at least the, I mean really it's not even the third packets, it's actually beyond that what this application is. So the important thing to take away is that you do have to let some traffic through because otherwise the network application firewall is just, it's not gonna know, certainly not on the first packet. And so looking at the flow table here in this next-gen firewall, basically what we can see here is that the application is unknown, which is zero, you'll see it'll make more sense in the future, but we've already sent three packets that have gone back and forth. Then of course once we send the actual application traffic then that's when we can identify what this application is. In this case it's just web browsing. But as I pointed to earlier, network application firewalls aren't gonna do anything in a network application firewalling isn't gonna do anything to protect you against any kind of layer seven exploits. So in this case just throwing a nice old vulnerability to execute command.exe on a iOS server went through just fine because of course identified it as the proper network application which is web browsing but it was a malicious threat and of course the network application isn't looking for that, it's just trying to identify what application is. So let's kinda go in a little bit more detail here and discuss some of the specific threats, some things that I've tested. And the first one is kind of the fact that network application firewalls in and of themselves are only typically looking at a few hundred to a few thousand bytes in either direction. So it's not going to be inspecting the whole flow, at least none of the ones that I've seen actually will inspect the entire flow, they're just gonna inspect a small portion. And of course the reason for that is because performance and typically an application ought not to change but as an attacker you could potentially do that. Now what's the likelihood of client and server collusion? Actually it's a lot higher than you might think just kinda off hand because we'll kinda, just a few examples, right? Obviously there's a lot of new applications that are trying to be evasive take like peer to peer. The client and the server can collude, they're speaking the same protocol, they can coordinate the message. Obviously if you are a client and there's a server that you don't control out there, then you can't just talk HEP to say FTP or something like that, that won't work. But if the client and the server are going to be speaking the same application protocol, then that's perfectly fine. And I really expect to see a lot more of this with both applications and also with malware as well. Because this malware understands really what's going on, the creators of malware understand what's going on with these types of filtering. They'll start to leverage the same type of collusion, start the application connection as something and switch it over. So in this example, I just wrote a really simple program to do it but you can use like scapey or write your own little script. I started the actual application as HDP and I just flipped it mid stream to start talking FTP, I'm sorry, SMTP after the initial identification had occurred. And of course, because we're only looking in network application firewalls, we're typically only looking at a few hundred, a few thousand bytes. Once you're past that threshold, then you're home free. If there isn't another mechanism to restrict that and we'll kind of discuss that shortly. Now, in this particular, this vendor had this vulnerability before and they actually fixed it. But basically they were only looking at the time at one direction of the traffic. So basically it enters the client to the server and that presents issues for a few different reasons. I mean, first off, accuracy issues because a lot of times you need to look at the server to client response to be able to make a good guess. I mean, FTP and SMTP actually look really, really similar as it turns out. And if you're not looking at both directions, it can be very hard to tell the difference. Especially depending on the implementation, the different SMTP and FTP servers. So actually checking for both bidirectional inspection is gonna be really important. In this example, what I did was I just sent a Git request to an FTP server. And not all applications, remember, will actually, let's say you only were looking at the client to server. FTP, SMTP, other applications as well may not close down that connection, right? So if you sent a Git, the FTP server is gonna say, I don't know, that's bad message. But if all the network application firewall did was look at that client to server direction, then it would say, oh, well it's HTTP but really it could be something else. And then they could just do an FTP file transfer right after without any issues. So of course, if you're not looking at things bidirectionally, that can certainly create an issue for you. Also what happens if you reverse the direction? Again, this is more of an evasion, right? But in not something that a normal application would do, but something that I did have some luck on some different network application firewall implementations where basically I sent the same application but I reversed the client to server and the server to client to kind of see, are they matching? Are they looking in both directions? And more specifically, not only are they looking in both directions but are they specifically looking for the patterns that should be in the client to server direction, in the client to server direction or are they just saying, hey, match any of these and look in both directions? Again, that's something that I saw especially on some earlier routing code. It really didn't, they really weren't checking the directions properly. They were just looking in one direction or the other but the patterns weren't differentiated. In some cases, certainly noticed some port based detection being used so basically you could send the exact same pattern over a different port and it would be not detected. In this case, I sent DNS over, what port was it? Over port 80 or something and versus port 53 it was the exact same traffic but it was detected as being unknown. Now this isn't necessarily a vulnerability because in some cases as I mentioned this has done a little bit more for accuracy. DNS is probably an extreme example because you really ought never to see it on any port besides 53 or 53, 53. But it certainly is possible and if you're evaluating or you're looking in this technology making sure that it isn't just doing the inspection based upon the port can be very important because what could potentially be happening is yeah, they're looking for DNS on port 53 but that may be the only place that they're looking for it and if you're allowing something else out it could be an issue. And of course, one other thing to mention, in the case of DNS tunneling, something that our friend Dan Kaminsky has covered in great detail as of others, of course that would just be detected as DNS in the case of simple network application firewall because that's what it is. It wouldn't necessarily say hey, there's like 10 gigs of traffic being transmitted over here. Might be something kind of weird. It's just gonna be DNS and it'll be perfectly happy with that. So I mentioned about application caching and it's again, it's not that application caching is a bad thing at all and depending on how you're deploying this it could be perfectly legitimate. Like if you're deploying this in front of a data center that you control to like, accept inbound connections. Typically if you're controlling the actual servers then it shouldn't be a big deal. Doing application caching can be used for performance and also in some other uses of the actual app ID information let's say like application routing. So making routing decisions, let's say to like send the traffic through a proxy or something like that. That would really need to use caching because you wouldn't be able to know again ahead of time what it's gonna be unless if you've already seen the traffic. So stuff like application routing and QOS and stuff like that could really leverage the application caching but there is a limitation and potential vulnerability. So in this example what I've done is I just configured the firewall to look for SMTP on any port and drop it no matter what and allow everything else. So just kind of testing, smoke test here. I just send SMTP and it gets detected properly. This is looking at the logging message but we see that it's SMTP, we drop it. Exactly what we'd expect. And what happens or what we're gonna do now is we're gonna actually poison the cache to be able to insert the application in the cache table and see what happens. So in this case I just sent a bunch of HGP messages I just used again this simple program I whipped up but you could use WGIT or really anything as long as the client and the server can properly collude. So basically I just send a bunch of HGP messages and you can see that it puts a entry in the application cache. Protocol six is obviously TCP, port 80 and it cached it as application ID 109 which stands for web browsing in this case, HTTP. And so now, whereas before I couldn't send my SMTP traffic through, I can, I worked just fine. And the reason why is because it identified that traffic on port 80, TCP port 80 on the server which is 192.168.2.13, anything that goes over there until this cache entry times out is gonna be considered HTTP even though it isn't. We can see here now that we're getting cache hits every time that we, so the count is the threshold of how many they need to see before they actually put a entry in the app cache. The hits is how many that we're getting now which is saying yes, this is a cache hit, it matches but in reality we're sending SMTP, not HTTP. And that's exactly what the logs say that this is all web browsing when in fact it's not. Now obviously there's security implications for that but the other thing as well to think about is a lot of folks are using this for logging and reporting and trying to understand volumes of traffic and metrics. So even if something malicious wasn't going on here you might potentially get these reports that the information is completely inaccurate because it hasn't properly, it's not matching the real application. So sometimes it can be more than just a security thing as well. Now caching of nest applications is something that I've been actually quite interested in and it's really kind of a bad idea if you think about it because first off a lot of servers take like a web server doing virtual hosts unless if the actual application ID engine is smart enough to look and understand what hosts it's going to then if you cached a potentially like a Google video there could be another Google plus potentially hosted on the exact same server and that could be both something done maliciously or it could be something perfectly legitimately done it's very common and basically if you cached nested applications and you have to go back and check for the actual caches you're already doing most of the work anyway so there's really no point in most cases of doing the nested application caching because it kinda can just really limit you on your detection. Now a really interesting thing has come up which we've noticed and different implementations are gonna handle this differently but it's called conflict resolution and this is something that attacker might be able to do but what happens if you have an application that looks that matches more than one application so it could potentially match like at some TP and FTP are very similar they could potentially match each other's which how do you resolve conflicts in the actual application detection and that could be used potentially to an attacker's benefit and it'll really just vary by implementation a lot will just do port they'll kinda fall back on the port and say hey if we detected this pattern and we expect this there's kinda like a default port that we'd say okay well this must be HTTP some will just list it as an unknown application or others might just pick one of the two in order of precedence in order of the likelihood. So conflict resolution is potentially something that could be leveraged for both good and bad. Now I've also been doing a little bit of research and this is something that I just kinda crammed in here this week so sorry the slide's a little bit busy but application layer gateways if you guys aren't familiar these are something that I've been around in firewalls for a long time and basically what they're used to do is to they actually do have to they look at layer seven taking FTP in this example looking at the control channel to see what port is gonna be dynamically negotiated for the data channel and the really interesting thing about application layer gateways and how they could potentially interact is that how do you classify the data channel right in the case of FTP it can just be a binary stream so if you actually I did a test and I sent just a P cap right and it actually detected the data channel as HTTP because obviously it hadn't coordinated that because being a P cap I mean obviously there's the per packet headers but if it's just doing some blind pattern matching then it's just gonna identify that as HTTP just fine without actually thinking that hey this could be a P cap so application layer gateways especially when it comes to the auxiliary channel the data channel can have interesting impacts on the actual flow of traffic and application identification what I've noticed is some do a good job and they will actually have the intelligence to mark the session the auxiliary session as being part of the parent session but some may not it's kinda your mileage may vary so if you're doing some sort of testing or something you might wanna look at that to kinda see and like I said the easy way to do that is really just to send a P cap as the auxiliary traffic and see what happens if it picks it up as say HTTP or something else in the P cap or if it's actually smart enough to identify it by the application that it really is so what do we do about applications that we don't know and this is probably one of my favorite things when it came to checking out this vendor is what happens if you don't know an application and this will happen all the time right and it's not just that you can always block unknown applications it's kind of like protocol anomalies and IPS a lot of applications are written very poor so it could be just that it's not following the RFCs or the standards of the applications applications change all the time you have new versions and so it's not really uncommon and also you may just not have an actual application signature or detection for that application so it could be unknown so what I did here was just kind of walk you through what I noticed this particular vendor was doing and so basically I just sent some unknown traffic here's just looking I haven't sent anything layer seven yet I just opened the session TCP and we can actually look at the if I dug into the actual session ID itself we can see the application is unknown it's undecided and layer seven processing is still being done as far as it's concerned just send a few packets back and forth so now I'm gonna send some actually I'm gonna send just a bunch of garbage and I think I showed in the next slide but just sending garbage through right so it's not gonna know what this actual application is and what I noticed was a very interesting thing you know marked it as unknown TCP but I noticed that it said layer seven processing was completed and so that means you know no IPS no AV no URL filtering nothing at layer seven but it got even better than that not only were they not looking at anything from layer seven they actually pushed the traffic down into the ASIC into the you know so out of the processor that's actually doing the security processing just down into the MPU or network processing unit so they weren't even inspecting this at all and I did that simply by just sending some garbage traffic and then of course in that session I was not only able to do that but I could then send exploits through now of course if you send garbage application traffic it's gonna you know your mileage is gonna vary right because you know some applications may just close down the connection while others like FTP, SMTP you know might just say hey I don't know what that is and then you know you might be able to push and exploit through but this could also be used not only for actual exploits but it could be used simply to try to evade the application network application firewall and try to you know push traffic through potentially you know do backdoor communication command and control etc so there's a lot of things that you could potentially leverage with the vulnerability like this and as I mentioned all the different systems seem to be implementing this behavior differently but it's a great one to look at so the really interesting thing that you know looking forward and also looking in the past and what's happened is that applications you know you have honest applications right but other applications are trying to do things to remain undetected now maybe that's something like Tor or BitTorrent or you know there could be perfectly good uses for this so it's not a bad thing but in terms of what I'm seeing is that more applications are gonna get a lot they're gonna go to greater lengths to remain undetected encryption can be one mechanism to do this now it's pretty easy as it turns out to detect encrypted applications because you can just measure the randomness of the bytes so it's called the data entropy you can measure that and anything that's encrypted or compressed should be highly random but anything that isn't would you know would you know ought not to be encrypted at least with anything any kind of standard encryption or compression protocols and for that reason I also expect that we're gonna see more leveraging of like steganography because that's kind of the ultimate especially if you've leveraged steganography and encryption it's kind of like the ultimate way to really hide messages because you're hiding stuff in plain sight it works in prisons it's worked you know it's been around for you know thousands of years so it's not anything that's particularly new but it's a really strong method and of course tunneling applications within other applications as well can be a method to obfuscate the traffic it might be of legitimate use like GRE tunneling or SSL or it may be something a little bit more nefarious and I mentioned just a moment ago the ability to do application ID without specifically pattern matching pattern matching is good for matching you know easy applications and we'll just say you know honest applications but in order to match some of the more dynamic and complicated applications you can't just leverage pattern matching for the exact same reason as with IPS you can't just only leverage pattern matching because sometimes it won't you know the pattern could actually change dynamically within every connection and it won't be something that remains consistent so in the case of BitTorrent there's different ways of doing that I've actually seen some really cool things where they'll actually look at the messages the distributed hash tables and try to look at the super note information that gets pulled down because once the host can start communicating encrypted it's easy to identify that this application is encrypted but it's hard to say hey this is BitTorrent versus you know something else you know which may be perfectly legitimate so doing application ID pattern matching I'm sorry app ID without pattern matching is something that we're definitely seeing a little bit more and that's kind of in response as I mentioned to these applications getting more and more complex and more evasive in nature so really what is that what does application firewalling change and again it's not the application firewalling is bad it certainly is a step better than stateful firewalling but you still it's still a subset of IPS so it's you can't just you know if you're really concerned about security if you're only deploying a firewall before you know that would be an issue but you know and this can advance that to essentially keep honest applications honest right it's just like you know the locks on your door we all know that you know to a normal person they wouldn't be able to pick them but you know as we see right down the hall there's a lot of people who are exiled in it and it's really the same thing with applications and even if you look at BitTorrent or Skype those are examples of applications that people are using and they don't have any idea about how it's functioning under the hood so it's not like you have to be you know crafted a very skilled attacker to be able to leverage these types of evasions you could just be using an application that has been you know written even one that's very public and you know and widely used you could be using an application that really leverages these evasive behaviors and maybe not really know about it application firewalling you know it is kind of a lightweight implementation of IPS in a way it's basically doing the application identification but we're not doing any of the actual exploit detection so you still need to use full IPS if you're going to deploy this and you care about you know not being hacked or at least putting up you know more defense in depth and more controls you know to protect yourself and really a lot of the different network application firewalls they're kind of what you know again as I've noticed they really vary in nature it's kind of a it's not a technology that has matured like you know staple firewalling or you know antivirus is relatively mature it still has limitations but you know it's something that the folks have you know spent a lot of time on this is a relatively new technology and the behaviors are kind of not very well defined it's going to vary on implementation by implementation I already covered this but really I expect more applications you know they're going to be optimizing themselves like take speedy for instance and I know there's been a few talks on that here and at a black hat which is Google's new HEP application you know it can leverage both SSL and built in compression and does things a lot more intelligently you know I expect to see that applications are going to start leveraging steganography and other mechanisms to really make themselves more evasive and that'll be really tough to block I mean if you think about it we'll have to really start leveraging heuristics you know especially folks do a good job and it's not only applications I expect this to happen with malware as well that you know with botnets they're going to start phoning home and they probably already do a lot of this to some degree so really you know what to take away and you know what do you still need to do because again just from the media marketing perspective application firewalls really kind of market as kind of a panacea and it's not that they're bad but they still need to be used and they still need to complement they need to be used in concert with a lot of the traditional technologies that you're already deploying you know you can't just you don't want to open up your firewall and you know just start blocking on application ports you still want to do all the stateful firewalling you still want to you know be deploying full IPS you know and looking for those exploits because the network application firewall you know of itself isn't going to do that there's certain things that may or may not be turned on and you have to look at your individual deployment whether it makes sense to do things like caching and really examining what the default behaviors and default settings are and you know again just kind of following a lot of the same best practices that you've already grown accustomed to you know don't let this new technology kind of lower your guard because you think that it's going to be doing more more than it's actually capable of doing so that's really it I'm going to be in the track one QA room and again my name is Brad Woodberg I really appreciate it thanks everyone for coming out Stuff Count has been awesome