Add additional metadata to the control definition to allow for more complete mapping to security guidance documents

[aaronlippold]

I would like to propose that we add four additional non-required elements to the control to enhance the ability for chef compliance profiles to be more fully mapped to existing security guidance policies. Security guidance documents group elements and security concerns by larger meta groups - such as Authentication or Access Control. The guidance then decomposes those areas into more specific actions with respect to the target platform and application - to keep track of each of these specific actions they create an Index and an Identifier.

The four additional elements are:

• severity: {critical, high, medium, low,nil} - non-required or required if impact is nil.
  Most if not all security guidance documents still use this mapping to group control elements. I agree that impact also gives similar information but it is more granular than most existing guidance. This may be deprecated in 2.x or when the shift that CVSS and CIS policies are trying to move standard practice to using a 1-10 scale because agreed on by the community.

  Having both impact and severity can be useful, if you make the assumption that that L => .01 - .03 ; M => .04 - .06, H => .07 - .09, C => 1, then, when you print out reports and risk, you have a way to way that these High items are more important than those High, etc. etc.

  severity: nil will actually cover two uses:

  1. Can indicate that we have decided that we want that control to have no impact on the compliance standing - i.e. an 'accepted risk' or 'not applied' control. This happens sometimes when enforcing the control would impede the larger systems function or we don't want to enforce the control at this time but we still want it in the process.
  2. Can map to controls that are in the profile but can't be check programmatically - i.e. you will have security documents.

• identifiers: {a, b, c} - non-required, text, comma separated ( there could be spaces in the name)
  These identifiers are intended to be unique tags or keys, not descriptive names. By way of a loose analogy, CCE-IDs are like scientific names for animals, providing a precise identifier for a species that is agreed upon by the technical community but which may have little or no meaning in common language usage. see: https://cce.mitre.org/lists/cce_list.html

• controls: {a, b, c} - non-required, text, comma separated
  Identify the specific high level 'spirit' of the security issue being addressed. This is very important to be able to map back to the implementation because the Security Control officer or Approving Authority thinks at this level - they want to know did you cover all required controls not the details. see: https://web.nvd.nist.gov/view/800-53/Rev4/home

• references: {a, b, c} - non-required, text, comma separated ( there are spaces in the items)
  This is a list of where the security policy guidance - usually documents - references the control you are writing. This allows us to easily provide traceability and show completeness of the chef compliance policy for security guidance or set of guidance. For example, the NSA guidance, the DOD Guidance and the CIS guidance all have 95% of the same elements however their identifiers are different - since we have both references and identifiers in the control we can easily streamline the amount of compliance content we write because we can show - programmatically - that we covered everything in each document.

Take for example the use case of a basic Web/DB server, that applied three policies to – the OS policy, the Web Server Policy and the DB Server Policy – each would have controls that covered User Management and Access Control. The Identifiers would be different in each policy ( a unique index ) however, the Control References ( AC* and IC* etc. ) which deal with the same “spirit of the idea” i.e – you should use complex passwords – would be the same.

Below is an example of this applied to an SSH Config:

control 'sshserver-06' do
  impact 1.0
  severity: critical
  title 'Server: SSH daemon must be configured to use only
        Protocol (SSHv2) connections allowed'
  desc 'Set the SSH protocol version to 2. SSH protocol version 1 suffers
           from design flaws that result in security vulnerabilities
           and should not be used.'
  identifier 'CCE-27072-8'
  identifier 'CCI-000774'
  control 'AC-17(7)'
  control 'IA-5(1)(c)'
  reference 'NSA-RH6-STIG - Section 3.5.2.1' 
  reference 'DISA-RHEL6-SG - Section 9.2.1'

  describe sshd_config do
    its('Protocol') { should eq('2') }
  end
end

[aaronlippold]

updated the example code per feedback from Galen

[arlimus]

We had a great discussion in Gitter/WebConf on tuesday, here's the outcome: We should opt for generalized tags and references with the following syntax:

ref 'reference by name or title'
ref 'another reference', url: 'http://...'
ref url: 'http://...'

tag 'simple tag'
tag key: value

for the use-case reported by @aaronlippold this could then be implemented as:

tag nist: 'AC-17(7)'
tag nist: 'IA-5(1)(c)'
tag CCE: '27072-8'
tag CCI: '000774'

all tags and references can then be exposed via the API and become fully searchable and have some nice views and links in reports and the UI.

Thank you @aaronlippold @kdshah1 and @chris-rock for the talk this week and everyone else who contributed to the question via mail!! 😄

It would be great to have another round on the severity and impact points you posted, let's follow this up in a separate thread and get some of the points here implemented.

[aaronlippold]

title 'SSH Server Configuration'

control 'ssh-1' do
    impact 1.0
    tag severity: 'high'

    title 'Allow only SSH Protocol 2'

    desc 'Only SSH protocol version 2 connections should be permitted. 
          The default setting in /etc/ssh/sshd_config is correct, and can be 
          verified by ensuring that the following line appears: Protocol 2'

    tag 'production','development'
    tag 'ssh','sshd','openssh-server'

    tag cce: 'CCE-27072-8'
    tag disa: 'RHEL-06-000227'

    tag nist: 'AC-3(10).i'
    tag nist: 'IA-5(1)'

    tag cci: 'CCI-000776',
    tag cci: 'CCI-000774'
    tag cci: 'CCI-001436'

    tag remediation: 'stig_rhel6/recipes/sshd-config.rb'
    tag remediation: 'https://supermarket.chef.io/cookbooks/ssh-hardening'

    ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf' 
    ref 'DISA-RHEL6-SG - Section 9.2.1', url: 'http://iasecontent.disa.mil/stigs/zip/Jan2016/U_RedHat_6_V1R10_STIG.zip'
    ref url: 'http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/ssg-centos6-guide-C2S.html'

    describe ssh_config do
        its ('Protocol') { should eq '2'}
    end
 end

[arlimus]

This looks great ^^
We'll have a rerun on severity later on, but tag + ref is great :)

[aaronlippold]

+1, agreed. I know severity may be old / deprecated lingo but just keeping it in the conversation scope until we have a way / path on where we will go with it.

[aaronlippold]

+1

[aaronlippold]

added a corner case where the nist value can have '.' and 'i...' in it from some of the older 800-53 revisons.

[chris-rock]

I am not convinced of

ref url: 'http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/ssg-centos6-guide-C2S.html'

From my perspective, it reads easier if we use:

ref 'http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/ssg-centos6-guide-C2S.html'

[aaronlippold]

I agree. That was just me using the same pattern that we used before. But Dom and I agreed that just a simple key value works there.

[aaronlippold]

We have a gist link we have been pushing on. Let me find there link.

[aaronlippold]

The gist link with these test file is in the chat room.

[chris-rock]

Just for reference, the discussed gist is available here: https://gist.github.com/aaronlippold/dbe6701085dafadfaa7f

[arlimus]

Thank you everyone and have fun testing it! 😄

[arlimus]

@aaronlippold i'll open a separate issue in time to talk about severity and impact :)

[aaronlippold]

OK. Happy to talk the issue. Shouldn't be hard to come to the right solution.