[ResponseOps] Some rules are getting skipped when performing bulkEnableRules and bulkDisableRules

[xcrzx]

Related to: #177634

Summary

When performing bulk enable or disable operations, some rules are getting skipped. For the bulk enable operation, it skips all rules that are already enabled, and for bulk disable, it skips those that are already disabled. This behavior creates several issues when using the rules client.

1. Inconsistent responses from RulesCLient

If you call rulesClient.bulkEnableRules({ ids: ['ruleId1', 'ruleId2'] }) with the same arguments but affected rules in different enabled/disabled states, you can get three different responses, making this call non-idempotent. Here are some examples:

Both rules initially disabled:

{ 
  "errors": [], 
  "rules": [{...}, {...}], // <- All rules are correctly returned
  "total": 2 // <- The total is correct
}

One rule disabled, one enabled:

{ 
  "errors": [], 
  "rules": [{...}], // <- Only one rule is returned
  "total": 2 // <- The total is correct
}

Both rules initially enabled:

{ 
  "errors": [], 
  "rules": [], // <- No rules
  "total": 2 // <- The total is correct
}

Expected responses

I expect the rules passed as params to end up either in the errors array or the rules array in the returned object regardless of their initial state.

2. Discrepancy between the rule state and task manager

When enabling rules, the Alerting framework skips rules if their saved object has alert.attributes.enabled: true. This behavior creates issues described here and in the attached SDH. There might be a situation where a rule is marked as enabled, but no corresponding task exists in the Task Manager. In the UI, these rules will appear enabled but will never run. Users expect that all rules affected by the bulk enable action will get a corresponding task created in the Task Manager and be scheduled for execution. Therefore, it would be best to also check if the rules to be enabled have tasks in the Task Manager, instead of relying solely on the rule's current enabled state.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[banderror]

@xcrzx Thanks a lot for opening this ticket! I would imagine that this bug affects our bulk actions endpoint through which detection rules are being enabled/disabled.

• Could you describe the impact here and what workaround we use, and where it is in the code?
• When someone fixes this bug, will they need to also update any code in security_solution?

[xcrzx]

• Could you describe the impact here and what workaround we use, and where it is in the code?
• When someone fixes this bug, will they need to also update any code in security_solution?

We have implemented a workaround in our code where we loop through the original rule array instead of relying on the response from RulesClient. Yes, it would be best to update this code as well when the issue is resolved.

kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_management/api/rules/bulk_actions/bulk_enable_disable_rules.ts

Lines 69 to 85 in acdeb8d

	// We need to go through the original rules array and update rules that were
	// not returned as failed from the bulkEnableRules. We cannot rely on the
	// results from the bulkEnableRules because the response is not consistent.
	// Some rules might be missing in the response if they were skipped by
	// Alerting Framework. See this issue for more details:
	// https://github.com/elastic/kibana/issues/181050
	updatedRules.push(
	...rules.flatMap((rule) => {
	if (failedRuleIds.includes(rule.id)) {
	return [];
	}
	return {
	...rule,
	enabled: operation === 'enable',
	};
	})
	);