User Profile
AndrewBlumhardt
MicrosoftJoined 7 years ago
User Widgets
Recent Discussions
Re: Incident Missing Entities
I am not sure if these link helps. I recommend using Account with multiple indicators. You might also look at other template rules as an example. The template-based rules are really good at entity mapping, but it can be tricky for custom rules. You are identifying one or more column as an entity indicator. It can be hard to determine if the data in that column is properly formatted. It may be possible to revise the column in the detection KQL to improve entity mapping consistency. If mapping is failing, try running the query to see if the mapped indicator is missing or oddly formatted. https://learn.microsoft.com/en-us/azure/sentinel/map-data-fields-to-entities https://learn.microsoft.com/en-us/azure/sentinel/entities https://learn.microsoft.com/en-us/azure/sentinel/entities-reference1View0likes0CommentsRe: Microsoft Sentinel - Alert suppression
Consider that Sentinel analytic rules and XDR rules will eventually merge. Consider using allow indicators in XDR, especially where MDE is the source. I think you will find most of your alerts are origination from detection logic in other solutions like MDE, MDI, etc. These solutions often have unique entity and alert suppression options. MDI for example has an entity filter for each rule. For Sentinal native alerts, maybe a combination of watchlist and KQL filter. Revise the alert rule KQL with an allow list stored in a watchlist. That will make the list easier to manage and automate. I also recommend evaluating the noisy rules for validity. The first party tools like MDE, MDI, MDO, need very little add-on logic. I find that custom rules and many of the rules included with data connectors can introduce redundant, unnecessary, and noisy alerts when added to 1st party solutions. If the rules are noisy and hard to tune, check the source.52Views0likes0CommentsRe: IdentityInfo with analytics KQL query
The Sentinel rule settings override your query lookback (where TimeGenerated). It is not documented but I suspect that putting your SAM lookup table into a let table first will prevent the rule from overriding. So run your rule every 10 min if that is your preferred frequency with a reasonable lookback like 10-15 minutes. Create a lookup table first. let SamLookup = IdentityInfo | where TimeGenerated > ago(14d) | summarize arg_max(TimeGenerated, *) by SAMAccountName; Log_source | project-rename SAMAccountName=sourceProcessUsername | join SamLookup on SAMAccountName102Views1like4CommentsRe: IdentityInfo with analytics KQL query
Hard to help without more transparency on your query but I would set the rule to 14 days, run a 14 day lookback query on IdentityInfo using arg_max, put that into a let variable, then run a 10 min query on the target table, and join the results. You might also look at building this as an XDR rule. Worst case setup a logic app to setup a reference watchlist. IdentityInfo | summarize arg_max(TimeGenerated, *) by SAMAccountName162Views0likes7CommentsRe: Missing details in Azure Activity Logs – MICROSOFT.SECURITYINSIGHTS/ENTITIES/ACTION
I recommend using Microsoft Copilot or ChatGPT. Both can be very useful when researching obscure or legacy topics. I suspect these entries are because a Sentinel user interacted with an entity profile in some way. You might also try speaking with a listed user and trying to recreate the activity.70Views0likes1CommentRe: ARC Server disappear after less than 10 days
If these servers also have MDE the device log on the profile timeline is available for 180 days. You could look on the timeline to see if a local command is causing a disconnect. You could also check the Azure Activity log if you think someone else may be removing the objects.36Views1like0CommentsRe: Tips on how to process firewall URL/DNS alerts
You could consider just using these logs for investigations and reporting. MDE monitors network activity for each device and MDCA adds web application activity. Both have good out of the box alert rules. Your solution could be duplicate. Make sure your alert run can tie this back to device or user entities. This may require a more complex query with a join. If your Sentinel rules do not have entity mapping, XDR cannot perform proper correlation. I would revise this to be a daily summarization of key entity and URL. I would do something like summarize arg_max(TimeGenerated, *) by DeviceId, URL Then have a daily alert for the entity that has an event for each entity. This can be performed using event grouping. You issue is likely a combination of too frequent reporting and entity mapping.79Views0likes1CommentRe: Scheduled Analytics Rule not triggering...
The query is valid. I am not sure why you are having issues. I recommend revising your intent and target table. Verify that there are not templated rules that meet your needs that are included with these connectors. Your query would alert anytime someone assigned GA logs on. This could be very noisy and the security context is unclear. You might do better to monitor the AuditLog for PIM elevation and GA usage. It may even be better as a workbook to make GA usage easier to review.51Views0likes1CommentRe: Microsoft sentinel custom parsers
samikroy There is no cost for post-ingestion parsing and no change to the data. This is essentially a query or reusable function that displays the parsed data in a view. Transformation or pre-ingestion parsing can change the data This feature is in preview and pricing information has not been announced. Data collection transformations - Azure Monitor | Microsoft Learn1.6KViews0likes0CommentsRe: Microsoft Sentinel Potentially malicious events - Flagging as Safe/Informational?
Correct. The dashboard reflects a union of the supported tables where malicious IPs are noted. Such a filter would need to be applied on the dashboard. It is an interesting visualization but no controls or alerts are included.1.6KViews1like0CommentsRe: Microsoft Sentinel Potentially malicious events - Flagging as Safe/Informational?
Several tables are enriched in the background using Microsoft's threat intelligence. This feature is not well documented. Most notably the CommonSecurityLog table. The number of supported tables is frustratingly limited. There is no option to customize. You can drill down on the map to see the KQL. You could use this to create a custom map in a workbook and even custom alerts. From there you could add exclusions and additions.1.8KViews2likes2CommentsRe: Playbook (Logic App) - trigger - When Azure Sentinel incident creation rule was triggered
I haven't seen any specific training on Logic Apps for Sentinel. As you have seen, every connector/activity has its quirks. The Automation Rules are new and most of the GitHub examples are using the alerts trigger. Logic Apps are all about trial and error. Check out the run after feature if this is new...super cool. Run After: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-exception-handling#customize-run-after-behavior Logic Apps Learning Path: https://docs.microsoft.com/en-us/learn/paths/build-workflows-with-logic-apps/4.4KViews0likes4CommentsRe: Playbook (Logic App) - trigger - When Azure Sentinel incident creation rule was triggered
I would start by creating a logic app with just a Sentinel incident trigger. Save the app so it can be linked in Sentinel. In the Automation blade create an Automation rule. This will default to "Rule name contains all". Add a Playbook action calling your new logic app. There are some additional steps to grant Sentinel access to trigger logic apps. This adds the Sentinel Automation role to the resource group of your workspace. Look in settings for setup UI and instructions. Now your logic app will start being triggered by every new incident. Now you have a good mechanism to start adding activities and testing the logic app. Using "run trigger" doesn't work with triggers that require input. Beyond that I recommend importing some sample Logic Apps from the Sentinel repo for comparison. That initial trigger may not bring in all of the data you want/need. You can run secondary activities from the Sentinel connector. It is not uncommon to see a Sentinel trigger followed by a Sentinel activity; like Get an entity, or Get Incident. Sometimes those activities pull additional information or present it in a more useful way. There is also a Azure Monitor connector that can read data from the workspace directly.4.4KViews1like6CommentsRe: Playbook (Logic App) - trigger - When Azure Sentinel incident creation rule was triggered
SocInABox The Sentinel logic app triggers for incidents and alerts do not monitor Sentinel for new alerts (though that is understandable assumption). Rather those triggers configure the Logic App to be triggered or called by Sentinel. The logic app is waiting to be called. Alert-based triggers are linked to specific scheduled analytic rules and can be run manually from an incident (scroll to the far right on the alerts list inside an incident). This option is limited to alerts generated by the scheduled rule-type. Incident-based triggers are called by the new Automation rules. These can be setup to response to any rule-type (any specific rule or all rules). For a global trigger, create a logic app with an incident trigger and create an automation rule to call the Playbook for all rules.4.5KViews0likes8CommentsRe: Playbook (Logic App) - trigger - When Azure Sentinel incident creation rule was triggered
erlendoyen Private previews tend to move pretty fast with Sentinel. Worth the wait on the new activity. If you need something sooner you can schedule a query against the incidents table using the "Run query and list results" activity. https://azurecloudai.blog/2020/09/23/sentinel-email-notification-logic-app/11KViews0likes0CommentsRe: Table Data Retention
Your TI analytic rules ignore duplicate and expired entries. You could just add new indicators knowing the old will be groomed when expired and will not impact new entries. I would just add new. You could manually delete entries using the new Threat Intelligence view if you don't have a large number to remove. For larger tables there is a purge option: ttps://docs.microsoft.com/en-us/rest/api/loganalytics/workspacepurge/purge1.7KViews0likes0CommentsRe: Table Data Retention
ThreatIntelligenceIndicator is a special table. My understanding is that the time generated value is updated regularly to support the 14 day lookback limit on the analytic rules. You should be able to store values in this table up to the record expiration date. You can set table-level retention but it would not be necessary in this case. https://cloudadministrator.net/2019/10/16/set-per-table-retention-in-log-analytics-via-arm-template/1.8KViews0likes0Comments
Recent Blog Articles
No content to show