PACKET HACKING VILLAGE - Target-Based Security Model
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 322 | |
Author | ||
License | 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. | |
Identifiers | 10.5446/39921 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
DEF CON 2661 / 322
18
27
28
40
130
134
164
173
177
178
184
190
192
202
203
218
219
224
231
233
234
235
237
249
252
255
268
274
287
289
290
295
297
298
299
302
306
309
312
315
316
00:00
Mathematical modelInformation securityOnline helpInformation securityMathematical modelCASE <Informatik>Descriptive statisticsWeb page
00:36
Multiplication signSimulationLevel (video gaming)Repository (publishing)EmulatorLibrary catalogPoint (geometry)SoftwareExploit (computer security)Computer animation
01:12
Control engineeringVulnerability (computing)Flow separationMalwareDisk read-and-write headAtomic numberComputer wormDifferent (Kate Ryan album)Denial-of-service attackSoftwareInjektivitätLevel (video gaming)Buffer overflowPhysical systemFunctional (mathematics)Buffer solutionComputer animation
02:34
Block (periodic table)Library catalogHand fanInformation securitySoftware testingDifferent (Kate Ryan album)Control engineeringMultiplicationBoss CorporationSoftwareOrder (biology)Computer animation
04:04
Mathematical modelPoint (geometry)Firewall (computing)CASE <Informatik>Context awarenessDirect numerical simulationRouter (computing)Different (Kate Ryan album)InternetworkingWeb browserContent (media)Dependent and independent variablesMedical imagingServer (computing)Local ringMathematical modelNeuroinformatikString (computer science)WindowLatent heatIP addressMultiplication signSoftwarePhysical systemScaling (geometry)Electronic mailing listInformationType theoryOrder (biology)WebsiteService (economics)MalwareCombinational logicPerspective (visual)TheoryLine (geometry)Control engineeringPoint cloudGroup actionComputer programmingConnectivity (graph theory)Military baseVector potential
08:04
Block (periodic table)Physical systemLibrary catalogRight angleProduct (business)Computer animation
08:39
Execution unitVisual systemHacker (term)LogicSoftware frameworkOnline helpVulnerability (computing)Matching (graph theory)Different (Kate Ryan album)Category of beingType theoryStandard deviation1 (number)Context awarenessVideo gameInformation securityImplementationComputer programming
09:28
Control engineeringElectronic mailing listDifferent (Kate Ryan album)
10:06
Numerical taxonomyGUI widgetBlock (periodic table)Point (geometry)Table (information)Electronic mailing listProcess (computing)Multiplication signParameter (computer programming)Mathematical modelComputer animation
11:06
Field (computer science)Cartesian coordinate systemTouch typingDiagramControl engineeringPoint (geometry)Service (economics)Order (biology)Web 2.0Server (computing)outputTerm (mathematics)Operating systemLine (geometry)System administratorArithmetic meanExpected valueComputer animation
13:03
Library catalogVulnerability (computing)Control engineeringNoise (electronics)Group actionCartesian coordinate systemSocial classInterface (computing)Order (biology)Server (computing)Different (Kate Ryan album)Point (geometry)Computer animation
14:28
DatabaseMalwareSequelInjektivitätInformationVulnerability (computing)Dependent and independent variablesBlock (periodic table)HookingDenial-of-service attackServer (computing)Mathematical modelCodeWeb 2.0Communications protocolGroup actionFlagResultantDifferent (Kate Ryan album)Physical systemMessage passingView (database)
16:02
Physical systemMilitary operationOperator (mathematics)Physical systemChainInjektivitätHacker (term)Order (biology)Communications protocolAttribute grammarSequelUniform resource locatorVulnerability (computing)Computer animation
17:27
FlagBuffer overflowNormal (geometry)Context awarenessDenial-of-service attackMultiplication sign1 (number)InjektivitätIP addressFlow separationStreaming mediaNormal operator
18:22
Drill commandsDifferent (Kate Ryan album)Capability Maturity ModelIntegrated development environmentField (computer science)Latent heatMultiplication signLevel (video gaming)Software bugBlock (periodic table)Computer animation
19:33
MIDIOrder (biology)Information securityParameter (computer programming)SoftwareSequelServer (computing)ImplementationControl engineeringInjektivitätTheoryDifferent (Kate Ryan album)Group actionAttribute grammarIntegrated development environmentIdentifiabilityPoint (geometry)CybersexChain
22:08
Information securityMathematical modelDynamic Host Configuration ProtocolCommunications protocolServer (computing)Direct numerical simulationClient (computing)Duality (mathematics)Sanitary sewerType theoryJava appletFrame problemInformation securityMathematical modelElectronic program guideComputer fileDirect numerical simulationVulnerability (computing)Cartesian coordinate systemClient (computing)Table (information)File formatPhysical systemControl engineeringOperator (mathematics)Office suiteDifferent (Kate Ryan album)EmailCommunications protocolGateway (telecommunications)Server (computing)Context awarenessTransformation (genetics)Content (media)InformationMechanism designOrder (biology)NeuroinformatikProduct (business)LogicWeb 2.0Hydraulic jumpForm (programming)Type theoryFormal languageWeb pageLoginWebsiteProxy serverRouter (computing)PerimeterHeegaard splittingIP addressDirection (geometry)Group actionMultiplication signService (economics)BitSelf-organizationConfiguration spaceHookingSoftwareArithmetic meanPhishingTorusLink (knot theory)HyperlinkIntegrated development environmentOperating systemComputer animation
30:37
FluidSoftwareVolumeControl engineeringDenial-of-service attackFlagSet (mathematics)Computer animation
31:13
Buffer overflowRemote procedure callService (economics)CodeSoftwareOrder (biology)Arrow of timeComputer worm
31:56
CodeServer (computing)Point (geometry)Communications protocolLevel (video gaming)Parameter (computer programming)Control engineeringoutputException handlingRemote procedure callLatent heatSerial portSoftware
32:45
Computer fileCartesian coordinate systemCharacteristic polynomialClient (computing)WebsiteAttribute grammarOrder (biology)Slide ruleWindowSoftwareServer (computing)MalwarePhysical system
34:04
GUI widgetComputer networkClient (computing)PhishingGroup actionSoftwareFirewall (computing)Multiplication signAntivirus softwareServer (computing)Utility softwareLatent heatCartesian coordinate systemElectronic signatureVolume (thermodynamics)Type theoryControl engineeringWeb application
36:01
Table (information)Physical systemControl engineeringLine (geometry)Information securityExterior algebraComputer animation
36:43
Personal digital assistantOpticsConvex hullInfinite conjugacy class propertyDuality (mathematics)Inclusion mapForm (programming)MathematicsPairwise comparisonProduct (business)Internet service providerIP addressForm (programming)String (computer science)ResultantTerm (mathematics)Order (biology)Exception handlingLatent heatInformation securitySoftware testingMultiplication signDigitizingBoss CorporationUtility softwareElectronic mailing listVisualization (computer graphics)Numerical taxonomyIntegrated development environmentBuffer overflowSingle-precision floating-point formatConstraint (mathematics)HexagonBlock (periodic table)Formal languageSoftwareControl engineeringReal-time operating systemTheoryContext awarenessSound effectInformation privacyBuffer solutionLevel (video gaming)Computer animation
41:36
Forschungszentrum RossendorfLink (knot theory)Row (database)BlogComputer animation
Transcript: English(auto-generated)
00:00
And with that now, with that said, it is my pleasure to introduce a friend of ours from the Packet Pack, you've spoken here before. I have. Yep, and you've spoken here before, Garrett Montgomery on target based security model. Woo! Alright, so, uh, my name's Garrett Montgomery, I'm here to talk about the target based security model, and in
00:21
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
00:41
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
01:04
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 refresher, 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
01:22
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, I 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
01:45
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
02:03
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
02:22
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
02:44
challenge to provide suggestions. How would we block these things that we are sending? And with our large catalog, that was a challenge. Um, 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
03:04
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
03:24
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
03:41
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
04:01
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
04:21
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
04:40
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's going to go, hopefully, to internal DNS and say,
05:03
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
05:25
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
05:42
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
06:00
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
06:23
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,
06:40
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
07:02
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. You could say, 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
07:23
this 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
07:43
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
08:01
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
08:22
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
08:40
not anything out there. You've got different standards and frameworks and they're very broad, say, for infosec programs. There's a hole 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
09:03
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
09:24
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
09:41
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
10:02
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
10:24
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
10:41
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
11:01
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
11:23
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
11:42
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
12:02
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
12:21
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
12:41
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
13:02
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
13:22
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 NotPetya, they don't really apply so much to servers that are listening
13:40
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 7 and below. So you have things like this and we found that
14:01
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
14:20
to get places you have to have things that do stuff at certain layers. 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, named vulnerabilities, what's happening under the hood is you might have a TCP SYN flood, which is a lot of
14:41
packets that have a certain flag set on TCP. An SMB attack is, what is it, some 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
15:02
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
15:24
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
15:40
taken. You can't exploit somebody who doesn't do something ahead of, in response to what you have sent. 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 fishing. 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
16:01
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
16:20
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
16:42
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
17:02
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 an 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
17:24
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
17:41
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
18:00
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, and that's normal operation, so it's allowed. You have to be context aware for some attacks. Those are the
18:20
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, um, 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
18:42
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
19:01
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
19:20
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
19:42
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
20:02
important is because you have different places that you could stop an 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
20:21
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 now only for UDP. You can't attack something that an attacker can't
20:40
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 US company and you don't do any business with China or Russia, why would you allow any packets from
21:01
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 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 differently. So the other one is the cyber kill chain. You've got
21:21
these different layers, and in order to get to more interior, in 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
21:40
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.
22:02
Do they have unintended consequences? Possibly. It'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
22:20
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
22:41
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
23:00
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
23:21
the TCP IP 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 pass it off to the server
23:40
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
24:02
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
24:21
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
24:42
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.
25:01
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's encrypted they definitely can't see it. You won't be able to see the bad thing until it goes through and has
25:21
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 a 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
25:41
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 have
26:01
different types of targets, some examples of things that you're familiar with that makes it 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.
26:22
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 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
26:41
than applications because they 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
27:00
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
27:20
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
27:42
going to happen 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
28:01
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're 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,
28:20
an example might be sending clear text HTTP 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 HTTP and you are sending clear text HTTP data, you're violating a policy. Now
28:40
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's different things. You train your users, you tell them to do
29:01
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
29:21
is it? It's an email that contains say an HTML page that 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.
29:40
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
30:00
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 the user will download a web page containing what looks to be a login form for a site that they think
30:20
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
30:43
a network based attack which is a DDoS. That's what people will call it and it's essentially a volumetric flood of packets with the SYN flag set for a TCP. It's at the network layer. If you have controls that read network layer
31:01
things and are 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
31:20
WannaCry 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
31:40
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.
32:01
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. Well the point being here is it operates at a higher layer. You have to have a target that
32:21
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 3 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
32:41
layer. And now we have a policy attack. So no, sorry, this is out of order slide but essentially this is a client application. You have to have a user who uses the application and it has to open a file that's bad.
33:01
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
33:22
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
33:42
that that is a problem. The malware it operates, once it's in, 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
34:01
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
34:20
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 traffics. You can segment your network using different devices. You can have data inspection devices.
34:40
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 an application server layer control. A WAF may be more specific in what it can block and why.
35:02
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
35:21
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, say, in a sequence and say this is an application that's misbehaving.
35:42
And so for users, you can try to educate them. 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.
36:02
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
36:20
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
36:40
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,
37:01
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
37:21
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
37:41
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 HTTP traffic, rather. You might have a WAF versus an IPS.
38:01
You can actually now control which devices which technologies and controls they are implementing regardless of the classification of the device. You can compare an IPS to a WAF if you know what you are sending in and then you can look at those results and say what's more effective
38:21
for my intended 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
38:41
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 set up, 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
39:01
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
39:20
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
39:41
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.
40:01
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
40:22
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
40:42
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
41:01
different devices you might want to know how well your different devices protect you against long data strings 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
41:21
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. that is all that I have for today.
41:41
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.
42:02
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. That's all I got. Thank you very much. Appreciate it.