You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many CIS benchmarks cite multiple CIS CSC security controls in their benchmarks. In addition, some cite from different versions of the CIS CSC security controls, often citing a version 6 CSC security control and a version 7 CSC security control in for the same requirement (inspec control). The mappings between CIS and NIST are cited in these two documents, one for version 6 and one for version 7 of the CSC security control families. (Note: a version 6 number can be completely different than the same number in version 7. They heavily restructured and re-used CSC control numbers between versions.)
Currently, this converter only seems to map from one of these 2 spreadsheets for the entire benchmark conversion (seemingly based on version of the first CSC security control encountered, not sure) and only captures the first CSC security control if more than one is listed for a requirement. Consequently, it will incorrectly map a version 6 CSC control to a NIST control from the version 7 spreadsheet, as found with the EKS CIS benchmark spreadsheet.
Please capture all CSC security controls for each benchmark requirement and correctly map using the proper mapping spreadsheet, such as for requirement 4.1.4 below:
The text was updated successfully, but these errors were encountered:
@ejaronne@aaronlippold and I talked about how the cis_controls tag should be recorded in an InSpec control, and agreed on an array of hashes. This is because there are CIS benchmarks that map a single control to cis_controls from different versions. For example, looking at the control 4.1.4 in the above spreadsheet, it has two listed CIS controls, one for each revision 6 and 7. So the InSpec control should tag it with:
The NIST tags should just be an array that is the set of all NIST controls that correspond to each cis_control in the hash array. Don't worry about aligning a particular NIST control to a cis_control.
Many CIS benchmarks cite multiple CIS CSC security controls in their benchmarks. In addition, some cite from different versions of the CIS CSC security controls, often citing a version 6 CSC security control and a version 7 CSC security control in for the same requirement (inspec control). The mappings between CIS and NIST are cited in these two documents, one for version 6 and one for version 7 of the CSC security control families. (Note: a version 6 number can be completely different than the same number in version 7. They heavily restructured and re-used CSC control numbers between versions.)
https://github.com/mitre/inspec_tools/blob/master/lib/data/NIST_Map_09212017B_CSC-CIS_Critical_Security_Controls_VER_6.1_Excel_9.1.2016.xlsx
https://github.com/mitre/inspec_tools/blob/master/lib/data/NIST_Map_02052020_CIS_Controls_Version_7.1_Implementation_Groups_1.2.xlsx
Currently, this converter only seems to map from one of these 2 spreadsheets for the entire benchmark conversion (seemingly based on version of the first CSC security control encountered, not sure) and only captures the first CSC security control if more than one is listed for a requirement. Consequently, it will incorrectly map a version 6 CSC control to a NIST control from the version 7 spreadsheet, as found with the EKS CIS benchmark spreadsheet.
Please capture all CSC security controls for each benchmark requirement and correctly map using the proper mapping spreadsheet, such as for requirement 4.1.4 below:
The text was updated successfully, but these errors were encountered: