Episode 383 – Securing Azure: Monitoring and observing your Azure estate

August 29, 2024

Episode Transcript

Welcome to Episode 383 of the Microsoft Cloud IT Pro Podcast. In this episode we continue our discussion on security, transitioning from Microsoft 365 to Azure (Episode 382 – Securing the Modern Workplace: Exploring Microsoft Entra ID Security Defaults, Conditional Access Policies, and Microsoft Secure Score) to Microsoft Azure. We begin with Azure security logging and auditing, discussing the importance of capturing and analyzing security logs to detect and respond to potential threats. Next, we delve into Azure Monitor data sources and data collection methods. Azure Monitor provides a comprehensive set of tools to collect, analyze, and act on telemetry data from your cloud and on-premises environments. Finally, we discuss how the components of Azure Monitor can be used for managing and analyzing the vast amounts of data generated in your Azure environment. We’ll explore how this platform supports advanced analytics, helps you identify trends and anomalies, and enables proactive threat detection.

Whether you’re a cloud architect, security professional, or IT admin, this episode offers practical advice and strategies for leveraging observability to enhance your security posture in Azure. Tune in to discover how you can better protect your organization by implementing effective observability practices.

Like what you hear and want to support the show? Check out our membership options.

Show Notes

About the sponsors

Would you like to become the irreplaceable Microsoft 365 resource for your organization? Let us know!

See full episode transcriptTranscript is autogenerated by AI

1 00:00:03,600 --> 00:00:04,740 Welcome to episode 2 00:00:05,200 --> 00:00:05,700 383 3 00:00:06,000 --> 00:00:09,139 of the Microsoft Cloud IT Pro podcast recorded 4 00:00:09,199 --> 00:00:11,219 live on August 23, 2024. 5 00:00:11,919 --> 00:00:14,474 This is a show about Microsoft 360 5 6 00:00:14,474 --> 00:00:16,795 and Azure from the perspective of IT pros 7 00:00:16,795 --> 00:00:19,114 and end users, where we discuss a topic 8 00:00:19,114 --> 00:00:21,114 or recent news and how it relates to 9 00:00:21,114 --> 00:00:24,074 you. In this episode, we continue our discussion 10 00:00:24,074 --> 00:00:24,814 on security 11 00:00:25,195 --> 00:00:28,574 as we transition from Microsoft 365 to Azure. 12 00:00:28,794 --> 00:00:31,370 We kick things off with Azure Security Logging 13 00:00:31,370 --> 00:00:34,409 and Auditing before moving into Azure Monitor for 14 00:00:34,409 --> 00:00:37,770 collecting, analyzing, and acting on telemetry data. We 15 00:00:37,770 --> 00:00:40,109 also explore how it can help you identify 16 00:00:40,329 --> 00:00:41,469 trends and anomalies 17 00:00:41,850 --> 00:00:43,630 to help with your threat detection. 18 00:00:46,085 --> 00:00:48,965 We got the Logitech MX keyboard, the MX 19 00:00:48,965 --> 00:00:50,804 mini. Are you enjoying it? I don't know. 20 00:00:50,804 --> 00:00:53,045 I have a problem. Sound very clicky clacky. 21 00:00:53,045 --> 00:00:55,045 It's not clicky. It is definitely not a 22 00:00:55,045 --> 00:00:55,945 clicky keyboard. 23 00:00:56,340 --> 00:00:57,559 It is better than 24 00:00:57,939 --> 00:01:00,579 the macOS keyboard except that it doesn't have 25 00:01:00,579 --> 00:01:03,079 my fingerprint reader. I do like the fingerprint 26 00:01:03,140 --> 00:01:04,119 reader on 27 00:01:04,500 --> 00:01:06,659 my Mac keyboard. Like, they need to just 28 00:01:06,659 --> 00:01:09,459 sell a standalone fingerprint reader for logging in 29 00:01:09,459 --> 00:01:10,680 to, like, desktops. 30 00:01:11,060 --> 00:01:13,754 I too wish they would get there. But 31 00:01:13,754 --> 00:01:14,494 it's backlit, 32 00:01:14,795 --> 00:01:17,534 but it's definitely not like a NuPhy or 33 00:01:17,754 --> 00:01:21,354 a Keychron or a Clicky Mechanical. It's yeah. 34 00:01:21,354 --> 00:01:23,454 I would say it's a little bit more 35 00:01:23,674 --> 00:01:24,174 tactile 36 00:01:24,555 --> 00:01:27,069 than, like, the macOS keyboard, Little bit more 37 00:01:27,069 --> 00:01:27,890 key travel, 38 00:01:28,189 --> 00:01:30,989 but not a mechanical keyboard. So if you 39 00:01:30,989 --> 00:01:32,129 like backlit 40 00:01:32,510 --> 00:01:34,989 macOS keyboards that are not, I would say 41 00:01:34,989 --> 00:01:36,909 better, and if you want space gray, they 42 00:01:36,909 --> 00:01:39,170 do not sell a space gray 43 00:01:39,549 --> 00:01:42,194 mini I don't want the number pad. They 44 00:01:42,194 --> 00:01:43,634 don't sell a space gray one without the 45 00:01:43,634 --> 00:01:45,555 number pad. They only sell white. They don't 46 00:01:45,555 --> 00:01:46,834 have a black one with the number pad? 47 00:01:46,834 --> 00:01:48,194 They have a black one with the number 48 00:01:48,194 --> 00:01:50,114 pad, not a black one without the number 49 00:01:50,114 --> 00:01:52,674 pad. Go figure. Baby will get one in 50 00:01:52,674 --> 00:01:54,994 September. Only pros use number pads. That's your 51 00:01:54,994 --> 00:01:56,719 problem. You you gotta upgrade. You gotta be 52 00:01:56,719 --> 00:01:59,040 more you gotta put more pro in the 53 00:01:59,040 --> 00:01:59,540 pro 54 00:02:00,079 --> 00:02:01,520 of Apple Pro. Joshua Sharfstein: What do I 55 00:02:01,520 --> 00:02:03,040 need a number pad for? Joshua Sharfstein: What 56 00:02:03,040 --> 00:02:04,719 don't you need a number pad for? It's 57 00:02:04,719 --> 00:02:06,420 there to like mishmash navigate. 58 00:02:06,880 --> 00:02:09,194 Turn it into like hot keys so that 59 00:02:09,194 --> 00:02:11,194 you can do, like, window management or something 60 00:02:11,194 --> 00:02:12,715 with it. When I hit 1, it goes 61 00:02:12,715 --> 00:02:14,555 to lower quarter. When I hit 9, it 62 00:02:14,555 --> 00:02:16,235 goes to the upper right quarter. No. That's 63 00:02:16,235 --> 00:02:17,854 what keyboard shortcuts are for. 64 00:02:18,314 --> 00:02:20,394 I'm telling you. Who needs extra keys when 65 00:02:20,394 --> 00:02:22,699 I can push 5 keys at the same 66 00:02:22,699 --> 00:02:23,199 time? 67 00:02:24,219 --> 00:02:25,120 Use the numbers 68 00:02:25,419 --> 00:02:26,319 as a 69 00:02:26,699 --> 00:02:29,099 macro pad, and you'll be okay. That's what 70 00:02:29,099 --> 00:02:30,699 my stream deck is for, and it gets 71 00:02:30,699 --> 00:02:32,299 in the way of my mouse. Oh my 72 00:02:32,299 --> 00:02:34,699 goodness. Okay. Today. Yes. Real quick before we 73 00:02:34,699 --> 00:02:36,865 do that. I should be recording the correct 74 00:02:36,925 --> 00:02:38,685 mic. Do I not sound like I'm on 75 00:02:38,685 --> 00:02:40,205 the right mic to you? No. You're not. 76 00:02:40,205 --> 00:02:42,605 Really? Yeah. I blame Teams. I have an 77 00:02:42,605 --> 00:02:45,165 issue with Teams, though we're not getting into 78 00:02:45,165 --> 00:02:46,145 the topic today. 79 00:02:47,085 --> 00:02:49,270 It has to do with its ability to 80 00:02:49,270 --> 00:02:51,189 select the right audio device even though the 81 00:02:51,189 --> 00:02:53,509 right audio device is selected. That's the Teams 82 00:02:53,509 --> 00:02:56,469 audio driver, Core Audio d. Horrible name because 83 00:02:56,469 --> 00:02:58,789 it's not actually Core Audio for, like, the 84 00:02:58,789 --> 00:03:01,030 system, but they named their audio driver Core 85 00:03:01,030 --> 00:03:02,814 Audio d for Teams, which is like, 86 00:03:03,254 --> 00:03:05,414 I don't know why you have a daemon 87 00:03:05,414 --> 00:03:07,094 with the same name as the other daemon 88 00:03:07,094 --> 00:03:09,094 that does the thing and Microsoft got a 89 00:03:09,094 --> 00:03:11,334 Microsoft. But let's just talk about other ways 90 00:03:11,334 --> 00:03:13,254 that Microsoft is gonna Microsoft. I don't know 91 00:03:13,254 --> 00:03:15,914 what other ways Microsoft will Microsoft. Loop 2.0 92 00:03:15,974 --> 00:03:17,909 is out. That still doesn't allow you to 93 00:03:17,909 --> 00:03:18,409 secure 94 00:03:18,949 --> 00:03:22,090 a workspace with any form of group whatsoever. 95 00:03:24,389 --> 00:03:26,330 You're asking the wrong questions. 96 00:03:27,110 --> 00:03:28,995 The question isn't, can I secure it with 97 00:03:28,995 --> 00:03:30,914 a group? It's, why would I ever wanna 98 00:03:30,914 --> 00:03:32,754 do that? And then once you get over 99 00:03:32,754 --> 00:03:33,474 the hump of, 100 00:03:34,194 --> 00:03:36,914 you can't, you'll find another way through. Yes. 101 00:03:36,914 --> 00:03:38,275 You know what my other way through is 102 00:03:38,275 --> 00:03:40,194 gonna be? I'm gonna go create an Azure 103 00:03:40,194 --> 00:03:42,775 Automation runbook that loops through all of my 104 00:03:43,080 --> 00:03:46,039 teams or my groups, my Microsoft 365 security 105 00:03:46,039 --> 00:03:48,060 groups. So when to look at the name, 106 00:03:48,120 --> 00:03:50,219 it's going to create a corresponding workspace 107 00:03:50,599 --> 00:03:52,840 and loop, it is then going to iterate 108 00:03:52,840 --> 00:03:56,525 through every member in my group, compare it 109 00:03:56,525 --> 00:03:58,544 with every member of my workspace, 110 00:03:59,164 --> 00:04:01,824 and then add or remove users appropriately 111 00:04:02,125 --> 00:04:02,625 running 112 00:04:03,084 --> 00:04:05,664 every 10 minutes in an Azure automation 113 00:04:06,205 --> 00:04:08,844 runbook. No. I'm not gonna do that. Super 114 00:04:08,844 --> 00:04:11,790 easy. Barely an inquiry. Workspaces should be securable 115 00:04:11,849 --> 00:04:13,389 by group. End of 116 00:04:13,689 --> 00:04:14,189 story. 117 00:04:14,490 --> 00:04:16,810 Especially given that there are now notes for 118 00:04:16,810 --> 00:04:18,649 Teams meetings. If I'm gonna do a Teams 119 00:04:18,649 --> 00:04:21,529 meeting and my meeting notes are going into 120 00:04:21,529 --> 00:04:22,670 a loop component, 121 00:04:23,129 --> 00:04:24,110 said loop component 122 00:04:24,464 --> 00:04:26,384 1 should be able to be assigned to 123 00:04:26,384 --> 00:04:26,964 a workspace 124 00:04:27,584 --> 00:04:29,904 so that said meeting notes can be in 125 00:04:29,904 --> 00:04:32,305 the same workspace with all my other loop 126 00:04:32,305 --> 00:04:33,444 things for 127 00:04:33,824 --> 00:04:36,540 said client. It means the way channels work 128 00:04:36,620 --> 00:04:38,540 and they can aggregate meetings and you can 129 00:04:38,540 --> 00:04:40,300 have multiple meetings in a channel, but it's 130 00:04:40,300 --> 00:04:41,899 technically still all in the same team and 131 00:04:41,899 --> 00:04:43,020 still Yes. Joshua Sharfstein: still in the same 132 00:04:43,020 --> 00:04:44,379 channel? Wouldn't that make sense? Joshua Sharfstein: And 133 00:04:44,379 --> 00:04:47,020 then secured by the same group security group, 134 00:04:47,020 --> 00:04:48,779 yes. Joshua Sharfstein: You tried to tell them 135 00:04:48,779 --> 00:04:50,220 how to fix the problem, not that it 136 00:04:50,220 --> 00:04:52,154 was actually going to be fixed, but let 137 00:04:52,154 --> 00:04:53,675 let me know how much your Azure automation 138 00:04:53,675 --> 00:04:55,294 costs you to run every 10 minutes. 139 00:04:55,995 --> 00:04:57,514 I think I can get it in for 140 00:04:57,514 --> 00:04:59,774 free. I figured out the math ones. 500 141 00:05:00,154 --> 00:05:02,394 minutes, if it runs for 1 minute, I 142 00:05:02,394 --> 00:05:04,074 can run it how many times a day. 143 00:05:04,074 --> 00:05:05,354 We're gonna have to figure that out as 144 00:05:05,354 --> 00:05:05,854 Copilot. 145 00:05:06,209 --> 00:05:08,930 So have you no. You're Scott, I've been 146 00:05:08,930 --> 00:05:11,170 up since 3 AM teaching, and I warned 147 00:05:11,170 --> 00:05:12,769 you I'm gonna be all over the place. 148 00:05:12,769 --> 00:05:14,129 I keep trying to get you back into 149 00:05:14,129 --> 00:05:16,449 it. Thoroughly enjoying this. Back on topic. So 150 00:05:16,449 --> 00:05:18,790 back on topic, we chatted in the past 151 00:05:18,930 --> 00:05:19,430 about 152 00:05:20,324 --> 00:05:23,044 security, and we started getting into securing the 153 00:05:23,044 --> 00:05:24,664 modern workplace through 154 00:05:25,125 --> 00:05:26,425 the lens of 155 00:05:26,725 --> 00:05:29,384 identity and things that are available within 156 00:05:29,925 --> 00:05:32,724 intra ID. So we talked about things like 157 00:05:32,724 --> 00:05:35,144 security baselines for identity within 158 00:05:35,800 --> 00:05:38,759 intra and conditional access and some other stuff, 159 00:05:38,759 --> 00:05:41,419 and that kinda naturally leads into a conversation, 160 00:05:41,560 --> 00:05:43,579 which we had last time, about 161 00:05:44,519 --> 00:05:48,199 Microsoft 65 Office 365 workloads. Just because you're 162 00:05:48,199 --> 00:05:50,120 in that identity space, you're all tied in, 163 00:05:50,120 --> 00:05:51,615 you're already in SaaS 164 00:05:53,034 --> 00:05:54,875 land, and in that software as a service 165 00:05:54,875 --> 00:05:57,935 land. So you've got identity as a service, 166 00:05:57,995 --> 00:06:00,154 and you have software as a service things 167 00:06:00,154 --> 00:06:01,534 that exist out there 168 00:06:01,834 --> 00:06:02,334 like 169 00:06:02,714 --> 00:06:05,454 SharePoint Online and Exchange Online that are dependent 170 00:06:05,514 --> 00:06:07,470 on this identity as a service in the 171 00:06:07,470 --> 00:06:08,610 form of IntraID. 172 00:06:09,470 --> 00:06:12,110 The other thing that IntraID governs and becomes 173 00:06:12,110 --> 00:06:15,089 the identity store for is also Azure. 174 00:06:15,709 --> 00:06:18,689 So we should really talk about the Azure 175 00:06:18,750 --> 00:06:20,050 side of the conversation, 176 00:06:20,805 --> 00:06:23,365 which isn't going to be constrained so much 177 00:06:23,365 --> 00:06:25,685 to identity. Identity is a component about it. 178 00:06:25,685 --> 00:06:28,725 Right? So, like, something for conditional access, the 179 00:06:28,725 --> 00:06:31,144 way conditional access can apply to 180 00:06:32,004 --> 00:06:32,504 your 181 00:06:32,879 --> 00:06:36,000 SharePoint online tenancy. Conditional access can also apply 182 00:06:36,000 --> 00:06:38,339 to things like the Azure portal or potentially 183 00:06:38,480 --> 00:06:38,980 workloads 184 00:06:39,360 --> 00:06:40,959 that you stand up, say, like a custom 185 00:06:40,959 --> 00:06:43,600 website that you secure with entry ID and 186 00:06:43,600 --> 00:06:46,245 you're driving, like, OAuth authentication through there, 187 00:06:46,644 --> 00:06:49,365 then that's available to you as well. So 188 00:06:49,365 --> 00:06:50,725 if you're interested in, like, the ID side 189 00:06:50,725 --> 00:06:52,104 of it, you can go back and listen 190 00:06:52,165 --> 00:06:54,485 to that episode. But for this one, I 191 00:06:54,485 --> 00:06:56,264 wanted to just talk more about 192 00:06:56,725 --> 00:06:57,225 Azure 193 00:06:57,604 --> 00:06:59,764 Security in general, which starts to get a 194 00:06:59,764 --> 00:07:01,779 little bit weird because security is an open 195 00:07:01,779 --> 00:07:04,660 ended conversation anyway. And then it gets even 196 00:07:04,660 --> 00:07:05,560 weirder because 197 00:07:05,939 --> 00:07:09,139 it's Azure, and what is Azure, but a 198 00:07:09,139 --> 00:07:10,120 set of components 199 00:07:10,740 --> 00:07:13,860 that all sit behind this governance scheme of 200 00:07:13,860 --> 00:07:16,295 things like subscriptions and management groups and ultimately 201 00:07:16,295 --> 00:07:18,714 that identity construct in IntraID. 202 00:07:19,415 --> 00:07:20,855 So, yeah, we should talk a little bit 203 00:07:20,855 --> 00:07:22,774 about Azure and some of the other things 204 00:07:22,774 --> 00:07:25,735 that sit over here. So things like security 205 00:07:25,894 --> 00:07:28,209 we talked about security baselines for identity. We 206 00:07:28,209 --> 00:07:30,849 should talk about security baselines for Azure and 207 00:07:30,849 --> 00:07:32,769 what those mean, and how as we start 208 00:07:32,769 --> 00:07:35,329 to decompose out of identity as a service 209 00:07:35,329 --> 00:07:36,769 and software as a service, and we get 210 00:07:36,769 --> 00:07:39,029 more into, like, platform as a service, infrastructure 211 00:07:39,169 --> 00:07:41,009 as a service components that are out there, 212 00:07:41,009 --> 00:07:42,129 what do we do, and how do we 213 00:07:42,129 --> 00:07:44,475 think about that? Yeah. And real quick, because 214 00:07:44,475 --> 00:07:46,875 you mentioned identity too, it made me think 215 00:07:46,875 --> 00:07:49,215 of this. Just a heads up with identity, 216 00:07:49,595 --> 00:07:51,455 there is also a new 217 00:07:52,155 --> 00:07:54,415 identity in Azure. Starting in October, 218 00:07:54,875 --> 00:07:57,355 so, like, a month from when you'll probably 219 00:07:57,355 --> 00:07:58,959 hear this episode if you listen to it 220 00:07:58,959 --> 00:08:02,100 on release day, Microsoft is actually making MFA 221 00:08:02,319 --> 00:08:02,819 mandatory 222 00:08:03,600 --> 00:08:04,419 for all 223 00:08:04,720 --> 00:08:07,139 Azure users. Your break glass accounts. 224 00:08:07,600 --> 00:08:09,839 Come up with a plan for your break 225 00:08:09,839 --> 00:08:12,079 glass accounts because they are going to have 226 00:08:12,079 --> 00:08:13,379 to be MFA'd. 227 00:08:14,055 --> 00:08:15,675 A great way to think about that 228 00:08:16,055 --> 00:08:16,555 is 229 00:08:16,935 --> 00:08:17,754 our friend, 230 00:08:18,134 --> 00:08:18,634 mister 231 00:08:19,175 --> 00:08:21,894 Yubike or a Fido key. Since you do 232 00:08:21,894 --> 00:08:22,795 have to have MFA, 233 00:08:23,175 --> 00:08:24,314 tying that to 234 00:08:25,175 --> 00:08:27,814 my admin today's phone number might not be 235 00:08:27,814 --> 00:08:30,029 the best way to go about that. Consider 236 00:08:30,029 --> 00:08:32,350 things like Fido keys and plan for that 237 00:08:32,350 --> 00:08:33,950 because now you're going to have that for 238 00:08:33,950 --> 00:08:35,629 your break glass accounts as well. That I 239 00:08:35,629 --> 00:08:36,529 think that's probably 240 00:08:36,990 --> 00:08:38,129 more the automation 241 00:08:38,830 --> 00:08:40,190 and how am I getting in on the 242 00:08:40,190 --> 00:08:42,429 back end if something does go wrong scenario. 243 00:08:42,429 --> 00:08:44,355 Yep. Because this is also then gonna roll 244 00:08:44,355 --> 00:08:45,575 out early 2025, 245 00:08:46,115 --> 00:08:47,735 gradual enforcement of MFA 246 00:08:48,434 --> 00:08:51,714 for Azure CLI, Azure PowerShell, Azure Mobile app, 247 00:08:51,714 --> 00:08:54,834 infrastructure as code tools, like, everywhere. And with 248 00:08:54,834 --> 00:08:55,495 the YubiKeys, 249 00:08:56,149 --> 00:08:57,529 like, I would say 250 00:08:57,990 --> 00:09:00,230 see, this gets a little tricky because you 251 00:09:00,230 --> 00:09:01,910 also don't wanna just hide to 1 YubiKey 252 00:09:01,910 --> 00:09:04,070 because have you ever misplaced a YubiKey and 253 00:09:04,070 --> 00:09:06,230 then you can't log in? It's let's do 254 00:09:06,230 --> 00:09:08,170 this for multiple YubiKey 255 00:09:08,629 --> 00:09:10,649 and probably have multiple administrators 256 00:09:11,334 --> 00:09:14,375 of your Azure environment have these YubiKeys. Because 257 00:09:14,375 --> 00:09:15,735 I'm with you. I've had it tied to 258 00:09:15,735 --> 00:09:17,815 a phone or tied to my authenticator app 259 00:09:17,815 --> 00:09:19,014 in my phone and then you lose your 260 00:09:19,014 --> 00:09:21,754 phone or you reset your phone. That MFA 261 00:09:21,894 --> 00:09:23,995 does not come back reliably 262 00:09:24,375 --> 00:09:25,274 in my experience 263 00:09:25,850 --> 00:09:28,570 with the authenticator app. I don't know if 264 00:09:28,570 --> 00:09:30,029 you start switching to passkeys. 265 00:09:31,050 --> 00:09:33,470 Yeah. I like YubiKey for it. Phishing resistant, 266 00:09:33,529 --> 00:09:35,450 secure. But that is one thing I did 267 00:09:35,450 --> 00:09:38,889 want to mention that people should absolutely start 268 00:09:38,889 --> 00:09:41,565 preparing for kind of in that whole Azure 269 00:09:41,565 --> 00:09:44,845 security and identity vein that has been announced. 270 00:09:44,845 --> 00:09:46,225 To your point of dual enrollment, 271 00:09:46,605 --> 00:09:48,845 even with a single key, you might wanna 272 00:09:48,845 --> 00:09:51,324 consider dual enrollment depending on, like, the devices 273 00:09:51,324 --> 00:09:52,764 that you might need to actually use to 274 00:09:52,764 --> 00:09:53,264 access. 275 00:09:53,929 --> 00:09:55,710 For example, I have 276 00:09:56,250 --> 00:09:59,289 a USB c UB key with NFC on 277 00:09:59,289 --> 00:10:02,089 it. I've enrolled both the NFC component and 278 00:10:02,089 --> 00:10:03,389 the USB c component, 279 00:10:03,769 --> 00:10:05,929 and that lets me use USB c, like, 280 00:10:05,929 --> 00:10:07,610 on my desktop or my laptop when I 281 00:10:07,610 --> 00:10:09,524 need to get in. But if my desktop 282 00:10:09,524 --> 00:10:11,125 or laptop aren't available and I still have 283 00:10:11,125 --> 00:10:12,404 the key on me because it's on my 284 00:10:12,404 --> 00:10:12,904 Keyring, 285 00:10:13,764 --> 00:10:15,845 then I can still get in via my 286 00:10:15,845 --> 00:10:18,565 phone, which does support NFC. And it has 287 00:10:18,565 --> 00:10:20,485 to listen. There's the call out to multiple 288 00:10:20,485 --> 00:10:22,500 keys also to minimum every time. 289 00:10:23,199 --> 00:10:25,360 Any piece of hardware can die. It it 290 00:10:25,360 --> 00:10:27,679 can crash out. It can crap out. I've 291 00:10:27,679 --> 00:10:30,259 had the YubiKey, particularly like the nano YubiKeys, 292 00:10:30,399 --> 00:10:32,319 the ones that stick in, the little nubbin. 293 00:10:32,319 --> 00:10:34,399 Those things seem to die on me all 294 00:10:34,399 --> 00:10:35,600 the time, and I don't know if it's 295 00:10:35,600 --> 00:10:37,035 just cause they get so tight in the 296 00:10:37,035 --> 00:10:39,035 USB c ports and something goes wonky when 297 00:10:39,035 --> 00:10:40,095 you're trying to pull them out. 298 00:10:40,475 --> 00:10:42,554 Whatever it is, like, those things have not 299 00:10:42,554 --> 00:10:45,035 been reliable for me. So I've completely moved 300 00:10:45,035 --> 00:10:47,915 over to, like, USB c plus NFC kinds 301 00:10:47,915 --> 00:10:49,434 of things so that I can make my 302 00:10:49,434 --> 00:10:51,769 life just a little bit easier. Also, 303 00:10:52,470 --> 00:10:54,710 consider that if you're doing FIDO keys, they're 304 00:10:54,710 --> 00:10:56,889 going to come in various forms of connectivity, 305 00:10:57,110 --> 00:11:00,470 not just USB C and NFC, but also 306 00:11:00,470 --> 00:11:03,029 USB A. And what's the device I need 307 00:11:03,029 --> 00:11:04,710 to log in on? So you might actually 308 00:11:04,710 --> 00:11:06,605 want to have 2 or 3 of these, 309 00:11:06,605 --> 00:11:08,445 especially in the cases of, like, break glass 310 00:11:08,445 --> 00:11:08,945 accounts 311 00:11:09,404 --> 00:11:11,404 because it is super important kind of stuff. 312 00:11:11,404 --> 00:11:13,725 Like, it's worth investing $30 in a couple 313 00:11:13,725 --> 00:11:15,725 of keys and then distributing them out there 314 00:11:15,725 --> 00:11:16,764 and getting them to where they need to 315 00:11:16,764 --> 00:11:18,690 be. 100%. I'm with you. I have 3 316 00:11:18,690 --> 00:11:19,190 keys 317 00:11:19,490 --> 00:11:21,410 that I enroll in almost all of my 318 00:11:21,410 --> 00:11:23,889 services when I use FIDO keys, and they're 319 00:11:23,889 --> 00:11:25,730 for sure all enrolled in Azure AD. Same 320 00:11:25,730 --> 00:11:27,809 thing as you. One's USB a, couple are 321 00:11:27,809 --> 00:11:30,129 USB c, one of them has NFC as 322 00:11:30,129 --> 00:11:30,629 well. 323 00:11:31,065 --> 00:11:33,304 Multiple options, they're not all in the same 324 00:11:33,304 --> 00:11:35,465 spot. So if I lose one, I can 325 00:11:35,465 --> 00:11:37,705 go look for 1 in another spot and 326 00:11:37,705 --> 00:11:40,585 all that. So moving on from identity and 327 00:11:40,585 --> 00:11:43,785 security to where you started to take me 328 00:11:43,785 --> 00:11:44,285 is 329 00:11:44,789 --> 00:11:46,470 security all up in Azure. Where do you 330 00:11:46,470 --> 00:11:48,549 wanna start with? Is this a broad, big, 331 00:11:48,549 --> 00:11:50,809 large topic? I think it's 332 00:11:51,190 --> 00:11:51,690 helpful 333 00:11:53,110 --> 00:11:55,209 to start at the top, 334 00:11:55,509 --> 00:11:58,709 consider what's the landscape of things that's available 335 00:11:58,709 --> 00:12:00,285 to you. So I I think one of 336 00:12:00,285 --> 00:12:02,144 the reasons this topic becomes 337 00:12:02,524 --> 00:12:03,424 so broad 338 00:12:03,965 --> 00:12:05,504 is you could say, 339 00:12:06,605 --> 00:12:09,644 I don't know, something like I'm a Azure 340 00:12:09,644 --> 00:12:12,065 SQL customer. Yep. And I'm running 341 00:12:12,524 --> 00:12:13,024 SQL 342 00:12:13,660 --> 00:12:14,960 inside of 343 00:12:15,340 --> 00:12:15,840 Azure 344 00:12:16,220 --> 00:12:18,779 Virtual Machines. I'm not running like SQL as 345 00:12:18,779 --> 00:12:20,779 a PaaS service, I'm running it as IaaS 346 00:12:20,779 --> 00:12:23,120 in a virtual machine. And in that world, 347 00:12:23,259 --> 00:12:25,664 you're running virtual machines. And how do you 348 00:12:25,745 --> 00:12:27,584 secure virtual machines, and what does that look 349 00:12:27,584 --> 00:12:29,445 like? And that's a pretty constrained conversation. 350 00:12:29,824 --> 00:12:31,424 Maybe that takes us back to the CrowdStrike 351 00:12:31,424 --> 00:12:32,784 thing. But if you take a step back 352 00:12:32,784 --> 00:12:34,625 from that and you say, hold on, like, 353 00:12:34,625 --> 00:12:36,644 before I was a virtual machine customer, 354 00:12:37,024 --> 00:12:39,745 what was I? Oh, I was an Azure 355 00:12:39,745 --> 00:12:40,245 customer. 356 00:12:40,549 --> 00:12:42,549 So what are the things that are available 357 00:12:42,549 --> 00:12:44,809 to me in Azure that I should go 358 00:12:45,509 --> 00:12:48,709 think about lighting up and turning on and 359 00:12:48,709 --> 00:12:49,209 enabling 360 00:12:49,669 --> 00:12:51,129 based on my scenarios? 361 00:12:51,669 --> 00:12:54,069 So in my mind, there's no reason that 362 00:12:54,069 --> 00:12:55,049 you would treat 363 00:12:55,514 --> 00:12:56,894 Azure in any 364 00:12:57,355 --> 00:12:59,774 way differently than you might like your 365 00:13:00,235 --> 00:13:02,634 Microsoft 365 environment. Right? So when you go 366 00:13:02,634 --> 00:13:04,575 into your Microsoft 365 environment, 367 00:13:05,195 --> 00:13:06,894 you don't first go into 368 00:13:07,355 --> 00:13:08,415 Exchange Online 369 00:13:09,029 --> 00:13:11,769 and start configuring security around Exchange Online. 370 00:13:12,230 --> 00:13:13,909 You start at the top and you say, 371 00:13:13,909 --> 00:13:16,070 oh, I'm I'm an m 65 customer. What 372 00:13:16,070 --> 00:13:17,589 can I turn on that gives me logging 373 00:13:17,589 --> 00:13:19,449 across the suite? And, 374 00:13:19,909 --> 00:13:21,669 hey, there's the audit log. So let let 375 00:13:21,669 --> 00:13:23,115 me go start to light that stuff up. 376 00:13:23,274 --> 00:13:25,534 What can I do to get visibility into 377 00:13:26,235 --> 00:13:28,315 the wider swath? And I think that's a 378 00:13:28,315 --> 00:13:30,235 good way to start with Azure as well 379 00:13:30,235 --> 00:13:30,735 because 380 00:13:31,914 --> 00:13:34,235 we've tied into the identity piece. So we 381 00:13:34,235 --> 00:13:36,600 talked about that and getting in, you can 382 00:13:36,600 --> 00:13:38,440 report on your sign in logs and start 383 00:13:38,440 --> 00:13:40,200 to understand that stuff. And then you take 384 00:13:40,200 --> 00:13:42,299 that next stop down to Azure, 385 00:13:42,840 --> 00:13:45,100 and before you even get into the services, 386 00:13:45,639 --> 00:13:46,139 there's 387 00:13:46,519 --> 00:13:50,274 this common base layer for Azure customers in 388 00:13:50,274 --> 00:13:52,754 the form of Azure Resource Manager and like 389 00:13:52,754 --> 00:13:53,254 the 390 00:13:54,034 --> 00:13:56,835 modern API surface, which is different than that 391 00:13:56,835 --> 00:13:59,955 old Azure service management service. At the ARM 392 00:13:59,955 --> 00:14:03,815 layer, you have these things like activity logs 393 00:14:04,000 --> 00:14:07,360 that are available automatically. Right? So for every 394 00:14:07,360 --> 00:14:09,139 Azure resource that's deployed, 395 00:14:09,680 --> 00:14:12,399 that you interact with, in certain cases that 396 00:14:12,399 --> 00:14:15,360 you perform like listing operations with or things 397 00:14:15,360 --> 00:14:18,320 like that, you've got the activity log there 398 00:14:18,320 --> 00:14:19,059 by default. 399 00:14:20,054 --> 00:14:22,934 And the activity log is integrated directly into 400 00:14:22,934 --> 00:14:23,674 a service, 401 00:14:24,134 --> 00:14:27,254 called Azure Monitor. And what does Azure Monitor 402 00:14:27,254 --> 00:14:30,714 give you? Azure Monitor gives you insights into 403 00:14:30,774 --> 00:14:33,995 metrics about your environment. So metrics being numbers. 404 00:14:34,054 --> 00:14:37,210 Right? Number of API calls, number of errors, 405 00:14:37,210 --> 00:14:38,970 number of sign in attempts, like whatever it 406 00:14:38,970 --> 00:14:41,210 happens to be given the the service you 407 00:14:41,210 --> 00:14:43,210 consume. So we start at the Arm layer, 408 00:14:43,210 --> 00:14:45,290 we start at the controllable plane. I think 409 00:14:45,290 --> 00:14:47,550 the first place we look is 410 00:14:48,490 --> 00:14:50,350 activity logs in general, 411 00:14:50,865 --> 00:14:53,825 because as you're getting into Azure, like you 412 00:14:53,825 --> 00:14:55,764 light it up and you have no resources, 413 00:14:56,465 --> 00:14:59,184 the very first resource you create let's say 414 00:14:59,184 --> 00:15:01,825 you create a virtual machine. So you're gonna 415 00:15:01,825 --> 00:15:04,225 go into the marketplace, and you're gonna click, 416 00:15:04,225 --> 00:15:06,100 I wanna create a new resource, you're gonna 417 00:15:06,100 --> 00:15:08,100 search for virtual machines, and you're gonna hit 418 00:15:08,100 --> 00:15:10,919 that blade. Ultimately, you're gonna submit that deployment, 419 00:15:11,220 --> 00:15:13,379 and that deployment, the act of submitting that 420 00:15:13,379 --> 00:15:16,019 deployment and having it ingested by Arm, captures 421 00:15:16,019 --> 00:15:18,019 that entry in the activity log, and then 422 00:15:18,019 --> 00:15:20,115 it's there for you. And then later when 423 00:15:20,115 --> 00:15:21,875 you come back and you interact with that 424 00:15:21,875 --> 00:15:23,795 virtual machine, let's say you come back and 425 00:15:23,795 --> 00:15:26,134 you add a disk to it, you're modifying 426 00:15:26,195 --> 00:15:26,935 that deployment, 427 00:15:27,315 --> 00:15:29,634 then that's captured in the activity log for 428 00:15:29,634 --> 00:15:31,379 you. And like I said, there's a whole 429 00:15:31,620 --> 00:15:34,980 slew of information that's captured in the activity 430 00:15:34,980 --> 00:15:37,700 log in general, but it's there for 90 431 00:15:37,700 --> 00:15:39,399 days, 93 days by default. 432 00:15:40,019 --> 00:15:42,660 It's basically 3 months of data, both Azure 433 00:15:42,660 --> 00:15:45,940 Monitor for metrics and your activity log as 434 00:15:45,940 --> 00:15:48,095 well that you just have out of the 435 00:15:48,095 --> 00:15:48,595 box, 436 00:15:49,054 --> 00:15:50,654 ready to go. You don't have to turn 437 00:15:50,654 --> 00:15:52,754 anything on. You don't have to configure anything, 438 00:15:52,894 --> 00:15:54,735 but you do have to know that it's 439 00:15:54,735 --> 00:15:57,535 there and that it's available to you because 440 00:15:57,535 --> 00:15:59,580 what's going to happen is, for that activity 441 00:15:59,580 --> 00:16:02,779 log, any interactions with the control plane, so 442 00:16:02,779 --> 00:16:05,740 things that happen through the API surface of 443 00:16:05,740 --> 00:16:08,779 Azure Resource Manager, that would be your CRUD 444 00:16:08,779 --> 00:16:11,580 operations for these resources, your creates, your reads, 445 00:16:11,580 --> 00:16:14,595 your updates, your deletes. All that stuff is 446 00:16:14,674 --> 00:16:15,574 going into the 447 00:16:16,434 --> 00:16:17,574 Azure Activity Log, 448 00:16:18,034 --> 00:16:19,735 and it's just there, 449 00:16:20,355 --> 00:16:21,954 ready to go for you, which is nice. 450 00:16:21,954 --> 00:16:23,735 You didn't even have to turn it on. 451 00:16:23,794 --> 00:16:25,154 It's always weird to me that you have 452 00:16:25,154 --> 00:16:26,754 to turn on the audit log in Office 453 00:16:26,754 --> 00:16:27,495 in M365, 454 00:16:28,274 --> 00:16:29,919 but I get why they do it, but 455 00:16:29,919 --> 00:16:31,600 it's well, just turn it on by default. 456 00:16:31,600 --> 00:16:33,839 It's Right. They had a security incident. Right? 457 00:16:33,839 --> 00:16:35,440 That compelled them. That made them turn it 458 00:16:35,440 --> 00:16:37,620 on, but you're right. For a long time, 459 00:16:38,000 --> 00:16:39,919 multiple years, it was not on by default. 460 00:16:39,919 --> 00:16:41,200 And I said the same thing. I'm like, 461 00:16:41,200 --> 00:16:43,185 that's stupid. It should just be on. Anyways, 462 00:16:43,185 --> 00:16:45,825 yes, it is. It's on. It's there. Use 463 00:16:45,825 --> 00:16:47,205 step 1 is recognize 464 00:16:47,985 --> 00:16:50,065 the activity log is there. One of the 465 00:16:50,065 --> 00:16:52,804 things that I mentioned was the activity log 466 00:16:53,105 --> 00:16:53,605 is 467 00:16:53,985 --> 00:16:54,485 integrated 468 00:16:55,024 --> 00:16:55,524 with 469 00:16:55,985 --> 00:16:56,884 Azure Monitor. 470 00:16:57,209 --> 00:16:59,629 Azure Monitor is this whole 471 00:17:00,009 --> 00:17:01,069 Azure service 472 00:17:01,529 --> 00:17:02,269 that is 473 00:17:03,289 --> 00:17:05,849 a crosscut, and it allows ingestion from a 474 00:17:05,849 --> 00:17:07,390 bunch of other Azure services. 475 00:17:07,929 --> 00:17:09,869 But the goal is to give you 476 00:17:10,329 --> 00:17:13,664 access to that observability data. That comes in 477 00:17:13,664 --> 00:17:16,224 the form of the activity log, which is 478 00:17:16,224 --> 00:17:19,264 effectively strings, right? We're talking about like words 479 00:17:19,264 --> 00:17:21,184 that go in, this was a create event, 480 00:17:21,184 --> 00:17:22,724 here was the name of the resource, 481 00:17:23,264 --> 00:17:24,644 this was the 482 00:17:25,424 --> 00:17:25,924 UPN 483 00:17:26,429 --> 00:17:28,589 that initiated that call, so you can do 484 00:17:28,589 --> 00:17:31,069 things like track, k. Was this resource created 485 00:17:31,069 --> 00:17:31,569 by, 486 00:17:32,109 --> 00:17:33,950 a service principal? Was it created by a 487 00:17:33,950 --> 00:17:35,869 real human? Which human was it created by? 488 00:17:35,869 --> 00:17:37,149 And how does that start to tie back 489 00:17:37,149 --> 00:17:38,829 to your identity environment? That's all there for 490 00:17:38,829 --> 00:17:40,429 you. And the other thing that it gives 491 00:17:40,429 --> 00:17:41,904 you is the observability 492 00:17:42,845 --> 00:17:43,904 part of the platform 493 00:17:44,365 --> 00:17:46,944 is it also gives you access to 494 00:17:47,325 --> 00:17:47,825 metrics. 495 00:17:48,284 --> 00:17:50,865 So you're probably, like, once you start deploying 496 00:17:50,924 --> 00:17:51,904 Azure services, 497 00:17:52,525 --> 00:17:55,240 and and it's not directly related to security, 498 00:17:55,240 --> 00:17:57,179 but it's important to know that it's there, 499 00:17:57,400 --> 00:17:59,240 is you're probably gonna wanna think about ways 500 00:17:59,240 --> 00:18:01,339 that you can tie metrics into that 501 00:18:01,720 --> 00:18:04,279 and things like metric alerts. Let's say I 502 00:18:04,279 --> 00:18:04,779 deploy 503 00:18:05,079 --> 00:18:07,240 a storage account. So I deploy a storage 504 00:18:07,240 --> 00:18:09,994 account, one of the things that I might 505 00:18:09,994 --> 00:18:11,855 want to monitor as 506 00:18:12,394 --> 00:18:13,535 a storage customer 507 00:18:14,234 --> 00:18:14,734 is 508 00:18:15,275 --> 00:18:17,515 how many transactions or how many errors am 509 00:18:17,515 --> 00:18:19,755 I driving? Like, how many transactions are erring 510 00:18:19,755 --> 00:18:21,840 out? What's the class of the error? Is 511 00:18:21,840 --> 00:18:23,920 it is it a 5 0X error, like 512 00:18:23,920 --> 00:18:26,420 a a throttle? Is it a 4 0X? 513 00:18:26,720 --> 00:18:28,640 Maybe it's 4 0 threes or 4 0 514 00:18:28,640 --> 00:18:31,119 fours, things like that. So that's all tracked 515 00:18:31,119 --> 00:18:33,440 in monitor by default. You can just go 516 00:18:33,440 --> 00:18:34,259 into monitor, 517 00:18:34,664 --> 00:18:37,545 and you can select a storage account, or 518 00:18:37,545 --> 00:18:39,625 you can even graph multiple storage accounts if 519 00:18:39,625 --> 00:18:40,664 you want to. I think you can put 520 00:18:40,664 --> 00:18:43,225 up to 200 individual storage accounts in a 521 00:18:43,225 --> 00:18:45,805 single Azure Monitor workbook for crosscut reporting, 522 00:18:46,265 --> 00:18:49,065 and you can immediately get those insights in 523 00:18:49,065 --> 00:18:50,045 a visual form. 524 00:18:50,559 --> 00:18:52,080 Or you can go the next click stop 525 00:18:52,080 --> 00:18:53,200 and you can say, hey, here's the things 526 00:18:53,200 --> 00:18:54,559 that are really important to me. Like, I 527 00:18:54,559 --> 00:18:56,580 might wanna know when I have more than 528 00:18:56,880 --> 00:18:57,380 n 529 00:18:57,839 --> 00:18:58,980 five zero three errors 530 00:18:59,279 --> 00:19:01,440 in a given period. So in the last 531 00:19:01,440 --> 00:19:04,259 hour, if I had more than a 1,050 532 00:19:04,640 --> 00:19:07,494 threes, maybe I've got some segment of throttling 533 00:19:07,494 --> 00:19:08,934 going on that's a little bit higher than 534 00:19:08,934 --> 00:19:10,215 I want it to be. So you can 535 00:19:10,215 --> 00:19:13,115 do things like configure alerts on top of 536 00:19:13,174 --> 00:19:15,095 that metric or those set of metrics, or 537 00:19:15,095 --> 00:19:16,535 you can start to combine the logs and 538 00:19:16,535 --> 00:19:18,299 metrics inside of alerts as well, 539 00:19:18,700 --> 00:19:20,160 and and you can start to 540 00:19:20,619 --> 00:19:22,080 layer that information 541 00:19:22,539 --> 00:19:23,039 together 542 00:19:23,580 --> 00:19:25,259 a little bit along the way, if that 543 00:19:25,259 --> 00:19:27,340 makes sense. Some people are like, yeah, platform 544 00:19:27,340 --> 00:19:29,360 metrics, my storage account, my 545 00:19:29,900 --> 00:19:32,460 CPU resources, that type of stuff. Maybe not 546 00:19:32,460 --> 00:19:34,825 security, but I also think as you start 547 00:19:34,825 --> 00:19:37,164 developing a baseline for how these should behave, 548 00:19:37,225 --> 00:19:38,445 a storage account or 549 00:19:38,904 --> 00:19:42,105 a VM that you're monitoring these platform metrics 550 00:19:42,105 --> 00:19:45,065 on, and you set those alerts to alert 551 00:19:45,065 --> 00:19:46,664 you when you stray outside of your baseline, 552 00:19:46,664 --> 00:19:49,150 it could indicate a security event. Like, someone 553 00:19:49,150 --> 00:19:50,750 got access to your storage account and started 554 00:19:50,750 --> 00:19:52,990 uploading and downloading a whole bunch of junk 555 00:19:52,990 --> 00:19:54,670 to it or somebody got into a VM 556 00:19:54,670 --> 00:19:56,269 and is running a bunch of processes on 557 00:19:56,269 --> 00:19:58,509 it that are and you see it because 558 00:19:58,509 --> 00:19:59,970 your VM CPU 559 00:20:00,430 --> 00:20:02,715 spiked and is running way higher than it 560 00:20:02,715 --> 00:20:05,595 normally runs. The SQL resource or SQL platform 561 00:20:05,595 --> 00:20:08,555 metrics, all of those things, I think, are 562 00:20:08,555 --> 00:20:10,955 very valid, and it's something that people would 563 00:20:10,955 --> 00:20:11,455 monitor 564 00:20:11,835 --> 00:20:14,975 anyways on prem. If you're running a VMware 565 00:20:15,035 --> 00:20:16,899 host or some other 566 00:20:17,279 --> 00:20:19,779 servers on prem, you're typically monitoring 567 00:20:20,159 --> 00:20:22,179 CPU consumption, memory consumption, 568 00:20:22,480 --> 00:20:22,980 storage, 569 00:20:23,919 --> 00:20:26,880 disk, IO, all that type of stuff. So 570 00:20:26,880 --> 00:20:27,859 why would you 571 00:20:28,319 --> 00:20:30,799 stop monitoring it when you go to Azure? 572 00:20:30,799 --> 00:20:31,299 Because, 573 00:20:31,634 --> 00:20:32,134 ultimately, 574 00:20:32,595 --> 00:20:34,434 Microsoft doesn't care if you fill up a 575 00:20:34,434 --> 00:20:36,275 storage account or if you incur a bunch 576 00:20:36,275 --> 00:20:38,755 of costs or have some type of security 577 00:20:38,755 --> 00:20:40,615 incident that's really affecting 578 00:20:40,994 --> 00:20:43,734 your data. Right? It's still that shared responsibility 579 00:20:44,035 --> 00:20:46,379 model of I'm running a VM in Azure. 580 00:20:46,379 --> 00:20:49,099 I'm still responsible for patching my OS. I'm 581 00:20:49,099 --> 00:20:50,559 still responsible for 582 00:20:50,859 --> 00:20:53,419 antivirus on the v maybe even storage accounts, 583 00:20:53,419 --> 00:20:55,339 like, getting into some of the other security 584 00:20:55,339 --> 00:20:57,345 options maybe that we'll talk about is 585 00:20:57,825 --> 00:21:00,544 what files are in my storage account that 586 00:21:00,544 --> 00:21:03,025 I have up in Azure. So I think 587 00:21:03,025 --> 00:21:04,164 from that perspective, 588 00:21:04,784 --> 00:21:06,164 like, platform metrics 589 00:21:06,544 --> 00:21:09,184 can still very much be an indicator of 590 00:21:09,184 --> 00:21:11,710 security issues or other issues. I I have 591 00:21:11,710 --> 00:21:12,529 a lot of conversations 592 00:21:12,829 --> 00:21:14,450 with customers in this area, 593 00:21:16,109 --> 00:21:18,429 is there's both the control plane and there's 594 00:21:18,429 --> 00:21:20,450 the data plane. So there's interactions 595 00:21:20,909 --> 00:21:22,529 that are driven through 596 00:21:22,829 --> 00:21:25,644 Azure Resource Manager, like I want to in 597 00:21:25,644 --> 00:21:27,164 the case of a storage account, I wanna 598 00:21:27,164 --> 00:21:29,484 create a storage account. Now once your storage 599 00:21:29,484 --> 00:21:31,404 account is created and you do things like 600 00:21:31,404 --> 00:21:31,904 you 601 00:21:32,365 --> 00:21:34,605 stand up a container and you upload an 602 00:21:34,605 --> 00:21:35,984 object into that container, 603 00:21:36,525 --> 00:21:38,525 the upload of that object, the creation of 604 00:21:38,525 --> 00:21:41,339 that container, those are data plane operations. So 605 00:21:41,339 --> 00:21:43,660 we've we've actually crossed over to a new 606 00:21:43,660 --> 00:21:44,160 API 607 00:21:44,700 --> 00:21:46,000 surface. But the the 608 00:21:46,299 --> 00:21:48,319 the thing to remember here is, 609 00:21:48,700 --> 00:21:50,940 like, in the context of, say, a storage 610 00:21:50,940 --> 00:21:52,859 account and just about every service I can 611 00:21:52,859 --> 00:21:54,059 think of off the top of my head 612 00:21:54,059 --> 00:21:54,960 that's in Azure, 613 00:21:55,259 --> 00:21:57,105 even though it's got a data plane to 614 00:21:57,105 --> 00:21:59,825 it, that data plane information was still available 615 00:21:59,825 --> 00:22:01,045 and monitored to me 616 00:22:01,505 --> 00:22:05,105 alongside my control plane information. So it's a 617 00:22:05,105 --> 00:22:06,705 kinda have your cake, you need it too 618 00:22:06,705 --> 00:22:09,265 scenario, and it's important to recognize, like, where 619 00:22:09,265 --> 00:22:11,440 those things are coming in and how they're 620 00:22:11,440 --> 00:22:13,360 getting there and where they're coming from. Because 621 00:22:13,360 --> 00:22:14,900 in that scenario where I described 622 00:22:16,000 --> 00:22:19,200 monitoring a storage account for things like number 623 00:22:19,200 --> 00:22:20,019 of errors, 624 00:22:20,559 --> 00:22:23,474 those errors, those those HTTP error codes like 625 00:22:23,474 --> 00:22:24,214 that 404, 626 00:22:24,674 --> 00:22:25,174 403, 627 00:22:25,555 --> 00:22:27,815 those 5 0 x errors, those are ultimately 628 00:22:27,954 --> 00:22:29,954 data plane metrics. But I didn't have to 629 00:22:29,954 --> 00:22:31,394 do anything to turn them on. Like, they 630 00:22:31,394 --> 00:22:32,674 were just there for me out of the 631 00:22:32,674 --> 00:22:34,755 box, and they were presented to me through 632 00:22:34,755 --> 00:22:35,494 that observability 633 00:22:35,795 --> 00:22:37,174 layer in Azure Monitor 634 00:22:37,700 --> 00:22:40,039 where it was automatically combining 635 00:22:40,500 --> 00:22:43,460 my control plane and data plane. So while 636 00:22:43,460 --> 00:22:47,160 Azure Monitor itself is not a security service, 637 00:22:47,460 --> 00:22:48,920 it has these components 638 00:22:49,299 --> 00:22:51,299 that are giving you all the observability and 639 00:22:51,299 --> 00:22:52,359 alerting capabilities, 640 00:22:53,085 --> 00:22:53,585 which 641 00:22:53,964 --> 00:22:55,265 leverage the right way, 642 00:22:55,644 --> 00:22:58,784 becomes something that's a component of your strategy 643 00:22:59,244 --> 00:23:02,204 to thinking about how you monitor and secure 644 00:23:02,204 --> 00:23:04,865 your environment. Because a lot of security constructs 645 00:23:04,924 --> 00:23:07,349 do come down to things like observability. If 646 00:23:07,509 --> 00:23:09,269 you think of even like the basics of 647 00:23:09,269 --> 00:23:11,750 an AV client, an AV client is there 648 00:23:11,750 --> 00:23:14,230 to watch for heuristics and new things to 649 00:23:14,230 --> 00:23:15,829 load and try and block them when they're 650 00:23:15,829 --> 00:23:18,569 malicious. So it's own kinda like little observability 651 00:23:18,950 --> 00:23:20,835 container. And, yeah, once you start to 652 00:23:21,315 --> 00:23:23,634 walk down that path and and recognize that 653 00:23:23,634 --> 00:23:26,134 crosscut is there for you, I I think 654 00:23:26,434 --> 00:23:28,054 it it makes things a little bit easier, 655 00:23:28,434 --> 00:23:31,095 and it opens up that mindset 656 00:23:31,634 --> 00:23:33,315 of, how do I get out of just 657 00:23:33,315 --> 00:23:33,815 observability 658 00:23:34,115 --> 00:23:35,174 mode into 659 00:23:36,730 --> 00:23:39,710 translating my security needs into things that observability 660 00:23:39,929 --> 00:23:41,929 is going to inform and where does this 661 00:23:41,929 --> 00:23:42,750 pull me to? 662 00:23:46,169 --> 00:23:48,250 Do you feel overwhelmed by trying to manage 663 00:23:48,250 --> 00:23:51,389 your Office 365 environment? Are you facing unexpected 664 00:23:51,715 --> 00:23:54,835 issues that disrupt your company's productivity? Intelligent is 665 00:23:54,835 --> 00:23:56,434 here to help. Much like you take your 666 00:23:56,434 --> 00:23:58,994 car to the mechanic that has specialized knowledge 667 00:23:58,994 --> 00:24:00,775 on how to best keep your car running, 668 00:24:00,994 --> 00:24:03,875 Intelligent helps you with your Microsoft cloud environment 669 00:24:03,875 --> 00:24:05,414 because that's their expertise. 670 00:24:05,920 --> 00:24:08,080 IntelliJunk keeps up with the latest updates in 671 00:24:08,080 --> 00:24:10,240 the Microsoft cloud to help keep your business 672 00:24:10,240 --> 00:24:12,480 running smoothly and ahead of the curve. Whether 673 00:24:12,480 --> 00:24:14,480 you are a small organization with just a 674 00:24:14,480 --> 00:24:16,960 few users up to an organization of several 675 00:24:16,960 --> 00:24:17,940 1000 employees, 676 00:24:18,320 --> 00:24:20,285 they want to partner with you to implement 677 00:24:20,285 --> 00:24:23,025 and administer your Microsoft Cloud technology. 678 00:24:23,805 --> 00:24:25,345 Visit them at inteliginc.com/podcast. 679 00:24:27,565 --> 00:24:28,464 That's intelliginkdot 680 00:24:32,830 --> 00:24:33,330 com/podcast 681 00:24:34,750 --> 00:24:36,830 for more information or to schedule a 30 682 00:24:36,830 --> 00:24:38,930 minute call to get started with them today. 683 00:24:39,150 --> 00:24:42,509 Remember, Intelligink focuses on the Microsoft cloud so 684 00:24:42,509 --> 00:24:44,289 you can focus on your business. 685 00:24:46,590 --> 00:24:50,455 So that covers activity logs, platform metrics, those 686 00:24:50,455 --> 00:24:53,815 both collected by default have access to. There's 687 00:24:53,815 --> 00:24:56,475 one other type of kinda core 688 00:24:57,174 --> 00:24:59,830 log. I would say you probably also want 689 00:24:59,830 --> 00:25:02,630 to monitor high I would highly recommend you 690 00:25:02,630 --> 00:25:04,789 start monitoring, but this one is not on 691 00:25:04,869 --> 00:25:07,269 activity logs is I'm going in and I'm 692 00:25:07,269 --> 00:25:10,230 creating storage accounts, I'm creating VMs, platform, the 693 00:25:10,230 --> 00:25:13,125 metrics we just talked about. Resource logs are 694 00:25:13,125 --> 00:25:14,105 actually then 695 00:25:14,565 --> 00:25:16,904 insights into operations that are performed 696 00:25:17,204 --> 00:25:19,845 within the Azure resource. So actions that are 697 00:25:19,845 --> 00:25:21,384 performed within a 698 00:25:21,845 --> 00:25:22,825 storage account, 699 00:25:23,284 --> 00:25:24,505 uploading, downloading 700 00:25:25,529 --> 00:25:26,029 files, 701 00:25:26,410 --> 00:25:28,809 actions within a VM. You can pull out 702 00:25:28,809 --> 00:25:30,350 event logs from VMs, 703 00:25:30,890 --> 00:25:32,670 actions within the SQL database. 704 00:25:32,970 --> 00:25:35,390 You have to turn on your diagnostic settings 705 00:25:35,769 --> 00:25:37,789 in these individual resources 706 00:25:38,330 --> 00:25:41,434 or potentially use something like Azure policy 707 00:25:42,054 --> 00:25:44,054 or something else to turn these on and 708 00:25:44,054 --> 00:25:46,774 then figure out where do I want these 709 00:25:46,774 --> 00:25:49,255 logs to go. And these are going to 710 00:25:49,255 --> 00:25:50,474 very much vary 711 00:25:50,855 --> 00:25:52,075 resource to resource 712 00:25:52,615 --> 00:25:54,954 based on what types of logs you're collecting. 713 00:25:55,095 --> 00:25:55,914 Logs within 714 00:25:56,250 --> 00:25:58,890 IIS are very different than logs within storage, 715 00:25:58,890 --> 00:26:00,509 are very different than logs within 716 00:26:00,970 --> 00:26:01,470 VMs. 717 00:26:01,849 --> 00:26:03,769 You can pick and choose too. There's multiple 718 00:26:03,769 --> 00:26:05,130 logs within all of these. You can go 719 00:26:05,130 --> 00:26:06,650 in and say, I just want all the 720 00:26:06,650 --> 00:26:09,130 logs from this resource. Or based on the 721 00:26:09,130 --> 00:26:10,565 resource, you can go in and pick, I 722 00:26:10,565 --> 00:26:12,565 just want this certain type of information, these 723 00:26:12,565 --> 00:26:15,765 certain logs from this particular resource. And usually, 724 00:26:15,765 --> 00:26:17,765 you have different options. You can go into 725 00:26:17,765 --> 00:26:19,924 storage accounts with these. Scott would love it 726 00:26:19,924 --> 00:26:21,285 if you put all your logs in his 727 00:26:21,285 --> 00:26:24,244 storage accounts. Typically, I think what people tend 728 00:26:24,244 --> 00:26:25,200 to do, and this is 729 00:26:25,759 --> 00:26:27,279 what I tend to do, is send these 730 00:26:27,279 --> 00:26:27,779 into 731 00:26:28,159 --> 00:26:31,039 log analytics. You can also I can't remember. 732 00:26:31,039 --> 00:26:32,559 What are the are there 3 or 4 733 00:26:32,559 --> 00:26:35,380 options? Log analytics, a storage account, queues? 734 00:26:35,759 --> 00:26:39,119 There's 3. Log analytics, storage account, and event 735 00:26:39,119 --> 00:26:40,734 grid. Yes. So you can send them back 736 00:26:40,734 --> 00:26:41,794 through through eventing. 737 00:26:42,255 --> 00:26:44,515 Taking a step back, when we talk about 738 00:26:45,214 --> 00:26:46,355 monitoring and observability 739 00:26:46,654 --> 00:26:47,875 and then tying observability 740 00:26:48,335 --> 00:26:50,015 back to things like what do I want 741 00:26:50,015 --> 00:26:51,234 to monitor to 742 00:26:51,694 --> 00:26:53,474 think about the security of my environment, 743 00:26:54,059 --> 00:26:56,159 You need to start answering those questions 744 00:26:56,779 --> 00:26:59,440 like service by service or area by area. 745 00:26:59,740 --> 00:27:02,940 So for a storage account, I could be 746 00:27:02,940 --> 00:27:05,759 really interested, like I said, in things like 747 00:27:05,980 --> 00:27:07,039 number of errors 748 00:27:07,595 --> 00:27:10,795 on a given subset of transactions that exist 749 00:27:10,795 --> 00:27:13,115 out there. So that's my class of, hey, 750 00:27:13,115 --> 00:27:15,355 what are my 4 0 x errors for 751 00:27:15,355 --> 00:27:17,674 GitLab requests? Like, how many unknown requests am 752 00:27:17,674 --> 00:27:19,914 I getting? Is somebody randomly hitting me? Once 753 00:27:19,914 --> 00:27:21,434 you start getting to the place where you're 754 00:27:21,434 --> 00:27:24,230 like, show me the user who did that 755 00:27:24,230 --> 00:27:26,410 thing, or show me the URI 756 00:27:26,869 --> 00:27:29,750 for the resource that was impacted by that 757 00:27:29,750 --> 00:27:30,250 event, 758 00:27:30,549 --> 00:27:32,470 those are logs. So a good way that 759 00:27:32,470 --> 00:27:34,309 you can rationalize this in your head, or 760 00:27:34,309 --> 00:27:35,509 at least it's a way that I found 761 00:27:35,509 --> 00:27:38,085 to work for me, is metrics are always 762 00:27:38,085 --> 00:27:38,585 numbers, 763 00:27:38,965 --> 00:27:40,484 and those are always gonna be in Azure 764 00:27:40,484 --> 00:27:41,845 Monitor, and they're always gonna be there for 765 00:27:41,845 --> 00:27:44,164 free for the those 3 months. Outside of 766 00:27:44,164 --> 00:27:45,924 that, it's on you to retain them for 767 00:27:45,924 --> 00:27:48,484 longer. Once you start talking about things like, 768 00:27:48,484 --> 00:27:49,865 oh, was it a UPN? 769 00:27:50,164 --> 00:27:51,144 Was it a URI? 770 00:27:51,765 --> 00:27:55,099 What was the operation that was called? Things 771 00:27:55,099 --> 00:27:55,839 like that. 772 00:27:56,380 --> 00:27:57,759 Those are logs, 773 00:27:58,140 --> 00:27:59,519 and logs are strings. 774 00:28:00,140 --> 00:28:02,619 And if it's a string, it's always gonna 775 00:28:02,619 --> 00:28:04,460 be in a resource log if it's coming 776 00:28:04,460 --> 00:28:06,940 from, like, a native service perspective. So if 777 00:28:06,940 --> 00:28:08,674 you're just looking to rationalize, hey, do I 778 00:28:08,674 --> 00:28:10,914 need to turn on resource logs? If the 779 00:28:10,914 --> 00:28:13,634 thing you want to interrogate sounds and feels 780 00:28:13,634 --> 00:28:15,394 like and it is a string, yeah, you 781 00:28:15,394 --> 00:28:17,394 need resource logs to make it work. We 782 00:28:17,394 --> 00:28:19,875 talked about the activity log for Arm. That 783 00:28:19,875 --> 00:28:20,375 absolutely 784 00:28:20,835 --> 00:28:22,674 is a bunch of strings that you can 785 00:28:22,674 --> 00:28:23,494 go in query 786 00:28:23,869 --> 00:28:25,170 through Azure Monitor 787 00:28:25,549 --> 00:28:27,950 and light up scenarios around that without needing 788 00:28:27,950 --> 00:28:30,750 to enable resource logging on a given resource 789 00:28:30,750 --> 00:28:33,070 and standing up a log analytics thing or 790 00:28:33,070 --> 00:28:34,910 dumping your logs to a storage account and 791 00:28:34,910 --> 00:28:36,750 then worrying half, how do I download it? 792 00:28:36,750 --> 00:28:38,850 What's the scheme of the JSON file? 793 00:28:39,304 --> 00:28:40,765 All those kinds of things 794 00:28:41,224 --> 00:28:43,065 that come along with it along the way. 795 00:28:43,065 --> 00:28:43,565 Yes. 796 00:28:43,865 --> 00:28:46,345 Absolutely. Your audio wasn't going through the Discord. 797 00:28:46,345 --> 00:28:48,585 That was my fault. Yeah. Teams. It goes 798 00:28:48,585 --> 00:28:50,285 back to my Teams issue at the beginning. 799 00:28:50,825 --> 00:28:52,190 But, yeah, absolutely. 800 00:28:52,490 --> 00:28:54,569 Excellent points on all of that. Trying to 801 00:28:54,569 --> 00:28:57,130 think. Activity logs. We got platform metrics. We 802 00:28:57,130 --> 00:28:59,609 have resource logs. Which did you know? We 803 00:28:59,609 --> 00:29:02,409 have all that log data, Entra. Yes. And 804 00:29:02,409 --> 00:29:03,929 I'm gonna tie this back. The log data 805 00:29:03,929 --> 00:29:06,649 in Entra has been there. I noticed it 806 00:29:06,649 --> 00:29:07,149 with 807 00:29:07,505 --> 00:29:09,424 global secure access and some of the enhanced 808 00:29:09,424 --> 00:29:11,025 logging you can do now, because this is 809 00:29:11,025 --> 00:29:14,144 a requirement for enhanced logging, is you can 810 00:29:14,144 --> 00:29:18,225 actually configure Entra diagnostic settings. So these resource 811 00:29:18,225 --> 00:29:20,970 logs we just talked about, Entra has resource 812 00:29:20,970 --> 00:29:23,710 logs where you can go set up Entra 813 00:29:24,250 --> 00:29:24,750 to 814 00:29:25,450 --> 00:29:28,029 send its essentially diagnostic 815 00:29:28,330 --> 00:29:31,130 logs into log analytics as well. Mhmm. I 816 00:29:31,130 --> 00:29:32,815 don't know how long that's been there, but 817 00:29:32,815 --> 00:29:34,494 I haven't always had that set up because 818 00:29:34,494 --> 00:29:36,174 I haven't had a need to until I 819 00:29:36,174 --> 00:29:38,335 was playing with Global Secure Access. So for 820 00:29:38,335 --> 00:29:41,375 these things like monitor, entry ID, or like 821 00:29:41,375 --> 00:29:43,615 the activity log, entry ID logs, things like 822 00:29:43,615 --> 00:29:46,335 that, where they're there by default, but maybe 823 00:29:46,335 --> 00:29:48,569 they're not pumping their data out to to 824 00:29:48,569 --> 00:29:51,130 another source like Log Analytics. The reason that 825 00:29:51,130 --> 00:29:52,569 you start to pump the data out to 826 00:29:52,569 --> 00:29:54,809 Log Analytics, or maybe you go and you 827 00:29:54,809 --> 00:29:58,329 look at security specific offerings like Sentinel or 828 00:29:58,329 --> 00:30:00,089 things like that, that can ingest that data 829 00:30:00,089 --> 00:30:01,450 for you, or they can act as a 830 00:30:01,450 --> 00:30:03,549 target or a sync source for that data, 831 00:30:03,694 --> 00:30:05,775 is because you wanna retain it longer, or 832 00:30:05,775 --> 00:30:07,615 because you wanna start to get that crosscut 833 00:30:07,615 --> 00:30:08,115 visibility 834 00:30:08,894 --> 00:30:10,355 and insights into, 835 00:30:10,734 --> 00:30:12,734 do I need to correlate an event that 836 00:30:12,734 --> 00:30:14,734 happened in enter ID to an event that 837 00:30:14,734 --> 00:30:17,890 happened in the activity log to ultimately an 838 00:30:17,890 --> 00:30:19,410 interaction on the data plane in one of 839 00:30:19,410 --> 00:30:20,070 my resources. 840 00:30:20,609 --> 00:30:22,289 That might be something like, do we want 841 00:30:22,289 --> 00:30:24,130 the ability to track the malicious sign in? 842 00:30:24,130 --> 00:30:26,289 Say there was like a phishing hack, and 843 00:30:26,289 --> 00:30:29,410 somebody got in with some admin credentials to 844 00:30:29,410 --> 00:30:32,005 your enter ID tenant, And then from there, 845 00:30:32,005 --> 00:30:34,484 they created another user, they created a service 846 00:30:34,484 --> 00:30:36,244 principal, and they gave that some kind of 847 00:30:36,244 --> 00:30:37,865 elevated rates in your environment, 848 00:30:38,325 --> 00:30:40,724 and then they connected with that user. Great. 849 00:30:40,724 --> 00:30:42,904 The login attempt up here is in Entra, 850 00:30:43,180 --> 00:30:45,820 and then the other interaction now is down 851 00:30:45,820 --> 00:30:47,580 in the activity log, and then all the 852 00:30:47,580 --> 00:30:49,420 way down to what they do while they 853 00:30:49,420 --> 00:30:51,980 were there. Oh, I can see that they 854 00:30:51,980 --> 00:30:52,880 went into 855 00:30:53,420 --> 00:30:55,519 my storage account, and they changed the configuration 856 00:30:55,660 --> 00:30:57,704 of a container on my storage account, and 857 00:30:57,704 --> 00:31:00,105 they enabled it for public access, like public 858 00:31:00,105 --> 00:31:02,025 and on access. And then I tie that 859 00:31:02,025 --> 00:31:03,384 back to a metric, and I see that 860 00:31:03,384 --> 00:31:06,505 they egress some data or something like that 861 00:31:06,505 --> 00:31:09,144 along the way. You know, so it's, like, 862 00:31:09,144 --> 00:31:11,309 a little convoluted. I I I think, if 863 00:31:11,309 --> 00:31:13,169 you're not, like, deep and 864 00:31:13,789 --> 00:31:15,869 and, like, familiar with it and you haven't 865 00:31:15,869 --> 00:31:17,630 touched it all. But once you start to 866 00:31:17,630 --> 00:31:19,710 touch it all, it it starts to make 867 00:31:19,710 --> 00:31:21,789 sense because you're just decomposing it into the 868 00:31:21,789 --> 00:31:22,690 various layers. 869 00:31:23,015 --> 00:31:25,335 So really, you're walking through, like, the various 870 00:31:25,335 --> 00:31:28,315 API surfaces, right, like, Entra and Graph, 871 00:31:28,775 --> 00:31:29,674 down to 872 00:31:30,055 --> 00:31:32,715 Azure and Arm, and the control plane, ultimately 873 00:31:32,775 --> 00:31:34,695 maybe back to, like, data plane within an 874 00:31:34,695 --> 00:31:36,455 Azure service, if it happens to have a 875 00:31:36,455 --> 00:31:37,115 data plane. 876 00:31:37,579 --> 00:31:39,579 Not all services have data planes. Some of 877 00:31:39,579 --> 00:31:41,759 them only have control plane interactions. 878 00:31:42,220 --> 00:31:44,299 It's hit or miss depending on the service, 879 00:31:44,299 --> 00:31:45,579 so you do have to know what you're 880 00:31:45,579 --> 00:31:47,660 going for service by service. And someone in 881 00:31:47,660 --> 00:31:51,194 Discord was just asking to, like, being able 882 00:31:51,194 --> 00:31:54,154 to track who created, like, a function app 883 00:31:54,154 --> 00:31:56,315 and when they created it and stuff and 884 00:31:56,315 --> 00:31:57,835 where those would be. That would be more 885 00:31:57,835 --> 00:32:00,474 of that Azure activity log. That's gonna be 886 00:32:00,474 --> 00:32:03,275 logging more of those, and we had talked 887 00:32:03,275 --> 00:32:04,554 about a little bit more of those control 888 00:32:04,554 --> 00:32:05,960 plane creating those. 889 00:32:06,900 --> 00:32:08,980 But I do agree everything you just said 890 00:32:08,980 --> 00:32:11,700 about logging, and that's why I personally logging 891 00:32:11,700 --> 00:32:13,619 all of these to log analytics. We'll probably 892 00:32:13,619 --> 00:32:16,419 start talking about more security stuff in future 893 00:32:16,419 --> 00:32:16,919 episodes. 894 00:32:17,375 --> 00:32:19,075 To your point of 895 00:32:19,535 --> 00:32:22,414 it's these different APIs, it's these different control 896 00:32:22,414 --> 00:32:22,914 planes, 897 00:32:23,375 --> 00:32:25,695 but then somebody gets into NTRIC, gets into 898 00:32:25,695 --> 00:32:27,535 a storage account, finds a file out there 899 00:32:27,535 --> 00:32:29,134 that has other login data, and then they 900 00:32:29,134 --> 00:32:31,215 go log in to SharePoint and pull information 901 00:32:31,215 --> 00:32:32,035 out of SharePoint. 902 00:32:32,980 --> 00:32:34,980 It in my opinion, it's really important when 903 00:32:34,980 --> 00:32:37,940 you have this wide range of things. Like 904 00:32:37,940 --> 00:32:40,579 you said, bring all of those logs into 905 00:32:40,579 --> 00:32:43,799 one central spot. So when you are investigating 906 00:32:44,099 --> 00:32:46,955 an incident or doing some type of threat 907 00:32:46,955 --> 00:32:48,715 hunting or if you wanna set up some 908 00:32:48,715 --> 00:32:49,615 type of alerting, 909 00:32:49,994 --> 00:32:52,075 all these logs are together, and you're not 910 00:32:52,075 --> 00:32:54,394 jumping between the entry ID sign in log 911 00:32:54,394 --> 00:32:56,955 and then over to the SharePoint audit log 912 00:32:56,955 --> 00:33:00,069 and then over to the Azure activity log 913 00:33:00,069 --> 00:33:02,869 and then jumping back into your diagnostic logs 914 00:33:02,869 --> 00:33:05,509 for your storage account. It gets really hard 915 00:33:05,509 --> 00:33:06,009 to 916 00:33:06,549 --> 00:33:09,130 correlate everything when they're all in these disjointed 917 00:33:09,190 --> 00:33:11,690 places, and that's where I think log analytics 918 00:33:12,149 --> 00:33:12,649 and 919 00:33:13,065 --> 00:33:14,984 Sentinel, if we talk about Sentinel in the 920 00:33:14,984 --> 00:33:15,484 future, 921 00:33:16,184 --> 00:33:18,365 really give you a good security 922 00:33:18,904 --> 00:33:20,744 benefit when it comes to being able to 923 00:33:20,744 --> 00:33:22,264 pull all of this together. So it's an 924 00:33:22,264 --> 00:33:24,684 interesting conversation. I have it with customers 925 00:33:25,384 --> 00:33:26,204 quite a bit. 926 00:33:27,450 --> 00:33:27,950 There's 927 00:33:28,410 --> 00:33:29,630 the class of customers 928 00:33:30,170 --> 00:33:31,390 that is 929 00:33:32,250 --> 00:33:32,750 scrappy. 930 00:33:33,049 --> 00:33:35,769 I absolutely understand the motivations, where they're coming 931 00:33:35,769 --> 00:33:37,929 from, and they want these things to be 932 00:33:37,929 --> 00:33:40,025 free. In that world where they want them 933 00:33:40,025 --> 00:33:41,384 to be free, they kind of stick with 934 00:33:41,384 --> 00:33:43,545 the free offerings. So they do these things 935 00:33:43,545 --> 00:33:45,964 where they end up building bespoke tooling, 936 00:33:46,505 --> 00:33:47,404 say, to 937 00:33:48,265 --> 00:33:50,684 use the graph PowerShell commandlets 938 00:33:51,929 --> 00:33:52,669 to query 939 00:33:52,970 --> 00:33:55,049 the the sign in logs and things like 940 00:33:55,049 --> 00:33:58,349 that from Entra. And then they go and 941 00:33:58,409 --> 00:34:01,529 they wire up a CLI command to extract 942 00:34:01,529 --> 00:34:04,349 metrics from over here, and they build these. 943 00:34:05,654 --> 00:34:08,135 It's gonna come across as, like, derogatory. I 944 00:34:08,135 --> 00:34:09,734 don't mean it to be that way. You 945 00:34:09,734 --> 00:34:12,074 end up building these, like, Rube Goldberg machines 946 00:34:12,295 --> 00:34:14,554 that that are just these mismatches of things. 947 00:34:14,695 --> 00:34:16,934 And they accomplish their goals in many cases, 948 00:34:16,934 --> 00:34:18,534 like, they figured it out and they learn 949 00:34:18,534 --> 00:34:20,199 how to get there, and they think in 950 00:34:20,199 --> 00:34:21,719 their heads they did it on the cheap. 951 00:34:21,719 --> 00:34:23,400 But the reality is they had to invest 952 00:34:23,400 --> 00:34:25,719 all the time into building that bespoke tooling 953 00:34:25,719 --> 00:34:28,039 and doing all those things. And ultimately, you 954 00:34:28,039 --> 00:34:30,280 still need to spin up the compute. And 955 00:34:30,280 --> 00:34:31,719 and the compute is what costs you the 956 00:34:31,719 --> 00:34:33,800 money in these scenarios is, k, I need 957 00:34:33,800 --> 00:34:36,275 to wire something up that can be online 958 00:34:36,655 --> 00:34:38,974 and available with networking and disks so it 959 00:34:38,974 --> 00:34:40,574 can talk to that other thing and bring 960 00:34:40,574 --> 00:34:43,135 it down and ingest it. I caution folks 961 00:34:43,135 --> 00:34:44,894 about they get into their heads very quickly. 962 00:34:44,894 --> 00:34:46,574 They look at the pricing of Log Analytics 963 00:34:46,574 --> 00:34:48,094 or Sentinel or things like that, and they 964 00:34:48,094 --> 00:34:49,780 go, too much money. I can just go 965 00:34:49,780 --> 00:34:51,299 send my engineer off, and they can take 966 00:34:51,299 --> 00:34:53,380 3 months and build it for me. Your 967 00:34:53,380 --> 00:34:55,139 engineer that just built that thing for 3 968 00:34:55,139 --> 00:34:57,299 months, depending on their salary, you might have 969 00:34:57,299 --> 00:34:59,059 been able to buy a year of Log 970 00:34:59,059 --> 00:35:02,260 Analytics at your ingestion rate. It all depends 971 00:35:02,260 --> 00:35:04,304 on your environment, like what rate you have 972 00:35:04,304 --> 00:35:06,565 and rate of change and churn and retention 973 00:35:06,784 --> 00:35:08,405 and those things that you want 974 00:35:09,025 --> 00:35:10,405 along the way. But, 975 00:35:10,784 --> 00:35:11,984 I I think if you take a step 976 00:35:11,984 --> 00:35:13,664 back and you peel it back, like some 977 00:35:13,664 --> 00:35:15,344 of these things that look like they cost 978 00:35:15,344 --> 00:35:16,619 a lot of money when it comes to 979 00:35:16,700 --> 00:35:17,200 security, 980 00:35:17,740 --> 00:35:19,740 they're like a net wash when it comes 981 00:35:19,740 --> 00:35:20,240 to 982 00:35:20,619 --> 00:35:21,119 resourcing 983 00:35:21,420 --> 00:35:22,320 and operations 984 00:35:22,860 --> 00:35:25,180 and things like that. You do have to 985 00:35:25,180 --> 00:35:27,340 keep those things in mind. Oh, yeah. Another 986 00:35:27,340 --> 00:35:28,860 interesting question in the chat. So if you 987 00:35:28,860 --> 00:35:31,200 use a third party SIEM instead of Sentinel, 988 00:35:31,565 --> 00:35:34,204 would you consider log analytics aggregation doubling up 989 00:35:34,204 --> 00:35:35,585 on a function? So 990 00:35:37,005 --> 00:35:39,425 you don't have to Maybe. Install. I I 991 00:35:39,485 --> 00:35:41,345 I think is the yeah. 992 00:35:41,805 --> 00:35:43,905 But I think this is another misnomer 993 00:35:44,510 --> 00:35:47,329 is, like, customers feel that they're 994 00:35:48,030 --> 00:35:49,389 locked in, and I I get it. To 995 00:35:49,389 --> 00:35:50,670 a certain degree, you are locked in. Right? 996 00:35:50,670 --> 00:35:52,589 If you're an Entree customer, absolutely. You're using 997 00:35:52,589 --> 00:35:54,690 Entree. You really don't have another choice there. 998 00:35:54,829 --> 00:35:56,989 That is the identity provider for Azure and 999 00:35:56,989 --> 00:35:57,489 M365. 1000 00:35:58,030 --> 00:36:00,005 So you you can do things like have 1001 00:36:00,005 --> 00:36:02,485 your IdP, Okta, or whatever, as the relying 1002 00:36:02,485 --> 00:36:04,164 party, but the reality is you're using Entra 1003 00:36:04,164 --> 00:36:05,525 at the end of the day. Some stuff 1004 00:36:05,525 --> 00:36:06,965 you can't fight. Some of these things you 1005 00:36:06,965 --> 00:36:08,965 can. Do you have to use Sentinel? No. 1006 00:36:08,965 --> 00:36:10,265 Do you have to use Log Analytics? 1007 00:36:10,910 --> 00:36:13,789 Absolutely not. You can do things like build 1008 00:36:13,789 --> 00:36:14,610 out that integration 1009 00:36:14,910 --> 00:36:18,190 for those diagnostic logs, which can include metrics 1010 00:36:18,190 --> 00:36:19,869 in them. They're not just resource logs. You 1011 00:36:19,869 --> 00:36:21,869 can pump out the metrics as well. You 1012 00:36:21,869 --> 00:36:23,789 can build out those integrations around things like 1013 00:36:23,789 --> 00:36:25,984 Event Grid and pump those out 1014 00:36:26,284 --> 00:36:28,605 to any system that you want to. I 1015 00:36:28,605 --> 00:36:30,525 have no expectation that every customer who comes 1016 00:36:30,525 --> 00:36:32,784 to me who says, I'm a Splunk shop, 1017 00:36:33,164 --> 00:36:36,444 is immediately going to go and turn the 1018 00:36:36,444 --> 00:36:39,349 switch and learn Kusto and start doing Sentinel 1019 00:36:39,409 --> 00:36:41,489 or log analytics tomorrow. That's not good for 1020 00:36:41,489 --> 00:36:43,730 them. They're already a Splunk shop. Or you 1021 00:36:43,730 --> 00:36:46,069 might have another solution that's out there. So 1022 00:36:46,369 --> 00:36:48,449 90 ish percent of the time, and it's 1023 00:36:48,449 --> 00:36:49,969 almost a 100% of the time with, like, 1024 00:36:49,969 --> 00:36:52,735 the really large providers out there, they're going 1025 00:36:52,735 --> 00:36:54,034 to have some integration 1026 00:36:54,414 --> 00:36:55,855 that is going to be able to hook 1027 00:36:55,855 --> 00:36:56,355 into 1028 00:36:56,974 --> 00:36:59,775 Event Grid and the eventing system. That's a 1029 00:36:59,775 --> 00:37:02,335 core service within Azure. Right? It's available. It's 1030 00:37:02,335 --> 00:37:02,835 scalable. 1031 00:37:03,215 --> 00:37:05,054 It it will do all those things for 1032 00:37:05,054 --> 00:37:07,000 you, and it it would allow you to 1033 00:37:07,000 --> 00:37:08,599 put that data out to where it needs 1034 00:37:08,599 --> 00:37:11,960 to be. Your answer of maybe classic consulting 1035 00:37:11,960 --> 00:37:12,460 101, 1036 00:37:12,839 --> 00:37:15,079 but very true, there might be pieces of 1037 00:37:15,079 --> 00:37:15,579 functionality 1038 00:37:16,119 --> 00:37:19,179 that you could absolutely replicate and do yourself. 1039 00:37:19,295 --> 00:37:21,135 It's just, to my point earlier, it's not 1040 00:37:21,135 --> 00:37:23,375 worth your time, right? Like the engineering effort 1041 00:37:23,375 --> 00:37:24,195 that you'll invest 1042 00:37:24,575 --> 00:37:26,735 to duplicate some of these solutions when they've 1043 00:37:26,735 --> 00:37:28,894 already been done and built for you, I 1044 00:37:28,894 --> 00:37:30,414 I really do think you need to have 1045 00:37:30,414 --> 00:37:31,555 that kind of rationalization 1046 00:37:31,934 --> 00:37:32,434 moment 1047 00:37:32,735 --> 00:37:35,429 of, do I want my engineer to take 1048 00:37:35,429 --> 00:37:37,989 a day, a week, a month, a year, 1049 00:37:37,989 --> 00:37:40,469 whatever it is to build this thing, or 1050 00:37:40,469 --> 00:37:42,150 can I just buy it and be done 1051 00:37:42,150 --> 00:37:43,909 with it? Let's be honest, like you're in 1052 00:37:43,909 --> 00:37:45,989 a pay go service anyway, everything's not gonna 1053 00:37:45,989 --> 00:37:48,265 be free for you. Be smart and pick 1054 00:37:48,265 --> 00:37:50,184 and choose where you're spending your money. Yeah. 1055 00:37:50,184 --> 00:37:52,905 And, right, it depends too is we're looking 1056 00:37:52,905 --> 00:37:54,585 at this from a security lens. So I 1057 00:37:54,585 --> 00:37:56,605 would say from a security lens, 1058 00:37:57,065 --> 00:37:59,485 if you are sending everything to Log Analytics 1059 00:37:59,704 --> 00:38:01,885 and everything to a third party SIEM, 1060 00:38:02,369 --> 00:38:04,849 yeah, you're probably doubling up on a lot 1061 00:38:04,849 --> 00:38:06,469 of stuff that you don't need to be. 1062 00:38:06,529 --> 00:38:07,589 That being said, 1063 00:38:07,969 --> 00:38:10,869 Log Analytics is also not just security. So 1064 00:38:11,089 --> 00:38:12,309 I actually have 1065 00:38:12,609 --> 00:38:14,614 some clients I've worked with as well that 1066 00:38:14,614 --> 00:38:16,855 have 2 log analytics instances. 1 that they 1067 00:38:16,855 --> 00:38:19,594 send everything to from a security standpoint or 1068 00:38:20,054 --> 00:38:20,954 even certain, 1069 00:38:21,414 --> 00:38:23,574 resource logs that they wanna look at from 1070 00:38:23,574 --> 00:38:25,894 a security perspective, and then I have another 1071 00:38:25,894 --> 00:38:29,139 one for, like, operations because, for instance, 1072 00:38:29,760 --> 00:38:31,299 Azure app services. 1073 00:38:31,599 --> 00:38:33,679 If you're hosting a website in there, part 1074 00:38:33,679 --> 00:38:36,819 of the resource logs or those diagnostic logs 1075 00:38:36,960 --> 00:38:38,880 are also used for app insights for doing 1076 00:38:38,880 --> 00:38:39,940 things like tracking 1077 00:38:40,335 --> 00:38:42,994 website visitors and response time on your website 1078 00:38:43,855 --> 00:38:44,835 and things that 1079 00:38:45,295 --> 00:38:46,514 operations developers, 1080 00:38:47,534 --> 00:38:48,355 your SEO 1081 00:38:48,734 --> 00:38:49,234 folks, 1082 00:38:49,534 --> 00:38:52,195 if they care about response time, certain, 1083 00:38:52,619 --> 00:38:55,179 depending on their role, may actually want some 1084 00:38:55,179 --> 00:38:56,799 of these logs. So you may 1085 00:38:57,099 --> 00:39:00,159 still want a certain aggregation in log analytics, 1086 00:39:00,779 --> 00:39:04,000 not from a security perspective, but from a 1087 00:39:04,380 --> 00:39:04,880 operations 1088 00:39:05,420 --> 00:39:07,839 monitoring perspective or from a debugging 1089 00:39:08,484 --> 00:39:11,045 perspective or from a we just wanna know 1090 00:39:11,045 --> 00:39:12,324 if there's an error on one of our 1091 00:39:12,324 --> 00:39:14,405 Windows servers, again, going back to some of 1092 00:39:14,405 --> 00:39:16,565 the operations. So I think from a pure 1093 00:39:16,565 --> 00:39:17,464 security perspective, 1094 00:39:17,844 --> 00:39:21,464 yes. There can absolutely be use cases for 1095 00:39:21,684 --> 00:39:22,585 sending data 1096 00:39:22,949 --> 00:39:26,070 either to both or even, again, sending sometimes 1097 00:39:26,070 --> 00:39:28,730 data to 2 different Log Analytics workspaces. 1098 00:39:29,190 --> 00:39:32,150 We mentioned the diagnostic logs. When you configure 1099 00:39:32,150 --> 00:39:34,150 those, you can send them multiple places. You 1100 00:39:34,150 --> 00:39:36,250 can send them to 3 or 4 different 1101 00:39:36,389 --> 00:39:39,045 locations. It's not, I'm only going to send 1102 00:39:39,045 --> 00:39:40,905 these logs to 1 or the other. Yeah. 1103 00:39:41,204 --> 00:39:43,284 It's like level of effort and things like 1104 00:39:43,284 --> 00:39:44,724 that, and I was saying you've inquired the 1105 00:39:44,724 --> 00:39:46,804 whole time. It's EventOps, mea culpa. So the 1106 00:39:46,804 --> 00:39:48,484 other thing to keep in mind too is 1107 00:39:48,484 --> 00:39:50,585 if you're a customer who's 1108 00:39:51,309 --> 00:39:53,809 coming to Azure with an existing solution 1109 00:39:54,269 --> 00:39:56,109 and you're, like, looking at this space and 1110 00:39:56,109 --> 00:39:58,029 you're going, yeah, I know there's some native 1111 00:39:58,029 --> 00:40:00,589 stuff, but maybe you are that customer who 1112 00:40:00,589 --> 00:40:04,109 has a third party SIEM or something else. 1113 00:40:04,109 --> 00:40:06,369 Maybe you use, like, a a different firewall. 1114 00:40:06,465 --> 00:40:08,465 Like, you you're out there using FortiGates and 1115 00:40:08,465 --> 00:40:10,325 you're, like, Azure Firewall is not my thing. 1116 00:40:10,465 --> 00:40:12,625 Those options are often available to you as 1117 00:40:12,625 --> 00:40:14,625 well. So it's not like you have to 1118 00:40:14,625 --> 00:40:17,125 completely ditch the ecosystems 1119 00:40:17,905 --> 00:40:19,744 that you're in today. There there there's a 1120 00:40:19,744 --> 00:40:22,550 pretty wide swath of partners 1121 00:40:23,010 --> 00:40:24,710 and ISV solutions 1122 00:40:25,570 --> 00:40:28,210 that are available to you. So like in 1123 00:40:28,210 --> 00:40:29,750 the monitoring space, 1124 00:40:30,449 --> 00:40:32,449 Elastic's there. So you can do like Elastic 1125 00:40:32,449 --> 00:40:36,315 Integrations, Elasticsearch, things like that. Datadog is another 1126 00:40:36,315 --> 00:40:38,394 one that I run into a lot. Like, 1127 00:40:38,394 --> 00:40:39,594 I end up working with a lot of 1128 00:40:39,594 --> 00:40:41,594 our cloud native customers and things like that, 1129 00:40:41,594 --> 00:40:43,755 like custom dev shops who are spinning things 1130 00:40:43,755 --> 00:40:45,135 up. So I see a lot of that. 1131 00:40:45,355 --> 00:40:47,835 You can do things like Event Hubs has 1132 00:40:47,835 --> 00:40:49,135 native Kafka integrations. 1133 00:40:49,640 --> 00:40:51,239 So if you're pumping data out and you 1134 00:40:51,239 --> 00:40:53,019 wanna pump it through Kafka 1135 00:40:53,400 --> 00:40:56,940 and then ingest that over in, say, Databricks 1136 00:40:57,079 --> 00:40:59,079 or do some Spark analysis on top of 1137 00:40:59,079 --> 00:41:00,920 it, that's just all available to you. It's 1138 00:41:00,920 --> 00:41:03,480 all possible. It's there. The hooks are there. 1139 00:41:03,480 --> 00:41:05,155 It's worth checking through the documentation 1140 00:41:06,014 --> 00:41:06,755 and seeing, 1141 00:41:07,054 --> 00:41:09,054 hey, is there something that's already here that's 1142 00:41:09,054 --> 00:41:11,295 in my wheelhouse that I'm familiar with so 1143 00:41:11,295 --> 00:41:12,675 that you don't need 1144 00:41:13,534 --> 00:41:15,775 to reinvent the wheel. And I think that's 1145 00:41:15,775 --> 00:41:18,114 a big consideration, right? Because if you're reinventing 1146 00:41:18,175 --> 00:41:19,630 the wheel or you're at it net new 1147 00:41:19,630 --> 00:41:21,309 and you've never done it before, it's not 1148 00:41:21,309 --> 00:41:23,230 like an immediate security hole, but it's a 1149 00:41:23,230 --> 00:41:24,829 gap for you. And the and the more 1150 00:41:24,829 --> 00:41:26,130 gaps you have in that observability, 1151 00:41:26,590 --> 00:41:29,150 the less comfort factor you have, and you 1152 00:41:29,150 --> 00:41:30,670 start to go down the weird rabbit hole 1153 00:41:30,670 --> 00:41:33,074 in your own head sometimes about it. Ultimately, 1154 00:41:33,074 --> 00:41:35,315 like, the cloud is about plugging a a 1155 00:41:35,315 --> 00:41:36,614 bunch of pieces together. 1156 00:41:36,914 --> 00:41:38,355 I I always think about it as like 1157 00:41:38,355 --> 00:41:40,434 Lego bricks and every if I gave you 1158 00:41:40,434 --> 00:41:42,434 a bucket of Lego bricks and it had 1159 00:41:42,434 --> 00:41:43,875 a 100 different colors in it and I 1160 00:41:43,875 --> 00:41:44,994 just spilled it on the floor and I 1161 00:41:44,994 --> 00:41:46,920 said build me a house, you're gonna build 1162 00:41:46,920 --> 00:41:48,380 something that looks like a house. 1163 00:41:48,679 --> 00:41:51,400 Your house might have 4 walls, and the 1164 00:41:51,400 --> 00:41:53,480 one my overachieving son builds is gonna have 1165 00:41:53,480 --> 00:41:55,880 6, whatever it is. But it's still gonna 1166 00:41:55,880 --> 00:41:58,280 be a house, and that's okay. You're not 1167 00:41:58,280 --> 00:41:59,994 gonna necessarily land on the same solution that 1168 00:41:59,994 --> 00:42:00,133 somebody else did. I see a lot of 1169 00:42:00,133 --> 00:42:00,273 customers that are like, just tell me how 1170 00:42:00,273 --> 00:42:01,065 the other customer did it. I'm like, somebody 1171 00:42:01,065 --> 00:42:02,184 else did. I see a lot of customers 1172 00:42:02,184 --> 00:42:03,545 who are like, just tell me how the 1173 00:42:03,545 --> 00:42:05,464 other customer did it. I'm like, I I 1174 00:42:05,464 --> 00:42:06,605 really don't want to. 1175 00:42:06,905 --> 00:42:08,204 We're not gonna be bespoke, 1176 00:42:08,824 --> 00:42:10,284 and it's not like everything's 1177 00:42:10,585 --> 00:42:13,065 in, you know, a unique snowflake that fell 1178 00:42:13,065 --> 00:42:13,804 on the ground, 1179 00:42:14,340 --> 00:42:14,840 but 1180 00:42:15,380 --> 00:42:16,440 at the same time, 1181 00:42:17,059 --> 00:42:18,739 we're all gonna be a little bit different. 1182 00:42:18,739 --> 00:42:19,640 And that's okay. 1183 00:42:19,940 --> 00:42:22,119 That's the place we're gonna land. Yep. Agree. 1184 00:42:22,420 --> 00:42:23,780 Scott, when we said at the beginning of 1185 00:42:23,780 --> 00:42:25,300 this episode, we're gonna keep an eye on 1186 00:42:25,300 --> 00:42:27,539 time and quit out 30 minutes. Yeah. And 1187 00:42:27,539 --> 00:42:29,264 we didn't even make it past, like, metrics 1188 00:42:29,344 --> 00:42:31,424 and resource logs. Who saw that coming? Not 1189 00:42:31,424 --> 00:42:33,264 me. Maybe we need to rename this to, 1190 00:42:33,264 --> 00:42:36,244 like, the Microsoft Cloud Security Podcasts. 1191 00:42:37,505 --> 00:42:38,005 Something 1192 00:42:38,464 --> 00:42:38,964 observability. 1193 00:42:39,824 --> 00:42:41,105 Yeah. We can probably cut it here. I 1194 00:42:41,105 --> 00:42:42,989 think that's a good kinda grounding 1195 00:42:43,369 --> 00:42:44,110 and an overview 1196 00:42:44,809 --> 00:42:46,590 of Log. Some of the observability 1197 00:42:46,890 --> 00:42:47,390 pieces 1198 00:42:47,690 --> 00:42:49,849 and some things to think about there. We 1199 00:42:49,849 --> 00:42:52,090 should definitely come back and revisit some of 1200 00:42:52,090 --> 00:42:52,590 the 1201 00:42:53,050 --> 00:42:55,210 native tooling that's there. I I think it's 1202 00:42:55,210 --> 00:42:56,670 worth talking about. Sentinel 1203 00:42:57,434 --> 00:42:59,114 and and some of the other things there, 1204 00:42:59,114 --> 00:43:01,835 Defender, which we've talked about Microsoft Defender in 1205 00:43:01,835 --> 00:43:03,994 context of Lakeham 365. I don't know that 1206 00:43:03,994 --> 00:43:06,235 we've ever talked about Defender for Cloud and 1207 00:43:06,235 --> 00:43:07,675 some of the integrations that come on the 1208 00:43:07,675 --> 00:43:10,015 Azure side. There's a bunch of third party 1209 00:43:10,075 --> 00:43:11,670 stuff out there. So, yeah, we can just 1210 00:43:11,750 --> 00:43:13,510 keep running with this one for a while. 1211 00:43:13,510 --> 00:43:15,109 I think that might be the plan. We'll 1212 00:43:15,109 --> 00:43:16,710 see how long it goes. Not how long 1213 00:43:16,710 --> 00:43:18,150 we can drag it out. We don't wanna 1214 00:43:18,150 --> 00:43:19,210 drag it out, but 1215 00:43:19,510 --> 00:43:21,109 how long it takes us to cover it 1216 00:43:21,109 --> 00:43:22,569 to our satisfaction? 1217 00:43:22,869 --> 00:43:23,369 2025. 1218 00:43:23,829 --> 00:43:27,265 Here we come. Perfect. Alright. Scott, go enjoy 1219 00:43:27,265 --> 00:43:27,925 your weekend. 1220 00:43:28,385 --> 00:43:31,345 Sounds good. Rest. Relax. As always. Thanks, Ben. 1221 00:43:31,345 --> 00:43:33,285 Thank you. Alright. Have a good one. 1222 00:43:35,184 --> 00:43:37,440 If you enjoyed the podcast, go leave us 1223 00:43:37,440 --> 00:43:39,679 a 5 star rating in iTunes. It helps 1224 00:43:39,679 --> 00:43:41,440 to get the word out so more IT 1225 00:43:41,440 --> 00:43:43,219 pros can learn about Office 365 1226 00:43:43,519 --> 00:43:44,179 and Azure. 1227 00:43:44,719 --> 00:43:46,400 If you have any questions you want us 1228 00:43:46,400 --> 00:43:48,559 to address on the show or feedback about 1229 00:43:48,559 --> 00:43:50,960 the show, feel free to reach out via 1230 00:43:50,960 --> 00:43:51,619 our website, 1231 00:43:51,936 --> 00:43:53,155 Twitter, or Facebook. 1232 00:43:53,456 --> 00:43:55,296 Thanks again for listening, and have a great 1233 00:43:55,296 --> 00:43:55,796 day.

Digital Dispatch Podcast Podcast Artwork Image

Microsoft Cloud IT Pro Podcast

Ben Stegink, Scott Hoag

On the MS Cloud IT Pro Podcast, Scott and Ben discuss the Microsoft Cloud with a focus on IT Pros. They'll discuss the latest in Microsoft 365 and Office 365 News, Azure news and talk about their experiences with managing the Microsoft Cloud as well as interview industry experts on various cloud technology. They'll cover things such as SharePoint, Exchange, Microsoft Teams, PowerShell, Azure, Azure AD, Security, Networking, Storage, and the many other technologies and products that have made their way into the Microsoft 365 suite and Azure. To stay up-to-date on the latest in Microsoft Cloud news and gain some valuable knowledge as you deploy it within your own organization, make sure to tune in every week! Find out more at msclouditpropodcast.com.

Contact Show