1. Connect Data to Microsoft Sentinel using Data Connectors
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. Now we begin Section 7, in which we will discuss connecting, specifically connecting logs to our newly created Microsoft Sentinel. So here’s what we’ll go through: In this section, we are going to talk about connecting data to Microsoft Sentinel using the data connectors.
We are talking about connecting Microsoft services to Sentinel, connecting Microsoft 365 Defender to Sentinel, connecting Windows hosts to Sentinel, connecting Chef logs to Sentinel, using CEF (common event format), connecting Syslog Data, and connecting threat indicators to Microsoft Sentinel. So let’s get into our first lesson here and talk about the data connectors in Microsoft Sentinel. So data is sent to the Microsoft Sentinel Workspace by configuring the provided data connectors. Now, the included Data Talk connectors are for Microsoft 365 Services, Asia Services, and third-party specific services. So here we go. Let’s talk about ingesting logs with the Data Connectors.
So to collect log data, you need to connect your data sources with Microsoft Sentinel connectors. The Data Connectors page will display a growing list of connectors provided by Microsoft Sentinel. And Microsoft is constantly adding new connectors to this list. For example, as you can see, the picture from the slide was taken when there were 120 connectors available. Now if we just quickly switch back to the portal and go to the Data Connectors tab, we’ll probably see that there are 122 connectors available for us in the Microsoft Sentinel Workspace. Now, after selecting the connector page, the detailed connector page has a left blade and a right blade. Now the left blade, as you can see, displays the connectors themselves, and the right blade displays information about each connector. So I’m going to switch back to the portal, and let’s select, for example, a connector. Let’s select the Asia-Pacific directory one.
So here we have the connector itself, and on the right blade, you have a description of the connector and you have other information like when it was connected, when the last data was received, and, of course, a nice little graph about how data is being sent and ingested into your Microsoft Sentinel Workspace. Now just note here: the connector does not install workbooks and analytic rule templates, right? So when you connect a connector to Microsoft Sentinel, you just connect and start streaming data. Then you also need to configure analytic rules, detection rules for that specific connector, and any workbooks, if there are any available, of course. Okay, now let’s describe a little bit what connectors we have available here in Microsoft Sentinel. So first of all, we have the Microsoft 365 Defender connector available, and the Microsoft 365 Defender and related data connectors basically provide the alerts and data that have already been normalized and used in the Microsoft 365 Defender portal. So here are all of the available data and connectors.
So there’s Microsoft Defender for Endpoint, Microsoft Defender for Identity, Defender for Office, 365 Defender for Cloud Apps, and the Insider Risk Management Connector, which is in Preview. Again, all of these connectors are available in Microsoft Sentinel. Then we have the Microsoft and Asia Services Connectors. And this is the whole bunch of lists of connectors available, like the Asia Directive directory, the one I’ve just shown you as your activity identity protection, DDoS Protection Defender for IoT Information Protection as your firewall, and the Asia Web application firewall. Again, Microsoft Defender for Cloud has its own connector. And then we have the DNS connector and the Office 365 connector. This basically streams activity data in Office 365 User Activity Data, the Windows Firewall connector, and the Security Events connector, with which you can connect your Windows machines to stream data and logs to Microsoft Sentinel.
Then we have the vendor connectors. And in this regard, Microsoft Sentinel essentially provides an ever-expanding list of vendor-specific data connectors. These connectors primarily use the CEF and Syslog Format to stream data into Microsoft Sentinel. Now, we also have custom connectors using the Log Analytics API. So you can use the Log Analytics DataCollector API to send logs to Microsoft SentinelLog Analytics Workspace, and you’ll have links with documentation on how you can do that in the downloadable resources for this lesson. Also, we have the Log Stash plugin using the Markson Sentinel’s output plugin for the Log Stash data collection engine. You can also send any log you want directly to your log using log stash. Markson Sentinel’s analytics workspace The logs are written to a custom table that you define using the output plugin. Again, you’ll also have documentation with regard to this plugin and the downloadable resources for this particular lesson. Now the CEF and syslog connectors common event format and syslog connector. If no vendor-provided connector is available, for example, you can use the generic common event format or Syslog connector.
Syslog is an event logging protocol that is common to Linux, but applications will send messages that may be stored on the local machine or delivered to a Syslog collector. On the other hand, the common event format is an industry standard for messages that sit on top of Syslog messages, and it is used by many security vendors to enable event interoperability, say, across platforms. Now, let’s talk a little bit further about Syslog versus the common event format. The common event format is always a superior choice because the log data is parsed into predefined fields in the common security log table. Syslog provides rather header fields, but the rawlog message is stored in the Syslog table in a field called “Syslog Message.” So the entire message is stored in a single field where, in the common event format, the message is stored in many different fields in the Log Analytics table. Of course, for the Syslog data to be queried, you will basically need to either write a parser to extract specific fields or create some kind of, let’s say, query complications again to be able to query or extract specific fields.
Now, let’s take a look at the connector architecture options. So, to connect the CEF or Cisloc connector to Microsoft Sentinel, the agent must be deployed on a dedicated Azure virtual machine or an on-premises system to support the appliances’ communication with Microsoft Sentinel. You can deploy the agent automatically or manually. Automatic deployment, of course, is only available if your dedicated machine is an Azure virtual machine. Now, the following diagram illustrates an on-premises system sending Syslog to a dedicated Azure VM running the Microsoft Sentinel Agent. So basically, in a nutshell, this entire VM is your log collector. Let’s say all these sources from your on-premises system are configured to forward CEF or Syslog logs to this machine, which of course has the Syslog daemon installed on it and the Log Analytics agent, of course.
And this configuration is done via TCP port 5114 or UDP port 5114. Then this demon, which basically receives the logs, will forward the logs on TCP port 25226 to the log analytic agents, from which they will go into Microsoft Sentinel. Alternatively, you can also deploy this VM into your own on-premises environment. As you can see here, this is the entire on-premises environment that you have the syslogs for. The log analytic agents will still be installed on this particular VM over here, and the process is the same. The sources will send logs to the VM via TCP or UDP port five one four, to the Syslogname, and the VM will forward this to the Log Analytics agent, which is also running on the VMON TCP port two five, two to six. And then from there on, they will be streamed to your Log Analytics workspace and your Microsoft Sentinel workspace, of course. Now let’s see, basically, how to view the connected hosts.
And here is a very simple process: So the data connector page shows the connectors that are connected and the number of Windows and Linux hosts connected with the Log Analytics Agent that are available in the Log Analytics Workspace. Now, to see this, I’ve enumerated what you need to do over here. But I’m also going to show you exactly how to use the portal. So let me get into the portal, and if I just open this connector page for Asia Active Directory, for example, you will see here the kind of logs that are streamed. Again, we are streaming. But if you want to view your connected hosts in the Microsoft Sentinel Workspace, your Windows or Linux VMs that are actually sending logs to this workspace, Let me just search here for the security event. Here we go. This is the connector window. security events via MAA, right? There is another one called Security Events via Legacy Agent, which basically does kind of the same thing.
But this one is used for servers or machines that you have on board. It’s through the Asia Arc, and we’ll get into that a little bit later. So here, as you can see, if we open the connected page, you will see what logs are being connected and the streaming of blogs, but you cannot actually see which machines are actually sending logs to your workspace. So for that, you will need to go into the log analytics workspace. And let me just open up another tab over here, and let’s search for log analytics here in the search bar: log analytics workspaces. Here we go. And we proceed to our sentinel workspace. And then on the agent management tab, you will find your Windows servers. Currently, I have none that are sending logs. And if you switch to this tab, you will see your connected Linux computers, and here are the connected Windows servers. And with this, we conclude our lesson. I will see everyone in the next lesson, where we’ll discuss how to connect Microsoft services to Microsoft Sentinel. Until then, I hope this has been informative for you, which I thank you for.
2. Connect Microsoft 365 Defender to Microsoft Sentinel
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. Now, in this lesson, we are going to discuss connecting Microsoft services to Microsoft Sentinel. So first of all, let’s talk a little bit about planning the Microsoft 365 Connectors deployment. Microsoft 365 Security Portal again provides a purpose-driven interface to mitigate threats by using the Microsoft Three Six Five Defender. The Microsoft Three Six Five Defender family of products will include things like Microsoft Three Six Five Defender for Endpoint, for Identity, for Office 365 Cloud apps, and all of those that we’ve talked about until now. These products each have a connector that will send alerts to security alerts stored in Microsoft Sentinel, which then can of course generate an incident. The Microsoft 365 Defender connector from all of those individual connectors also allows for the raw, normalised data to be ingested by Microsoft Sentinel.
Now, currently only the Microsoft Defender for Endpoint Data is configurable in the Defender 365 Connector, along with the email data from Office 365. Now, I will try to show you in this lesson how you can actually connect all of these connectors individually or use the other option of connecting the Microsoft Three Six Five Defender Connector, which will automatically enable all of the other connectors. So let’s get back to the portal, and let’s talk about our first connector here, which is the Microsoft Defender for Office 365. So here in the portal, if we go to the connectors and search for Microsoft, OK, we will go down and see that we have all of these connectors over here. The Defender, which I mentioned earlier, includes the Defender for Cloud, the Defender for Cloud apps, the Defender for Endpoint, the Defender for Identity, the Defender for IoT, and the Microsoft Defender for Office 365 Connector. Again, what this connector does is essentially send the security alerts. And if I just scroll down here, as you can see, it will send the security alerts from Microsoft 365 Defender and let me just go back, sorry, into Microsoft Sentinel.
So if we open the connector page, the only thing you need to do is connect the connector, right? There will be a Connect button here. Of course, mine is already connected, and you will see a Connect button here. You click Connect. And then as next steps, you have the option to enable these analytic rules, for example, which basically pull their data and query the data from this specific connector, the Microsoft Office 365 Connector. And you can see how to create query alerts for this specific connector. But again, I’m going to show you a new way to do it, which is the recommended way, at least from my point of view. But also, Microsoft recommends doing it this way because I’m talking about the Microsoft 365 Defender connector, and when you enable that connector, you enable all of the other Defender Suite connectors. So let’s get back and see the other one. That is Microsoft Defender for Endpoint Connector. Again, this is the one. Again, it streams the security alerts into Microsoft Sentinel. We open the connector page, and we will also see a button to connect. You will just click Connect, but beware that you need read and write permissions and you need to be a global administrator or security administrator to be able to enable this particular connector. Now, you might have noticed that every one of my connectors says I cannot disconnect while Microsoft 365 Defender is connected. That is because I have connected all of my connectors using this one, the Microsoft 365 Defender. And this is the one that I will talk about just now. And if you open the connector page, you will see several configuration options here.
First of all, you have the Connect button. So, when you connect this connector, it will start streaming all of these below, which you can select. So this is the raw Microsoft Defender Endpoint data. As you can see, you have the DeviceInfo events, the Device Network Info events, the Device Process events, the Device Network events, and all of the other events connected to or collected by Microsoft Defender for Endpoint from your workstations, laptops, mobile devices, and so on, right? And you can stream all of those right into Microsoft Sentinel using this particular connector. Then you also have the Microsoft Defender for Office 365 events. So this will also stream the email events, the email URL, and info events.
So, information about URLs in Office 3, 6, and 5, emails, attachment info, and email post-delivery events All of these are available through this particular connector. Now, once you’ve selected what events you want to stream into Microsoft Central, you click on “apply changes” over here. One last thing that I want to mention is very important. Now, when you click this button to connect incidents and security alerts, as you can see, it connects the Microsoft 365 Defender incidents to your Microsoft Sentinel. So incidents will appear in the incident queue.
So once you do this, this is a bidirectional process, let’s say, right? Because you don’t need to enable the analytic rules to create incidents from alerts from other products like Microsoft Defender for Endpoint, Microsoft Defender for Identity, or Microsoft Defender for Office 365, So basically, if you enable these connectors one by one, like I’ve shown you previously in the portal, you will also need to go and create the analytics rules that will basically create Microsoft Sentinel incidents based on alerts from each of these products.
Now, you won’t need to do it via disconnector because once you hit this Connect button, what will happen is the following: any kind of incident, and, as you can see here, a security alert. So any kind of security alert or security incident triggers the Microsoft 365 Defender, the unified portal, and the Security Center, correct? Security Microsoft.com. As a result, any incident or alert generated there will automatically generate a Microsoft incident in Sentinel. As a result, an incident will be created in Sentinel. Now, once you investigate that incident in Sentinel and you close that incident in Microsoft Sentinel, it will also automatically close the incident in Microsoft 365 Defender or the alert in Microsoft 365 Defender.
And as you can imagine, this is a more convenient way to work. Because you will only have to work from Microsoft Sentinel and won’t have to, let’s say, pivot through the portals, Or let’s say you investigated an incident in Microsoft Sentinel related to Microsoft Defender for Endpoint, right? In Microsoft Sentinel, you close the incident. Then you will also need to go into Microsoft 365 Defender to close the incident there as well. Well, with this connector, this issue is basically resolved. Simply close the incident in Microsoft Sentinel. It will automatically close all other portals from which the alert or incident originated. Now don’t worry, you will enable these connectors in the hands-on lab that’s available at the end of the section. You will enable them one by one. And of course, this concludes the discussion in regards to connecting Microsoft 365 Defender to Microsoft Sentinel. I’ll see you in the next lesson somewhere. We’ll discuss connecting Windows hosts to Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for viewing.
3. Connect Microsoft Services to Microsoft Sentinel
Everyone and welcome back to my course, Security Operations Analyst SC 200. Now in this lesson, we are going to discuss connecting other Microsoft services to Microsoft Sentinel. You can connect Microsoft and Asia-related services on the data connector page again with just a few clicks. So let’s get into the portal, and let’s see our first connector over here. Let me get back to the data connector page. That is the connector for Office 365. And for the Office 365 connector, this one essentially provides insights into ongoing user activities.
So you will get details of operations such as file downloads, requests, sent changes to group events, set mailbox operations, and other details in regard to Office 365 activity. So let’s search here on our connectors page for Office 365. And here we go. This is the connector. So I am going to open the connector page just now, and as you can see, you can connect exchange logs, SharePoint logs, and team logs. So for that, you just need to click on “Apply changes.” This will validate the connector, and again, it was successfully validated. The connector appears with a green bar, which means it’s connected. The only thing left to do is to begin ingesting logs. Now the other connector that I wanted to talk to you about in this lesson is Microsoft’s Azure Service connector. So this one is for the Azure Active Directory connector. I’ve already shown you that when we’re disconnected, we have a lot of options. So we have all of these logs available that we can send into Microsoft Sentinel. Sign-in logs, audit logs, non-interactive user sign-in logs, service principal sign-in logs, and managed identity sign-in logs can all be sent.
These are the accounts that applications that use managed identity use to log in ADFS signing logs, provisioning logs, user risk events, and risk users. This one actually comes from Asia AdIdentity Protection, which is the connector we’re going to talk about next. Now, as you can see, I have all of these logs connected over here. So again, it’s a matter of choosing which ones you want to ingest in your Microsoft Sentinel workspace and clicking on Apply Changes. Now the Azure ActiveDirectory identity protection connector And here, this one basically provides a consolidated view of all utterly at-risk users, risk events, and vulnerabilities, with the ability to remediate risk immediately and set policies to automatically remediate future events. This is Azure AD identity protection. And for this, I am going to open the connector page, and you can see that you can stream the alerts generated from Azure Active Directory Identity Protection into Microsoft Sentinel so they will get created as incidents in Microsoft Sentinel.
Now, as next steps, you can query the security alert table for the Azure Active Directory Identity Protection alerts.
Or you can create these rules to create incidents based on Azure Identity Protection alerts. And we will create the rules when we get to the next section, when we’ll actually discuss creating analytic rules about detections and about how to perform investigations. So these are the majority of AzureServices connectors to which you can connect. Of course, you have an Azure firewall. Azure’s keywords are security, information, and security. So basically, you can stream logs from all of your Azure Services into Microsoft Sentinel to be analysed for potential threats, suspicious activity, or abnormal activity. So that being said, this concludes the discussion for this lesson. I am going to see everyone in the next one, where we’ll discuss connecting Windows hosts to Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for reviewing.
4. Connect Windows Hosts to Microsoft Sentinel
Everyone and welcome back to my course, Security Operations Analyst SC 200. In this lesson, we are going to discuss connecting your Windows hosts. Your Windows host sends logs to Microsoft Sentinel. So first of all, let’s talk about planning this. The Security Events connector basically lets you stream all the security events from your Windows systems, servers, or workstations, physical or virtual, to your Microsoft Sentinel workspace. This enables you to view Windows Security events in your dashboards, use them to create custom alerts, or rely on them to improve your investigations. This gives you more insight into your organization’s network and expands your security operations capabilities. Now you can select which events to stream from the following sets.
So you can select all events, and this again forwards all Windows security events and unlocker events to Microsoft Sentinel. You can select the common set. So this is a standard set of events for auditing purposes. A full user audit trail is included in this set. For example, it contains both user sign-ins and sign-outs. There are also auditing actions such as security group changes, key domain controllers, Kerberos operations, and other types of events. in line with the accepted best practices. You can also choose to stream minimal events. Minimal events are basically a small set of events that might indicate potential threats. This set does not contain a full audit trail, and it covers only events that might indicate a successful breach and other significant events with low rates of occurrence.
For example, it contains successful and failed user log-ons. Still, it doesn’t contain sign-out information for the event. For example, for event 4634 and the last one, none This means that no security or up locker events will be recorded. Now you can enable this connector via the connectors page as well. It’s called Security Events via Legacy Agent, and I’m going to show you how to do it. So back here in the portal on the connectors page, let’s search for security and get the security events via the Legacy agent. So if we open the connector page, first of all, we have the option to, again as I’ve mentioned, select which events to stream: non, minimal, common, or all events, right?
And then you have the option to install the agent on Azure virtual machines. That is done with this link, by downloading the agent for Asia Virtual Machines and actually installing it on the machine that you want to connect to. Alternatively, install the agent on non-Asia virtual machines. Install the agent on non-Azure Windows machines, and of course, you can download the agent and then install it on the machine, and then click on the Connect button once the logs begin to stream into the log analytics workspace in the Microsoft Sentinel workspace.
So here, if you click on this link, you will be taken to this page. So you download the agent for 64-bit machines or 32-bit machines. And once the agent is installed, you will need to specify the workspace primary ID. The workspace. ID. Sorry. And the workspace primary key in the agent itself, so the agent can begin communicating with the Microsoft Sentinel Workspace. Now this is a way to do it, another way to do it, and this is with the Asia Monitoring Agent. However, you can connect to either Asia-based or non-Asia-based virtual machines; this only applies to virtual machines onboarded via Asia Arc.
Now don’t worry, I’m not going to go through this connector because you will have a hands-on lab available at the end of the section in which you will actually do just this. The Asia Monitor agent will connect your Windows servers in the lab with Windows Security events. One last thing I want to mention in this lesson is that you can also collect system events. And here Sysmon, or System Monitor, is a Windows system service and device driver that remains resident across system reboots to monitor and log system activity to the Windows event log. Once it is installed on a system, it provides detailed information about process creations, network connections, and changes to file creation times. By collecting these events, it generates them using the Windows Event Collection or SIM agents and then analyses them so you can identify malicious or anomalous activity and understand how intruders or malware operate on your network.
Installing and configuring Sysmon is out of the scope of this course, but you will have a link to documentation with step-by-step instructions on how to install and configure Sysmon on one of your machines. And you will also have an exercise in the lab where you will do just that. After connecting the CIS monitoring agent to the machine itself, you can enable CIS monitoring system logs to be streamed to Microsoft Sentinel from within Settings. Click here and go to Workspace Settings. Then, from the Agents configuration blade over here, you just need to click Add Windows EventLog and search for Microsoft. Let’s look at Microsoft Windows. Let me type it in here. Microsoft Windows CSM and operational Here we go. Then click it and select Apply Changes. From this point forward, all system events will be streamed into your Log Analytics Workspace, which, of course, has Microsoft Sentinel enabled. This concludes the discussion for this lesson. I am going to see everyone in the next lesson, where we’ll discuss connecting common event format logs to Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for viewing.
5. Connect CEF logs to Microsoft Sentinel
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. Now, in this lesson, we are going to discuss connecting common event format logs to Microsoft Sentinel. So you can stream events from Linux-based or syslog-supporting machines or appliances even to Microsoft Sentinel using the log analytics agent for Linux, formerly known as the OMS Agent. And you can do this streaming on any device that allows you to install the Log Analytics agent directly on the host. Now, the host’s native syslog daemon will collect local events of the specified types and forward them to the agent, which will stream them to your log analytics workspace. Log analytics supports message collection via Rsislog or Syslog Ngdemons, as specified here.
And the default syslog demon on version five of Red Hat Enterprise Linux, Sent OS, or Oracle Linux is not supported for syslog event collection. Now, the Rsyslog demon should be installed and configured to replace the SysK log of these versions of Linux that I’ve just mentioned that are not supported. So, how does this work, so Syslog Events? Syslog is an event logging protocol that is coming to Linux when the log analytics agent for Linux is installed on your VM appliance. And this is the VM appliance. This one is in the Azure architecture. So you host your log collector in Asia. This one is for on-premises use only. So you deploy your log collector on premises here. The installation routine basically configures the local syslog daemon to forward messages to the agent on TCP port 26.6, as you can see here. Then the agent sends the message to your log analytics workspace over HTTP, where it is parsed into an event log entry in the Syslog table in Microsoft Sentinel logs. Now, let’s talk about connecting, specifically connecting the Microsoft Sentinel common event format connector.
So you first need to designate and configure a Linux machine either in Asia or on-premises to forward logs from your security solutions to your Microsoft Sentinel workspace. This machine can be physical or virtual, and it can be on-premises, an Azure VM, or a VM bound to another cloud. Using the link provided on the CES page, you will run a script on the designated machine that will perform the following tasks: First of all, it will install the Log Analytics agent for Linux and configure it for the following two purposes: And I’m going to select them here, right, listening for coming down format messages from the built-in Linux syslog daemon and securely sending these messages to your Sentinel workspace over TLS. Then it will also configure the built-in Linux syslog daemon, either R, syslog D, or syslog Ng, for the following two purposes: It will listen for Syslog messages from your security solutions on TCP port 51, and it will forward the messages it identifies, of course, in Chef format, into the log analytics agent using TCP port 225226.
Now, when you run the deployment script and give me access to the portal, let’s go to Microsoft Sentinel and data connectors. and search for common event formats. Here we go. This is the one. If we open the connector page, you will basically run the script as follows: So you select the Linux machine that you want to, let’s say, transform into your log collector. And then you just copy and paste this command from over here. What this does is it will actually run a script that will install the log analytics agent, and after that it will actually configure the syslog daemon on the Linux machine and the log analytics agent to receive logs and stream them forward to your log analytics workspace in Asia. So this is how it’s done.
And then, after you run the script, you can also run the following script to validate your connectivity. What this does is actually do some checks to see if the installation script ran successfully, and it will send a test log into your log analytics workspace. So this is basically how you connect common event format logs to Microsoft Sentinel. Again, you will have links in the documentation files for this particular lesson with step-by-step instructions on how to implement this connector. That being said, this concludes our discussion for this lesson. I am going to see everyone in the next lesson, where we’ll discuss how to connect Syslog data to Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for viewing.
6. Connect Syslog data to Microsoft Sentinel
And welcome back to my course, Microsoft Security Operations Analyst SC 200. In this lesson, we are going to address connecting Syslog data sources to Microsoft Sentinel. Now, as with the Common Event format, you can stream events from Linux-based syslog-supporting machines or appliances into Microsoft Sentinel, again using the Log Analytics Dick’s Agent. Now it is basically the same as what you did with the Common Event format.
But here, rather than the agent looking for common event format logs and streaming them into Sentinel, they will ingest all the logs from the appliances, security solutions, or Linux machines that are streamed via Syslog. And then you can configure exactly what events to collect. Now again, when you collect data, you have a special dedicated connector called the Syslog Connector. And for that, I am going to go straight into the portal and show you how you can perform this. So, I’m going to open the connector page, and you can see from the start that you have two options: install the agent on Azure Linux Virtual Machines or install the agent on non-Azure Linux Virtual Machines on-premises. When you do this – when you click Download and Install the agent – you will be taken to the Log Analytics page, where the agent will be available.
If we click on Linux servers over here, you will have the agent available through this script. So you can copy this command and run it on your machine. This command, if you copy it directly from here, will also contain the necessary workspace ID and primary key of your workspace, which is your Log Analytics workspace. And this will install the log analytic agent on the Linux machine and start listening for Syslog events, which will be streamed to your Microsoft Sentinel workspace depending on the configuration you choose. So after doing this step, you actually need to go into your Log Analytics workspace and configure these installed agents on Linux machines to collect syslog data and to specify what type of syslog data to collect. So to do that, we are going to go back here and go to the settings part of the Microsoft Sentinel and click on Workspace Settings. We are now in the workspace settings, essentially in the Log Analytics workspace settings, and we must proceed to the agent configuration.
And you can see that there is a tab called Syslog available here. Well, from here, you can configure your Syslog data collection. So by clicking on this, you can add a Syslog facility, and you have all the Syslog facilities available over here, right? And let’s say that I want to stream syslog data, right? So we’ll click on FTP, and then you can select what type of severity of syslog you want to send. So you can select to stream the debug logs, info logs, notices, warnings, errors, critical alerts, or emergency logs.
Now, depending on your requirements, you can send all of the types of logs or just some of them. Again, this completely depends on your type of configuration and your organization’s requirements. And in a nutshell, this is how you connect Syslogs to Microsoft Sentinel. Again, don’t worry; you will have documentation in the downloadable resources for this lesson with more details and step-by-step instructions on how to configure this. With this being said, this concludes yet another lesson from this section, and I will see everyone in the next lesson, where we’ll discuss connecting threat intelligence and threat indicators to Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for viewing.
7. Connect Threat Indicators to Microsoft Sentinel
Hello everyone, and welcome back to my course, Microsoft Security Operations Analyst SC 200. In this last lesson from this section, we are going to discuss connecting threat indicators to Microsoft Sentinel. So first of all, we need to take a look at how to plan for Threat Intelligence Connectors. So Microsoft Sentinel again, as we’ve established in a previous lesson, lets you import the threat indicators your organisation uses, which can basically enhance your security’s ability to detect and prioritise known threats. Several features from Microsoft Sentinel will then become available or will be enhanced. These ones are the analytic rules, and this includes a set of scheduled rule templates you can enable to generate alerts and incidents based on matches of log events from your threat indicators that you have imported. Then the workbooks will also get enhanced.
And these workbooks basically provide summarised information about the threat indicators imported into Microsoft Sentinel and any alerts generated from analytic rules that match your threat indicators. You can also enhance your hunting queries, which allow security investigators to use threat indicators within the context of common hunting scenarios. And lastly, the notebooks can use threat indicators when you investigate anomalies and hunt for malicious behaviors. Now, you can stream threat indicators to SendNow by using one of the integrated ThreatIntelligence platform products, connecting taxi servers, or by direct integration with the Microsoft Graph Security Ti Indicators API. There are two threat intelligence connectors: the taxi connector and the threat intelligence platforms connector.
Both connectors write to the ThreatIntelligence Indicators table in Log Analytics. So let’s take a look at the taxi connector. Microsoft Sentinel integrates with Taxi Two and TwoOne data sources to enable threat intelligence monitoring, alerting, and hunting. You can use this connector to send threat indicators from taxi servers to Microsoft Sentinel. Threat indicators can include IP addresses, domain URLs, or file hashes. Now again in the Azure portal, if we go to the Threat Connectors, you will see the Threat Intelligence Taxi Connector, and from here you can basically configure the settings for your taxi server over here and specify which threat feeds you want to ingest. Now don’t worry, you will have a task in the lab for this section in which you will configure this connector to ingest threat indicators from an open source taxi feed called Limo Anomaly. So you will do this step by step in the hands-on lab, going on to the next threat intelligence connector available. And this is the threat intelligence platform connector. And here again, Microsoft integrates with Microsoft Security Graph API sources to enable monitoring, alerting, and haunting using threat intelligence. You can use this connector to send threat indicators to Microsoft Sentinel from your own threat intelligence platforms.
And these can be intelligence platforms such as Threat Connect, Palo Alto Networks, MindMeld, MISP, and other integrated applications. How do you go about doing that? Let me get into the portal. We are in the Threat Intelligence Platform connector over here. So you have all the necessary options here. So, first and foremost, you must register an application in Asia Active Directory. And if you click on this link, it will actually take you to a tutorial—a step-by-step tutorial on how to do that. Over here, I’m going to close this. Then you need to configure the permissions of this newly registered application to give the threat indicators read, write, and own permission in Microsoft Graph. And again, clicking on this link will take you to the documentation with step-by-step instructions on how to do that. Then the next step is to ask, or if you are an Asia administrator, you need to grant admin content to the application. And again, clicking on the links shows you how to do that. And the last step is to configure your threat indicator platform, whatever that is, to push indicators to Microsoft Sentinel. Again, specifying these three key points here—the application ID for Microsoft Sentinel as the target and the action for each indicator—will basically alert or push depending on your threat intelligence platform.
Again, you have a list of full documentation over here, which I strongly suggest that you go through to see step-by-step instructions on how to configure this connector. This brings our discussion to an end for this lesson and also the section as well. You have a hands-on lab available at the end of this section, which I strongly suggest that you go in and do because you will do hands-on configuration on all the topics that we’ve discussed throughout this section. And you’ll also have the review questions available to test your knowledge of what you’ve learned on the topics. Again, throughout this section, I’m going to see everyone in the next section, where we’ll start discussing creating detections and how to perform investigations on incidents using Microsoft Sentinel. Until then, I hope this has been informative for you, and I thank you for viewing.
