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/refere...
) 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.