Sentinel's Built-in Consultant: An In-Depth Guide to SOC Optimization

Alright, class.
You've built your security operations center in Sentinel. The logs are flowing, the alerts are firing, and your team is bravely fighting the good fight against the daily onslaught of Dave's clicking on phishing links.
But a quiet, nagging voice starts whispering in the back of your head. Are we blind to something? Are we paying for a firehose of logs we don't even use? Could our coverage be better?
It’s the question that keeps every good security professional up at night. In the past, answering it required expensive consultants, endless spreadsheets, and a heroic amount of guesswork. Not anymore.
Microsoft has built a consultant directly into Sentinel. It's a powerful, and sometimes slightly confusing guide called SOC Optimization. Today, we're going to learn how to use it to level up your entire security posture.
What's the Point? Your SOC's Report Card
The SOC Optimization feature is, in simple terms, a continuous health check for your Sentinel deployment. It scans your environment every 24 hours and compares your current setup, your data connectors, and your active analytic rules against Microsoft's vast knowledge of threat actor techniques and best practices.
It then gives you a personalised, actionable "to-do" list, broken down into three main categories:
- Threat Coverage: "You're a bit weak against this type of ransomware. Here are the specific rules you should enable."
- Data Value: "You're paying to ingest 50GB of this log table every month, but you have zero rules using it. What's up with that?"
- Cost Optimization: "This table could be on a cheaper plan without losing security value. Click here to save money."
Let's dive into the main dashboard. You'll find it under Threat Management > SOC optimization.

The first thing you'll see is the Overview panel, which tracks your progress. You can mark recommendations as Active, In progress, Completed, or Dismissed. This is your team's shared quest log, so everyone knows who is working on what.
Below that is the real meat: the list of Threat Scenarios. This is where Microsoft gives you a coverage score (Low, Medium, High) against major threats like "Human-Operated Ransomware" or "Business Email Compromise."
The Coverage Quest: Slaying the AiTM Dragon
Let's tackle the most important type of recommendation first: improving your threat coverage.
In your list, you see an active recommendation: "Improve your coverage against AiTM (Adversary in the Middle) attacks from Medium to High." You click on it.

A pop-up appears, and it's a thing of beauty.

This is your skill tree. The graph shows you, tactic by tactic from the MITRE ATT&CK framework, where your current coverage is (the red bars) and where it could be if you enabled Microsoft's recommended rules (the blue bars). You can clearly see you're weak in Initial Access
.
You can click Go to Content Hub
there is a special filter applied, showing you only the specific solutions and analytic rules related to stopping AiTM attacks.
Here's Where You Need to Use Your Brain
Sentinel, in its infinite wisdom, has no idea you ripped out your Cisco gear two years ago or that you use Palo Alto, not Fortinet. The Content Hub will often recommend content for products you don't own. It's your job to be the smart human in the loop. You need to know your environment and ignore the irrelevant suggestions.

But buried in that list, you find a gem: a rule called "Risky user signin observed in non-Microsoft network device."

This sounds perfect. It correlates a risky sign-in from Entra ID with traffic seen on your third-party firewalls. Let's look at the logic:
SigninLogs
//Find risky Signin
| where RiskState == "atRisk" and ResultType == 0
| extend Signin_Time = TimeGenerated
| summarize
AppDisplayName=make_set(AppDisplayName),
ClientAppUsed=make_set(ClientAppUsed),
UserAgent=make_set(UserAgent),
CorrelationId=make_set(CorrelationId),
Signin_Time= min(Signin_Time),
RiskEventTypes=make_set(RiskEventTypes)
by
ConditionalAccessStatus,
IPAddress,
IsRisky,
ResourceDisplayName,
RiskDetail,
ResultType,
RiskLevelAggregated,
RiskLevelDuringSignIn,
RiskState,
UserPrincipalName=tostring(tolower(UserPrincipalName)),
SourceSystem
| join kind=inner (
CommonSecurityLog
| where DeviceVendor has_any ("Palo Alto Networks", "Fortinet", "Check Point", "Zscaler")
| where DeviceProduct startswith "FortiGate" or DeviceProduct startswith "PAN" or DeviceProduct startswith "VPN" or DeviceProduct startswith "FireWall" or DeviceProduct startswith "NSSWeblog" or DeviceProduct startswith "URL"
| where DeviceAction != "Block"
| where isnotempty(RequestURL)
| where isnotempty(SourceUserName)
| extend SourceUserName = tolower(SourceUserName)
| summarize
min(TimeGenerated),
max(TimeGenerated),
Activity=make_set(Activity)
by DestinationHostName, DestinationIP, RequestURL, SourceUserName=tostring(tolower(SourceUserName)),DeviceVendor,DeviceProduct
| extend 3p_observed_Time= min_TimeGenerated,Name = tostring(split(SourceUserName,"@")[0]),UPNSuffix =tostring(split(SourceUserName,"@")[1]))
on $left.IPAddress == $right.DestinationIP and $left.UserPrincipalName == $right.SourceUserName
| extend Timediff = datetime_diff('day', 3p_observed_Time, Signin_Time)
| where Timediff <= 1 and Timediff >= 0
This query is designed to answer a very specific and important question: "Has a user, who just had a successful but risky sign-in to our cloud services, also been seen accessing resources through our corporate firewall from that same suspicious IP, around the same time?"
Finding this specific pattern is a high-fidelity indicator of a potential adversary-in-the-middle (AiTM) attack or a compromised account being used to pivot from the cloud into your internal network.
This is why SOC Optimization is so powerful. You might never have thought to write a query this complex, but Sentinel is giving it to you on a silver platter. You click Install, and the rule is added to your Analytic rule templates. You can now go create an active rule from it, tuning it to your specific needs.
The Data Value Quest: Using the Loot You Already Have
The second type of recommendation is all about efficiency. You'll see one that says: "Low usage of UrlClickEvents table."

You click View details.

The pop-up tells you a simple, brutal truth: "We've observed you're ingesting data into this table, but you have zero analytic rules using it."
This is a classic SOC problem. You're paying for data you're not using for detections. Clicking Go to Content Hub will show you recommended rules that do use this table. This leaves you with a strategic choice:
- Activate the Rules: If the detections are valuable, turn them on and start getting value from the data you're already paying for.
- Stop Ingestion: If the table and its potential detections are useless to you, go to the data connector and stop sending the logs! You've just saved money.

dismiss
option comes in handy!The Cost Optimization Quest: Stop Overpaying for Storage
Finally, the recommendation that makes your CFO happy. You might see one for a table like AADServicePrincipalSignInLogs
that says the table plan could be optimized.

When you click Change plan, it takes you directly to the table configuration in your Log Analytics Workspace. It's suggesting you can change the plan from the expensive Analytics tier to the much cheaper Basics tier.

This is perfect for logs that you don't need for real-time alerting but still want available for investigations. By making this one change, you could drastically reduce the ingestion cost for that table. (Moving forward, this will be even more powerful with the Data Lake integration).
Final Thoughts
The SOC Optimization feature isn't a magic button that will run your SOC for you. It's a guide, a mentor, a nagging but brilliant consultant that's built right into your SIEM. It forces you to ask the hard questions: Is our coverage adequate? Are we using the data we pay for? Are we paying too much?
By regularly reviewing these "quests," you'll methodically close your security gaps, streamline your data ingestion, and build a smarter, more efficient, and more cost-effective security operation.
Class dismissed.
