metrics: Fill in Amoe metric templates

[franzling]

Draft of AMOE metric contents including the metric.rego files
The parameters need to be included into the ontology.

To propose a new compliance metric, please make sure to check off each box below:

• I have created a folder with the new within an existing category folder (e.g., metrics/EndpointSecurity) or create a new category folder.
• I have created a file data.json (example).
• I have created a file .yaml (example).
• I have created a file metric.rego (example).
• The <metric.rego> file is valid according to the JSON schema.
• The properties used in the .yaml and metric.rego files are available in the Ontology.
• I have added a reviewer (e.g., @immqu).

[anatheka]

We changed the target branch to main.

Please update the following points:

• Rename folder and name fields to self-explaining names without Q1, Q2, ...
• Change targetValues to integer values, if you use the operator "<=" or similar
• Only use sentences like "The rule assesses whether ..." in the description . The other information move to the comment part.
• Delete | Selector: PolicyDocument (Resource Type) and change [Resource]to [PolicyDocument] in the description part.
• Delete TBD in the comments part if not needed.
• Add the resource type check in applicable in the metric.rego files, see comment.

[lebogg]

See my suggested changes. For each metric:

• Fix the package name (same as metric folder name but in snake case)
• I would use the Selector part within the Description and remove it from the comments (The reason: For now it is only Policy Document relevant. Later, if we say also another collector will use this, we can still generalize it to "Resource")
• I would remove the "Previous name..." part from the comments.

[anatheka]

A first review: I couldn’t read all metrics, but I’ve read some in detail and skimmed others.

I think it already looks very good, I just have a few comments:

• Most of my comments apply to all metrics—for example, specifying the “time period” in the comments so it’s clear what time period exactly is to be checked.
• As mentioned in the comment for the metric MonitoringReviewFrequency, please delete or remove the specific AMOE or EMERALD information from the comments section and use the PolicyDocument as specific resource in the description.

[anatheka]

I’m thinking about whether it would make sense to indicate directly in the metric name that it represents a policy evaluation. What do you think @lebogg ?

If we want to do so, we should do it in the other metrics as well.

[franzling]

addressed proposals over all files. please review