scap-security-guide July 2020

scap-security-guide@lists.fedorahosted.org

10 participants
6 discussions

Support for SSG checks?
by N B 10 Aug '20

10 Aug '20

Could anyone speak to SSG support for check content written for SCE (vs. OVAL)? The developer's guide (section 7 intro) implies XCCDF check content is not required to be in OVAL, but in fleshing out support for checks later in that section it's hard to see how anything but shorthand OVAL could be supported. If not SCE directly, might it be possible to somehow use raw XCCDF snippets to incorporate SCE check content? I'm on the hook to support some custom content for an internal need, and have found OVAL to be a bit inflexible (unless I want to propose extensions to OVAL itself which is a bit beyond the scope I can take on at the moment). One example is retrieving additional metadata from an RPM beyond what OVAL's rpminfo supports. Admittedly, since my effort is internal, I'm misusing SSG in the sense that I wouldn't be contributing the custom content back to the SSG repo. SSG still offers an excellent framework for my isolated situation though, except that without support for non-OVAL checks, I'm not sure if I can author the content i need with it.

3 6

Approach to allow support of UEFI grub2 for grub2_audit_argument rule
by Andy Coates 03 Aug '20

03 Aug '20

Hi All, First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more. I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path. So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not. If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience. What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something. Thanks! Andy.

4 5

Lets do potentially breaking project changes now
by Matej Tyc 31 Jul '20

31 Jul '20

The PR https://github.com/ComplianceAsCode/content/pull/5606 introduced a large number of changes that may break patches, but those changes were much needed in the project. So I think that we should use this opportunity to introduce more changes, so we introduce only one pair of versions between which things could break, as opposed to breaking many times in a row in the future. So what I think we could consider? - Rename description, rationale to html_description, html_rationale. Reason: We could start to introduce Markdown input, and doing it this way would allow us to do it gradually. We probably want to have html as a canonical form, but we could offer more possibilities for content authors. - Restructure project's folder structure - right now, the list of products is really long, which makes the project page too long. Having products in a separate directory would also allow us to get a list of supported products programmatically from the filesystem. - Put macros where they belong. We have plenty of boilerplate in the project, and macros can keep the code readable and free of duplicates. Moreover, if people use a macro to e.g. instantiate an XCCDF variable, we can change the underlying implementation without breaking the public API. Most of these changes is just about crafting and running a sed command, plus comparing the result before and after - I have in mind large-scale changes that don't require a large amount of time to perform. What do you think? Do you have other suggestions you would add to the list?

4 4

ComplianceAsCode Content 0.1.51
by Vojtech Polasek 17 Jul '20

17 Jul '20

Hello all, ComplianceAsCode/Content 0.1.51 has been released. Among the highlights of this release are: - Add SSG content for McAfee VSEL - Creation of Australian ISM 'Official' RHEL 8 profile - Add RHCOS4 product - Add ubuntu cis profile For full release notes, please have a look at: - https://github.com/ComplianceAsCode/content/releases/tag/v0.1.51 Zip archive with pre-built content: https://github.com/ComplianceAsCode/content/releases/download/v0.1.51/scap-… Zip archive with pre-built content using only OVAL-5.10: https://github.com/ComplianceAsCode/content/releases/download/v0.1.51/scap-… Thank you to everyone who contributed! Happy hardening! -- Vojtech Polasek Associate software engineer, security compliance Red Hat <https://www.redhat.com> vpolasek(a)redhat.com <mailto:vpolasek@redhat.com> <https://www.redhat.com>

1 0

Help needed identifying and correlating rules in SCAP Security Guide for RHEL8 STIG (draft)
by N B 09 Jul '20

09 Jul '20

I'm in the process of upgrading to RHEL8, and need to analyze the STIG rules since my project had waivers in place for some of the rules in earlier RHEL versions. My team would like to use the SCAP Security Guide as the source of our content for scans, and so the plan was to review the rules from the SSG's RHEL8 STIG profile. I thought it would be pretty easy to just get a list of the rules with their ids, titles, and descriptions, but have run into a couple issues. First, I am seeing a lot of differences between the ruleset I can download directly from DISA (their manual xccdf for RHEL8 STIG - draft) and the ruleset in the SSG RHEL8 STIG profile. Figured the titles might not have been brought over from the DISA STIG verbatim, so thought it might be better to align them by identifier, which leads to the second problem... I can't find any identifiers in common between the DISA STIG and the SSG profile. DISA has indicated that STIG IDs (e.g. RHEL-08-010050) are the way to go moving forward, and only provides these ids in their draft STIG. SSG on the other hand, provides CCEs (presumably ones that it generates from a pool allocated by NIST), vul group ids, and sub-vul rule ids, but does not appear to provide the STIG IDs (I've looked in the table-rhel8-nistrefs-stig.html file of the 0.1.50 release and in the scan report from scanning my system). I would appreciate guidance on how to correlate these two sources and ideally where STIG IDs can be found in SSG STIG content since these seem to be DISA's preferred identifier going forward.

4 6

Stabilization of v0.1.51
by Vojtech Polasek 09 Jul '20

09 Jul '20

Hello all, *Release of Content version 0.1.51 is scheduled for July 17th*, so I've created a stabilization branch for it. Now is a good time to hunt for bugs and propose fixes for them. Starting today, merged Pull Requests should be assigned to milestone v0.1.52. As the branch has been created on Wednesday July 8, I will move closed pull requests created after this date to 0.1.52 milestone. Bug fixes should be proposed to master and labeled "bugfix", they will be cherry-picked to the stabilization branch. Best regards, Vojta

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide July 2020