Integrating on-prem security information to Azure Sentinel via SCOM | Quisitive
Search

At a recent SCOM event (SCOMathon), I had the opportunity to learn about Nathan Gau’s security management pack for SCOM. I immediately realized what I’m sure Nathan had all along – that the information available in this pack could be invaluable in Azure Sentinel. So, during (and after) this event, I reached out to Nathan to express this and offer whatever help I could to make this a reality. Once we started communicating on the topic, I quickly realized that I needed some big guns on the Azure Sentinel side, so I asked Rod Trent if he would join in on this project. So, fast-forward to today, I am excited to announce the release of On-Prem Security Monitoring for Sentinel!

Highlights of this management pack include:

Check out Rod’s and Nathan’s blog posts on this new solution at the links below!

Rod:

Nathan:

Welcome to the “Introducing” series. In the previous blog post, we introduced Logic Apps. In this blog post, we will introduce a security solution that Microsoft has created called Azure Sentinel.

What is Azure Sentinel?

Security is a core requirement for IT organizations. Compute, network and storage-based devices each gather information about what is occurring for those devices and write that data into some form of a log. For Windows systems these are written to event logs, Linux systems write to log files, and network/storage devices write their data to Syslog servers. Azure Sentinel works to consume and correlate these logs to provide new capabilities.

SIEM: With security data being written to many different types of systems, it is difficult to impossible for system administrators to watch all the different log files to identify relevant information. Furthermore, it is both challenging and complicated to compare events within one log with another to detect any patterns that could indicate the need for attention, sometimes critical attention. As a result, it is common to generate alerts for specific conditions or to gather the information across the various systems into a single location where the data can more effectively be analyzed. This common repository is a Security Information and Event Management (SEIM) solution. A SIEM aggregates data and helps to correlate these data to provide actionable alerting and dashboards that assist with performing analysis of the security information that is collected. Think of it as a one-stop-shop for all security events across all of information technology’s compute, network, and storage devices whether on-prem or in the cloud.

SOAR: Security Orchestration Automation Response (SOAR) provides the automated actions that a company decides should occur when specific conditions are identified. An example of this is what is referred to as the “Impossible Travel” situation. This would occur if a user logged in to their work computer in Dallas at 8:00 am and then logs into another system in Europe two hours later. It is an impossible travel situation as even with the fastest air travel it would not be possible for the same person to have logged in at these times in both locations because it would take too long to travel from the first location to the second location. When a situation like this occurs, organizations may choose to perform automation that validates the situation for specific risks (such as, was it a different computer for the two logins, does the user have a VPN that may be communicating to Europe, etc.) and then performs some form of action. For the “Impossible Travel” situation, this might be disabling the user’s account and generating a notification to the user’s manager – after verifying that it was a different device on each login and that the user does not have a history of using VPNs.

So, what is Azure Sentinel? Azure Sentinel is a cloud-based SIEM and SOAR solution that can be used to gather security information from across an organization and help to identify and remediate security threats.

A did-you-know: Also, if you are familiar with internal and external IT audits, you may be familiar with some of the requirements that many regulations and laws require. One such common requirement is the retention and review of security event logs. Now, apply what we have just discussed, and you will quickly realize how Azure Sentinel can play a beneficial role in helping you meet this audit requirement even automatically. We will delve into this topic later in the series.

What are the components of Azure Sentinel?

Azure Sentinel is built upon existing Azure technologies including Log Analytics, Kusto, Logic Apps, Workbooks, and Azure Monitor. If you have been reading this series for a while now, the list below should seem very familiar as these were the recent blog posts in this series.

Log Analytics: The data that is gathered by Azure Sentinel’s connectors are stored in a Log Analytics workspace.

Kusto: As the data for Azure Sentinel is stored in a Log Analytics workspace, Kusto is the query language that is used to work with the data that is gathered by Azure Sentinel.

Logic Apps: Azure Sentinel uses Logic Apps to perform remediations for alert conditions to provide low-code or no-code automation. In Sentinel, these are referred to as “playbooks”.

Azure Monitor/Workbooks: Workbooks provide pre-built and customizable solutions to visualize the data stored in Sentinel. In Sentinel, these are referred to as “workbooks”.

Working with each of the solutions above provides a solid foundation to work from when learning Azure Sentinel.

Connectors: Data connectors are used in Sentinel to gather data from a variety of sources. An example of this is shown below where the connectors are filtered by the keyword “Azure”. Connectors that are already installed into Sentinel are shown with the vertical green bar on the left of the icon representing the Azure service.

What are common uses for Azure Sentinel?

Once data has been collected by Azure Sentinel it can be used to assist with investigating a potential incident or to hunt for threats in the environment.

Insights: Incidents are a gathering of alerts, entities, and additional evidence that is gathered when an alert is triggered based on the detection. The example below shows several incidents in Azure Sentinel.

Investigation: The details of an incident can be investigated an incident and see the relationships between the various entities as shown below.

Digging further into an investigation provides pre-built Kusto queries that can be used to further analyze the underlying data.

Hunting: Sentinel includes a variety of pre-built queries that assist with hunting for threats in an environment.

Tip: Azure Sentinel also has a community on GitHub that contains custom workbooks, hunting queries, notebooks, and playbooks. If you are looking for additional hunting queries (among other assets), it is a good place to start.

How is Azure Sentinel priced?

Additional Reference material:

Special thanks to Ed Higgins, Rod Trent, and Maarten Goet for their assistance with this blog post!

Welcome to the “Introducing” series. In the previous blog post, we introduced workbooks. In this blog post, we will introduce a “low code” or “no-code” option for developed called Logic Apps.

What does “low-code” or “no-code” mean?

Traditional development is done by writing software (IE code) to perform the actions that you want to take. As an example, the browser you are currently using to access this website is an application that was written with code. The concepts of “low-code” or “no-code” provide a method to develop an application without having to write code through using a graphical user interface and providing configurations within the user interface. This approach is often embraced by people who are not developers, such as an IT professional like me.

What is Azure Logic Apps & what are common uses for it?

Azure Logic Apps is an automation platform that provides a graphical user interface and pre-built components (called connectors) that you can use to build automation, in most cases without having to write code.

We utilize Logic Apps to automate the delivery of scheduled reports, to gather data from different sources and act upon that data, or to perform automation that occurs when a specific situation is identified with other Microsoft solutions such as Azure Sentinel.

The graphic below shows a simple example of Logic App which on a scheduled basis queries information from a data source (Log Analytics in this case), and then sends an email with the relevant information. We utilize Logic Apps on our managed automation team to provide delivery of scheduled reports to our customers.

Logic Apps can also be used for more complex tasks such as gathering data from an external Application Programming Interface (API). The graphic below shows a completed Logic App which queries to gather data from an API. In the example below this is querying to gather current weather data from the OpenWeather API. This could be used for any type of API.

What are connectors?

Connectors are pre-built components that can be used to assemble automation. They are triggered in some way (such as a scheduled to run on a specific recurrence, or when a web request is made), and they act after they are triggered. There are a variety of connectors for Logic Apps which are documented here and here.

How are Logic Apps priced?

Logic Apps pricing is based on the number of actions that you perform and the connectors that you use within your automation. Details on pricing for Logic Apps is available here.

If you have ever seen Power Automate or Microsoft Flow, Logic Apps may look very familiar. This is logical because Flow is built on top of Logic Apps, they both share the same designer user interface, and they can share connectors. If you have worked with Flow you should find Logic Apps very simple to work with.

Additional Reference material:

Series Navigation: