Harnessing the power of KQL Plugins for enhanced security insights with Copilot for Security

outline

Copilot for Security is a generative AI-based security solution that enables security and IT professionals to respond to cyber threats, process signals, and assess risk exposure at the speed and scale of AI. In building Copilot for Security, we are guided by four principles that shape our vision for the product. Adhering to intuitive, customizable, scalable, and responsible AI principles. Plugins are a great example of how we implement the principles of customization and extensibility within our products. Accordingly, Copilot for Security allows customers to bring in signals from multiple third-party security solutions, as well as Microsoft solutions, through plugins. Today, the platform supports three types of plugins: API, GPT, and KQL-based plugins. KQL-based plugins can gather insights into Copilot from three sources: Log Analytics workspaces with data from custom tables, M365 Defender XDR, and Azure Data Explorer (ADX) clusters.

Why should I use the KQL plugin?

• Leverage the vast amounts of data already available in your data stores in Log Analytics, Microsoft 365 Defender XDR, and Azure Data Explorer clusters.
• Provide highly customized insights to Copilot for Security. Kusto is a very versatile query language that provides tremendous flexibility in customizing the signals you bring into Copilot for Security.
• Accelerate time to value from your Copilot for Security investment by leveraging data and queries that already exist in your user environment, with a low technical barrier to entry for building plugins.
• Leverage data from third-party solutions within tables such as CommonSecurityLog.
• Leverage built-in “on behalf of” authentication and authorization capabilities to control access to target data sources in accordance with existing RBAC settings.

In this blog, we will focus on how to get insights from a Microsoft Sentinel-enabled Log Analytics workspace using a KQL-based plugin.

Use Case Summary

To demonstrate how to leverage the vast amount of security insights contained within a Sentinel-enabled Log Analytics workspace using a KQL-based plugin, we will build a query based on UEBA anomaly insights from Microsoft Sentinel. Sentinel’s UEBA engine is uniquely and invaluable in sifting through vast amounts of raw data to build a baseline of expected behavior within your Azure tenant over a historical time range. Based on this baseline, anomalies can be detected, surfaced, and ultimately ingested to complement the Copilot for Security workflow. As a result, the KQL queries that need to be built on top of the normalized insights generated from UEBA are typically much simpler than building anomaly detection queries on top of raw data that targets similar outcomes.

Connect to a Log Analytics workspace

To connect to a Sentinel-enabled Log Analytics workspace, you must specify four required connection parameters within the YAML or JSON-based plugin manifest file: Tenant ID, Log Analytics workspace name, Azure subscription ID, and the name of the resource group hosting the Log Analytics workspace as shown in the image below.

Figure 1: Details of required configuration parameters for setting up a workspace

When the workspace parameters are defined in the Settings section under the plugin, explainerNow referenced Skill Group The section also specifies additional parameters for the “target”. In this case, since we are targeting the Sentinel workspace, the target is specified as “Sentinel”. The elements in curly brackets allow us to now provide these inputs in the Copilot plugin settings UI, as opposed to previously providing them within the plugin manifest.

Figure 2: Dialog box for entering workplace details in the Copilot for Security plugin settings UI.

For KQL-based plugins, user access is handled by Entra ID and permissions are scoped to match the user’s existing access in the Sentinel Log Analytics workspace that the plugin connects to. In other words, authentication and authorization occur “on behalf of” the user who logged in using your custom plugin.

Parameters can also be used to capture specific user input, allowing you to further customize your plugin. In our example, we use parameters to get the time range and investigation priority values ​​from the end user.

Figure 3: Parameters for setting up the workspace

Sample use case: Detecting unusual application and/or user activity within your Azure tenant.

Now that we’ve covered the basics, let’s dive into a specific use case that demonstrates how to leverage the KQL plugin architecture to bring synthetic insights into Copilot for Security, providing insight into anomalous behavior detected around admin users and applications. To complete this use case, you’ll need the following prerequisites:

1. An active instance of Microsoft Sentinel with UEBA enabled.
2. At a minimum, the following data sources are collected by the UEBA engine: SigninLogs, Audit Logs, AzureActivity, and ARM logs.

Here we leverage the built-in capabilities of Sentinel UEBA to build a baseline over time and a large amount of raw data, and then detect outliers that deviate from that baseline. In this case, this is a standard established for a period of 10 to 180 days based on UEBA insights. The KQL query then looks back over the specified time period and identifies outliers based on the technique called. The plugin defines two techniques: Abnormal app activity App-related anomalies surface Abnormal administrator activity Administrator user related activities detailed below will surface.

Unusual app activity. If the user is new to the app, it is a rarely used app, a rarely used app among the user’s peers, the first app observed in the tenant, or a rarely used app in the tenant.

Abnormal administrator activity

Activity performed for the first time, activity that is unusual for the user, activity that is unusual among the user’s peers, activity that is unusual for the tenant, activity performed in an uncommon country or by a user connecting from a country that is unfamiliar to them, or activity accessing a resource that is unusual among users or peers accessing the resource for the first time. It doesn’t matter if the account is dormant, a local administrator, or a new account.

A full list of Sentinel UEBA enrichments available for use in KQL queries is detailed here. document.

Technical Description

Pay special attention to the following: explanation This section should be as unambiguous as possible to avoid technical conflicts.Situations where the Copilot planner selects the wrong technology because the description of a plugin is very similar to the description of one or more active plugins.).

Figure 4: Skill description in manifest file

Add a second skill/query to the same KQL-based plugin manifest

An additional feature available in KQL-based plugins is the ability to add additional techniques by specifying additional queries that retrieve a different but related set of insights, making plugin building more efficient. To do this, you need to add a new section starting with the name of the new technique under the first query, as shown below.

Figure 5: Adding a second skill to the same plugin manifest file

Full plugin manifest

memo: The code below has been reformatted for presentation within the blog. If you copy and paste directly into a YAML editor, you may encounter formatting issues that will need to be addressed before uploading the manifest to Copilot.

Descriptor:

  Name: AnomalousAppandAdminUserActivity

  DisplayName: Anomalous Application and Admin User Activity

  Description: Uses UEBA normalized Insights in Sentinel UEBA to identify Applications observed for the first time in the tenant over the last 30 days. It applies to profiled activities across ARM, Azure sign-in, and audit logs

  Settings:

    - Name: TenantId

      Required: true

    - Name: WorkspaceName

      Required: true

    - Name: SubscriptionId

      Required: true

    - Name: ResourceGroupName

      Required: true

  SupportedAuthTypes:

    - None

 

SkillGroups:

  - Format: KQL

    Skills:

      - Name: AnomalousAppActivity

        DisplayName: Anomalous activity detected around application

        Description: Uses Sentinel UEBA to identify unusual or anomalous actons such as first time application observed in tenant,  

        Inputs:

          - Name: fromDateTime

            Description: The start of the lookback window

            Required: true

          - Name: toDateTime

            Description: The end of the lookback window

            Required: true

        Settings:

          Target: Sentinel

          # The ID of the AAD Organization that the Sentinel workspace is in.

          TenantId: '{{TenantId}}'

          # The id of the Azure Subscription that the Sentinel workspace is in.

          SubscriptionId: '{{SubscriptionId}}'

          # The name of the Resource Group that the Sentinel workspace is in.

          ResourceGroupName: '{{ResourceGroupName}}'

          # The name of the Sentinel workspace.

          WorkspaceName: '{{WorkspaceName}}'

          Template: |-

            let fromDateTime=datetime('{{fromDateTime}}');

            let toDateTime=datetime('{{toDateTime}}');

            BehaviorAnalytics | where datetime_utc_to_local(TimeGenerated, "US/Eastern") between ( fromDateTime .. toDateTime )

            | project-away TenantId, Type, SourceRecordId, EventSource, TimeProcessed

            | where ActivityInsights.FirstTimeUserUsedApp == true or

            ActivityInsights.AppUncommonlyUsedByUser == true or

            ActivityInsights.AppUncommonlyUsedAmongPeers == true or

            ActivityInsights.FirstTimeAppObservedInTenant == true or

            ActivityInsights.AppUncommonlyUsedInTenant == true

      - Name: AnomalousAdminActions

        DisplayName: Anomalous administrative actions performed by user

        Description: Uses Sentinel UEBA to identify Users performing activities that are performed for the first time, uncommon by the user, uncommon among the user's peers, uncommon in the tenant, from an uncommon country or a user connecting from a country seen for the first time, or user accessing a resource for the first time or accessing a resource that is uncommon among their peers

        Inputs:

          - Name: fromDateTime

            Description: The start of the lookback window

            Required: true

          - Name: toDateTime

            Description: The end of the lookback window

            Required: true

          - Name: InvestiGationPriority

            Description: Calculated priority for investigation between 1 and 10

            Required: false

        Settings:

          Target: Sentinel

          # The ID of the AAD Organization that the Sentinel workspace is in.

          TenantId: '{{TenantId}}'

          # The id of the Azure Subscription that the Sentinel workspace is in.

          SubscriptionId: '{{SubscriptionId}}'

          # The name of the Resource Group that the Sentinel workspace is in.

          ResourceGroupName: '{{ResourceGroupName}}'

          # The name of the Sentinel workspace.

          WorkspaceName: '{{WorkspaceName}}'

          Template: |-

            let fromDateTime=datetime('{{fromDateTime}}');

            let toDateTime=datetime('{{toDateTime}}');

            BehaviorAnalytics

            | where datetime_utc_to_local(TimeGenerated, "US/Eastern") between ( fromDateTime .. toDateTime )

            | project-away TenantId, Type, SourceRecordId, EventSource, TimeProcessed

            | where ActivityType =~ "Administrative"

            | where isnotempty(UserName)

            | where ActivityInsights.FirstTimeUserPerformedAction == true or

            ActivityInsights.FirstTimeActionPerformedInTenant == true or

            ActivityInsights.ActionUncommonlyPerformedByUser == true or

            ActivityInsights.ActionUncommonlyPerformedAmongPeers == true or

            ActivityInsights.FirstTimeUserAccessedResource == true or

            ActivityInsights.CountryUncommonlyConnectedFromByUser == true

 

Using plugins

Upload your custom plugin manifest file following the documented steps. here:

Once configured, you can either invoke the plugin via natural language or invoke the skill directly, depending on how specific you want the prompts you provide to Copilot for Security. Note: The investigation priority for the AnomalousAppActivity skill is the default priority => 5.

Method 1: Sample natural language prompt

Figure 6: Sample output of a natural language prompt for the AnomalousAdminUserActivity technique.

Figure 7: Sample output of a natural language prompt for the AnomalousAppActivity technique.

Method 2: Sample Direct Tech Call Prompt

Figure 8: Example of a direct technical call

Sample prompt

1. Show me the first user who performed unusual admin activity in the last 14 days. If more than 3, include the investigation priority. Include the blast radius.
2. Show me applications that have exhibited unusual behavior over the last 14 days

Expert Tip:

• Since KQL queries must be executed in real time on the Sentinel side first, it is recommended to optimize the queries as much as possible to improve performance. To optimize query performance, follow the existing best practices published here.

• Use it Project-Away For this use case, we use operators to remove columns that we don’t think need to be collected in Copilot, such as TenantID and SourceRecordID.
• Using Azure Monitor’s ingestion time transformation feature is another strategy to achieve efficiency by minimizing real-time calculations of fields using operators. Extend Or perform regular expression operations at query time.

• YAML is sensitive to tabs, indentation, and hidden characters, so if you’re having trouble successfully uploading your plugin to Copilot, using a code editor like Visual Studio Code can help you spot formatting issues.
• Use a reasonably short review period in your KQL queries to narrow the scope of your search and avoid returning too many records, which could result in errors due to exceeding the context window limit.

conclusion

The KQL plugin provides a relatively simple and scalable way to leverage the existing repository of proven KQL queries within the Microsoft security ecosystem. You can then use it as a foundation to apply AI enhancements to security data already in your Sentinel-enabled Log Analytics workspace, while leveraging specialized capabilities such as UEBA for anomaly detection and other Sentinel-specific use cases. Give it a try and give us your feedback so we can continue to improve the product for your benefit.

Additional Materials