OpenAI and Microsoft Sentinel Part 2: Explaining the Analysis Rules

Welcome back to our series about OpenAI and Microsoft Sentinel! Today we’ll explore another use case for OpenAI’s popular language models and take a look at the Sentinel REST API. If you don't have a Microsoft Sentinel instance yet, you can create one using a free Azure account and follow the Getting Started with Sentinel quickstart. You will also need a personal OpenAI account with an API key. get ready? let's start!

One of the tasks security practitioners face is how to quickly use analysis rules, queries, and definitions to understand what triggered an alert. For example, here is an example of a relatively short Microsoft Sentinel analysis rule written in Kusto Query Language (KQL):

Experienced KQL operators will have no difficulty Parse it out, but it still takes some time to mentally map out the keywords, log sources, actions, and event logic. People who have never used KQL may need more time to understand what this rule is designed to detect. Luckily, we have a friend who is really good at reading code and interpreting it in natural language – OpenAI’s GPT3!

GPT3 engines like DaVinci are very good at interpreting code in natural language and have extensive training in Microsoft Sentinel KQL syntax and usage. Even better, Sentinel has a built-in OpenAI connector that allows us to integrate GPT3 models into automated Sentinel playbooks! We can use this connector to add comments to Sentinel events that describe analysis rules. This will be a simple Logic App with a linear flow of operations:

# Let’s walk through Logic App, starting with triggers. We use a Microsoft Sentinel event trigger for this playbook so that we can use the Sentinel connector to extract all relevant analytics rule IDs from the event. We will use the Sentinel REST API to find the rule query text using the rule ID, which we can pass to the AI ​​model in the text completion prompt. Finally, we will add the output of the AI ​​model to the event as a comment.

Our first action is the "For each" logic block that acts on Sentinel's "Event-related analysis rule ID item":

Next , we need to use the Sentinel REST API to request the scheduled alert rule itself. This API endpoint is documented here: https://learn.microsoft.com/en-us/rest/api/securityinsights/stable/alert-rules/get ?tabs= HTTP . If you haven't used the Sentinel API before, you can click the green "Try It Out" button next to the code block to preview the actual request using your credentials. This is a great way to explore the API! In our case, the "Get - Alert Rules" request looks like this:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertRules/{ruleId}?api-version=2022-11-01

We can make this API call using the "HTTP" action in our logic app. Fortunately, the event-related analysis rule ID item we just added to the "For each" logic block comes with almost all of the parameters pre-populated. We just need to prepend the API domain with the version specification to the end - all parameters for subscriptionID, resourceGroupName, workspaceName and ruleId will come from our dynamic content object. The actual text of my URI block is as follows:

https://management.azure.com@{items('For_each_related_Analytics_Rule_ID')}?api-version=2022-11-01

We also need to configure authentication options for HTTP operations - I am using managed identity for my logic app. The completed action block looks like this:

Now that we have the alert rule, we just need to parse the rule text so that we can pass it to GPT3. Let's use the Parse JSON action, provide it with the body content from the HTTP step, and define the schema to match the expected output of this API call. The easiest way to generate the schema is to upload a sample payload, but we don't need to include all the properties we're not interested in. I have shortened the architecture to look like this:

{"type": "object","properties": {"id": {"type": "string"},"type": {"type": "string"},"kind": {"type": "string"},"properties": {"type": "object","properties": {"severity": {"type": "string"},"query": {"type": "string"},"tactics": {},"techniques": {},"displayName": {"type": "string"},"description": {"type": "string"},"lastModifiedUtc": {"type": "string"}}}}}

So far our logic blocks look like this:

Now it’s time to get the AI ​​involved Come in! Select "GPT3 Completes your prompt" from the OpenAI connector and write your prompt using the "query" dynamic content object from the previous Parse JSON step. We will use the latest Resolve engine and keep most of the default parameters. Our query did not show a significant difference between high and low temperature values, but we did want to increase the "max tokens" parameter to give the da Vinci model more room for long answers. The completed action should be like this:

The final step in our playbook is to add a comment to the event using the resulting text from GPT3. If you want to add an event task instead, just select the Sentinel action. Add an "Event ARM ID" dynamic content object and compose the comment message using the "Text (Completion Text)" output by the GPT3 action. The Logic App Designer automatically wraps your comment actions in a "For each" logic block. The finished comment action should look something like this:

Save your logic app and let’s try it out in an event! If all went well, our Logic App run history will show successful completion. If any problems arise, you can check the exact input and output details of each step - an invaluable troubleshooting tool! In our case it was always a green check mark:

Success! The playbook adds commentary to the event, saving our overworked security analysts a few minutes.

The above is the detailed content of OpenAI and Microsoft Sentinel Part 2: Explaining the Analysis Rules. For more information, please follow other related articles on the PHP Chinese website!