[01:00.880 --> 01:06.040] Good afternoon, everyone. My name is Michael Kafka. Everybody calls me Shecky. If you want [01:06.040 --> 01:13.380] to find out why I got the name Shecky, see me after the talk. It's a long story. Wait, [01:13.380 --> 01:21.380] there can be only one. Interesting title, huh? Expect a lot of Highlander references? [01:22.100 --> 01:28.540] Maybe a couple. What we've got is... let me give you a little bit about myself here. Hold [01:28.540 --> 01:43.900] on. You test beforehand, and it doesn't go, and now it does. Come on. We'll start off [01:44.100 --> 01:55.180] a little bit about me. I've been in the field of professional for seven years. I've been [01:55.180 --> 02:04.120] in IT for over 25 years. That doesn't include a period of time where I was just learning. [02:04.120 --> 02:10.100] I started programming computers back in the early 80s. So I've been around computers for [02:10.320 --> 02:17.880] a very long time. I'm one of the organizers of one of the Birdsects. If those of you who [02:17.880 --> 02:21.800] are down in the Chicago area, you might have heard of us. We're a weekly, basically, meetup [02:21.800 --> 02:30.360] group. We have chapters, meetups, all throughout the Chicagoland area every Thursday. Each [02:30.360 --> 02:34.960] area gets one Thursday per month. I happen to be one of the organizers of the North version [02:34.960 --> 02:41.420] of it. We average about 15, 10, 15 people. So if you are in the area on the second Thursday [02:41.420 --> 02:46.380] of the month, feel free to come out to mine. Or any Thursday, feel free to look up Birdsect [02:46.380 --> 02:54.220] and meet up, and you can find out where we're meeting that week. I volunteer for Hack4Kids. [02:54.220 --> 02:58.980] I have for a number of years. I'll be volunteering tomorrow morning for the Hack4Kids. I enjoy [02:58.980 --> 03:06.120] seeing the children going ahead and getting introduced to all the concepts, learning, [03:06.120 --> 03:13.560] destroying stuff in the destruction village. There's my website, if you're interested. [03:13.560 --> 03:19.140] I blog, but I blog infrequently. Why infrequently? Well, because like the rest of you, I've got [03:19.140 --> 03:24.560] other things on my mind half the time. And finally, you can find me on Twitter. I do [03:24.700 --> 03:32.280] a lot of tweeting. I try to keep it more professional, I would say. I try not to tweet [03:32.280 --> 03:35.660] as much about, say, politics and stuff like that, as some people out there are trying [03:35.660 --> 03:41.760] to keep it more infosec or personal-orientated, comparatively speaking. [03:43.060 --> 03:50.460] So why can't there be only one? What is the whole deal? Well, the one thing is related [03:50.460 --> 03:57.920] to defense in depth. What is defense in depth? The idea of using multiple layers to make [03:57.920 --> 04:05.420] things more secure. It's a very simple definition, and we'll go a little bit more into it as [04:05.420 --> 04:14.220] we move forward with the presentation today. And how are we examining it? We will be examining [04:14.220 --> 04:21.240] it through an actual real-world situation that I was involved in last year. The data [04:21.240 --> 04:26.620] that I found, the reasoning behind defense in depth and how defense in depth actually [04:26.620 --> 04:34.680] relates on downward, beyond what your general thoughts are on it, is actually rather interesting [04:34.680 --> 04:44.200] because it goes through a lot more than you might realize. We will be talking about a [04:44.200 --> 04:48.840] There will be a couple screenshots. All the data has been sanitized, so nothing really [04:48.840 --> 04:57.380] to worry about. You're looking at defense in depth. This is your typical look at it. [04:57.380 --> 05:02.420] You've got your data layer, you've got your application, your host, your internal network, [05:02.420 --> 05:07.540] your perimeter, your physical, and your policies, procedures, and awareness. It's your basic [05:07.540 --> 05:14.020] idea behind it. It's the castle theory. You get your moat, you get your castle walls, [05:14.020 --> 05:19.140] you have your people right behind that, you have your people in front of it. You get through [05:19.140 --> 05:24.880] one layer, the next layer is hopefully going to stop whatever is going on. But defense [05:24.880 --> 05:33.820] in depth goes beyond just these basic layers. And what this diagram doesn't do, it doesn't [05:33.820 --> 05:41.700] go into the depth of the depth. In any of these layers here, you can actually re-layer [05:41.700 --> 05:53.360] things. Maybe we might not have an area of host or internal network. You've seen flat [05:53.360 --> 06:02.580] networks before. Perhaps our policies and procedures are lacking a bit. Maybe it's because [06:02.580 --> 06:08.780] of budgeting, maybe it's because of lack of resources physically and people. But everything [06:08.780 --> 06:13.740] goes through there, and it just layers up. And in each one of these layers, you can have [06:13.740 --> 06:20.760] layers, like onions. Onions have layers. Yeah, I know people prefer parfaits, but onions [06:20.760 --> 06:28.040] do have layers. I know not everyone likes ogres or onions, and you might prefer cakes [06:28.040 --> 06:35.700] or parfaits, but we understand the idea of the layers, but it's not as easy, and it still [06:35.700 --> 06:44.520] isn't, because you can have sub-layers, or layers within layers. The reality is, with [06:44.520 --> 06:50.680] sub-layering, it's usually done at a vendor slash product level, as opposed to a different [06:50.680 --> 06:57.620] type of technology, per se. How many different technologies, on average, do you think your [06:57.620 --> 07:06.180] company uses? Three, four vendors? Five? More? How many of those different technologies, [07:06.180 --> 07:12.440] or layers, wind up going ahead and crossing over with other ones? Do you have an EDR that [07:12.440 --> 07:20.140] does web-blocking? Do you have a firewall that's doing IPS on top of it all? Where you [07:20.140 --> 07:24.540] have another thing going ahead and doing IPS, and then you've got a separate web-blocking [07:24.540 --> 07:34.260] situation. So you get this whole strata of different areas. We used to hate the idea [07:34.260 --> 07:39.780] of using multiple vendors in these layers, as it is. We all remember back in the day [07:39.780 --> 07:46.280] with Norton versus McAfee, versus Avast or any of the free AVs out there. How many AVs [07:46.280 --> 07:51.580] can you have on a machine at once? How many times did those interfere? Did anybody run [07:51.580 --> 07:59.340] into that, where they interfered with each other? Plenty of times. Nowadays, it's not [07:59.340 --> 08:04.920] as prevalent. You have multiple vendors sitting out there, and they're not really interfering [08:04.920 --> 08:11.120] with each other. Or if they are, they're interfering in a way that we don't just quite get, and [08:11.120 --> 08:21.340] it drives us crazy. Yeah, it still happens though sometimes, where they interfere with [08:21.340 --> 08:29.280] each other. But we'll talk a little bit about that later on. So the scenario that I've got [08:29.280 --> 08:37.620] for you is very simple. It's a website. How many people have web-blocking technology out [08:37.620 --> 08:46.880] there? Use Cisco Umbrella or whatever, or Bluecode or Zscaler to go ahead and help prevent [08:47.620 --> 08:52.380] people getting from sites to sites that they aren't supposed to be getting to, including [08:52.380 --> 08:59.440] malicious sites. How many people out there have an EDR? Feel free to raise your hand. [08:59.440 --> 09:10.340] Alright, so one person has an EDR and nobody's using web-blocking? Well, if you know anything [09:10.340 --> 09:16.360] about it when you're dealing with a website, it came from the net, and eventually it was [09:18.280 --> 09:29.370] blocked. And then you go ahead and say, alright, so we blocked this site, we blocked that site. [09:30.790 --> 09:35.190] Don't think much about it. You don't think about what technology is actually blocking it. [09:35.190 --> 09:42.370] Is it the web-blocker? Is it EDR? Is it something like you blocked origin inside of the browser [09:42.370 --> 09:47.790] that you might have distributed out through your company? And why does that matter? [09:50.290 --> 09:55.390] I ran into the situation with mail.ru and its subdomains. They were being blocked and [09:55.390 --> 10:04.330] alerted on by Microsoft security tools in some machines, and Cisco's umbrella in other [10:04.330 --> 10:12.370] machines. Does that make sense to anybody? Hands? Or should I have just been banging [10:12.370 --> 10:18.910] my head against the wall like a crazy man? Would you have banged your head against the [10:18.910 --> 10:24.450] wall like somebody that was just ready to give up? I see a lot of head shaking out there. [10:25.310 --> 10:32.630] So, I ran into a, wait, what? And I didn't think too much about it. Both technologies [10:32.630 --> 10:39.330] would block. There was a reason why one was blocking over the other in different instances. [10:40.410 --> 10:47.570] But why was it happening? We'll start off with the mail.ru. Has anybody ever heard of [10:47.570 --> 10:52.650] that site before? Alright, we've got one person. You know, it's basically like a generic [10:52.650 --> 10:57.350] casual Russian type site. There's legitimate stuff on it, there's illegitimate stuff on [10:57.350 --> 11:02.610] it. A lot of illegitimate stuff on it that's hosted on it. There's also ads that are hosted [11:02.610 --> 11:07.870] on it. It's not really something that most people are going to wind up wanting to go [11:07.870 --> 11:15.610] to from our country or from most corporations, as it is, because the stuff on it is just [11:15.610 --> 11:25.470] what it is. It has some legit things on it, but during my research on this as to what [11:25.470 --> 11:33.410] it was and why it was being blocked in the first place, alienvault.otx.alienvault.com [11:33.410 --> 11:38.130] went ahead and listed out about 20 different malicious items that had been found on that [11:38.130 --> 11:43.790] site over the course of time. And that was just a quick look that I did on it, just to [11:43.790 --> 11:49.570] get an idea of what I was dealing with in here. As it turns out, the initial block and [11:49.570 --> 11:54.030] the initial reason somebody went there was somebody that was an employee that was originally [11:54.030 --> 11:59.670] from Russia and had their own personal mail account on mail.ru. And we looked at them [11:59.670 --> 12:04.410] and said, yeah, you can use your personal devices and your personal machines for that, [12:04.410 --> 12:10.110] not a corporate device. Thank you very much. And, yeah, we asked to it. But then we were [12:10.110 --> 12:17.490] still getting these weird blocks from it. And they were ads. And we're going, okay, so [12:17.490 --> 12:23.050] why is it being blocked one way and not the other, now that we've put this into an actual [12:23.050 --> 12:32.190] block list because we don't want people going to it. So, we found that there were layers [12:32.190 --> 12:38.030] sitting inside of there. The web blocking had layers. And what was it that was blocking [12:38.030 --> 12:43.170] it? It wasn't just the differing technology that we were running into. It was because [12:43.170 --> 12:47.550] of how they were layered is why one was blocking over the other. But that still doesn't make [12:47.550 --> 12:53.430] complete sense, does it? Why would you go ahead and still get, why would, if you've [12:53.430 --> 12:58.570] got the technology in place on two different machines, why would one use one technology [12:58.570 --> 13:06.330] and one use the other technology? Both machines make the exact same way. Well, it's a matter [13:06.330 --> 13:11.870] of knowing where in the stack, where is everything layered. Now, why is that important? You're [13:11.870 --> 13:17.330] on an incident. You've got to do a response on this. You're going through all the logs [13:17.330 --> 13:22.270] and everything. You see that something was blocked. Why would it be important to know [13:22.270 --> 13:28.350] when in the layers it was blocked? Well, it would give you an idea of how fast it was [13:28.350 --> 13:32.590] blocked, what's the chance of it spreading to other machines, what's the chance of something [13:32.590 --> 13:37.370] else going on beyond it, and what technology was actually doing the hard work on it all, [13:37.370 --> 13:43.650] so that way you can start digging into that technology more to get more answers. Not a [13:43.650 --> 13:51.330] bad idea, huh? How many people out here understand what their layering is? Understand if they've [13:51.330 --> 13:55.270] got multiple technologies that can do something, which one comes first, the chicken or the [13:55.270 --> 14:04.610] egg? It's not something that we think of very often, is it? So, let's take a look at [14:04.610 --> 14:11.050] this. This right here are two separate screens. You'll see the one that says Destination Mail [14:11.050 --> 14:17.410] RE, that is from the Cisco Umbrella Portal. You'll see there that it's categorized as [14:17.410 --> 14:24.330] News Media, Portal, Search Engine, Webmail, and our Internal Block List. To the right [14:24.330 --> 14:33.290] you'll see Microsoft Defender blocking, alerting on the site being blocked by Network Filter [14:33.290 --> 14:44.750] Lookup Service through Firefox. We put this into the Cisco Block List, into our Umbrella [14:44.750 --> 14:49.090] Block List, because of the research that I did and Microsoft was naturally trying to [14:49.090 --> 14:53.750] block it. So we figured, well, everybody should get the pop-ups through the corporate screen [14:53.750 --> 14:58.810] saying, we blocked the site and if you think that's incorrect, please report it to us and [14:58.810 --> 15:05.210] we'll take a look into it. That was the only way we could get that to go, but not everybody [15:05.210 --> 15:12.790] was getting it when we started testing. It is real interesting that it says Network Filter [15:12.790 --> 15:22.050] Lookup Service, as opposed to a Web Block. Now, Cisco's Umbrella works off of what used [15:22.050 --> 15:30.210] to be called Open DNS. They use categorizations, they use simplified systems to go ahead and [15:30.210 --> 15:34.310] allow you to set up what sites people can go to, what sites you're going to block down [15:34.310 --> 15:42.550] to, and it doesn't always give you 100% information. Now, while we were working through this, they [15:42.550 --> 15:46.930] actually made a couple of changes inside of the portal. The first question that we [15:46.930 --> 15:54.850] had was, is mail.ru even making it to the Cisco interface? We go in there and we see [15:54.850 --> 15:59.970] it says DNS next to it, and no, I don't have screenshots of this just because there was [15:59.970 --> 16:07.550] proprietary information inside of there that I cannot reveal at this point in time. But [16:07.550 --> 16:12.370] it would say DNS. So when we got on board with Cisco to start looking at this issue, [16:12.370 --> 16:18.930] why wasn't Cisco blocking it? Why was it being blocked by Microsoft? They said, well, the [16:18.930 --> 16:23.050] simple thing is, is that yeah, it's showing it, but it's just a DNS lookup that's going [16:23.050 --> 16:29.910] through and we're not seeing anything else beyond that. At least on the machines that [16:29.910 --> 16:34.710] we weren't getting the block screens on. We'll take a look into it maybe, but there's got [16:34.710 --> 16:39.370] to be something else going on. Not a lot of great information, except for the fact [16:39.370 --> 16:45.850] that even if you've got a website and a URL, it's still going to go through and at least [16:45.850 --> 16:52.250] hit the open DNS servers, the umbrella DNS servers, before it does any block. And that [16:52.250 --> 16:57.890] starts breaking down to, okay, so now we know when I type in a website, we'll go ahead and [16:57.890 --> 17:02.730] we'll take a look at that site and we'll see what the IP address is. We'll get that IP [17:02.730 --> 17:08.530] address first. And then when he tries to go ahead and make a connection to that site, [17:08.530 --> 17:12.770] we'll go ahead and we'll block it through the web locking technology inside of it all. [17:13.450 --> 17:21.940] Okay, makes sense. Would you agree with me on that? Well, the interesting thing is, is [17:21.940 --> 17:27.280] that we're still going ahead, not any closer to understanding why Microsoft was doing this. [17:31.800 --> 17:38.260] Why did it need to be in a manual block listing umbrella? Well, it's a matter of threat [17:38.260 --> 17:42.920] intelligence. Microsoft has their own threat intelligence. Cisco has their own threat [17:42.920 --> 17:48.160] intelligence. AlienVault has its own threat intelligence. Palo Alto has its own threat [17:48.160 --> 17:54.420] intelligence. Threat intelligence is its own threat intelligence. There's no standardization [17:54.420 --> 17:59.140] and there's very little communication between a lot of these companies. So they'll go ahead [17:59.140 --> 18:06.540] and do their best analysis on it. And the analysis boils down to, in a lot of cases, [18:06.540 --> 18:13.800] what a human being will say or what a machine learning algorithm says. Once it passes through [18:13.800 --> 18:18.460] one, the other one takes a look at it and makes a final decision. At least that's how [18:18.460 --> 18:28.540] I've seen it work at this point in time. So we decided to trust Microsoft and put it [18:28.540 --> 18:32.440] into the block list. We knew we weren't going to be stopping anything that we needed to [18:32.440 --> 18:37.280] worry about from a corporate standpoint. We weren't going to be affecting anything from [18:37.440 --> 18:42.340] a business standpoint. It was all going to still be there. And we weren't going to get [18:42.340 --> 18:47.040] any complaints. And sure enough, we put the block in there and we still don't get any [18:47.040 --> 18:51.980] complaints. And yes, I still get these alerts from Microsoft Defender to this day occasionally [18:52.880 --> 19:02.580] if there's an ad being served from mail.ru. You would think that adding it into the umbrella [19:02.580 --> 19:09.700] block list would be the end of it. We thought so and we were wrong. [19:11.840 --> 19:13.360] That does say wrong there. [19:17.840 --> 19:23.520] So what we started to do is, well I started to do the testing. The reason why was I [19:23.520 --> 19:28.520] was asked by the CISO, why is Umbrella not working the way it's supposed to be working? [19:29.440 --> 19:34.740] Or is it Microsoft Defender that's not working the way it's supposed to be working? [19:34.740 --> 19:38.240] One or the other is not working the way it's supposed to be working. Why are we getting [19:38.240 --> 19:43.640] to? So it was tasked to me to go through it. So I started testing mail.ru and enforcing [19:44.140 --> 19:50.880] things. First off, through different browsers. If it was getting blocked by Umbrella, we [19:50.880 --> 19:56.560] would get an umbrella block in all three browsers. Okay, so we know that it's not a [19:56.560 --> 20:04.020] browser-based situation. If it was getting blocked by that network filter on Microsoft [20:04.020 --> 20:08.600] Edge, you would get the smart filter screen. Has anyone here seen that red smart filter [20:08.600 --> 20:14.100] screen? I know that Edge is not always very popular. But it's a nice bright red screen [20:14.100 --> 20:21.320] that says, basically, we're blocking this because of security concerns. But if it was [20:21.320 --> 20:28.700] being blocked in Firefox, like you saw in the slide, or Chrome, or Brave, or any of [20:28.700 --> 20:33.240] the others, all you get is a white screen with a little bit of black text that says [20:33.240 --> 20:39.860] access denied. Well, that tells us a whole lot. Both screens tell us a whole lot, don't [20:39.860 --> 20:49.260] they? Access denied can be just about anything. So, the question is, which one is it going [20:49.260 --> 20:58.260] to actually hit first? What is the order? And order is important because security is [20:58.260 --> 21:04.160] knowledge. Knowing what should be doing what, when it should be doing it, helps you find [21:04.160 --> 21:10.100] out if you've got a misconfiguration or a vulnerability sitting out there that somebody [21:10.100 --> 21:16.880] is going to slide through, or potentially can slide through. If you don't know all of [21:16.880 --> 21:21.100] it, you might end up chasing your own tail forever, which, as you can hear, is what I [21:21.100 --> 21:31.240] was doing with this whole situation. So I was doing these tests. And it made me learn [21:31.240 --> 21:39.080] about both technologies in play. The first thing that I did was I found out that uBlock [21:39.080 --> 21:44.740] Origin, inside the browser, if it's an app that uBlock Origin has in their block list, [21:44.740 --> 21:49.640] because that's what they use as a centralized block list up on the net, that's going to [21:49.640 --> 21:55.200] supersede Umbrella, it's going to supersede Microsoft, it's going to supersede anything. [21:55.200 --> 21:59.000] It's going to see that URL that you punched in and say, hey, this is on my block list, [21:59.000 --> 22:05.040] it is blocked, boom, done. So there's your first layer right there, uBlock Origin. But [22:05.040 --> 22:10.480] as we all know, that is dependent upon things being reported in uBlock Origin, and however [22:10.480 --> 22:16.080] they decide what sites are good and what sites are bad. And it's mostly ad-based sites that [22:16.080 --> 22:20.560] uBlock Origin blocks anyway. They don't necessarily block malicious or anything like that. [22:23.200 --> 22:27.500] You also know that that could very easily be bypassed. It's very easy, even in corporate, [22:27.500 --> 22:33.260] to go ahead and just turn off uBlock Origin to go ahead and allow a site to work the way [22:33.260 --> 22:39.840] that they originally intended it to. We've all done that. We all know our users have [22:39.840 --> 22:44.320] done that as much as they say, oh no, I wouldn't do anything like that. We all know that that's [22:44.320 --> 22:48.740] not true. So let's start taking a look at it. [22:50.580 --> 22:57.500] Cisco Umbrella. Pardon me for a second. I've got to see how the screen looks. I have some [22:57.500 --> 23:02.820] slides here where things will pop up and some where they don't. Having the screen behind [23:02.820 --> 23:09.540] me is a little bit different than how I'm used to giving a presentation. So Cisco Umbrella [23:09.540 --> 23:17.160] was formerly OpenDNS. They allow successful DNS lookups before blocking. And it uses its [23:17.160 --> 23:25.920] own intelligence, Cisco Talos, to go ahead and categorize sites. Basically what Umbrella [23:25.920 --> 23:35.140] is, is a machine in the middle attack. If you really think about it, and it becomes [23:35.140 --> 23:42.060] more evident when there's a problem with the Umbrella root certificate, which I've seen [23:42.060 --> 23:46.900] happen before where the root certificate didn't get installed onto a machine, and [23:46.900 --> 23:53.240] your browsers nowadays with how they're going off about security and certificates, you all [23:53.240 --> 23:57.980] of a sudden get a block in Firefox, you get a block in Chrome, you get a block in Edge [23:57.980 --> 24:06.600] with a security warning on it saying, yeah, this is not a valid certificate. So you know [24:06.600 --> 24:11.780] that there's a middle section there that it's going through. It also means that the [24:11.780 --> 24:20.420] DNS lookup happens before any sort of blocking happens. Now we've got part of what's going [24:20.420 --> 24:24.120] on. So we understand the basics, and that's all that you need to know is the basics of [24:24.120 --> 24:28.640] how Umbrella is doing it. You're going in, you're typing in your website, it's going [24:28.640 --> 24:34.620] ahead and shifting everything over to its DNS and using its certificates, and then allowing [24:34.620 --> 24:45.780] everything to go through or blocking it. Simple, concise, almost pretty in a way. [24:47.480 --> 24:52.820] So then you get into the Microsoft network protection. And as I said, it was Microsoft [24:52.820 --> 24:58.580] Defender for Endpoint that was alerting on this. Network protection, we found out, bases [24:58.580 --> 25:06.540] and things on Microsoft's Intel. Big surprise there. But it has to be turned on. And where [25:06.540 --> 25:14.580] does it get turned on is the next thing. It's part of the exploit guard series of ASR rules, [25:15.360 --> 25:23.840] or attack surface reduction rules. So if I tested a machine, if I tested an ALR on a [25:23.840 --> 25:28.440] machine that did not have those rules applied, but did have Umbrella applied on it, the Umbrella [25:28.440 --> 25:36.460] block screen would show up as expected. If I had a machine that actually had those rules [25:36.460 --> 25:43.600] turned on, well, then we get into a different situation. But again, this is all through [25:43.600 --> 25:47.740] Defender that we're looking at. Now those of you that don't understand, Defender changes [25:47.740 --> 25:54.540] itself every three months right now. And it gets better. And it gets better. But you still [25:54.540 --> 25:58.740] have to go through a lot of these queries to figure out what's really going on behind [25:58.740 --> 26:04.540] the scenes. So we know it's part of exploit guard. We know it's turned off by default. [26:05.300 --> 26:11.180] It's enabled through group policy or Intune. Now why do I bring both of those up? Well, [26:11.180 --> 26:17.400] we'll get to that in a moment. But wait, there's more. It uses Microsoft's threat [26:17.400 --> 26:25.140] and tell, and it will give the smart screen message if you're using Microsoft Edge. And [26:25.140 --> 26:30.820] finally, it will just give you that access denied if you're using a non-Microsoft browser. [26:34.200 --> 26:40.040] Finally, it does alert in Defender. So we've got all this information. So we now know that, [26:40.040 --> 26:47.860] well, if we have exploit guard turned on on a machine, that seems to go first. If we don't [26:47.860 --> 26:54.460] have exploit guard turned on in the machine, it hits umbrella. So we're getting somewhere. [26:54.460 --> 27:02.040] So we now know the order of operations. So the question is, why is exploit guard not [27:02.040 --> 27:11.720] turned on in everything? So Microsoft's protection works similarly in the sense that it runs [27:11.720 --> 27:17.840] off a pure IPS DNS response, and it's not... network filtering is not a web-locking technology. [27:17.840 --> 27:25.960] I don't decide categories on that. It is purely done off of threat intel. If it blocks, [27:25.960 --> 27:31.040] it says either that the site's IP is good or bad, but there's always some network traffic [27:31.040 --> 27:35.900] involved with it. But there's less network traffic, and it's sitting closer to the kernel. [27:37.700 --> 27:42.700] Cisco was the third layer. So if the other two aren't working, then umbrella will wind [27:42.700 --> 27:47.240] up going and blocking it, or if it gets through these. Now we're getting to a point of going, [27:47.240 --> 27:52.960] now I understand why the layering is important. And we're not having technology interfering [27:52.960 --> 27:57.340] with each other. Instead, it's complementing each other. Isn't that what defense in depth [27:57.340 --> 28:04.460] is supposed to be? Isn't that what we're looking for? Is if something fails, we've got something [28:04.460 --> 28:10.460] else to back it up? And now we're doing it with two separate, completely separate ecosystems. [28:10.460 --> 28:15.900] A Cisco ecosystem and a Microsoft ecosystem. And they're actually working together, even [28:15.900 --> 28:26.960] though they don't directly communicate with each other. Defense in depth is layers. So [28:26.960 --> 28:33.400] the ultimate reasoning behind it all, and the final portion of the layers is, so why [28:33.400 --> 28:38.520] were it was only some machines? Well, when you're dealing with a hybrid situation where [28:38.520 --> 28:47.080] you have an on-premise domain and an Azure domain, unless you're joined to both of them, [28:47.080 --> 28:52.640] everything does not get pushed out through one technology. Azure joined machines do not [28:52.640 --> 29:00.040] get GPOs pushed to them. Everything goes through and to. This all started up during a period [29:00.040 --> 29:04.880] of time where we were starting to implement the ASR rules, including exploit guard and [29:04.880 --> 29:13.400] network filtering. We wound up in a situation where machines that were part of the rollout [29:13.400 --> 29:20.620] already, which was mostly on-prem machines joined to the on-prem domain, were getting [29:20.620 --> 29:26.900] those ASR rules. So they were blocking it through Microsoft network filtering. The machines, [29:26.900 --> 29:32.400] the laptops that were being taken home that were part of the Azure joined domain, they [29:33.060 --> 29:38.440] weren't getting that protection yet. Which gave us the time to go ahead and say to our [29:38.440 --> 29:42.360] other teams that were in charge of pushing out these protections, why aren't you pushing [29:42.360 --> 29:46.280] these out yet? You've pushed them out to the most sensitive of the machines and the [29:46.280 --> 29:51.260] machines that would break the easiest. Why have they not gone out to everybody else yet? [29:51.260 --> 29:57.300] To which we got the typical, we haven't had time to go ahead and finish testing them and [29:57.820 --> 30:03.200] we don't have enough resources to do it in a super fast fashion. We'll get to it within [30:03.200 --> 30:10.180] the next month. And they slowly have gotten to it and things have gotten pushed out. In [30:10.180 --> 30:14.060] the meantime, we turned around and said, well, thank God that we've got these multiple [30:14.060 --> 30:21.000] layers sitting there. Shows flat out that defense in depth does work. And it works very [30:21.000 --> 30:28.040] well if set up and configured properly. But again, whether it's the overview of different [30:28.040 --> 30:38.380] technologies from physical to policies, or it's inside of an endpoint solution or solutions, [30:38.380 --> 30:42.040] if you don't know where things are going to happen, you're just going to drive yourself [30:42.040 --> 30:47.500] crazy going, well, or you're just going to say, well, it's blocking, who cares? But somewhere [30:47.500 --> 30:51.500] down the line going that, who cares, can turn around and bite you in the butt when you have [30:51.500 --> 31:02.600] an actual situation. As to where Ublock working comes into play, it blocks ads nicely. I said [31:02.600 --> 31:08.500] it happens before Microsoft's technology. And it looks at the URL name and compares [31:08.500 --> 31:20.730] it to its own list. There are general layers. There are sub-layers. Layers can be different [31:21.170 --> 31:26.370] technologies. So layers upon layers upon different technologies. And sometimes inside of the [31:26.370 --> 31:31.970] same technology stack, you can have different layers sitting there. Microsoft Endpoint nowadays [31:31.970 --> 31:37.690] actually has its own web-blocking feature inside of it. I have not tested it thoroughly [31:37.690 --> 31:44.170] because it is still in its infancy and the way that it works doesn't lend itself to the [31:44.170 --> 31:49.250] corporate situation that I am in at this point in time. But I check it out every so often [31:49.250 --> 31:53.670] just to see if they've gotten it to a point where it's worth me completely testing on it. [31:55.630 --> 32:01.050] Cisco has multiple technologies. They're always acquiring stuff. You can have layers of Cisco [32:01.050 --> 32:06.530] technologies and in between layers of somebody else's technology in there. You could be using [32:06.530 --> 32:16.080] Duo with a Palo Alto firewall. The final idea though is to have the layers complement each [32:16.080 --> 32:20.620] other. So when you're actually doing a POC, when you're actually testing, you have to [32:20.620 --> 32:26.720] make sure that any machine that's being tested on has your current technology on there minus [32:26.720 --> 32:30.980] whatever technology is being replaced, if it's being replaced. So if you're trying to [32:30.980 --> 32:36.500] remove from something say like Defender from Endpoint to Carbon Black, you remove Defender [32:36.500 --> 32:40.000] from Endpoint from the machine but all the rest of your technologies have to still be [32:40.000 --> 32:47.620] on that machine. Two reasons why. Number one, you'll see where things hit. Number two, it'll [32:47.620 --> 32:51.700] make sure that you're not interfering like in the old days because that does happen at [32:51.700 --> 33:00.040] times. It's an instance where you need to go ahead and figure it out and that's part [33:00.040 --> 33:06.640] of our job. Everything is not all glam and not all writing up whatever you're writing [33:06.640 --> 33:14.820] up scripts, thread hunts, scene queries, however you look at it. Each one is just a greater [33:14.820 --> 33:19.700] part of the whole but you need to know how they fit into the whole like a jigsaw puzzle. [33:22.650 --> 33:31.010] There can be only one and that one is order. It is the order of operations, it is the order [33:31.010 --> 33:38.850] that things hit, it is the order that you implement them sometimes. But that's the only [33:38.850 --> 33:47.430] one consistent thing on it all, is that order. If you're going to do Defense in Depth properly, [33:47.430 --> 33:53.750] you need to know what that order is. Otherwise, it's basically spitballing it or throwing [33:53.870 --> 34:00.350] a piece of gum at a wall. Maybe it'll hit this, maybe it'll hit that, I don't know, [34:00.350 --> 34:05.250] maybe it hits here. And then when you have to go ahead and support that technology, you [34:05.250 --> 34:09.830] go, well, I don't know, and then you start wasting time trying to figure it out at that [34:09.830 --> 34:16.590] point. The vendors themselves are not always so helpful in being able to diagnose this [34:16.590 --> 34:23.390] sort of problem. And that's where we can really get better, is if we can get them to all work [34:23.390 --> 34:33.140] together with us. We see this on a regular basis. How many people here deal with scene [34:33.140 --> 34:41.860] technology? Logstash, Slipknot, what have you. How hard is it to go ahead and get things [34:41.860 --> 34:51.760] parsed properly into that scene? Anybody? Anybody have an easy time with it? How long? [34:52.360 --> 35:02.220] It's a mess? Syslog. How many items go in there that are Syslog? In different formatted [35:02.220 --> 35:08.040] Syslogs. In different shapes. You get the Linux, and then you get the Cisco, and then [35:08.040 --> 35:12.520] you get the Microsoft, and then you get this coming in, and you have to write up... I used [35:12.520 --> 35:17.080] to deal with Raylong this way. I had to write up parsers for five different technologies [35:17.740 --> 35:24.180] on Syslog, and a way for it to recognize which technology was coming in. That took me six [35:24.180 --> 35:32.480] months. Six months of testing, and checking, and testing. In the meantime, you're getting [35:32.480 --> 35:40.320] overfilled data on it. Why? Because everybody wants them in their one silo. We need to work [35:40.320 --> 35:48.040] together. And it's not just the corporations, such as Microsoft, or Palo Alto, or Cisco, [35:48.040 --> 35:53.640] or Carbon Black, that need to work together and come up with a standardized way to get [35:53.640 --> 35:58.820] logs in, and standardized fielding, so that way it parses properly. Because all that's [35:58.820 --> 36:04.900] part of defense in depth in its own right. That gives you the views that you need to [36:04.900 --> 36:11.000] see. But if you're not getting the fields that you need, or not able to easily see them, [36:11.000 --> 36:17.840] you're making your work two to three times as hard. But we also need to be able to share [36:17.840 --> 36:26.720] out these sorts of information. If you make a parser for Cisco Firepower, that parser [36:26.720 --> 36:32.980] is going to be different than Cisco ASA, by the way. I went through that. Inside of Cisco, [36:32.980 --> 36:40.280] ASA's syslog is different. The fields are different than Firepower's. Probably because [36:40.280 --> 36:45.820] Cisco bought Firepower and developed ASA. And the two teams don't necessarily communicate [36:45.820 --> 36:54.920] the best together. If we can share that information, if we can share something like this, where [36:54.920 --> 37:00.300] now all of you know that if you're using a Microsoft stack and a Cisco Umbrella stack, [37:00.300 --> 37:07.360] Microsoft's network filter is going to supersede anything that Umbrella does. That way, when [37:07.360 --> 37:11.280] somebody comes back and says, why isn't Umbrella blocking this? Why are we getting an alert [37:11.280 --> 37:16.540] from our EDR on this? Well, that's because Microsoft Threat Intelligence feels that this [37:16.540 --> 37:21.600] is blocked. Or we put it into a block that's inside of our EDR, and our network filter [37:21.600 --> 37:29.540] hits first. It goes ahead and says, oh, this is this? Fine. It hits before Cisco finally [37:29.540 --> 37:35.120] does. Well, we've got the same technologies everywhere. Well, obviously somewhere this [37:35.120 --> 37:38.480] technology is not working properly on the machine. Now you know where to go ahead and [37:38.480 --> 37:44.440] look for it. Now you know, well, wait a second, if that's not working on this one machine, [37:45.220 --> 37:50.520] what else isn't working on it that's part of the EDR? Is the EDR working properly? We [37:50.520 --> 37:53.320] need to dig into this to make sure that it's working right. [37:58.840 --> 38:05.520] CTEK astronomy is prevalent in the world that we live in. Anybody knows what CTEK astronomy [38:05.520 --> 38:17.630] is? Anybody ever see the movie Sneakers, and you don't know what CTEK astronomy is? Too [38:17.630 --> 38:28.020] many secrets. We're trying to protect secrets, but too many secrets are being kept from us [38:28.020 --> 38:37.100] by the vendors. I always liken our world to a set of layers anyways. We have the security [38:37.100 --> 38:44.320] industry, and we have the security field, and they cross over all the time. The security [38:44.320 --> 38:55.700] industry are the vendors, whether it's an MSP or a tool provider. The field is each [38:55.700 --> 39:01.420] one of us. You can work in whatever vertical you want to and be part of the security field. [39:02.420 --> 39:08.180] But that vertical isn't necessarily part of the security industry. We need to get everybody [39:08.540 --> 39:14.340] talking better together. Why? Because it gives us more depth. It gives us more knowledge. [39:14.560 --> 39:20.880] It gives us more information. I'm going to finish off by saying, it's not goodbye, but [39:20.880 --> 39:28.660] I'll see you later. If you have any questions, I'm free to take them right now. Anybody? [39:34.380 --> 39:39.240] All right. Well, that about does it. Again, you can find me on Twitter at SiliconShackie. [39:39.240 --> 39:44.100] You can check out my website at SiliconShackie.com. I'll be here all day if you feel you want [39:44.100 --> 39:51.800] to come up and talk to me. I'm always friendly. Well, try to be friendly at least. Thank you [39:51.800 --> 39:53.560] very much, and have a great day. [39:53.560 --> 39:55.480] Thank you.