Skip to content
Notifications
Clear all

Check out what I made: A simple app to manage analytic rules via REST API

7 Posts
7 Users
0 Reactions
17 Views
(@infra_ops_learner)
Reputable Member
Joined: 6 months ago
Posts: 297
Topic starter   [#25847]

Hi everyone! I'm still learning about SIEM tools and trying out Sentinel in our test environment.

I wanted an easier way to toggle analytic rules on/off without always using the portal. So I made a small Python script that uses the Sentinel REST API to list rules and change their status. It's really basic but helped me understand how the API works.

Has anyone else built little tools like this? I'm curious if there are better ways to manage rules at scale, or if I should look into something like Terraform instead. The API docs were a bit overwhelming at first 😅

Learning the ropes.


CloudNewbie


   
Quote
(@ashp99)
Honorable Member
Joined: 3 months ago
Posts: 377
 

Nice! Starting with a simple script is exactly how I got comfortable with the Sentinel API too. For toggling a few rules, your approach is perfect.

If you're thinking about scale, Terraform is a solid move. It's great for managing rule definitions and state across environments, but it can feel heavy if you just need quick enable/disable. Maybe try both - keep your script for ad-hoc changes and use Terraform for version-controlled deployments.

The docs are a lot at first, huh? I found the MS Graph API sections easier to follow after playing with the Azure CLI for a bit.


data over opinions


   
ReplyQuote
(@grafana_knight_shift_2)
Honorable Member
Joined: 4 months ago
Posts: 472
 

Great way to get started. For toggling during investigations, that's the perfect use case. I'd add a small bit of error checking to your script, though - logging the rule name and ID before you flip its status can save you from accidentally disabling the wrong thing during a late-night session.

I've stuck with similar scripts for quick operational changes. Terraform is better for the source of truth, but it's too slow when you're on-call and need to quiet a noisy alert right now. Keep both in your toolkit.


Sleep is for the weak


   
ReplyQuote
(@cassie2)
Honorable Member
Joined: 2 months ago
Posts: 546
 

That's awesome you built that! Starting with a hands-on script is the best way to learn the API for sure, I did the same. The docs totally are overwhelming at first - I found starting with just the GET calls to list things helped me get my bearings before trying any PUT/POST actions.

Your point about scale is a good one. Terraform is amazing for managing the actual rule definitions as code. But for your specific use case - quickly toggling rules on and off - a lightweight script like yours is actually perfect. Maybe just add some simple logging so you have a trail of what you changed and when.

Have you thought about adding a simple UI with something like Streamlit? That was my next step and it made it super easy for my team to use.



   
ReplyQuote
(@cost_analyst_liam)
Honorable Member
Joined: 6 months ago
Posts: 515
 

The logging suggestion is critical for audit trails, but it also creates an operational cost. That log data needs to go somewhere, likely Azure Log Analytics, and that ingestion has a per-GB price. For a small script it's negligible, but if this scales to team use with verbose logging, you should set a retention policy and maybe sample logs to avoid turning a cost-control tool into a cost generator.

I agree a Streamlit UI is a logical next step for team usability. Just remember that hosting it, even in a small Container App or App Service instance, introduces a new monthly compute line item. It's often worth it for the productivity gain, but you should tag that resource clearly so you can attribute its cost back to this project during budget reviews.


Always check the data transfer costs.


   
ReplyQuote
(@brian)
Reputable Member
Joined: 3 months ago
Posts: 282
 

The portal is a terrible interface for this, so you're right to script it. But the real problem isn't just toggling state. It's that the rules themselves, their logic, live outside the API in ARM templates or Terraform. So now you'll have two places to manage them - your script for status and something else for definitions.

That's the lock-in they don't tell you about.


Trust but verify.


   
ReplyQuote
(@deborahw)
Reputable Member
Joined: 3 months ago
Posts: 358
 

Playing with the Azure CLI to make the Graph API docs less intimidating is a real pro tip, I'll give you that. But the suggestion to maintain both a script and Terraform feels like the start of a classic vendor complexity tax.

You're managing the same resource in two places, which doubles the chance for drift. Now you need a process to sync them, or accept that your script's state is ephemeral and your Terraform state is the truth, which makes the script feel like a hack you'll eventually have to apologize for.


—DW


   
ReplyQuote