Secure Application Lifecycle - Part 3 - Azure Sentinel

Published Jan 25 2021 03:15 PM 1,911 Views
Microsoft

In the past part 1 and part 2, I discussed how we can monitor the security and health of our subscription manually. Also, we used Microsoft tools to find security issues with the subscription and discussed how we could resolve them.

Today I would like to discuss another Azure service called Azure Sentinel, to monitor security incidents in our subscription and respond to them.

 

What is Azure Sentinel?

Microsoft Azure Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Azure Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.

Azure Sentinel is our birds-eye view across the enterprise alleviating the stress of increasingly sophisticated attacks, increasing volumes of alerts, and long resolution time frames.

  • Collect data at cloud scale across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds. 
  • Detect previously undetected threats, and minimize false positives using Microsoft's analytics and unparalleled threat intelligence. 
  • Investigate threats with artificial intelligence, and hunt for suspicious activities at scale, tapping into years of cybersecurity work at Microsoft. 
  • Respond to incidents rapidly with built-in orchestration and automation of common tasks.

magdysalem_0-1611613203893.png

 

Using Azure Sentinel, We can collect security data. Then we can use the tools offer by Azure Sentinel to investigate these logs for the events we are interested in.

Also, we can use machine learning backed Azure sentinel tools to detect familiar security incidents. After we found these incidents, we can easily respond to them using responders. This means we can monitor Azure subscription security status or the subscription health and respond to Misconfigurations.

 

Consider the following example. We have resource group with the following azure services,

magdysalem_1-1611613203912.png

What kind of security checks we could enable and monitor

  • Storage account: HTTPS is mandatory enabled.
  • Key vault: soft-delete is enabled.
  • Azure SQL database: Threat detection is enables.

This can be done easily by configuring these services to send their logs to in Azure Sentinel workspace to monitor and report. The following section is a walkthrough demo where we will do the following:

  • Provision Sentinel workspace
  • Configure resources to send diagnostic logs to Sentinel.
  • Configure Sentinel to respond to incidents.

Provision Azure Sentinel Service

We can select all services, search for Sentinel, and click on Azure Sentinel.

magdysalem_2-1611613203933.png

 

Then we can click Create a new workspace

magdysalem_3-1611613203938.png

 

magdysalem_4-1611613203955.png

 

Now, we will give the workspace name and select a region that is suitable for Our resources. Once our workspace is ready then We can click add Azure Sentinel

magdysalem_5-1611613203968.png

 

magdysalem_6-1611613204003.png

our Azure sentinel workspace is created. So now we can go ahead and configure a few Azure resources to send logs to this workspace.

Configure resources to send diagnostic logs to Sentinel

We will start with apps services. From the portal page for the app services, we can scroll down under monitoring, click on diagnostic settings, click on add diagnostic settings.

magdysalem_7-1611613204044.png

 

From the Diagnostics setting, we can select a different type of logs to send to Sentinel workspace as following

magdysalem_8-1611613204062.png

 

We can do the same steps with other resources like Azure Key Vault

magdysalem_9-1611613204083.png

 

Now if we check the Azure Sentinel workspace page, we will see something like the following.

magdysalem_10-1611613204104.png

 

Configure Azure Sentinel to respond to Incidents

In this section, we will explain how to configure Azure Sentinel to respond to incidents and security violations. First, we need to connect Azure Sentinel to a data source by clicking on data connectors, it will show us a list of data sources.

magdysalem_11-1611613204136.png

 

We will configure Azure Sentinel to detect and respond to policy violations in our subscription. In this case, we will need to select Azure Activity as our data connector and click “Configure Azure Activity Logs”

magdysalem_12-1611613204158.png

 

Then we select the subscription and click Log Analytics Connection

magdysalem_13-1611613204171.png

 

magdysalem_14-1611613204182.png

 

Now, We are connected and Azure sentinel instance can now ingest Azure activity logs. We can check Activity Logs by running a simple query to make sure we are receiving logs

magdysalem_15-1611613204207.png

 

Next step, we will create a query to return policy violations.

magdysalem_16-1611613204232.png

 

Once we verify the query is working properly, we can start setting the alert. From Sentinel blade click on Analytics and click on “Create” to establish a new rule

magdysalem_17-1611613204253.png

 

Here we will fill the rule fields and Click Next

magdysalem_18-1611613204264.png

 

Under rule logic, we will enter the query that we created previously.

magdysalem_19-1611613204281.png

 

We will scroll down to specify how often we want the query to run.

magdysalem_20-1611613204295.png

 

After filling the schedule, we can click on Incident settings where we need to specify how we want Azure Sentinel to respond to the incident. If we do not have a playbook set up yet we can just click “Review” and create the alert

magdysalem_21-1611613204311.png

 

magdysalem_22-1611613204329.png

 

Next, we will add a new logic app to respond to the alert we just created in the above section.

From the Playbooks section click create a new playbook

magdysalem_23-1611613204345.png

 

We will be redirected to a new page to create a logic app

magdysalem_24-1611613204360.png

 

Once the logic app is created, we can review the “Overview page” and select “Blank Logic App”

magdysalem_25-1611613204372.png

 

The only difference between an ordinary logic, app, and responder is the first action. The first action here should be Azure sentinel.  Also if it is not showing, we can simply search for it.

magdysalem_26-1611613204376.png

 

Now, we will choice respond to Azure Sentinel Alert

magdysalem_27-1611613204398.png

 

Next will select the connection to connect to the Azure Sentinel Workspace instance

magdysalem_28-1611613204404.png

 

Once we complete the connections by choosing an existing one or create a new one.  We can use the Get entities functions, which enable us to get the relevant entities from inside the Entities list, such as accounts, IP addresses, and hosts. This will enable us to run actions on specific entities.

Now, We can define what happens when we trigger the playbook. We can add an action, logical condition, switch case conditions, or loops. For example, once an alert is triggered it will send an email and post a message in Team. Please review Logic App for more information

magdysalem_29-1611613204407.png

 

The last step now, we need to configure the alert to use the playbook we just created.

We start by clicking analytics and select the alert we click Edit

magdysalem_30-1611613204445.png

 

Click on Automated Response then click on the playbook we just created in the previous section

magdysalem_31-1611613204466.png

 

Then click Review and save. Now if any resource will violate the policy in place we will be notified from Azure Sentinel. Also, we can check Incidents Review to check all the violation and incident As we can see it is extremely easy to use Azure Sentinel to respond to security events threatening the health of our subscription

 

magdysalem_32-1611613204479.png

 

Summary

In this series, we talked about the importance of security. There are two aspects of security validations, credentials in the code, and Azure subscription security. 

We discussed CredScan tool and how we can use it automatically The credits can Tool has two flavors. Clients and server-side, the clients is a visual studio extension, which we can install on the developers' machine. So, each time the developer builds the solution, they'll get a list of warnings of the credentials in the coat. The Server side can be integrated into the continuous integration pipeline. So each time a bill kicks off, CredScan is going to look for credentials in the code.

 

 In the second blog, we talked about AzSK. This tool can be used to run security health checks for Azure subscriptions.

 

In the final blog, we talked about Azure Sentinel and talked about how we can provision it and how we can configure azure resources to send diagnosis logs to Azure Sentinel. We also talked about how to set an incident alert and how to configure a playbook to respond to the alert as an automated response for an incident.

 

Thank you for reading, I hope the information is useful to you. 

Version history
Last update:
‎Jan 25 2021 03:20 PM
Updated by: