Thanks for cross-posting, this is quite interesting. Responses inline.
On Tue, Aug 15, 2017 at 12:52 PM, Shawn Wells <[email protected]> wrote: > > > On 8/14/17 6:49 PM, Ed Brown wrote: > > More notes regarding the "DISA-aligned" STIG in RHEL-7.4, fwiw. > > Despite the poor quality of what is to be found (or not found) in the > > DISA STIG, our case to auditors recently for using SSG was weakened by > > a few mostly minor problems (as if a case even needs to be made in the > > absence of any alternative except manual checks.) Sorry if these are > > discussed or documented somewhere, haven't had time to research > > everything in depth, and operator error is always a possibility... > > > > > Feedback like this is invaluable. Cross posting to the SSG list as both > communities are interested in this kind of info. > > > > > > > > discrepancies between SSG and DISA STIG (v1r2) > > ------------------------------------------------------- > > - RHEL-07-021350 Enable FIPS Mode is a 'medium' in SSG, a Cat I > > (high) in the DISA STIG > > PR submitted and should get merged upstream in a day or two: > https://github.com/OpenSCAP/scap-security-guide/pull/2251 > > This is technically dependent on the FISMA level of the system and should not be set at a blanket CAT I without a FISMA target assessment. There is already guidance for this. > > > > > - RHEL-07-010320 (medium) pam faillock unlock_time is 'never' in SSG, > > '604800' in DISA STIG > The requirement is to permanently lock the account after an amount of > failed logins. In prior versions of RHEL this was not possible, with > 604800 being the maximum time a lockout could have. > > NSA opened a formal feature request for account locks never to expire: > https://bugzilla.redhat.com/show_bug.cgi?id=1273373 > > And that shipped in RHEL 7.3: > https://access.redhat.com/errata/RHBA-2016:2314 > > DISA has been saying they'll update their guidance in their next > quarterly update for about a year now. > Honestly, this is an abysmal idea overall. The SIMP project went with a default setting of 15 minute auto-unlock for users and a 1 minute unlock for root by default. This can be easily re-aligned to the STIG but this is one of the highest costs to help desks across the board and I *really hope* that someone notices that accounts are getting locked out after 15 minutes constantly (I mean, what scanner is going to hang around for another 15 minutes?). The actual risk assessment on this should have been more reasonable. Also, nobody can login to our systems as 'root' by default anyway so that's more of a non-issue. > > > - RHEL-07-040500 (low) ntp maxpoll, SSG says to set to '17' (!?), '10' > > in DISA STIG (the default anyway). Also, could the check accept > > maxpoll on 'server' lines in ntp.conf (as opposed to only on a line by > > itself)? > PR submitted: > https://github.com/OpenSCAP/scap-security-guide/pull/2252 > > > > (note: just happened across the above discrepancies, not a result of > > an item-by-item comparison...) > > > > - There are about 199 tests in SSG, 234 in DISA STIG. > > > > > > > false positives > > ---------------- > > - RHEL-07-010010 Verify RPM Permissions (High): > > - failing on all servers in FIPS mode, even though the manual test > > returns no results (rpm -Va |grep '^.M') > > - failing on physical servers (HP Proliant) in UEFI mode: files > > belonging to shim-x64 in /boot/efi are all 700, and rpm --setperms > > doesn't change them. They are 644 on non-uefi systems. (The > > "not-a-finding because permissions are more restrictive" argument is a > > little tenuous because of the added execute permission.) > > Can you open a ticket on this? Ideally a formal support case, because > that carries SLAs: > https://access.redhat.com/support/cases/#/case/list > > Or upstream -- but note, GitHub carries no SLAs: > https://github.com/OpenSCAP/scap-security-guide/issues/new > Honestly, a truth table needs to be put in place for "or better" and there needs to be room for exceptions. 700 is fine because...you're root and, unless you've got MLS enabled, well...root is root. > > > > - RHEL-07-020900 (medium) Device Files with device_t: fails on VMware > > guests for /dev/vmci. SSG output notes that if this fails, it's a bug > > to be reported. But a note here ( > > https://github.com/OpenSCAP/scap-security-guide/blob/ > master/shared/references/disa-stig-rhel7-v1r1-xccdf-manual.xml > > ) says the device_t label is required to operate. > Definitely open a case with RHT on this one. > > > > > - RHEL-07-020610 (medium) Create home directories for new users - > > inexplicable false positive across all servers tested, manual check > > succeeds. ("CREATE_HOME" is "yes" in /etc/login.defs) > > Took a look at the OVAL, but wasn't immediately apparent what could be > causing that. Please open a ticket. > This should also check to see if pam_oddjob_mkhomedir is present in the PAM stack. It's a *much* more reliable method for ensuring that users end up with a confined home directory. > > > > > > other > > ----- > > - RHEL-07-030630 (medium) - problems with the auditd config > > remediation for setuid/setgid programs, but saw mention somewhere that > > this is a known issue in SSG (and of course DISA STIG has a very > > broken check and 'slightly' broken fix) > Those rules get remediation on my side: > > > Title Ensure auditd Collects Information on the Use of Privileged > > Commands - sudoedit > > Rule > > xccdf_org.ssgproject.content_rule_audit_rules_privileged_ > commands_sudoedit > > Ident CCE-80402-1 > > Result fixed > > > > Title Ensure auditd Collects Information on the Use of Privileged > > Commands - newgrp > > Rule > > xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_newgrp > > Ident CCE-80403-9 > > Result fixed > > > - The opaqueness of the actual checks in xml files (as opposed to the > > suggested check in the help text) is frustrating. Over and over again > > during prep we wanted to know: what is the scan doing, why is it still > > failing? It's hard to follow the linked tests and logic in the xml > > file, and wasn't sure what engine is used for regex evaluation. A > > verbose or debugging mode would help a lot. > > You might be missing "--oval-results" from your execution: > $ sudo oscap xccdf eval --profile > xccdf_org.ssgproject.content_profile_stig-rhel7-disa --report > /var/www/html/stig.html --oval-results ssg-rhel7-ds.xml > > That will pull in the details like "found object XYZ in $file but was > looking for ABC." > > > > > - From the auditor's point of view, the ability to create categorized > > "checklists" or results would be a plus, a capability they like in > > StigViewer from DISA (where items can be marked "not reviewed", "open" > > (fail or finding), "not a finding" or "not applicable". > In theory, STIGViewer is supposed to take SCAP results. Might try > generating an ARF report and importing into STIG Viewer to see what > happens. > I have been unable to find formal specifications for DISA "checklists". Am I missing something? I can't sign my project up to using something that I need to reverse engineer. > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide@lists. > fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave@ > lists.fedorahosted.org > Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
