Marek - Thanks for the pointers. I was able to download the scap-workbench and make the mod to allow the admin user. Very nice.
I also noticed that the "OVAL details" in the workbench report showed what the rule was looking for - very helpful addition to the reports. Best regards, Ken From: Marek Haicman <mhaic...@redhat.com> Sent: Friday, July 15, 2022 5:52 PM To: Hatten, Kenneth <kenneth.hat...@zigabyte.com> Cc: open-scap-list@redhat.com Subject: [EXTERNAL] Re: [Open-scap] oscap use: finding specific remediation is obscure to me CAUTION: This email originated from outside of the organization. Verify the sender before clicking links, downloading attachments, or performing any requested tasks. Hello Kenneth, On Fri, Jul 15, 2022 at 9:22 PM Hatten, Kenneth <kenneth.hat...@zigabyte.com<mailto:kenneth.hat...@zigabyte.com>> wrote: Folks - I'm trying to remediate a RHEL7 VM guest and have it down to a couple findings that I'd like to ask about: 1. Rule ID: xccdf_org.ssgproject.content_rule_accounts_authorized_local_users I've surfed the web, RedHat and OpenScap; read through the OpenScap docs. I have not found how to apply a remediation to this one. The server has one (1) user that is not part of the OS installation set - an admin acct. How do I tell oscap that this account (and perhaps others later) is an authorized account? This rule is using a variable to define authorized users ( var_accounts_authorized_local_users_regex ). You can create a tailoring - alter the contents of the variable for example using SCAP Workbench, and add whatever user you consider authorized. I guess in your case it will be an addition of admin acct. 2. Rule ID: Ensure Software Patches Installed The system was fully patched with "yum update" before I ran oscap. There are currently seventeen (17) findings which specify running "yum update". I enabled all repos in /etc/yum.repos.d/redhat.repo and ran check-update repeatedly to find those that were not accessible, and disabled them. That left 896 potential yum repos being used. Then, I patched again and "yum update" shows NO patches outstanding. Yet the STIG still says I have seventeen (17) failures, with no indication of what has failed and the remediation advice given is "yum update". Is there a way to see EXACTLY what it is failing at, aka the raw output data, where I can review output like: "This specific package is not updated, therefore mark a FAIL" ? The `oscap xccdf eval` HTML report unfortunately does not handle it that well, that's for sure :) At the start of the stdout, you can observe: ``` Downloading: https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fsecurity%2Fdata%2Foval%2Fcom.redhat.rhsa-RHEL7.xml&data=05%7C01%7Ckenneth.hatten%40zigabyte.com%7C237f7f202cd84c49d78008da66b4a59c%7C5f2d630ecdea4cfda145e634cbd11dec%7C0%7C0%7C637935223326380872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d%2BjGedF2VGhwS%2BMzQ3YLGlTm4GLWrP8l%2Fl5w9ZSqRFI%3D&reserved=0> ``` this is the remote resource you are fetching with `--fetch-remote-resource` and it is the source of the Ensure Software Patches Installed check. If you want detailed report what's wrong, you can wget it, and run oscap in the oval format: ``` # wget https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fsecurity%2Fdata%2Foval%2Fcom.redhat.rhsa-RHEL7.xml&data=05%7C01%7Ckenneth.hatten%40zigabyte.com%7C237f7f202cd84c49d78008da66b4a59c%7C5f2d630ecdea4cfda145e634cbd11dec%7C0%7C0%7C637935223326380872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d%2BjGedF2VGhwS%2BMzQ3YLGlTm4GLWrP8l%2Fl5w9ZSqRFI%3D&reserved=0> # oscap oval eval --report vuln_rep.html com.redhat.rhsa-RHEL7.xml ``` in this report, you will be able to click on the particular RHSA which should cover the failing rule. I have two guesses why there are failures in your scan - you have some older, vulnerable kernel versions installed. The scan will fail even if the kernel is not in use, but is installed. If you remove all kernel versions but the latest one, many failures should vanish - your VM is not 7.9, but some older long support release. The OVAL referenced by the STIG in that case is not precise and will report false positives. If that's the case (and you run for example 7.7), run the scan separately with the content downloaded from https://www.redhat.com/security/data/oval/v2/RHEL7/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fsecurity%2Fdata%2Foval%2Fv2%2FRHEL7%2F&data=05%7C01%7Ckenneth.hatten%40zigabyte.com%7C237f7f202cd84c49d78008da66b4a59c%7C5f2d630ecdea4cfda145e634cbd11dec%7C0%7C0%7C637935223326380872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MsxlMB9iKnApfAZyRdMvkhR%2BEz6Hax9pF6xmIqoROlU%3D&reserved=0> and ignore rule in the STIG scan (you can even remove it from the scan with the SCAP Workbench. Hope it helped a bit :) Marek In case I am doing the scan wrong, these are the commands I am using to execute the oscap run: DateR=`date '+%m%d%y_%H%M%S'` UNAMEN=`/bin/uname -n` oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig \ --report report_${UNAMEN}_${DateR}.html \ --fetch-remote-resources /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml The latest scan this morning, following the latest patch and reboot is 93.63% clean. There are just five (5) areas still reporting a fail and the two referenced above are the only ones I am unable to resolve readily. I would appreciate any assistance you can provide. Best Regards, Kenneth Hatten Senior Consultant [http://zigabytepublic.s3.us-east-2.amazonaws.com/Zigabyte_Transparent.png]<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zigabyte.com%2F&data=05%7C01%7Ckenneth.hatten%40zigabyte.com%7C237f7f202cd84c49d78008da66b4a59c%7C5f2d630ecdea4cfda145e634cbd11dec%7C0%7C0%7C637935223326380872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y7GOg3vSAM2aCIxE83QCRs44aK0zMngepMdCI7mfR%2Bk%3D&reserved=0> | Character | Competence | Community email: kenneth.hat...@zigabyte.com<mailto:kenneth.hat...@zigabyte.com> cell: 972-658-1275 _______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com<mailto:Open-scap-list@redhat.com> https://listman.redhat.com/mailman/listinfo/open-scap-list<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistman.redhat.com%2Fmailman%2Flistinfo%2Fopen-scap-list&data=05%7C01%7Ckenneth.hatten%40zigabyte.com%7C237f7f202cd84c49d78008da66b4a59c%7C5f2d630ecdea4cfda145e634cbd11dec%7C0%7C0%7C637935223326380872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FXopmj9CPHz%2BWyjOjcvi3e8g%2FLPcBfLj7QWfm49rKfI%3D&reserved=0>
_______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://listman.redhat.com/mailman/listinfo/open-scap-list
