Forum Discussion

Asaad_Moosa's avatar
Asaad_Moosa
Copper Contributor
Jul 07, 2022

Reached the maximum limit of Analytics Rules of 512 in Sentinel

Hello all,

 

We have 539 toal analytics rules in Sentinel, 478 enabled rules and 61 disabled rules. 

Today, we noticed that we can't add new scheduled rules in the Analytics section of Sentinel. When we checked the Sentinel workspace's Activity logs, we saw this error message: "The maximum number of Scheduled analytics rules (512) has already been reached for workspace xxxxxx".

 

It looks that Microsoft Sentinel has indeed a Service Limit on the number of Analytics rules of 512 you can have in a workspace, as per this article Microsoft Sentinel service limits | Microsoft Docs

We need to add more rules to ensure that our Sentinel is benchmarked against Mitre Att&ck framework. 

 

According to Mitre, there are 191 techniques and 385 sub-techniques in the latest Att&ck framework – that’s a total of 576, how are we supposed to have have good analytics insights coverage with the limit of 512? That’s without even considering new ransomware rules, threat intel rules, and general zero-day rules e.g. Log4J etc.

 

We have a single workspace where all data connectors (from other Microsoft solutions, Defender products etc as well as other on-premise Syslog servers). If we consider splitting our rules between two or three workspaces to cover all the Mitre Att&ck techniques and sub-techniques (and other custom rules for our own environment), then we need to duplicate the data across those additional workspaces but we split the rules across multiple workspaces and work with incidents across all workspaces (per this article Work with Microsoft Sentinel incidents in many workspaces at once | Microsoft Docs) - but this means we have to pay for duplication of workspaces storage. This can't be a realistic solution that Microsoft expects us to do!

 

Has anyone faced this challenge and hit this maximum analytics rule limit of 512? Any advice how we might overcome it? Where do we go from here? I am surprised that this topics has not been discussed widely by companies who have mature SOCs based on Sentinel who have considered full benchmarking their Sentinel rules against Mitre Att&ck framework.

 

Any help will be highly appreciated and thanks in advance for any comments.

  • You can create a new workspace (without data) and use cross-workspace queries to hit the data in your main one. That way you can generate alerts in the other workspace to get around that limit.

    I'm surprised the 512 limitation isn't more prominently documented/mentioned, but I'd hazard that most orgs would struggle to come close to hitting that limit. Many don't have an analytics rule per-Mitre tactic/technique.
  • jderkowski's avatar
    jderkowski
    Copper Contributor

    I would love the opportunity to check out all of those rules! We have a little bit over half of those and personally, I think most of them create noise more than provided benefits. You could really help me out!

  • You can create a new workspace (without data) and use cross-workspace queries to hit the data in your main one. That way you can generate alerts in the other workspace to get around that limit.

    I'm surprised the 512 limitation isn't more prominently documented/mentioned, but I'd hazard that most orgs would struggle to come close to hitting that limit. Many don't have an analytics rule per-Mitre tactic/technique.
    • Asaad_Moosa's avatar
      Asaad_Moosa
      Copper Contributor

      ReganDangerCarey 

       

      Thanks ReganDangerCarey, we went ahead with creating a new workspace and enabled Sentinel on it, then we started creating new analytics rules but by using the "workspace" expression to execute the KQL queries on the first workspace.

      workspace("First_Workspace").TableName

      The second workspace is an empty workspace - meaning no data connectors are used since all rules queries will be executed on the first workspace where the logs data is collected centrally.

       

      One obvervation from using this approach, when writing the KQL in the second workspace, it doesn't activate the autocomplete of column names as you type it - which meant we have to switch back to the first workspace, complete the KQL query there (with the help of auto-complete column names) then save the final query as an analytic rule in the second workspace. 

       

      I think with time when more companies realise the importance of creating and developing more analytics rules (like our case to benchmark our SOC with Mitre Att&ck framework, or to catch any opportunistic zero-day IoCs as IT are busy rolling out a critical patch) and hit the max barrier of 512 limit in Sentinel, they will realise the pain of having to spin up a second and then third etc workspaces to evolve their Sentinel SOC maturity and make room for more analytics rules. But once it is set up, it works like a charm!

Resources