WEBVTT 00:00:11.009 --> 00:00:13.289 Hello, and welcome to another episode of the 00:00:13.289 --> 00:00:15.589 Everyday Defender podcast. I'm your host, Chris 00:00:15.589 --> 00:00:17.809 Goosen, and I'm joined as always by this man 00:00:17.809 --> 00:00:20.870 right here. Koos, how are you, my friend? Hey, 00:00:20.890 --> 00:00:23.149 Chris. How are you doing? I'm doing great. Doing 00:00:23.149 --> 00:00:24.829 very well. I'm back from the holidays, so I'm 00:00:24.829 --> 00:00:27.489 fully recharged and relaxed, and a little bit 00:00:27.489 --> 00:00:31.929 of a tan on me as well, so a relaxing start of... 00:00:32.570 --> 00:00:35.409 Greece will do that to you, I think. If you spend 00:00:35.409 --> 00:00:37.329 some time in Greece, you will come back energized. 00:00:37.609 --> 00:00:41.250 You do very much. You cannot evade the sun. I 00:00:41.250 --> 00:00:43.869 actually experienced an earthquake as well when 00:00:43.869 --> 00:00:46.750 I was there. It was my first time, actually. 00:00:46.909 --> 00:00:49.369 It was a quite weird experience. Middle of the 00:00:49.369 --> 00:00:51.810 night, my bed and the whole house was shaking 00:00:51.810 --> 00:00:54.850 a little bit. Luckily, nobody got hurt and there 00:00:54.850 --> 00:00:57.270 was no damage on the island. But it was a weird 00:00:57.270 --> 00:00:59.850 experience. That's so funny. We had an earthquake 00:00:59.850 --> 00:01:03.920 here. southwestern sydney which is where i am 00:01:03.920 --> 00:01:07.079 i'm on the outskirts um we had a 3 .5 magnitude 00:01:07.079 --> 00:01:10.599 earthquake like two days ago um i didn't i didn't 00:01:10.599 --> 00:01:13.280 even notice it but my cat my cat went crazy so 00:01:13.280 --> 00:01:16.879 it was really weird um so anyway i've i've been 00:01:16.879 --> 00:01:18.180 thinking about you over the last couple weeks 00:01:18.180 --> 00:01:21.180 because um i've been digging into and playing 00:01:21.180 --> 00:01:24.780 with um with sentinel and uh log ingestion with 00:01:24.780 --> 00:01:32.280 log stash Instead of using a syslog or something 00:01:32.280 --> 00:01:34.180 like that and then having the agent push it, 00:01:34.340 --> 00:01:37.579 I've been messing around with Logstash on Linux 00:01:37.579 --> 00:01:39.819 and then have Logstash take the logs and ingest 00:01:39.819 --> 00:01:42.859 them. Man, I love the idea of that. And I think 00:01:42.859 --> 00:01:45.459 being able to do those transforms and stuff before 00:01:45.459 --> 00:01:48.959 you ingest is such a powerful thing. But luckily, 00:01:49.060 --> 00:01:50.739 I haven't had to ping you yet because I've been 00:01:50.739 --> 00:01:52.439 able to get it all done myself without going, 00:01:52.540 --> 00:01:56.230 how do I do this thing? but it's yeah it's funny 00:01:56.230 --> 00:01:58.849 when you when you google something sentinel and 00:01:58.849 --> 00:02:01.769 logstash related my blogs came up uh come up 00:02:01.769 --> 00:02:04.489 quite high in the google rankings so that's funny 00:02:04.489 --> 00:02:08.610 i'm i'm a big fan yeah yeah yeah especially the 00:02:08.610 --> 00:02:11.689 multi -destination uh bit is also great that's 00:02:11.689 --> 00:02:14.330 something you cannot do easily with the microsoft 00:02:14.330 --> 00:02:16.969 out of the box solutions yeah well glad you like 00:02:16.969 --> 00:02:20.090 it yeah it's been a bit fun so uh more on this 00:02:20.090 --> 00:02:21.949 at some point uh at the moment i'm still just 00:02:22.379 --> 00:02:24.259 playing and labbing but at some point maybe we'll 00:02:24.259 --> 00:02:27.159 have an episode on that but yeah in today's episode 00:02:27.159 --> 00:02:31.379 um another month another episode uh we have so 00:02:31.379 --> 00:02:34.520 i've got five things that you can do uh to harden 00:02:34.520 --> 00:02:36.939 your m365 tenant things that you should probably 00:02:36.939 --> 00:02:40.139 be doing to harden your m365 tenants and and 00:02:40.139 --> 00:02:43.360 coast tell me about uh sentinel summoning rules 00:02:43.360 --> 00:02:45.960 or summary rules that is gonna we're gonna trip 00:02:45.960 --> 00:02:47.900 that one up a few times today aren't we Yeah, 00:02:47.979 --> 00:02:51.539 summary rules. It's a relatively new feature 00:02:51.539 --> 00:02:56.620 in Sentinel, still in preview. Yeah, so I spoke 00:02:56.620 --> 00:03:00.740 about some log strategy details in episode four 00:03:00.740 --> 00:03:05.099 back in March. And I touched on auxiliary logs, 00:03:05.280 --> 00:03:07.120 which were still in preview back then. They're 00:03:07.120 --> 00:03:10.539 now general available. And I touched on why you... 00:03:10.750 --> 00:03:12.710 would probably also want to look into Azure Data 00:03:12.710 --> 00:03:14.969 Explorer back then because the usefulness of 00:03:14.969 --> 00:03:18.469 logs and auxiliary and basic tables is a bit 00:03:18.469 --> 00:03:20.889 of well, it was a little bit meh, to be honest. 00:03:21.250 --> 00:03:24.169 And I think with summary rules, Microsoft is 00:03:24.169 --> 00:03:26.509 taking a great step into the right direction 00:03:26.509 --> 00:03:29.330 of increasing the value of the logs in those 00:03:29.330 --> 00:03:32.770 tables. So if you're not moving away to Azure 00:03:32.770 --> 00:03:35.090 Data Explorer or if you probably did and you 00:03:35.090 --> 00:03:38.199 have. probably reasons why it was easier to have 00:03:38.199 --> 00:03:40.860 all your logs in one place you might want to 00:03:40.860 --> 00:03:43.719 look into summary rules and they probably make 00:03:43.719 --> 00:03:46.099 your life a little bit easier man that sounds 00:03:46.099 --> 00:03:48.840 exciting okay well we'll get into that after 00:03:48.840 --> 00:03:50.740 we talk about some tenant hardening and i the 00:03:50.740 --> 00:03:53.860 reason that i've come and you know Back behind 00:03:53.860 --> 00:03:56.780 the scenes of this podcast, this has been a topic 00:03:56.780 --> 00:03:58.240 that I've been wanting to talk about for two 00:03:58.240 --> 00:04:00.900 or three episodes now. And whenever we plan our 00:04:00.900 --> 00:04:03.360 episodes, oftentimes something else comes in, 00:04:03.419 --> 00:04:07.520 trumps the topics that we have, or for whatever 00:04:07.520 --> 00:04:09.879 reason, we talk about other things. But I've 00:04:09.879 --> 00:04:11.360 been wanting to talk about this for a while because 00:04:11.360 --> 00:04:15.310 I think... Whenever I do assessments for customers 00:04:15.310 --> 00:04:18.850 and I look at their tenants, now, very often 00:04:18.850 --> 00:04:22.029 I'm following guidance like CIS and the CIS benchmarks. 00:04:22.930 --> 00:04:26.529 But I often, more often than not, find that a 00:04:26.529 --> 00:04:28.250 lot of these default configurations have never 00:04:28.250 --> 00:04:30.990 been changed, right? And I think one of the things 00:04:30.990 --> 00:04:35.350 about M365 is that your tenant by default is 00:04:35.350 --> 00:04:38.089 there to make you, and I'm using air quotes for 00:04:38.089 --> 00:04:40.649 those of you who are listening and not watching. 00:04:41.259 --> 00:04:44.139 to make you as productive as possible, right? 00:04:44.199 --> 00:04:47.759 So really optimize for productivity, but probably 00:04:47.759 --> 00:04:50.319 not optimal when it comes to security and secure 00:04:50.319 --> 00:04:52.500 posture, right? By default, a lot of the stuff 00:04:52.500 --> 00:04:55.079 is wide open and you really want to go in there 00:04:55.079 --> 00:04:59.240 and sort of turn off or tweak some of these configurations. 00:04:59.759 --> 00:05:01.959 And oftentimes customers say, well, you know 00:05:01.959 --> 00:05:03.579 what? I'm not using SharePoint online yet. So 00:05:03.579 --> 00:05:05.759 why should I bother configuring SharePoint online? 00:05:05.939 --> 00:05:08.620 Well, it's a lot harder to fix things and configure 00:05:08.620 --> 00:05:10.720 things once you start putting data in it right 00:05:10.720 --> 00:05:13.180 rather rather make sure that your tenant is is 00:05:13.180 --> 00:05:15.680 hardened before you start lighting up services 00:05:15.680 --> 00:05:18.560 um and so i've got some of these some tips here 00:05:18.560 --> 00:05:20.360 and to be fair there's there's a lot more than 00:05:20.360 --> 00:05:21.819 five things that you could probably be doing 00:05:21.819 --> 00:05:25.060 or should be doing but really um in the interest 00:05:25.060 --> 00:05:27.199 of time and distilling this down into into you 00:05:27.199 --> 00:05:29.740 know the episode i um i wanted to bring up the 00:05:29.740 --> 00:05:31.439 five things that i think are probably the most 00:05:31.439 --> 00:05:33.639 important right and and you know if you're an 00:05:33.639 --> 00:05:35.560 admin in a tenant doesn't matter what size tenant 00:05:35.560 --> 00:05:38.060 go and have a look at these these these configurations 00:05:38.060 --> 00:05:41.300 obviously the more complex your environment the 00:05:41.300 --> 00:05:43.420 longer it may take you to implement some of these 00:05:43.420 --> 00:05:46.000 things but have a look anyway and you you might 00:05:46.000 --> 00:05:47.779 be surprised that some of these things are still 00:05:47.779 --> 00:05:50.040 configured you know in the default setting so 00:05:50.040 --> 00:05:53.839 um the first thing these things are are not uh 00:05:53.839 --> 00:05:56.720 enabled by default by microsoft on also another 00:05:56.720 --> 00:06:00.230 new tenants correct they are um settings that 00:06:00.230 --> 00:06:01.910 you have to actually go in and tweak yourself 00:06:01.910 --> 00:06:05.029 so so if you think about you know the default 00:06:05.029 --> 00:06:06.610 tenant configuration kind of leaves the door 00:06:06.610 --> 00:06:08.870 open and and what these a lot of these settings 00:06:08.870 --> 00:06:10.610 are is to go and close that door a little bit 00:06:10.610 --> 00:06:12.870 or at least lock put a lock on it or what have 00:06:12.870 --> 00:06:18.610 you so okay right so the first one is disabling 00:06:18.610 --> 00:06:21.769 user app registration um now app registration 00:06:21.769 --> 00:06:25.810 application consent those things are currently 00:06:25.810 --> 00:06:30.139 um uh very very risky areas right we're seeing 00:06:30.139 --> 00:06:32.680 a lot more attacks happening on those vectors 00:06:32.680 --> 00:06:35.439 because folks are getting identity right like 00:06:35.439 --> 00:06:37.459 we're starting to harden identity to the point 00:06:37.459 --> 00:06:39.800 where it's a lot harder to to attack the identity 00:06:39.800 --> 00:06:42.079 so well what's the next best thing well we start 00:06:42.079 --> 00:06:44.139 attacking apps and app registrations right so 00:06:44.139 --> 00:06:45.800 this first configuration which is essentially 00:06:45.800 --> 00:06:48.540 allowing users within the tenant any user within 00:06:48.540 --> 00:06:51.540 the tenant to be able to register an app in in 00:06:51.540 --> 00:06:55.589 entra By default, any user can register an app 00:06:55.589 --> 00:06:59.089 in intro. It's a really bad idea for many reasons. 00:06:59.649 --> 00:07:04.050 But really, if you think about unauthorized access 00:07:04.050 --> 00:07:09.209 to tenant resources just due to misconfigurations, 00:07:09.230 --> 00:07:12.750 things like that, just restrictions on data and 00:07:12.750 --> 00:07:16.649 what data access you might be able to allow by 00:07:16.649 --> 00:07:19.329 doing this wrong or incorrectly, you really don't 00:07:19.329 --> 00:07:23.259 want users creating and registering apps in your 00:07:23.259 --> 00:07:27.959 tenant. In the intro portal, it's a very simple 00:07:27.959 --> 00:07:31.139 setting just called users can register applications, 00:07:31.480 --> 00:07:34.939 set it to no. I'm going to, with all of these, 00:07:34.980 --> 00:07:38.379 include the steps to remediate in the show notes. 00:07:38.920 --> 00:07:40.899 um also a lot more information about sort of 00:07:40.899 --> 00:07:42.920 why it's a good idea to remediate this is i don't 00:07:42.920 --> 00:07:45.399 take my word for it you can you know read up 00:07:45.399 --> 00:07:47.459 on what's here but also don't do some some of 00:07:47.459 --> 00:07:49.259 your own research and a lot of these things do 00:07:49.259 --> 00:07:52.180 actually line up very well with cis so again 00:07:52.180 --> 00:07:54.439 if you do follow cis benchmarks you'll find that 00:07:54.439 --> 00:07:57.819 all of these things um line up with cis but um 00:07:58.670 --> 00:08:01.870 The takeaway from the first one is you don't 00:08:01.870 --> 00:08:04.550 want users or any user to be registering apps 00:08:04.550 --> 00:08:06.269 in your environment. What you really want to 00:08:06.269 --> 00:08:09.850 be looking at is allowing specific roles to register 00:08:09.850 --> 00:08:12.769 apps. If you do happen to have developers in 00:08:12.769 --> 00:08:14.509 the environment that are writing custom apps 00:08:14.509 --> 00:08:16.930 for your environment, you probably need a workflow 00:08:16.930 --> 00:08:20.550 of some sort that you can wrap around how applications 00:08:20.550 --> 00:08:23.790 get registered. they probably should be working 00:08:23.790 --> 00:08:25.709 into a dev environment to begin with, right? 00:08:25.750 --> 00:08:27.430 So this shouldn't be happening in your prod environment 00:08:27.430 --> 00:08:32.429 anyway. But depending on your scenarios, it may 00:08:32.429 --> 00:08:34.450 not be as easy as saying no and turning everything 00:08:34.450 --> 00:08:37.210 off. You may want to have a workflow or some 00:08:37.210 --> 00:08:42.049 sort of request or consent form of some sort 00:08:42.049 --> 00:08:44.370 so that there's some control over who can do 00:08:44.370 --> 00:08:46.440 this and who cannot. Because there may be legitimate 00:08:46.440 --> 00:08:48.740 reasons that obviously are legitimate reasons 00:08:48.740 --> 00:08:51.740 why you might register apps into your tenant. 00:08:51.960 --> 00:08:54.600 But regular average users should not have the 00:08:54.600 --> 00:08:56.340 ability to do that. And you really want to go 00:08:56.340 --> 00:09:01.440 turn that off. Very, very closely aligned to 00:09:01.440 --> 00:09:05.080 that is user consent for applications, right? 00:09:05.179 --> 00:09:09.559 And I'm sure we've all sort of seen this in the 00:09:09.559 --> 00:09:14.610 wild where You want to use some whizzbang AI 00:09:14.610 --> 00:09:17.929 note -taking app, and immediately when you say 00:09:17.929 --> 00:09:19.889 sign up, the first thing it does is it pops up 00:09:19.889 --> 00:09:22.370 a window that says, you know, such and such app 00:09:22.370 --> 00:09:24.730 wants to have access to your profile and would 00:09:24.730 --> 00:09:26.690 like to do, and then it lists a few things there 00:09:26.690 --> 00:09:30.519 that it wants to do, right? And you can click 00:09:30.519 --> 00:09:32.720 allow. And most users never read that. They just 00:09:32.720 --> 00:09:34.779 click allow and whatever pops up because that's 00:09:34.779 --> 00:09:36.759 the only way you get to use the app. Well, that 00:09:36.759 --> 00:09:39.539 application now has full access to whatever you've 00:09:39.539 --> 00:09:42.080 given it permission to. And typically in your 00:09:42.080 --> 00:09:43.600 environment, users are going to be able to grant 00:09:43.600 --> 00:09:46.720 permission to their profile and everything that 00:09:46.720 --> 00:09:49.899 they have access to within the environment. But 00:09:49.899 --> 00:09:51.840 really, you should not be allowing users to do 00:09:51.840 --> 00:09:54.100 that. So again, you don't want users to be able 00:09:54.100 --> 00:09:58.690 to consent at all to applications. um and you 00:09:58.690 --> 00:10:00.710 should have a pretty tight policy again on who 00:10:00.710 --> 00:10:03.909 can consent uh for things that are tenant wide 00:10:03.909 --> 00:10:07.370 um and and um you should have some sort of uh 00:10:07.370 --> 00:10:10.250 uh request process right because if you if you 00:10:10.250 --> 00:10:12.269 think about it there are going to be things uh 00:10:12.269 --> 00:10:14.350 where you know users are going to want to install 00:10:14.350 --> 00:10:17.129 some application that interacts with their m365 00:10:17.129 --> 00:10:19.870 environment and their data but you you don't 00:10:19.870 --> 00:10:21.269 want them to just be able to do this with no 00:10:21.269 --> 00:10:24.529 sanction right you need um a process whereby 00:10:25.340 --> 00:10:26.899 your cyber security team your administrators 00:10:26.899 --> 00:10:29.220 can actually take a look and inspect the application 00:10:29.220 --> 00:10:31.600 and the permissions that the application has 00:10:31.600 --> 00:10:35.600 um and is requesting before you just allow uh 00:10:35.600 --> 00:10:38.840 any any app to be consented now the the problem 00:10:38.840 --> 00:10:40.700 with this as well is like once stuff is in there 00:10:40.700 --> 00:10:43.240 it's really hard to go and comb through it and 00:10:43.240 --> 00:10:46.419 get rid of it as well right so um for me this 00:10:46.419 --> 00:10:48.440 one you know i really don't like that this is 00:10:48.440 --> 00:10:50.840 on by default so by default anyone can consent 00:10:50.840 --> 00:10:53.570 to anything um This is one of the first things 00:10:53.570 --> 00:10:56.549 that I disable when doing a tenant hardening. 00:10:57.230 --> 00:11:00.570 And then you want to think about what sort of 00:11:00.570 --> 00:11:05.710 workflow can we create here for folks to do it. 00:11:05.750 --> 00:11:09.330 Now, there is actually built -in workflow, admin 00:11:09.330 --> 00:11:12.169 workflow scenarios within Entra where you can 00:11:12.169 --> 00:11:15.509 assign a group to a workflow. And then if the 00:11:15.509 --> 00:11:18.970 user needs to use whatever the app is, they can 00:11:18.970 --> 00:11:21.129 click request consent that goes into a queue 00:11:21.129 --> 00:11:22.950 that the administrators and the tenant can then 00:11:22.950 --> 00:11:25.730 you know look at they can investigate whether 00:11:25.730 --> 00:11:27.950 this is a good idea or a bad idea whatever and 00:11:27.950 --> 00:11:31.889 either decide to allow it or not so definitely 00:11:31.889 --> 00:11:34.710 want you to look at and like i said applications 00:11:34.710 --> 00:11:37.450 and application consent these things are being 00:11:37.450 --> 00:11:40.110 actively targeted at the moment um i actually 00:11:40.110 --> 00:11:43.210 have a presentation that i've done before where 00:11:43.210 --> 00:11:47.259 um i've created a fake app that looks to consent 00:11:47.259 --> 00:11:51.299 for a user, and it disguises itself as something 00:11:51.299 --> 00:11:54.279 that a user might want to use. But under the 00:11:54.279 --> 00:11:56.240 covers, what it's doing is it's getting as much 00:11:56.240 --> 00:11:58.039 permission to the user's profile as it possibly 00:11:58.039 --> 00:12:02.159 can. And through Graph, we all know Graph is 00:12:02.159 --> 00:12:05.340 very, very deep and very granular as far as what 00:12:05.340 --> 00:12:08.860 sort of permissions you can request. And once 00:12:08.860 --> 00:12:14.110 you have that, you've got... a real real difficult 00:12:14.110 --> 00:12:16.690 challenge to to to get through all of these things 00:12:16.690 --> 00:12:18.710 and actually revoke all of those things so um 00:12:18.710 --> 00:12:21.509 better to just look at disabling them to to begin 00:12:21.509 --> 00:12:25.129 with yeah attackers are using the phishing campaigns 00:12:25.129 --> 00:12:28.850 and all kinds of attacks indeed to to let user 00:12:28.850 --> 00:12:31.950 consent into certain uh certain stuff and uh 00:12:31.950 --> 00:12:35.250 yeah if you have not put the hardening in place 00:12:35.250 --> 00:12:39.289 it might end up with more permissions than you 00:12:39.289 --> 00:12:42.549 want to and even i see a lot of applications 00:12:43.389 --> 00:12:45.750 I think that's also something that needs to change. 00:12:45.870 --> 00:12:48.070 It's not something you can really harden on up 00:12:48.070 --> 00:12:51.490 front, but I see some third -party solutions 00:12:51.490 --> 00:12:54.929 wanting you to create applications and then consent 00:12:54.929 --> 00:12:57.230 to certain permissions, and there are way more 00:12:57.230 --> 00:13:00.210 permissions that they would likely to need, like 00:13:00.210 --> 00:13:04.830 full users read write or full user read all Entry 00:13:04.830 --> 00:13:07.389 ID properties from all the users, for example. 00:13:07.529 --> 00:13:11.289 It can be abused, obviously, also quite quickly. 00:13:11.350 --> 00:13:13.149 Yeah, and that's one of the reasons for the very 00:13:13.149 --> 00:13:14.769 first recommendation, Rob, which is don't allow 00:13:14.769 --> 00:13:18.950 end users to create those apps because as a vendor, 00:13:18.970 --> 00:13:20.409 the vendor comes to you with these requirements. 00:13:20.629 --> 00:13:22.750 As a user, you don't know what those things are. 00:13:22.789 --> 00:13:24.909 You just do it. No, no, no. Rather have that 00:13:24.909 --> 00:13:27.169 go through a process where you have a cyber team 00:13:27.169 --> 00:13:30.129 or administrators look at it and understand what 00:13:30.129 --> 00:13:32.669 these things are asking for before you actually 00:13:32.669 --> 00:13:36.669 just allow the app to be registered. So funny 00:13:36.669 --> 00:13:39.419 you mentioned that. firsthand of course with 00:13:39.419 --> 00:13:42.700 midnight Blizzard it was also an attack uh abusing 00:13:42.700 --> 00:13:45.639 apps in different tenants which happen to have 00:13:45.639 --> 00:13:48.740 permissions in the production tenant and so forth 00:13:48.740 --> 00:13:51.460 very difficult to find those things yeah yeah 00:13:51.460 --> 00:13:52.840 that's right and it's funny you mentioned the 00:13:52.840 --> 00:13:55.700 fishing the fishing scenario because that's very 00:13:55.700 --> 00:13:57.679 common and those fishing scenarios are not always 00:13:57.679 --> 00:13:59.720 on email right they can happen on teams as well 00:13:59.720 --> 00:14:02.179 and I actually have a tip for that as well coming 00:14:02.179 --> 00:14:06.379 up um as far as collaboration and you know we 00:14:06.379 --> 00:14:10.179 all understand sort of um guest access and and 00:14:10.179 --> 00:14:12.539 allowing folks to be invited into the tenant 00:14:12.539 --> 00:14:14.360 for collaboration which is a really really good 00:14:14.360 --> 00:14:17.179 idea but by default in the tenant anyone can 00:14:17.179 --> 00:14:21.399 invite anyone to collaborate and have guest access. 00:14:21.840 --> 00:14:23.539 Really, I think that this needs to be locked 00:14:23.539 --> 00:14:26.980 down and you want to be limiting it to those 00:14:26.980 --> 00:14:30.340 invites to allow domains only or trusted domains 00:14:30.340 --> 00:14:33.820 only. There's a domain allow list in Entra that 00:14:33.820 --> 00:14:38.500 you can use for this. You essentially add the 00:14:38.500 --> 00:14:41.399 domains that you want to allow guest access from, 00:14:41.519 --> 00:14:43.779 and those invites will only be allowed to go 00:14:43.779 --> 00:14:46.960 out to those domains, so it locks it down. Now, 00:14:46.980 --> 00:14:48.799 again, very easy to implement this, but obviously 00:14:48.799 --> 00:14:52.240 if you've been working and using M365 for five 00:14:52.240 --> 00:14:54.460 years or 10 years and you haven't done this, 00:14:54.620 --> 00:14:58.860 you might have a fairly large list of guest accounts 00:14:58.860 --> 00:15:01.139 already in your environment, right? And you want 00:15:01.139 --> 00:15:02.639 to, when you lock this down, you want to spend 00:15:02.639 --> 00:15:05.019 a little bit of time understanding who those 00:15:05.019 --> 00:15:09.000 collaboration partners are that you are, the 00:15:09.000 --> 00:15:11.059 organizations that you're collaborating with. 00:15:11.159 --> 00:15:13.580 Because it may be very simple and clear cut. 00:15:13.860 --> 00:15:16.299 It may not. be so simple and clear cut depending 00:15:16.299 --> 00:15:18.440 on your environment so again it's one of those 00:15:18.440 --> 00:15:20.500 things that um you know you over you want to 00:15:20.500 --> 00:15:22.620 build it up over time you build up this list 00:15:22.620 --> 00:15:24.419 it's not something you probably have full list 00:15:24.419 --> 00:15:27.279 on day one um i would say you need to implement 00:15:27.279 --> 00:15:29.700 this and you want to you want to provide a a 00:15:29.700 --> 00:15:32.899 mechanism for users to request um or provide 00:15:32.899 --> 00:15:36.039 feedback right if um you know typically your 00:15:36.039 --> 00:15:38.259 sales organization may be reaching out and collaborating 00:15:38.259 --> 00:15:41.840 with with lots of uh different vendors or different 00:15:41.840 --> 00:15:44.100 third parties you know those type of things so 00:15:44.700 --> 00:15:47.379 You as IT or as the security team may not know 00:15:47.379 --> 00:15:50.179 all of the folks that your organization is collaborating 00:15:50.179 --> 00:15:52.779 with, but it's a really, really good idea to 00:15:52.779 --> 00:15:54.840 lock this down and provide a mechanism for them 00:15:54.840 --> 00:15:59.379 to request that that be accessed. So again, something 00:15:59.379 --> 00:16:02.179 done in the Entra portal, and I have some steps 00:16:02.179 --> 00:16:04.340 in the show notes as to how you do this. The 00:16:04.340 --> 00:16:07.820 setting is called, well, you allow invitations 00:16:07.820 --> 00:16:10.919 only to be sent to specified domains, and then 00:16:10.919 --> 00:16:13.549 there's a list of domains. The fourth setting 00:16:13.549 --> 00:16:15.950 is very similar, but this one is actually in 00:16:15.950 --> 00:16:18.009 SharePoint and for SharePoint Online. Really 00:16:18.009 --> 00:16:21.769 what that does is external sharing again. Instead 00:16:21.769 --> 00:16:25.210 of allowing your users to just share with anyone 00:16:25.210 --> 00:16:28.590 outside, you want to lock that down to a list 00:16:28.590 --> 00:16:36.210 of trusted domains. If I know that I'm collaborating 00:16:36.210 --> 00:16:38.659 with folks at Microsoft, you lock down microsoft 00:16:38.659 --> 00:16:41.299 .com as a as an allowed list allowed domain you 00:16:41.299 --> 00:16:44.039 don't allow other domains to be um the recipient 00:16:44.039 --> 00:16:46.740 of of sharing requests and things like that and 00:16:46.740 --> 00:16:49.360 this it works under the very same prince a similar 00:16:49.360 --> 00:16:52.789 principle um but this one you actually control 00:16:52.789 --> 00:16:56.110 and lock down in the SharePoint admin center. 00:16:56.789 --> 00:17:00.389 And there's some settings in there for OneDrive 00:17:00.389 --> 00:17:02.649 as well that probably worth taking a look at. 00:17:02.710 --> 00:17:05.069 I haven't listed those out here explicitly, but 00:17:05.069 --> 00:17:09.230 worth taking a look at how the OneDrive settings 00:17:09.230 --> 00:17:11.369 affect as well, because OneDrive and the SharePoint 00:17:11.369 --> 00:17:13.890 settings are quite similar as far as allowing 00:17:13.890 --> 00:17:16.470 external access and things like that. A bunch 00:17:16.470 --> 00:17:18.269 of these sharing things are just on by default. 00:17:19.789 --> 00:17:21.789 it really does give you that sort of risk of 00:17:21.789 --> 00:17:24.930 data leakage and folks just sharing stuff out 00:17:24.930 --> 00:17:29.329 in the wider world where your compliance folks 00:17:29.329 --> 00:17:31.089 are probably, and your governance folks are probably 00:17:31.089 --> 00:17:35.950 not enjoying that. So yeah, so it's managed external 00:17:35.950 --> 00:17:39.750 sharing in SharePoint. And then the last one 00:17:39.750 --> 00:17:41.930 that I kind of wanted to talk about is in Teams. 00:17:42.029 --> 00:17:44.109 And again, there's so many things in Teams that 00:17:44.109 --> 00:17:47.890 are just on by default, but you can similarly 00:17:47.890 --> 00:17:50.880 allow... collaboration only with allowed domains 00:17:50.880 --> 00:17:53.240 and stuff like that within Teams. But this one 00:17:53.240 --> 00:17:56.480 specifically is about disabling communication 00:17:56.480 --> 00:18:00.039 with unmanaged Teams users. And the concept of 00:18:00.039 --> 00:18:03.359 unmanaged is free accounts, free Teams accounts. 00:18:03.660 --> 00:18:06.359 Those are accounts that are not managed by an 00:18:06.359 --> 00:18:08.059 organization. They're not part of an enterprise 00:18:08.059 --> 00:18:12.140 tenant. And really, you don't want your users 00:18:12.140 --> 00:18:16.910 to be able to message and communicate. outside 00:18:16.910 --> 00:18:19.710 or externally to folks that are not at least 00:18:19.710 --> 00:18:21.829 part of an organization right and if you've locked 00:18:21.829 --> 00:18:24.789 it down correctly then you're only allowing your 00:18:24.789 --> 00:18:27.109 team's users to collaborate with users in a domain 00:18:27.109 --> 00:18:30.710 that you know you trust um so you're not gonna 00:18:30.710 --> 00:18:33.690 you know you there's no danger of them um being 00:18:33.690 --> 00:18:36.730 contacted or or communicating with users that 00:18:36.730 --> 00:18:39.329 are in some unmanaged state and this is where 00:18:39.329 --> 00:18:41.490 because the example you mentioned of phishing 00:18:41.490 --> 00:18:43.930 this we've seen this play out right where you 00:18:43.930 --> 00:18:47.160 have um a scammer who just uses a free teams 00:18:47.160 --> 00:18:50.059 account finds out that you have open federation 00:18:50.059 --> 00:18:52.619 on your teams starts messaging your users on 00:18:52.619 --> 00:18:55.920 teams sending them links to stuff and potentially 00:18:55.920 --> 00:19:00.279 send them links to to um consent grants that 00:19:00.279 --> 00:19:03.500 then allow access into the environment so this 00:19:03.500 --> 00:19:05.359 one is really wanted to pay attention to here 00:19:05.359 --> 00:19:07.640 and this is done in the teams admin center where 00:19:07.640 --> 00:19:12.480 you basically um disable uh you know um what 00:19:12.480 --> 00:19:14.500 we call unmanaged teams users i think they should 00:19:14.500 --> 00:19:17.099 there's some settings in there still and they'll 00:19:17.099 --> 00:19:18.660 probably start going away soon but there's some 00:19:18.660 --> 00:19:20.819 settings in there about skype users as well like 00:19:20.819 --> 00:19:22.740 you could you know we've been able to do this 00:19:22.740 --> 00:19:25.720 for ages where we disable um skype users from 00:19:25.720 --> 00:19:27.519 communicating to our to our team's environment 00:19:27.519 --> 00:19:30.259 i imagine now that skype is is officially dead 00:19:30.259 --> 00:19:34.180 uh that will go away in time but um this is now 00:19:34.180 --> 00:19:36.680 for you know the next evolution of that where 00:19:36.680 --> 00:19:39.039 you have these unmanaged teams users you don't 00:19:39.039 --> 00:19:41.789 want um users to be able to communicate there's 00:19:41.789 --> 00:19:43.390 another setting that is very similar which is 00:19:43.390 --> 00:19:46.710 allowing teams users or unmanaged users to actually 00:19:46.710 --> 00:19:50.869 initiate chats to to your uh you know your team's 00:19:50.869 --> 00:19:53.910 folks again really bad idea to allow that there's 00:19:53.910 --> 00:19:56.690 there should be no business specific scenario 00:19:56.690 --> 00:19:59.609 where where that is is something that you want 00:19:59.609 --> 00:20:01.890 to allow it really is just a risky risky proposition 00:20:02.960 --> 00:20:09.819 Yeah, it's frustrating sometimes for the user 00:20:09.819 --> 00:20:12.559 experience, obviously, as with all security measures, 00:20:12.680 --> 00:20:15.680 I think. It takes away a little bit of the ease 00:20:15.680 --> 00:20:21.960 of use and people started applying their work 00:20:21.960 --> 00:20:23.680 in a certain way with these applications and 00:20:23.680 --> 00:20:26.380 now we're locking things down and we also need 00:20:26.380 --> 00:20:29.880 to explain to them why we're doing this and they 00:20:29.880 --> 00:20:32.529 might get frustrated. Yeah. Now, the beauty about 00:20:32.529 --> 00:20:34.670 Teams is that it's such a great platform for 00:20:34.670 --> 00:20:37.589 development, right? You could build a workflow 00:20:37.589 --> 00:20:39.509 for these types of things where you can get users 00:20:39.509 --> 00:20:45.049 to request at a specific email domain or get 00:20:45.049 --> 00:20:48.509 added to the list, have that go to their manager 00:20:48.509 --> 00:20:50.849 for approval first before it hits IT so that 00:20:50.849 --> 00:20:53.130 you know that users aren't just requesting their 00:20:53.130 --> 00:20:56.809 girlfriend be added to the whatever or boyfriend 00:20:56.809 --> 00:21:00.299 or partner or what have you. there's a lot that 00:21:00.299 --> 00:21:02.880 you can do here um but it really from from a 00:21:02.880 --> 00:21:04.440 strategy perspective you want to just think this 00:21:04.440 --> 00:21:06.160 through and go well how much of a leakage problem 00:21:06.160 --> 00:21:09.180 is this if i'm just allowing any unmanaged environment 00:21:09.180 --> 00:21:11.140 to be to be talking so a lot of the things that 00:21:11.140 --> 00:21:14.500 i've talked about are specifically about uh you 00:21:14.500 --> 00:21:17.640 know around um or at least the last three are 00:21:17.640 --> 00:21:21.019 very much about protecting data your data within 00:21:21.019 --> 00:21:23.509 the organization from leaking out And it's a 00:21:23.509 --> 00:21:27.589 big problem because of how open M365 is as a 00:21:27.589 --> 00:21:30.450 platform. But as we're seeing with compliance 00:21:30.450 --> 00:21:33.890 and all of these sort of governance and things 00:21:33.890 --> 00:21:37.250 like that, it's very risky for us to just allow 00:21:37.250 --> 00:21:39.569 our data to flow anywhere without actually having 00:21:39.569 --> 00:21:42.910 protections on who can get to it. And this is 00:21:42.910 --> 00:21:45.849 really the very basic first step of what you 00:21:45.849 --> 00:21:49.130 can do to protect your data from being shared 00:21:49.130 --> 00:21:52.569 by accident. you know, or on purpose. Sometimes 00:21:52.569 --> 00:21:55.289 this stuff happens by accident, but really protect 00:21:55.289 --> 00:21:57.369 the data that you have. And then from here, you 00:21:57.369 --> 00:21:59.190 can obviously layer on Purview and all the other 00:21:59.190 --> 00:22:01.349 cool technologies that Microsoft have to protect 00:22:01.349 --> 00:22:04.349 it. But five things that you can do and I would 00:22:04.349 --> 00:22:08.710 say should be doing to harden your M365 environment. 00:22:09.250 --> 00:22:11.410 No additional licensing required for any of these. 00:22:11.490 --> 00:22:14.069 So you can take a look at these today and jump 00:22:14.069 --> 00:22:17.730 in and think about how you can restrict them. 00:22:17.769 --> 00:22:21.259 The steps are in the show notes. Nice one, Chris. 00:22:21.500 --> 00:22:26.339 Nice summary. So these items, will these pop 00:22:26.339 --> 00:22:30.160 up? You mentioned SIS earlier. Will these pop 00:22:30.160 --> 00:22:33.259 up as a recommendation from something like posture 00:22:33.259 --> 00:22:36.380 management or Defender for Cloud recommendations, 00:22:36.700 --> 00:22:38.519 something like that? Do you know that, perhaps? 00:22:38.859 --> 00:22:42.460 I don't know the answer to that. Yeah, because 00:22:42.460 --> 00:22:45.160 these are tenant -specific in M365. Yeah, that's 00:22:45.160 --> 00:22:48.430 true. that i'm not i'm not sure exactly it's 00:22:48.430 --> 00:22:50.289 it's possible though that if you run something 00:22:50.289 --> 00:22:53.210 like uh maester um it mayster is checking against 00:22:53.210 --> 00:22:56.809 the cis benchmarks that it may um uh it may call 00:22:56.809 --> 00:22:59.690 those out for you yeah yeah and i must admit 00:22:59.690 --> 00:23:04.190 i'm also guilty of uh using these features as 00:23:04.190 --> 00:23:06.529 a user because sometimes i was in a call with 00:23:06.529 --> 00:23:09.349 a third party vendor or supplier or whatever 00:23:10.109 --> 00:23:12.009 And I had a follow -up question and I just copy 00:23:12.009 --> 00:23:14.369 -paste their email address in Teams and reach 00:23:14.369 --> 00:23:17.450 out over chat and it's much easier than jumping 00:23:17.450 --> 00:23:21.329 a call and send them an email again. But yeah, 00:23:21.410 --> 00:23:24.349 I also understand why you probably want to avoid 00:23:24.349 --> 00:23:28.309 this. In my personal email account, which is 00:23:28.309 --> 00:23:33.069 not a corporate Entra tenant, but my email address 00:23:33.069 --> 00:23:35.809 is floating around for years, obviously in all 00:23:35.809 --> 00:23:40.620 kinds of ways. And now I also see... spammers 00:23:40.620 --> 00:23:43.400 requesting chat messages on my private email 00:23:43.400 --> 00:23:45.519 address and teams as well. So they're really 00:23:45.519 --> 00:23:48.779 abusing it that way. Yeah, definitely. Definitely. 00:23:49.700 --> 00:23:52.019 And, you know, like I said, I don't think it's 00:23:52.019 --> 00:23:54.400 a case of where you, I mean, you are taking it 00:23:54.400 --> 00:23:57.539 away, having it be open, but if you do it correctly 00:23:57.539 --> 00:24:00.380 in the scenario that you just described as well, 00:24:00.400 --> 00:24:01.859 where you have a vendor and you want to get back 00:24:01.859 --> 00:24:04.019 to the get a quote, you know, if that was going 00:24:04.019 --> 00:24:05.259 to be something that was going to happen more 00:24:05.259 --> 00:24:08.009 than once. Maybe you had a Microsoft form or 00:24:08.009 --> 00:24:09.509 something internally where you could request, 00:24:09.670 --> 00:24:13.690 hey, we're partnering with Vendor XYZ. It's really 00:24:13.690 --> 00:24:15.109 helpful for us to be able to communicate with 00:24:15.109 --> 00:24:18.289 them by teams. Can we add their domain? Because 00:24:18.289 --> 00:24:20.470 you know what I mean? And then at that point, 00:24:20.509 --> 00:24:22.390 you've got the convenience and the ease of use 00:24:22.390 --> 00:24:24.789 back, but you don't have that sort of openness, 00:24:24.930 --> 00:24:28.529 right? Which is what we're trying to avoid. Yeah, 00:24:28.630 --> 00:24:33.349 sounds good. Well, yeah, like you said, these 00:24:33.349 --> 00:24:36.049 are just five tips, but I can imagine you can 00:24:36.049 --> 00:24:39.509 generate a list of much more tips than these 00:24:39.509 --> 00:24:43.069 five. So we'll probably get back to some of these 00:24:43.069 --> 00:24:48.029 examples in later episodes. Absolutely. Yeah, 00:24:48.109 --> 00:24:52.789 SSR, Sentinel Summary Rules. What was the acronym 00:24:52.789 --> 00:24:57.710 again? Yeah, like I mentioned earlier, I touched 00:24:57.710 --> 00:25:01.890 on auxiliary and basic logs earlier in episode 00:25:01.890 --> 00:25:07.069 four. So Microsoft Sentinel as a product has 00:25:07.069 --> 00:25:13.619 perhaps a bad reputation being expensive. product, 00:25:13.759 --> 00:25:17.619 an expensive solution. And like I explained earlier, 00:25:17.859 --> 00:25:20.900 you pay for the amount of gigabytes you ingest 00:25:20.900 --> 00:25:24.180 in the product. And when people are starting 00:25:24.180 --> 00:25:27.279 using Sentinel as a SIEM as they were used to 00:25:27.279 --> 00:25:30.599 doing in the old days, they'll probably want 00:25:30.599 --> 00:25:33.720 to attach all kinds of network appliances and 00:25:33.720 --> 00:25:36.960 all kinds of noisy logs, sending out network 00:25:36.960 --> 00:25:40.779 traffic data as well. And then you can quite 00:25:40.779 --> 00:25:43.579 easily end up into the hundreds or even thousands 00:25:43.579 --> 00:25:46.960 of gigabytes a day. And then the cost will skyrocket 00:25:46.960 --> 00:25:53.569 as well. And Microsoft already took a nice step 00:25:53.569 --> 00:25:57.890 providing you with different table tiers. So 00:25:57.890 --> 00:26:00.490 you could create a basic or an auxiliary table 00:26:00.490 --> 00:26:04.650 for noisy logs, which are much and much cheaper. 00:26:05.029 --> 00:26:08.910 For example, the basic logs is about one eighth 00:26:08.910 --> 00:26:11.390 of the price of a default analytics table and 00:26:11.390 --> 00:26:14.509 auxiliary is about one fortieth of the price 00:26:14.509 --> 00:26:17.569 of an analytic table. So that's a real big difference. 00:26:18.799 --> 00:26:24.400 And even if larger enterprises have a very high 00:26:24.400 --> 00:26:28.200 commitment tier, so they commit upfront for a 00:26:28.200 --> 00:26:30.480 certain amount of data, they get a discount, 00:26:30.579 --> 00:26:33.019 right? And even with maximum discount, I think 00:26:33.019 --> 00:26:36.319 it's about 50 % something off. It's still 1 20th 00:26:36.319 --> 00:26:38.400 of the price. So auxiliary logs is really cheap. 00:26:38.519 --> 00:26:41.400 But one of the downsides is when you store logs 00:26:41.400 --> 00:26:45.039 in auxiliary tables, you can look back the data 00:26:45.039 --> 00:26:47.619 for 30 days. And after 30 days, you can store. 00:26:47.759 --> 00:26:52.339 it in an archive if you want. But one of the 00:26:52.339 --> 00:26:55.460 downsides of these cheaper storages is that you 00:26:55.460 --> 00:26:58.680 cannot trigger real -time security incidents 00:26:58.680 --> 00:27:01.480 on them. So within Sentinel, you can create analytic 00:27:01.480 --> 00:27:04.140 rules. And within an analytic rule, you put a 00:27:04.140 --> 00:27:07.519 KQL query in there. And if the results of that... 00:27:08.460 --> 00:27:12.420 KQL query match certain conditions you set up 00:27:12.420 --> 00:27:14.359 in the analytic rule, then it will trigger a 00:27:14.359 --> 00:27:17.059 security incident, right? But with basic and 00:27:17.059 --> 00:27:19.579 auxiliary, you cannot use those logs in analytic 00:27:19.579 --> 00:27:22.779 rules. So you cannot trigger real -time security 00:27:22.779 --> 00:27:26.279 incidents from them. And, well, that's why I 00:27:26.279 --> 00:27:29.099 mentioned Data Explorer earlier. So if you... 00:27:29.549 --> 00:27:32.109 cannot trigger any incidents on them you might 00:27:32.109 --> 00:27:34.569 as well store those logs outside of sentinel 00:27:34.569 --> 00:27:37.990 for cheaper storage and this was already a good 00:27:37.990 --> 00:27:40.809 idea before auxiliary logs came along but even 00:27:40.809 --> 00:27:44.950 with auxiliary logs you pay about 15 cents per 00:27:44.950 --> 00:27:48.130 gigabyte give or take depending on your region 00:27:48.130 --> 00:27:51.589 and currency and everything With Data Explorer, 00:27:51.849 --> 00:27:54.170 you can even go lower. But the thing is that 00:27:54.170 --> 00:27:56.329 you have to maintain a Data Explorer cluster 00:27:56.329 --> 00:27:59.089 and it might be a little bit daunting to set 00:27:59.089 --> 00:28:03.109 up at first. And there are also some downsides 00:28:03.109 --> 00:28:05.829 of splitting logs across multiple destinations 00:28:05.829 --> 00:28:09.670 if you want to find stuff, of course. So I think 00:28:09.670 --> 00:28:11.950 Microsoft is also acknowledging that and they 00:28:11.950 --> 00:28:15.009 want people to stay in Sentinel or perhaps even 00:28:15.009 --> 00:28:18.369 move back. And well, this was a very long segue 00:28:18.369 --> 00:28:20.829 into the introduction and why I think summary 00:28:20.829 --> 00:28:24.289 rules is so useful. So what is a summary rule? 00:28:24.430 --> 00:28:28.029 A summary rule is just like an analytic rule. 00:28:28.150 --> 00:28:31.410 You can create a summary rule in Sentinel and 00:28:31.410 --> 00:28:35.210 it's sort of a scheduled KQL query in the same 00:28:35.210 --> 00:28:37.970 sense as an analytic rule is. So you can set 00:28:37.970 --> 00:28:41.329 up a time period for a couple of hours or days 00:28:41.329 --> 00:28:45.940 or multiple days. That KQL query can query data 00:28:45.940 --> 00:28:49.200 in your basic and auxiliary tables. And the results 00:28:49.200 --> 00:28:52.380 of that query are actually stored in an analytic 00:28:52.380 --> 00:28:55.220 table, in a separate analytic table. And in the 00:28:55.220 --> 00:28:58.700 show notes, you'll find a simple diagram showing 00:28:58.700 --> 00:29:01.480 this. So the query is reaching out into the auxiliary 00:29:01.480 --> 00:29:04.259 table, let's say every hour, for example. And 00:29:04.259 --> 00:29:07.380 the results of that, an aggregated set of those 00:29:07.380 --> 00:29:10.079 results is stored in an analytic table. What 00:29:10.079 --> 00:29:12.700 you can do from there is you can trigger an analytic 00:29:12.700 --> 00:29:16.319 rule. triggering on the actual results of that 00:29:16.319 --> 00:29:19.359 summary rule, if you want. So why would you use 00:29:19.359 --> 00:29:23.839 this? So example scenarios could be, let's say 00:29:23.839 --> 00:29:27.319 you have that firewall log, firewall sending 00:29:27.319 --> 00:29:29.779 those logs, those network traffic logs to Sentinel. 00:29:30.119 --> 00:29:33.200 And if you send all the traffic logs to an analytic 00:29:33.200 --> 00:29:37.079 table, you can look for threat intelligence indicators, 00:29:37.240 --> 00:29:39.400 for example, like IP addresses, domain names, 00:29:39.579 --> 00:29:42.819 file hashes, whatnot. But the downside is that 00:29:42.819 --> 00:29:45.220 you have to ingest all of those massive amounts 00:29:45.220 --> 00:29:47.539 of traffic logs. You see every allow and block 00:29:47.539 --> 00:29:51.140 and everything you see coming by just to pick 00:29:51.140 --> 00:29:56.559 out those TI matches, right? So now when you 00:29:56.559 --> 00:29:59.900 send those logs to an auxiliary table, you can 00:29:59.900 --> 00:30:03.259 create a summary rule. Let's say look every hour 00:30:03.259 --> 00:30:06.299 and distinct a list of all the unique source 00:30:06.299 --> 00:30:08.579 or destination IP addresses that's coming by. 00:30:09.500 --> 00:30:13.640 So you're already bringing down hundreds of thousands 00:30:13.640 --> 00:30:19.460 of logs back down to much less rows, actually, 00:30:19.539 --> 00:30:22.480 and storing only those IP addresses as a result 00:30:22.480 --> 00:30:24.900 in a new auxiliary table with the summary rules. 00:30:25.099 --> 00:30:28.119 And then with an analytic rule, you can look 00:30:28.119 --> 00:30:34.740 for TI matches on that new analytics table containing 00:30:34.740 --> 00:30:37.599 all the unique IP addresses that came by through 00:30:37.599 --> 00:30:39.990 the firewall. This is one of the examples, of 00:30:39.990 --> 00:30:47.589 course. What you can also do with your security 00:30:47.589 --> 00:30:51.259 analysts are probably want to look up. data and 00:30:51.259 --> 00:30:55.039 as part of the triage so when they're investigating 00:30:55.039 --> 00:30:57.759 a security incident they probably want to know 00:30:57.759 --> 00:31:00.119 maybe when an incident arises from defender for 00:31:00.119 --> 00:31:02.759 endpoint or defender for office they want to 00:31:02.759 --> 00:31:05.480 know this ip address this is an ip address i 00:31:05.480 --> 00:31:08.000 want to know if this was seen by one of our firewalls 00:31:08.000 --> 00:31:12.160 for example If you have to sift through the network 00:31:12.160 --> 00:31:15.640 data, which is very noisy, queries might take 00:31:15.640 --> 00:31:19.779 long. They might exceed certain query limits 00:31:19.779 --> 00:31:22.759 because and have to sift through millions of 00:31:22.759 --> 00:31:25.380 rows to find a certain IP address. And again, 00:31:25.480 --> 00:31:28.059 if the analyst knows that we have an analytics 00:31:28.059 --> 00:31:31.460 table with only the results of an hourly summary 00:31:31.460 --> 00:31:34.799 rule, the stinking out all the unique IP addresses, 00:31:35.019 --> 00:31:37.099 they can look for it there and see when it was 00:31:37.099 --> 00:31:42.299 last seen, for example, where. It sounds it sounds 00:31:42.299 --> 00:31:45.880 like such an obvious. feature right but yeah 00:31:45.880 --> 00:31:48.339 but okay but i mean i can definitely see how 00:31:48.339 --> 00:31:50.420 this would make a lot of sense especially if 00:31:50.420 --> 00:31:54.400 you're trying to save on costs by by by not just 00:31:54.400 --> 00:31:59.440 ingesting and storing everything right yeah yeah 00:31:59.440 --> 00:32:02.519 indeed i think microsoft is seeing uh when they 00:32:02.519 --> 00:32:05.019 started with sentinel as a cloud native seam 00:32:05.019 --> 00:32:08.000 solutions uh what is it six years ago something 00:32:08.000 --> 00:32:11.579 um I think it's great that you don't have to 00:32:11.579 --> 00:32:14.359 pay upfront a certain amount as you need to do 00:32:14.359 --> 00:32:18.140 with something like Splunk or QRadar or ArcSight 00:32:18.140 --> 00:32:22.579 or something like that. You pay... On the go, 00:32:22.660 --> 00:32:25.779 pay as you go, like with many cloud resources. 00:32:26.319 --> 00:32:30.000 But I think they underestimated the way Siemens 00:32:30.000 --> 00:32:33.460 were used by customers. And, well, customers 00:32:33.460 --> 00:32:36.920 still want their data when they move to Sentinel, 00:32:37.039 --> 00:32:39.559 for example, in the same way they were used to. 00:32:40.059 --> 00:32:44.200 And it also doesn't benefit Microsoft when people 00:32:44.200 --> 00:32:47.859 are migrating away from Sentinel, storing the 00:32:47.859 --> 00:32:51.140 data elsewhere in Blob or ADX or Data Lake or 00:32:51.140 --> 00:32:53.480 whatever. However, also with their vision on 00:32:53.480 --> 00:32:57.940 AI, I think, so security co -pilot was not able 00:32:57.940 --> 00:33:00.740 to reach into data outside of Sentinel and Defender, 00:33:00.779 --> 00:33:04.500 for example. So this might also be a future thing 00:33:04.500 --> 00:33:12.609 to keep in mind. Yeah, and again, this is a great 00:33:12.609 --> 00:33:14.950 step in the right direction of increasing the 00:33:14.950 --> 00:33:18.569 usefulness of those cheaper storage tables. Because 00:33:18.569 --> 00:33:22.730 before this, I always said to a customer, you 00:33:22.730 --> 00:33:25.950 can use auxiliary logs if you have to keep the 00:33:25.950 --> 00:33:28.650 data somewhere, but remember all of the downsides 00:33:28.650 --> 00:33:31.150 with it. So if you just want to store it for 00:33:31.150 --> 00:33:33.269 the sake of storing it for compliance reasons, 00:33:33.430 --> 00:33:36.789 for example, that's fine. But finding anything 00:33:36.789 --> 00:33:40.660 in there, all especially with auxiliary logs 00:33:40.660 --> 00:33:44.619 because they're also a lot slower and it's also 00:33:44.619 --> 00:33:47.920 why you pay 1 40th of the price the usefulness 00:33:47.920 --> 00:33:50.079 goes down and with summary rules i think that's 00:33:50.079 --> 00:33:53.960 a great step i yeah i was going to say you know 00:33:53.960 --> 00:33:55.960 you had mentioned sorry you had mentioned before 00:33:55.960 --> 00:33:59.079 that as well customers were they're expecting 00:33:59.079 --> 00:34:01.619 what they had before but i think this the other 00:34:01.619 --> 00:34:04.559 challenge was for a lot of customers who who 00:34:04.559 --> 00:34:07.500 are this was their first step into the seam landscape 00:34:07.500 --> 00:34:10.440 right they they've never had one before so it's 00:34:10.440 --> 00:34:13.099 really difficult to predict what your ingestion 00:34:13.099 --> 00:34:15.519 size and volume is going to be like at that point, 00:34:15.619 --> 00:34:17.860 right? So, yeah, now I can see where you're going. 00:34:17.880 --> 00:34:22.059 Yeah, and I think Microsoft might want to warn 00:34:22.059 --> 00:34:25.400 people about it up front a bit better, I guess, 00:34:25.460 --> 00:34:27.760 because when you look at the cloud architecture 00:34:27.760 --> 00:34:33.400 reference documentation Microsoft put up, they 00:34:33.400 --> 00:34:36.179 update it every couple of months or every six 00:34:36.179 --> 00:34:38.219 months or something like that, so recently a 00:34:38.219 --> 00:34:41.199 new version of that was released, and Sentinel 00:34:41.199 --> 00:34:44.179 is They're still shown as a security data lake. 00:34:44.239 --> 00:34:47.760 And you see all kinds of network vendors, labels, 00:34:48.000 --> 00:34:50.539 logos pointing towards Sentinel. So Microsoft 00:34:50.539 --> 00:34:53.920 is really also advising you to do this. And it 00:34:53.920 --> 00:34:56.679 makes sense, of course. Again, for TI matching, 00:34:56.980 --> 00:35:00.780 for correlation with all the other Defender stuff. 00:35:00.940 --> 00:35:04.340 So now Sentinel is part of Defender XDR in the 00:35:04.340 --> 00:35:07.400 security portal. When, for example, a Palo Alto 00:35:07.400 --> 00:35:10.039 finds something suspicious about some kind of 00:35:10.039 --> 00:35:13.440 network traffic. and your user account or a certain 00:35:13.440 --> 00:35:16.239 IP address is attached to that alert, it also 00:35:16.239 --> 00:35:18.219 correlates with all the other Defender stuff. 00:35:18.579 --> 00:35:20.699 Defender for Office, Defender for Endpoint might 00:35:20.699 --> 00:35:23.239 also be seeing suspicious things around your 00:35:23.239 --> 00:35:25.980 account. And now those events can be correlated. 00:35:26.019 --> 00:35:31.519 So the usefulness is not up for debate. But costs 00:35:31.519 --> 00:35:35.599 was something that Sentinel became notorious 00:35:35.599 --> 00:35:40.460 about very quickly as well. And that is also 00:35:40.460 --> 00:35:47.460 why I want to put an exclamation mark on some 00:35:47.460 --> 00:35:50.460 things you still need to remember when it comes 00:35:50.460 --> 00:35:53.619 to cost and with summary rules. So a summary 00:35:53.619 --> 00:35:57.980 rule still has the same query limitation, timeout 00:35:57.980 --> 00:36:00.659 restraints and stuff like that. So you can still 00:36:00.659 --> 00:36:04.760 not... for example, store millions of rows in 00:36:04.760 --> 00:36:07.659 an auxiliary table and then create a KQL query, 00:36:07.940 --> 00:36:10.719 very complex, which would probably take an hour 00:36:10.719 --> 00:36:13.099 to complete to get the results and just dump 00:36:13.099 --> 00:36:16.260 that in a summary rule and expect proper results. 00:36:16.559 --> 00:36:19.239 The queries can still time out in that way. So 00:36:19.239 --> 00:36:22.039 you have to make your timeframe shorter. Microsoft 00:36:22.039 --> 00:36:24.360 also reminds you when you create a summary rule 00:36:24.360 --> 00:36:28.280 and you do not include some kind of aggregator. 00:36:28.360 --> 00:36:31.070 So like summarize, for example, summarize. function 00:36:31.070 --> 00:36:34.010 in KQL, when you leave that out, you get an exclamation 00:36:34.010 --> 00:36:36.489 mark telling you that you probably want to summarize 00:36:36.489 --> 00:36:39.750 things. Hence the name summary rules, of course, 00:36:39.769 --> 00:36:42.130 because otherwise you're just dumping the same 00:36:42.130 --> 00:36:45.269 result, a large data set into a new table and 00:36:45.269 --> 00:36:48.449 you're duplicating data. And that's probably 00:36:48.449 --> 00:36:52.469 not what you're after. And to keep an eye on 00:36:52.469 --> 00:36:54.510 that, when you create a summary rule, Microsoft 00:36:54.510 --> 00:36:58.389 also warns you to enable diagnostics on summary 00:36:58.389 --> 00:37:01.929 rule. And this is a new diagnostic setting for 00:37:01.929 --> 00:37:05.670 log analytics, actually. So we all know the diagnostic 00:37:05.670 --> 00:37:07.909 settings in all kinds of Azure cloud resources. 00:37:08.409 --> 00:37:11.150 Now there's also a new checkbox for summary rules 00:37:11.150 --> 00:37:14.989 you can enable. And you're warned of this when 00:37:14.989 --> 00:37:18.010 you have not set this up before when you create 00:37:18.010 --> 00:37:22.340 a new summary rule. summary rules is then stored 00:37:22.340 --> 00:37:25.559 into a log analytics or blob storage, of course. 00:37:25.719 --> 00:37:29.099 I put in the show notes a KQL query where you 00:37:29.099 --> 00:37:32.719 can query the LA summary logs table, this log 00:37:32.719 --> 00:37:36.139 analytics summary rules results, where you can 00:37:36.139 --> 00:37:39.340 look for events which did not succeed or did 00:37:39.340 --> 00:37:41.460 not start properly, for example, because there 00:37:41.460 --> 00:37:43.639 were some issues. So something to keep an eye 00:37:43.639 --> 00:37:46.639 on. It's not set and forget. So keep an eye on 00:37:46.639 --> 00:37:54.570 those summary rules. Currently, you can only 00:37:54.570 --> 00:37:58.130 create up to 20 summary rules. I know customers 00:37:58.130 --> 00:38:01.769 already wanting more than those 20, especially 00:38:01.769 --> 00:38:04.030 when they have multiple different vendors, for 00:38:04.030 --> 00:38:07.409 example, like FortiAnalyzer, Palo Alto, Checkpoint, 00:38:07.510 --> 00:38:11.159 all kinds of different vendors. different destination 00:38:11.159 --> 00:38:14.019 tables, so they probably need different parsers 00:38:14.019 --> 00:38:16.159 and different summary rules for those because 00:38:16.159 --> 00:38:19.260 not everybody aligns them perfectly with the 00:38:19.260 --> 00:38:22.480 same column names, et cetera. So larger customers 00:38:22.480 --> 00:38:25.099 are already wanting more than 20. And I know 00:38:25.099 --> 00:38:28.619 from experience that when you request microsoft 00:38:28.619 --> 00:38:32.079 to get more than 20 summary rules you will get 00:38:32.079 --> 00:38:34.460 those so they have they will make an exception 00:38:34.460 --> 00:38:37.159 right now you have to go through support requests 00:38:37.159 --> 00:38:40.360 to to get that increased but but it's possible 00:38:40.360 --> 00:38:45.420 that's a good um yeah and one uh one thing that's 00:38:45.420 --> 00:38:49.199 a bit weird with the permission stuff so as we 00:38:49.199 --> 00:38:52.889 know sentinel is built on log analytics which 00:38:52.889 --> 00:38:58.050 is around much longer. When I see the RBAC permissions 00:38:58.050 --> 00:39:01.510 being applied to Sentinel, the security analysts 00:39:01.510 --> 00:39:03.670 normally get something like Sentinel incident 00:39:03.670 --> 00:39:06.650 responder role or something like that. Maybe 00:39:06.650 --> 00:39:09.409 even Sentinel contributor, so they can manipulate 00:39:09.409 --> 00:39:12.010 stuff on the Sentinel part, like watch lists, 00:39:12.150 --> 00:39:15.650 analytic rules, summary rules in this case. But 00:39:15.650 --> 00:39:17.949 like I mentioned, the summary rule is depending 00:39:17.949 --> 00:39:21.150 on a destination table to store its results. 00:39:21.369 --> 00:39:23.630 So as part of the creation of a summary rule, 00:39:23.829 --> 00:39:27.570 you provide a existing or a new table where it 00:39:27.570 --> 00:39:31.280 can store the output. What's weird is to create 00:39:31.280 --> 00:39:34.360 a new table, you need at least to have log analytics 00:39:34.360 --> 00:39:37.739 contributor role on the workspace. So if you're 00:39:37.739 --> 00:39:40.639 a Sentinel contributor, you can technically create 00:39:40.639 --> 00:39:43.699 a summary rule, but if you want to point to a 00:39:43.699 --> 00:39:46.639 new table, it will fail because on the water, 00:39:46.719 --> 00:39:49.260 the destination table gets created as well, and 00:39:49.260 --> 00:39:52.179 you get a failure. So also take this into account 00:39:52.179 --> 00:39:55.039 when you're using SIEM as a code deployments, 00:39:55.119 --> 00:39:58.500 which I'm really into. So when you have Sentinels... 00:39:58.730 --> 00:40:00.630 of your infrastructure's code deployment including 00:40:00.630 --> 00:40:03.610 the analytic rules the watch lifts summary rules 00:40:03.610 --> 00:40:06.809 you cannot just push out a summary rule in an 00:40:06.809 --> 00:40:09.289 arm or a bicep template you also need to create 00:40:09.289 --> 00:40:12.530 the matching destination table as well with the 00:40:12.530 --> 00:40:15.150 proper schema which you're going to use to store 00:40:15.150 --> 00:40:20.570 the results in so this was a very quick sum up 00:40:20.570 --> 00:40:26.070 of summary rules I provided in the show notes 00:40:26.070 --> 00:40:29.150 a couple of examples and also links to Microsoft 00:40:29.150 --> 00:40:32.949 Learn page, but also there are a couple of Microsoft 00:40:32.949 --> 00:40:37.030 MVPs specifically want to reach out to Bertjan 00:40:37.030 --> 00:40:40.170 Pals. He's Dutch, of course, Chris. You know 00:40:40.170 --> 00:40:42.789 what they say about the security MVP. That's 00:40:42.789 --> 00:40:47.860 right. But he wrote a nice blog with also some 00:40:47.860 --> 00:40:51.579 example scenarios with some useful tips and tricks 00:40:51.579 --> 00:40:55.739 you can use. Yeah, so that was summary rules 00:40:55.739 --> 00:41:00.000 for today's episode. That's awesome. I'll have 00:41:00.000 --> 00:41:03.099 you take a... a sip of water there or what have 00:41:03.099 --> 00:41:05.539 you because uh before you tell us about our community 00:41:05.539 --> 00:41:07.800 project for this uh for this month which i hope 00:41:07.800 --> 00:41:10.340 it wasn't a monologue okay chris sorry for that 00:41:10.340 --> 00:41:12.840 no it definitely wasn't but uh hey i figured 00:41:12.840 --> 00:41:14.980 you might you might want to a quick drink before 00:41:14.980 --> 00:41:17.360 we would jump into the the community project 00:41:17.360 --> 00:41:21.969 um yeah yeah mdu automator Yeah, and the Automator 00:41:21.969 --> 00:41:25.630 was created by a Microsoft MVP called Eric Mannen. 00:41:26.090 --> 00:41:28.809 I always read it like, because I'm European, 00:41:29.050 --> 00:41:31.389 I read it like it's a French name. So I would 00:41:31.389 --> 00:41:35.079 say... Eric Manon, but that's probably not the 00:41:35.079 --> 00:41:36.940 way how I should pronounce it because he's from 00:41:36.940 --> 00:41:42.599 the US. So Eric Manon created a very nice, elaborate 00:41:42.599 --> 00:41:47.440 toolkit for Defender for Endpoint. Part of that 00:41:47.440 --> 00:41:52.199 toolkit is a PowerShell module, which can help 00:41:52.199 --> 00:41:58.719 with all kinds of day -to -day tasks as a SOC 00:41:58.719 --> 00:42:02.030 analyst in the Microsoft space. He has a lot 00:42:02.030 --> 00:42:07.849 of experience in the SecOps area, and he was 00:42:07.849 --> 00:42:12.130 frustrated with all kinds of daily actions he 00:42:12.130 --> 00:42:16.650 wanted to automate and run regularly. So we created 00:42:16.650 --> 00:42:19.789 this PowerShell module NDE Automator. You can 00:42:19.789 --> 00:42:23.730 find it in the PowerShell gallery as well. Instructions 00:42:23.730 --> 00:42:26.150 are in the show notes again. And from there, 00:42:26.210 --> 00:42:29.570 for example, you could push profiles at multiple 00:42:30.670 --> 00:42:35.190 devices at once or pull in investigation packages 00:42:35.190 --> 00:42:39.250 for devices, et cetera. And as part of the package, 00:42:39.409 --> 00:42:42.409 he also created some Azure functions also built 00:42:42.409 --> 00:42:46.610 on PowerShell with the same module to orchestrate 00:42:46.610 --> 00:42:49.289 and automate a lot of these steps, if you will. 00:42:49.429 --> 00:42:52.829 And I would definitely advise to check it out 00:42:52.829 --> 00:42:56.150 and also give him a follow on LinkedIn. Because 00:42:56.150 --> 00:42:59.230 of his experience, he not only has some useful 00:42:59.230 --> 00:43:03.260 insights. for incident response challenges for 00:43:03.260 --> 00:43:05.900 SIEM and Microsoft security products in general. 00:43:06.139 --> 00:43:08.760 But his posts are also very enjoyable to read 00:43:08.760 --> 00:43:12.739 and also funny to read. He's an even bigger fan 00:43:12.739 --> 00:43:16.440 of the Big Lebowski, I guess, as I am, because 00:43:16.440 --> 00:43:19.300 he's always using references with Big Lebowski. 00:43:19.500 --> 00:43:22.599 And I think his profile picture is even a picture 00:43:22.599 --> 00:43:27.219 of Jeff Bridges as the dude. But he has some 00:43:27.219 --> 00:43:31.460 funny comments. comments with some very useful 00:43:31.460 --> 00:43:33.880 insights. So definitely give him a follow and 00:43:33.880 --> 00:43:37.340 check out his project MDE Automator on GitHub. 00:43:37.900 --> 00:43:40.980 This is very cool. I don't really do a lot of 00:43:40.980 --> 00:43:44.920 work in the sort of day -to -day or SecOps space, 00:43:45.059 --> 00:43:47.699 right? My work is a lot, especially with sort 00:43:47.699 --> 00:43:50.599 of something like MDE, is usually around the 00:43:50.599 --> 00:43:54.230 onboarding. this is cool i really like the look 00:43:54.230 --> 00:43:56.210 of it as well it's got a really really cool interface 00:43:56.210 --> 00:44:00.670 so yeah very very nice apis for a lot of this 00:44:00.670 --> 00:44:03.949 stuff like uh retrieving an investigation package 00:44:03.949 --> 00:44:07.210 from a design from a device or initiating a live 00:44:07.210 --> 00:44:09.769 response session to get into the command line 00:44:09.769 --> 00:44:13.469 on the destination device but um when you have 00:44:13.469 --> 00:44:15.690 a powershell module it's so much easier and and 00:44:15.690 --> 00:44:19.510 i all i agree with eric um i'm i'm not a huge 00:44:19.510 --> 00:44:22.420 developer per se i also like PowerShell modules 00:44:22.420 --> 00:44:26.639 over constructing my own HTTP requests with proper 00:44:26.639 --> 00:44:30.340 headers and authentication, etc. But Microsoft 00:44:30.340 --> 00:44:33.780 seems to be moving away a bit from PowerShell 00:44:33.780 --> 00:44:36.539 modules and letting you create your own stuff 00:44:36.539 --> 00:44:38.960 because they have the APIs in place and they 00:44:38.960 --> 00:44:42.179 just say, well, go figure out the API. A little 00:44:42.179 --> 00:44:43.739 bit the same with a lot of graph operations, 00:44:43.940 --> 00:44:48.780 right? Yeah, you're right. But yeah, hey, I love 00:44:48.780 --> 00:44:51.250 PowerShell, so it's... It's always a good challenge, 00:44:51.349 --> 00:44:53.269 but this looks very, very cool. So yeah, thanks 00:44:53.269 --> 00:44:55.369 for bringing this one to everyone's attention. 00:44:55.650 --> 00:44:59.150 It's very cool. Yeah, welcome. Yeah, and check 00:44:59.150 --> 00:45:06.889 it out. So you've got Experts Live coming up 00:45:06.889 --> 00:45:08.730 soon. And I guess as we're recording this, it'll 00:45:08.730 --> 00:45:11.349 be next week. But we're not sure when the episode 00:45:11.349 --> 00:45:13.869 will actually land. It may actually be next week. 00:45:14.309 --> 00:45:18.469 But yeah, coming days, you'll be getting ready 00:45:18.469 --> 00:45:21.579 for your talk at Experts Live. Yeah, June 3rd. 00:45:22.079 --> 00:45:26.500 I'm going to talk about Sentinel again. My session 00:45:26.500 --> 00:45:28.860 is called Getting the Most Bang for Your Logs. 00:45:28.860 --> 00:45:32.460 Sentinel tips you can't afford to miss. So you 00:45:32.460 --> 00:45:34.940 have to put a pun in your title nowadays to get 00:45:34.940 --> 00:45:36.320 noticed. I've seen some of the movie posters 00:45:36.320 --> 00:45:38.300 you created for that. And so they're all very, 00:45:38.360 --> 00:45:41.559 very good. Very, very good. Yeah, well, I like 00:45:41.559 --> 00:45:44.599 to put some pop culture references or something 00:45:44.599 --> 00:45:48.719 like that. to stand out in a way. And I hope 00:45:48.719 --> 00:45:53.440 people memorize the stuff I talk about more easily. 00:45:53.559 --> 00:45:56.420 But yeah, a lot of Sentinel tips. Summary rules 00:45:56.420 --> 00:45:59.920 is also being demoed and explained in depth there 00:45:59.920 --> 00:46:02.699 and shown in depth. And I also have a lot of 00:46:02.699 --> 00:46:05.960 other practical tips on cost management, monitoring 00:46:05.960 --> 00:46:09.400 your costs. making sure that you're getting notified 00:46:09.400 --> 00:46:12.519 whenever the costs rise or dip below certain 00:46:12.519 --> 00:46:14.920 thresholds, for example. So yeah, that's June 00:46:14.920 --> 00:46:17.659 3rd. Looking forward to that. Very cool. And 00:46:17.659 --> 00:46:19.300 I'm sure you'll be able to share all that stuff 00:46:19.300 --> 00:46:22.760 once you've presented it all. So let's just follow 00:46:22.760 --> 00:46:24.739 Kost and I'm sure you'll see all the goodies. 00:46:25.059 --> 00:46:27.760 So good luck, Kost, with that. Hopefully it all 00:46:27.760 --> 00:46:30.920 goes well and have a great time at the conference. 00:46:32.460 --> 00:46:34.019 Definitely look forward to catching up again 00:46:34.019 --> 00:46:37.320 for another episode in three, four weeks' time, 00:46:37.400 --> 00:46:41.039 I guess. Yeah. Thank you very much for your time. 00:46:41.039 --> 00:46:43.679 It needs recording due to my holiday, but we'll 00:46:43.679 --> 00:46:47.019 edit this one soon and get it up at the beginning 00:46:47.019 --> 00:46:50.000 of June, and we'll see each other and the listeners 00:46:50.000 --> 00:46:53.300 back in July again. That's right. For our eighth 00:46:53.300 --> 00:46:56.340 episode already, Chris. Time flies. Time flies 00:46:56.340 --> 00:46:59.300 when you're having fun. As always, folks, thank 00:46:59.300 --> 00:47:01.719 you very much for listening. Please feel free 00:47:01.719 --> 00:47:04.099 to like and subscribe. That really does help 00:47:04.099 --> 00:47:06.480 us out a lot. Also, feel free to reach out to 00:47:06.480 --> 00:47:07.840 us if there's anything you really want to know 00:47:07.840 --> 00:47:10.380 about or something you'd like us to cover on 00:47:10.380 --> 00:47:13.860 the show. Please do let us know and we'll do 00:47:13.860 --> 00:47:16.239 our best to facilitate that for you. Yes, please 00:47:16.239 --> 00:47:18.920 do that. Until then, Kost, have a great weekend. 00:47:19.079 --> 00:47:21.239 We'll chat to you again. And everyone else, take 00:47:21.239 --> 00:47:23.780 care and see you in the next one. Thanks for 00:47:23.780 --> 00:47:24.900 listening, everybody. Bye -bye.