PACKET HACKING VILLAGE - Target-Based Security Model
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Montgomery, Garett
Have you ever been asked 'what is the best way to protect against $ATTACK'? (usually shortly after $ATTACK makes headlines). Have you ever been challenged to provide the reasoning behind your suggestion? If you were in a room full of experts, would your reasoning hold up under scrutiny? When you discuss with your security-savvy peers, you're quickly come to a consensus on the 'best' control (!= device) to protect against $ATTACK. But do you know WHY it's the 'best'? The Target-Based Security Model is essentially a framework that breaks down attacks to their component level. This breakdown makes it easy to see what the 'best' security controls are - as well as alternative security controls that could also be applied. Its not so much something new, as it is a new way for the industry to communicate about security. In much the same way that the OSI model allows for developers to know they are talking about the same thing, a common security model allows security professionsals to communicate in a vendor-agnostic manner. Think of it as a translation tool for vendor-speak. In this talk we'll present the Target-Based Security model and discuss the following: how it came to be, what it is, and how to use it. And of course, we'll talk about how it can be used to make the world a better place - provided we all agree to use it.
 And with that now, with that said, it is my pleasure to introduce our friend of eyes 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. Woo! All right. So, uh, my name is Garret 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 worked 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. Just real quick. Um, hopefully everyone in here is familiar with the difference between a 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 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 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 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 into 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 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 FQDNs 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 at your IPS because I can block it here because I recognize this is bad stuff. Or an IPS might be context aware and say, oh, I know that these IP addresses aren't allowed. Or I know that the specific content from this IP address is a bad combination and 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, it 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 4,000 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 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. 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 and find some textbooks that 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 selling it to you doesn't understand what you're trying to say. So this is essentially what's out there. And again, what about attacks? Maybe if we look at it from the point of an attack, what kind of attack should be blocked by what kind of control or device? 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 tried discussing things. 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 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 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 an 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 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, 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 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 you 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, name 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, what is it? Samba message block protocol. HTTP command injection, it's targeting something that speaks HTTP or you might be targeting something that speaks SMB or SQL injection. You have to have a system that will accept things in the SQL 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 SQL, 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 correspond to like the TCP ICP 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 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're pretty excited. We figured something out. 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 and 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 SQL injection 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 too, not just hacker methodology. If you can block and attack at any layer, you have succeeded in protecting the asset. You don't have to block the specific thing that the attacker's trying to do. You could block it by 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 SYN flag set. 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. You can't say there's 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 HTTP data to an HTTP server, you have to have TCP working. You have to go to the right port. You have to have properly formatted HTTP before you can send the SQL in the HTTP 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 and attack. So while we might say the atomic badness is SQL injection, I keep referring to this because it's up high, but it's at the top. You can block the SQL 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 HTTP to this server. That's effective as well. If you have a server you don't want talking to somebody, don't allow HTTP. 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, which is don't allow packages or packets from attackers that you don't do business with. If you are a U.S. 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 SQL injection or not. If you block all of Russia, then Russia can't do SQL injection on you. They could use a proxy and come in another way. The point is you have different options that operate in different layers and you could do things differently. 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 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 server's 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 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 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 HTTP 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 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 are essentially giving you false information because they can't see through SSL, they can't see through zip and if it is encrypted, they definitely can't see it. You won't be able to see the bad thing until it goes through and has the SSL taken off. If it has been unzipped and if it is 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 is read by a certain application operated by a user on a host. So grouping them, we have different types of target. Some examples of things that you are familiar with that makes it easier to see what is 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 are 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 HTTP, 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 is going to happen to with that file unless somebody opens it with a vulnerable application. They will 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 are supposed to operate and the things they are supposed to do is say defined by a document. How it is actually implemented is your configuration. When you are attacking something or exploiting a policy, an example might be sending clear text HTTP data. There is nothing wrong with it unless that data is valuable, unless you don't want other people to see it. If your policy is don't allow other people to see data over HTTP and you are sending clear text HTTP data, you are violating a policy. In order for that policy to be violated, again, you have to have HTTP working, you have to have 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 is different things. 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 are trained to not allow other people to do things, they are 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 is 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 are looking at this stuff on the wire, there is 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 is not an easy thing to differentiate, but if you have Google.com and Google.com, they may have the same content. They will 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 is essentially what phishing is when they ask, 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 have got a network based attack, which is a DDoS. That is what people will call it. It is essentially a volumetric flood of packets with the send flag set for a TCP. It is at the network layer. If you have controls that read network layer things and 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 want to cry, which is what everybody heard, which is the delivery of a payload using the internal 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 have got Apache serialization. Experian got owned because they allowed an Apache server to listen and you could serialize an 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. 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 traffic. You can segment 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 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 a policy. Because antivirus can use signature-based matching to identify an executable as being bad, however it arrives. Or it can use heuristics and look at the actions being taken 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 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% 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% 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 HTTPS traffic or HTTPS traffic, rather. You might have a WAF versus an IPS, you can actually now control which devices, which technologies and controls they're 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 Infosec, 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 the first step. If you have everybody speaking the same language, you can be more confident in having a discussion about those concepts. 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. And then one of the things that, 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 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 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 data strings sent in data packets or buffer overflows. You might want some specifics. Whereas 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 in 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. Thank you.
 And with that now, with that said, it is my pleasure to introduce our friend of  eyes 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. Woo! All right. So, uh, my name is  Garret 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 worked 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. Just real quick. Um, hopefully everyone  in here is familiar with the difference between a 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 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 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 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 into 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 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 FQDNs 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 at your IPS because I can block it here because I recognize this is bad stuff.  Or an IPS might be context aware and say, oh, I know that these IP addresses aren't allowed.  Or I know that the specific content from this IP address is a bad combination and 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,  it 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 4,000 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 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. 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 and find some textbooks that 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 selling it to you  doesn't understand what you're trying to say. So this is essentially what's out there. And again,  what about attacks? Maybe if we look at it from the point of an attack, what kind of attack should  be blocked by what kind of control or device? 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 tried discussing things. 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 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 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  an 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 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, 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 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 you 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, name 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, what is it? Samba message block protocol.  HTTP command injection, it's targeting something that speaks HTTP or you might be  targeting something that speaks SMB or SQL injection. You have to have a system that will  accept things in the SQL 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 SQL, 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 correspond to like the TCP ICP 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 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're pretty excited. We figured something out. 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 and 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 SQL injection 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 too, not just hacker methodology. If you can block and attack at any layer, you have  succeeded in protecting the asset. You don't have to block the specific thing that the attacker's  trying to do. You could block it by 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 SYN flag set. 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. You can't say there's 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 HTTP data to an HTTP server, you have to have  TCP working. You have to go to the right port. You have to have properly formatted HTTP before you  can send the SQL in the HTTP 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 and attack. So while we might say the atomic badness is SQL injection, I keep referring  to this because it's up high, but it's at the top. You can block the SQL 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 HTTP to this server. That's effective as well. If you have a server you don't want  talking to somebody, don't allow HTTP. 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, which is don't allow  packages or packets from attackers that you don't do business with. If you are a U.S. 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 SQL injection or not. If you block all of Russia, then Russia can't  do SQL injection on you. They could use a proxy and come in another way. The point is you have  different options that operate in different layers and you could do things differently.  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  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 server's 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 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 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 HTTP 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 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 are essentially giving you false information because they can't see through SSL,  they can't see through zip and if it is encrypted, they definitely can't see it. You won't be able  to see the bad thing until it goes through and has the SSL taken off. If it has been unzipped and  if it is 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 is read by  a certain application operated by a user on a host. So grouping them, we have different types of  target. Some examples of things that you are familiar with that makes it easier to see what is  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 are 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 HTTP, 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 is going to happen to with that file unless somebody opens it with a  vulnerable application. They will 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 are supposed to operate and  the things they are supposed to do is say defined by a document. How it is actually implemented is  your configuration. When you are attacking something or exploiting a policy, an example might be  sending clear text HTTP data. There is nothing wrong with it unless that data is valuable,  unless you don't want other people to see it. If your policy is don't allow other people to see  data over HTTP and you are sending clear text HTTP data, you are violating a policy. In order for  that policy to be violated, again, you have to have HTTP working, you have to have 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 is different things. 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 are trained to not allow other people to do things,  they are 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 is 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 are looking at this stuff on the wire, there is  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 is not an easy thing to differentiate, but if you have Google.com and Google.com,  they may have the same content. They will 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 is essentially what phishing is when they ask,  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 have got a network based attack, which is a DDoS. That is what people  will call it. It is essentially a volumetric flood of packets with the send flag set for a TCP.  It is at the network layer. If you have controls that read network layer things and 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  want to cry, which is what everybody heard, which is the delivery of a payload using the  internal 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 have got Apache  serialization. Experian got owned because they allowed an Apache server to listen and you could  serialize an 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. 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 traffic. You can  segment 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 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 a policy. Because antivirus can use signature-based  matching to identify an executable as being bad, however it arrives. Or it can use heuristics and  look at the actions being taken 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 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% 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% 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 HTTPS traffic or  HTTPS traffic, rather. You might have a WAF versus an IPS, you can actually now control which  devices, which technologies and controls they're 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 Infosec, 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 the first step. If you have everybody speaking the same  language, you can be more confident in having a discussion about those concepts. 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. And then one of the things that, 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 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  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 data strings sent in data packets  or buffer overflows. You might want some specifics. Whereas 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 in 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.  Thank you.
DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_0_911.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_912_1811.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_1812_3851.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_3852_4619.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_4620_6095.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_6096_12107.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_12108_12251.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_12252_12983.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_12984_15167.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_15168_15839.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_15840_16631.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16632_16691.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16692_16751.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16752_16799.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16800_16847.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16848_16895.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16896_16943.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_16944_17003.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_17004_17051.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_17052_17099.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_17100_17159.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_17160_19583.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_19584_19907.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_19908_19955.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_19956_20363.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_20364_24047.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_24048_24251.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_24252_24335.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_24336_24419.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_24420_24575.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_24576_26183.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_26184_27551.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_27552_29279.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_29280_29327.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_29328_33215.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_33216_33455.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_33456_47915.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_47916_51455.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_51456_54035.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54036_54119.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54120_54167.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54168_54215.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54216_54287.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54288_54419.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54420_54515.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54516_54599.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54600_54647.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54648_54695.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54696_54791.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54792_54875.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54876_54923.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54924_54971.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_54972_55043.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_55044_62411.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Garett_Montgomery_-_Target_Based_Security_Model_nRNMH2AB-rM_62412_63417.png