 Hello, everybody. I'm joined today by senior security PM, Sarah Liatten, and we're going to talk about the whole implementation of Azure Sentinel on a hybrid implementation. Sarah, is Azure Sentinel only a cloud-based solution that can protect your cloud implementations? Or is there a story or something that we can share that can protect your on-premises implementation as well? Oh, definitely. The whole thing with a seam, I'm going to say seam, you might know depending on where you are in the world, you might know it as a SIM. It's S-I-E-M, so Security Information and Event Management System, that which is what Azure Sentinel is. It's really important that a seam looks at your entire environment. So whether that's on-prem or cloud or both in a hybrid implementation, which is what most people have these days, it's really important that a seam can look at both of those environments, because attackers aren't just going to look at your cloud environment, they're not just going to look at on-prem. They're going to traverse through different things. So that's why you're seeing needs to be able to ingest events and logs from everywhere in order to get security telemetry and potentially find attackers. So no, definitely, it's not just for cloud. It runs in the cloud and we use a lot of in-built cloud features to allow the service to scale, but it's certainly not just for monitoring cloud and not just for monitoring Azure. Wouldn't it be a very good seam if that's the only thing it did? That's just it, right? The whole aspect of attackers trying to get access to your information as a new currency and especially because we're all working from home, the situation is elevated in regards to the attacks that occur, because more data is traveling in more places. So a lot of organizations having that on-premises implementation, they worry, do they need a security solution just for their on-premises implementation, and then one for the cloud, meaning that I have multiple control vectors for my security piece, or something decentralized that I can go to the one portal and have an understanding in regards to what attacks are occurring and what I can do to automate to address those attacks. Yeah. I mean, one of the things that's really difficult for organizations nowadays is that our environments are getting more and more complicated. So you'll have some on-prem infrastructure. I mean, even Microsoft still has a bit of on-prem infrastructure. That's normal. You'll have some on-prem infrastructure. You've probably got something in the cloud. It may even be that you have something in other clouds as well. So you might have multiple clouds plus you're on-premise, and you need to be able to monitor all of these from a security perspective and operational as well, because if you don't, you don't have visibility of what's going on in your environment. But I mean, even before Cloud happened, it was still tricky to get appropriate monitoring and logging just across on-prem. So nowadays, when we've got the Cloud and on-prem in hybrid environments, it's even harder and it's definitely complicated, which is why you need to look at products that have that capability to look at everything. And as you said, to be able to centralize all that data, because the reality is you can't log into three, four, five, six, seven, even in double figures, number of portals, to try and work out what's going on in your environment. It's too time-consuming, it's too siloed. You need to be able to have a central place to be able to look at what's happening in your environment, because there's just no way that any one person, or even a big team of people, can efficiently run things without a centralized store. So, yeah, you're absolutely right. You need one place to go. And when hackers are chasing after your data, I don't think it matters to them if it's on-premise or in Cloud. They're going to chase it throughout your architecture regardless. And so, a new evolution like Sentinel has that ability to be that overseer of your entire architecture and not worry if it's on-premise or in Cloud, because it manages throughout. Yeah, exactly. Yeah, as you said, I have a sticker on the back of my laptop, which I can't hold up that says that's out of scope, said no attacker ever. And it's totally true that an attacker doesn't care where your data is. They're just going to go after whatever is valuable to them and whatever they can either resell or they can use. I mean, different attackers have different motivations. And so, yeah, they don't care where it is. And they will just go looking for it and they will take what they can find. So, certainly, there's no point just monitoring Cloud and saying, oh, we'll forget about on-premise and vice versa. It's, yeah, attackers go where the value is. And for most organizations, the reality is they will probably have valuable assets and data on-premise and in the Cloud. And attackers will just move around as they need to in your environment. So, yeah, you've got to look at all of those things. It's really important. So let's kick off with the first demo. And there's numerous demos you want to show us. What's the first demo we're going to go through? Okay, so, oh, so many things to go through. But I'll start with, I'm going to start talking about data connectors because a SIEM doesn't do anything until it has data in it. Now, I'm not going to go through all of these. You can see at the moment in the top there, I have 74 connectors. If you've been following Sentinel since it went GA about 18 months ago, you will know that we have a heck of a lot more connectors than we used to and we're adding them all the time. We do have, of course, have Cloud ones, as you would expect. We've got a lot of Microsoft products like Azure AD. We have Azure Firewall. As I said, I'm not going to call them all out, Security Center. We've got a lot of third-party products. So if you're using Barracuda's checkpoints, and as I said, I'll just scroll down slowly so people can read. If you're using Microsoft 365 Defender, Cloud App Security, Office 365. Now, that's looking at the cloud side of things, but of course, as we've just talked about a lot, there's a lot of telemetry that we can bring from on-premise as well. Because there's 74 connectors here, I don't have time to go through them all. Otherwise, we'd be here all day and I think people would be quite bored, but I did want to highlight a couple of important ones here. So the first one that I wanted to talk about, they kind of go together is the common event format one. So common event format, or CEP, C-E-F, uses the log analytics agent, which is something we use in other environments as well. And it's an agent that you can install either on Linux or Windows. And what it will do is it will collect CISLog, common event format and CISLog messages if it's Linux. And it also does something with Windows Events, which I'll talk about in a second. But if you've got a device that outputs in CEP, which many firewalls do, many third-party products do, you can send that into Sentinel using this collector. So you essentially can make a collector, a centralized collector, and you can send that to Sentinel. Now, you can either make that collector on-premise and send it up to Sentinel, or you can create a virtual machine scale set and you can actually have that centralized connector and it can scale in and scale out as required. We actually have a template for that in our Sentinel GitHub repo, which I'll talk loads about later, and we can put a link to that as well. So it's actually already been configured, we've actually already built a template for it for you to use. So that's a great way to collect things, both SysLog and any device that outputs in CEP. Now, I did wanna talk about, I'm talking about CEP and SysLog together and there's a reason for that, which is CEP is actually just a more formatted version of SysLog. So of course, SysLog, as we know, that's where you get a lot of things in Linux. So if you've got a lot of Linux machines in your estate on-prem, you can bring them in using, you install the log analytics agent and then you can either have a central collector or each individual machine can send SysLog up into Sentinel. Now, again, generally we find that most customers will create a central collector and then send that up to Sentinel, but we can accept it individually as well. So that's the first side of things, the Linux side. So the other thing that you can use a log analytics agent for is to take security events from Windows machines. Now, we use the Windows version of the same log analytics agent to do that. As you can see, we've actually got, you can install the agent here. We have a different, obviously slightly different installs for things that are in Azure and things that are not in Azure, but basically we can collect security events. Now, how it works at the moment is you can actually, within Sentinel you can actually select which events to stream. So you can see we've got four different levels per se here. All events, which as you can see is everything, Windows security and AppLocker. Common is a standard set of events for auditing purposes. There is a list on our Microsoft documents that shows you which event IDs are actually collected and common. And minimal is just the very bare minimum that might be of note from a security perspective and then there's non. Now, one would assume if you're looking at installing these you probably don't want to use non, but definitely look at the other three. The reason that we give you different options is of course, because when you send events up to Sentinel and log analytics you are paying for the ingestion. So you may, although a lot of people will automatically jump to all events and say, I want to put every single event in here that might actually not be the smartest thing to do because you always need to think when you're doing security logging because you pay for what you ingest you need to think if I'm ingesting this and paying money, is it worthwhile? Am I getting a useful detection from it? So, and each business is going to have different ideas about whether it's worth it or not, whether a particular log is worth ingesting or not. But do be careful, don't necessarily go straight to all events because you can end up with very, very noisy, very, very noisy logs and ingesting a lot of data. And if you're not getting some interesting security detections from it it's probably worthwhile thinking if that's actually worthwhile ingesting. Usually what I abide by in those scenarios is whatever the organization that you support has agreed to based on the business rules for that organization, they'll be okay with if they've asked for full documentation or full analysis of the inputs that are coming through to analyze all, then you're allowed to analyze all. Don't do it on your own. Make sure that you have the buy-in from the organization that you support. And if there isn't that need, possibly there is because of ISO standards or specific verticals like finance and healthcare there might be that requirement. But if there isn't that requirement there isn't a standard to adhere to and your organization is okay with not capturing everything put the rules in place that agree with what your organization is trying to accomplish. Definitely. And something again, traditionally on premise seams they did work in a different way. What you would have is you would build a number of virtual machines. You would buy licenses for those virtual, well they wouldn't need to be virtual machines but typically they would be. You would buy licenses for your seam and all the machines that were part of your seam infrastructure on premise. And then it wouldn't be on how much data you ingested. It would just be on the literally the processing capacity of the machines that you bought, which means you could, traditionally what people did was they would throw as many logs as they could at their on premise seam because that's how you got value for money is that from what you paid for the license. Now that's the traditional way of doing it. Now of course as seams have moved into cloud they've gone to this ingestion based charge. So there is also a bit of a strategic mindset shift here that you need to be aware of that it's not necessarily, it's not cost effective anymore just to collect all the things for the sake of it. So what we do find is a lot of customers making that transition, they do have to have a bit of an evaluation because it might be that they've literally never evaluated it before because it was just, oh, we just send everything to our seam. Whereas now of course there, it makes sense to be more efficient about that. So it brings up a good question. If I do send all my data up to the seam, does that provide latency in terms of a response or a detection? No, so the good thing, I mean, if you did want to send all the things to Sentinel, that is absolutely fine. I mean, Sentinel sits on top of Log Analytics, which is part of the wider Azure Monitor platform. It's our entire monitoring platform for Azure. It will scale as required. And unless I believe that we have tested it to something insane like 10 petabytes of data. So if someone, if anyone out there can send more than 10 petabytes of data at Sentinel, then that would be an interesting thing to look at. But realistically, any organization, even our big large global customers wouldn't be able to send enough data up to Sentinel to get it to slow down. What is worth mentioning there though, because that's a very good point, is if you were collecting events from Syslog and Windows events, because we have our intermediary, the machine that's running the agent, you would need to scale that appropriately. And that's what I was referring to, talking about what's in our GitHub repo. We do have some virtual machine scale set templates that we've already made. And if you're not familiar with a virtual machine scale set, what that is, is a way that you can set some thresholds. And if, say, the processing gets to, or the IO gets to 80%, then Azure will automatically build another machine and scale out. You can also scale up. Scaling up isn't great. I'm not a big fan. Always scale out. And by scaling out, we mean adding more machines. Scaling up is when you increase the power to a single machine. But in order to do that, you have to reboot things. So that will provide a service interruption. So we prefer scaling out. So for these two that I've just talked about, which are more aimed at on-premise, you do need to think about how you size the number of collectors, depending on how many events you expect to send up to Sentinel. But when it actually hits the actual Sentinel system, the platform, it's not a problem from there. So you're right. There are a couple of considerations to take in there, but not with the actual processing power of the seam itself. Now, from the GitHub repo for the templates themselves, anybody can go in and extrapolate that and use it for their own purposes. Have you seen the reverse in terms of, you know, organizations contributing to the repo and providing their own spam on templates specific to possible verticals like healthcare and what have you? We're getting there. So I have the honor slash very, very busy job. I'm one of the people who review some of the submissions we get into our GitHub repo. There is quite a big team that do that because you can imagine we get a lot of submissions. So we get submissions from our customers, from our partners and also from internal Microsoft resources as well who've been doing work. So we do get some of customers sharing things back with us. Of course, it does depend on what it is. Sometimes customers have written proprietary things that they're not able to share, which we completely understand. But we do get people sharing their workbooks, their playbooks, detection rules. I had a partner. I know they shared a very cool little way or it was a cool little script and a template that were just made security events sending more efficient. And we really encourage you, if it's something you're able to share with the community, please submit it to our GitHub repo. We do review everything and we'll give you feedback. We are quite busy. We're trying to get faster. So do apologize if you don't hear from us for a bit, but we are trying to go through them because the fact is that when we're talking about security and I was told this in an old job by a manager of mine, and I think it's a really nice, I think it's a really nice way of looking at security in that insecurity, we're all in this together. We're not rivals. We're not rivals. We're not competitors. Everybody who runs computer systems needs to keep them secure. Now, and we can really benefit from knowledge sharing with each other. And even companies that are in the same industry, so whether it's finance or if it's retail or whatever it is, they may be competitors on a commercial level, but when it's security, they actually face similar threats and often it's really helpful to share that knowledge. Now, of course, as I was saying, there will sometimes be proprietary things that can't be shared outside, but I think sharing knowledge as best we can is one of the best things that we can do as a security community and an industry because we will face similar threats and we have similar issues. So the more collateral we can share, the better. So yeah, if you're out there and you're listening and you've done, you've written a cool hunting query, you've done some cool automation, if it's something that you don't need to keep internal, we really, really encourage you to submit it to the repo you can now get, which is very exciting, you can get some badges and we did do last year and I believe we're gonna do it again later on this year is we didn't do an Azure Sentinel hackathon and that was judged by some of our top security VPs like and Johnson and the winners actually got cash prizes and some other cool things. So it's definitely worth doing, like go do it. I'll stop talking about it because I love people to submit to the repo and we're always happy. Even if it's your first time, we've got loads of guidance on how to do it and you know that if you submit something to the repo it's being reviewed by an engineer and we can help you if there are just some mistakes or it doesn't fit with our templates, like we'll tell you and help you. So don't be scared to submit. We really appreciate your submissions. And that's the important piece, right? It's not only your creativity from the outside coming in in terms of what you're sharing with us at Microsoft, it's where is the mindset going in terms of security? What are the things that people are thinking about that provides us a better idea in terms of, well, what services do we need to address? How can we make Sentinel that much better to achieve what organizations are trying to accomplish? Definitely. And yeah, we do look at things submitted to the repo for ideas for new things that the product needs. And also we do have the Sentinel user voice. That's something that we have for most Microsoft products where you can submit ideas. You can also upvote ideas that have already been submitted. So if you've never looked at the Sentinel user voice go and look at that. Add your votes to anything you'd like to see and if you can't find the thing you want on there feel free to add it as a new idea. That's something we really appreciate too. We do look at it and we do submit those ideas from user voice to the Sentinel product group who are the engineering team who decide on the new things we're going to develop and the new things we're going to put on the product. And we're always listening to customers because of course, if it doesn't do what our customers need it to do then no one's going to use it. So that's really important for us. So let's move on to the next demo. So what are you going to show us next? Oh, so I'm going to show you a little bit. I realize we've just gone on a tangent there but I'm going to show you something that is just worth mentioning because it does confuse a couple. It does sometimes confuse some folks and it's worth mentioning for that reason. Now I talked before about, I talked before about the log analytics agent and having security events and syslog already going into your log analytics work space where Sentinel can see it. It's worth mentioning that if you already have a log analytics workspace you may already have this configured. So I'm going to start just by showing you something that is worth mentioning here because sometimes it does confuse people. We have here log analytics. So log analytics is what sits underneath Sentinel. And it's just worth mentioning that if you are already using log analytics you may already be collecting Windows event logs and security logs and syslog because that's not a feature specific to Sentinel. So it's worth looking if you're putting Sentinel on top of an existing log analytics workspace you may already find here that we're already collecting those things. So you can see here for example, I've got syslog coming in already. You can actually be quite granular on what you choose that the agent will send to you. If you're already doing it here and then you've got Sentinel on top you don't need to configure this in Sentinel. This is specifically for Windows events and for syslog. It is, I realize there's a bit of an overlap there but it's just worth mentioning. So if you're not starting from scratch just have a look and see if your log someone has already configured it in your log analytics workspace because they might have done. And so the connectors and it's already feeding the information into Sentinel you're capturing that information. What is the next steps in terms of analytics? What is the next steps in terms of reporting that you would want to look at? Yeah, so next step is we would look if we were wanting to get this going as quickly as possible which is what I assume most people would we would go and have a look at analytics. Now we have loads of out-of-the-box rules and if you're new to Sentinel this is always where I would recommend you start. And we're adding to them all the time. So it's always worth having a look to see if we've got any new ones. So you can see here we've got in use and marked on the ones that are already turned on but what I would do is have a look at these rules. So for example, I'm gonna look at this I'm gonna look at user login from different countries. Now you can see here the data source is octa. This is actually preview so it's quite new. In here it tells you data source octa single sign on. Now because it's gray here it says that we don't have this data source coming in and I know in this demo I'm using here we don't have octa. So that's gonna appear as gray. So there's probably no point turning that on. We won't stop you from turning on a rule template where the data source isn't actually coming into Sentinel but you can do if you want to. So instead let's have a look at this first access credential added to an application or service principle when no credential was present. So of course this is an identity one. So we're looking at Azure AD and you can see in order to have this rule working properly we need Azure AD audit logs. Now you can see it's green. So we have Azure AD audit logs going into this going into this workspace which means we can turn the rule on. So what you would do I realized this rule is already turned on but let's go with it. You would click create rule and then everything here is fully customizable. So if you don't like the name of it you can change it. You can change the description. We also map these rules to the Mitre attack framework. So there are quite a few different tactics. It's something that a lot of SOCs are using or trying to adopt. So we've put this one under credential access which makes sense but if you disagreed and wanted to change it, arguably maybe you could put this one also under privilege escalation potentially we won't go there. And then we can also change the severity here as well which I think for most people when you're just turning on the templates for the first time is most likely to be the thing you might change because we've considered at Microsoft when you've been writing this template that it's gonna be high. This is a high severity incident if this rule is triggered but you might not think it's high. You might want to change it to medium or low. And again, this depends on your organization's security policies, risk tolerance, et cetera. So you can change that. In the next tab, we've got the set the rule logic. So you can see here this is actually the rule logic. So this is written in KQL. If you KQL is Kusto query language we have a lot of different tutorials on KQL that are free. There's a great plural site course. You may have already used KQL in Defender for Endpoint. We use it there. It's used in log analytics as your data explorer. If you're not familiar with it it is a really nice query language that's pretty easy to pick up quite high level but also really flexible. I'm not in this particular video we don't have time to go into the nitty-gritty of KQL but... If there's an ask for it we would create that video later on down the road if that's something that you can reach out to us and let us know. And we'll set up more time with staring and get that done. Yeah, we love a bit of KQL. I do KQL tutorials reasonably regularly. And yeah, we're definitely keen to do that. And again, there's a lot of material online that Microsoft provides for free as well to digest in your own time but we can do videos as well. We map entities here. Now entities are sometimes... Entities are important because they help us match more things together. So an entity, as you can see there we've got five entities, account, host, IP, URL and file hash. Now the reason entities are important is because we start to see patterns with entities because if you have a host if you see a host coming up in a number of different alerts that suggests maybe that there's something bad going particularly bad going on with that host. It helps us join together a lot of what's going on. Now for some of these queries, it will already be defined but if it's not defined you can actually choose one of the columns from the logs to say, okay, this is where the host is. Then you don't have to define all of them. It's not necessary. And in these rule templates, we've done it for you but that's just if you're writing your own. Coming down to the next bit, we have query scheduling. Now in Sentinel we do, we run our rules on a fixed time period. The most frequently you can run them is every minute. You can't do them any quicker than that. And we can't fix a set time. I get asked about this a lot by customers. And the reason for that, there's not a particular reason for that but to be honest with you when we're doing things and saying run this rule every hour, run this rule every day, run this rule every six hours or run this rule every five minutes. It's not really necessary to say please run this at a fixed time because that's quite static. And an attacker, for example, if an attacker knows you run a rule at midnight every day and maybe they'll do all their attacking and dodgy things up to 11.59 PM. And this sounds crazy but things like this happen. It's much better to run them on a frequent basis rather than run things on a specific time. And then we have event grouping. Now event grouping is something that's very flexible. What it says is you can, it basically means an event is something that is of note but it doesn't mean we wanna necessarily trigger on alert and create an incident. So what we can do is if this triggers we can make one alert and group the events together. Otherwise we can trigger an alert for each event. So different, this is very, very business. Writing rules can be tricky because this is very, very contextual depending on the organization. Some organizations might want an alert every single time something's triggered. Some businesses will want to group them together and say for the last hour just group them all as one. Again, that's so, so, so dependent on the organization and the industry and their environment. And that's one of the things that's super interesting about SIEM but also makes it really kind of tricky because it's very difficult to do a one-size-fits-all. So of course with these templates this is a good way to start and you can just tweak them rather than having to go from scratch. Then we go even further than that saying you can also group the alerts that have been created. You can group them if all the entities match. You can group them if only certain entities match. So you can put all the alerts into one incident if the account matches or if the IP matches. There's tons of different things here. I could talk about this for a long time. If you're familiar with SIEM, this won't come as anything new to you. If you're brand new to doing security operations you'll kind of get a feel for it. It don't feel bad if you have to tweak these rules quite a lot at the beginning. That's what most SIEMs you have to do. And to be honest with you, it's an ongoing effort for all organizations because your environment isn't static, things change. You may need to tweak these. The great thing about Sentinel is because we've got these built-in templates and rules and we have a nice UI, it can be very easy to tweak them rather than having to run your own analytics to work out whether your rule is working or not. The other thing to remember that you had brought up earlier is don't do it on your own. Make sure that you have the business decision maker at your organization in lockstep with your efforts in deploying appearance because you wanna make sure that the business is bought in in terms of the efforts that you're putting forth for the reporting and detection of what's important to your organization. You know, gone are the days where the traditional IT Pro was the gatekeeper and all the rules were abided by what the IT Pro had put forth in this new age of information and information being the new currency that hackers wanna gain access to. It's very important to have the business decision makers involvement and investment in terms of what's actually being detected, how it's being detected and what's of importance to the organization to keep safe. Definitely. And that leads on to something that I will talk about in a second. Automated response. Now I managed to pick one that doesn't have playbooks in here, well done. But this is where we would add a playbook and add our automation, which I will talk about later. But for example, automation is where we would add like sending an email, posting in Teams. We can also do remediation. So we would tag that there. And then when we're finished, we can review and create this rule. Now I think it's going to, yes, it's gonna fail this validation. I knew that it was gonna do that. But obviously the idea is that you would validate it like we do with other Azure resources and then you could click create. So there's a big bit of work to do here. There's a fair bit of work to do here, but much less than the traditional scene when you'd write from scratch. In going through these rules and looking to see what is relevant. In particular, I will show you, we can filter here on the data sources to make it a bit easier. So of course I was talking quite a lot about security events in Syslog and Seth that would often come from on-premise. So if I just filter on those and I didn't do that properly, then we can have a look at the rules that use those data sources. So if I do that properly, we can see here there's a lot. We've still got like quite a significant number of rules here that are using those data sources. So for example here, we can see PowerShell Empire Commandlets. That is not something you want to see in your Windows security events. And so you can see what's relevant to turn on and then this will generate incidents. So here we've got an incident. Now this one's very busy. I've picked a very, very busy one here, but this as you can see is a multi-stage incident. And I'm not, this is the investigation graph. Now this shows all the different alerts that have been generated. Now I realize you probably can't read them. Don't worry too much because I'm going to show you them down the side here in the timeline and all the different entities that are involved. So we have some PCs, some users, but we've got a timeline here. So we can see the first thing that happened was a suspected credential theft activity. Now if I click on that alert, it'll tell me more about that. Now that came from Microsoft Defender ATP. If you're unfamiliar with that product, Defender ATP, it has just been given a new name. We did rename a lot of things at Ignite. That is our product that does security for on-premise active directory. So this is coming from on-prem and we can see here that the program exhibits suspect characteristics associated with credential theft. So that looks like potentially something has happened there. So if we go back to the timeline, we can then see we've got another alert here. The next thing that's happened is a malicious credential theft tool has been executed. If I click on that, again, it's come from ATP and this looks like if we scroll down, so someone's used a credential theft tool. It doesn't say which one is there, but of course credential theft tool. You don't have to be a security expert to know that's not a good thing. And then we're going to suspected golden ticket usage. Now, golden ticket is an on-prem AD attack. It's attack against Kerberos, which is an authentication method used an on-premise AD. It's not used in the cloud. So you can see that we've got an attack here against Kerberos that's been detected and it's used to access six different resources. So if we actually hover over that, we can see those six different resources there. There's a number of PCs and some accounts involved. I'm not going to go through this whole thing, but you can see there's some more suspected golden ticket usage. Then we've got local admin users using .NET commands. Again, that suggests that it may be that a user's been compromised that's got admin access and they're creating a new account to do nefarious things with because what lots of attackers will do is create brand new accounts, do all their bad things, delete that account, and then it's kind of covered up their activity. So that's a fairly typical attack pattern. So as you can see, there's a lot of things going here. We've had remote code execution enumeration of SMB. So again, this is mostly an on-prem attack from what we can see here so far. This is mostly an attack that's happened on-premise, but we're looking at it in the cloud using various different sources. So it's a great example of a hybrid scenario and we can dig into this investigation graph more to understand what's happening. We can start digging into these, if I zoom in a little bit, we can start to see all these different entities. We've got the PCs, we've got the hashes, we've got, you see good old Mimicats there? That's the credential theft tool being used. So we can start to dig into this by clicking on the related entities. So a SOC analyst can really quickly start to understand and piece together what's happening without jumping between loads of different portals, which is good because with incident response, whether it's security or otherwise, we know that the first thing you need to do is establish what's happening and the bounds of what's happening so you can contain it and stop it going any further. So that's investigation. I know this is a very, very busy one to look at but I think it's a good one. As you can see, if I zoom out, that investigation graph gets really big. Of course, this is gonna change every time you do an investigation what you see here and the sources but I think this is a great illustration of what you can do with Sentinel to do your investigations. Now we've gone through data ingestion, we've gone through reporting, we've talked about investigations now. The next step I would think would be what is the response? Now that we've detected an attack is occurring, we've done the investigation in terms of how the attack is occurring, what is the next step that Azure Sentinel provides that now addresses this attack? Yeah, so there's a couple of things here. Mostly I'm gonna talk about logic apps and automation. Now logic apps is the way that we do automation throughout the whole of Azure. It's not a Sentinel specific thing but we do use it in Sentinel and we use it for three main things. One is alerting, one is remediation. So actually automatically remediating things and one is enrichment. So there's, and there are different use cases for different things, but typically every single customer really should be, as a starting point, you should be using the automation to do alerting. So if you're not familiar with logic apps, it's a really nice way to do automation, very simply. It has a nice GUI interface like you can see here. You don't have to know any code. For those of you who are interested in the background, it is running JSON. So we're gonna use logic apps. If you haven't seen logic apps before, it's the way we do automation across the whole of Azure. It provides a really nice GUI interface to write automation. In the backend is JSON. You can look at that in the code view. I personally am not the best coder in the world. I'd much rather just use the interface here. So what we can do is we can say, when in a response to an Azure Sentinel alert is triggered, what do we want to do? So we've added a box here that says, get the incident details from the alert. So we're grabbing here the subscript, we're grabbing the details. So we have to take the subscription ID, the resource group, the workspace ID and the system alert ID. Now the reason that we're taking these, and we have to take these every time we generate an alert, so we can pass them into another place, another program. We might be passing it to an API, but what we're doing here is we're adding it to Teams. So we're saying, if an alert is triggered, take all the details of that alert and send them to Teams. So you connect to Teams. It's very straightforward. And then you pick the Teams tenant, the channel you want it to go in and then you can post a message. Now you can see here the message can be dynamic content. So we take the alert severity, the title, the status, et cetera. And basically we would post that, for example, in your SOC Teams channel and say, hey, this is an alert. We need to, here's an alert that's been raised, someone needs to look at it. We can also send emails. You can raise tickets. So if you've got a ticketing system like ServiceNow or JIRA, something like that, you can do exactly the same thing. You can automatically create a ticket. You can assign it to different people, depending on the department you work for, because sometimes in some organizations, different tickets will go to different departments. There's a ton of things you can do here. And that's kind of your basic alerting, setting up the incident. The next thing you might... So sorry. No. That's huge because a lot of the questions we get about Sentinel is, does it always provide that automated response in terms of now addressing that issue? Can it do the notification? Because I have a trouble ticket system in place that I have to adhere to because of my requirements of my vertical. And I can't have that automated response in place. So Sentinel is not for me or my organization because under my understanding, that's what it does. It does the automated response. What you're telling us here is from this logic app, I can pretty much put my business rules in play. I don't have to have a coding background to do so. And I can make it so that it's a notification or set up of a trouble ticket for follow-up or something that's based on the business rules that my organization abides by, as opposed to, no, no, this is just going to address the issue and walk away. Yeah, no, totally. I mean, to be honest with you, most organizations I would not expect to just, I'm going to fix it and walk away because there's no, you can't report on that and you need to operationally understand what's happening in your business from a security perspective. In an ideal world, yeah, we'd automate and we should automate away as many things as we can. But the nature of security operations and the variety of things you see means that we will never be able to automate everything. There will always be a proportion of tickets and issues that have to be looked at by a person. The idea with automation is that we automate away the routine things where we know how we want to respond and where there's a lot of manual process and just very repetitive actions. And anyone who's worked in a SOC will know that there are a lot of repetitive actions that often have to be taken. Now, the idea with automation is we automate those away to leave SOC analyst to work on the really interesting duty things that have never been seen before. And that's exactly what we do internally within Microsoft as well. We try and clear away and automate away nine out of 10 alerts and incidents before they get to a real person. It's tricky to do. It takes a lot of, it's tricky. I'm not gonna lie, like it does require upfront work because of course, you have to think if we see this situation, how do we want to respond to it? Then you need to build some automation. And realistically for most organizations, it's a journey. A lot of customers I've worked with might just start off with this basic alerting. Raising a ticket, posting in teams, letting everyone know what's happening. And then further down the line, they might say, hey, we're keeping this incident and we do exactly the same thing every time. Can we work some automation into that? So it is a journey, definitely. But certainly if you need to raise tickets in your ticketing system for operational reporting, et cetera, Sentinel can definitely fit into whatever your operational procedures are. And although Sentinel does have its own incidents handling pages where you can write comments and do your own incident and write things in there, a lot of customers, because it aligns with their wider operational procedures, choose to use a third party ticketing system. And I would definitely say there is nothing wrong with that at all. If that's what you need to do, you do it. And that's been one of the biggest changes, right? And the fact that Microsoft is working with third party software because of that requirement, if you're in healthcare and you're finance, retail, whatever that may be, there's a current course of action that takes place. And you have to continue on using those applications. It's amazing that partnering with those third parties to have this rules in place and automation of a lot of the tasks that would be mundane or tedious before can now be quick in terms of the process of something as simple as creating a trouble-ticking number. Exactly, because realistically, and I have seen this in my career, it used to be that the scene would generate an alert and someone would have to go into whatever ticketing system they use and manually copy and paste things over, which is just a waste of a sock analyst time. It's not a constructive use of their time, really. And so it's cool that we can get rid of that. And so yeah, there's so many things we can do with automation. You've probably seen, and I've talked about many times before, we can do things like call virus total and look and see if the IP or the hash is in virus total. If you're not familiar with virus total, it is a third party system that has a store of things that have been identified as malicious because that might help you decide the urgency of an incident. You might want to block a user in Azure and NAD. So for example, the incident that we just looked at previously where there had been some, it looks like some accounts have been compromised, it might be that we say, okay, let's take that entity, let's block it. Now, it might be you don't want to block it, you might force them to change their password or ask them to re-authenticate with MFA. Again, what precisely you want to do, and I think this is one of the trickiest things, aside from writing rules and your thresholds, is how you want to respond to an incident. Because again, that's going to really depend on the business. Some businesses might have a very low tolerance for, might have a really, really low tolerance for accounts being compromised, so they might want to block anything that looks suspicious. But on the flip side of that, if you run automation where you're just blocking users all the time, it's going to, if there's a false, if it's a false positive and we have to, realistically, you will always have a, whilst we're always trying to bring them down as much as we can, there's always going to be some false positives. You don't want to block somebody and block their account when actually there's nothing wrong and it might increase calls to your service there to unblock people. So there's a huge balancing act there and I mean, that's security generally, right? You've got to balance security with the business running smoothly. And that's a line that's very difficult to tread. And it always will be, I think, but we have to keep trying. Now, from a business rules perspective, what was interesting, you talked about the whole aspect of Azure AD and if an account has been compromised, so that individual would be put through, okay, now you have to change your password because we did detect this. So Sarah, you shared the scenario about Azure AD and when a password has been compromised for a user, that user changed their password. What about in an instance where it's Active Directory and it's on-premises implementation? That's a really good question and a very good one to ask. Now, it's going to depend on how your Azure AD and on-premise AD is set up. If your Azure AD is synchronizing with your on-premise AD and Azure AD is the boss of all of that, then all we need to do is actually issue the commands to Azure AD and it would take care of it on-premise as well. If you're not syncing them, then that's a little bit different. So this is why we do recommend it is Microsoft Best Practice that you sync your Azure AD, your on-premise AD and you have Azure AD as the sort of master source and also this is controversial and we probably don't wanna go here. We also recommend that you do actually store all your password hashes, you don't just synchronize the user accounts, you also synchronize the hashes of your on-prem passwords in the cloud. That is Microsoft Best Practice. Some people, as I said, we won't go there because that can go into a heck of a debate. Some people feel very strongly about that, but just so you know, we don't store the actual password, we store sort of a hash, something that's been hashed and salted about a thousand times. There are many, many advantages to doing that. It helps us be able to use our threat intelligence on your on-premise AD passwords. So if you're not doing that and some organizations and some individuals I know feel very strongly about this because I've talked to people, do you go back and have a look and consider doing it? There's a ton of benefits, but that's probably a different session that we could go into that one. So we've gone through the full scenario, data ingestion, we've gone through reporting, we've gone through event investigation, we've gone through in terms of response. This covers everything from an on-premises implementation to cloud and a hybrid scenario with both scenarios, both instances connected into the one architecture. If somebody wants to start down their journey of now doing the investigation of Azure Sentinel for their hybrid implementation, what would be the best first steps? So I think the best thing, there's a couple of things. We have a heap of learning resources. We have, very recently, well, when we're recording this in the past month, we've released Microsoft Learn, MS Learn modules that you can go and work through to get familiar with Sentinel. We have the Azure Sentinel Ninja training. I've mentioned this before, but one of our amazing program managers in Israel took the downtime over Christmas and New Year to update it for 2021 because we've got so many more things in there. So that is, I mean, it's probably 20 odd plus hours of material about how to set up Sentinel, how to set up the connectors, how to set up particularly the log analytics agents that I talked about for taking things from on-prem. There's so much stuff in there and it has been very recently updated with all the new features in Sentinel, which we haven't even managed to talk about all of those because I talked too much and there's way too much in Sentinel to talk about, but it's all in there. Also, keep an eye, we've got the Azure Sentinel GitHub. Of course, I've already talked about that, but even if you don't feel like you're ready to contribute, we have loads and loads of templates and things where you can just deploy it into your subscription. So if you see something that either we have created or somebody else has and you think it would be useful for your organization, most things will have an ARM template, which means you just click deploy to Azure and it will go off and push it into your environment. You may need to configure some variables, but you get the idea. So, yeah, we've got the Microsoft security community where we do regularly, we do webinars, the program managers and engineering for Sentinel. We talk about new features, but we may just do a focus session on something in particular that's sort of a hot topic in Sentinel. I'm gonna be doing one later on this week about monitoring Azure Sentinel itself for how you audit what people do in Sentinel. We save them all onto YouTube so you can go back through the back catalog and see what's there. We've definitely got some things on running it in a hybrid environment. And yeah, they're probably the main ones I would start with, but there's so much out there. So definitely have a look. If you can't find something or you have specific questions, you can find me on Twitter. I do reply to people. And we're always happy to help. Sentinel's a really cool thing. It's still very new in the grand scheme of things. So we know lots of people have questions. So we're really keen to hear your questions, help you out and get you started with it. So, just reach out. But there is quite a lot of stuff out there and we'll have all the links to that as well accompanying this video. So yeah, it's a good way to start. The links themselves will be included on the video as well as there'll be an accompanying blog post that this video will be embedded into. So if you're watching this video on YouTube or on any other platform, channel nine, what have you, we will also share the link below that is the corresponding blog post that will have all the links as well as replicating all the steps that Sarah had gone through in terms of the demos themselves. Sarah, so awesome to have you on to run through this because I love your passion for security and your passion for enabling those to be more secure, to help the organizations be more secure. Again, one more time, if they wanna get ahold of you, what's the best way to get ahold of you on social media? Yeah, you can get ahold of me. I am at underscore Sarah Yo, Sarah Y.O. I've got a far too common name to be able to just have at Sarah or at Sarah Young. But yeah, you can get ahold of me on my Twitter handle. I do check my DMs, they actually are open. So, you know, do reach out to me. There's the Microsoft tech community where myself and my engineering colleagues, we answer questions as well. And yeah, please have a go with Sentinel. I'm a big believer, my main belief in life, not just with Sentinel in life, maybe just security, is that security doesn't have to be hard. Security should be easy. It is a lot of common sense. Of course, there are many things in real life, in business world, you know, there are competing pressures, et cetera, that don't make it that straightforward and black and white. But certainly here at Microsoft, we're trying to make that stuff as easy as we can and make good security straightforward. So yeah, have a go at Sentinel and see how you go because it's definitely a great thing and it's changing a lot. We're getting so many new features so quickly. It's even hard for me to keep up and it's my job. So yeah, go out there and have a go. Now, if you have any additional questions, we have a Discord server that's set up specifically for this session, for session ops 103. And if you want to get ahold of me for some reason, you can get ahold of me on Twitter at Wireless Life. Sarah, thank you very much for your time and everybody, we'll just get you on the next video. Thanks, bye.