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
>
> - 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.
> - 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
>
> - 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.
>
>
> 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.
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org