Update Minstack versions for SentinelOne rules

[shashank-elastic]

Issues

Double Bump in Version Lock #3776

Summary

• Follow steps of How do I Fix double version bumps for related integrations rules in FAQ
• Update Min stack version for all affected rules
• SentinelOne integration version changed across versions documented here

[Mikaayenson]

Do you know why this double bumped? Was it because the integration version changed across versions?

[shashank-elastic]

Do you know why this double bumped? Was it because the integration version changed across versions?

Yes @Mikaayenson the versions have changed

In 8.12 and below sample rule snippet SentinelOne Version was 0.1.0

{
  "author": [
    "Elastic"
  ],
  "description": "Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one.",
  "from": "now-9m",
  "index": [
    "winlogbeat-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-sentinel_one_cloud_funnel.*"
  ],
  "language": "eql",
  "license": "Elastic License v2",
  "name": "Suspicious Antimalware Scan Interface DLL",
  <<<READCTED>>>
  "related_integrations": [
    {
      "package": "windows",
      "version": "^1.5.0"
    },
    {
      "package": "endpoint",
      "version": "^8.2.0"
    },
    {
      "package": "sentinel_one_cloud_funnel",
      "version": "^0.1.0"
    }
  ],
  <<READCTED>>
  "timestamp_override": "event.ingested",
  "type": "eql",
  "version": 111
}

In version 8.13 and above sample rule snippet SentinelOne Version was 1.0.0

{
  "author": [
    "Elastic"
  ],
  "description": "Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one.",
  "from": "now-9m",
  "index": [
    "winlogbeat-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-sentinel_one_cloud_funnel.*"
  ],
  "language": "eql",
  "license": "Elastic License v2",
  "name": "Suspicious Antimalware Scan Interface DLL",
<< REDACTED>>
  "related_integrations": [
    {
      "package": "windows",
      "version": "^1.5.0"
    },
    {
      "package": "endpoint",
      "version": "^8.2.0"
    },
    {
      "package": "sentinel_one_cloud_funnel",
      "version": "^1.0.0"
    }
  ],
<<REDACTED>>
  "timestamp_override": "event.ingested",
  "type": "eql",
  "version": 110
}

[terrancedejesus]

We attempted to avoid this with https://github.com/elastic/detection-rules/pull/3627/files.
Ideally, the rules would be allowed to have a pre-release version. I think the when the code touches here it chooses 1 > 0 and uses that one. The rule in the UI will always point to the latest compatible with the stack, so 8.11 will show a prerelease compatible whereas 8.13 will show the 1.0.0+ for the integration installation.

What we did was allow for rules to have a related integration with only pre-releases but did not solve the SHA256 diff that follows in related integrations when the rule is backported and the field value is dynamically generated. I wouldn't say this is a "bug" either as we expect some rules to have their min-stack bumped when "breaking changes" are introduced to an integration, causing the major to be bumped.

Per conversation with @shashank-elastic - I don't think we should block the release entirely as these rules were released with S1 compatibility in the previous release and therefore will approve.