ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.22k stars 697 forks source link

[RFE] Add ability to specify list of concrete profiles that should be included in the produced benchmark #871

Closed iankko closed 8 years ago

iankko commented 8 years ago

Will describe current situation for RHEL/6 product below (the situation for other products is similar / analogous). As of right now the determination which profiles, available for the specific product, will be included in the produced benchmark is performed by specifying the list of profiles to be included in the: <product>/input/guide.xslt XSLT transformation.

The current form of this file for RHEL/6 product (listing only issue interesting part of this transformation):

       <!-- adding profiles here -->
                <xsl:if test=" number($withtest) = number(0) ">
                        <xsl:apply-templates select="document('profiles/test.xml')" />
                </xsl:if>
                <xsl:apply-templates select="document('profiles/CS2.xml')" />
                <xsl:apply-templates select="document('profiles/common.xml')" />
                <!-- <xsl:apply-templates select="document('profiles/desktop.xml')" /> -->
                <xsl:apply-templates select="document('profiles/server.xml')" />
                <!-- <xsl:apply-templates select="document('profiles/ftp.xml')" /> -->
                <xsl:apply-templates select="document('profiles/stig-rhel6-server-upstream.xml')" />
                <xsl:apply-templates select="document('profiles/usgcb-rhel6-server.xml')" />
                <xsl:apply-templates select="document('profiles/rht-ccp.xml')" />
                <xsl:apply-templates select="document('profiles/CSCF-RHEL6-MLS.xml')" />
                <xsl:apply-templates select="document('profiles/C2S.xml')" />
                <xsl:apply-templates select="document('profiles/pci-dss.xml')" />
                <xsl:apply-templates select="document('profiles/nist-CL-IL-AL.xml')" />

Since during the build process it might be desired the users building the content to be able to specify the final list of profiles to be included in the benchmark, the build process should be modified / enhanced to allow this functionality.

The expectation being issuing a build command like the following: make content PROFILES=C2S, desktop,usgcb-rhel6-server

(IOW calling make content target with `PROFILES=`` variable set to list of profile ids, split by comma)

would produce a benchmark containing only these profiles included.

Side note:

iankko commented 8 years ago

Taking this one (unless someone bits me to it), I will implement this change somewhere during next month.

mpreisler commented 8 years ago

Do we have a use-case for this that's common enough to warrant the extra complexity? I think we shouldn't implement this at all.

redhatrises commented 8 years ago

I agree with Martin on this. What is the use case?

iankko commented 8 years ago

@mpreisler

Do we have a use-case for this that's common enough to warrant the extra complexity? I think we shouldn't implement this at all.

Suppose a use case when independent / 3-rd party certification authority is requesting to provide the benchmark in the form it to contain one concrete profile (they don't want to see the overall form of the default benchmark. They just want to see how the benchmark looks like for one concrete profile).

Another use case might be federal / government vs business environment company orientation. The former might want just the federal requirements included (e.g. USGCB, DISA STIG etc.) , the latter just the business requirements included (e.g. PCI DSS).

As the count of the available profiles per product will raise, IMHO it's just question of time, when this request will be officially expressed by the users.

Also, the implementation of this feature won't change the default benchmark form -- we would still include the all possible profiles into the benchmark when building the checklist for official distribution.

But would just provide a way how to create a restricted benchmark, when desired.

mpreisler commented 8 years ago

Suppose a use case when independent / 3-rd party certification authority is requesting to provide the benchmark in the form it to contain one concrete profile (they don't want to see the overall form of the default benchmark. They just want to see how the benchmark looks like for one concrete profile).

Can't we just cut it out manually and not have this additional complexity? It's easy to do and this action doesn't need to be performed often.

I haven't heard any user complain that we have too many profiles :-)

iankko commented 8 years ago

@mpreisler

Can't we just cut it out manually and not have this additional complexity? It's easy to do and this action doesn't need to be performed often.

Noticed, there oscap provides something like xccdf generate custom --stylesheet transform.xslt --profile ID --output_file new_xccdf.xml. Will try that one instead of changing SSG build process (since it's less work :)).

I haven't heard any user complain that we have too many profiles :-)

Hopefully not yet (because as of right now there truly aren't that many of them). But /me hopes to we to reach this state one day :).

Thanks!