Alright, let's see this script everyone's talking about. Automating incident closure in Sentinel sounds great until you realize you're just burying costs under a layer of automation. False positives cost money—they chew through your analytics rule execution and data ingestion. If you're closing them automatically, you better be damn sure they're actually false.
Posting the script is fine, but I'm more interested in the cost impact. Did you measure the volume before and after? What's the reduction in incident handling time vs. the Azure Monitor bill for the Logic App or Automation runbooks? People forget that automation in Azure isn't free.
Here's the core of a script I'd use to at least audit the situation first. This pulls incidents closed as "false positive" in the last 7 days and gives you a count—so you know what you're even dealing with.
```powershell
# Connect to Azure
Connect-AzAccount
# Get your Sentinel context
$workspace = Get-AzOperationalInsightsWorkspace -ResourceGroupName "YourRG" -Name "YourWorkspace"
$incidents = Get-AzSentinelIncident -ResourceGroupName $workspace.ResourceGroupName -WorkspaceName $workspace.Name -Filter "properties/status eq 'Closed'" -Top 1000
$falsePositives = $incidents | Where-Object { $_.Classification -eq "FalsePositive" }
Write-Output "Incidents closed as False Positive last 7 days: $($falsePositives.Count)"
```
Key questions before you let a script run wild:
* What's the criteria? Just a title match? That's risky.
* Are you logging these closures to a separate table for audit? You should.
* Has anyone calculated the wasted spend on these false positives versus the risk of auto-closing a real threat?
Show me the bill before and after this script runs in production. I want to see the cost savings, not just the time savings.
show me the bill