Hello Ben,
part of the rule metadata are references - see e.g. the
audit_rules_dac_modification_setxattr rule from the RHEL8 PCI-DSS
profile:
https://static.open-scap.org/ssg-guides/ssg-rhel8-guide-pci-dss.html#xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_setxattr
The rule is part of implementation of many security
controls/requirements. We also produce tables of references, when you
build the ComplianceAsCode content locally, you can find the
human-readable reference->rule mapping e.g. in the
build/tables/table-rhel8-pcidssrefs.html file.
However, neither of those forms of referencing is user-friendly wrt your
use case. Coincidentally, we have started thinking about introducing
another entity to take part in profiles definition - right now, we
define profiles as list of selected rules and parametrizations. We are
considering to use security controls - rules would implement security
controls, and security controls (plus maybe a couple of extra rules)
would implement a profile. Having the concept of security controls
emphasized in the build system would allow us to produce tables that are
grouped in a smarter way, as well as a better overview of what security
controls exist but are not implemented by the profile, or what controls
are not SCAP-applicable at all.
Therefore, stay tuned, and consider subscribing yourself to the
scap-security-gu...@lists.fedorahosted.org mailing list, as discussions
about this new feature may start there as soon as in March. However,
there is still a relatively long way to go from support in the build
system to useful output data - consider this more a marathon run than a
sprint.
HTH,
Matej
On 04. 03. 20 15:18, Benjamin P Segal wrote:
Hi all,
We've been exploring the SCAP security guide for various platforms,
their policies, and within policies, their provided profiles which
might include PCI-DSS, HIPAA, various NIST control baselines, DISA
STIGs, among many others.
Given these different profiles/baselines have been created from
guidance by the respected authorities, is there a direct way to assess
the "gap" in terms of meeting the appropriate standards/regulations
within an enterprise adhering to and enforcing the SCAP baseline(s)?
Or put another way, and in direct reference to PCI-DSS v3.2.1 for the
sake of a concrete example, PCI-DSS contains about ~260 controls
comprising a combination of people, processes, and technologies. For
the technical controls, I see that SCAP provides a lot of these
logical assertions/remediations in RHELx. But there are also technical
controls around (e.g.) dynamic penetration testing and collection of
various logs for evidence for audit which is beyond the scope of SCAP.
Is there an easy way to, say, extract the PCI-DSS controls that have
particular SCAP rules to cover them, vs. those that aren't covered, to
more easily build out a plan for covering full compliance at an
enterprise level?
Thank you for your time, in advance.
-Ben
_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list
_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list
