Full Scapolite example of a Compliance-as-Code Security Guide (RHEL 8) published on github.com

[B Grobauer]

Dear all,

following the discussion during the SCAPv2 workshop a month ago, I have made available one more complete example of what SCAP content would look like

when authored and maintained in Scapolite, this time using the Compliance-as-Code guide for RHEL8. The Scapolite conversion

is available from

https://github.com/scapolite/example_c_as_c_guide_rhel_8_relase_0_1_44

Compliance-as-Code makes heavy use both of OCIL and of implementation mechanisms (bash and Ansible). The current import

basically mirrors the SCAP-version, except that non-XCCDF content has been either broken up (OVAL and OCIL) or

factored out (sh/ansible/anaconda content) and stored alongside the  file containing the rule.

A evolvement of Scapolite should, of course, do things differently, where things can be improved. For example, for lack of a better
mechanism, in its SCAP export, Compliance-as-Code stores shared shell-scripts using XCCDF-values, which currently
is mirrored 1:1 in the Scapolite-conversion. Obviously, a dedicated mechanism would be preferable.

Also, OCIL as used in the guide (basically, a yes/no question that always leads to either passing or failing the text)  just begs for a
mechanism that allows the inclusion of the question within the rule-file and generating this rather simple piece of OCIL ---

comparable to what ComplianceAsCode have indeed done in their rule-file format:

~~~

	ocil_clause: 'the package is not installed'
	ocil: '{{{ ocil_package(package="psacct") }}}'

 

~~~

... but maybe not quite as succint, since this much brevity very much depends on a custom  build-tool chain; one could;

however, think of specifying a templating-mechanism, making explicit what Compliance-as-Code's build chain
does implicitly.

Compliance-as-Code also has other short-hands, which currently are not available in Scapolite. 

Another example: ComplianceAsCode specifies cross-references much more succinctly: 

~~~

references:
	nist: AU-12,CM-7
	nist-csf: DE.CM-1,DE.CM-3,DE.CM-7,ID.SC-4,PR.IP-1,PR.PT-1,PR.PT-3
	isa-62443-2013: 'SR 1.1,SR 1.10,SR 1.11,SR 1.12,SR 1.13,SR 1.2,SR 1.3,SR 1.4,SR 1.5,SR 1.6,SR 1.7,SR 1.8,SR 1.9,SR 2.1,SR 2.10,SR 2.11,SR 2.12,SR 2.2,SR 2.3,SR 2.4,SR 2.5,SR 2.6,SR 2.7,SR 2.8,SR 2.9,SR 6.1,SR 6.2,SR 7.6'
	isa-62443-2009: 4.3.2.6.7,4.3.3.3.9,4.3.3.5.1,4.3.3.5.2,4.3.3.5.3,4.3.3.5.4,4.3.3.5.5,4.3.3.5.6,4.3.3.5.7,4.3.3.5.8,4.3.3.6.1,4.3.3.6.2,4.3.3.6.3,4.3.3.6.4,4.3.3.6.5,4.3.3.6.6,4.3.3.6.7,4.3.3.6.8,4.3.3.6.9,4.3.3.7.1,4.3.3.7.2,4.3.3.7.3,4.3.3.7.4,4.3.4.3.2,4.3.4.3.3,4.3.4.4.7,4.4.2.1,4.4.2.2,4.4.2.4
	cobit5: APO10.01,APO10.03,APO10.04,APO10.05,APO11.04,BAI03.05,BAI10.01,BAI10.02,BAI10.03,BAI10.05,DSS01.03,DSS03.05,DSS05.02,DSS05.04,DSS05.05,DSS05.07,DSS06.06,MEA01.01,MEA01.02,MEA01.03,MEA01.04,MEA01.05,MEA02.01
	iso27001-2013: A.12.1.2,A.12.4.1,A.12.4.2,A.12.4.3,A.12.4.4,A.12.5.1,A.12.6.2,A.12.7.1,A.14.2.2,A.14.2.3,A.14.2.4,A.14.2.7,A.15.2.1,A.15.2.2,A.9.1.2
	cis-csc: 1,11,12,13,14,15,16,2,3,5,6,7,8,9 ~~~

The syntax of Scapolite would have to be changed so as to accept more than one reference per reference system; further, one would have to think whether a standard set of short-hands for the most important reference systems 
should be defined rather than always specifying a longish URN/URI.

In short: a balance between brevity one one hand and mechanisms that work in general

rather than for a specific use case / build chain would have to be found in order to evolve Scapolite

into something that would also be useful for Compliance-as-Code.

Kind regards,

Bernd