- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
SMB and cyber
I've run my SMB IT consultancy since 1998, and boy has our industry changed a LOT since then. Most of my clients are either totally in the cloud or partially on their way there. IT security has slowly crept up the priority list, from somewhere near the bottom to very close to the top. As always, small businesses need enterprise-grade IT services and solutions but at SMB prices. In an ideal world, my clients could afford a complete managed detection and response (MDR) solution from a managed security service provider (MSSP) with a 24/7/365 security operations center (SOC), but they can't.
Given this challenge, I do what I can: make sure they have up-to-date malware on each endpoint, keep up with OS and application patching, use business class firewalls, simulate phishing campaigns, and deliver cybersecurity awareness training.
The lack of visibility is the scariest part. If an attack bypasses email hygiene filtering and the local AV solution, the likeliest way I'll find out is a phone call about "a strange message on our screens saying all our documents are encrypted and we need to pay to get them back."
As mentioned in our earlier look at Sentinel, there are some free data sources for Sentinel: Azure activity, Office 365 audit logs, and alerts from the Microsoft 365 Defender suite (max 90-day retention). Back then, Sentinel had fewer than 20 connectors for other data sources; today, that list is 116 and growing rapidly.
So I thought maybe I could build an SMB SIEM on a shoestring budget, which would provide the visibility we were lacking.
The first client is a small school with about 90 students (years 1–12) and 20 staff, all using Microsoft 365 A3, which is like E3 in the commercial world. We have two Windows Server 2019 Dell Hyper-V hosts with seven VMs, all running on the newer server, with the older server as a Hyper-V replica target in a separate building.
The VMs (Windows Server 2016/2019) are two DCs, a file and print server, Windows Server Update Services (WSUS), a school management application, Microsoft's Advanced Threat Analytics (ATA), and a Linux syslog server.
Data sources
Since they had Microsoft 365 but no Azure subscriptions, I created one for them through CSP (Microsoft's partner program). I made sure to base it on the same Azure Active Directory as in their M365 tenant, as this is important for the AAD data to flow into Sentinel properly.
I deployed a Log Analytics workspace and then enabled Azure Sentinel for the workspace in the Australia East region (use https://www.azurespeed.com/ whenever possible to ensure the lowest latency to the client). The retention period for the workspace was 90 days, which was a calculated risk. It definitely restricted our ability to investigate breaches going back into the past, but that's the free retention period and budget was king in this project.
The cloud-based data connectors were the easiest to connect; it's a couple of clicks for each. For this client, I used Azure AD (sign-in logs for users, interactive, non-interactive, and service principals, plus audit logs), DNS, Office 365 (SharePoint, Exchange, and Teams activity), Windows Security Events, Threat intelligence—TAXII, and Windows Firewall.
Office 365 Connector
Nearly all connectors come with workbooks to visualize the data, which you can then customize to suit your needs. Again, it's as simple as importing them into your Sentinel workspace and configuring what data you want to see.
Azure AD Sign in Logs workbook
The non-cloud data source connectors (security events, Windows Firewall, and DNS) are based on data from the on-premises VMs and hosts. On each physical server and VM, I deployed the Microsoft Monitoring Agent (MMA), a simple MSI installer that you run, supplying the workspace ID and primary key from the Log Analytics workspace in Azure. There's now a newer option, the Azure Monitoring Agent (AMA) which spans both Windows and Linux hosts. It's in public preview at the time of writing, which I would have used had it been available back when I deployed the agents. The main benefit for Sentinel in AMA is data collection rules that let you fine-tune exactly which events from the Windows Security Event log are collected. MMA simply has three options: Minimal, Common, or All—I picked Common. It would have been nice to be able to collect security events not only from servers but also from Windows 10 clients, but I needed to watch the ingestion cost carefully before expanding the agent deployment.
Finally, I configured the Threat Intelligence—TAXII connector, which is one of two ways to ingest TI information into Sentinel. Following this blog post, I set up Anomali’s free intel feeds so domains/IPs, malware domains, TOR nodes, C2 servers, and compromised host matches in our logs would be flagged.
Threat intelligence data in Sentinel
Next step
Getting the log data into Sentinel is the first step. Next, you use analytics rules to run queries over the data to alert you to suspicious activity. There are hundreds of built-in rule templates. I started by filtering the view on severity (high and medium), plus the data sources we have, and enabled all matching built-in rules.
When you configure a rule, you have to decide how often the rule will run. The shortest time is every five minutes, but you can set it to hours or days. Sentinel doesn't charge you for running rules, so setting them fairly frequently helps to let you know about suspicious activity quickly. Another setting is the look-back time—how far back in the log the rule is going to look. Keep these two values fairly close. I had configured a rule for detecting rare RDP connections to run every hour but look back for 24 hours; this means I was getting the same alert every hour for 24 hours, which is not very useful 😊.
Here, you can see a rule for distributed password cracking attempts against Azure AD, its description, and the Kusto Query Language (KQL; see below) query that runs every time the rule runs.
Analytics rule—distributed password cracking attempts
I had initially set up most rules to run once a day, but I've since shortened the time to run hourly; I'm now looking to shorten the time even further.
I mentioned KQL, which is used in Azure Log Analytics, Azure Data Explorer, and all other Microsoft security solutions to analyze data. It borrows from SQL and PowerShell, but is optimized for digging through large amounts of log data. If you're interested, there are some frees (no subscription required) courses on Pluralsight here. Microsoft also provides a free "playground" Log Analytics workspace with security log data to practice your KQL-fu here, and an introduction to KQL here.
Here, I'm using an ad hoc KQL query to look at DNS event log data.
KQL query against DNS event log data
As mentioned, you can also use workbooks to visualize aggregated data to understand what's "normal" in your environment. Here you can see a month's worth of identity activity across different interesting sign-in event IDs.
Workbook for sign in event log IDs
Bringing it all together
Sentinel is based on the idea that if you get too many alerts, you'll start ignoring them or not investigating them deeply, so avoiding alert fatigue is critical. One way it does this is to use AI through a feature called Fusion to automatically correlate different alerts into incidents so that when you start investigating different but related suspicious events, they are all presented together.
Another way you can manage this is through automation, as there's just me in the SOC. I needed a way for Sentinel to let me know when suspicious activities happened. The Analytics rules can have an email (or any other action in a Logic App), but I didn't want to go through each rule to add the automation. I found an alternative that would send me an email every time any of the alert rules were triggered here. Automation in Sentinel takes the form of playbooks or newer automation rules, but a playbook is really just an Azure Logic App where you add actions and connect them graphically, optionally with branching logic. The sky's the limit here, but you can certainly have playbooks that run automatically for certain incidents. For instance, if you have an impossible travel alert, email the user's manager to double-check whether that user really is traveling to country X. If the answer is yes, close the alert automatically; if it is no, raise the severity of the incident.
Here's an example email alert:
Email alert from Sentinel
Clicking the link in the email takes me directly to the incident with more information about the entities (user accounts, devices, IP addresses, etc.) involved, with the option to investigate further, using a graph that links each item, provides a timeline of activities, etc.
Investigating an incident in Sentinel
Does it work?
This client has now had Sentinel in production for over four months. We've had 373 reported incidents, mostly false positives and expected alerts (some rule tuning required), with some serious brute force password attacks (none succeeded). The monthly cost is under $70.
The next step is to connect a few more data sources. Their firewall is a Check Point Quantum Spark 1550 that sends its logs to a syslog server (the Linux VM mentioned above). They're also using ESET on each device for antimalware. Its central server is called "Protect," and, again, it can upload its data via a syslog server. The third data source is Microsoft's ATA, the on-premises version of Microsoft Defender for Identity, which monitors Active Directory for suspicious activity. It can also emit its logs via syslog.
I've deployed an Ubuntu 18.04 server, but the logs aren't synchronizing to Sentinel—troubleshooting to follow. Once these data sources show up in Sentinel, I feel confident that we'll have good visibility if (when) an intrusion does occur.
Subscribe to 4sysops newsletter!
I'm sure security architect readers can identify plenty of areas for improvement in this solution, but it works for the client, doesn't cost them a fortune, and they're definitely more secure than they were before. If you're interested in Azure Sentinel, there's an excellent free collection of training videos and material here.
