SANS Webcast - Zero Trust Architecture

Key Takeaways

Today we're going to be talking zerorust architecture. A and really the concept here is I want to focus in on how can we apply the concepts of zero trust with a lot of the technologies you already have. We're starting to hear vendors talk a lot about implementations and products that can sell. And in my research and in my opinion both at the same time, these are not necessarily full zero trust implementations. uh and we really need to use a combination of things. So, we're going to kind of start with then what's the need for zero trust and then my goal is to show you some fun little ways you can implement it in your environment. So, okay. So, my name is Justin Henderson. Let me get this going here. There we go. I'm the author of 555 SIM with tactical analytics, the co-author of 455 SIM design and implementation as well as the course author the co-author of the new 530 defensible security architecture. And I'm here because I've had a lot of help from a lot of different people. Seth Meisner, Eric Conrad, Ishmail, Brian Simons. Basically, the security community as we know it's a living breathing thing. It's a lot of fun. And so I like to take the time to share some of the things I find. So for this talk as well as my previous talks, I always try to put these on GitHub. So after this webcast, I will be posting the PowerPoint presentation online as well as there are YouTube videos and a few scripts related to this talk that are also on this GitHub. So at the end when we're asking questions, I'll try to flip back to this in case you need it. uh because for now I'm going to go ahead and go right into the presentation. So really the need for zero trust comes from the old school concept of a perimeter defense and this was back in the olden days we would have a firewall and we had the inside of our network and we had the outside. So really we had this concept of you're a trusted device or user on the inside of the LAN and everything else is untrusted. And that worked. I mean we had things like the internet worm and all those different attacks. They bump up against the perimeter firewall and poof problem solved. But the problem is nowadays when we're dealing with attacks, whether it's worms, automated malware, or actual targeted attacks, pentests, uh, mafia, things like this, this perimeter-based defense doesn't work so well. Now, there's datacentric approaches and those work well, but we need to go even farther than that. like just having a WFT, just having a database security control still isn't sufficient because it's the concept of if you're on the inside, you have more trust. Now, to kind of put this into perspective, when we're dealing with the inside of a network nowadays, we still have things like segmentation. Like we have maybe human resources is on one subnet, maybe IT desktops get a different one, we have domain controllers, we have DMZ. Like we have zones, but even there segmentation is a step towards the right thing. But in between segmentations, if the only thing separating them is the subnet itself, it's not enough controls. And quite frankly, kind of one of my favorite things to point out is today in 2018, when someone's on the inside attacking your network and they're pivoting between VLANs, they're pivoting between zones, the attacks they're running often are not exploits. It's not exploitation, it's log. It's the concept of credential theft and reuse. As an example, not Pedia. Not pedia was a piece of malware that would try to uh exploit eternal blue. But if it successfully found one box cuz one box wasn't patched, it would turn around and use credentials from the box it did exploit. And if you had a thousand other systems that were patched against ernal blue doesn't matter because it would log in to the rest. So the concept of being on the inside equals trusted and has more access is highly insufficient. Instead, there's this kind of new model, this new strategy, this new implementation that's starting to come out called zero trust architecture. Now, this originally was developed by Forester, specifically John Kervag. He's got some videos online that are pretty good to watch on this back in 2010. And the concept really here is on when we're dealing with things like access, like why do we trust but verify? like we're dealing with computer systems. It doesn't need to be trust and then verify. It should be verify then you have trust. It should be the opposite. It we have the ability to calculate full lease privilege concepts and we have the ability to move away from what I reference as binary trust aka you're allowed you're not allowed because there's a whole lot of gray area in between. And part of zero trust is being able to scale into that gray area. Now before we go too far down this rabbit hole, I want to talk about some of the basic principles of zero trust. And the concept here is these first three bullet points. Assume your network is always hostile and internal and external threats are always present. This means things like even your routers and switches could be compromised. And if they were, does that make you uneasy? Like does the security controls you have, are they contingent, hinging on a one major control? Because if so, you're probably a little off of off field of zero trust. We need defense and depth and we need to architect things differently with the assumption of, hey, this thing could get compromised. These things could be compromised. So how do we enforce control and access in internal network? Well, and here what we have cloud, we have business partners, we have multiple data centers. Like the perimeter is not quote unquote dead, but it has been highly extended. Think of this like you have a house. And before we would do perimeter security, which meant I would either come through the front door or maybe I'd come through the back door. But now as things have matured and gotten more, we now have cloud and all these other things. So now I can break in through all the windows, the garage door. I can go down the chimney like Santa Claus cuz why not? So it's not dead. But man, having to put security controls around it requires more effort because there's a lot more points of vulnerability. So because of this under zero trust we're getting to the concept that every device every user every network connection has to be proven. No trust before you have access prove that you have it. And also because we're assuming that things are always hostile that there's compromised assets we must log and inspect all traffic. Now, this is a tough pill to swallow and I don't really think that we're going to have a 100% full implementation of zero trust, but we absolutely can start doing it to things moving forward and then slowly kind of backfill because there's some stuff in here I'm going to show you that you already own and you can already do. And that's why I'm using those examples. I'm not showing a uh uh while I'm a huge fan of it, I'm not going to be demoing like an identity management solution with single sign on federated things, multifactor that works in front of thirdparty applications and can dynamically change your access. That falls to me under zero trust implementation and is fantastic. But I want to scale it back and show you how to do it with things that probably everybody on this webcast shows owns. Kind of an an extension to zero trust is also this concept of the trust level. The verification we have needs to change as time goes on. Think of this as you have a workstation. You loaded it from a gold image. It's got all your software on it. it's patched according to whatever was in that image. So the chance that that system is compromised or has unauthorized software in the beginning is fairly low. But 3 years down the road when you haven't had a hardware refresh cycle, that system has deviated from baseline and is significantly more likely to have unauthorized applications or potentially be compromised. So part of this too is that your risk decreases over time. So we might implement different things like virtual desktops, credential rotation, even SSLTS certificate uh renewals. Uh the concept here is if they get stolen, they get hacked, we rotate them and we lose them. So I'm not going to go too much into that, but that's kind of a common extension such as in the book Zero Trust Networks, which is a fantastic book by the way. So okay, one of the f first mandates of zero trust was the concept of the network is hostile. You can't trust things just by being on the inside. And one of the ways you implement that and what zero trust is really asking for is authenticate and encrypt all traffic, but not just like in general, but literally end to end. That's a tough pill to swallow, which is why I'm going to show you some fun ways addressing it. But if you look at the diagram on this slide, like we have a laptop coming into a VPN concentrator. It VPNs, maybe it's an SSLVPN. The tunnel is encrypted to the concentrator. So like we have connections from this laptop down through the firewall, through the router or switch into the concentrator and that is tunnneled and encrypted. It's authenticated as well. Yet when the laptop goes through the tunnel to talk to say like a domain controller from here to the concentrator might not be encrypted because it's now application specific. So the problem is there's an implicit trust that those two are talking to each other like they should be. It's probably clear text and life goes on, but it's implicit trust when really what we're trying to say is no. no connections unless I've actually verified it. So, the first couple things that I'm going to show are ways that you can practically apply authentication and encryption in a way that greatly increases your security posture. The goal here is whether something's on my inside of my network or is a laptop out on the internet. Are there things that I can use from internal when I say internal your assets to your assets that we can verify and or encrypt that data. So basically, if you're being man-in-the-middleled or someone brings in a device that's not yours, can we control that zero trust concept of lease privilege and uh verification? And the first example I'm going to give here is actually just standard TLS. Standard TLS though can be changed very simply. I want you to think about this for a second. If you have uh your own web servers like say like a company internet, you have uh SharePoint, you have whatever and it's your asset, you're deploying a certificate to that server and your clients connect to it. But usually when you do that, that is standard TLS handshake, meaning the client verifies the server. The server doesn't verify the client. So, think about this for just a little bit different. I go into something like and I've got that little box check that says require SSL and that's great. That means any that it's going to verify the server is as it is and it's going to force TLS connections. However, it's usually set to client certificate ignore. So, one of the things we could do under zero trust for verification and lease privilege enforcement is simply check require. And if you have an internal PKI like a Windows PI infrastructure, you can dynamically deploy and autoenroll all of your assets with certificates. And now because you've flipped from ignore to require, what happens is when you connect to a web server, you verify that the server is who it says it is, but then the server verifies that the client is who the client says it is. And in this case, here's a couple benefits you're reaping from this. If I'm trying to hack you, say over the internet or I bring in a uh my personal laptop into your organization and your server is vulnerable to every attack known to man with the exception of being here at heartbleleed. We'll call that a really weird weird oneoff a rare one. But if I'm trying to do an application attack like let's say I'm attacking I is engine X or the code within the web service itself and you have mutual TLS basically going from ignore to require enabling client verification you've went from TLS to mutual TLS the problem I have now is unless I can steal or somehow acquire a client certificate I can't actually start my payloads and my attacks against your application. because the server verifies the client if it's not one of your authorized clients with a certificate, no access. So, I could be running something like ISIS6. I mean, don't tell anybody I'm rocking that, but here I am running II6 public to the internet and the box isn't getting hacked because that mutual TLS handshake has to finish. Now, in all fairness, if you have something like an internetfacing site and you're taking orders like shopping carts, you can't do mutual TLS cuz your clients are they're not your assets. But this is for your assets to your assets and it works on the public cloud. It works with some SAS applications like as long as you can feed it a CA file and ver turn verify client on this will work and can greatly get you to a zero trust posture for just the authentication verification encryption part. There's multiple pieces. We still have login inspect and other things to do, but to me this is a simple win with huge benefits. A different one, one that I I really love. I I have a lot of fun with this is what I refer to as the rapture according to Microsoft, you know. So, the rapture, we have that in biblical times. It's end of the times and a bunch of people disappear from the face of the world and no one knows where they went. Well, that's Windows domain isolation. The concept here is if you have internal assets, you're controlling them, you're protecting them. What you can do is go into the Windows firewall and enable rules that say traffic must be authenticated and optionally encrypted. And when you do this, when assets try to see each other and they're your assets, the answer is yes. But if I come in with something that's not your asset or is not part of this domain isolation, they won't see the other systems at all. And if they somehow figure out how to man in the middle one of them, which would be really hard to do anyway at this point, but if they do, they can't tell what the traffic is and they can't see any of it because of what you're doing. Now, I'm going to drop into a virtual machine here real quick just so I can kind of show tell you what's going on. So, I'm on I know. I'm sorry. So, you have Windows firewall and in the Windows firewall when this opens up, what I'm going to do is show you where you can put these IP sec rules. And what this is, that's not where I wanted. Here we go. Go back. I want here advanced settings. And you control this with group policy. But this little option that says connections, a lot of you are have seen that and you're kind of wondering like what is that? So if I go through this wizard and I say certain subnets, certain IPs, I'll just do a custom rule here real quick. And I can say anything from this machine over to I'm just going to put a box in here real quick. 10530.2. This could be a subnet, could be whatever you want. You could say for everything require authentication both inbound and outbound. And I could say how do I want to handle authentication and I can natively use Keraros. I can also flip over to doing certificates as well as other forms such as a pre-shared key. Finally, I select what traffic. I'll just say any. And which profiles to apply it to. And I'm going to go ahead and finish this out. I'll just call it test ipsec rule. And when I do that now any traffic from this box going to or from the 10530 network now has authentication encryption assuming authentication works and even that as far as how the authentication encryption works you fully control if I do properties on the fire firewall itself there's this little IP sec tab and when I go through here I can customize it and say hey when you do key exchange Let's do I'm going to back these out and I'm going to do something like Shaw 384 AES 256 and we'll do elliptical curve P384. So I can get some really strong security for both authentication and encryption here. Same thing here. Let's force encryption for everything. And I get again I can crank this up as high as I want it to assuming my operating system support it. Here's Vista and later. So that would work and it's extremely strong encryption. Now I'm going to go ahead and set this. Now here's what's going to happen. If I do this and I enable IPSec between different Windows machines and I start to do something like even like a ping, well without IPSec, I can see the ping if I were man-in-the-middleing or capturing that traffic and I'm going to be able to see things like the ABCDE EFG payload because that's what a Windows ping sends. But with IPSSEAC enabled, which was controlled via group policy via the standard firewall, and by the way, this is not just a Windows thing. IPSec is supported by IPv IPv4, IPv6. You can do it on Windows pretty easily. You can do it within Linux. You can do it within Mac. So, this is not something new. And if you stop to think that bottom side of this picture, that was a ping. But how do you tell it's a ping? What's the point? You don't. It shows up as an ESP packet. It's encrypted. It's encapsulated. You don't know whether this is TCP, UDP, or ICMP. But does ping, ICMP, echo reply, echo response, does that natively support authentication, encryption? It doesn't. It does not support encryption natively. So by using IPSec it sits lower in the stack and now you can provide lease privilege verification, authentication and encryption even for applications that don't support that. Uh this is a favorite for mine like in healthcare organizations they routinely will have old applications that they can't fix the code. Maybe the vendor went out of business or the vendor is just refusing to do it until they switch to a different product line. But under HIPPA, we're supposed to have unique authentication, logging, and encryption when accessing healthcare records. This might be one of the ways to do it for something that's kind of old and busted. So, IPSec has some good wins. Now, I will caveat real quick so that you guys don't leave the webcast and just go IPSec crazy. You can't enable it for everything because you have a chicken and an egg problem. For example, you can't authenticate if you don't have an IP. Therefore, DHCP can't enforce IPsec because you have to get an IP address. Also, you can't do IPSec to the domain controllers because you need DNS and Keraros for authentication. So, there are weird tricks around such as using pre-shared keys between those. But usually what's recommended is you make exceptions for a few things like DHCP, DNS, and Active Directory domain controllers, and then the rest, poof, domain isolation. Everybody disappears. So you try to do a scan from Cali or something like that, you don't see anything. If you somehow get access to packets, again, you just see ESP and you're like, I can't tell what's going on. I can tell these two IPs are talking, but I don't know what they're doing. So those are two methods, mutual TLS and IPSE. There's also this new concept coming out called single packet authorization. Now, this works fairly well on Linux, the Windows and Macs. You're probably looking for a commercial solution to this for stability. This is kind of the replacement to the old school part port knocking where you would hit certain ports in a certain order and then all of a sudden the firewall would open up a port. But this time, what we're doing is we're sending a single packet, one packet. It's usually UDP. And in that packet is a one-time HMAC that says, I want to authenticate and access this port and here's my credentials. And if the server that's receiving this pulls in that single packet, the authentication passes, then poof, it dynamically opens up the host firewall just for the one machine or user that's authenticated and then they can connect. Now the subsequent connection is just normal. Could be FTP that's still clear text. It doesn't matter in this case. At least I'm verifying access before granting it instead of just saying this subnet has access to FTP. So that's still a step up uh even though you're not technically authenticating and encrypting the entire session. Again, how far we go down the rabbit hole in lease privilege and zero trust, that's where we have to go with this. Now, for me, true effective zero trust has to implement what I'm referencing as variable trust. And this is getting away from binary yes no decisions. I can't just say you're in IT granted access. Because in truth, just because you're in IT doesn't actually mean that you're trustworthy and all is good. like it ideally should be, but that's not necessarily the case. So, this this concept here of variable trust allows me to dynamically change access for good or bad, and it works both ways. I consider this akin to a credit score. So, think about this as, you know, you're doing like Credit Karma, maybe you're doing like Mint.com, and if you have good credit, your score goes up and you're more trustworthy. If you do things like don't pay things every month, you lose points and your credit score goes down. Well, on the slide, I'm kind of showing this in context of information security. The points on this slide actually don't really mean anything. You could use them in a quas scoring system, but the goal here is to use things like Knack, uh, software definfined networking, network virtualization, an identity management solution, or even something like a next-gen firewall to dynamically implement conditions to change your access and again in a non binary way. So here's an example. You are trying to access the credit card database and it requires 40 points. Again, the point system doesn't really mean anything, but it helps understand this concept. So, you need 40 points to access the database. Well, you logged in from with your credentials and it succeeded 10 points. The device you logged in from also authenticated Active Directory and that's a device you normally use. So plus 10 because it's one of our corporate assets and plus 10 again because we know that device and it's in the normal location. At this point you have 30 points. However, you need 40. So the problem here is I don't have enough to get access the database. In this case it's not just oop access denied. Now instead it's if you want to access this you need to do more steps to verify trust. So maybe it pops up a capka maybe it asks for a smart card. Maybe it does something like Google authenticator. So we do multifactor authentication or a smart card. We gain an additional 20 points because that's strong. Now you went from 30 to 50. Access is granted. But later on you're surfing Facebook and Twitter. you go to a known bad link and you start to lose points and again you could kicked out or you could be asked to scan your hard drive. Again, variable trust is you taking the time to put conditions for accessing things where trust can be lost and gained in your level of access changes in the same manner. Think about this kind of as um let's talk about like a nextg firewall here for a second. So kind of the new identity model here is your user account plus your device plus even other conditions like time of day, geol location, all of that is kind of your new identity. And in zero trust, the user plus the device equals the network agent. And this is just kind of a push over into that direction. Example, you might be a developer and you're issued a corporate mobile phone or a tablet and you also have a corporate laptop. Now you have access to remote onto the production servers and push code because you're a developer. But does it really make sense that you can do that at home on your mobile phone? Like if you're pushing code into a critical web application, you probably should only be doing that on your corporate laptop. maybe on the VPN, but again, your user plus your device plus other conditions should equal your access. So, this shows just two firewall rules. One is saying, hey, if you want to access the production app servers from your tablet, the answer is no. Nope, you're not doing that. If you want to do it from your corporate desktop or laptop, yeah, that's what we expect. That's what we want. Go for it. But in those cases, it could even be this corporate workstation's only a desktop because if that ever left the building and was turned on, access would be denied because it's missionritical code and we can't ever let it leave the building. So you can see here where we're changing the level of access here. Now in that example, that was still more of a binary trust. Like we did the whole you have access, you don't have access, but it was multiconditional. And that's a step up, but we can go so much farther than that. So, on the GitHub page I showed up earlier, there is a uh YouTube video. It's less than an hour long, and it's on doing things with zero trust using a 48 firewall. This would work on Apollo and many of the other uh awesome firewalls out there. But think about this as a second. Rather than just saying you're allowed or you're not, I could do something like this. I create an address group called normal assets and every asset gets put into the normal uh normal assets and then I create lowrisk, medium risk, high risk, whatever risk groups I want and they're empty. But in this example, what I'm doing is I'm having a PowerShell script reach into a SIM when you could do this to anything, maybe an network security monitoring, an IDS, whatever. But it's reaching into the sim and it's basically saying, are you observing things from any assets that's unusual? And it could be, you know what, this desktop's making a decent amount of connections and that's more than normal. And based on that, it reaches into the nextG firewall here and it says, you know what, that asset is no longer a normal asset. It's now a lowrisk or a medium asset. And again, you're defining what these conditions are. And so it starts to move them around. So now your access isn't just yes, no. Now I can do some really weird things. For example, one of the things I do at my house just because I have too much time apparently is if my home systems or my lab starts to do unusual activity, that script will reach into my house for the only thing it does initially is it'll pop a captive portal by moving the asset from the normal address group to the lowrisk address group. The only access that actually changed is well, it's actually none. The only difference is it'll pop up a message that says, "Hey, are you human?" And the only button is yes. Now, for home, I do it because it's funny and I don't want someone being smart and clicking on no or something like that. But the goal here is if one of these machines were infected and they were trying to reach out to the internet, the captive portal actually is enough to stop them from working because it needs to be smart enough to click that yes button. But if it's me, I'm minorly inconvenienced because I have to click yes and then I get all my access back. So it's kind of fun. And you don't even necessarily have to disconnect all the sessions because you can apply this logic. Now when I go from low to medium now all of a sudden it's turning off certain URL categories and once I'm high-risisk I lose all internet access but variable trust and implementations through Knack SDN network virtualization nextg firewall or identity management solutions you control what you do. So all of these to me are technologies you might own and you can hook into them to implement zero trust and I highly encourage you to do that. Don't do binary access, do variable trust. Okay. Now the flip side of the coin when dealing with zero trust is implementing log and inspection of all things. And I got to be honest, that one bullet has caused me a lot of heartburn in the these years. And I say that because I feel that's been interpreted by many organizations as log everything. And then when you log everything, that turns into too much data. Let's ignore it all in one spot. And that's unfortunate because if you log certain things, the right things, you bring them into a central location, you can do some really awesome analysis for catching the adversaries and evicting them from your network. Now also by collecting the logs of what's going on, you're also making it easier for you to implement things like variable trust because now I can use that central data repository to do analysis and decision making for infrastructure. Now this does require a level of maturity. I basically need something like a SIM. Technically, to be honest, you could also do this with some of the newer endpoint detect responses, but you're going to be missing a lot of cool network data, and you're not going to be able to parse custom log sources, but you could use either one. My preference would be all the things. Give me EDR, give me Knack, give me nextG firewall, give me endpoint logs, and ultimately give me a SIM so that I can handle that in a central fashion because a SIM is not log collection. If you just wanted to centralize your logs, you need a log sensor. That's it. Even like SIS log, it's cheap and it can handle a lot of logs. But what we're actually wanting is a system that lets us do analysis so that we can verify that unauthorized activity, whether automated or manual, is not occurring. And we want something that's efficient for doing analysis and finding the bad, the evil. And we want something that can automatically kick off automation, do things like orchestration, kick off PowerShell or Python scripts. And a SIM is that when done correctly. So this this kind of webcast is really focused on both um 530 defensible security architecture which leans towards what we talked about at the beginning of the slide as well as log collection and analysis and sect 555 SIM with tactical analytics where we really focus in on I don't care what SIM you're bringing to the table. How do we get from a CL a collection box to something that does massive analysis alerting automation and so on? And that's what we want to do. think things like enrichment. We're told to not verify anything bas or I'm sorry, not trust anything, but verify everything. And part of what we need is the SIM to do that for us. So this is the concept of quit working for your SIM and instead have it work for you. example, and I don't care where we're doing this at, but I could start at google.com here on this slide. And I could tell the sim the platform to enrich that, add context to that so that I can automatically do false positive reduction, have alerts that I otherwise wouldn't do or if I already would have alert, maybe I'm an enriching alert that it is better for human analysis and even things like machine learning, data science. So to do that, I could say things like, you know what, bring in the who is information, the creation date, when the domain was registered, figure out if this is a top 1 million site, or really other things like has it ever been observed in this organization? Because there's a difference between newly observed and newly registered. What is the entity associated with the IP address behind the domain? Well, that's things like Google incorporate or Microsoft or Netflix. Not the geoloccation, but the geoN, the entity. Is it a randomly generated domain using natural language processing? What is the length of it? And I could go on and on, but I didn't have time to fit it on this slide. So, I don't care whether you're doing this during log ingestion and parsing. That's a common spot. It could be at the time you process your search such as within Splunk or to be honest you could also do some of this within a orchestration platform like a so s o r a soore to be honest I prefer to do it in multiple stages because even if you're using orchestration having the enrichment up front also helps the orchestration platform go even farther and there's your verification and your response capabilities allin one. So that is part of this having this all at your fingertips so that you can make these actions. Now to me I also kind of extend zero trust. Uh this is kind of my personal opinion. Um this might be a little farfetched for some of you and I I just want to share this because I find this to be very effective in production environments. I've seen it work and so I just want to share this because I kind of I lump this into zero trust. And the concept here is the adversaries are not playing fair. They're not playing by the rules. They're hacking us. They're doing exploits and we're just sitting there and taking it. What I want to do as a defender is I want to not play fair in a legal way that I can't get in trouble or break my systems. And an example of that is whenever someone browses your web servers, your web servers are saying, "Hey, you know what? I'm Apache. I'm running version 2418 and guess what? I'm an Ubuntu bucks. So if you'd like to try to run attacks against me, that's probably what you want to target." And that's crazy to me. Like why are we giving out so much information to systems that one we shouldn't trust. We know they're not trusted. And quite frankly, even to our own systems, they don't need to know that. Like Firefox connecting to a web server, whether it's I is or Apache, it still loads. So what we can do as defenders is start to change the game. Part of it, if you just want to take the easy route, is using the built-in capabilities of our services to just tell them, hey, settle down, calm down a little bit. Quit saying exactly what you are. you know, like an Apache, why don't you just say that you're Apache and call it a day? The version number is probably not going to break the application and you're still being honest and saying you're Apache. And that can stop a lot of automated attacks and some scan activity. But really what I like to do is I like to step in and actually modify things. And this can be applied uh say like a web application firewall running in front of a web server. This could be running something like mod security on Apache or Engine X. It could be doing like URL rewriting and different modules on top of the newer versions of what it's allowing me to do is change things on the fly. So now you're trying to scan my server. It's running Apache and I tell it to show up as I is 85. Now why IS-85? because I want it to be a new version that is less likely to be hacked to begin with because I don't want you running exploits against me. But even if you find one and run it, it'll be for and it won't work against my server. Now you have clients hitting your sites, the page still loads correctly, but automated attack tools and scanning look for the wrong things. Wrong file extensions, wrong exploits. Same thing works in different directions. If it's external, again, it's a bug hitting the windshield here, but it's not going to work. If it's on the inside and someone runs an IIS attack against my Apache box, well, now, not only is that not going to work, but I now know for sure somebody's doing something they shouldn't do. Even like if you ask me for like an ASP page, this site doesn't have ASP pages, but the scanner because it's an automated tool accidentally does it. And when you're using these, you can do stuff like, you know what, for the developers, let them see the real service banner, but for everybody else, it's I like you can make exceptions as you see fit. And this kind of concept works across many things. Even things like a web proxy. your clients go out to the internet and they say, "Hey, you know what? I'm Google Chrome on a 64-bit box. It's Windows 10 and here's the exact version of Chrome I'm using." And that is just crazy. So, you could use a web proxy on the outbound to also do this kind of you rewriting on the user agent. The difference is you will have to have exceptions on user agent modifications, but it's not like you're going to have to have thousands of these things. So, it's still something that is manageable. And in fact, it could also solve the problem where you have old web applications that must be used by things like Internet Explorer, but all it actually is is your user agent has to identify it and then the site works. So this has its advantages and disadvantages, but I like it from the technique. So okay, before I close out the session, I do want to point out here in about two weeks, we are having the tactical detection and data analytics summit. It is solely focused on two days of glorious details on how to catch ad adversaries, blue team detection, detect simple ways and even things like how do we apply data science with security expertise so that it actually works correctly. So it's a no fluff awesome time in Scottsdale's Arizona. I'll be there. I highly encourage you guys to come and make the summit. I don't make any money for you to be there. I'm just saying that because this is my favorite event of the year and I'd love to see you guys if you can make it. So, at this point, I'm going to go ahead and turn this over for questions and I hope you guys have enjoyed this webcast and after questions we'll release you for the holidays. Well, thank you so much Jason for that or Justin I'm sorry for that great presentation and we do have um a question ready for the Q&A session. And Debbie, are you have do you have the questions on your screen because I don't have them on mine. Uh, yes, I'm showing the questions. Um, do you recommend using these type of banner rewrites? Debbie, I apologize. I can't hear you. I'm sorry. Let's see here. Let me I'm going to try. There we go. I can. Okay. Can you hear me now? I can. Yes. Okay, perfect. Do you recommend using these type of banner rewrites in enterprise environments to address detection attacks? I do and I have these running in enterprise environments um from small, medium, and large and they do work, but it's not something you can just blindly put in and hope that it'll just work right off the bat. You will have to make a few exceptions. Um example, the user agent one is the one that's more likely to break something because certain sites only uh work with certain user agents. Those are where you'll have to make some exceptions, but it's just like in a web proxy making like whitelist and category exceptions anyway. Uh so it's usually not too bad and you can do it in uh kind of sections. Okie do. Um another question, any estimate for how much overhead would be added by using mutual TLS authentication and IP sec? So the overhead is not on like added encryption or authentication. The overhead is on maintaining the certificates. So like if you had automatic enrollment for Windows and you were using the same PKI for Linux and Mac systems, there's not much overhead. From a performance standpoint, the handshake up front is different, but once it's established, it's encryption like you're used to. Okie do. And I think that's all our questions for today. Okay. Anyone does have a question afterwards you think of something that you did want to ask Justin, please send them to qsand.org and we'll get those right over to him. So, thank you so much Justin for your great presentation. To our audience, we greatly appreciate your listening in. For a schedule of all upcoming and archived SANS webcasts, including this one, please visit sans.org/webcasts. Note, you can find your CEUs for all completed webcasts by logging into your SANS portal account. Navigate to your account dashboard, then click my webcasts. You can then download your CEU on the right hand side of the web page. Until next time, take care and we hope to have you back again for the next SANS webcast. Thanks everybody. Have a good holiday.