mitre / saf

The MITRE Security Automation Framework (SAF) Command Line Interface (CLI) brings together applications, techniques, libraries, and tools developed by MITRE and the security community to streamline security automation for systems and DevOps pipelines
https://saf-cli.mitre.org
Other
133 stars 37 forks source link

xlsx2inspec doesn't map CIS to NIST tags properly #91

Open ejaronne opened 2 years ago

ejaronne commented 2 years ago

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:

image

wdower commented 2 years ago

@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:

  tag cis_controls: [
    { 6 => [5.1] },
    { 7 => [5.2] }
  ] 

If the same control had more than one cis_control aligned to the same revision number, it would be something like:

  tag cis_controls: [
    { '6' => ['5.1'] },
    { '7' => ['5.2', '5.3'] }
  ] 

etc.

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.

  tag nist: ['AC-6 (9)', 'CM-2']
camdenmoors commented 2 years ago

This requires updated mappings for CIS to NIST controls