[Security Solution] Rule filters: strict schema

[banderror]

Epic: #138606
Related to: #147441

Summary

Currently, query filters stored in rules of selected types are typed as an array of t.unknown values which allows a user to store anything in there via the API.

kibana/x-pack/plugins/security_solution/common/detection_engine/rule_schema/model/common_attributes/misc_attributes.ts

Lines 100 to 105 in 47ad5ed

	/**
	* TODO: Right now the filters is an "unknown", when it could more than likely
	* become the actual ESFilter as a type.
	*/
	export type RuleFilterArray = t.TypeOf<typeof RuleFilterArray>; // Filters are not easily type-able yet
	export const RuleFilterArray = t.array(t.unknown); // Filters are not easily type-able yet

For example, for the Custom Query rules, filters are defined here:

kibana/x-pack/plugins/security_solution/common/detection_engine/rule_schema/model/rule_schemas.ts

Line 303 in 47ad5ed

filters: RuleFilterArray,

kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_schema/model/rule_schemas.ts

Line 175 in 47ad5ed

filters: t.union([RuleFilterArray, t.undefined]),

If a user stores an invalid value instead of a valid instance of a filter model, it might break both the UI (e.g. rule Creation and Details pages) and the BE logic (rule executors).

Let's implement a strict io-ts schema for filters and validate them on-write.

To do

Let's do the following:

• Figure out what is the model of the filters we use. Find existing TypeScript types for it, find existing validation functions.
• Implement a strict io-ts schema for a filter and replace t.unknown with it in RuleFilterArray.
• Consider handling (potentially invalid) values already stored in filters. We could try to make sure whatever filters we return from the API are valid objects. Options could be: do an on-read validation or normalization, implement a rule migration,...

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)