[RFC] Manual Profile Use

Spencer R. Shimko sshimko at tresys.com
Mon Aug 13 23:35:40 UTC 2012


On 8/13/12 10:37 AM, "Jeffrey Blank" <blank at eclipse.ncsc.mil> wrote:

>I don't quite follow.  Is this a list of Rules for which no automated
>checking is possible?  Or is it a list of things whose remediation
>cannot be automated?
>
>(Essentially, will this be the set (or subset) of all Rules that cannot
>be expressed in OVAL?)  (Admittedly there are a few that may be
>expressible in the SCE/scripts, but let us avoid that conversation for
>now.)
>
>This is a big topic now.  In transition_notes.xml, you will see a <note>
>with a list of references from the RHEL 5 STIG which are policy/manual
>checks; we are in the process of determining for the STIG profile (once
>we understand fully what a STIG should be) whether these non-automatable
>checks should be included.

I do believe Michael's suggestion is combination of those you listed above
plus those related to remediation.

There is a large set of SSG content that is process-specific and automated
checks can not be developed.  To my knowledge those are the ones currently
be discussed in transition_notes.  However, there are some that can not be
reasonably "assured" (sorry I hate that word) via the existing OVAL
checks.  Some of the existing logic is based on the premise that the
system in question was generated via a default RHEL config.  But much of
it relies on the fact that the state of the system was *always* in the
state found when the content was interpreted.

For example, password complexity - yes OVAL can ensure the current
configuration is correct.  However, it fails to ensure the existing
passwords met the specified requirement.  The PAM configuration used when
the password is created is not stored in /etc/shadow. A root password or
user password entered during Anaconda install may not meet the requirement
thus the results of the SSG post-install content interpretation are wrong.
 I might be missing something there, but many of the assumptions are based
on the fact that the system being audited via SSG content was *installed
and booted* w/ the relevant configuration.  Building on that assumption is
the fact that the configuration was laid down prior to a reboot and the
audit was run after reboot with *no* configuration changes between those
two (e.g. Ensure ntp is enabled, reboot, thus it is enabled).

In addition to that set of content (process-related + not validatable
through automation) there is a set of requirements that can be verified
through automated means but can not be met through automated means.
However, I have a feeling the correlation between automated auditing and
automated remediation sets is strong.   Checking for a 12 character
password is not sufficient.  Ensuring the system is configured properly
*and* prompting for a password addresses that issue.

Undoubtedly you guys have put more thought into the SCAP content than I
have.  But this strikes me as a rather systemic issue that must be
addressed to ensure interpretation of the SSG content results in an
accurate report.

Yes Michael and myself would like to submit a manual check profile to SSG.
 It would address both situations.  If this isn't acceptable we are quite
willing to carry a patch that addresses these issues.


Thanks,
--Spencer

>
>
>
>
>
>On 08/13/2012 10:22 AM, Mike Palmiotto wrote:
>> Due to the need for handling Manual remediation of audits, I wanted to
>> see if there was any interest in a Manual profile.  We have one already
>> generated, and it helps establish a separation of content in
>>remediation.
>> 
>> This should help address the OCIL void while it exists.
>> 
>> If there is any interest, I can submit a patch to the list.  Otherwise,
>> we can carry a patch in CLIP.
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>_______________________________________________
>scap-security-guide mailing list
>scap-security-guide at lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide



More information about the scap-security-guide mailing list