[RFC] Manual Profile Use

Shawn Wells shawn at redhat.com
Tue Aug 14 02:47:32 UTC 2012


On 8/13/12 7:35 PM, Spencer R. Shimko wrote:
> 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.

Would an actual profile be called for, or just identification of rules 
that need to be manually validated?

> 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.
So you want to carry a Tresys fork of SSG?   o_O
I'd say toss the patch over so we can see exactly what you're talking about.


More information about the scap-security-guide mailing list