Introducing Threat Intelligence Ingestion Rules
Microsoft Sentinel just rolled out a powerful new public preview feature: Ingestion Rules. This feature lets you fine-tune your threat intelligence (TI) feeds before they are ingested to Microsoft Sentinel. You can now set custom conditions and actions on Indicators of Compromise (IoCs), Threat Actors, Attack Patterns, Identities, and their Relationships. Use cases include: Filter Out False Positives: Suppress IoCs from feeds known to generate frequent false positives, ensuring only relevant intel reaches your analysts. Extending IoC validity periods for feeds that need longer lifespans. Tagging TI objects to match your organization's terminology and workflows Get Started Today with Ingestion Rules To create new “Ingestion rule”, navigate to “Intel Management” and Click on “Ingestion rules” With the new Ingestion rules feature, you have the power to modify or remove indicators even before they are integrated into Sentinel. These rules allow you to act on indicators currently in the ingestion pipeline. > Click on “Ingestion rules” Note: It can take up to 15 minutes for the rule to take effect Use Case #1: Delete IOC’s with less confidence score while ingesting When ingesting IOC's from TAXII/Upload API/File Upload, indicators are imported continuously. With pre-ingestion rules, you can filter out indicators that do not meet a certain confidence threshold. Specifically, you can set a rule to drop all indicators in the pipeline with a confidence score of 0, ensuring that only reliable data makes it through. Use Case #2: Extending IOC’s The following rule can be created to automatically extend the expiration date for all indicators in the pipeline where the confidence score is greater than 75. This ensures that these high-value indicators remain active and usable for a longer duration, enhancing the overall effectiveness of threat detection and response. Use Case #3: Bulk Tagging Bulk tagging is an efficient way to manage and categorize large volumes of indicators based on their confidence scores. With pre-ingestion rules, you can set up a rule to tag all indicators in the pipeline where the confidence score is greater than 75. This automated tagging process helps in organizing indicators, making it easier to search, filter, and analyze them based on their tags. It streamlines the workflow and improves the overall management of indicators within Sentinel. Managing Ingestion rules In addition to the specific use cases mentioned, managing ingestion rules gives you control over the entire ingestion process. 1. Reorder Rules You can reorder rules to prioritize certain actions over others, ensuring that the most critical rules are applied first. This flexibility allows for a tailored approach to data ingestion, optimizing the system's performance and accuracy. 2. Create From Creating new ingestion rules from existing ones can save you a significant amount of time and offer the flexibility to incorporate additional logic or remove unnecessary elements. Effectively duplicating these rules ensures you can quickly adapt to new requirements, streamline operations, and maintain a high level of efficiency in managing your data ingestion process. 3. Delete Ingestion Rules Over time, certain rules may become obsolete or redundant as your organizational needs and security strategies evolve. It's important to note that each workspace is limited to a maximum of 25 ingestion rules. Having a clean and relevant set of rules ensures that your data ingestion process remains streamlined and efficient, minimizing unnecessary processing and potential conflicts. Deleting outdated or unnecessary rules allows for a more focused approach to threat detection and response. It reduces clutter, which can significantly enhance the performance. By regularly reviewing and purging obsolete rules, you maintain a high level of operational efficiency and ensure that only the most critical and up-to-date rules are in place. Conclusion By leveraging these pre-ingestion rules effectively, you can enhance the quality and reliability of the IOC’s ingested into Sentinel, leading to more accurate threat detection and an improved security posture for your organization.Microsoft Sentinel Automation Tips & Tricks – Part 2: Playbooks
This blog is part of a multi-series Part 1: Automation rules Part 2: Playbooks – this blog Part 3: Send email notification options Part 4: Dynamic content and expressions – coming soon Playbooks A playbook is a collection of response and remediation actions and logic that can be run from Microsoft Sentinel as a routine. A playbook can help automate and orchestrate your threat response, integrate with other internal and external systems, and be set to run automatically in response to specific alerts or incidents triggered by an analytics rule or an automation rule. It can also be run on-demand manually from the incidents page in response to alerts. Here are some tips & tricks that can be helpful when creating playbooks: Run playbooks on incidents manually Running playbooks on incidents using automation rules provides a fantastic management point. But sometimes, we need to run a playbook with incident trigger manually. With a new API endpoint, that is possible, and now you can run playbooks on the incident from the incident overview page, and you can even mark favorite ones to be on the top of the list. More details about running playbooks on demand you can find on this blog: What's new: run playbooks on incidents on demand - Microsoft Tech Community Run playbooks from workbooks With the option to run playbooks with incident trigger on-demand using a new API endpoint, we also got the possibility to use ARM action in workbooks to run incident trigger playbooks from workbooks on-demand. To get details on how to use this functionality in workbooks, please check this blog: Run Microsoft Sentinel playbooks from workbooks on-demand - Microsoft Tech Community Nested playbooks - Run new playbooks as an action in the playbook Using the same API endpoint in running incident trigger playbooks from workbooks, we can run the playbook as an action in the existing playbook. To make it work, the first playbook must have the Logic App Contributor role assigned to the service principal or managed identity used to authorize HTTP action. HTTP Method: POST API path: https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/incidents/{incidentId}/runPlaybook?api-version=2019-01-01-preview Body: { "LogicAppsResourceId":"/subscriptions/{subscriptionId}/resourceGroups/{PlaybookResourceGroup}/providers/Microsoft.Logic/workflows/{PlaybookName}", "TenantId":"{TenantID}" } Create ARM template from the existing playbook Many organizations are using development instances of Microsoft Sentinel, where they test analytic rules, playbooks, etc., before deploying them into production instance. Creating playbook template manually can be time consuming job. That is why Sreedhar Ande had created ARM template generator, that is automating most of the things needed to create playbook template. The same tool can be used to create playbook to contribute to Microsoft Sentinel official GitHub repository. On this blog, you can find info how to deploy and used this tool: Export Microsoft Sentinel Playbooks or Azure Logic Apps with Ease - Microsoft Tech Community How to authorize Logic App connector and what identity to use Playbooks are using power of Logic App to automate SOC actions on incidents. Every Logic App action is using API in the background, which needs to be authorized. To authorize Logic App connector, it is possible to use 3 different identities: Managed Identity Service principal (Azure AD application registration) User identity In this blog you can find more details about each type of identity and when to use each: API connections and permissions for Microsoft Sentinel Playbooks In this article you can find more details about authenticating playbooks in Microsoft Sentinel: Authenticate playbooks to Microsoft Sentinel | Microsoft Docs Assign API permissions to managed identity using PowerShell System-assigned managed identity is the preferred method of authorizing Logic App connectors because organizations don’t need to manage keys, and only that Logic App can use permissions. No other Logic App can use it, as with service principal or user identity. Assigning Azure RBAC controls or Azure AD roles are straightforward and can be done quickly from the GUI, like with service principal or user identity. But sometimes, we need to assign specific API permissions to get the least privileged access. This can be done using Powershell. When we deploy the playbook, we need to ensure the system-assigned managed identity is enabled and copy the GUID of managed identity as we need it. We open PowerShell, and we need to run these commands: Set-ExecutionPolicy unrestricted Install-Module AzureAD Import-Module AzureAD After we are sure the Azure AD module is installed, we can connect to Azure AD. Connect-AzureAD And then, we run a PowerShell script that will assign specific API permissions. For example, we will use the playbook Block-AADUser. First, we need GUID from managed identity, application ID, and permissions. Managed Identity GUID you can find after deploying the playbook under “Identity”. Application ID can be found on the Azure AD admin portal under Enterprise applications. Under filter, choose All applications. We will search for the application regarding the API we are using: Microsoft Graph, Microsoft Defender for Endpoint, etc. The most common application IDs will be: Azure AD (Microsoft Graph) - 00000003-0000-0000-c000-000000000000 Microsoft Defender for Endpoint - fc780465-2017-40d4-a0c5-307022471b92 Microsoft 365 Defender - 8ee8fdad-f234-4243-8f3b-15c294843740 Permissions will depend on the action we need to perform, whether we need to get the user, update the user, get the machine, isolate the machine, etc. Depending on API documentation, you can find specific API permissions needed to be assigned to perform the action. In this specific playbook, we need to assign these API permissions: User.Read.All User.ReadWrite.All Directory.Read.All Directory.ReadWrite.All PowerShell code would look like this: PowerShell code would look like this: $MIGuid = "<Enter your managed identity guid here>" $MI = Get-AzureADServicePrincipal -ObjectId $MIGuid $GraphAppId = "00000003-0000-0000-c000-000000000000" $PermissionName1 = "User.Read.All" $PermissionName2 = "User.ReadWrite.All" $PermissionName3 = "Directory.Read.All" $PermissionName4 = "Directory.ReadWrite.All" $GraphServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$GraphAppId'" $AppRole1 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName1 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole1.Id $AppRole2 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName2 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole2.Id $AppRole3 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName3 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole3.Id $AppRole4 = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName4 -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MI.ObjectId -PrincipalId $MI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole4.Id We need to run it and have API permissions assigned to the managed identity! Continue with playbook when action fails Sometimes failure of an action in playbook is expected and we don’t want that whole playbook run fails as well. This is possible to configure in playbooks by configuring “run after” option. Use case would be using “Get a watchlist by alias” to check is watchlist available or not, before using action to create a new watchlist. Action is returning status code 200 and 400, depending on is watchlist available or not. By configuring condition action to be triggered even if “Get a watchlist by alias” fails, you are able to check status code and if it’s 400 (watchlist not available), continue creating new watchlist. < Part 1: Automation rules Part 3: Send email notification options >Using Microsoft Teams Adaptive Cards to enhance incident response in Microsoft Sentinel
With the Microsoft Teams Logic App connector, we can utilize Adaptive Cards to send notifications to Teams and/or ask for feedback to act on a Microsoft Sentinel incident. The example we will be using in this blog is to send Microsoft Teams Adaptive Card on incident creation, with the option to change the incident's severity and/or status.Revolutionize your SAP Security with Microsoft Sentinel's SOAR Capabilities
The purpose of this blog post is to demonstrate how the SOAR capabilities of Sentinel can be utilized in conjunction with SAP by leveraging Microsoft Sentinel Playbooks/Azure Logic Apps to automate remedial actions in SAP systems or SAP Business Technology Platform (BTP).What’s new: Monitor the health of your automation rules and playbooks
Now available: Monitor the execution of your automation rules and playbooks, visualize automation health data, audit who triggered playbooks on demand, correlate Azure Logic Apps and Microsoft Sentinel health logs and set up notifications of health events for relevant stakeholders, who can then take action.What’s new: Incident tasks
SOC analysts can follow checklists to handle the processes of incident triage, investigation, and response without worrying about missing a critical step; SOC managers and MSSPs can document, update, and align the standards of incident response across the analysts' teams and shifts.
