Update the securityCenter.bicep module API provider so that warnings do not occur

[glennmusa]

Benefit/Result/Outcome

So that deployments do not present warnings.

Description

Today, the src/bicep/modules/securityCenter.bicep module uses a provider type that is not published and any az deployment sub create followed by the Quickstart will present this warning to the end user:

/workspaces/missionlz/src/bicep/modules/securityCenter.bicep(73,34) : Warning BCP081: Resource type "Microsoft.Security/policies@2015-06-01-preview" does not have types available.

Acceptance Criteria

• Security Center is still deployed as desired, but the warnings are not present and a supported provider is used instead

[glennmusa]

@lisamurphy-msft since you've picked this up, one way to solve this problem is to look at the deployed resources that the ARM deployment produces from the template today after an az deployment and update the templates to use those specific resource providers and API versions. Happy to chat offline and show you what I mean. Probably other ways to solve this too, though!

[lisamurphy-msft]

Thank you for the idea @glennmusa !
Will investigate the approach you suggested.

[lisamurphy-msft]

As per previous guidance; in order to test this we need to enable the boolean parameter deployASC to test via:
az deployment sub create -n <deploymentName> -l <location> -f mlz.bicep --parameters deployASC=true
The problematic portion is that Microsoft.Security/policies is not defined in any version of the API according to the documentation Still investigating.

[lisamurphy-msft]

Spoke to the content creator of the documentation; reconfirmed in the azure-rest-api-specs that there was no defined Microsoft.Security/policies - this is not a REST API documentation issue. Discussed briefly with the ASC owning team for additional guidance. It was relayed that Security "policy" is not an API that is exposed by ASC but rather there is a default recommendation to use the policy set definitions that are exposed via the Azure policy REST API defined here
Ultimately the recommendation is to change the securityCenter.bicep to use Microsoft.Authorization/policysetdefinitions instead. Will investigate a path forward.

[lisamurphy-msft]

Appears what happened is we enabled ASC and in so doing enabled a default policy titled "ASC default" which appears to apply 207 policySetDefinition controls that are the default that are applied when initializing ASC through other methods. These are automatically assigned and are audit only. I'm trying to determine what value this brings to the customer by explicitly initializing ASC. When looking at other documentation it also appears that we are advertising NIST when I think we should be really distinguishing between NIST 800-53 r4 and NIST 800-53 r5
Similar to how this is done here
Should we be using the policyId builtin for this effort?

var policyId = 'cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f' // NIST SP 800-53 R4 
var assignmentName = 'NIST SP 800-53 R4'

or

var policyId = '179d1daa-458f-4e47-8086-2a68d0d6c38f' // NIST SP 800-53 R5 
var assignmentName = 'NIST SP 800-53 R5'

In the shorter term I can modify the securityCenter.bicep file to simply initialize ASC since this should just create the default policy automatically upon initialization.

[lisamurphy-msft]

Although a PR was proposed that met the acceptance criteria, we are taking a more holistic approach to solving this problem. There were a few issues brought up that need to be addressed:

• The undocumented API for Microsoft.Security/policies appears to regenerate the default policies if they are deleted in ASC
• Even though we can generate the default policies upon initialization of ASC, the default policies aren't activated without first opening the blade in the subscription to view them (TBD)

[lisamurphy-msft]

Alright, spoke with the ASC team quick notes:
We should not be using this Microsoft.Security/policies API as it is being deprecated
Policy assignment can take up to 24 hours to propagate.
If we navigate to Microsoft Defender to the Cloud and check the definitions, there should be an Azure Security Benchmark which can be assigned to the subscription
This is a built-in policy that is exposed to all customers that can be removed and re-assigned. ASC Default is the initial naming of this Azure Security Benchmark definition.
Will continue on this when I get back in the office in January.