[BUG] Tag must start with "attack" when creating detection rule

[amsiglan]

What is the bug?
When creating a detection rule, an exception is thrown by the create/update rule API if a tag does not start with attack.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to Detection rules page
2. Add below rule yaml in the YAML editor and hit Create

id: OFRhN4wBypPZ_lmJW5Q2
logsource:
  product: dns
title: High DNS Bytes Out cloned
description: High DNS queries bytes amount from host per short period of time
tags:
  - cve.exfiltration
  - attack.t1048.003
falsepositives:
  - >-
    Legitimate high DNS bytes out rate to domain name which should be added to
    whitelist
level: medium
status: experimental
references: []
author: 'Daniil Yugoslavskiy, oscd.community'
detection:
  selection:
    query: '*'
  timeframe: 1m
  condition: selection

What is the expected behavior?
Rule gets created but instead it shows error that tag must start with attack

What is your host/environment?

• Security analytics all versions upto 2.11

Do you have any screenshots?

Do you have any additional context?
N/A

[engechas]

The error comes from a frontend validation here: https://github.com/opensearch-project/security-analytics-dashboards-plugin/blob/main/public/pages/Rules/components/RuleEditor/RuleEditorForm.tsx#L80-L92

I removed this validation and tested the following:

1. Creating a rule with arbitrary tags (cve.exfiltration)
2. Generating findings and alerts for the rule
3. Generating correlations for the rule

All of these worked with no errors on the backend.

@sbcd90 do you have any context on why the frontend validation would have been added? I don't see any context in the PR that introduced it: opensearch-project/security-analytics-dashboards-plugin#622

[mimicbox]

I would like to shine more light on this issue. This is a decent issue with porting SIGMA rules from other sources as they do not follow this, what seems arbitrary, restriction.

I currently automate our loading of SIGMA rules from a repo to OS via API and having to scrub tag names and add attack. to the start of them is not ideal, and is misleading for a lot of tags. For example if we tag a rule winlogbeat as it works on that dataset, it will have to be attack.winlogbeat in the tag which does not make sense for a rule looking for sysmon configuration changes.

I will also note that the preloaded rules in OS do not follow this restriction.

Example:
title: UAC Bypass via Sdclt
id: 5b872a46-3b90-45c1-8419-f675db8053aa
status: experimental
description: Detects the pattern of UAC Bypass using registry key manipulation of sdclt.exe (e.g. UACMe 53)
references:
- https://enigma0x3.net/2017/03/17/fileless-uac-bypass-using-sdclt-exe/
- https://github.com/hfiref0x/UACME
author: Omer Yampel, Christian Burkard
date: 2017/03/17
modified: 2022/06/26
logsource:
category: registry_set
product: windows
detection:
selection1:
EventType: SetValue
TargetObject|endswith: Software\Classes\exefile\shell\runas\command\isolatedCommand
selection2:
EventType: SetValue
TargetObject|endswith: Software\Classes\Folder\shell\open\command\SymbolicLinkValue
Details|contains: '-1???\Software\Classes'
condition: 1 of selection*
falsepositives:
- Unknown
level: high
tags:
- attack.defense_evasion
- attack.privilege_escalation
- attack.t1548.002
- car.2019-04-001

This is a preloaded rule in OS and one of the tags does not follow the restriction placed on users.

[tallyoh]

Any update on this issue?

[tallyoh]

Wondering if a fix might be coming for this in 2.15? Thanks