Detect Windows Security Center COM call

[Still34]

Summary

This PR adds a detection for the CLSID/IIDs used when interacting with the Windows Security Center via COM call. This method has been used in-the-wild to disable Windows Defender by registering a dummy module as the security solution via Windows Security Center.

[mike-hunhoff]

Thanks @Still34 ! I left a quick comment for your review. Also, please add a description field with a short blurb discussing how the capability is used.

[Still34]

I've added a short description though I'm unsure if there's any guideline for writing rule-level descriptions. I just went with what was described above.

[mike-hunhoff]

Thank you for the updates @Still34 . Rule lints are failing:

    (nursery)  register Windows Security Center product
      WARN: referenced example doesn't exist: Add the referenced example to 
samples directory ($capa-root/tests/data or supplied via --samples)
      WARN: rule format incorrect: use scripts/capafmt.py or adjust as follows

Please address these failures and run the linter locally before requesting another review. Also, add the referenced test file to capa-testfiles and move your rule to the corresponding folder listed in the namespace field. Otherwise, remove the examples field and leave the rule in the nursery folder.

[Still34]

Just to clarify, there is almost always at least one reason why I'm not putting a rule directly into the folders corresponding to the namespaces at the beginning of each PR. I'm not risking potentially shipping a rule that doesn't get careful approval before putting them in there for two reasons a) there is a possibility that the namespace is inappropriate for the type of rule b) it hasn't been tested well enough in ITW samples (i.e., lesser confidence).

Per README,md,

We encourage contributors to create rules in the nursery, and hope that the community will work to "graduate" the rule once things are acceptable.

Additionally, for this specific rule, currently other Defender-related detection, as well as other impact/features rules sit under the same directory as well.

Just to confirm, would you like me to move it to the respective folder still?

[Still34]

There also appears to be something wrong with the capafmt linter. Whenever I attempt to lint the description field, it'd want to move it under authors with the incorrect indentation - which is not the case for other rules with the identical field.

py -3 ..\capa\scripts\capafmt.py -i nursery/register-windows-security-center-product.yml

results in the commit b8c5ea7

[Still34]

Discovered the cause: for some reason, the namespace impact/features causes the capafmt to break. Changing the namespace to impact or anything that doesn't contain features fixes it. This might warrant an investigation for why this bug occurs?

[Still34]

Root cause has been found. This PR is currently blocked by the other newly created issue unless a new namespace for this rule is proposed, or we omit the description field.