[Bug] In Version requirement in related integration field for Microsoft 365

[shashank-elastic]

Describe the bug
User report in community slack channel a bug with the related_integrations field - related to version - https://elasticstack.slack.com/archives/C016E72DWDS/p1709825029106529

I'm enabling the rule Potential Password Spraying of Microsoft 365 User Accounts in a new cluster where the latest version of the office365 Logs is installed.
When viewing the rule I see the following warning. Does it require an older version?

To Reproduce

• Try Enabling Potential Password Spraying of Microsoft 365 User Accounts on latest version of Microsoft 365

Expected behavior
TRADE needs to bump up the version requirement in this related integration. The requirement is defined by the ^1.3.0 semver range, where the installed version is already 2.3.0. Major version 2 is not supported by this semver range.
Additional Reference: https://devhints.io/semver

Additional context
Slack Discussion Thread - https://elastic.slack.com/archives/CN7AD3605/p1709827164869209

[shashank-elastic]

Discussion Notes from @terrancedejesus

If I understand correctly, when we discussed the logic for this, TRADE was required to supply the least compatible version for a rule, related to an integration. If this rule passed validation, then we can confirm that the query specified has fields and types found within integration versions 1.3.0+
I think the issue is the semver range where we use ^ to specify major 1  and minor and patch can be anything whereas we need to specify 1.3.0+

With the existing logic, we would be bumping rule min-stacks anytime a major version changes for an integration which could be problematic, if for sure, the query is valid but we require the customer to be on the latest stack and integration version.

[shashank-elastic]

Debugging Starters

The logic to dynamically generate the build time field, related_integrations needs to be evaluated to determine version compatibility determination, specifically for major version that may have changed.
To start: Find a rule that has an integration tag, then debug loading the rule with the view-rule  CLI command. Add a breakpoint in the post_dict_conversion  method to start.```

[shashank-elastic]

Initially Debugging on DED sync showed. the expected rule version for this is rightly being populated on branch main

Debugging rule via view-rule /Users/shashankks/elastic_workspace/detection-rules/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml

{
  "author": [
    "Elastic"
  ],
  "description": "Identifies a high number (25) of failed Microsoft 365 user authentication attempts from a single IP address within 30 minutes, which could be indicative of a password spraying attack. An adversary may attempt a password spraying attack to obtain unauthorized access to user accounts.",
  "false_positives": [
    "Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives."
  ],
  "from": "now-30m",
  "index": [
    "filebeat-*",
    "logs-o365*"
  ],
  "language": "kuery",
  "license": "Elastic License v2",
  "name": "Potential Password Spraying of Microsoft 365 User Accounts",
  "note": "",
  "query": "event.dataset:o365.audit and event.provider:(Exchange or AzureActiveDirectory) and event.category:authentication and\nevent.action:(\"UserLoginFailed\" or \"PasswordLogonInitialAuthUsingPassword\")\n",
  "related_integrations": [
    {
      "package": "o365",
      "version": "^2.0.0"
    }
  ],
  "required_fields": [
    {
      "ecs": true,
      "name": "event.action",
      "type": "keyword"
    },
    {
      "ecs": true,
      "name": "event.category",
      "type": "keyword"
    },
    {
      "ecs": true,
      "name": "event.dataset",
      "type": "keyword"
    },
    {
      "ecs": true,
      "name": "event.provider",
      "type": "keyword"
    }
  ],
  "risk_score": 73,
  "rule_id": "3efee4f0-182a-40a8-a835-102c68a4175d",
  "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
  "severity": "high",
  "tags": [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access"
  ],
  "threat": [
    {
      "framework": "MITRE ATT&CK",
      "tactic": {
        "id": "TA0006",
        "name": "Credential Access",
        "reference": "https://attack.mitre.org/tactics/TA0006/"
      },
      "technique": [
        {
          "id": "T1110",
          "name": "Brute Force",
          "reference": "https://attack.mitre.org/techniques/T1110/"
        }
      ]
    }
  ],
  "threshold": {
    "field": [
      "source.ip"
    ],
    "value": 25
  },
  "timestamp_override": "event.ingested",
  "type": "threshold",
  "version": 104
}

[shashank-elastic]

The Release Patch https://github.com/elastic/ia-trade-team/issues/306 has the right version requirements across the integration packages for 8.10 through 8.13

"related_integrations": [
    {
      "package": "o365",
      "version": "^2.0.0"
    }
  ],

So the obvious suspect would be customer on the older stack, which is yet to be confirmed!
Customer has been asked to share the stack details https://elasticstack.slack.com/archives/C016E72DWDS/p1710436957387209?thread_ts=1709825029.106529&cid=C016E72DWDS

[Mika Ayenson]

You could stand up an old stack with the older related integration version. Then upgrade to the next version when the related integration should bump to ^2.0.0 and see if the issue appears.

[shashank-elastic]

This can be closed the user has not got back with any confirmations and we have not seen this issue reported else where as well. Clearing from backlog.