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/reference... ) 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.
Thanks for cross-posting, this is quite interesting.
Responses inline.
On Tue, Aug 15, 2017 at 12:52 PM, Shawn Wells shawn@redhat.com 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
scap-security-guide@lists.fedorahosted.org
-
Shawn Wells -
Trevor Vaughan