Sharing my rule update experience on Elastic Security Serverless

Hello,

Just sharing my experience updating Elastic prebuilt Security rules after being away for about 1.5 months.

When I logged back in, I had roughly 1,200 rule updates waiting. That is fine in itself - I clicked Update all and expected the bulk update process to handle it.

However, 36 rules showed conflicts, even though I had never intentionally modified those rules.

For each of those 36 rules, I then had to individually:

  • Open and review the conflict

  • Click Save and accept

  • Click Update rule

  • Deal with the deprecated-rule popup and click Load rules

  • Wait several seconds for the update to complete

  • Repeat the entire process for the next rule

With roughly 10 seconds of clicking/navigation plus around 4 seconds of update time per rule, resolving 36 conflicts easily turns into 15-20 minutes of repetitive manual work.

There are really two issues here.

First, I would like to understand why prebuilt rules that I never modified are being reported as conflicting/modified in the first place. If there is some migration, versioning, or other internal change causing this, the UI should make that clear.

Second, even when conflicts are legitimate, the current workflow does not scale. Human review of a conflict can make sense, but forcing the administrator through the same multi-click update workflow 36 times does not.

It would be much better to have something like:

  • Review all conflicting rules in one workflow

  • Multi-select rules and accept the Elastic version in bulk

  • An "Accept upstream version for all" option where appropriate

  • Clear visibility into exactly what caused each conflict

  • Batch/background processing of accepted updates

  • Removal or consolidation of the deprecated-rule popup during this process

I fully understand that conflicting changes should not simply be overwritten without review. The problem is not the review itself - it is the amount of repetitive UI work required after that decision has been made.

For a product with hundreds or thousands of prebuilt detection rules, this workflow needs to scale better.

Willem

Oh, and during this process, my browser hanged multiple times...

And the Save and accept button also sometimes stays greyed out for a long time..

I have a similar experience, but we are basically postponing the update of Elastic rules as we use more our custom rules.

Do they have the Modified tag or they are just reporting a conflict that needs to be manually fixed?

Some pre-built rules may show an unresolved conflict because they are changing types, for example, from eql to esql.

This pop-up is pretty annoying, I can not understand why every single update asks for this, another issue that we have is that trying to update the rule from the rule page will not work, because for some reason this pop-up will not show up, you need to go to the dedicate rule updates page and update the rules from there.

Thanks for your feedback.
They are all unmodified...

Also I get this annoying popup too half of the time...

Yeah, for example the rule Process Discovery via Built-In Applications, in my cluster this rule is unmodified, but it has an Unresolved conflict tag because the type is changing from eql to new_terms.

I honestly have serious concerns about the way this is progressing.. Several promises were made over the past years to improve this process, but I dont feel like its going in a good direction. Did anyone at Elastic even try this process him/herself...? How this gets through QA I dont know..

It seems like the hanging rules are all those who have many "modifications", like this one:

This one took 14 seconds before the Save and accept button was no longer greyed out.... And 13 seconds the browser hanged after clicking Save and accept....

Hi @willemdh,

Thanks for you using Security Solution from Elastic :folded_hands:

I understand the difficulties you go through. And it's a really precious feedback. We'll definitely do our best to make prebuilt rules update UX smoother. And some of the things could be done faster while another could take much more time.

It indeed a time consuming process to update prebuilt rules and preserve customisations. Though as immediate help in case you want to update only to the prebuilt rule versions provided by Elastic I may suggest using internal API the UI sits on.

First fetch a list of prebuilt rules having updates

KBN=<Kibana base url>
AUTH="Authorization: ApiKey <base64-api-key>" # or use username/password auth

curl -sk "$KBN/internal/detection_engine/prebuilt_rules/upgrade/_review" 
  -X POST -H "$AUTH" 
  -H 'kbn-xsrf: true' 
  -H 'elastic-api-version: 1' 
  -H 'x-elastic-internal-origin: Kibana' 
  -H 'Content-Type: application/json' 
  -d '{"page":1,"per_page":100}' 
  | jq '[.rules[] | {rule_id, version: .target_rule.version, revision, name: .current_rule.name}]'

then dry run the update with rule_id, version and revision substituted

curl -sk "$KBN/internal/detection_engine/prebuilt_rules/upgrade/_perform" 
  -X POST -H "$AUTH" 
  -H 'kbn-xsrf: true' 
  -H 'elastic-api-version: 1' 
  -H 'x-elastic-internal-origin: Kibana' 
  -H 'Content-Type: application/json' 
  -d '{
  "mode": "SPECIFIC_RULES",
  "dry_run": true,
  "pick_version": "TARGET",
  "rules": [
      { "rule_id": "9a1a2dae-0b5f-4c3d-8305-a268d404c306", "version": 214, "revision": 0 },
      { "rule_id": "e26f042e-c590-4e82-8e05-41e81bd822ad", "version": 111, "revision": 3 }
    ]
  }'


and finally drop "dry_run": true and run real prebuilt rules update process.

I wouldn't recommend using it all the time. Only when you struggle with a lot of conflicts and want to update to the new Elastic shipped version.

Thanks for your suggestion to use the API, but this is for my personal home environment which has like 4 agents and a firewall. In an Enterprise env ofc we should use automation, but this should just work fluently ootb from the ui. And certainly in Serverless it should not hang and take me an hour to update 36 rules I didn't even modify.