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

  • Thread starter Thread starter Inwafula
  • Start date Start date
I

Inwafula

Overview

Copilot for Security is a generative-AI powered security solution that empowers security and IT professionals to respond to cyber threats, process signals, and assess risk exposure at the speed and scale of AI. As we build Copilot for Security, we are guided by four principles that shape the product’s vision: Intuitiveness, Customizability, Extensibility and adherence to Responsible AI principles. Plugins are a great example of how we bring the principles of customizability and extensibility alive within the product. In line with this, Copilot for Security allows customers to bring in signals from not just Microsoft solutions but also several third-party security solutions via plugins. Today, the platform supports three types of plugins: API, GPT and KQL-based plugins. KQL-based plugins can ingest insights into Copilot from three sources: Log Analytics workspaces-including data from custom tables, M365 Defender XDR and Azure Data Explorer (ADX) clusters.



Why use KQL plugins?

  • To tap into vast amounts of data already available in data stores across Log Analytics, Microsoft 365 Defender XDR and Azure Data explorer clusters.
  • To bring in highly customized insights into Copilot for Security. Kusto is a highly versatile query language that gives you tremendous flexibility to customize the signals to bring into Copilot for Security.
  • To accelerate value realization from your Copilot for Security investment by tapping into data and queries you already have in your environment coupled with the low skill barrier required to build the plugins.
  • To tap into data from third party solutions within tables such as CommonSecurityLog.
  • To leverage built-in “on behalf of” authentication and authorization capabilities that align to existing RBAC setting controlling access to the target data sources.

In this blog we shall focus on how you can use a KQL-based plugin to bring in insights from Microsoft Sentinel-enabled Log Analytics workspaces.



Use case summary

To showcase how one can leverage KQL-based plugins to tap into the vast amounts of security insights contained within Sentinel-enabled Log Analytics workspaces, we will build a query based on Microsoft Sentinel’s UEBA anomaly insights. Sentinel’s UEBA engine plays a unique and valuable role in sifting through large amount of raw data to build baselines of expected behavior within an Azure Tenant across historical time horizons. Based on these baselines, anomalies can then be detected and surfaced for eventual ingestion to supplement Copilot for Security workflows. As a result, the KQL queries that one needs to build based on the normalized insights generated by UEBA are typically far much simpler than would have been if one were to build anomaly detection queries on top of raw data targeting similar outcomes.



Connecting to a Log Analytics workspace

To connect to the Sentinel-enabled Log Analytics workspace, you will need to specify four required connection parameters within the YAML or JSON-based plugin manifest file i.e. Tenant ID, Log Analytics Workspace name, Azure Subscription ID and the name of the Resource group that hosts your Log Analytics workspace as captured in below image:



Figure 1: Required setup parameter details for Workspace settingsFigure 1: Required setup parameter details for Workspace settings



Once the workspace parameters are defined under in the settings section under the plugin Descriptor, they are now referenced in the SkillGroups section where the additional parameter of “Target” is also specified. Given that in this case we are targeting a Sentinel workspace then the target is specified as “Sentinel”. The elements within the curly brackets now make it possible for these inputs to be provided in the Copilot plugin setup UI as opposed to within the plugin manifest as was previously the case:



Fig. 2: Dialog box for entering workplace details in Copilot for Security plugin setup UIFig. 2: Dialog box for entering workplace details in Copilot for Security plugin setup UI



For KQL-based plugins user access is handled by Entra ID, and permissions will be scoped to match the existing access the user has in the Sentinel Log Analytics workspace the plugin is connecting to. In other words, authentication and authorization occur “on behalf of” the signed in user using the custom plugin.



Parameters can also be used to capture specific user input, making the plugin further customizable. In our example, we are using parameters to take in a time range and an investigation priority value from the end user.



Fig. 3: Parameters for workspace settingsFig. 3: Parameters for workspace settings



Sample use case: Detect unusual application and/or user activity within an Azure tenant

With the basics covered, let us now dive into a specific use case that will showcase how we can leverage the KQL plugin architecture to pull in synthesized insights into Copilot for Security, giving us insights about anomalous behavior detected around admin users and applications. To accomplish this use case, you will need to have the following pre-requisites in place:

  1. An active instance of Microsoft Sentinel with UEBA enabled.
  2. At least the following data sources ingesting into the UEBA engine: SigninLogs, Audit Logs, AzureActivity and ARM logs.

Here we are leveraging Sentinel UEBA’s built-in capability to build the expected baseline over time and large amounts of raw data and then make it possible to detect anomalies that are a deviation from that baseline. In this case-what has been established to be the norm for periods ranging between 10 and 180 days depending on the UEBA insight. The KQL query will then look back within a period that you specify and check for anomalies depending on the skill invoked. This plugin defines two skills: AnomalousAppActivity which surfaces app-related anomalies and AnomalousAdminActivity which surfaces admin user-related activity as detailed below:

AnomalousAppActivity. The first time a user used an app, an uncommonly used app, an app uncommonly used among user peers, an app that is observed in a tenant for the first time or an app that is uncommonly used in the tenant.



AnomalousAdminActivity

Activity 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, whether the account has been dormant, is a local admin or is a new account.



The full list of Sentinel UEBA enrichments that can be used in KQL queries are detailed in this document.



Skill description

Pay particular attention to the Description section as this need to be as unambiguous as possible to avoid skill collision (a situation whereby the Copilot planner selects the wrong skill because the description of one plugin is very similar to that of one or more active plugins).



Fig. 4: Skill description within the manifest fileFig. 4: Skill description within the manifest file



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

An additional capability available within KQL-based plugins is the ability to add additional skills by specifying an additional query that brings in a different but related set of insights, making plugin building more efficient. To do so one needs to add a new section below the first query but starting with the name of the new skill as shown below:



Fig. 5: Adding a second skill to the same plugin manifest fileFig. 5: Adding a second skill to the same plugin manifest file



Full plugin manifest

Note: The code below has reformatted for presentation within the blog. Copy pasting directly into a YAML editor may present formatting issue that will need to be addressed before you can upload the manifest into Copilot.





Code: 
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 the plugin

Upload the custom plugin manifest file by following the steps documented here:

Once configured, you can invoke the plugin via natural language or by calling the skills directly depending on how much control you want to have over the specificity of the prompt you provide to Copilot for Security. Note: The investigation priority for the AnomalousAppActivity skill has default priority of => 5.



Method 1: Sample natural language prompt

Fig 6: Sample output of natural language prompt against the AnomalousAdminUserActivity skillFig 6: Sample output of natural language prompt against the AnomalousAdminUserActivity skill

Fig. 7: Sample output of natural language prompt against the AnomalousAppActivity skillFig. 7: Sample output of natural language prompt against the AnomalousAppActivity skill



Method 2: Sample direct skill invocation prompt

Fig. 8: Example of direct skill invocationFig. 8: Example of direct skill invocation



Sample prompts

  1. show me which users performed an anomalous administrative activity for the first time over the past 14 days, include the investigation priority if 3 or higher. Include the blast radius
  2. show me applications exhibiting anomalous behavior over the last 14 days

Pro tips:

  • Use the project-away operator to eliminate columns that you feel you won’t need to be ingested into Copilot e.g. TenantID and SourceRecordID in the case of this use case.
  • Using Azure Monitor's ingestion time transformation capabilities is another strategy to achieve efficiency by minimizing real-time calculation of fields using operator such as extend or performing Regex operations at query time:
  • Ensure to use a code editor such as Visual Studio Code that can help you spot any formatting issues as YAML is sensitive to tabbing, indentation and hidden characters which would prevent the plugin successfully uploading into Copilot.
  • Use reasonable short lookback periods in the KQL query to narrow down your search and avoid returning too many records that could exceed the context window limits which would lead to an error.



Conclusion

KQL plugins present a relatively simple and scalable way to leverage the existing repositories of proven KQL queries within the Microsoft security ecosystem. These can then be used as a basis to bring AI enrichment onto security data already present within Sentinel-enabled Log Analytics workspaces while taking advantage of specialized capabilities such as UEBA for anomaly detection and other Sentinel related use cases. Give it a go give us your feedback so we can continuously improve the product for your benefit.



Additional resources


Continue reading...
 
Back
Top