This sounds roughly like reinventing OSCAL. On Fri, Mar 6, 2020 at 11:35 AM Matěj Týč <ma...@redhat.com> wrote:
> 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 > listOpen-scap-list@redhat.comhttps://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 -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
