[Security Solution] Discuss rule fields in the context of the prebuilt rule upgrade workflow #147239

banderror · 2022-12-08T11:44:17Z

Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168
Forked from: #144060

Summary

We need to figure out what rule fields we’re going to show in the rule upgrade flyout.

Which fields will be "customizable" (the user will be able to see a diff and resolve conflicts in the flyout)?
Which fields will be "technical" (we will handle their update under the hood)?

You can see a detailed breakdown of all the existing rule fields below. They are categorized by multiple dimensions which will hopefully help us with reasoning about each field and making decisions.

Please scroll down to find fields to pay attention to and discuss.

Rule fields

Kind:

Technical: is needed for the app to work
Domain: is needed for the users' use cases and/or detection rule business logic to work

Change:

Static: changes at least once (e.g. on rule creation) or at most every time a user updates this field in a rule
Dynamic: may change often and/or in the background without any user actions

Level:

Framework: defined at the Alerting Framework level, is known to the Framework, is common to many rule types including Observability and Stack rules
Solution: defined on the Security Solution side, in most cases stored in the rule params object
Both: defined at both levels simultaneously (sometimes it's one part at the Framework and another one at the Solution level)

Prebuilt?

✅: supported by the prebuilt rule schema and can be specified in https://github.com/elastic/detection-rules
✅ (unused): supported by the schema but is not used in https://github.com/elastic/detection-rules
✅⁉️: supported by the schema but probably shouldn't be
✅⁉️ (unused): supported by the schema but probably shouldn't be + not used in https://github.com/elastic/detection-rules
❌: is specific to the app and not supported by the prebuilt rule schema

User editable?

Editable: currently, users can create and update the field via the UI or the API
Editable (1): currently, users can specify this field only once during rule creation, they cannot update it after a rule is created
Editable (no UI): currently, users can create and update the field only via the API
Readonly: currently, users can only read the field

Customizable?

✅: users will be able to edit this field in prebuilt rules and then be able to resolve potential conflicts during the rule upgrade process (the field will be visible in the rule upgrade UI)
⚙️ (auto): users will be able to edit this field in prebuilt rules, but conflicts during the rule upgrade process will be resolved automatically under the hood (the field won't be visible in the rule upgrade UI)
❌: users won't be able to edit this field in prebuilt rules (the field won't be visible in the rule upgrade UI)

Fields common to all rule types

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
Main technical fields
`id`	Technical	Static	Framework	❌	Readonly	❌
`rule_id`	Technical	Static	Solution	✅	Readonly	❌
`created_at`	Technical	Static	Framework	❌	Readonly	❌
`created_by`	Technical	Static	Framework	❌	Readonly	❌
`updated_at`	Technical	Static	Framework	❌	Readonly	❌
`updated_by`	Technical	Static	Framework	❌	Readonly	❌
`immutable`	Technical	Static	Solution	❌	Readonly	❌
`version`	Technical	Static	Solution	✅	Readonly	❌
`revision`	Technical	Static	Framework	✅	Readonly	❌
`enabled`	Technical	Static	Framework	✅	Editable	⚙️ (auto)
`execution_summary`	Technical	Dynamic	Both	❌	Readonly	❌
`meta`	Technical	Static	Solution	✅⁉️(unused)	Editable (no UI)	⚙️ (auto)
Attributes related to SavedObjectsClient.resolve API
`outcome`	Technical	Dynamic	Framework	✅⁉️(unused)	Readonly	❌
`alias_target_id`	Technical	Dynamic	Framework	✅⁉️(unused)	Readonly	❌
`alias_purpose`	Technical	Dynamic	Framework	✅⁉️(unused)	Readonly	❌
Main domain fields
`type`	Domain	Static	Both	✅	Editable (1)	❌
`name`	Domain	Static	Framework	✅	Editable	✅
`tags`	Domain	Static	Framework	✅	Editable	✅
`description`	Domain	Static	Solution	✅	Editable	✅
`severity`	Domain	Static	Solution	✅	Editable	✅
`severity_mapping`	Domain	Static	Solution	✅	Editable	✅
`risk_score`	Domain	Static	Solution	✅	Editable	✅
`risk_score_mapping`	Domain	Static	Solution	✅	Editable	✅
About -> Advanced settings
`references` - reference URLs	Domain	Static	Solution	✅	Editable	✅
`false_positives` - false positive examples	Domain	Static	Solution	✅	Editable	✅
`threat` - MITRE ATT&CK classification	Domain	Static	Solution	✅	Editable	✅
`note` - investigation guide	Domain	Static	Solution	✅	Editable	✅
`setup` - setup guide	Domain	Static	Solution	✅	Readonly	❌ ?
`related_integrations`	Domain	Static	Solution	✅	Readonly	❌ ?
`required_fields`	Domain	Static	Solution	✅	Readonly	❌ ?
`author`	Domain	Static	Solution	✅	Editable	❌
`license`	Domain	Static	Solution	✅	Editable	❌
`building_block_type`	Domain	Static	Solution	✅	Editable	✅
`rule_name_override`	Domain	Static	Solution	✅	Editable	✅
`timestamp_override`	Domain	Static	Solution	✅	Editable	✅
`timestamp_override_fallback_disabled`	Domain	Static	Solution	✅ (unused)	Editable	✅
Timeline template
`timeline_id`	Domain	Static	Solution	✅	Editable	✅
`timeline_title`	Domain	Static	Solution	✅	Editable	✅
Rule schedule
`interval`	Domain	Static	Framework	✅	Editable	✅
`from`	Domain	Static	Solution	✅	Editable	✅
`to`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
Rule actions
`actions`	Domain	Static	Framework	✅⁉️ (unused)	Editable	⚙️ (auto) ?
`throttle`	Domain	Static	Framework	✅⁉️ (unused)	Editable	⚙️ (auto) ?
Rule exceptions
`exceptions_list`	Domain	Static	Solution	✅	Editable (extra UI)	⚙️ (auto) ?
Alerts indexing
`max_signals` - cirquit breaker	Domain	Static	Solution	✅	Editable (no UI)	?
`output_index` - deprecated and unused?	Domain	Static	Solution	✅⁉️ (unused)	Editable (no UI)	?
`namespace` - unused?	Domain	Static	Solution	✅⁉️ (unused)	Editable (no UI)	?

Fields specific to Custom Query and Saved Query rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`index`	Domain	Static	Solution	✅	Editable	✅
`data_view_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`query`	Domain	Static	Solution	✅	Editable	✅
`language`	Domain	Static	Solution	✅	Editable	✅
`filters`	Domain	Static	Solution	✅	Editable	✅
`saved_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`response_actions`	Domain	Static	Solution	✅⁉️ (unused)	Editable	⚙️ (auto) ?
`alert_suppression`	Domain	Static	Solution	✅ (unused)	Editable	✅

Fields specific to EQL rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`index`	Domain	Static	Solution	✅	Editable	✅
`data_view_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`query`	Domain	Static	Solution	✅	Editable	✅
`language`	Domain	Static	Solution	✅	❌	❌
`filters`	Domain	Static	Solution	✅	Editable	✅
`event_category_override`	Domain	Static	Solution	✅ (unused)	Editable	✅
`timestamp_field`	Domain	Static	Solution	✅ (unused)	Editable	✅
`tiebreaker_field`	Domain	Static	Solution	✅ (unused)	Editable	✅

Fields specific to Indicator Match rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`index`	Domain	Static	Solution	✅	Editable	✅
`data_view_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`query`	Domain	Static	Solution	✅	Editable	✅
`language`	Domain	Static	Solution	✅	Editable	✅
`filters`	Domain	Static	Solution	✅	Editable	✅
`saved_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`threat_query`	Domain	Static	Solution	✅	Editable	✅
`threat_mapping`	Domain	Static	Solution	✅	Editable	✅
`threat_index`	Domain	Static	Solution	✅	Editable	✅
`threat_filters`	Domain	Static	Solution	✅	Editable	✅
`threat_indicator_path`	Domain	Static	Solution	✅	Editable	✅
`threat_language`	Domain	Static	Solution	✅	Editable	✅
`concurrent_searches`	Domain	Static	Solution	✅ (unused)	Editable (no UI)	?
`items_per_search`	Domain	Static	Solution	✅ (unused)	Editable (no UI)	?
`alert_suppression`	Domain	Static	Solution	✅ (unused)	Editable	✅

Fields specific to Threshold rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`index`	Domain	Static	Solution	✅	Editable	✅
`data_view_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`query`	Domain	Static	Solution	✅	Editable	✅
`language`	Domain	Static	Solution	✅	Editable	✅
`filters`	Domain	Static	Solution	✅	Editable	✅
`saved_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`threshold`	Domain	Static	Solution	✅	Editable	✅

Fields specific to Machine Learning rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`machine_learning_job_id`	Domain	Static	Solution	✅	Editable	✅
`anomaly_threshold`	Domain	Static	Solution	✅	Editable	✅

Fields specific to New Terms rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`index`	Domain	Static	Solution	✅	Editable	✅
`data_view_id`	Domain	Static	Solution	✅⁉️ (unused)	Editable	✅
`query`	Domain	Static	Solution	✅	Editable	✅
`language`	Domain	Static	Solution	✅	Editable	✅
`filters`	Domain	Static	Solution	✅	Editable	✅
`new_terms_fields`	Domain	Static	Solution	✅	Editable	✅
`history_window_start`	Domain	Static	Solution	✅	Editable	✅

Fields specific to ES|QL Rules

Field name	Kind	Change	Level	Prebuilt?	User editable?	Customizable?
`query`	Domain	Static	Solution	✅	Editable	✅
`language`	Domain	Static	Solution	✅	❌	❌

Rule fields to discuss

Fields common to all rule types:

type ― Confirm that we're not going to support changing the rule type on upgrade.
related_integrations, required_fields, setup ― These can be specified in https://github.com/elastic/detection-rules but we don't support editing them in the app. Since we don't have UI for editing them, I'm wondering if it's time to finally build it. When we build the UI we will be able to support these fields in the rule upgrade flyout.
author, license ― Are we going to allow the user to customize these? Could there be any legal restrictions on that?
actions, throttle ― We allow the user to specify actions for installed prebuilt rules, but no prebuilt rules actually have actions in https://github.com/elastic/detection-rules. Can we remove support for actions from the prebuilt rule schema and handle the upgrade for these 2 fields under the hood (always take the current user's version)?
exceptions_list ― We allow the user to specify exceptions for installed prebuilt rules, but only one prebuilt rule actually have exceptions in https://github.com/elastic/detection-rules. It's the "Endpoint Security" rule. How should we handle potential conflicts between Elastic's and user's versions of this field? Can we use some simple heuristic and handle this under the hood instead of building some kind of UI?
max_signals ― This is a circuit breaker value. A few prebuilt rules have it in https://github.com/elastic/detection-rules. Users can modify it via the API. We don't have a UI for it. How do we resolve conflicts in this field?
output_index ― This is a name of a concrete target index where the rule is supposed to write alerts. I believe this field is deprecated and unused in the app. No prebuilt rules have it in https://github.com/elastic/detection-rules. Users can still modify it via the API because it's in the schema. I don't think we have a UI for it. What should we do with this field?
namespace ― This is a namespace (a suffix) of the alerts-as-data index where the rule is supposed to write alerts. AFAIR this is a replacement for output_index but it looks to be unused in the app. No prebuilt rules have it in https://github.com/elastic/detection-rules. Users can still modify it via the API because it's in the schema. I don't think we have a UI for it. What should we do with this field?

Fields specific to Custom Query and Saved Query rules:

response_actions ― This is fully user-editable and supported by the prebuilt rule schema, but no prebuilt rules have it in https://github.com/elastic/detection-rules. Our suggestion would be to remove it from the schema and handle it under the hood of the upgrade workflow.

Fields specific to EQL rules:

language ― Specifically for EQL rules, do we allow the user to change this? From the rule schema, it looks like this can accept only one value: "eql".
- EDIT: No, we don't want users to be able to change language for EQL (and neither for ES|QL) rules. Language should be eql and esql respectively. The field might change if a rule changes its type from an upstream update, but a user should not be able to manually force this.

Fields specific to Indicator Match rules:

threat_indicator_path ― What is this field used for? Do we have a UI for it? A few prebuilt rules have it in https://github.com/elastic/detection-rules.
- EDIT: corresponds to Indicator prefix override field, is currently editable in the UI and should be customizable.
concurrent_searches ― This one is user-editable via API but we have no UI for it. No prebuilt rules have it in https://github.com/elastic/detection-rules. How should we handle it in the upgrade workflow?
items_per_search ― This one is user-editable via API but we have no UI for it. No prebuilt rules have it in https://github.com/elastic/detection-rules. How should we handle it in the upgrade workflow?

The text was updated successfully, but these errors were encountered:

elasticmachine · 2022-12-08T11:44:19Z

Pinging @elastic/security-detections-response (Team:Detections and Resp)

elasticmachine · 2022-12-08T11:44:20Z

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

banderror · 2022-12-08T11:49:45Z

@jethr0null @peluja1012 Can we please have your input on this?

Please review the tables in the Rule fields section.
Please check the Rule fields to discuss and submit your thoughts here in the comments per each field.

Feel free to ping us if you have any questions and would like to chat over zoom.

banderror · 2023-11-07T17:26:14Z

@approksiu As we agreed over Zoom, please review the ticket's description and especially the "Rule fields to discuss" section. There's a list of rule fields we will need to make some decisions for.

There's also a related discussion "ticket" in the form of PR #148913 that gives examples of typical diff situations for a few typical rule fields. We will need to revisit this PR at some point after we start working on Milestone 3. cc @jpdjere

approksiu · 2023-11-09T08:33:53Z

Some corrections to the tables above:

building_block_type - is used in prebuilt rules schema
threat_indicator_path - editable and customizable - corresponds to "indicator prefix override" setting
new_terms_fields - is used in prebuilt rules schema
history_window_start - is used in prebuilt rules schema

approksiu · 2023-11-09T08:34:45Z

@vitaliidm could you add the fields for es|ql rule type in the comment please?

approksiu · 2023-11-09T08:48:14Z

type ― Confirm that we're not going to support changing the rule type on upgrade.

This one is tricky.
The arguments towards supporting it:

the rule use-case will stay the same, but the other type is better-suited to address the use-case.
if user has set exceptions and actions, they would apply to the updated rule type, and user would not need to recreate these settings for the new rule of other type for the same use-case.
the rules deprecation flow is not yet implemented

Arguments for not supporting rule type change on upgrade:

it does not happen often, effort put into development for the small impact is not justified
we are planning to improve the deprecation workflow to make it more clear
we are not allowing users to customize rule type, it could be confusing if we do allow it in the updates
if the user customises prebuilt rule and we change it's type - user changes will not be applicable to the updated rule

That being said, I think we should not allow rule type updates at the moment. We can revisit this in the future if there are substantial arguments against this decision. cc @brokensound77

approksiu · 2023-11-09T08:52:56Z

related_integrations, required_fields, setup ― These can be specified in https://github.com/elastic/detection-rules but we don't support editing them in the app. Since we don't have UI for editing them, I'm wondering if it's time to finally build it. When we build the UI we will be able to support these fields in the rule upgrade flyout.

we should support setup field editing
required_fields - can we make this fields auto-update based on the query fields?
related_integrations - I think this field is most relevant to the prebuilt rules, I think it would make sense to eventually allow editing it as well, it is helpful for providing more context and rules monitoring

approksiu · 2023-11-09T08:59:05Z

actions, throttle ― We allow the user to specify actions for installed prebuilt rules, but no prebuilt rules actually have actions in https://github.com/elastic/detection-rules. Can we remove support for actions from the prebuilt rule schema and handle the upgrade for these 2 fields under the hood (always take the current user's version)?

I agree. I don't expect to ship actions and throttle in the prebuilt rules.
As for schema changes - I would like to understand the implications of this on the users managing their detections as code. cc @banderror

approksiu · 2023-11-09T09:03:29Z

max_signals ― This is a circuit breaker value. A few prebuilt rules have it in https://github.com/elastic/detection-rules. Users can modify it via the API. We don't have a UI for it. How do we resolve conflicts in this field?

Would it make sense to build UI for this? Looks like advanced setting that users can benefit from.

approksiu · 2023-11-09T09:07:34Z

response_actions ― This is fully user-editable and supported by the prebuilt rule schema, but no prebuilt rules have it in https://github.com/elastic/detection-rules. Our suggestion would be to remove it from the schema and handle it under the hood of the upgrade workflow.

Agree, same as actions, same question about implications

approksiu · 2023-11-09T09:08:46Z

language ― Specifically for EQL rules, do we allow the user to change this? From the rule schema, it looks like this can accept only one value: "eql".

We don't allow changes, this field will always be the same. I don't think it is needed.

approksiu · 2023-11-09T09:10:05Z

concurrent_searches ― This one is user-editable via API but we have no UI for it. No prebuilt rules have it in https://github.com/elastic/detection-rules. How should we handle it in the upgrade workflow?
items_per_search ― This one is user-editable via API but we have no UI for it. No prebuilt rules have it in https://github.com/elastic/detection-rules. How should we handle it in the upgrade workflow?

We could consider adding UI for this at a later stage. Can we treat no-UI fields with the json diff?

approksiu · 2023-11-09T09:11:58Z

output_index ― This is a name of a concrete target index where the rule is supposed to write alerts. I believe this field is deprecated and unused in the app. No prebuilt rules have it in https://github.com/elastic/detection-rules. Users can still modify it via the API because it's in the schema. I don't think we have a UI for it. What should we do with this field?
namespace ― This is a namespace (a suffix) of the alerts-as-data index where the rule is supposed to write alerts. AFAIR this is a replacement for output_index but it looks to be unused in the app. No prebuilt rules have it in https://github.com/elastic/detection-rules. Users can still modify it via the API because it's in the schema. I don't think we have a UI for it. What should we do with this field?

This could be useful for MSSP use-case. Will investigate further.

vitaliidm · 2023-11-09T09:47:39Z

@approksiu

There are no new fields introduced to schema specific to ES|QL rule type, only new value to

language ― only takes value esql

And some of the fields are not applicable to ES|QL rule:

filters - not applicable, but exceptions can be used
index - not applicable, index is defined in ES|QL query itself
data_view_id - not applicable, data views not supported in ES|QL

Before #167999, sending these fields in request would fail it. But not anymore, they will be dropped after migration to OpenAPI

approksiu · 2023-11-09T16:35:15Z

type ― Confirm that we're not going to support changing the rule type on upgrade.

This one is tricky. The arguments towards supporting it:
* the rule use-case will stay the same, but the other type is better-suited to address the use-case.

* if user has set exceptions and actions, they would apply to the updated rule type, and user would not need to recreate these settings for the new rule of other type for the same use-case.

* the rules deprecation flow is not yet implemented
Arguments for not supporting rule type change on upgrade:
* it does not happen often, effort put into development for the small impact is not justified

* we are planning to improve the deprecation workflow to make it more clear

* we are not allowing users to customize rule type, it could be confusing if we do allow it in the updates

* if the user customises prebuilt rule and we change it's type - user changes will not be applicable to the updated rule
That being said, I think we should not allow rule type updates at the moment. We can revisit this in the future if there are substantial arguments against this decision. cc @brokensound77

We had a discussion on zoom, and decided to support rule type changes on updates. Will look into UI for this.

brokensound77 · 2023-11-16T19:02:10Z

field	comments
`meta`	why should this be unsupported? We don't currently use it directly in any rules, but have had small use cases
`type`	I know there is a lot of discussion on whether to allow type changes or not. It is definitely beneficial, but then it does add complications to "default" updates and conflict resolution, since some changes may need to be enforced depending on the pre and post type
`setup`	should be editable by users
`required_fields`	the problem with this UI-side is that the query is not parsed and so auto-updating this based on modified query is not currently possible without adding the parsing capability
`author`	should be treated as a special use case where the array is only updateable not modifiable
`license`	great question - if it is elastic license, it should probably stay there, but with what additional caveats
`interval`	all of the rule scheduling fields can create breaking and also unoptimized scenarios for EQL sequence rules (ES
`from`	see `interval`
`to`	see `interval`
`max_signals`	why not be editable?

ML rules

field	comments
`machine_learning_job_id`	will there be dyunamic validation that the job id exists in Kibana

There is also quite a bit of unit testing and rule sync validation that goes on within the rules repo. To an extent, we should be letting users know that by modifying a prebuilt rule, they take on the risk/responsibility of unsyncing, but also, there may be some opportunity to do some of that validation at the rule and rule set level as well

jpdjere · 2023-12-11T11:31:46Z

Updates:

adding revision to the table
removing "(unused)" annotations not for New Terms rules new_terms_fields and history_window_start fields based on this comment
removing "(unused)" annotation for building_block_type field based on this comment
clarifying threat_indicator_path field: is currently editable and should be customizable
setting author and license as not modifiable based on comment
adding alert_suppression as a customizable field to Threshold rules (new feature)

Open questions:

How we will handle "non-customizable" fields if they can still be edited via API? (Examples: author, license, etc.) I see two options:
1. Continue to allow the user to modify them via API. Which means we'll have to build the UI to handle update conflicts anyways.
2. Prevent their update for prebuilt rules. The fields would remain part of the rule schema, but we would add manual checks in the endpoints that reject the update with 400 if the request tries to update those fields.
alert_suppression: I think this follows a similar logic to actions and response_actions - suppression will probably never be defined in the prebuilt rules assets and it's better if we handle this under the hood: always taking the user's current value.
output_index and namespace are marked as deprecated and unused. Should we ignore them for now? Doesn't make sense to build UI for them at this point.
meta: currently stores the information for:
- lookback period, as meta.from but seems superflous: the actual values is stored in a combination of the top-level interval and from properties . from has a value of now-${time}s, where from is: interval.asSeconds() + lookback.asSeconds(). If meta is set to an empty object, the rule continues to have the right data to work.
- kibana_siem_app_url: unsure but seems to be related only to legacy notifications?
  None of them seem to provide value to the user. However, a user might still update it for their own uses, and TRADE team mentions it that they've had some use cases in the past. How should we handle this?
1. If we are expecting prebuilt rules to have updates to it, use a diff view similar to the JSON diff for the whole rule, but only for this field?
2. ignore changes and keep the current value? or alternatively, the target value?

Fields to add customization for: (WIP)

`max_signals` (Max Signals)

Part of BaseRuleParams in the Security Solution side
Part of BaseDefaultableFields in the OpenAPI schema
Is an integer with a minimum value of 1
is non-optional and defaults to 100 on creation
currently modifiable via API

✅ could be added to the customization and update flows without much complexity

`setup` (Setup Guide)

Part of BaseRuleParams in the Security Solution side
Only part of ResponseFields in the OpenAPI schema
This makes it non-modifiable via API (as of 8.12 - see change)
Is an optional string
Defaults to empty string on creation

🟡 if we want to make this customizable (for both custom and prebuilt rules), we need to move this to the BaseDefaultableFields in the OpenAPI schema

`required_fields` (Required Fields)

Part of BaseRuleParams in the Security Solution side
Only part of ResponseFields in the OpenAPI schema
This makes it non-modifiable via API (as of 8.12 - see change)
Is an array of RequiredFields:

    RequiredField:
      type: object
      properties:
        name:
          $ref: '#/components/schemas/NonEmptyString'
        type:
          $ref: '#/components/schemas/NonEmptyString'
        ecs:
          type: boolean
      required:
        - name
        - type
        - ecs

Defaults to empty array on creation
The proposal to make this field be automatically filled based on the query seems out of scope for now: we'd have to build parsers for all the possible query languages that we have.
For allowing the user to customize this, we'd need to create a new UI that allows to type in in free-form text the name of the required field, probably a dropdown for their types, and a (? - unsure here) a checkbox to mark it as ECS compliant or not.

🟡 if we want to make this customizable (for both custom and prebuilt rules), we need to move this to the BaseDefaultableFields in the OpenAPI schema

`related_integrations` (Related Integrations)

Part of BaseRuleParams in the Security Solution side
Only part of ResponseFields in the OpenAPI schema
This makes it non-modifiable via API (as of 8.12 - see change)
Is an array of RelatedIntegration objects:

    RelatedIntegration:
      type: object
      properties:
        package:
          $ref: '#/components/schemas/NonEmptyString'
        version:
          $ref: '#/components/schemas/NonEmptyString'
        integration:
          $ref: '#/components/schemas/NonEmptyString'
      required:
        - package
        - version

Defaults to empty array on creation
In order to make customizable, we will have to create the UI to let users select existing integrations (since it doesn't make sense to allow for free text typing). We can make a call to the Fleet endpoint: GET /fleet/epm/packages which lists all packages. Responds an array like so:

{
    "items": [
        {
            "name": "1password",
            "title": "1Password",
            "version": "1.26.0",
            "release": "ga",
            "description": "Collect logs from 1Password with Elastic Agent.",
            "type": "integration",
            "download": "/epr/1password/1password-1.26.0.zip",
            "path": "/package/1password/1.26.0",
            "icons": [
                {
                    "src": "/img/1password-logo-light-bg.svg",
                    "path": "/package/1password/1.26.0/img/1password-logo-light-bg.svg",
                    "title": "1Password",
                    "size": "116x116",
                    "type": "image/svg+xml"
                }
            ],
            "policy_templates": [
                {
                    "name": "1password",
                    "title": "1Password Events",
                    "description": "Collect events from 1Password Events Reporting"
                }
            ],
            "conditions": {
                "kibana": {
                    "version": "^8.7.1"
                }
            },
            "owner": {
                "github": "elastic/security-external-integrations"
            },
            "categories": [
                "security",
                "credential_management"
            ],
            "signature_path": "/epr/1password/1password-1.26.0.zip.sig",
            "id": "1password",
            "status": "not_installed"
        },
        {
            "name": "akamai",
            "title": "Akamai",
            "version": "2.21.0",
            "release": "ga",
            "description": "Collect logs from Akamai with Elastic Agent.",
            "type": "integration",
            "download": "/epr/akamai/akamai-2.21.0.zip",
            "path": "/package/akamai/2.21.0",
            "icons": [
                {
                    "src": "/img/akamai_logo.svg",
                    "path": "/package/akamai/2.21.0/img/akamai_logo.svg",
                    "title": "Akamai",
                    "size": "409×167",
                    "type": "image/svg+xml"
                }
            ],
            "policy_templates": [
                {
                    "name": "akamai",
                    "title": "Akamai logs",
                    "description": "Collect SIEM logs from Akamai"
                }
            ],
            "conditions": {
                "kibana": {
                    "version": "^8.7.1"
                }
            },
            "owner": {
                "github": "elastic/security-external-integrations"
            },
            "categories": [
                "security",
                "cdn_security"
            ],
            "signature_path": "/epr/akamai/akamai-2.21.0.zip.sig",
            "id": "akamai",
            "status": "not_installed"
        },
        // many more packages
    ]
}

A similar logic will probably be needed in the UI for the update/conflict workflow (call to the endpoint to list existing packages).

🟡 if we want to make this customizable (for both custom and prebuilt rules), we need to move this to the BaseDefaultableFields in the OpenAPI schema

`concurrent_searches` (Concurrent Searches)

Part of ThreatSpecificRuleParams in the Security Solution side
Part of ThreatMatchRuleOptionalFields in the OpenAPI schema
Is an integer with a minimum value of 1
is optional and does not default to any value
currently modifiable via API

✅ could be added to the customization and update flows without much complexity

`items_per_search` (Items Per Search)

Part of ThreatSpecificRuleParams in the Security Solution side
Part of ThreatMatchRuleOptionalFields in the OpenAPI schema
Is an integer with a minimum value of 1
is optional and does not default to any value
currently modifiable via API

✅ could be added to the customization and update flows without much complexity

approksiu · 2024-01-02T13:46:41Z

Issues for exposing the fields:
Setup - #173626
Max signals #173593
Required fields #173594
Related integrations #173595
cc @jpdjere

jpdjere · 2024-01-16T14:23:01Z

Answers for questions in comment above from Product Meeting of 14/12/2023:

How we will handle "non-customizable" fields if they can still be edited via API? (Examples: author, license, etc.) I see two options:

Prevent their update for prebuilt rules. The fields would remain part of the rule schema, but we would add manual checks in the endpoints that reject the update with 400 if the request tries to update those fields.

alert_suppression: I think this follows a similar logic to actions and response_actions - suppression will probably never be defined in the prebuilt rules assets and it's better if we handle this under the hood: always taking the user's current value.

This field might be subject to change, so handle alert_suppression by calculating the diff in the endpoint, but for a first iteration, just hide the diff, as we currently do for actions.

output_index and namespace are marked as deprecated and unused. Should we ignore them for now? Doesn't make sense to build UI for them at this point.

Don't create UI to edit them. In the endpoint, always return the user's value. No diff should ever show up for these fields.

meta: currently stores the information for:
- lookback period, as meta.from but seems superflous: the actual values is stored in a combination of the top-level interval and from properties . from has a value of now-${time}s, where from is: interval.asSeconds() + lookback.asSeconds(). If meta is set to an empty object, the rule continues to have the right data to work.
- kibana_siem_app_url: unsure but seems to be related only to legacy notifications?
None of them seem to provide value to the user. However, a user might still update it for their own uses, and TRADE team mentions it that they've had some use cases in the past. How should we handle this?

meta should be deprecated and eliminated eventually. So, for now, in the endpoint, always return the user's value. No diff should ever show up for this fields.

banderror · 2024-04-13T11:53:18Z

@jpdjere @approksiu I think we can consider this discussion finished, with decisions made and tickets created. Thank you very much for the work you've done for making it clear.

Besides the tickets for missing editing UI for certain rule fields, @jpdjere is working on a ticket #180393 that describes what other changes for rule fields should be introduced to the rule upgrade workflow, rule schemas, and in general. Closing this one as done ✅

banderror assigned peluja1012, xcrzx, jethr0null, banderror and spong Dec 8, 2022

banderror mentioned this issue Dec 8, 2022

[Security Solution] PoC of the rule upgrade and installation workflows #144060

Closed

12 tasks

banderror added the 8.7 candidate label Dec 29, 2022

banderror mentioned this issue Jan 5, 2023

[Security Solution] Architecture design for prebuilt rules customization #125665

Closed

banderror added 8.8 candidate and removed 8.7 candidate labels Feb 22, 2023

banderror removed the 8.8 candidate label Apr 26, 2023

banderror assigned approksiu and unassigned peluja1012, xcrzx, jethr0null and spong Nov 7, 2023

banderror mentioned this issue Nov 15, 2023

[Security Solution] Write an RFC for customizing prebuilt rules #171309

Closed

Mikaayenson mentioned this issue Nov 21, 2023

[FR] Add Support for ES|QL Rule Type and Remote Validation elastic/detection-rules#3281

Merged

This was referenced Jan 3, 2024

[Security Solution] Users can Customize Prebuilt Detection Rules: Milestone 1 #174166

Closed

[Security Solution] Users can Customize Prebuilt Detection Rules: Milestone 3 #174168

Open

approksiu mentioned this issue Jan 16, 2024

[Security Solution] Implement per-field text-based diffs for the prebuilt rule upgrade flyout #166489

Closed

17 tasks

nikitaindik mentioned this issue Jan 16, 2024

[Security Solution] JSON diffs for prebuilt rules: Technical / runtime properties are displayed #174844

Closed

maximpn mentioned this issue Feb 7, 2024

[Security Solution] Prebuilt rule's exceptions are lost when the rule is upgraded to a new version in which the rule's type is different #169480

Closed

3 tasks

banderror mentioned this issue Mar 14, 2024

[Security Solution] RFC for Prebuilt Rules Customization - Milestone 3 #171856

Merged

banderror assigned jpdjere Apr 13, 2024

banderror added 8.14 candidate and removed needs product labels Apr 13, 2024

banderror closed this as completed Apr 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Security Solution] Discuss rule fields in the context of the prebuilt rule upgrade workflow #147239

[Security Solution] Discuss rule fields in the context of the prebuilt rule upgrade workflow #147239

banderror commented Dec 8, 2022 •

edited

elasticmachine commented Dec 8, 2022

elasticmachine commented Dec 8, 2022

banderror commented Dec 8, 2022 •

edited

banderror commented Nov 7, 2023 •

edited

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

vitaliidm commented Nov 9, 2023

approksiu commented Nov 9, 2023

brokensound77 commented Nov 16, 2023 •

edited

jpdjere commented Dec 11, 2023 •

edited

approksiu commented Jan 2, 2024

jpdjere commented Jan 16, 2024 •

edited

banderror commented Apr 13, 2024

[Security Solution] Discuss rule fields in the context of the prebuilt rule upgrade workflow #147239

[Security Solution] Discuss rule fields in the context of the prebuilt rule upgrade workflow #147239

Comments

banderror commented Dec 8, 2022 • edited

Summary

Rule fields

Fields common to all rule types

Fields specific to Custom Query and Saved Query rules

Fields specific to EQL rules

Fields specific to Indicator Match rules

Fields specific to Threshold rules

Fields specific to Machine Learning rules

Fields specific to New Terms rules

Fields specific to ES|QL Rules

Rule fields to discuss

elasticmachine commented Dec 8, 2022

elasticmachine commented Dec 8, 2022

banderror commented Dec 8, 2022 • edited

banderror commented Nov 7, 2023 • edited

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

approksiu commented Nov 9, 2023

vitaliidm commented Nov 9, 2023

approksiu commented Nov 9, 2023

brokensound77 commented Nov 16, 2023 • edited

ML rules

jpdjere commented Dec 11, 2023 • edited

Updates:

Open questions:

Fields to add customization for: (WIP)

max_signals (Max Signals)

setup (Setup Guide)

required_fields (Required Fields)

related_integrations (Related Integrations)

concurrent_searches (Concurrent Searches)

items_per_search (Items Per Search)

approksiu commented Jan 2, 2024

jpdjere commented Jan 16, 2024 • edited

Answers for questions in comment above from Product Meeting of 14/12/2023:

banderror commented Apr 13, 2024

banderror commented Dec 8, 2022 •

edited

banderror commented Dec 8, 2022 •

edited

banderror commented Nov 7, 2023 •

edited

brokensound77 commented Nov 16, 2023 •

edited

jpdjere commented Dec 11, 2023 •

edited

`max_signals` (Max Signals)

`setup` (Setup Guide)

`required_fields` (Required Fields)

`related_integrations` (Related Integrations)

`concurrent_searches` (Concurrent Searches)

`items_per_search` (Items Per Search)

jpdjere commented Jan 16, 2024 •

edited