[Bug]: azure_194 false positive: Storage Accounts on TLS1_2 marked fail

[JonasBogvad]

Rule azure_194 ("Ensure the 'Minimum TLS version' for storage accounts is set to 'Version
1.2'") returns statusCode: "fail" for storage accounts whose properties.minimumTlsVersion is
already "TLS1_2". The verdict contradicts the evidence captured in the same finding document.

The resource data collected by Monkey365 correctly shows minimumTlsVersion: "TLS1_2", but the
rule still evaluates to Fail. My hypothesis: the rule compares against a literal like "1.2"
while the ARM API returns "TLS1_2" (or "TLS1_3"), so the string comparison never matches.

How to reproduce it

1. In an Azure tenant, ensure a Storage Account has Minimum TLS version set to 1.2 (ARM
   property: properties.minimumTlsVersion = "TLS1_2"). This is the default for new accounts and
   can be confirmed in the portal under Storage account → Configuration → Minimum TLS version.
2. Run:
   Invoke-Monkey365 -Instance Azure
   -Collect All -TenantID <TENANT_ID>
   -ClientId <CLIENT_ID> -ClientSecret <SECURE_STRING>
   -AllSubscriptions `
   -ExportTo JSON
3. Open the exported JSON and search for azure_194.
4. Observe: statusCode is "fail" even though
   resources.data[].metadata.properties.minimumTlsVersion is "TLS1_2" in the same finding.

Expected behavior

Storage accounts with minimumTlsVersion of "TLS1_2" or "TLS1_3" should produce statusCode:
"pass" for azure_194.

Screenshots or Logs

Redacted excerpt of the finding from the exported JSON (two different storage accounts, both
set to TLS 1.2, both marked Fail):

{
"unmapped": { "ruleId": "azure_194", "resource": "StorageAccounts" },
"statusCode": "fail",
"findingInfo": {
"title": "Ensure the 'Minimum TLS version' for storage accounts is set to 'Version 1.2'"
},
"resources": {
"data": [
{
"metadata": {
"name": "<REDACTED_STORAGE_1>",
"type": "Microsoft.Storage/storageAccounts",
"properties": {
"minimumTlsVersion": "TLS1_2",
...
}
}
}
]
}
}

Reproduced on both 0.96.6 (Azure Automation runtime environment) and 0.97 (local clean
install). No custom -RuleSet or -RulesPath used - default built-in ruleset.

From where are you running Monkey365?

• Resource: Workstation
• OS: Windows 11
• PowerShell Version: 7.6.0
• Monkey365 Version: 0.97 (also reproduced on 0.96.6)
• Others: Service Principal auth with Reader on subscriptions

Additional context

The finding's own resource data and its verdict contradict each other within the same JSON
document, so this is detectable deterministically - a regression test that asserts "given
TLS1_2, azure_194 must pass" would catch this class of bug.

[silverhack]

HI @JonasBogvad thanks for submitting this, it's really appreciated.

I can confirm that there is a bug with that query, as the condition will always return true for every possible value and will returns every storage account, even the compliant ones.

The condition:

{
    "filter": [
        {
            "conditions": [
                [
                    "properties.minimumTlsVersion",
                    "ne",
                    "TLS1_2"
               ],
               [
                   "properties.minimumTlsVersion",
                   "ne",
                   "TLS1_3"
               ]
          ],
         "operator": "or"
      }
  ]
}

Will be converted to

@($InputObject).Where({$_.properties.minimumTlsVersion -ne "TLS1_2" -or $_.properties.minimumTlsVersion -ne "TLS1_3"});

The above query will return both, storage accounts with TLS1_2 and TLS1_3.

Thanks!