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.

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(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On 8/13/12 7:35 PM, Spencer R. Shimko wrote: > On 8/13/12 10:37 AM, "Jeffrey Blank" <blank(a)eclipse.ncsc.mil&gt; 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. _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On 8/13/12 10:47 PM, "Shawn Wells" <shawn(a)redhat.com&gt; wrote: >On 8/13/12 7:35 PM, Spencer R. Shimko wrote: >> On 8/13/12 10:37 AM, "Jeffrey Blank" <blank(a)eclipse.ncsc.mil&gt; 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 &gt;scap-security-guide(a)lists.fedorahosted.org >https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On Tuesday, August 14, 2012 04:29:39 AM Spencer R. Shimko wrote: > Our patches, if necessary, will always be additive. We will always >engage > the relevant community first. Hence this RFC. *We are not forking*. > Quite to the contrary, we learned from Red Hat. Red Hat carries >countless > patches to upstream repositories. They include those patches in source > RPMs. You don't consider those packages containing patches forks do you > Shawn? We have an upstream first policy. We find problems, talk with upstream about the problem, submit patches that are acceptable by upstream, only then do we patch an old release that we want some stability in. We re-base to a current release that allows us to drop patches when convenient.

-Steve