Azure Sentinel – Where to start?

First announced back in late February, Azure Sentinel is the first cloud native SIEM service from a major provider. SIEM (security information and event management) is a primary component in any security service. Sentinel aims to leverage cloud specific benefits like elastic scale and AI to allow customers detect and respond to security incidents as quickly and efficiently as possible.

The workflow of Azure Sentinel can be broken into four steps:

Azure Sentinel core capabilities

1. Collect

Sentinel allows you to collect data at scale from multiple users, devices, applications and infrastructure, hosted in Azure, on-premises, and even in multiple clouds. This means you can aggregate all security data using industry standard log formatting. With built-in integration, you can enable collection for features such as Office 365 or Azure AD within seconds.

2. Detect

Having all of your data collected to Sentinel allows for more simple analysis and detection at scale than was previously possible. This more efficient triage, and the capability to leverage Microsoft Machine Learning allows you to be more productive, minimise false positives and react to those high accuracy alerts as early as possible.

3. Investigate

Sentinel allows you to visualise and resolve alerts using the same dashboards. Proactively hunting for incidents can be automatic or scripted into a set of queries. Microsoft have provided some to get you started too based on their analysis and response teams.

4. Respond

Continuing the efficiency seen in previous steps, Sentinel allows you to orchestrate and automate responses to incidents. Allowing you to automatically handle repeat and/or known incidents.

So now that you know what it is, the next step is to put it in action and see if it can be of use to you and your client/business. Currently still in preview, Sentinel is free to use, which is always good and allows you to assess the service without any significant financial impact. Bear in mind, you will pay for the Log Analytics workspace which stores the data!

First, you’ll need to enable Sentinel and a workspace, this can be done via the portal and a walkthrough is here. Then, you need to connect some services to start streaming data to Sentinel. As you can see below, there are multiple options and you can choose which logs/data is sent to Sentinel too.

Once your data connector is active, you can make use of the built in dashboards to visualise it. Below is a subsection of the Azure AD sign-in log dashboard, which is available immediately via Sentinel. You can also create your own custom dashboards, there is a guide with samples here.

Now that is being collected and you have visuals, your next step is analysis. The first thing you will need to do is to create Detection Rules. These are essentially Log Analytics queries with alerting parameters wrapped around them. Microsoft offer sample queries on Github which are updated regularly. Alternatively, you can simply write your own to meet your needs.

The results of your Detection Rules are then fed into the Cases section of Sentinel. Here you can triage, investigate and remediate incidents. The cases are created dynamically from the parameters you set for Detection Rules such as severity and entity mapping. As such, be prepared to have to tweak those thresholds and alert patterns a bit. I have Sentinel running within several customer tenants, and am still not 100% happy with my detection rules yet. Always remember to update the status of your case too, in progress, resolved etc.

Finally, you should set up some Playbooks to respond to your alerts. A Playbook is simply a set of procedures that you can run from Azure Sentinel. They help automate and orchestrate your responses to alerts, and you can run them manually or ideally set them up to run automatically in response to certain alerts. They are based on Logic Apps, which means all of the same actions are available via Sentinel. One quick note, there is a charge for Logic Apps and therefore Playbooks, so ensure you understand your costs first.

When creating a Playbook, regardless of it is going to be run automatically by Sentinel or manually by you, you should first define your scenario. My preferred approach here is to come up with “If-This-Then-That” loops and apply them as needed. This is another section that will take some tweaking over time. In my experience, I only run Playbooks manually initially, then start to add automated triggering once I’m happy with the alert and response. Docs have a nice sample alert-response playbook with messaging and actions which is a great place to start.

Another function which I haven’t covered here is Hunting. I haven’t spent enough time with this feature yet to give a detailed opinion but you can read more on it over on Docs.

So, if you haven’t given Sentinel a try yet, I’d recommend you review the quickstarts and deploy in your tenant for one or two of the data sources like Azure AD. While it’s in Preview, it is a great chance to assess it relevant to your tenant and hopefully gain some greater insight and response capability too.

As always, if there any questions or if you have any problems with your Sentinel, get in touch!

AZ-500 Microsoft Azure Security Technologies – Study Guide

The latest Azure exam is now out of beta, AZ-500 Microsoft Azure Security Technologies. Passing this single exam will allow you to earn a Microsoft Certified: Azure Security Engineer Associate certification. I recently got the results for my exam which I sat in beta back in April and thankful to say I passed!

So, if you’re interested and wondering if you should take this exam? Here is what Microsoft have to say:

Candidates for this exam are Microsoft Azure security engineers who implement security controls, maintain the security posture, manages identity and access, and protects data, applications, and networks. Candidates identify and remediate vulnerabilities by using a variety of security tools, implements threat protection, and responds to security incident escalations. As a Microsoft Azure security engineer, candidates often serve as part of a larger team dedicated to cloud-based management and security and may also secure hybrid environments as part of an end-to-end infrastructure.

Candidates for this exam should have strong skills in scripting and automation, a deep understanding of networking, virtualization, and cloud N-tier architecture, and a strong familiarity with cloud capabilities, Microsoft Azure products and services, and other Microsoft products and services.

Below, I’ve put together a collection of links relevant to the sections highlighted as being part of the skills measured for this exam. As always, these are only guide links, sometimes you need to explore a topic much more deeply if you are not familiar with it.

If you spot something, or have a better link for a topic, get in touch! I will update this post as regularly as possible and always appreciate any feedback.

A good place to start is the Azure Security Documentation page. This site includes most of the key concepts and services covered in this exam, as well as several best practice approaches you should consider.

Manage Identity and Access

App registration

MFA

Groups

Users

Adconnect

CA

AADIP

PIM

Tenant

Implement Platform Protection

VNET

NSG & ASG

Firewall

Remote Accesss Management

Baseline Security

Resource Firewall

Endpoint Security VM

VM Security

Harden VM

Container Networks

Container Isolation & Security

AKS Security

Container Registry Security & Authentication

Container Instance Security

Resource Locks

Resource Group Security

Azure Policy

Custom RBAC

Manage Security Operations

Azure Monitor

Log Analytics

Diagnostic Logs

Vulnerability Scanning

Security Center Policies & JIT

Security Alerts

Secure Data and Applications

Data Security Policies

Data Infrastructure

Data at Rest

Application Delivery

Application Security

Key Vault

Azure – Protect My App

If you’ve taken a path to adopt public cloud and part of that adoption is a public facing application, you need to review how you are protecting it within Azure. When your application was on-premises, there was most likely only a single well managed solution to granting external access. In Azure, there are several various solutions available and each carries its own set of functionality and risk.

Rather than try define that entire list, let us look at how best to protect your application, regardless of how you have deployed it. With Azure, these are my three preferred options:

  1. Azure AD Application Proxy
  2. Azure Application Gateway
  3. 3rd Party Network Virtual Appliance

These arguably run from least to most secure. An important tip is to treat each application as unique, because it is. There is not a single best solution for all of your applications and as Azure is a shared model of security it is up to you to protect your data!

Awkward stuff out of the way, let’s look at Application Proxy, we’ve already had a post on setting this up here. The key point with this service is that you do not have your site exposed externally at a network level. Of course, the application itself will be and therefore possibly your server and data, but there is not an open endpoint accepting traffic.

Next is Application Gateway. This is actually a load-balancing solution but you can enable the Web Application Firewall tier easily. This provides protection of your applications from common exploits and vulnerabilities. However, this protection is based on rules from the OWASP core rule set and while it is configurable, this only means you can disable certain rules, not add custom ones. Application Gateway can seamlessly integrate into your environment whether you are running PaaS or IaaS solutions and is economical from a cost perspective. However, that point regarding customisation can often be the deciding factor in choosing our third option instead.

Finally, a 3rd party appliance. Azure offers solutions from the majority of the major providers in this space. Easily deployable from the Azure Marketplace within minutes. Integration options are good but require some work, (See post on routing here) and cost can be a factor to meet required availability levels. But if you need maximum protection and customisation, this is your best option.

Overall, I think there is definitely a solution in Azure that will meet your requirements. Take the time to understand your application, consult with your SMEs and you won’t go wrong!

 

 

First Impressions – Azure Firewall Preview

Recently Microsoft announced that a new Azure Firewall service was entering a managed public preview. Azure Firewall is a managed, network security service that protects your Azure Virtual Network resources. It is a fully stateful firewall as a service with built-in high availability and scalability.

firewall-overview.png

The services uses a static public IP meaning that your outbound traffic can be identified by third party services as/if required. Worth nothing, that only outbound rules are active within this preview. Inbound filtering will hopefully be available by GA.

The following capabilities are all available as part of the preview:

  • Stateful firewall as a Service
  • Built-in high availability with unrestricted cloud scalability
  • FQDN filtering
  • Network traffic filtering rules
  • Outbound SNAT support
  • Centrally create, enforce, and log application and network connectivity policies across Azure subscriptions and VNETs
  • Fully integrated with Azure Monitor for logging and analytics

As with all previews it should not be used for production environments, but for testing purposes this is how to register your tenant for deployment.

To enable the Azure Firewall public preview follow the guide here: Enabling the preview

Once enabled, follow this tutorial for a sample implementation: Deployment Tutorial

Now that you’re familiar with the deployment, you should apply to your specific test scenarios. Be wary of some operations that could be limited by applying a default route to your VM. There is an updated FAQ for the service here: Azure Firewall FAQ

Overall, this is a welcome addition to Azure networking. As the preview progresses and more service options are added, especially inbound options, I see this being as common as deploying an NSG in your environment. Combining it with peering and the right set of rule collections for your environment allows for an easily managed, scalable, and most importantly, secure environment within Azure with minimal cost and infrastructure footprint.

Securing Azure PaaS

When considering Azure as a platform, part of the conversation should revolve around transformation. That is, how do we transform our approach from what is viewed as traditional to something more modern. Often this could lead to redesigning how your application/service is deployed, but with some workflows, a simple change from IaaS to PaaS is viewed as a quick win.

This change isn’t suitable in all scenarios, but depending on your specific requirement it could allow for greater resiliency, a reduction in costs, and a simpler administration requirement. One service that is often considered is SQL. Azure has its own PaaS SQL offering which removes the need for you to manage the underlying infrastructure. That alone makes the transformation a worthy consideration.

However, what isn’t often immediately apparent to some administrators is that PaaS offerings are, by their nature, public facing. For Azure SQL to be as resilient as possible and scale responsively, it sits behind a public FQDN. Therefore, how this FQDN is secured must be taken into consideration as a priority to ensure your data is protected appropriately.

Thankfully, Azure SQL comes with a built in firewall service. Initially, all Transact-SQL access to your Azure SQL server is blocked by the firewall. To allow traffic, you must specify one or more server-level firewall rules that enable access. The firewall rules specify which IP address ranges from the Internet are allowed. There is also the ability to choose whether Azure applications can connect to your Azure SQL server.

The ability to grant access to just one of the databases within your Azure SQL server is also possible. You simply create a database-level rule for the required database. However, while this limits the traffic to specific IP ranges, the traffic still flows via the internet.

To communicate with Azure SQL privately, you will first need an Azure V-Net. Once in place, you must enable the service endpoint for Azure SQL, see here. This will allow communication directly between listed subnets within your v-net and Azure SQL via the Azure backbone. This traffic is more secure and possibly faster than via the internet.

Once your endpoint is enabled, you can then create a v-net firewall rule on Azure SQL for the subnet which had a service endpoint enabled. All endpoints within the subnet will have access to all databases. You can repeat these steps to add additional subnets. If adding your v-net replaces the previous IP rules, remember to remove them from your Azure SQL firewall rules.

Also worth noting is the option for “Allow all Azure Services”, the presumption here is that this somehow would only access from Azure Services within your subscription, but this is not the case. It means every single Azure service in all subscriptions, even mine! My recommendation is to avoid this whenever possible, however, there are some cases where this required and this access should be noted as a risk.

More on Azure SQL Firewall – https://docs.microsoft.com/en-us/azure/sql-database/sql-database-firewall-configure

More on Azure SQL with V-Nets – https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vnet-service-endpoint-rule-overview