maester365
First CIS test
A few discussion points on these
- Any concern with nesting the CC license for these, see docs page?
- Links reference to CIS' download link as to not redistribute unnecessarily.
- This is pretty close to other tests, concerns with multiple cmdlets running essentially the same test?
Since we use caching, it shouldn't add too much of an overhead.
I think including the CC License here should be okay. Doesn't CIS have a program for apps like ours and vendors to register with them?
Doesn't CIS have a program for apps like ours and vendors to register with them?
I see their marketplace, and they have their communities, but not sure about OSS that leverages their benchmarks or controls. Were you thinking of something different? https://www.cisecurity.org/services/cis-cybermarket
Suggestion re the folder name. CIS versions change fairly often and when they update it it usually includes major updates to the check identifiers etc. I think it would make sense to include the version and the benchmark name in the folder name to make it clear which CIS benchmark it is checking against. My suggestion would be something like cis-365-v3.1.0.
Additionally, I am interested in thoughts on adding the CIS control identifier to the test name. IE the example is Test-MtCisCloudAdmin.Tests.ps1 but this doesn't instantly show you which CIS control it maps to (until you open the file and read the tags). I realise it deviates slightly from the current naming conventions but if we included the control version like Test-MtCisCloudAdmin-cis-1.1.1.Tests.ps1 or something similar, it would be easier to retrospectively work out which test is which.
Agree, even with the CISA tests I struggle to find the mapping cmdlet, but I also don't like including numbers and version in the cmdlet and file name.
I see two options.
Option 1: Change the file name to include the test and version number but the cmdlet itself does not have the test and version number.
Option 2: Create a folder for each with the test and version number but the .ps1 filename and cmdlets have the name without the test number.
Thoughts @Snozzberries @f-bader
Option 2 is in my opinion the better way to go. But then we would have to deal with same names and how to choose the correct one.
Having multiple options within one function and use an parameter might also be possible. But when big changes happen it might break.
If its any consolation, the way I have done it previously is to create a folder for the CIS checks which includes the version number, something like CISv3.1.0 and then I renamed the test files sitting within that folder with the name of the CIS check, something like 1.1.1.Tests.ps1, but the function itself and the name of that file stays in the normal format like this Test-MtCISGlobalAdminCount.
The advantage of doing it this way, is that some of the cmdlets cross over, for example for CIS 1.1.1 you can use Test-MtCisaCloudGlobalAdmin.
Full example test:
tests/cis/CISv3.1.0/1.1.1.Tests.ps1
Full example cmdlet:
powershell/public/cis/Test-MTCISAntiPhishingPolicy.ps1
not a contributor here but have been waiting for the CIS controls to be incorporated. as a msp i see a lot of value in using a tool like this across our customer base to provide CSPM.
Full example test:
tests/cis/CISv3.1.0/1.1.1.Tests.ps1Full example cmdlet:
powershell/public/cis/Test-MTCISAntiPhishingPolicy.ps1
I do like this though @f-bader concern is valid.
Having multiple options within one function and use an parameter might also be possible. But when big changes happen it might break.
Part of me is thinking do we just have a CIS for current version or latest supported version by Maester, then allow for an N-1 version support through a switch. So if there was a breaking change it would use that switch. Part of me also just wonders if sticking to only have one supported version, but still tagging in the tests and the test folder structure what that version is would be the simplest.
We could retain the legacy docs too and add a note, of what PR# caused the breaking change. That may make it too big of an update set though.
The more I think about it the more I agree with you. I think we just support one version, but I think it should be clear which version that is in the code as well as the documentation
The more I think about it the more I agree with you. I think we just support one version, but I think it should be clear which version that is in the code as well as the documentation
Added some additional references, but should have the version in each file now.
I have started writing some of the checks, but was short on time this week.
Once this request is merged, I will retest the checks and make a PR for them. Currently working out of https://github.com/NZLostboy/maester/tree/cis-365-v3.1.0
There should hopefully be more of them by then as well
@Snozzberries this is looking good.
There are around 7 Pester tests that are failing and preventing the merge. E.g for naming of some cmdlets etc.
Would you be able to fix them?
Rebase and some cleanup on #416, should be in a better state now @merill, thanks!