Having all controls be `impact 1.0` or `impact 0.0` makes the data less than useful

[aaronlippold]

thinking out loud 💭

We should look at making them go into at least 2 or 3 buckets? .3 .5 .9 would make sense to me but if they are all 0.0 and 1.0 then it doesn't really tell me anything right?

Further, in the operational setting, the data point 0 and 1 are usually reserved for the extreme cases - i.e. Not Important / Ignore and "Totally Critical - remove the system from the network". If this isn't the case again - those values start to loose any meaning and will be ignored.

[atomic111]

@aaronlippold yes i agree, but the CIS Benchmark has just the two things: scored and not scored. that is the reason why i did just impact 0 and 1. Do you have any proposals?

[aaronlippold]

@atomic111 @rx294 My team and I just had a conversation about this with respect to the cis-aws-foundations-benchmark. My thinking was with respect to the goal or intention of the impact in an InSpec control and CIS, we think that the intention of impactwould be best served with:

• 'Not Scored' == impact 0
• Level 1 == impact: .4 ( roughly a 'low' )
• Level 2 == impact: .7 ( roughly a 'high' )

However, I think that in general we want to keep away from 1 and 0 cases as they should be reserved for special processing cases.

For example, in our work - when a control is 'Not Applicable' in a security control selection sense or a control is 'Inherited' ( the operational responsibility of some other group or system ) we "override" the base control with impact: 0 and change the description: to be the justification for the change.

For impact: 1 this would be a 'critical' control that is a hard stop for the system under evaluation.

[atomic111]

@aaronlippold thanks for the input. but the score should be level 1 == impact 1, because those are the basics and level 2 is a nice add on.