SC-100 Cybersecurity Architect Expert Certification Study Cram PDF

SC-100 Cybersecurity Architect Expert Certification Study Cram Hey everyone, welcome to this SC100 study cram, hopefully trying to help you get the new cyber security architect expert certification. As always, if this is useful a like and subscribe is appreciated. So the focus here is for this cyber...

SC-100 Cybersecurity Architect Expert Certification Study Cram Hey everyone, welcome to this SC100 study cram, hopefully trying to help you get the new cyber security architect expert certification. As always, if this is useful a like and subscribe is appreciated. So the focus here is for this cyber security architect expert certification certification. And so we get this via the SC100 new exam that at the time of recording is in beta. Now, in addition to taking this exam, you also need to have taken either SC200, SC300, AZ500 or the MS500. So it's either one of these and then you add in the SC100 to get this new certification. So you have a lot of flexibility there, you just need one of them and then you're good to go. If we actually go and look at the page for the certification, we can see it talks about, hey, yes, the SC100 exam. And then it does talk about the actual certification itself and it shows you the path. Hey, one of these prerequisites, then take the exam and then you get that certification. On the exam page, it goes through how you can schedule the exam. Pay really close attention to this exam skills outline. You always want to go and look at this. This goes through all of the individual skills that you want to be able to check a box next to and say, yes, I understand those. I'm good with all of those various things. Now, one of the key things you will notice as you go through this, and I did just take the exam. So I just took the exam so I could get an understanding of what is the level that we need to understand for this. It's a two hour exam. I had about 45, 46 questions, but it's very broad and it kind of hints at that. I can take any of these as a prerequisite. And then the SC100 exam really covers the full scope of all of the different security solutions across all of Azure and Microsoft 365. It's all of those. So I need to have very broad understanding of what the different solutions do, the capabilities they bring. But I don't need to know any of them to any depth. There is no how would I do that in the solution. It's none of those. It's very basic questions. Hey, I need to meet this requirement. Which solution would I use or which solutions could make up part of this solution? I finished in 30 minutes. Now, there were case studies. I didn't read them. I was actually in a rush, but it was pretty obvious most of the time what you wanted to do. Maybe you would quickly go and, hey, based on business requirements. So go and look at the business requirements tab and then whatever it might be. There was no hands on lab. Most of them, they were pretty short questions. Again, it took me half an hour. I'm not saying I passed, but it took me half an hour and I was done and I felt pretty comfortable. I had plenty of time to read the questions and pick the right answer. So it is very short and sweet. It's just a broad exam. Again, it is in beta right now, so you won't get the results until it actually releases. And then it can take a couple of weeks after it releases. So you're taking it. You don't know exactly what you're going to do. So it's not super complex. It's not super deep. You just need to have a pretty good idea of which technologies solve which types of problems. So that's what I'm going to focus on in this study, Cram. I'm going to really go through the different elements we think about and then what solutions would be part of those different requirements that I might have. Now, a key thing to think in mind as we go through all of this is a big focus today is all about zero trust. So keep that in mind through the entire exam. And there are three key principles to this. I did a whole video on zero trust. You should go and kind of watch that to get more information about it. But we always think about verify explicitly. I'm not trusting just because something's on a certain network that it's good. No, we're constantly going to verify, we're going to revalidate the identity. If it's a user, a service principle, everything. The device that's being used, we want to try and validate that as well. So we're going to verify everything explicitly. We want to use least privilege. We have this idea of just enough permission. So the role that just gives me the permissions I need to do something, I'm not going to share identities. Ideally, I want it only when I need it. So we think about things like privileged identity management. We elevate up to a role when we require it. And that really builds into these is we assume breach. Once again, we're not trusting that network. We look at signals, we look at telemetry. So we're constantly looking for some indicator of something bad happening, a malicious actor, some ransomware, whatever that might be. We're going to gather as many signals as we can from everywhere we can, because obviously the more signals, the better context we can get, the better intelligence we can apply to look for some sign of compromise. So it's all about signals and they're making a decision to enforce certain types of access. Now, as you go through this, Microsoft has a whole cybersecurity set of reference architecture. And what I would recommend is actually go and download this. So it's a PowerPoint and it's a huge number of basically pictures that go through all the things you might think about, different types of roles, different types of solutions, how they fit. So go and download the file and take some time to really go through that and understand all the different elements. So that's definitely a recommended resource that you want to use. So let's walk through the different actors, the different entities we have as part of our all up solution. So when I think about my environment, if I think about the first element, and this really is the key to the door, we think about identity. Now that identity we're thinking about, that's users, that's groups of users, that's service principles, that's applications. We have identities for all of these things. And in the cloud, when I think about identity, well, that's Azure AD. So we have this concept of our Azure Active Directory that contains users, groups, application registrations, devices. We have these different types of entity in there. Now, there are different SKUs that we license users for. I can think about, well, there's the free SKU, there's the Azure AD Premium P1, then there's the Azure AD Premium P2. Different features use different levels of these SKUs. There is a document that goes through all the differences actually between them. This is in the link below, but there's a feature comparison. You can see, well, with the free, sure, I get basic information. I can use the mobile app as a second factor. For my global administrators, they get more MFA type capabilities. But for most of the richer features, conditional access, flexible MFA for everybody, you're really getting into this Azure AD Premium P1 world. And then the P2 are more of the enterprise features, things like identity protection, access reviews, entitlement management, and PIM. So, those are key features. And we can, on a per-user basis, we can enable different people for the different features. So, we think about there are different SKUs available for this. Now, when I want to think about this protection, the cybersecurity types elements, and if I think about protecting the Azure AD identities, and this could be users, in preview right now is service principles as well, so workload identities. So, we think about the Azure AD identity protection. So, the identity protection solution is a P2 feature. So, if I want intelligence about risk of an individual logon, risk of the overall users, and based on different types of signals coming in, well, that's Azure AD identity protection. So, it's P2, I'd need that license for these. I also think about, okay, great, that's going to give me signals of attack, but also I want strong authentication. We think about multi- factor authentication. Now, typically, MFA is a feature of P1. So, MFA with P1, I can use SMS, I can use phone calls, I can use hardware tokens, I can use the authenticator app, software tokens. With free, there is something called security defaults that I can turn on. So, security defaults does enable me to have an MFA for users, but it's only by the authenticator app, only through the software tokens, I can't use text. It also will turn off legacy authentication protocols. It tries to give me this locked down set of capabilities just by default for that. So, it's going to block the legacy authentication, it's going to make the users do MFA for what it considers an elevated type of access in the portal. It's going to make me do an MFA for that. But for P1, I get all of the different types of MFA available. And obviously, P1 introduces the idea of conditional access, which we're going to talk a lot more about. But conditional access is typically how we want to drive having to perform an MFA. Hey, I'm doing some elevated permission. And also, identity protection feeds into conditional access with risk information. So, hey, we're detecting an elevated risk. Okay, then conditional access is going to make you do an MFA or make you change your password or other things. But this drives that. So, we want the strong authentication MFA, security defaults gives us a limited predefined set of MFA. We can think about passwordless. I don't want a password at all. And that is available across the SKUs. Passwordless could be, hey, I'm using the Microsoft Authenticator app. I'm using hardware FIDO keys. I'm using Hello for Business. So, I have a passwordless option as well. Now, when I think of identity protection, it's great talking about the cloud and Azure AD identity protection and things like that. But realize, does our identity normally just burst into life in the cloud? It doesn't. For most of the time, what we actually have is we have an existing Active Directory domain services. So, I have my regular Active Directory domain services. And that has our users, our groups, et cetera, machines joined to it. I may optionally have something like ADFS, Active Directory Federation Services, where I'm federating the authentication authorization from maybe other cloud services so I can use my identities in my AD. I can even federate from Azure AD to AD via ADFS, but it's generally not recommended. It's better to just, hey, use conditional access and use cloud-based authentication. Now, what about if I want to protect the identities in here? Well, we have Defender for Identity. Now, this has gone through a number of name changes, but Defender for Identity, it deploys agents on all my domain controllers, and if I have it, my ADFS, and it feeds that into a cloud-based service. So, this is now going and looking for signs of compromise in my Active Directory environment, pass the hash, golden ticket, DNS dumping, a big sink of records, et cetera. It's looking for those types of indicators. So, it was like advanced threat protection, which I think was the old name. Now, it's Defender for Identity. So, we have these sensors on the domain controllers on my ADFS that's going to look for those signs of attack. Now, obviously, if my identities are originating here, I have to get them to the cloud some way. So, what we have is we have Azure AD Connect. Now, there's an Azure AD Connect Cloud Sync, where the engine runs in the cloud, but what they're doing is they're synchronizing mainly from AD to Azure AD. There's a few things that write back, but most of it is going that way. Now, one of the options we can turn on on this is I want to replicate and synchronize the hash of the password hash. So, it's not the original password hash, it's a hash of the hash. It's like a thousand SHA iterations, a per-user sort, so I can't reverse it. But if we add this, and this is the recommended, things like Azure AD Identity Protection can now look for things like leaked credentials, so it can stop things like a breach replay attack. So, by sending that hash of the hash, even if I'm not using CloudAuth, by adding that hash of the hash, now Identity Protection, when it's looking at the dark web, hey, it finds a leaked credential and it can compare the passwords to say, yes, this is compromised. So, then in my conditional access that gets signals from this, hey, the user is at risk, make them change their password. So, conditional access could drive that. So, I think about combining those things together. So, this is all about my corporate identities. Now, realize I may have other types of identity out there. I may have, for example, my partners that I collaborate with. So, my partners may have their own Azure AD. Maybe they have Microsoft accounts, maybe they have Gmail accounts, maybe they've got some other SAML or WSFED, maybe it's a one-time passcode, and I want to collaborate with them. Well, if I want to collaborate with them in my Azure AD, I can create a little stub object that represents that external identity. This is B2B functionality. So, it's people I want to collaborate with and applications and services I have that trust my Azure AD, could be SharePoint, could be Azure, could be an application I've created, I can add them using B2B as guests. So, now they'll show up, I can collaborate with them. That's very different from if I have customers. If I'm creating something for my customer, I don't want customers in my Azure AD. So, we have a separate type of Azure AD we can create, Azure AD B2C. So, this is now the customers have all their social accounts, Twitter, LinkedIn, whatever that might be, and they can use their social account in that Azure AD B2C instance. So, then the application you create that uses this, they can authenticate. I can still have local accounts if they don't have a social identity they want to use. I can customize every pixel of this experience. This is separate from my AD for my corporation. I'm going and creating a separate Azure AD and it's a special type B2C that has support for all of these different types of social identity they can bring and use in the application. So, that's really the key point around that from the identity perspective. So, identity is super important. I'm actually going to touch on a few other types of identity later on, but really think about, hey, I want to protect the identities in Azure AD. We have identity protection, that's users, that's service principles. I think about, hey, identity is in my regular Active Directory, hey, Defender for identity through agents can detect types of activity and then different ways to interact with external parties. Partners, hey, I want them to have an external identity. Customers, I don't want them in my Azure AD, completely separate instance. So, that's the identity. Well, those identities are used from something. So, I think about the next part is, well, there's the endpoint. I have some device that they're leveraging. Now, realize when I think about endpoints, there's a mass of different types. I can think about, well, there's computers, there's mobile devices, my iOS, my Android, there's things like IoT, there's printers, there's network, there's a mass of different types of devices that we have. And these could be on a corporate network, they could be on the internet. But remember, with zero trust, whether it's on our corporate network or not, for the most part, we're still going to treat it like the internet. We assume breach, we verify explicitly. If it's on my corporate network, I'm not going to bypass any checks. I treat it almost like it's on the internet as well. Now, one of the first things I want to do for these types of devices is what I can think about, especially here, I've got that Azure AD I talked about, users, I want to register these. Now, potentially, I may even join them. My Windows 10, my Windows 11 can actually join the Azure AD. But at minimum, I want them registered, they become known entities to my Azure Active Directory environment. Because from there, it starts to drive other types of capabilities in terms of managing the devices, managing in terms of applying policy, managing in terms of getting information about them so I can track compliance. From a solution perspective, when I think about the endpoints, there used to be two, and they've really combined together. So when I think about the endpoint protection, I'm going to shift to a slightly different colour. We think about Microsoft Endpoint Manager. Now, Microsoft Endpoint Manager is really combining two technologies. We can think about this idea of Microsoft Intune. That was all about our internet connected devices, our mobile devices, could be those Windows 10, Windows 11, etc. And then we had the idea of Configuration Manager. What were devices connected on our network? This could include servers as well, for example. So MEM is really combining these two things together. What I can do is I can actually have a co-management scenario, and I can think about using as much or as little as I want. I connect my Configuration Manager site to the cloud, to my Intune instance, and then I actually have the ability to, as a property of that co-management at Configuration Manager, say, well, which features do I want to manage from the cloud? Which do I still want to manage from Configuration Manager? Hey, compliance policies, endpoint protections, client apps, Office Click-to-Run, resource access policies. Hey, some of that I'll do in Config Manager, some of that I'll do in Intune. So I can pick the component I actually want to do. But what Microsoft Endpoint Manager is driving is, well, there's types of policy, for example. Now, with policy, I can do different things. I can think about compliance. Is it not jailbroken? Is it patched? Has it got these various things? And a huge part of compliance, so Microsoft Endpoint Manager can detect the compliance status of our devices. Is it healthy? Is it compliant? Well, with that information, that compliance status, we can actually feed back into Conditional Access, which we're going use later on to decide if we're going to allow access to something. So these all really connect together. I can also apply things like configuration. And think of this, once again, this goes across different types of devices. There's also other things like inventory. There's a whole set of different capabilities I have over here if I jump over super, super quickly. So if I exit out of that, I'm going to close all these down for a second. So firstly, if I was looking at the Azure AD, I talked about identity protection. So hey, it's got those user risk policies, sign-in risk policies. But you can see I can see things like risky users, risky workload identities, risky sign-ins, different types of risk detection. So I have all of those capabilities. I have the Defender for Identity. That's the on-premises. It's going and actually looking at for example, my various, I've got my sensors on my domain controllers installed. So I can see all those pieces of information there. And then when I think about my actual Endpoint Manager, so this is where I can go and look at those devices. They've got registered in Azure AD. Then I can go and manage them through Microsoft Endpoint Manager. We can see, hey look, Windows, Android, iOS, macOS, Windows Mobile. And through the devices, well I have these different types of capabilities. Hey look, I can create compliance policies. I can create configuration profiles. I could deploy software, deploy certificates, different things I want to do. But if I do a compliance policy, well I can create a policy. It's going to be based on the type of platform. It's going to see all the different platforms we get support from here. Likewise, if I was to actually create one of these, like say Windows 10, Windows 10 compliance policies, for example, but also I could do a configuration profile. And a configuration profile, once again, we get all the choices. And then I can say, well is this settings catalog? Is it based on the old style kind of ADMX type things we had with group policy? So we're not losing functionality. More and more the things we used to do with group policy, for example, I can now do with this as well. So we have all of those types of capabilities actually available to us. So think of Microsoft Endpoint Manager as I want to apply configuration, but also I want to understand the compliance of that device by creating the policies. And then I can use that compliance information to feed into things like conditional access, which I'm going to use to make decisions on access later on down the line. And again, you kind of pick that level. I might be all Configuration Manager. I might be all Intune. I might have that co-managed. I'm using different things for different parts. Often as a customer, we'll move through the stages. Maybe I started off Configuration Manager, then I'll start moving bits of functionality to the Intune until I'm 100% cloud- based. Now the other thing I can do is then we think about, so that was MEM, Microsoft Endpoint Manager. Another very important component we have, and I'll do a slightly different colour, is we have Defender for Endpoint. Now Defender for Endpoint is doing a number of different things. It's all about the idea of protecting, so stopping things happening, detecting, OK, something's happened and I want to know it's happened. I want to be able to trace the complete path of things. Hey, someone clicked on this thing, this thing then fired off this process, this process then went and spoke to this and then talked to these other machines. I want to be able to detect all of that happening and respond. So Defender for Endpoint is doing this. And one of the things Defender for Endpoint, as part of this detection, it can go and see, hey, something's happened. If there is a breach, I get visibility into it. I can isolate, respond to those attacks. It supports different types of endpoints. It can help me discover endpoints that maybe aren't managed. Windows endpoints, Windows Server endpoints, Linux, macOS, iOS and Android on mobile terms. It's going to give me information about them and then surface that information. And then based on the information, show me known vulnerabilities to help me go and actually protect them. It has a full threat and vulnerability management component. There's a dashboard. It has an exposure score. Helps me understand my entire organisation. And then, well, what are the biggest impacts to my devices so I can go and focus on those different severities, different patch levels and recommendations of what I should do first based on those highest priorities. And the key point here is when this detects a problem, maybe some machine has been attacked, it can actually feed that into the compliance state. So I can connect Defender for Endpoint into MEM so when it finds something has gone wrong. So, hey, a machine is flipped to non-compliant because there's a certain risk score. Well, that will then flip this policy, which then flips conditional access. When it's healed, hey, it will notify the compliance, get a new token and I'm good to go. So they work together to help give me these different levels of protections. So this is really a key component when I think about this. This whole protect, detect. There are things like attack surface reduction rules, i.e. all of the different places attacks can occur where a threat is likely to attack. I might block certain types of office apps from types of behaviour, block types of content from emails, different scripting rules, JavaScript, Python, macros, PowerShell, block those things. I can understand things like polymorphic threats. So it's going to look and block if something isn't running on a certain number of machines for a certain duration, it's not on a trusted list. Don't allow it. Don't allow things to run from USB. Stop lateral movement. Stop credential theft. Maybe types of behaviour from PS exec or WMI process creations. Don't steal things from the LSASS. So Defender for Endpoint is doing a whole bunch of different things. And yes, it has an antivirus, an anti-malware component. It has the basic sets of client heuristics based on signatures, but there's also local machine learning models for those kind of day zero things. It has cloud-based machine learning rules. It understands, hey, there's some suspicious file. Well, I can upload it for a deep neural network classification inspection, detonate it in a chamber to get a deeper analysis and classify those threats. There's a whole set of fantastic things that this Defender for Endpoint is doing, but it really is, sure, protect it. Antivirus, anti-malware, detect it. Okay, we're seeing these behaviours that help me actually respond to that. So there's really a key set of features around that. And there's automation to surface those recommendations and automatically respond to them. Maybe block that client straightaway, block those types of actions. So Defender for Endpoint layers on top of that. And then obviously I have these computers. I have these devices. And what that means is, well, there's also Defender for Servers. Now Defender for Servers does a whole bunch of different things. I'm going to come back to this a few different times. But when I think about the endpoint and protecting it, one of the things it does is it has this adaptive application hardening. And what that means is, again, it's this idea of machine learning. It looks at what normally runs. It creates an allow list. And then if things try and run this outside what it's observed, it's not going to let it run. It's going to stop those things happening. There's things like file integrity monitoring that's part of this as well. Core OS files, core application files, something tries to change it, it's going to stop that happening. And remember, verify explicitly. So for these devices, when we're having all the different types of interactions, think mutual authentication. We don't want the endpoint just to validate, hey, I'm really talking to this service. The service should validate, hey, this endpoint really is who they say they are. I've got some mechanism to deploy certificates to the devices that I can then validate. AppGateway, for example, in Azure has mutual authentication capabilities. A lot of the IoT solutions, they will validate the identity of that IoT device talking to them because, hey, I've got some sensor giving fake information. Well, that's then going to drive me to do maybe strange things I don't want to do. So we always think about that mutual authentication type of interaction. So we've got the identities. We've got the endpoints. Now, we say we don't trust the network. But obviously, we have a network still. So we have this idea of the network. And it may be part of some decision criteria that we want to use. Now, when I start about the network, I mean, the key thing here is, and I'll just kind of highlight this, we don't trust it. Just because something's on a certain network doesn't mean I give it a free pass to do whatever it wants. And we're still going to verify explicitly for everything it's trying to do. But we may use where it is on the network potentially as one part of a decision criteria. Now, if I think about the networking side, in an Azure world, our core network structure is built around this idea. I'll make this big so I have some space. We have a virtual network. So I have a certain virtual network, which, remember, exists in a certain subscription in a certain region. It's made up of at least one IPv4 range, optional IPv6. So what can I do here? Well, remember, my virtual network is broken up into virtual subnets. Two for the time being. I might want micro-segmentation. So how do I control the flow of information within the virtual network and coming in and out of the virtual network? So the first thing we actually use is network security groups, NSGs. So an NSG is a set of rules. Source port, source IP range, destination port, destination IP range, protocol, allow, deny, priority. I have all those elements that I build in and then I attach it to certain virtual networks, subnets. So it then applies those rules to control the traffic. There's things like application security groups, which is a tag on the NIC of a resource. And then instead of basing on IP address, I can say, well, is the NIC tagged with this particular tag, SQLVM, or compromised? And I might apply different rules to it. So network security groups enable me to add a layer four. So a key point, this is layer four. It understands TCP, UDP, port, IP. It doesn't understand application, HTTPS. It doesn't understand fully qualified domain names, anything like that. But this enables me to do micro segmentation. Hey, I'm going to let these things talk, but not talk to the internet or not talk to this other subnet. So NSGs help control this. Now, I did mention Defender for Servers, and I said, hey, adaptive app hardening, the whole FIM capabilities. There's a whole set of other features, I said. Well, one of the other features it has is a feature of adaptive network hardening. The whole point of that is just like the adaptive app hardening, sure, I've got NSGs. But what the adaptive network hardening is doing is going to provide me recommendations based on what it's seeing, based on the traffic observed, indicators of compromise, threat intelligence, to say, hey, great, you've got this NSG, but that's a bit generous. You have these things open that you really shouldn't have open. Let's lock those down a bit. So it's going to give me recommendations to change my rules to make it more restrictive. Now, additionally, I'm actually going to take this one out. I have services like Azure Firewall. So Azure Firewall is a managed native appliance that auto scales as different SKUs available. But the whole point of Azure Firewall is, well, it understands those layer seven constructs, fully qualified domain names. It can understand the full URL so it can do classification, not just based on the fully qualified domain name, but also the URL, the path-based part of it as well. It has threat detections. It can do TLS inspection. It can sit in the middle, generate a cert to my client that represents the server I'm trying to talk to and actually look at the TLS traffic. So then even if it's TLS, it can still do categorisation and rules based on the path, not just a fully qualified domain name. So it's a super, super powerful feature. And to use Azure Firewall, what we do is we have user-defined route, UDRs, which say, hey, when you're trying to get to this path, actually your next hop is this appliance. It has a certain IP address. And then it can go off to wherever it wants to go. It could be the internet. It could be some other network. So I can drive traffic through by defining these user-defined routes that say, hey, to get to here, this is your next hop. One of the nice things we can do with Azure Firewall is it gives us all of that great protection, but we can integrate it with other things. So imagine I have a global service. So if I think about global services, we have Azure Front Door. So Azure Front Door is global. So it's not regional. It's not confined to one Azure region. It's a global service. It's layer seven. So it understands HTTPS. It can do any cast on different points of presence, so I get a great experience. It can do split TCP to terminate the connection to my client and then go and talk to the services that can actually render it. It can do TLS offload then. It has all these different types of capabilities for me. But one of the things I can add to this Azure Front Door is WAF, Web Application Firewall. So if I think about the OWASP top 10 protections, I think about rate limiting, this can apply it. So even before it gets to my resource, it's giving me protection. I can add custom rules to block, for example, certain types of traffic. So I have that ability at a global level. Now at a regional level, well, I have AppGateway. Now AppGateway also can have WAF added to it. So that's another option. Once again, this is a layer seven technology. So it understands HTTPS. It can do SSL offloads, things like that. But this also is now using this core rule set from the OWASP, the Open Web Application Security Project. So this is going to give me protection. So, hey, maybe I've got applications behind this. I want SQL injection protection. I want command injection. I want cross-site scripting protection. I want protocol violations or protocol anomalies, crawlers, scanners, all those things blocked. Well, AppGateway, when I add in the WAF, gives me those capabilities. And once again, I have those custom rules. So there's different things I can do. This is a regional. It lives within a certain region. Then Front Door is a global solution. From a security perspective, I also want to stop things like a distributed denial of service attack. So one of the services I can add is the distributed denial of service protection. And there is a standard SKU. There's also a free SKU, a basic, which applies to everything. But I don't have any control over that. It's really designed to stop very large-scale DDoS attacks. Whereas the standard offering is saying I create, I then link it to my virtual network, and it protects all of the public IP addresses that are associated with resources within there. It uses machine learning to understand what's a typical behavior. So it gives me a lot more granular protection. I get great reporting from that. I get the ability to maybe get support during an attack. There's certain SLA-based protections. So I have these great capabilities with that DDoS protection standard option there. If I think about other types of workloads, not everything lives within the virtual network. So I might think about, let's take a few different scenarios. I might think, well, there's some instances that lives out here, and I've got some service. Now it's of a certain type. So we'll say it's of type service 1. So one of the things I can do, remember I'm in my, I have a certain subnet, I can use something called service endpoints. So what a service endpoint does is I can light this up for service 1 types of a service endpoint. And then what that does is it makes this subnet a known entity to the native firewall solution that pretty much all of the services have. I can allow listing to come through. And when I add that, I could now add a rule to say, hey, this is subnet 3 of vnet 1. And it could say, hey, excuse me, subnet 3 of vnet 1, sure, you're allowed through. So subnet 3, you can come through. But it only applies to services running within that subnet. I can't use it from other things. So then the other thing I can do is I have an actual instance of a particular service. So maybe here, this is a Postgres managed database or a SQL, whatever it is. And this is actually DB instance 3. And by default, remember, all of these things, they actually have a public endpoint. So it's an internet accessible address. We lock it down if we want through the rules. We want to authenticate to it. But it's still a public endpoint. With a service endpoint, I'm still accessing the public endpoint. It just gives me a slightly more direct path to it. Maybe I don't want that. So the other thing we can do is I can actually add a private endpoint. This is private endpoint 1, which links directly to a specific instance of a service. So this is using private link. So it's a private endpoint, which is part of the private link service. And if I wanted to now, I could completely disable the public endpoint. Hey, everything has to come through this private endpoint. And one of the great things is this is just an IP address. So this IP address, I could actually access from other subnets, from peered VNets, from on-premises networks, have a site-to-site VPN or an express route connection. They can all get to that. So if I had other networks kind of sitting over here, as long as there was some connection, a site-to-site VPN, an express route private peering, hey, they have a path to it as well. They can use that path to get to that instance of the service. There's some DNS configuration I require as well that would give me now a private path to that particular service. So that's a really powerful thing to do. So private endpoint is all about talking to a service. Imagine I had something like app service, an app service instance. I could do a private endpoint. So I could do a P2 to talk to it. But what if the app service wants to talk to things in the VNet? How does that work? Well, there's VNet integration where now it can go and talk the other way. So there's these capabilities I can do there. Some services will actually deploy into a subnet in a virtual network. So an app service by default exists out there, but it can talk to things in a VNet. Another option would actually be for app services. I take a particular subnet and I deploy an app service environment with company at V3. So all of the things that are normally shared that make that work, they now all live within that app service environment. So it's actually in my virtual network. So I don't have public endpoints. I don't have to worry about private endpoints or VNet injection. It's running in my virtual network. Things like SQL managed instance runs in my virtual network. There are many other services that follow this pattern or use a delegated subnet in which to talk. So those things happen as well. And realize different services have different capabilities. For example, AKS, Azure Kubernetes service. That has the idea of, for example, an open service mesh. That's an add on for AKS. That's an envoy based. So it adds a sidecar to the pods to add networking capabilities, which can then add pod to pod MTLS. So it encrypts all of the communications. It can do traffic shaping like canary deployment patterns or blue green. It can send portions of the traffic to different sets of pods, depending on how I'm rolling out an update. It gives me very granular access policies even beyond what NSGs do within the pods. Gives me visibility and much, much more. So look at the individual service to understand, well, what are some of those things I can actually do for that all up solution? So it's important to kind of understand that there are many different capabilities. So we have the network. And then if we keep flowing through beyond there, we have the infrastructure. So what's running on the network is my infrastructure. Now see that that's huge in scope. And there's different things I want to do when I think about the all up infrastructure as my environment. One of the biggest things we want to do is to understand our cloud posture. What is our overall security posture? What is our compliance to maybe different types of standards? What are recommendations we can do? So the key solution we use here is Defender for Cloud. This used to be the Azure Security Center. So now it's Defender for Cloud. And so this is all about, hey, understanding that cloud posture. How healthy am I? What is my compliance state, for example? And is it built in Azure Security Benchmark that it's using to drive a lot of these things? And it can then drive some key recommendations to help me get a better posture. And a part of this posture is, hey, I get a secure score. And different things have a different amount of points. So the higher the number of points, the higher the priority. Hey, if I'm not getting those points, I'll go and focus on that first to try and improve my overall standard. Now, there are that built in Azure Security Benchmark kind of just there by default. But then what we can actually do, if I jump over quickly, if I go and look at Defender for Cloud, so there's a free type of capability. Then what we really want to turn on is you have these enhanced protections. And then you'll see there's a whole bunch of separate services, Defender for Cosmos DB, for Storage Accounts, for Key Vault, for Resource Manager, for DNS. These all add enhanced protections. Defender for Server is all part of these. But what I'm actually, when I think about these things, if I was to, for example, let's look at regulatory compliance. So by default, it's basing on this Azure Security Benchmark. But I can add additional ones. Now, I have to have turned on the Azure Defender to enable me to use those additional standards. But I can still go and look at them. So if I just pick a management group where it's not actually tied down to a particular element, notice I can add more standards. Look at all the different standards that are available. So I can say, hey, I'm subject to this certain industry. I could go and add one of these or multiple of these to my environment as well. So when I think about using these, what these will then give me is when I start looking at my overview, I'll start to see my security posture. I'll see my regulatory compliance on the different ones I've added. It would actually show me those right here and give me recommendations. So the key part of this is, yes, I can go and add additional compliance standards. So from here, I can absolutely add additional. But what I have to have done is the subscription must be enabled for that enhanced. And then I can go and add whatever particular compliance, new, HIPAA, whatever that might be, I want to actually enable for that. So the Defender for Cloud is giving me those capabilities. And the key thing, you probably saw that on the screen, is yes, it's Azure, but it would also go and talk to AWS and the Google Cloud. So it's going to give me those features as well. Now, when I think about the environment and I think about, I can start with Azure, but it actually goes beyond that. One of the big things this can drive is actually Azure Policy. So I can think about Azure Policy. Azure Policy is some particular thing I want to do. It's a control, it's a guardrail. Or maybe it's just saying I want to track for a compliance. Hey, you can only use this type of storage account. You mustn't create public IPs except in this particular subnet. Hey, you must have this agent deployed. And maybe what I want to do is just track it for compliance purposes. So I'm going to let you do it, but I want to know about it. Or maybe I'm actually doing it as, I'm going to block it. It's a guardrail. Maybe I'm going to remediate. I can actually go and fix these things. And when I look at these secure scores and these recommendations, behind the scenes, these are actually using Azure Policies. There's a built-in initiative for the Azure Security Benchmark that it applies, and it goes and looks at that to drive my secure score, to drive those recommendations. So it has all of those things. And that Azure Policy typically is talking to the Azure Resource Manager, the control plane of that. But what it can also do is, well, there's other cloud support, but also I have the option to do in-guest configurations through my Azure Policy. And what this is doing here is for Windows and Linux, it's using PowerShell DSC. And also for Linux, it's using Chef. So I can actually define requirements I want within the guest itself through Azure Policy. So then that could be in Azure. It could be in another cloud. It could be on-premises. I can drive those various things from there. Now, one of the other things I can do at this point, when I create Azure Policies, I can link them to a subscription. I can link an initiative to a subscription. But I might also go and create the idea of a blueprint. So a blueprint is made up of policies, resource group definitions, role-based access controls, and even templates. And then I can assign that blueprint to essentially stamp down that configuration on a subscription. And likewise, I could directly apply the Azure Policy. I don't have to go via a blueprint. Blueprint gets this combination of policy, resource group definitions, RBAC, and templates that I could then link to a subscription to apply some configuration. But remember, Azure Policy has that guest configuration. It has policy for things like Kubernetes, where it's actually then going to using Gatekeeper inside Kubernetes to apply policies that I've defined in Azure Policy. So there's really just a huge, huge scope of these various types of things I want to do. Now, when I think about these all-up sets of protection for infrastructure, realize there's many different solutions here. But I thought about Defender for Cloud at the key fabric level, but realize what you're actually going to see is Defender for dash, dash, dash. Nearly everything has some Defender element. So if we went back here for a second, just to show you, hey, if I try and turn these on, notice all of these different types of things, Defender for servers, Defender for app service, Defender for SQL, Defender for the managed databases, for storage accounts, for Cosmos, containers, Key Vault, RMAP. There's a huge set of these. And these all have intelligence about the types of threats that can affect these various types of resources. So when I think about my workloads, there's just a massive set of Defender solutions available for me that I'm probably going to want to leverage as part of that. So that's a part of the all-up solution. Now, one of the big things we care about for security is encryption. So when I think about my Azure resources, hey, I have some resource. This could be a database. It could be a storage account. There's many other types of things. And we talk about encryption in transit, and we think about TLS, requiring encryption as we talk to it. Then we also think about encryption at rest. And in Azure, I really can't think of anything that's stateful that we care about that isn't encrypted. But there's an option of a platform managed key. So a platform managed key is Azure is managing the key. Azure is rotating it when it thinks it should to industry best practices. Or I can have a customer managed key, i.e., bring your own key. With that, you're specifying the key, and also you pick when you want to do things like rotate it. What are your requirements? Hey, things happen, you want to rotate it straight away. You have that. And the way this works is one of the key Azure services we have is Azure Key Vault. And really, Azure Key Vault is a key service you're going to use when I think about any type of sensitive information. So Azure Key Vault has support for things like secrets. So a secret is something I can write to and read out of, an access key, a password. It has support for keys, something I can generate, I can import, but I can't read out, but I can perform cryptographic operations through the key vault using the key. Sign something, decrypt something. And it has support for certificates, the lifecycle management of that cert, distributing the cert. And for the key, if I'm using the premium SKU, for example, or I'm using a managed HSM, this can actually be HSM backed. So it always uses a hardware HSM as part of that. And when I use a customer managed key, it's stored as a key in my key vault. So I notice my board is slowing down just a little bit. So let's refresh my board just for a second. It seems to fix the performance side of it, hopefully. There we go. Hopefully that'll perform a bit better again. So we refreshed our board. So it's going to use your Azure Key Vault to store the key. Now, it may not be actually encrypting with that key. There's often a data encryption key, and it's using this to encrypt the data encryption key. But fundamentally, you are controlling the key that's being used to encrypt the data. So you then have control over that rotation. Different services encrypt differently. SQL has transparent data encryption, for example. So there's some encryption going on. Now I can then think, remember, that's one type of resource. There are other resources in Azure. There's building block resources. I can think about a VM. So one of the things we like today are the Gen 2 VMs. So the Gen 2 is UEFI based hardware instead of the old BIOS based, and it gives me a virtual TPM. One of the nice things the virtual TPM lets me do with the Gen 2 is I can turn on trusted launch. So it's only available with the Gen 2 because it's using the virtual TPM. That gives me an attestation from that virtual UEFI all the way through to the booted operating system. So that's saying I can measure, I can validate before I let other things happen. So that's a nice security solution. We can then build on top of this for things like confidential compute. And there's different offerings around here, but this is all about, hey, that memory and the CPU is encrypted. Now there are options for doing this at the entire operating system, the AMD- based SKUs, or there are ones that do this at an enclave. So the enclave of the Intel SGX. So I have to change my app to be able to use their enclave, whereas the AMD whole OS, I don't have to do anything special to use them. It's just there, it's giving me those capabilities. But I have those different levels of capability around that. And again, there's all these different Defender solutions for these. Defender for AKS is a very popular one. And remember, AKS can be Windows, it can be Linux, and there's different protections depending on what I do with that. But the whole Defender for containers, don't think of it as only AKS in Azure. It's any managed kind of Kubernetes environment, which we're going to talk a little bit more about later on. Now, when I'm thinking about my resources, just all up resources, one of the key things we always want to think about is this idea of least privilege. I think least privilege in terms of the role. So we have role-based access control, which is this security principle, a user, a group, a service principle, managed identity. It's given this role at this scope, managed subscription, a resource group, hopefully not a resource, maybe a management group, but it's a certain permission. I should have the smallest possible role that does what I need. And ideally, I want it just in time. Now, the just-in-time solution is Azure AD Privileged Identity Management. This is a P2 feature. So when I think about that Azure AD over here, and I think about the P2, another feature of the P2 is PIM, the Privileged Identity Management. So that's another component of that. But the whole point of what this does is either at the actual Azure AD roles or the Azure Resource Manager roles, it gives me the permission only when I actually need it. I have to go and elevate up. Maybe I have to do an MFA. I have to get approved before I get that role. So more privileged roles, rather than me having them all the time, I would elevate up through PIM, and I'd have it for two hours. Now, the AD version of this, let's go green. So that's for Azure AD roles. What about if it's my old-style Active Directory domain services? So something called PAM, Privileged Access Management. What that does, it uses a bastion forest where I have duplicate groups. I have a special trust to this bastion forest. It uses the same SIDs. So my token has a certain SID in it. It's a tie-bombed membership. So I get a role for a certain amount of time, but that's for Active Directory. So there's a different solution when I actually want to do this on-prem compared to actually things in Azure AD. We talked about the RBAC giving it to a user or service principal. I said a managed identity. Anytime I have some application that needs to talk to something else, it needs a role, and it has to have permission to that resource. If it's a regular user account, I have to somehow store a certificate or secret that the app has to be able to get, let's say it's running inside a VM or an app service or container, to be able to authenticate to Azure AD to get a token to talk to the resource. Hey, John, store it as a secret. Okay. How do I authenticate to the key vault to get the secret? So one of the things we can do is we have the option to add, I'll do it in orange, a managed identity to Azure resource. Now this can be a system assigned, i.e. that managed identity is linked only to that individual resource. So let's say this is actually called VM1. So basically you have a managed identity system assigned VM1. Or it can be user assigned. User assigned, the managed identity has a separate lifecycle. And I then grant that resource the ability to use that managed identity. Why would you want to do that? Imagine I had lots of resources that needed the same sets of permissions to other resources. Rather than having to give 10 system assigned managed identities the same set of permissions, hey, I'll create a user assigned, give it permissions, and then let these 10 resources use that identity. So that's the point behind it. But then resources within apps inside this resource can just get a token as its managed identity through just Azure and then use it to get permissions. So the whole point here is the RBAC on this resource, for example, would say, hey, managed identity VM1, you have contributor role, for example. Or maybe it's a data plane permission. Many services today support RBAC at the data plane level. So I might leverage that as part of it. When I think of virtual machines, one of the key things we often want to do is connect to it. Say I want to get to this resource. And how do we control that? So I want to use, for example, RDP or SSH. I don't want to leave those open. Definitely not to the internet, but even maybe on internal systems. So how do I use those? So in Azure, in any network, we might use a managed jump box. So in Azure, the managed jump box service is Azure Bastion. That deploys into our virtual network. So it takes up a certain subnet. And then I, as the user, typically through the portal, to the Azure portal, I'll do that way too small. But I can actually also use the native tooling in preview through the Azure CLI. I can then kick off MSTSC for RDP or SSH. I talk to the Azure Bastion, which then lets me RDP SSH to the services. So if I want to manage jump box, typically accessed by the Azure portal, so I can apply things like conditional access to add controls around being able to use that service, I can use Azure Bastion for that. Now, the other thing is typically this VM might have a network security group applied to it, which is blocking certain communications. So one of the other things I can do as the user, I can actually leverage something called JIT, just in time access. So I can go and make a request for a certain IP. It could be my IP that I'm accessing from, or maybe I'm using Azure Bastion or Azure Firewall, and I want to enable the IP space that that lives in for a certain duration, maybe two hours. And when I raise that, what it will do is it modifies the NSG for that period of time to let the communication from me or from the Bastion. And after that period of time expires, it closes it again. So just in time is doing that. Now, this just in time is a feature of Defender for server. So JIT is a feature. So it's those whole Defender solutions. I turn on that enhanced protection. Defender for server is what is giving me that ability to do JIT to a particular workload. So it's letting me do those capabilities. Now, when I think about the manageability, I talked about this infrastructure and Azure policy, and Azure policy is one of these huge, lovely things about Azure, but there are other elements. So, hey, I've got Azure, and the control plane of Azure is the Azure Resource Manager. And one of the things is when I talk to the Azure Resource Manager, I try and perform some operation, it's always checking, hey, is Azure policy? Hey, the guest OS configurations. And that's just native. Anything I do to Azure is always going through the Azure Resource Manager. But there are many features that that arm control plane brings. Hey, those things like RBAC, tagging, the policy is an obvious one, there's various types of extensions, there's various types of services, there's bringing those Defender things. Well, what if I have other clouds? Other. And I want to manage things in those other clouds. Or I have things on premises. I want to manage those as well. So the way we do this is we have Azure Arc. It does not stand for anything. Azure Arc lets us extend that control plane to things in other clouds, to things on premises. And we have Arc for servers, Windows, Linux, and then I can bring, hey, these capabilities. There's Arc for Kubernetes. If it's CNCF compliant, I can use Azure Arc for Kubernetes. Now, once I have Azure Arc for Kubernetes, I can then do Azure Arc. I can add some of the data services like SQL, like Postgres Hyperscale. I can add some of the app services. I can add some of the AI services. It basically deploys evergreen container instances on top of that Kubernetes environment to bring other Azure things to that. So Azure Arc and then the workloads running inside, be it OS instances, be it Kubernetes, I can then bring those in and manage them and bring capabilities through Azure Arc. But then I can even think about, well, OK, that's one part of it. That's great. But these other clouds, for example, how can I bring maybe some of those other compliance, those cloud posturing solutions to the cloud itself? So when we think about Defender for Cloud, if I drew Azure, AWS, and GCP, Defender for Cloud, I can use there. And one of the great things that Defender for Cloud does is it adds things like automatic agent provisioning. So what does that do? OK, so I'm now managing the cloud through Defender for Cloud. I've onboarded AWS GCP. As it detects services, it can now onboard agents, which could then bring it into Azure Arc management. So they come together. Hey, the cloud itself's posture management, hey, Defender for Cloud, AWS GCP. The workload inside it management, hey, I'll use Azure Arc. Azure Arc is extending the Azure control plane to that. And then you get things like policy management. And the exact features will vary depending on is it AWS or GCP. The AWS seems further apart at this time. But vulnerability management, security configuration, compliance. I can get log information to drive behaviors on these. I can get Defender deployed to these solutions on top of the Arc to start protecting those services on top of there as well. So it's the other Defender solutions can come into play as well. Defender for endpoint for the various types of protections, remember. So we have all of these amazing things going on. If I zoom out for a second, just a crazy number of things across identity, the endpoints themselves, the network and the infrastructure. What do I do with all of those things? So I can really think at a fairly basic level. What's really happening across all of those systems is what I'm getting in from all over the place. Fundamentally, I'm getting signals. I'm going to gather signals from all of these places. And what do signals give me? Well, signals help me understand the context of what someone is doing, what's happening. Is it safe? Is it risky? Is it all of those things? So how do I apply some logic to that context and then drive controls? Well, it's conditional access. So conditional access is really what's going to drive once I've got that context, is then going to drive my control. And remember, conditional access, this is part of Azure AD. And remember, specifically, it's Azure AD P1. Now, if I want to use signals about user risk from identity protection, then I need P2. So it depends on exactly what feature I'm using. But it's giving me those various capabilities. If we was to jump over super, super quickly, the whole point here is if I go and look at my Azure AD, and I go and look at my security, look at my conditional access. So yes, there are locations in conditional access. I can create a location based on the country, and the country can be based on the IP address. Or if it's a mobile device, the GPS coordinates. Or I could create a location based on a particular range of IP addresses. I can create things like terms of use, PDF documents people have to accept. But then what I'm doing is I create a policy. I assign it to certain users, certain groups, maybe certain service principles. I can apply it to certain roles. I can apply it to all apps. I could apply it to certain types of actions like, hey, I want to register my security information, or join devices. Hey, I want extra security if they're going to go and register for MFA, for example. So I can apply it to different types of things. Then I have conditions. User risk. This is where I need Azure AD P2. Sign-in risk. I need P2. Particular device platforms. Obviously, it's a Windows phone. You really want to be pretty concerned if someone's trying to log on from a Windows phone in this day and age. I can exclude. I can do it based on location. I could do certain client apps. I could filter for different types of devices. Maybe I'm looking at property of devices, like it's a SOAR. Only if it's a SOAR does this apply and I allow access through. But then I give controls. Control could be block access. It could be grant access. It could be I'm going to grant access, but I need them to do an MFA. Or it's marked as compliant, depending on MEM, which could also get signals from Defender for endpoint. Hey, it's hybrid Azure AD joint. It's an approved client app. There's an app protection policy. They've accepted a terms of use. It's all of them. It's one of them. I have all of these different options. And I can even have session controls. Different types of app enforced restrictions. Hey, conditional access app control. Defender for cloud apps has a reverse proxy that I want to actually control the access in case I want to revoke it if I see certain strange things. So conditional access takes all of those different things we know about and then adds that control. And the key point about all of that control is we're then giving control to something. And ultimately, what we're giving control to is really the bit we actually start to care about. All of that other stuff I don't really care about. It's not particularly adding business value to me. What I care about is the next set of bits. What I care about is it's giving me control to my applications because the applications are the gateway to my data. So I use the conditional access. Now, my applications, if I think about, they might integrate with my Azure Active Directory. They become an enterprise app or an app registration if I'm creating it myself. So then it's an application in the Azure AD. And I could then use Azure AD features to actually grant access to it. As part of my identity governance, there's the idea of access packages. And people can go and apply for an access package. Remember, that's a P2 feature, Azure AD Premium P2, to get access to the application. They can go and apply for the package to get that. So that would be one way I could enable access to it. This application, remember, well, maybe it's some other external software as a service sitting out here. So what do we have? We have that Defender for cloud apps. This is the cloud broker. So Defender for cloud apps, what that's doing is it's looking at, well, things going via Azure AD tokens requested. It can get feeds from network devices as well. And it can then go and hook into these apps if it supports it via an API. So it can actually gather information via the API to see what users are doing. Hey, they're downloading a lot of documents. That's weird. Hey, let's block them out. If it doesn't support that, there's an optional reverse proxy component. So to access the app, I have to go through it. So we saw there was session controls. Well, the session control in the conditional access policy says you have to use the reverse proxy to get to the service. So now I can control, I can see what's happening. I can block access if I need to as part of that. I can detect shadow IT now because I'm getting those feeds from the apps, from the authentication happening. I can go and see those various things happening if it's a sanctioned or unsanctioned application. And one of the great things this does is I can actually find where I am. So Defender for cloud apps, one of the nice things it has, it will discover what you're doing. It has this cloud app catalogue. And the cloud app catalogue has thousands and thousands of applications. It has risk scores. So is it really a good app? If I see people using it, is that OK? It shows me, I'm just going to pick one at random. It shows me why it has certain risks. OK, so what can it do for security, for compliance? What does it mean? So it will show me this for all of the applications it discovers. So I can then make a decision on this application. Would I want to allow it? Would I want to block it? I now have those controls actually available to me. Now, what about, there's another element to applications we do need to think about. If I'm writing my own custom application, then there's a whole set of DevOps considerations. I have code. Most likely we're using GitHub. Maybe we're using Azure DevOps. But one of the nice things about GitHub is it has this advanced security feature. And what advanced security does is actually a few different things. So one is it converts my code to data, which I know sounds kind of weird. But by converting it to data, I can then run code QL queries against it to look for mistakes in my code that would expose security vulnerabilities. It has a depender pot. It creates a dependency graph of the things my app is using and understands vulnerabilities in those dependencies. It can create a pull request to say, hey, go and update to a newer one so you don't have this vulnerability in your code anymore. It can find secrets I've got in my repo. There's different elements. There's pipelines, there's repos, there's whole sets of stuff. Hey, you've got some secret from over 45 leading providers. You should go and do something about this because this is not a good thing that you've got going here. Think about that complete pipeline. If I have a pipeline, if the identity is weak for the pipeline or vulnerability is added in, could be a template in my repo, my app code, where someone can insert something bad in there that then gets deployed to my production environment. So there should be various gates and checks going on. There should be validations going on. I should really make sure I'm locking down those principles that have those permissions. So don't forget about that whole set of things that we have in play there. And then really the last part of that flow and the bit we really, really care about is the data. I mean, that's ultimately what a lot of the things boil down to. And I want to understand, well, what data do I have out there? And then maybe control it. So a big solution is Microsoft Purview. And the whole point of Microsoft Purview is it will go and discover data wherever it is. It doesn't have to import it into Azure, but it will go and discover the data from all across your environment. And once it does a discovery, what it will then let you do is actually classify it. And it will also show you things like the lineage. Where did it come from? Where did it go through? How was it transformed? Where did it end up? Now, once I do that classification, I can do things like apply labels to it. And with the labels, I can use information protection. So that's a different solution. And what information protection lets me do is a separate compliance center. It defines the labels that I'm applying there. And once I have the labels, I can then choose to do protection. Hey, if it has this label, which is based on its classification, I might have data leakage prevention rules applied to it. So it can't be shared. And there's other native solutions, for example, SQL Database. SQL Database has its own sets of discovery classification. So discovery classification protection. It can do things like data masking. Hey, I found this type of data. Let's hide all of the characters except the last four. Social Security number, for example. So there's features it can do there to help protect and stop people seeing that parts of the data. When I think of information protection, hey, my office applications, there can be automatic rules applied if it detects types of data. It might offer a suggestion. Hey, do you think you should classify it as this based on the types of data we're seeing? And the user could accept it or give a reason why they're not doing that. There's a whole set of protections around this. Now, also remember your data, you're probably backing it up. So think about things like Azure Backup. I might be using the Azure Backup service to back up my data. If someone's doing a ransomware attack against me, a lot of times they're going to go after the backups, delete them. And there's things I can do like soft delete. But how can I protect the backups? So Azure Backup really has two key mechanisms. One is a pin. So I have to get a pin before I can do actions against it. The other one I can do is a multi-user authorization. And what this does is there's actually a resource guard. So before I don't have any permission because there's a resource guard on my Azure Backup, someone else has to go and give me a permission short term so I can then do actions against this. And it might be a different subscription, completely the resource guard. So it's completely isolated from someone being able to attack my subscription to go mess with this resource guard. So it's capabilities that I want to protect my backups in case people do bad things because they're typically going to go after that. So we have all of these amazing sets of capabilities across the identity, the endpoint, the network, the infrastructure. Then we get the signals to drive conditional access. Key themes, Defender. I mean, Defender is just a huge solution around a lot of these, be it for the cloud, for endpoints, for different workloads. Obviously, Microsoft Endpoint Manager is huge. Azure AD, identity is the lock. And the identity is the key to get inside there. So identity really is everything when I think about modern zero trust, verify explicitly, all of those different aspects to it. So understand the different solutions and how I can apply things. Azure Policy is so powerful. Hey, I want to disable this type of access on an Azure feature. Hey, Azure Policy can do that. It's that guardrail, those controls I can have. Now, there is one kind of element. I talked about signals to give me context, to give me control. But those signals can also be really powerful to understand something bad is happening. Hey, I want to know about there's some security event happening I have to respond to. So sure, signals give me context. That's a really important thing. But there's another thing we like to do. And the thing we like to do is this idea of a SIM and also a SOAR. So a SIM is all about the idea of a security information and event manager. I'm going to be able to detect some security thing is happening. And then a SOAR is about the idea of security orchestration automation response. Do something about it. Great. I know it's happening. Do something. So for a SIM and SOAR solution, when I think about Azure, it's Azure Sentinel. Now, Azure Sentinel actually sits on top of a log analytics workspace. So if I think about a SIM, the first thing I have to be able to do, obviously, is collect. If I don't have the information coming in, it's useless. I have to be able to collect the information. So it's all about connectors. Now, there are native connectors for log analytics workspace, but this adds a huge number of additional ones. So the whole point here is I'm getting feeds of security logs and information from all over the place. Sure, Azure. Sure, Azure AD. Sure, Microsoft 365. Lots of third-party clouds and applications. I can think about syslogs. I'm getting information from those. And CEF. I'm getting custom logs. There's APIs. So it's just a massive number of connectors available for Azure Sentinel. The more information I get coming in, the more different types of signals I can correlate and come to a good conclusion and detect types of behavior. So I want to get everything collected into this log analytics workspace. Some of the connectors are law. Some of them are Azure Sentinel specific. Once we have the collection, well, then I can detect. And there's different ways we can have that detection going on. So I'm looking for threats based on that data collected. Now, one of the things log analytics workspace does is, sure, it's a place to ingest and store the data, but it has this idea of KQL, the Kusto Query Language. So one of the things that detection does is a whole set of analytics. It can run queries against it. It could be a scheduled query, a scheduled KQL that's looking for a certain set of triggers. But there's also things like machine learning-based algorithms looking for anomalies based on some baseline that's generated over a period of time. There's fusion. This is a multistage advanced attack detection, again, using machine learning. And there's hunting. So hunting is basically a set of KQL queries that I can execute. I'm looking for certain things. I'm looking for how many times something has occurred. Has this occurred? Something I may not want to automatically act on, but it's something I want to go and be able to find if I want to. I can think about intelligence. There's different types of threat intelligence. This could be from Microsoft. Microsoft has a whole set of cybersecurity teams. It could be a feed using taxi, T-A-X-I-I, from other external people. And I'm going to map it against the logs. And maybe this information is about a set of known bad IPs. It's a certain predefined threat signal that I want to act on. Maybe I'm using this user and entity behavior analytics based on things I'm seeing people doing. Hey, that gives me some signals. And all of these signals might be there's an incident going on. So when there's an incident, then I want to investigate. Now, that investigation, there's different things I can do. I have those incidents. I might want to look at a timeline view. I might want to look at investigation graph. I want to be able to track exactly what's happened to these different things from that incident. And then I want to respond. There might be a manual response, but also I have automation. And there's really two key types of automation we have here. We have automation rules. Now think of these as very simple and easy to leverage. They are some kind of automatic response I want that I can define through, hey, some incident comes in against a certain entity or a certain type. I want to do this. I want to email someone. I want to raise the severity. I don't have to do much customization. There's some trigger, there's some conditions, and then some actions I want to take. But it's very predefined. It's very simple to use. I also have the option of using playbooks. Now, a playbook is actually using an Azure Logic App. And Logic Apps are this really powerful capability that has all these, again, types of connectors, things it can work with. It's a nice flow-based visual representation of the things I'm going to do, but I don't really have to have a great programming background. They're very nice designer-based ways to create sets of actions I want to perform. Now, an automation rule can call actually a playbook, if I have that there. But these are all about, hey, responses I want to do. And with that playbook, like I say, I could pretty much do anything I wanted to do at all. I have a whole set of capabilities. So the whole point of Azure Sentinel is I want to get all of the signals coming into it, so then apply these detections to look for incidents happening. It helps me then investigate them, automate the responses, the whole SIM and SOAR part of the solution. So huge amounts of stuff there. I get it. But hopefully you saw it wasn't a massive amount of detail on any of them. You would need to understand the capabilities they bring, where they fit in the picture, but I don't have to have an expertise in how I would go and create a policy to do this. I just need to know, hey, okay, I need to go and manage things in AWS, for example. Well, okay, if I want to go and connect to AWS, I need Defender for cloud to go and connect to the cloud, for example. That can then help me onboard agents automatically. And I would use Azure Arc to manage the actual workloads on it. Okay, those things. How would I define some control? Oh, Azure Policy lets me do that on those fabrics. And understand where they fit in the different parts of the solutions. And that's really what you're looking for. Piecing the things together to meet some kind of requirement. So it's very broad. It's not super deep. Just have that good overall understanding of where different things fit together. Take your time. Again, mine was two hours. I finished in 30 minutes. I did rush. I didn't pay that much attention to what I was doing, but it should give you an indication. They're not super long, complicated questions. There were questions where it was like, hey, pick the solution. Which components would I use? There were the questions where you can't go back. It gives you a scenario. Does this meet it? Does this meet it? Does this meet it? There were the case studies. The case studies were nice that really, again, I didn't read any of them. But it would say, hey, to meet the business requirement, to meet the security requirement. So you might just flip over to the security tab. Okay, what is it looking for? Okay, that. I didn't even look at the tabs for some of them because really the answers, there was only one answer. It was, hey, I should use Azure Policy. I don't want to use cheese or pizza. Those ones that pretty much stood out as pretty obvious. So take your time. You have time, but do pace yourself. Don't let yourself get stuck on any particular question. If you don't pass, now, again, it's in beta. You're not going to find out for a while. But if you don't pass, you can look at where you're weak, focus on that area, and you'll get it the next time. There is the Microsoft learning path. But if you look at it, it's really based on AZ500 and I think SC200, which again goes to show it's not like this is all new information you need for this. It's just having a fairly broad knowledge of the all up security set of solutions. So if you've done AZ500 already, for example, you're in a pretty good place for a lot of these things. But I mean, all of them will help to different degrees. If you did the MS, you're probably going to be stronger on the endpoint things, Defender for endpoint. You're going to be strong on one area already. So maybe focus on the other ones to bring that all up general broad knowledge. As always, a ton of work goes into creating this. So I would appreciate a like and subscribe. But yeah, just good luck. Don't panic. Do your best. And I'll see you in another video soon.