 And with that now with that said it is my pleasure to introduce a friend of ours from the packet back You've spoken here before. I have. Yep, and you've spoken here before Garret Montgomery on target-based security model All right So, uh, my name is Garrett Montgomery. I'm here to talk about the target-based security model and in case you were Misled by the description. This isn't the best way to do everything You're not going to find an answer here that's going to you know go save your network So you're not going to run out of here with something to do you're going to run out of here with something to think about So hopefully this helps So my background you can read about it But what I wanted to talk about is that I work for a company called breaking point You may have heard of us in the past. We were a big deal. We got acquired because we were a big deal I technically work for Keysight now, but most of this knowledge comes from breaking point Which has been doing exploit simulation on the network low level stuff for 15 years We have a really big repository of things that we can send on the network 50 000 plus in our catalog. So we kind of have an idea of what we're talking about and I hope that I don't use jargon That's not applicable outside of my industry. So I apologize ahead of time if I do And to that end terminology refresh you just real quick Hopefully everyone in here is familiar with the difference between the vulnerability exploit and payload like when you're talking about malware I'll be talking about malware payloads a thing that does something on your system An exploit would be how it gets onto your system and the vulnerability would be how The the chink in the armor that the exploit uses to deliver the malware payload So I'm going to be splitting it up like that and just wanted to give you a heads up Same thing with device versus technology versus control. You have to buy a device Devices will say that they implement some technologies and then under the hood They are actually implementing different kinds of controls So there's a functional difference here and it's important because I'm going to be talking mostly about controls But when you go and try to protect your network, you're going to have to buy a device And when I say atomic badness, I'm talking about an attack in the smallest form possible that you can see it If you have a command injection, you might be able to see the attack in a single packet If you have a buffer overflow, that attack may show up on the network across several packets If you have a DDoS where you're sending thousands of packets The atomic badness that I'm talking about is going to be all of those packets together The smallest level that constitutes an attack Same thing with say the command injection. It may just be in that one packet So last year my team got a challenge After years of making things difficult for security devices and testing them We had the opposite challenge to provide suggestions How would we block these things that we are sending and with our large catalog that was a challenge Personally, I'm a fan of automation. I hate doing things manually So I did not want to go through all 50,000 of them and choose something and say that's the way to block it I also didn't want to have to come up with differentiating between different devices Different technologies and different controls because each device that you buy is made by a vendor that vendor may reuse the technology across multiple devices Each vendor also calls their devices different things and the technologies that they use they're called different things Under the hood though, they all typically Implement the same controls Finding out what those controls are is what we had to do or at least that was my intent I wanted to find controls that would be applicable across technologies and across devices So that's our challenge. Some of you may have seen this. I mean you may have to deal with this day to day There's something in the news your boss says are we protected you need to know How do we defend against it? You have certain things on your network. You have devices at your disposal What are you going to do to block them? And if you don't have the recommended device, what are your other options? So that's kind of what this talk about is about today breaking things down so that you can see that you have More options than you might realize So in order to meet this challenge, we did a lot of threat modeling and here's an example of what we did We have a user who's connected by some kind of device to say internal resources You may be protected your internal network may be protected by a device that does Intrusion prevention, which is a technology different vendors again have different names for this and that they may have different Certainly have different models for the devices that implement it You may have an exposed cloud. It may have some servers. It may provide services. You may even have specific devices technologies and controls that protect those Externally exposed systems. Hopefully you've got a firewall sitting behind a router And that's how you connect to the internet So in the case of a drive-by download if you break it down into the components What happens if you're looking at wireshark from the user's computer? There's a lot of different things that go on when a user goes out to a website Usually the first thing they're going to do is type in a name to their browser the browser is going to go Hopefully to internal dns and say what's the ip address? That's a request and a response internally Based on that answer the ip address is given to the user's computer. They can then go out to the internet through these devices Get the content that they want and then it comes back. Now in the case of a drive-by download there may be some Server that looks at the different User agent strings that a browser will provide to say hey I'm this kind of browser in case you want to do different things for me to show me different content An exploit server may use those strings to deliver an exploit that's targeted at a specific browser So you may see a redirection happening there There may be a request that tells that computer it comes all the way back in your network and says go to this site Because I have some special content just for your browser And then the user will again go back out and go to that site and it'll get the bad stuff It may be an exploit for the browser Or they may have tricked the user into Downloading something at which point you can install malware because all you're doing is saying i'm downloading an executable i'm double clicking it and i'm running it and Maybe with windows 10 you have Can I do this do you want to allow this action to happen? This thing wants to do uh elevated privileges and you say yes I do because I downloaded it from the internet with that express purpose So fundamentally there's nothing really different about an executable that installs a program that you want to use And an executable that's considered malware that you allowed to run on your system So it's important to keep that in mind from the low layer perspective Along these lines you have actually multiple different options for blocking something you could say have a list of host names Or fq dns that are not allowed to be resolved You could implement this as a control On your user's computer you can issue images that have say a blacklist It can be host name. It could be ip address You might also have it implemented on your local dns server don't resolve these names And what happens the user can't go most users can't go because they don't know the ip address You might be able to look at the content that comes in or out it's your ip s because I can block it here because I recognize This is bad stuff or an ip s might be context aware and say oh i know that these ip addresses aren't allowed Or I know that this specific content from this ip address is a bad combination I'm not going to allow it in theory. You could do that You could also block it at your firewall. You have that option Potentially you may not know ahead of time that you should do it, but you could block it there You can also block it at your router. You may just decide you don't want traffic from certain ip ranges That's another option you have does it scale? Is it realistic? Perhaps not, but it could be done and you'll find that some vendors today are doing What we call orchestration they take information from one place and apply it at a different place because they Provide context to devices that need it like say your router. It can block by ip address if it has a reason to block by ip address So again, we have this large catalog of attacks. We've got some systems We have all these different things and we have to say what's the right way to protect them So again, like I said, I'm not the most industrious. I'm lazy I wanted to find a standard something written that would tell me what the right thing to do is I want to go look something up so that when I argue with somebody I can say I'm right because here's this reference That we all agree is great It means something and it says I should use this control or this device or this product But what we found is that there's really not anything out there You've got different standards and frameworks and they're very broad say for infosec programs as a whole That tells you you need infosec. Here's all the different categories that you need There's other ones that are very specific It'll say there's four different thousand or four thousand different types of vulnerabilities And it's up to you to figure out which Of the attacks that you're concerned about matches it And even then what do you do it tells you that it's a certain kind of uh Vulnerability exploiting a logic flaw. How does that help you do something about it? What are you supposed to do to block a logic flaw? Generally, there's no context. There's no going from research to implementation Okay, so there's no Thing that will do exactly what I want make my life a lot easier But maybe there's a list of controls that you can apply you go go and find some textbooks and say Here's the different controls and things that you can use and their purpose and how they relate to each other And this is what I found. This is essentially it. This is marketing speak These are vendors who want to sell you things and they're going to call their stuff Whatever they call it and it's all going to be different and there's not going to be any way to say I need a thing that does this it's Let me hear a vendor pitch and they will tell you why their device is the best for everything And they will poo poo you if you say well, what about this because the guy's selling it to you Doesn't understand what you're trying to say So this is essentially what's out there And again, uh, what about attacks? Maybe if we look at it from the point of an attack What what kind of attack should be blocked by what kind of control or device? There's there's really nothing again You have the same resources, but they don't really apply They're not really useful for the purpose of if I see something and I want to know how to block it Where's my lookup table that says for this go block it with this? there's nothing so That was our challenge. We were like what do we do here? We have lots of problems. We we tried discussing things We we worked out scenarios. We did more threat modeling And this is actually a process that took several weeks We kept trying different things out to see what would work and this is essentially what it was There was lots of yelling. There was occasional, you know Calm discussion and then there was some arguments where we fought over things because we all are stubborn and we think That we're right every single time So at some point I'm not going to say who I assume it's one of the people on the list that I mentioned earlier on We had like the light bulb go off. We kind of figured out like oh my gosh There is a thing that matters and it kind of came about because we looked at it like there are devices we are Relatively aware of what's in the field. What's the market? You can buy things They they tend to say that they serve a certain purpose And you typically want to use them for something. So maybe that's where we should start and that actually helped us a lot because Once we looked at it from what devices are out there. What are they supposed to be doing? We were able to drill down and figure out underneath the hood. What are they talking about? What is their intent? And the thing is all attacks They target a thing and when I say a thing I mean either an application Or the api that you use to interact with that application There may be multiple apis you may have a web server that tends to listen to user input on one port with Even its own service. You may also have Admin account that does perhaps a different port a different service And you can also do things from the command line and the operating system. So those are all essentially touch points for interacting with an application But in order to interact with an application you actually have to Interact with it in a place that it's expecting So it may not be obvious from this Diagram, but essentially you have an application and the only way to do anything with that application to affect it In any way is to go through one of the doors. They provide an access means So you have to go through there and while that may seem like Duh no, duh everybody knows that it's it's actually like a fundamental thing that made our lives much easier Once we realize you have to go in a certain way in order to do something Everything else kind of just fell into place after that. So there's only so many ways you can interact with a target and so if you Put your controls or think about your controls in terms of where they would go after the target You kind of find that things line up and it will make more sense as we go a little further on So it's all about the target. So we had this we have, you know bad guys You have stuff that's in the news. We have all these things that we have to catalog There's named vulnerabilities and we have to figure out what the controls are So by focusing on that a target rather We were able to eliminate the noise And then we found out that it's not all targets are not all Not all targets are equal some targets listen And some targets require a user to do something or an action to be taken before you can be exploited So things like uh, not petia. They don't really apply so much to servers that are listening because In order to be infected by an application that requires you to download something You have to have a user who's using an application that can download something So essentially you end up with two different classes of attacks attacks that work at Say what you're familiar with the the application layer seven and below So you have things like this and we found that you can organize them that we have interfaces that operate at layers And this may look a little bit familiar and we'll get into why that is later on but It makes it or uh easier when you organize things and so When we organize according to say osi In order to get places You have to have things that do stuff at certain layers that they have to interact with an application at a certain point What does that mean? How does that apply? What does it really matter? So if you translate these things that are in the news and how they're referred to dame vulnerabilities What's happening under the hood is you might have a tcp sin flood Which is a lot of packets that have a certain flag set on tcp An smb attack is uh, what is it soma message? block protocol htb command injection it's it's targeting something that speaks http or you might be targeting something that speaks smb Or a sequel injection you have to have a system That will accept Things in the sequel injection now it may be poorly written code on the web server that allows results to happen Behind on the database and return information But if a web server doesn't provide a way to get there it doesn't provide a way to accept the sequel you won't get the data So what we found is that different attacks target things that operate at different layers and the layers most closely respond Correspond to like the tcp icv model and things like malware and phishing Don't really apply to servers that you have listening. They are essentially Attacks that require an action to be taken You you can't exploit somebody who doesn't do something ahead of in response to what you have said you may set out a lure But you can't catch a fish if you don't bait the hook you can't catch a fish if you aren't out phishing But once you put the lure out if the fish bites your lure then you can catch the fish So that's why phishing and malware are separate in this view So we we're pretty excited. We figured something out. We we found a way to organize attacks And look at them in different ways. So yes, we were pretty excited and then we got back to work and said, okay What else can we do? What else can we use that would help describe different attacks and Classify them in such a way that we could then Find the right control to apply So something we found too is that by organizing the attacks from top to bottom You realize that some attacks occur at lower layers some attacks occur at higher layers and in order to reach these higher layer Vulnerable systems you actually have to have the correct operation of the things underneath You can't send a sequel ejection attack in a malformed tcp packet. It won't reach the target. And so if it doesn't reach the target You don't have to worry about it an attacker can't attack a system that he can't reach So you have to have correct operation of the underlying protocols and Something similar here is the kill chain from Lockheed Martin You may have seen it if you can break the chain at one location you can disrupt the entire attack This applies to specific attacks to not just hacker methodology if you can block an attack at any layer You have succeeded in protecting the asset You don't have to block the specific thing that the attack is trying to do you could block it by a And a tribute that you can find at a different layer So some of the other things that we found is that attacks are either explicit or implicit It's a good way to categorize things and makes it easier to see what is the right control You may have some attacks like command injection or a buffer overflow if you look at the packets on the wire You can see that that's a bad thing. It contains something that I don't want to allow. I'm going to not allow it For implicit attacks they require context. That's things like a tcp flood One tcp packet by itself is not bad If you're only inspecting one packet at a time or one packet stream You may not see that there are hundreds of thousands of other packets all trying to come in On separate streams from other ip addresses if your control is not context aware You'll only see a tcp packet that has a sin flag set and that's normal operation So it's allowed you have to be context aware for some attacks. Those are the implicit ones So the best control when people say what's the best thing to do We found there isn't really a best because one there's different devices. There's different environments people care about different things They have different budgets. They have different Maturity levels not every environment is the same. So you can't say there is one thing. That's the best You can however say that the one control is the most specific If you want to block something and only block that thing you need something that's very specific So the way we differentiate the idea is you have a surgeon who is going to do one specific thing and only affect One specific thing if you're looking at say battlefield triage They may say your hand hurts and they'll ship you to maybe where hands are The surgeon might say there's a problem with this specific nerve and do something about that specific nerve only So there's a difference in specificity. It's not best. It's most specific But at the same time if you have gangrene in your hand A battlefield surgeon can just chop off your hand and the problem goes away You may have unintended consequences like not being able to use your hand ever again But it is also effective in stopping that particular attack So what did we do we put it all together we took defense in depth Which gives you the idea of layered security. It doesn't just apply to networks It also applies to individual hosts in order to get htp data to an htp server You have to have tcp working. You have to go to the right port You have to have properly formatted htp before you can send the sequel in the htp parameter So at the host layer as well as the network you have the idea of defense in depth The reason that's important is because you have different places that you could stop an attack So while we might say the atomic madness is sequel injection I keep referring to this because it's up high, but It's at the top You can block the sequel injection if you can see it and if you know what it looks like But you could block the attack because all of a sudden I don't want to allow htp to this server That's effective as well if you have a server you don't want talking to somebody Don't allow htp You could allow or rather you could not allow tcp at all. Maybe the server is not only for udp You can't attack something that an attacker can't reach You can also attack or block things at Say the delivery vehicle entrance entrance, which is don't allow packages or packets from Attackers that you don't do business with If you are a us company and you don't do any business with china or russia Why would you allow any packets from them? It doesn't matter if you're blocking sequel injection or not If you block all of russia, then russia can't do sequel injection on you Directly from russia. Yes, they could use a proxy and come in another way But the point is you have different options that operate at different layers and you could do things different things differently So the other one is the cyber kill chain. You've got these different layers and in order to get to more interior in theory more valuable Data and having a user take actions on your behalf You have to go through the outer layers. You have to reach them You have to be allowed to perform all the underlying actions in order to reach the internal layer So that also gives you an idea of yes, I can implement controls at different places for different things You may not be able to recognize things that attack a user But if you do and you can cluster things and say identify attributes that they all have in common You can use those attributes to block at a different layer Do they have unintended consequences? Possibly that's up to each environment to decide if those consequences are worth it So what we've got is target based security model We we wanted something that was simple to use that made sense That was easy to understand and essentially be a reference guide And so what we came up with is a table format that makes it a little bit easier to see When and how you might organize different types of attacks So above we have indirect which is somebody has to do something in order to be attacked you have Say laying a trap or baiting a hook you have to Make it available for somebody but they also have to follow through the target has to take an action in order to be attacked Those don't happen At the lower layers generally 99% of the time they happen at the higher layers Direct attacks are where you have a service that's listening somebody can run up and smack you in the face because you have your face sticking out there That's essentially what a direct attack is because you have your servers listening. They are reachable Somebody can directly attack them. They don't require any action on behalf of the target So again, these are layered similar to the tcpip model networking Protocol and then we split up protocol We split out protocol from application server and application client because you often have say proxies that speak a protocol And will deliver data or operate on the data in order to transfer pass it off to the server that then does things with that data So they are slightly different Sometimes you might have a server that can be its own proxy Like you could have a rails web server that listens and operates on htp as well as performing the business logic in a production environment You might separate them You might have nginx in front passing requests that have business logic to the rails web server behind it So they are slightly different and separated for various reasons one being that You might have different controls that operate in different places If you can see direct and indirect most people might make the natural jump or the natural conclusion that on the The lower half you have network based controls that can see things because They are able to see the packets. They don't have to do any transformation This data comes across the wire in this form And so a network based control can see them as you go further up the stack there are more options for transporting the data and packaging the contents of that data and so you might not think or most often A network based control is not going to be the best control Because if you send a file that is zipped over ssl a network based control is not going to see it And if you have a device that claims to provide you protection for a cve in this form They're essentially giving you false information because they can't see through ssl. They can't see through zip And if it's encrypted they definitely can't see it You won't be able to see the bad thing until it goes through and has the the ssl taken off If it's been unzipped and if it's unencrypted only then will you be able to see the bad thing So you want to control that will use the underlying mechanisms that the attack is relying on like your Transport your operating system your client the application that opens the data and knows how to do all these things and then inspect it So that would be the most specific control for say a file because it has a bunch of different ways that can arrive And it doesn't actually do anything until it's read by a certain application operated by a user on a host so grouping them We we have different types of targets some examples of things that you're familiar with that makes a little easier perhaps to see What's being exploited? You might exploit a router or you might exploit everything that speaks tcp that can be your perimeter devices It can be your host devices. They all have to understand tcp in order to know that data is intended for them L4 and l3 can kind of be combined because generally these days all Devices that you buy are ip as well as port aware So they're they're fundamentally split up because you have a difference between ip and tcp But essentially the controls would operate at the same place Protocols are different than applications because there are things that speak a protocol like htp dhcp dns These things all speak a rfc defined protocol. They know the language. They know what to do with it They are different than application servers that tend to rely or first have to translate the language of the protocol in order to operate on the data being sent using The protocol as a means of delivering Application client is obviously different. You have applications that listen and then you have applications that do things on behalf of say the user You might have A dns client that's on a user computer as well as a dns server the dns server Is listening for things the dns client isn't going to do anything unless a user drives it to do something Same thing with a file an office file You can send a bad file. It can sit at an email gateway Nothing's going to happen to with that file Unless somebody opens it with a vulnerable application and they'll have to open it on a system that has the vulnerable application Installed and it has to have the ability to read it policy Is essentially the Intent of the system you have lots of different pieces that work together And how they're supposed to operate and the things they are supposed to do Is say defined by a document how it's actually implemented is your configuration So when you're attacking something or exploiting a policy something an example might be sending clear text hdp data Inherently there's nothing wrong with it unless that data is valuable unless you don't want other people to see it So if your policy is don't allow other people to see data over hdp And you are sending clear text hdp data. You're violating a policy Now in order for that policy to be violated again, you have to have hdp working you have to have h ip and tcp working all those underlying protocols And layers have to be operating correctly in order for that policy to be violated And then lastly we have users because there's different things you you train your users You tell them to do things their intent is to be productive They want to do that they are trained not to give away secrets They're trained to not Allow other people to do things they're trained not to take action on behalf of outsiders So when somebody sends a phishing email again, correct operation all the way to the user they have to receive it But what is it? It's it's a Email that contains say an html page It might have an href in it a user would have to click that link It goes to an ip address again if you're looking at this stuff on the wire There's nothing wrong with it unless you know that that ip address is known to host content that is bad Or if you know that that website Is not owned by the company whose content is being sent It's not an easy thing to differentiate, but if you have google.com and Google.com they may have the same content They'll be served by two different ip addresses unless you can associate the content With the ip address the inspection device cannot know What the difference is when one is bad and one is not And that's essentially what phishing is when they ask they the user will download a web page Containing what looks to be a login form for a site that they think they trust and they enter credentials The only way to know that is with context So if you have a control that you want to apply to that that Control has to be context aware and it also has to see it in the same way that the user does So what's next so here's some examples of classifying things we've got A network based attack, which is a ddOS. That's that's what people will call it and it's essentially a volumetric flood of packets with the sin flag set for a tcp It's it's at the network layer if you have controls That read network layer Things and are network layer network aware they will be able to do something about this They might be able to examine it and say oh, I should block this But if you have controls that operate at a higher layer, they are not going to see this attack Now unfortunately, I have my arrows not quite working but what we have is Wanna cry which is what everybody heard which is the delivery of a payload using the eternal blue exploit Which is an smb buffer overflow You have to have ip and tcp working in order to get to the smb service that you want to target So it has to reach there And then you overflow the smb service in order to achieve remote code execution So you have two options for blocking that you can block something that reads smb Or if you know who sent it or if you only want to allow smb from certain people that you trust Then you can also block it at the network layer. It gives you that option And the same thing here, we've got Apache deserialization Experian got owned because they allowed an Apache server to listen and you could serialize HTTP parameter input that would fail and the exception handling is when it achieved remote code execution What the point being here is it operates at a higher layer You have to have a target that speaks HTTP. You have to have a target that will listen At the network layer. It also means you can have controls that operate at layer three and at the protocol level You have several opportunities to block this not necessarily with The thing the specific thing maybe not the most specific, but you still have the option You can block it at a lower layer and now we have A policy attack so No, sorry, this is out of order site, but essentially there's a client application You have to have a user who uses the application and it has to open a file that's bad In order to get that file everything underneath it has to be operating correctly Which means you can use some attributes and characteristics to block it before it reaches the user So this is a policy and this is where we put malware because malware itself is Typically a binary executable. It doesn't really do anything wrong unless you think The data that's being sent to that server in russia is valuable and you don't want them to have it So if you're an inspection device looking at the network and you see this binary going over the wire Unless somebody has flagged that binary as being bad and doing things that are bad You can't really know on the network that that is a problem They the malware it operates once it's in it's this again This is separate from the exploit used to get onto the system. It uses correct os commands to execute its target It will use windows to send data over tcp to russia There's nothing inherently wrong with it And so same thing with phishing you've got the violation of the intent of the user The user doesn't want to give things away and you're essentially tricking the user into doing it But again, everything has to be working correctly underneath the hood So here are some places things you might be familiar with these are essentially technologies That are applied at different layers. You can filter by ip you could Filter by volume of types of trafics You can segment your your network using different devices You can have data inspection devices You could have a web application firewall that inspects HTTP traffic if it knows what to look for it can block it same with an IPS application server you might also think of that as a application server Layer control a WAF may be more specific in what it what it can block and why? antivirus on a network if it's been identified sure you can block things on the network It's a lot more efficient. You save resources and utilization, but unless The antivirus can see the commands that are being executed It's going to have a hard time finding something that hasn't previously been identified as malicious as a whole So it has to be able to see the specific actions And that's why we also have it as has have it as a policy Because antivirus can use signature base matching To identify an executable as being bad however it arrives Or it can use heuristics and look at the actions being taken say in a sequence and say This is an application that's misbehaving And so for users you can try to educate them and you can try to train them But those are the controls you would apply to that user and they are the most specific Because they operate at the same layer as the attack Which is targeting The thing that operates at that layer So yes, that is it. We didn't really do much of anything other than Come up with a system that made things easier for us to classify attacks And it just so happened to line up very nicely with security controls So for our purpose we were able to say for this kind of attack The most specific control is something that operates here and because we know that it's a layered system We can also provide alternatives This I think is useful outside of my specific industry and my company It might be useful to others as well And I'd like to think that a table is pretty simple and provides a visual that's easier to use So what we think within our industry, which is the test industry Security device testing industry we now have a way of classifying what we are sending and what test Test companies are sending to Compare devices if we can say this is a particular kind of attack they can compare devices And provide results based on their effectiveness against specific kinds of attacks Why is that useful? Well in waiting if we have 50,000 attacks and you don't know that 90 percent of our attacks are a certain kind The results of comparing two devices with all of those attacks is going to be weighted towards Devices that are good at blocking one specific 90 percent of our attacks So you want to be able to control what you are Testing these devices with in order to see What are the most relevant devices and what are the most relevant things that we care about? So you can choose your device based on how well it performs in a role that you want it to be in there If you want something that will protect you from Web-based attacks you want to know the different The results of comparing two devices that can block hdbs traffic or hdb traffic rather You might have a WAF versus an IPS. You can actually now control Which devices? Which technologies and controls are implementing regardless of the Classification of the device you can compare an IPS to a WAF If you know what you're sending in and then you can look at those results and say what's more effective For my intended and purposes you might not need a second device if you don't have budget You might find that an IPS blocks just as much stuff as a WAF does you don't necessarily need a WAF And then in theory if you have the idea of layered security controls it gives you the option to think about Your environment and what you can do within the constraints of your budget and what you can do now In real time if you have a network setup if you have some devices already you might want to plan for getting other devices in the future But here's are some options that you might be able to do In a again a visual layered simplistic way today So outside of info sec what we're thinking is perhaps It might be useful to teach the concept of layered attacks Everyone in this room likely already is very familiar with this If you saw an attack in the news you could say I know exactly what to do But when you're learning this stuff it's hard and if you're just reading the news all the time If you've got bosses who just read about things that we should be scared of It makes it easier to say Here's how they're broken down and here's the right way or the most specific way to block it and so While we hope that it's used outside of our industry We understand if it's test specific and We are making changes to our products based on this taxonomy and classification system And we think it might be useful outside of that So in the future we hope to standardize and get everyone to agree to use the terms because that's that's the first step If you have everybody speaking the same language you can Be more confident in having a discussion about those concepts Um, there there should be a very easy way to Come up with an official list of controls or technologies that map to layers Because then you can say these are applicable and most appropriate for these kind of attacks Again internally and externally if we get internal and we get things published then we provide public data for others to use um, and then one of the things that So Because we found it effective to categorize the different attacks We're thinking now that it might also be just as effective to categorize the different forms that attack takes attacks take When you think of attacks that are buffer overflows buffer overflows are generally a long string of characters That is a form of attack Um, and it looks generally the same on the wire And if you have different devices you might want to know how well your different devices protect you against Long string long data strings sent in data packets or buffer overflows. You might want some specifics whereas, um Something that targets exception handling you might have just a single digit. That's a bad character But without context. It's just a single hex digit that shows up in a packet on the wire. You won't know So we think that there's utility again and categorizing the different forms that attacks take in order to reach their targets at the end And that is all that I have for today Again, I work at Keysight. I think we have some publicly available material if you want to look it up I believe there's a recent blog post I don't have a link for it But if you're really dedicated you could probably find it And I think we have two or three minutes for questions if anybody has any If not, I understand it's a lot to take in But hopefully you guys took notes and I believe the recordings will be up later So if you want to look at it again, you might find it useful. So That's all I got. Thank you very much. Appreciate it