What should be considered a secure module

[AlexanderSehr]

We currently updating the security of our modules with the following approach:

All default values should comply with a security baseline, e.g. NIST 800
The build-in policies of Azure can be used as a reference.

However, while the security baseline provides a good starting point, it also raises questions to be answered. For example:

• What to do about security parameters that require additional user input (e.g. private endpoints). Currently we provide the capability, but cannot 'deploy it by default'.
• What about security parameters that require providers to be enabled on the subscription (i.e. a user would need to do that as a pre-requisite)
• What about security parameters that can only be enabled but not disabled again (e.g. purge protection for key vaults)
• What about security parameters that must be enabled by the time the service is deployed for the first time as they are not idempotent (e.g. EncryptionAtHost for the VM module)

We should agree on an approach. For example

• Only provide the capabilities without enabling them by default
• Enable all those that don't require manual actions / pre-requisites
• Always include security implementation based on ALZ and ASB guidance.
• Security settings that introduce breaking changes will be implemented but not enabled by default. and with a note.
• We recommend pushing security, governance, control up to Azure policy. but can't always rely on that.

cc: @mblant @eriqua @MariusStorhaug @matebarabas @alex-lee-microsoft @elanzel @elbatane @ahmadabdalla @rahalan @SeSeicht

[MariusStorhaug]

Just adding suggested ruleset from discussion in teams:

1. As secure as possible by default.
2. Always include security implementation based on ALZ and ASB guidance.
3. Security settings that introduce breaking changes will be implemented but not enabled by default, with a note.
4. We recommend pushing security, governance, control up to Azure policy, but can't always rely on that.
5. Add security professionals to open this discussion wider and deeper.

[MariusStorhaug]

We should also consider what we mean by "breaking change". I would not consider a new secure default value that breaks deployments for resources where certain settings can only be configured on deployment time (set-once properties) in a brow fielding setting as "breaking change". In any brownfield setting you would collect all the parameters of a module from the environment you would retrofit into IaC. This discussion also goes into versioning of the module for publication I think.