1. Threat Detection with Microsoft Sentinel Analytics
Now, using Microsoft Sentinel Analytics rules, you can basically configure notifications and alerts based on data coming from the sources that are connected to Microsoft Sentinel. This alert will help you ensure that your security operations team knows when a threat occurs and that the team can appropriately react to prevent the threat from reaching your corporate assets. You can search for potential threats using the built-in analytic rules that Microsoft Sentinel Analytics provides. There are currently several types of analytic rules, which are listed below. So again. Microsoft Security Fusion machine learning behaviour analytics anomaly Scheduled alerts and near real-time alerts Now let’s talk about the fusion alerts first. Fusion Alerts detect suspicious behaviour and activities at various stages of the cyber kill chain.
Fusion correlates multiple security alerts from various products and uses machine learning to detect advanced multistage attacks. Now one note here: The Cyber Kill chain basically describes a typical workflow, including the techniques, tactics, and procedures used by attackers to infiltrate an organization’s networks and systems. By default, fusion detection is enabled in Microsoft Sentinel. Microsoft is basically constantly updating the fusion detection scenarios for thread detection. Now, at the time of the recording of this course for fusion detection, you must configure the following data connectors:
Active Directory Asia Active Directory Identity Protection Microsoft Cloud App Security is now called Microsoft Defender for cloud apps. Microsoft Defender Advanced Threat Protection formally, this is the former name of the connector, but this is basically the Microsoft Defender for Endpoint Connector. And you can also use the Palo Alto Connectors if you use Palo Alto Firewalls in your environment. Now, some of the common attack detection scenarios identified by Fusion alerts include data exfiltration and suspicious activity detected, such as suspicious forwarding rules in a Microsoft 365 mailbox following a suspicious sign into an Azure AD account.
In reality, this could be an indication of compromised user account data destruction. An example would be an unusually large number of unique files deleted following a suspicious sign into an Azure AD account, followed by a denial of service alert. And these are a significant number of, for example, Asia virtual machines deleted after a suspicious sign-in to an Asia Ad account, a “lateral movement alert.” Again, as an example here, there are a significant number of impersonation actions that occur after a suspicious AzureAD sign-in, including ransomware. And here, after a suspicious Azure AD sign-in account, there might be some unusual user behaviour used to encrypt data, which can actually trigger a ransomware execution alert. Again, you’ll have a link in the downloadable resources for this particular lesson with more documentation and details in regards to Microsoft Sentinel Fusion Technology.
Now, let’s talk about the Microsoft Security Alerts. As a result, you can configure Microsoft Security Solutions that are linked to Microsoft Sentinel to create incidents automatically based on alerts generated in the connected services. And we’ve seen how to do that in the previous section where we configure the Microsoft Services connectors, right? So, for example, you can configure your organisation to be alerted when a user who has been categorized as high risk attempts to sign in to access corporate resources. You can configure the following security solutions to pass their alerts to Microsoft Sentinel: And we’ve kind of gone through all of these in the previous section. So again. Microsoft Defender for Cloud Apps I’m going to refer to these by their updated names: Microsoft Defender for Cloud, Microsoft Defender for Iota, Microsoft Defender for Identity Defender for Office 365, Asia Ad Identity Protection, and Microsoft Defender for Endpoint. And on top of this, you also have the Microsoft 365 Defender connector that you can enable, like I’ve shown you in the previous section. And you will have all of these connectors connected, so basically incidents and alerts will be automatically streamed to Microsoft Sentinel. Now, we have the next stop here, and we are going to talk about machine learning and behaviour analytics here.
Microsoft Sentinel Analytics includes built-in machine learning behavioural analytics rules. You can’t edit these built-in rules or review the rule settings. These rules use Microsoft machine learning algorithms to detect suspicious activity. Machine learning algorithms correlate several low-fidelity incidents into high-fidelity security incidents. And this saves you the hours you would have spent manually analyzing multiple alerts from different products and attempting to correlate them. For example, by using the machine learning behavioural analytic rules, you can detect an anomalous secure shell protocol login or an RDP protocol login activity.
Then we have the anomaly detections and the anomaly rule templates to use. Again, machine learning can detect specific types of anomalous behavior. Now, each rule has its own unique patterns, parameters, and thresholds appropriate to the behaviour that’s being analyzed. Then we have the scheduled rule alerts. And here again, this provides you with the highest level of customization. You can define your own expression using the KQL queries to filter the security events. And you can even set up a schedule for the rule to run. The near real-time rules are the last on our list. These are NRT, as they are shortened, and these are a limited set of schedule rules designed to run every minute in order to supply you with the information as up-to-date as possible. Now let’s talk about creating an analytic rule from a template. And then we’ll talk about creating an analytic rule from scratch, right?
So let’s basically get into the portal, and let me show you how to do this in the portal itself. So here on the analytics tab, we can again see that we have the active rules, the rules that we have already enabled, and I have already enabled a few in my trial environment here. And here we have the rule templates. All right, again, in the rule templates, you can apply the filters. As I’ve mentioned, if you apply the filters, you can do it by severity, by rule type, or by data sources. For example, if we select by rule type, you have all of these types available here that we’ve just talked about: Fusion, NRT, Schedule, Microsoft Security, Anomaly, Behavior, Analytics, and so on. So now, if we want to create a rule from a template, what do we need to do? We need to go to the rule template tab and let’s say we want to create any type of rule here would be fine, but let’s pick this one, the Solar iGATE named Pipe.
Now here you can see a description of the rule, so it identifies the match across various data feeds for any kind of Solar gate incident, right? and it will throw up an alert. Now we click on “create the rule” here on the first page that we are presented with. We can customize the name, we can customize the description of the rule, we can select the techniques that we want to show up in the alert, we can select the severity of the rule, and of course we can select the status to enable or disable. Right? Now on the next page, we setup the alert rule logic, right?
This is basically the Krell query that will look for your events in your environment. Here we can also map entities, so we can map entities in key-value pairs like full name, and we can specify a field that is different from the Kosovo query result that will be returned. And of course, we can add new entities and more. On the custom details here, we can basically specify key-value pairs again if we have cruise queries that are basically looking deeper into the fields of the table of the events that are generated. And we can customise these custom details as per our requirements, let’s say. And the alert details here you can select—as you can see, it says here you can select parameters in your alert that can be represented in the name description of each instance of the alert. You have a link here that takes you to more documentation about this, and you can run the rule every day for the last day on the query schedule. For the last hour, you can run it every hour. For example.
Again, this is fully customizable based on your specific requirements and, of course, the alert threshold. You can use that to notify you if this query returns only one result. So if this query, for example, returns one single result, it will surpass the threshold of zero that’s set here, and you will get an alert if again we have results from this query here. Under event grouping, you can configure how the rule query will be grouped into actual events, right? And, of course, if the rule is essentially grouped, if the rule returns, say, ten events of the same type, isn’t that correct? You can group all of these events into a single alert, or you can create an alert for each event for each result of the query by specifying this option to trigger an alert for each event. Then we go to the next page, which is called “Preview.” And here you have the ability to create incidents from alert triggers generated by these analytic rules.
Or if you don’t want to create incidents, you can click this to disable it, and it won’t create alerts. Alert grouping is useful if you have multiple alerts, not just events alerts. They can also be grouped into a single incident, but that’s not really recommended. Next on the automation page, you can select Playbooks, and we’ll get into Playbooks in an upcoming lesson. You can create automations here. You can create automated responses based on logic apps, which are called Playbooks, that you create to automatically respond to an alert and automatically do some actions when an alert triggers. When a Microsoft central incident triggers, you can create playbooks to do automatic actions like post a messaging team or send your security operations an email, or more complex tasks like performing a full scan of the machine involved in the incident and blocking IP addresses, domains, and stuff like that.
Now, next on the Review and Create page, we are waiting for this to be validated. As you can see, it’s validating the rule, so we click Create. Then, after the creation, we can see that we now have 57 active rules in our environment. The next thing is to create an alert from scratch, which is done by clicking the Create button here. And you want to create a scheduled query rule, right? And this will take us to the scheduled query rule creation. And here, it’s basically pretty simple. Because you provided a name, we’ll call this test rule that. I’m not going to create the rule; I’m just going to show you how to do it. A description: it’s the same thing as with Customizing.It is based on a template. We specify a tactic, and you specify an alert severity. We go to the alert rule, and here the difference is that you will need to write your own queries, right?
So, for example, I’ve prepared a query that examines the successful deployment of an Azure virtual machine in the environment. So the rule looks like this: So it looks in the Asia activity log where your operation name is “create or update a virtual machine,” then it looks for the activity status of the deployment to be “successful,” and then it summarises this event to basically, let’s say, spit out a result. We can remove the last line over here and leave it just like this, right? And then we can select entity mapping, and let’s say we are interested in the Asia resource, the virtual machine that was created. And here we specify the resource ID, and the value would be something like “resource.” Okay? And then we can add a new entity, and let’s say we are interested in the account that’s initiated this deployment.
And here we can select from multiple parameters over here.But let’s say we are interested in the display name of the user or the full name of the user who initiated this. And this can be correlated to the caller, right? Because in the Asia activity operation, the caller would be the account that initiated this operation, right? And let’s say we’ve mapped our entities over here. Next, we want to run this every 5 hours for the last 5 hours. So I will stick with the defaults here, and then we can group all events into a single alert. Then it’s just a matter of “next,” “next,” and “next,” because I don’t want to configure anything else, any automated response here we’ll review the rule element created, and this will basically create our new rule from scratch, right? Okay, so this is how you create analytic rules from templates or how you create your own customised analytic rules from scratch by specifying your own Kousto queries to look for events that you are interested in. Now let’s talk about managing the analytic rules. Well, managing the analytic rules is fairly simple.
So if I select a rule over here, let’s say this one, I have the option to disable the rule. So this will actually disable the rule itself; it will not generate alerts and incidents any longer. You have the option to delete the rule, right? Then, if I right-click on this rule, I have the option to duplicate the rule as well.
So I might want to duplicate this rule to keep its configuration, customise it a little bit, and rename it into another new, different rule. And you have the option to edit the rules. And this is done by clicking the edit button here. And again, it takes you to the same pages that we’ve seen in the wizard, where you can customise your query, customise the rule, and basically edit your analytic rule. And this is, in a nutshell, about the analytic rules and the analytic rule templates. I will see everyone in the next lesson, where we’ll discuss security incident management in Microsoft Centinel. Until then, I just want to mention that you will have lots of links to further documentation and more details in regards to the topics that we’ve discussed in this lesson, in the downloadable resources for this particular lesson, and again, until the next lesson. I hope this has been informative for you.
2. Security Incident managent in Microsoft Sentinel
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. In this lesson, we are going to talk about security incident management in Microsoft Sentinel. In the previous lesson, we covered alerts. Now we are going to talk about the actual incidents that are created in Microsoft Sentinel. Now, before we begin, let’s review some of the key concepts here before we dive into our topics of incident management. So it is again important to understand the following key incident management concepts: First of all, we have the data connectors, and we use the data connectors in Microsoft Sentinel to ingest and collect data from security-related services. These events are forwarded to a Log analytics workspace associated with Microsoft Sentinel. Events can be collected, of course, from Linux or Windows computers running the Log analytic agents on Linux Syslog servers or directly from Microsoft or Asia services. Then we have the events, which Microsoft Sentinel stores in a Log Analytics workspace. These events contain the details of security-related activity that you want to monitor with Microsoft Sentinel.
Then we have the analytics rules, and basically, like you saw in the last lesson, you create analytics rules to detect important security events and generate alerts. You can create analytic rules by using the built-in templates or by using custom KQL queries against the log analytics workspace in Sentinel. Then we have the alerts, and analytics rules generate alerts when they detect important security events as you have them configured. You can also configure alerts to generate incidents. And that takes us to our incidents over here. So Microsoft Sentinel creates incidents from analytic rule alerts. Incidents contain multiple related alerts. You use each incident as a starting point and track, let’s say, a mechanism for investigation into security concerns in your environment.
Now, the incident management page in Microsoft Sentinel is a complete process for incident investigation. from creation to in-depth investigation and finally to resolution. Sentinel provides a complete incident management environment in which you can perform these steps. You can use Sentinel to review detailed information, assign incident owners, maintain incident severity, and manage incident status. First and foremost, the overview page in Microsoft Sentinel, and it appears that incident management in Microsoft Sentinel begins here as well, where you can review the current Sentinel environment. Let’s see, and the overview page basically contains a list of the most recent incidents, as well as other critical Sentinel information. And you can also use this page to understand the general security situation before going in to investigate your incidents.
Now let’s talk about some of the evidence and entities that we can find in incidents. Again, Sentinel uses, of course, various sources of security information to create incidents, so basically, you will need to understand those sources to best utilise incident management in Microsoft Sentinel. The Evidence of the Incident First of all, we have two pieces here: the incident evidence and the incident entities. The incident evidence basically contains security event information and related sentinel assets that identify threats in the Microsoft Sentinel environment. Evidence displays how a threat has been identified, and it links you back to the specific resources that you can use to increase your awareness of the incident details.
And here under evidence, we have first of all the events, right? And the events again link you back to one or more events from the Log Analytics workspace associated with Microsoft Sentinel. On their own, these workspaces typically contain thousands of events, even tens of thousands of events. These are too numerous to manually go through them or parse them, right? So if a query attached to a Microsoft Sentinel analytic rule returns events, these events are attached to the generated incident. for potential further review. You can use events to understand the scope and frequency of the incident before investigating further. Then you have the alerts under the evidence, and most incidents are generated because of an analytics rule alert. Again, examples include the detection of suspicious files, the detection of suspicious user activities, attempted privilege elevation, and so on.
Analytics rules generate alerts based on either KQL queries or direct connections to Microsoft security solutions such as Microsoft Defender for Cloud or Microsoft Defender for Microsoft 365 Defender, as we’ve seen in the previous lessons. Now we also have bookmarks. And here, while investigating an incident, you might identify events that you want to track or mark for later investigation. You can preserve the queries run in the Log Analytics workspace by choosing one or more events and designating them as bookmarks. Notes and tags can also be recorded to help reinforce later threat hunting processes. So bookmarks are available to you and your entire, let’s say, security operations team to use them.
Then we get into the incident entities over here, and an entity refers to a network or a user resource involved in an event. Entities can be used as entry points to investigate all alerts and correlations associated with that entity. Entity relationships are useful when you’re investigating incidents. Instead of analysing the identity alerts, network alerts, and data access alerts individually, you can use entities to observe any alerts associated with a particular user, host, or address in your environment. Now again, some types of entities can include the following that I’ve listed here: account host, IP address, URL, or file hash. For instance, entities would help you identify all the alerts associated with a specific user. The user’s host machine and other hosts that the user has connected to are just an example.
You can, for example, determine which IP addresses are associated with the user in question, exposing which events and alerts could be part of the same attack cycle, the same kill chain, let’s say. Now let’s take a look at actually investigating incidents. So after you start using Microsoft Sentinel to generate incidents, you will basically want to investigate those incidents. You can use the advanced investigation and analysis tools to gather information and determine the remediation steps. Now, first of all, to identify and resolve these security issues, you’ll need to investigate the incidents first.
So the overview page in Microsoft Sentinel is the incident overview page. For more details and a complete overview of your incidents, use the Incidents page, which displays all the incidents in the current workspace as well as the details about those specific incidents. Of course, you can now take various steps to investigate the incidents from this page.
Now you can review the incidents, examine the incident details, and manage your incident’s ownership, severity,
status, and of course, classify your incident.So for that, let’s get into the portal and work with an actual incident that I have here. And if we go to the Incidents page over here, I have generated a test incident because basically what I did was set a KQL query to look for any sign-in from this account that I’m currently using and create a sentinel incident as soon as it, let’s say, finds a sign-in from this account. So first of all, here, basically, in the overview page of the incidents, you can see the list of incidents that you currently have in the environment. We only have one here, and if you want to review the incidents, basically this page provides a complete list of your incidents and details about them. Because if I select this incident over here on the right hand side, we will see a detailed page, an overview detailed page, where we can look at the incident’s status. Here we go. The severity depends on whether it’s assigned to any particular member of the security operation team or not assigned.
You can also refer to all of these details to better understand the context of the incident. You see the entities involved in the incident and many, many more details. Now, directly from here, you can manage the ownership of the incident’s data sensibility, as I’ve mentioned. So each incident has manageable data attached to it, and this information can really help you set and track the status of the incident, review the severity of the incident, or assign and track the ownership of the incident.
So for example, if I wanted this incident to be assigned to me, I would just specify it here and click “assign to me,” or you can assign it to any other user or, of course, whoever makes sense or whoever is involved in investigating this incident. Right? Now, in a typical environment, each incident should be assigned to an owner from your security team. Now, the status of the incident is here, and the status can be new, active, or closed, right? Because a new status is created when an incident is created, it should be in an active state when you actually start an investigation on the incident, and when an incident is fully resolved, you will probably want to set the status to closed. Now one more thing here: when you set the status to closed for an incident, let me just do that to show you what I mean.
You will also need to select a classification for this incident, and the classification can be one of the following: positive, which means suspicious activity, as it says here, “positive.” And this basically means it is suspicious activity, but it is expected, right? So someone in your IT admin team, for example, has performed an activity that generated an alert and an incident. So we know this is suspicious, but it is expected. Then there’s the false-positive incorrect alert logic and the false-positive incorrect or incorrect data, right? And this means that the alert has been generated and doesn’t represent a suspicious activity, but rather has incorrect logic in the alert query or the data is incorrect. That means that it generated a false-positive alert.
And then there’s the undetermined state. Now for the severity, and let me cancel out of this for the severity. Basically, this is set by the rule or the Microsoft security source from which the incident was generated. In most cases, the incident severity remains unchanged. However, you can manually set the severity after the investigation to “informational low,” “informational medium,” or “informational high.” Now you can also perform a deep analysis using the investigation graph of the incident. So if I just go here and view the full details of this incident, first of all, you will have a timeline. If there were any other alerts here, they would be correlated to this incident.
And you can select to investigate this incident using the investigation graph. Now this action basically opens up the investigation graph, which is, let’s say, a visual tool that helps you identify entities involved in the attack and the relationship between those entities. If the incident involves multiple alerts over time, you can also review the alert timeline and correlations between the alerts from over here, right? But we only have one alert for this investigation. So basically, after a visual representation, we can see that this account logged in from this IP address and that it generated this alert. I have set an alert rule to generate an incident. For this. You can also review email entities and incident entities sorry.So you can select each entity on the graph and observe more information about the entities. As you can see, we have five related events for this particular entity, in which case it’s a user account. And we also have this IP address, from which it logged in.
Again, one single host is assigned with this IP address, and we can see that host if we click here, which will query a log. Analytics workspace. Again, we get no results because we don’t have much data in our trial tenant, but in a real tenant, you would get those results and everything that you are interested in. You can also review the incident details on the graph. You can observe important incident metadata relatedto the incident security and environment context. And if I go back to the incident page, you can also see here a few full details of the entities involved in this incident. As you can see, this involves an account and an IP address because it’s a pure and simple sign-in event, right? And basically, this brings our discussion to an end. You can play around with this in the portal, and don’t worry, you will have a hands-on lab available at the end of the section in which you will actually work within incidents and get experience hands-on with all of these topics that we are talking about here. Now I will see everyone in the next lesson, where we’ll discuss threat response with Microsoft Sentinel Playbooks. That is the automation part of the incident response. Until then, I hope this has been informative for you.
3. Threat Response with Microsoft Sentinel Playbooks
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. In this lesson, we are going to discuss threat response with Microsoft Sentinel. And specifically, we are going to talk about playbooks. These are automated responses or on-demand responses that you can use in Microsoft Sentinel. So, in addition to assessing and addressing problems with the security integration in a Microsoft Sentinel environment, you also need to respond appropriately. Microsoft Sentinel is both a SIM and SOA solution. Okay, so basically, SOAR means security orchestration automation and response that’s designed for hybrid environments. Now, Microsoft Sentinel uses built-in and custom detections to alert you on potential security threats, such as attempts to access your resources from outside the infrastructure, for example, or when data appears to be sent to known malicious IP addresses. So you can also create incidents based on this alert, as we’ve established.
But you can also create playbooks, right? And here you can create security playbooks and use Microsoft Sentinel to respond to alerts. Security playbooks are basically collections of procedures based on Azure logic apps that run in response to an alert. You can run these security playbooks manually in response to your investigation of an incident, or you can configure an alert to run a playbook automatically when the alert fires. Now, with the ability to respond to incidents automatically, you can automate some of your security operations and make your team more productive. For example, you can develop a workflow with defined steps that can block a suspicious username from accessing resources from a non-corporate or non-secure IP address. Alternatively, you can configure the playbook to perform a simple operation, such as emailing a high-level security alert to your security operations team or posting a message in teams. Now. Azure Logic apps This is done through Azure Logic apps.
Azure Logic Apps is a cloud service that automates the operation of your business processes. You can use a graphical design tool called Logic Apps Designer to arrange pre-built components into the sequence that you need. You can also use the code view to write your automated process in JSON format. The logic now applies. Connector. Logic apps use connectors to connect to hundreds of services. A connector is a component that provides an interface to an external service, such as a logic app connector. Now, one note here: a Microsoft Sentinel Data connector and a logic apps connector are not the same thing, right? As previously stated, a Microsoft Sentinel data connector connects Microsoft Sentinel to Microsoft security products or security ecosystems in order for non-Microsoft solutions to ingest data into Microsoft Sentinel.
A Logic Apps connector, on the other hand, is a component that provides an API connection for an external service and allows integration of events, data, and actions across other apps, services, systems, protocols, or platforms. Right? Now, let’s talk about what the triggers and actions are in a logic application. So in Azure logic apps, you can use triggers and actions, which are defined as below. So a trigger is an event that occurs when a specific set of conditions is satisfied. Triggers activate automatically when conditions are met. For example, a security incident occurs in Microsoft Sentinel, which can be a trigger for an automated action. Now on the other hand, an action is an operation that performs a task in the logic app workflow.
So actions run when a trigger activates the logic app and another action completes or a condition is met. Now let’s talk about the Microsoft Sentinel Logic Apps connector, the one over here. So for the Microsoft Sentinel Logic apps, Connector Playbooks are used in Microsoft Sentinel, right? And for this, we need a connector to basically trigger our logic apps, our playbooks, in Microsoft Sentinel. Now it provides the triggers and actions. So this Microsoft Sentinel Logic apps connector provides the triggers and actions that can start the playbook and perform the defined actions. Now currently there are two triggers from the Microsoft Sentinel Logic Apps connector and these two triggers are the following when a response to a Microsoft Sentinel alert is triggered, or when a response to a Microsoft Sentinel creation rule is triggered.
Now one note here: because the Microsoft Sentinel Logicapp connector is in preview mode, these features that I’m describing here might change in the future, right? Now I’ve summarized this table to basically have a list of the current actions for the Microsoft Sentinel Connector and what they actually do, right? So pause the video for a moment. Please go through the table and see each action and what it does. Now some actions require integration with actions from other connectors. For example, if you want to identify all suspicious accounts returned in the alert from the defined entities, you must combine the entities’ get accounts action with each action, right? So for each account, it will iterate through a loop. So again, let’s go into our next topic and actually talk about how to actually create a logic app. First of all, you can configure the Microsoft Sentinel Playbooks, of course, to respond to your security threats or to automate your security operations processes.
You can automate responses to threats on the Playbooks page. And on this page, you can see your existing playbooks and create new ones. So let’s get into the portal, and I’ll show you where you can find it. So over here on the automation blade, we can see that we have the automation rules, and I’m not going to go into these at the moment. And you have the active playbooks page, where, of course, if we had had any playbooks here, we would have seen them in a list. But we don’t have any playbooks, and we can just create a new playbook. So for this, we can use the Create button over here. And you have several options. Here you have the option of creating an automation rule. You have the option to create a playbook with an incident trigger or with an alert trigger. The ones that I’ve just mentioned occur when a response to a Microsoft Sentinel alert is triggered or when a Microsoft Sentinel incident creation rule is triggered. Or you can go with a blank playbook. Let’s choose the last option. Go with a blank playbook.
And let’s take a look at how we can create our automation playbook here. Now, first of all, you need to give it a resource group. So I will put it in my sentinel resource group. We will give it a name. First of all, let’s see what playbook we want to create. So let’s say we want to create a simple playbook to, let’s say, get an email notification each time a sentinel alert is triggered, right? So I’m going to refer to this as a notification playbook. Here we go. Notification playbook. and then a region. Of course, if you want to be associated with any kind of integration service, we will not do so. In our case, if you want to enable Log Analytics, then you can do so by clicking this tick button over here and selecting the LogAnalytics workspace in which you want this playbook, this logic app, to send its diagnostic logs.
So let’s click on “Review and Create” and create our playbook. Because then we’ll need to get into the logic app designer to actually set our conditions and actions for this particular playbook. So currently it’s validating the playbook, and now we need to hit the Create button, and we will go into the next page where Asia will actually deploy this logic app. Now bear in mind that this is just for demonstration purposes, but in the hands-on lab for this section, you will actually have a task to actually create a playbook, play with it, run it, and so on. So you will get to do this hands-on. Now let’s go to our resource here, to our logic app.
And from here, we will select the logic app designer. We will be taken directly to the logic apps designer because we selected a blank playbook. If we choose one of these two playbooks with an incident trigger or one with an alert trigger, the trigger will be added to our design page once the logic app is created. But this way it will just fire up a blank logic app. And I’m not sure why it’s running so slowly when it should be faster. But again, let me see if I just refreshed here to see if we have our logic app listed. Here we go. So we have it. Let’s try to get into the logic app from here. Here we go. It takes us to the logic app designer. So I will close this page. So now let’s scroll down a little bit and select a blank logic app here. We will need to search for our Microsoft SentinelLogic app connector because that’s the one that contains our trigger, the trigger that we want to use. So let me take it all on over here and type Sentinel. And this will search for the Microsoft Sentinel Logic app connector. Here we go. So we select the Microsoft Sentinel and have the alert trigger and the incident trigger. I am going to select the alert trigger because this way these logic apps and these playbooks with the alert trigger can be run on demand.
The Microsoft Sentinel incident triggers, on the other hand, cannot be run on demand. These are for automated responses. So let’s say you want to create a notification. For example, when a Microsoft Sentinel incident fires up in the Sentinel portal, we would use this incident trigger over here, and once that incident is created, the logic app will automatically run. But I’m going to go with the alert one because I want to show you how to run it after that, right? So let’s click on the Microsoft Sentinel alert. We need to sign in to create a connection to our Microsoft Sentinel environment. We are going to do just that right now because we are prompted by this pop-up over here. Okay? And here we go. The connection should be created. Now for our next step, we need to select an action. What do you want to do when a Microsoft Sentinel alert fires up? So we said that we wanted to create a notification. So for that, we will use another connector from another app, and that is the Outlook 365 app. Okay, so here we go. Let me type Outlook with a single L, and this should probably bring us to the search page here. So office 365 Outlook.
Here we go. And, among the many actions available through this connector, we want to scroll down and look for the Send email action. Okay, so here we go. Send Email. Bear in mind that you can also send an approval email and play with it. For example, if you want a user account to be blocked from signing, right, you can create anaction which connects to Azure ad, blocks that useraccount, sign in, sends you an approval email, or to the security operations team, an approval email. And once you investigate that account and conclude that the activity was legitimate, for example, in the case of an alert, you can click on the “approved” button, and then another action in your flow, in your logic app, in your playbook will unblock that user account. It’s just a simple example, but you can do so much with it.
So now we want, in our case here for demonstration purposes, to send an email, right? And again, we are asked to sign in to create a connection to Outlook 365. I’m going to select this account that I’m using in my trial subscription once more, and we want to send an email to, say, admin sock at whatever your talent is called or whatever email address you specify. Mine is traininglabs 200 on Microsoft.com. Okay, a high alert has been triggered, and here in the body of the incident, you can play around and get more stuff from the Microsoft Sentinel alert trigger over here. So, for example, you can include in the body of the email the entities that were involved in the alert. And this is done by selecting dynamic content over here and clicking on entities. This actually enumerates all of the entities from the previous step in the body of your email. Sorry, this is just a simple logic application based on an action from a trigger. and then an action. We are going to save this logic app.
Okay? And now this is our playbook; this is our notification playbook. Bear in mind that we use the alert trigger so that we can run this playbook on demand. But again, for a notification playbook, you might want to use the incident trigger so that a notification is automatically sent when an incident appears in Microsoft Sentinel. But with the alert trigger, you can do other stuff. You can integrate it with Microsoft Defender for endpoints, for example, to trigger a full scan of the machine that’s involved in an incident, and so on. So when you go to the incident, you just click a button and launch a playbook that will probably initiate a full scan of the machine, isolate the machine from the network, or whatever actions you might think are necessary according to your processes in your security operations.
Okay? So now let’s get back to our Microsoft Sentinel workspace. We have our playbook over here, and if we want to run this playbook on demand, or if we want to manually run this playbook, we would go to our incidents over here, and we see that we have several incidents with my test sign in the analytic rule that I’ve created for the previous demonstration in the previous lesson. So I’m going to select one of these incidents over here, and as soon as it loads up, we are going to click on “View full details,” and then from the incident timeline, you can see that you have a button over here called “View Playbooks.” Now if we click on this, it should have our playbook available. You saw that I needed to refresh this because it probably takes a few minutes to replicate when you create a new logic app, a new playbook, right? So if you would have other playbooks available with the alert trigger, you would have them available over here in a list, and you could choose which playbook you wanted to run for this specific incident.
So in this case, let’s click on “Run over here” to run our playbook. And this basically initiated the trigger from our playbook, and it ran the Logic app that we’ve configured. And for this demonstration, that is to send us an email to notify us of these alerts and include the entities of this incident. And the entities are this one, the account, and the IP address from which the account logged in. And now, let’s return to Microsoft Sentinel. Let’s get back to the automation blade; let’s get back to our playbooks. And now let’s take a look if the playbook succeeded. It might not, because I have specified the correct email address; I’m not sure if I did, but as you can see, the playbook succeeded, right? And if I just log in to my Let me Take This Account over here, let me copy it. Let’s see, view the account, here we go, and here we go. I just want to copy the account from over here, and let’s go to Outlook.com and see if we have indeed received an email. I’m not sure if I specified the correct email address. Again, here we go. Not this one. Okay, sorry. So, let’s go back to Outlook.com and sign in with a different Microsoft account. This is my personal email address. So I’m going to paste this account over here. Indeed.
So I have not specified the correct email address in the playbook. Let’s go back and take care of that. We go back to the Logic app designer again and expand our action, and in the two email addresses we will specify the correct email address. This time, I had a feeling I put in the wrong email address. We saved the playbook. We simply need to go back into our incidents and, say, for another incident, run the playbook from the timeline view playbooks and run. Here we go; this is it. And now our playbook should have run successfully, and here we will try to I’m not sure why it’s not letting me log in to Outlook, but again, I’m not going to go through this because you probably won’t be so interested in seeing an email with the entities from the incident. But again, let me show you once again that the playbook did run successfully twice, as we ran it twice manually from within the incident timeline. And here we go. But again, don’t worry; you will have a playbook to configure from scratch in the hands-on lab for this particular section. There is one more thing I want to show you before we close off this lesson. If I go back to the automation section in Sentinel, you will see that we have another tab here called Playbook Templates. And these Playbook templates are basically templates created by the Microsoft Sentinel community, which are available on GitHub.
And you will have the GitHub link because there are more playbooks in GitHub than the ones that are appearing here as templates in Microsoft Sentinel itself. But you can see that you have a whole bunch of playbooks that you can actually use from the templates, right? So, for example, let’s say that you want a Playbook to reset an Azure AD user password, right? So we can use this template to deploy our own playbook that resets an Azure RDS password, and you can run it again. It specifies over here what kind of trigger this playbook uses. So this uses the Marksoft Sentinel alert trigger, but it can be run manually as well. These ones use the Microsoft Sentinel incident trigger. And suppose you want this book to reset your stale user password. Because, as you see, we have two of them. One that you can use in an automatic way to run when an incident is created, and one that you can manually run, right? So for example, this one, let’s create a playbook and then of course the usual process you need to select resource group, you need to give your playbook a name if you want to associate it with an integration environment or with your log analytics workspace.
And then you need to configure the parameters. So the parameters refer to the account that will be used to sign into the connectors in order to create that initial sign-in in order to create that connection. So for that, I’ll probably use this account that I have, which is a global admin account. Now again, here you have the option to connect with a managed identity, right? And I’m not going to go into this, but I will leave you links to resources for further details in regards to logic apps and what “managed identity” means in the downloadable resources for this lesson. And here we go. A new connection will be configured. A new connection will be configured here. Now let’s click on “Review and Create.” And then, when we start initialising this deployment, it will take a few minutes, and from this template, you will have this playbook available in your own environment. Of course, you can go into the logic app and the playbook itself and customise them in any way, shape, or form that you see fit for your environment. So this will take a few moments. Here we go.
The playbook is deployed, and as you can see, these are the steps that can be expanded. This is how the playbook is configured. Here we go. As you can see, you can customise each of these steps individually, or you can customise them however you want to basically fit your requirements, right? This playbook’s functionality is also described here. So if I just go back into the playbook templates, and if we select the one for resetting a user’s AAD password, this one again has a description. This playbook will reset the user password using the graph API. It will send the password, which is a random width and substance, to the user’s manager, and the user will have to reset the password upon the next login. So this is what this playbook does. You can go through each, and I recommend that you go through each of these playbooks and at least read what they do, the description, and then play with them on your own. This concludes our discussion on this lesson. I’m going to see everyone in the next one, where we’ll talk about yet another cool feature and capability in Microsoft Sentinel called User Entity Behavior Analytics. Until then, I hope this has been the case.
