On 8/13/12 10:47 PM, "Shawn Wells" <[email protected]> wrote:
>On 8/13/12 7:35 PM, Spencer R. Shimko wrote: >> On 8/13/12 10:37 AM, "Jeffrey Blank" <[email protected]> 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? IMO either way works. In the long term as long as it is well-defined it will work more generally. We thought a profile was the least invasive approach to solve the problem in the short term. > >> 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. We have one :) I thought an RFC was a better approach since this was related to an existing topic-of-interest on the list that was still in-flux. We will post it for review tomorrow. Thanks, --Spencer >_______________________________________________ >scap-security-guide mailing list >[email protected] >https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
