1. Microsoft Sentinel Overview
Welcome back to my Security Operations Analyst SC 200 course. Now we are starting section six, and we can say that we are starting the other half of the course, in which we are going to focus on Microsoft Sentinel. And of course, for the rest of the course, we are going to focus on Microsoft Sentinel. Now let’s see the lessons in this section. First of all, we are going to have a Microsoft Sentinel overview. We are going to see what it is, what it does, and its capabilities. Then we are going to see how to create and manage a Microsoft Sentinel Workspace. We are going to query logs in Microsoft Sentinel, and we are going to leverage the use of watch lists in Microsoft Sentinel. And in the last lesson, we’ll talk about threat intelligence in Microsoft Sentinel.
So that being said, let’s get on with our first lesson here and have a Microsoft Sentinel overview. First and foremost, let’s start with a few concepts. Let’s say about security information and event management, which is a SIM solution, and about Microsoft SANDYL. So first of all, what is a seam? SEAM is the abbreviation for security, incident, and event management. Now a SIM system is a tool that an organization uses to collect, analyses and perform security operations on its computer systems. Those systems can be hardware, appliances, applications, or both. Now, in its simplest form, let’s say a SIM enables you to collect and query logs from different data sources. It also allows you to perform some form of correlation or anomaly detection. And of course, it is capable of alerting and creating incidents based on the detections that it makes on the logs that you collect. Now Asim might also offer functionalities like this one for log management.
And this is basically the ability to collect, store, and query the log data from resources within your environment. Alerting, right? So this is kind of a proactive look inside the log data for potential security incidents and anomalies. It can also provide visualization, such as graphs, dashboards, and reports, to provide visual insights into your log data. Incident management. The ability here is to create, update, assign, and investigate incidents that have been identified, as well as the ability to query the data. So basically, you should have a query language available in your SIM solution similar to that for log management that you can use to query and understand the data that you are collecting from different sources. Okay. Now let’s talk about Microsoft Sentinel.
So Microsoft Sentinel is basically a cloud-native SIM system that a security operations team can use to, of course, do all of the stuff here and get security insights across the enterprise. Basically, this is done by collecting the data from different sources to detect and investigate threats quickly. Microsoft Sentinel uses machine learning and threat intelligence to do this, and of course it also has the “Orchestration Let’s See” capability. This is to automate threat responses by using what’s called Playbooks, and we’ll talk about this in an upcoming lesson. and integrating with Azure Logic apps, a topic that will also be covered in an upcoming lesson.
Now, unlike a traditional SIM solution, to run Microsoft Sentinel, you don’t need to install any servers, either on-premises or in the cloud. Microsoft Sentinel is an Azure service that you can deploy. You can get up and running with Sentinel in just a few minutes from within the Azure Portal, and we’ll see how to do that in an upcoming lesson. Again, Sentinel is tightly integrated with the other cloud services. So not only can you quickly ingest logs, but you can also use other cloud services natively, for example, authorization and automation. Sentinel also helps you enable end-to-end security operations, including the collection here. the collection piece, the detection piece, the investigation piece, and the automation response piece—the orchestration piece—that we’ve already mentioned.
Okay? Now let’s see how Microsoft Sentinel actually works. So, as we’ve already established, sentinels help enable end-to-end security operations, right? So it starts with log ingestion and continues through automated response to security alerts. Now, let’s see some key features and components of Microsoft Sentinel. So, first and foremost, we have data connectors, and the first step is to have your data brought into Microsoft Sentinel, or ingested into Microsoft Sentinel. So data connectors enable you to do just that. You can add some services, such as Asia Activity Logs, just by selecting a button and toggling it on or off, and it will start ingesting that data. Now, you can also bring in other logs from other data sources, such as Syslog, which require a little more configuration.
And there are data connectors that cover all scenarios and sources, including all the sources here. So Syslog combination format, trusted Automated Exchange Indicators information—that is the taxi protocol for threat intelligence—all kinds of Azurelogs, or for example, other logs from other cloud services like AWS services. Now, you also have a log retention setting that you can configure. And this is basically after the data has been ingested into Microsoft Sentinel, where your data will be stored using Log Analytics.
Now, the benefits of using log analytics include the ability to use the Coastal Query Language to query your data, which we covered in the last section. And of course, just as a reminder, KQL is a rich query language that gives you the power to dive into and gain insights from your data across multiple sources. Then you have the workbooks, and you can basically use these workbooks to visualize your data within Sentinel. You can think of workbooks as dashboards. Each component in the dashboard is built using an underlying KQL query of your data.
You can use the built-in workbooks within Microsoft Sentinel, edit them to meet your own needs, or create workbooks from scratch. You can create your own workbooks from scratch. If you’ve used Asia Monitor workbooks before, this feature will be familiar to you because it’s Sentinel’s implementation of the Asia Monitor workbooks. Right now, don’t worry; we will have lessons to teach, and one of these topics that we cover here is just an overview. Next, you have the analytics alerts. Assume you currently have your logs and some data visualization with the workbooks. It would be great to have some proactive analytics across your data. So you’re notified when something suspicious occurs, right? You can enable the built-in analytic alerts within your Sentinel workspace. And there are various types of alerts, some of which you can customize to your own needs. Other alerts are built on machine learning models that are proprietary to Microsoft and those you contacted.
And you can also create your own custom schedule alerts from scratch. Then we have the threat-hunting capability in Microsoft Sentinel. So we won’t dive deeply into threat hunting in this particular lesson because we have an entire section dedicated to it. But if Sock analysts need to hunt for suspicious activity, there are some built-in hunting queries that they can use. And they can also create their own queries. Sentinel also works with Asia notebooks. It provides example notebooks for advanced hunters who want to use the full power of a programming language such as Python to hunt through their data. Then we have the incidents and investigations. And here, an incident is basically created when an alert that you’ve enabled is triggered. And here you have an incident investigation graph—just an example of how it looks in Microsoft Sentinel. You can do standard incident management tasks like changing the status of the incident or assigning incidents to individuals for investigation. You also have the investigation capability. So, as shown here, you can visually investigate incidents by mapping entities across log data along a timeline. So these are all the entities, and this would be the timeline.
And we will get into more details when we actually talk about this and get into the portal. And then, lastly, we have the automation playbooks. This is the automated response capability. So with the ability to respond to incidents automatically, you can automate some of your security operations and make your security operations centre more productive. Microsoft Sentinel integrates with Asia Logic apps, enabling you to create automated workflows, or “playbooks” as they are called, in response to events. This functionality could be used for incident management, for incident enrichment, for investigation, or for remediation. However you choose to leverage this capability Again, these capabilities are often referred to as “security orchestration,” “automation,” and “response.” The abbreviation would be Sore, right?
So as a stock analyst, you can now start to see how Microsoft Sentinel can help you achieve your goals. So again, it can ingest data from your cloud and on-premises environments. It can perform analytics. It can manage and investigate incidents, and it can automatically respond to incidents by leveraging Azure Logic Apps or Playbooks. Now, let’s get into our last topic here on the course, and let’s see when you would use Microsoft Sentinel. So, Microsoft Sentinel is again a solution for performing security operations on your cloud and on-premise environments. Typically, you would use Microsoft Sentinel when you want to collect event data from multiple sources, as it says here on the slide. When you want to perform security operations on that data to basically detect and identify suspicious or anomalous activity, Now again, security operations can include all of these, let’s say, key points that I’ve mentioned here.
The visualisation of log data, anomaly detection, threat hunting, security, incident investigation, or automated response to alerts and incidents Now, besides this, Microsoft Sentinel also offers other capabilities that could help you decide whether it’s the right tool for you and if it fits your organization’s needs. And it’s a cloud-native SIM, first of all. And this basically has the advantage that you don’t have to invest in hardware, in servers, to keep your SIM solution on premises, right? Then you have the integration with Azure Logic apps, as we’ve mentioned. And basically, you have hundreds of connectors here in the Azure Logic app. So you can automate, if I come to think about it, pretty much everything, right? Then you have the benefit of Microsoft Research and machine learning, which are built into Microsoft Sentinel. And you can leverage that just like that from the beginning, without the need for further complicated configurations.
You have key log sources provided for free. So, for example, all the tools that we’ve talked about up until now, like Microsoft Defender for endpoints, Microsoft Defender for three, Office 365, and Microsoft Defender for cloud apps They have built-in native connectors that enable native integration of these tools with Microsoft Sentinel with just a few clicks of a button. And then again, you have support for hybrid cloud environments and on-premises environments. So you can connect your on-premises resources to Microsoft Sentinel to stream logs from on-premises to Microsoft Sentinel, as well as from other clouds like AWS or GCP. And again, if you come to think about it, you have a theme and a data lake all in one. So this is an odd overview of Microsoft Sentinel; we’ll start discussing it in the next lesson about how to create and manage a Microsoft Sentinel workspace. Until then, I hope this has been informative for you, and I thank you for viewing.
2. Create and Manage Microsoft Sentinel workspaces
Everyone and welcome back to my course, Security Operations Analyst SC 200. Now, in this lesson, we are going to discuss creating and managing our Microsoft Sentinel Workspace or Workspaces. Deploying the Microsoft Sentinel environment involves designing a workspace configuration to actually meet your security and compliance requirements. The provisioning process includes creating a log, an analytics workspace, and configuring the Microsoft Sentinel options.
So let’s expand on that in this lesson. So first of all, before deploying Microsoft Sentinel, it’s crucial to understand the workspace options. The Microsoft Sentinel solution is installed in a Log Analytics Workspace, and most implementation considerations are focused on the creation of the Log Analytics Workspace creation. The single most important option when creating a new Log Analytics workspace is the region. So the region specifies the location where the log data will actually reside. There are three implementation options: a single tenant with a single Microsoft Sentinel Workspace, a single tenant with a regional Microsoft Sentinel Workspace, and a multitenant deployment.
So let’s get into each and every one of these options. So, the single tenant with a single Markon SentinelWorkspace will serve as the central repository for logs from all resources within the same tenant, correct? Because you can see, we have our subscription or subscription resource groups here. And at the bottom here, we have a central point with the Microsoft Sentinel Workspace. Now this workspace receives logs from resources in other regions as well as within the same tenant. Because the log data, when collected, will, of course, travel across regions and be stored in another region. This creates two possible concerns. First, it can incur a bandwidth cost. And second, if there is a data governance requirement to keep data in a specific region, the single workspace option would not be recommended. Let’s say you chose the implementation option, and I’ve summarised here in this table at the bottom of the page the pros and cons of a single tenant, single workspace deployment.
So take a moment and please go through them. We are going to talk about our second option here, and that is the single-tenant with regional Microsoft Sentinel Workspaces. So this deployment model, let’s say, will have multiple Sentinel Workspaces, requiring the creation and configuration of multiple Microsoft Sentinel and Log Analytics Workspaces, as you can see here in this graphical representation. Again, you have the talent and the subscription, which is fine, but you have multiple, multiple. This is the first deployment method, and this is the second deployment method with regional Microsoft Sentinel Workspaces. As you can see, you have multiple resource groups in multiple regions, each with its own Microsoft Sentinel Workspace. Again, I’ve summarised the pros and cons in this table over here.
And basically, to query, as it says here, the data across workspaces, you can use this type of query in Kousa query language. Now let’s talk about the last option here, which is multitenant workspaces. And here if you are required to manage a Microsoft Sentinel Workspace but lack the necessary skills. You then implement the multitenant workspaces using Azure Lighthouse. This security configuration basically grants you access to the tenants. The tenant configuration within the tenant itself—regional or multiregional—is the same consideration as before. Now, in this deployment model, as you can see, we have Tenant A, Tenant B, and Tenant Cover here, and Tenant A, Tenant B, and Tenant C will all be managed by Asia Lighthouse. This deployment model is typically carried out by a service provider, correct? For example, if it provides security services for multiple customers, with each customer having its own talent and its own Microsoft Sentinel Workspace, Okay, let’s get into our next topic here and actually talk a little bit more about Asia Lighthouse and what it does.
So again, if you are required to manage a Microsoft Sentinel Workspace that is not in your tenant, implementing Asia Lighthouse will provide the option to enable your access to the tenant itself. Once Azure Lighthouse is onboarded, you can use the Add another directory subscription selector on the Azure Portal to select all the subscription-containing workspaces that you actually manage. Azure Lighthouse allows, let’s say, greater flexibility to manage resources from multiple customers without having to actually sign in to different accounts at different tenants. As an example, as previously stated, a service provider may have two customers, as in this example, with varying responsibilities and access levels. So using Azure Lighthouse, authorised users can sign into the service provider’s tenant to access these resources in both tenants.
Okay. Now let’s talk about creating a Microsoft Sentinel Workspace. So after designing the workspace architecture, you can log into the Azure Portal and search for Microsoft Sentinel. And then you just select the plus button to add your Microsoft Sentinel Workspace. However, there are some prerequisites, right? And the prerequisites are the following: To enable Microsoft Sentinel, you must have contributor permissions for the subscription in which the workspace is to be enabled. And to use Microsoft Sentinel, you need either contributor or reader permissions on the source group that the workspace belongs to. Let’s get started with the subscription itself, our trial subscription. And let me show you how to create a Microsoft Sentinel Workspace before.First of all, we need to create and configure a Log Analytics Workspace, and then add the Microsoft Sentinel Workspace to the LogAnalytics Workspace that we’ve created.
So let me get into our subscription over here. Again, from the search bar, you can search for Sentinel. Click on “Microsoft Sentinel.” As you can see, I already have a workspace deployed, but I am going to show you how to basically create a new Microsoft Sentinel Workspace. So first and foremost, we need to create a separate Log Analytics workspace. So if I just type in Log Analytics here, let’s go to Log Analytics Workspaces and click on the Create button. Now let’s put our workspace, say, in the Sentinel resource groups. Let’s name our workspace “Sentinel.” Okay, then let’s select a location for our workspace. I’ll stay in West Europe to review and create. Of course, if you wanted to assign text to this resource, you could do that. Now I will click on Create, and we’ll wait for our Log Analytics workspace to be deployed and created.
Once that’s complete, of course, we need to go and add the Microsoft Sentinel solution to this workspace that we’ve just created. So we’ll just wait a few moments for this to be deployed. It shouldn’t take very long, but again, it depends on the region and on how your Azure Portal is performing. Okay, so now that we’ve created the workspace, we can click on Go to Resource, and here is our Test Sentinel workspace. Getting back to the main search here, let’s select Microsoft Sentinel, and let’s click on Create. Here’s the plus button. And now we need to select the Log Analytics workspace that we want our Sentinel workspace to be added to. So I’ll select the test sentinel workspace and click add, and that’s it. The deployment will basically start. I’m not going to do that. But on the next screen, basically, you will have an active screen, and the Microsoft Sentinel Workspace will have three areas: general threat management, configuration, and an overview tab. I’m going to show you this in my already-deployed workspace, and let me cancel out of this.
So if I just select the Sentinel workspace over here, As you can see, you have the general threat management area and configuration and, of course, content management, which is a kind of new feature. As you can see, they’re all in preview mode. Okay, now we’ve created our Microsoft Sentinel Workspace. Let’s talk about Microsoft Sentinel permissions and roles. And for that, I’m going to quickly get back to our slides over here. So Asia role-based access control is basically the authorization system that manages access to Asia resources. It’s built on Asia Resource Manager, which provides fine-grained access management of Azure resources. You can use Azure RBAC to create and assign roles within your security operations team, for example. And Azure RBAC lets you grant the appropriate access to Microsoft Sentinel. Now the different roles give you specific control over what users of Microsoft Sentinel can access and actually do. Now, there are some Markove sentinel-specific roles. And these are the Microsoft Sentinel subscribers.
Microsoft Sentinel responder and Microsoft Sentinel contributor So the reader role can basically review data, incidents, workbooks, and other marks of Sentinel resources. The responder role has all the permissions of the reader role, plus it can manage incidents by assigning or dismissing them. And, like the reader and responder roles, the marks of sentinel contributor role can create and edit workbooks, analytic rules, and other marks of sentinel resources to deploy marks of sentinel on your tenants. Of course, as I’ve mentioned in the prerequisites, you need the contributor permissions for the subscription where the Microsoft Sentinel Workspace is actually deployed. All of these built-in Microsoft Sentinel rules grant read access to data in your Sentinel Workspace. For best results, let’s say these roles should be assigned to the resource group that contains the Microsoft Sentinel Workspace. The role then applies to all resources that will be deployed in that resource group, if those resources are, of course, in the same resource group.
Now let’s talk about the additional roles that you would need to properly manage Microsoft Sentinel. So these are the Asia roles and Asia Log Analytics roles because, in addition to the Microsoft Sentinel dedicated Asia RBAC roles, other Asia and Log Analytics roles AsiaRBAC roles can grant a wider set of permissions. These roles include access to your Microsoft Sentinel workspace and other resources. So the Asia-specific roles here basically grant access to all your Asia resources, which include the Log Analytics Workspaces and Microsoft Sentinel resources. And here we have the owner role, the contributor role, and the reader role. So basically, if you have the owner role at the subscription level, you will also have access to everything in the Microsoft Sentinel Workspace and the Log Analytics Workspace.
Then we have the log analytics roles that grant access to your log analytics workspace. These are the log analytics contributor and log analytics reader roles. Now, just as an example, for a given user, who is assigned the Microsoft SentinelReader and Asia Contributor role, right?So Asia, not Microsoft Sentinel, is a contributor. This user can add data to Microsoft Sentinel because it has the “Asia Contributor” role at the subscription level. If you only want to grant permissions to Microsoft Sentinel, then you should carefully remove the user’s prior permissions, and of course, make sure you don’t break any kind of needed permission role for any other resource within the subscription. Now, let’s talk about the Microsoft Sentinel roles and the allowed actions. And as you can see here, I’ve summarised this in a table with the role and the allowed permissions, right? So please pause the video, take a moment, review the table, and we will go into our next topic, where we’ll discuss how to actually manage some of the Microsoft Sentinel Workspace settings. And for that, I’m going to go back to our portal here.
And of course, Microsoft Sentinel environment settings are basically managed in two areas: in Microsoft Sentinel and in the Log Analytics workspace where Microsoft Sentinel resides. Now in Microsoft Sentinel, over here on the left navigation pane, we have an option for settings, and I will click on this. And here you can manage some of the settings specifically for the Microsoft Sentinel Workspace, right? And here you would have, as you can see, pricing settings and workspace settings over here. Now, basically, most of the Microsoft Sentinel environment settings are actually managed in the Log Analytics Workspace. Other areas within the Microsoft Sentinel portal will actually transfer you to the Log Analytics Workspace. If you want to configure a data connector, for example, some of the data connectors will be configured in the Log Analytics Workspace settings. And now let me give you a quick example of how you can configure the log retention.
So again, by clicking on Workspace settings over here, as I’ve mentioned, you will be taken to the LogAnalytics Workspace settings, and if we go to usage and estimated costs here, and as you can see on the top of the page here, you have a data retention option button, or whatever you want to call it blade.And if we click on this, it is set to default to 30 days, and you can set it to whatever. Let’s see what necessary requirements you have in your environment. Now bear in mind that the default 30 days are free, but anything beyond 30 days is not free in Log Analytics. If you have Sentinel Workspace deployed on your Log Analytics Workspace, the free period goes up to 90 days, and everything that’s above 90 days will be billable or charged by Microsoft. With that being said, this concludes the discussion for this particular lesson. And of course, I will see everyone in the next lesson, where we’ll start talking about how to query logs in your Microsoft Sentinel Workspace. Until then, of course, I hope this has been informative for you.
3. Query logs in Microsoft Sentinel
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. Now in this lesson we are going to talk about querying logs in Microsoft Sentinel. Of course, we already know that Microsoft Sentinel collects log data from different data sources and actually stores this log data in tables in the Log Analytic workspace that you’ve enabled Sentinel on. The logs page in Microsoft Sentinel provides a user interface to build and view query results using the Kusto query language, which we’ve covered in a previous section.
So now let’s take a look at the log page again. KQL is the language used to query the log data in the Log Analytics Workspace. And in Microsoft Sentinel, the logs page provides access to the query window. This is the query window on the table, and it should look familiar; it’s the same one we used in our Log Analytics demo environment. Well, that’s because it is the same. Basically, it’s the same log page as the one we have used in Log Analytics in the Koostoquari language section. But here we do have some additional tables in the log schema that are specific to Microsoft Sentinel, and we’ll go just through those tables. Next, let me change the slide. Here we go. So first of all, let’s try to understand the specific Microsoft Sentinel tables. Microsoft Sentinel has analytic rules that will generate alerts and incidents based on querying the tables within the Log Analytics Workspace. The Security Alert table (which I will highlight) and the Security Incident table are now the primary tables for managing alerts and incidents.
Now again, Sentinel provides tables to be a repository of indicators and watch lists on top of that. Now one note here is that some data connectors will send alerts directly and will not store them in any table like the Security Alert table. Now again, take a look at the table and the differences over here on the right side, and we will go into our next slide and we’ll talk about the common tables that we can find in Microsoft Sentinel. So again, when Sentinel ingests data from the data connectors, depending, of course, on which data connectors you have enabled, these are the most commonly used tables. So as your activity here shows, you can query the logs that have to do with any kind of subscription-level event right here in Azure Diagnostics.
We have system activity and information about user and group management applications and directory activities if you’ve enabled diagnostics for your Asia resources, such as virtual machines, key vaults, network security groups, and the list goes on the audit logs table here. I’m not going to go through all of them; I just want to highlight a few. So MCAs have a shadow. It reporting. This is if you’ve integrated your Microsoft Defender for Cloud with Microsoft Sentinel and enabled the streaming of the Microsoft Defender for Cloud logs. Right here. It says “Microsoft Cloud App Security.” Not to cause any confusion, this is the old name of Microsoft Defender. For Cloud, you can stream Office Activity, and the logs will be stored in the Office Activity table. The security event table Of course, this is where the security events from your connected virtual machines go.
Asia virtual machines or on-premise virtual machines with signed-in logs are both options. This comes from the Asia ActiveDirectory sign-in logs in syslog. If you have any kind of Linux or Unix computer, machine, or server in the environment, you can stream those logs as well into Sentinel. Then you have Windows Firewall logs again, which can be sent to Microsoft Sentinel. Now let’s see the specific Microsoft 365 Defender tables. When you enable the Microsoft 365 Defender SentinelData connector, you can choose to populate tables with raw data from Microsoft 365 Defender solutions. And some of these—probably all of them—have to do with Microsoft Defender for endpoints.
So, as you can see, you can stream the device event logs, devicefile, events logs, device image load logs, device info logs, device log on events network info, device registry events, or process events. So I recommend pausing the video and reading the explanations for each table. In the meantime, I’m going to go into the portal and show you how to access the log window from within Microsoft Sentinel. So it’s very easy on your Sentinel workspace. You just click on the logs blade over here, and you will be taken to the exact same window that we used for our log analytics demonstration in the demo environment. But again, here you can also find the Microsoft Sentinel-specific tables that we were talking about in the slides, like the security incident, the security alert, email events, and all of those device events that I’ve mentioned in regards to Microsoft Defender 365 raw logs. That being said, guys, this concludes our discussion for this particular lesson.
I’ll see everyone in the next lesson, where we’ll go over another cool feature that you can use in Microsoft Sentinel in conjunction with your queries, logs, and, to be more specific, your Cousteau query language. And you can use this feature very effectively in your detection queries, in your analytics rules, and in the watch lists in Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for viewing.
4. Use Watchlists 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 the concept of watch lists in Microsoft Sentinel. Microsoft Sentinel basically provides a table of store list data accessible through the Cousteau query language queries. The Watch List page in Microsoft Sentinel provides the management options necessary to actually maintain this list. So let’s get started and see what watch lists are and what they do.
Microsoft Sentinel Watch lists allow you to collect data from outside sources and correlate it with events in your Microsoft Sentinel environment. Watch lists, once created, can be used in your search detection rules, threat hunting, or response playbooks. Watch lists are stored as name-value pairs in your Microsoft Sentinel Workspace and are cached for optimal query performance and low latency. So these are basically just lists of entities, or whatever you want to call them, which you can import from external sources and use in your Microsoft Sentinel workspace to correlate between event alerts. And I will show you momentarily what I’m actually talking about. First of all, let’s see some common scenarios for using watch lists. For example, the first one here, and let me bring up my pen, is when you want to investigate threats or respond to incidents with the import of, say, IPad dresses, file hashes, or other data from CSV files. Once imported, Watch lists name key-value pairs can be used for joins, filters and alert rules, threat hunting, workbooks, notebooks, or general queries. Another use-case scenario would be to import business data as a watch list.
For example, you can import user lists with privileges and grant high privileges to systems, right? So you can import this user list, or another example would be a list containing terminated employees. Then, using these watch lists, you can create, allow, or deny lists that are used to detect or prevent those users from logging into the network. Just an example You can also use watch lists to reduce alert fatigue. So you can create “allow” lists to suppress alerts from a group of users, for example, users from authorised IP addresses that perform tasks that would otherwise normally trigger alerts. And you can prevent those nine events from becoming alerts this way. Or you can use watchlists to enrich event data. You can use it to enrich your event data with name-value combinations, again derived from external data sources.
Okay, now let’s talk about actually creating a watchlist. And for this, I’m going to go into the portal, and I’m going to show you exactly how to do that. So here in the Microsoft Sentinel Workspace, if we go to the Watchlist page over here, we also have a template preview. I’m not going to talk about this because it’s in preview, but you have templates for watch lists like high-value assets, identity correlation, network addresses, service accounts, terminated employees like I just mentioned, or VIP users. You can create lists from these templates, but again, you will have links to documentation in detail in regards to this. In the downloadable resources for this particular lesson, I am going to show you how to do it the old-fashioned way. Let’s see. So you just go here and click on “Add new watch list.” Let’s give our watch list a name. So we’ll call this experiment Watchlist and an alias. I am going to do the same. But again, you can use any name here, but you can use an alias to actually reference the alias in your queries, right in your Cousteau queries. Now, let’s click on “next.” Now it asks us for a CSV file to import the list. Now, I have a CSV file here on my desktop. Let me just show it to you. Here we go.
So it’s just a list with an IP address header, a CSV with an IP address header, and two fictional IP addresses, right? So let me go back into the portal and let me choose this CSV file as my source for my list. As you can see, we have the header IP address and the IP addresses that I’ve specified in my CSV file. Now click on “next” to review and create. For some reason, the verification is missing or not valid. Okay, so we need to specify a search key field. And as it says here, the search key is used basically to optimise query performance when using Watchlist. Now, not to use fancy words here, you need to specify the actual header from your CSV file, right? So now let’s click on “Review and Create” and create our watchlist. Now, once that’s done, we can see our watch list over here, as you can see. Let me also demonstrate how you would use this watchlist in your Kusto query analytic rules, Workbooks, or threat hunting queries.
So let’s get over to the logs page here. And to do this, we need to use this function, which is called Get Watchlist. And here is how you can use it: Let me delete this. So we must specify the name of our watch list here, which we will call test watch list. Here we go. And if I just run this query again, it will return the values that we’ve specified in our CSV file in our Watch list. So this is how you can query your watch list, and by using this Get Watch List function, you can integrate them into your analytics rules, your workbooks, your threat hunting queries, and the list goes on. In the downloadable resources for this lesson, I will include links to additional documentation with much more information about Watchlists and how to use them. And with this being said, this concludes our lesson. I will see everyone in the next one, where we’ll talk about utilising threat intelligence in Microsoft Sentinel. Until then, I hope this has been informative for you. And thank you for viewing.
5. Use Threat Intelligence in Microsoft Sentinel
Welcome back to my course, Microsoft Security Operations Analyst SC 200. We will discuss the threat intelligence component of Microsoft Sentinel in this lesson because Microsoft Sentinel also provides a table-like structure with watch lists to store indicator data that is accessible via the Koso query language. Queries on the Threat Intelligence page in Microsoft Sentinel provide the management options to maintain these threat indicators. But first of all, let’s talk about what threat intelligence is and the threat intelligence part of Microsoft Sentinel. So-called “cyber threat intelligence,” or CTI, is information describing known existing or potential threats to systems and users. This type of knowledge takes many forms, from written reports detailing a particular threat actor’s motivation and infrastructure techniques to specific observations of, say, IP addresses, domains, and file hashes associated with cyber threats.
Organizations usually use CTI cyber threat intelligence to provide essential context to unusual activity so that security personnel can quickly take action to protect their people and assets. CTI can be sourced from many places, such as open source data feeds, threat intelligence sharing communities, commercial intelligence feeds, or local intelligence gathered in security investigations within an organisation itself. Now, within a security information and event management system solution, In a SIM solution like Microsoft Sentinel, the most utilised form of cyber threat intelligence is threat indicators. Often referred to as “indicators of compromise,” or simply “IOCs,” Threat indicators are data that associate observations such as URLs, file hashes, or IP addresses with known threat activities such as phishing, botnets, or malware. This form of threat intelligence is often referred to as “tactical threat intelligence” because it can be applied to security products and observed and automated on a large scale to basically protect and detect potential threats to an organization.
In Microsoft Sentinel, you can use threat indicators to help detect malicious activity that is found in your environment and provide context to security teams to help inform response decisions. Now, you can integrate threat intelligence into Microsoft Sentinel in many ways, but basically, you can integrate Ti through the following activities that I’ve listed here on the slide: So first of all, you can use data connectors to various threat intelligence platforms to import those threat intelligence indicators into Microsoft Sentinels. Threat intelligence platforms would be like third-party solutions that provide threat intelligence feeds. You will actually have a task in the hands-on lab that’s available at the end of the section to actually integrate threat intelligence feeds using the taxi connector.
That’s called the limousine anomaly. So you will do this hands-on. Now, another activity is to view andmanage the imported threat intelligence indicators. And you can do this in the logs on the logs page of Microsoft Sentinel using the Kousa query language. Then you can use the built-in analytic rules to generate security alerts and incidents using your imported threat intelligence. You can reference those threat intelligence indicators in your analytic rules to create alerts and incidents. You can also visualise information—overview information—in regards to your threat intelligence with the threat intelligence workbook that’s available out of the box in Microsoft Sentinel. And last but by no means least, you can also perform threat hunting queries with your imported threat intelligence by referencing the threat intelligence indicators again in your Cousteau query language queries. Now this is what it looks like. So first of all, you have the connectors with which you can import your threat intelligence indicators into Microsoft Sentinel, as I’ve mentioned, the ones using the Taxi protocol using taxi servers.
These are available as free or paid open-source services. Or you can integrate threat intelligence feeds from your threat intelligence platform. third-party solution, right? All of these go into Sentinel, where you can query the data. You can query your threat intelligence indicators by using the threat intelligence indicator table in Log Analytics. And then you can also reference them in your analytic rules to create incidents and alerts. And you can also use them in your playbooks over here, so you can reference them in your automated responses, right? And also, of course, you can make use of the threat intelligence workbook, which basically provides you with a nice overview and dashboard about your threat intelligence imported into Microsoft Sentinel. Now let’s see how we would manage our threat indicators that we have imported. Well, we would do that by using the threat intelligence page in Microsoft Sentinel.
And let me just get into the portal, and here you would go to the threat intelligence page. Of course, here we have no threat indicators imported, but again, when you import them using the connectors (the data connectors will go into data connectors in the next section), they will automatically appear here and you can edit them and work with them. But you can also manually add your own threat indicators based on, for example, your past security investigations from your past security incidents, right? And to do that, you would click on “Add New” over here. You first need to select the type of threat indicator that you want to add, like a domain name file, IPV 4 or 6, or a URL. We will choose IPV4 for our demonstration here, and then you need to specify the actual indicator.
So in our case, it would be an IPV4 address. So let’s take one example: you can tag your indicator if you want, or if you are using some kind of tagging strategy within your Microsoft Sentinel workspace or within your Asia subscription overall, then you need to select the threat type. and here you have several options. Let’s choose a malicious activity for our demonstration here and then a description. And you need to give your threat indicator a meaningful name. In our case, I’m going to call this one IP, right? if I can spell that as well. Okay, you can give it a confidence level from zero to 100, let’s say in our case. We are 100% sure that this is a known bad IP address, and you can set a validity date. So we will set the validity starting from today, and you can also create a lifespan for this indicator. And if I specify here that it will expire tomorrow, this indicator will basically not be valid anymore starting from tomorrow. I won’t set an expiration date, or better yet, just leave it so it can expire, and all we need to do is click Apply.
Now this will create our indicator over here. As you can see, it’s created a better IP. We can select it; of course, we can code our threat indicator; we can add tags to our threat indicator; and so on. If you want to use this in your loganalytics workspace, you’d use the threat indicators, the threat intelligence indicator table, and let me go into logs to see what this looks like. So the threat intelligence indicator is set to 10, and I am going to limit the results to ten. We only have one, and we don’t know if it’s been replicated. So we might not get any results. Again, it will take a little bit of time for the indicator that we’ve created to actually replicate itself in the threat intelligence indicator. So probably if you are doing this, just leave it for about two to four minutes, and then you can run your query again and you will get your results with your threat intelligence indicator.
Now this concludes our discussion for this lesson and also concludes our section with regard to configuring the Microsoft Sentinel Environment. Now I strongly suggest that you go in and do the hands-on lab available for this section, where you’ll do many cool things. You’ll enable your Microsoft Sentinel workspace, you’ll configure it, and you’ll also work with threat intelligence indicators and basically with most of the topics that we’ve discussed throughout the section. Now I will see everyone in the next section, where we’ll discuss actually connecting logs to Microsoft Sentinel. So we are going to connect logs from different data sources, and we are going to start to get data into our Microsoft Sentinel environment that we can use further in our detective actions and investigations. So until the next section, I hope this has been informative for you, which I thank you for.