<HTML><BODY>
    <BR>
    <BR>
    I have one more minor contribution.<BR>
<BR>
In the past, there has only been one SCAP content per OS. With the introduction of multiple SCAP contents that could be applicable to a single system, I have had a desire to create a way to facilitate performing a scan with all applicable content in a simplified manner. I really liked the concept of the /etc/init.d/oscap-scan and /etc/sysconfig/oscap-scan setup. I contributed a minor change to these files in openscap, which are available in v1.2.0. I have also attached the init file for older versions (1.0.8). So with the init file change in place, it creates a means of walking through multiple scan configurations and applying each.<BR>
<BR>
So the attached zip includes oscap-scan configuration files for the new content I included. I also updated the spec file to package them in the rpm. The only further enhancement I could foresee is including a detection of the running OS in the spec file and only installing oscap-scan configuration files applicable to the OS (e.g. don't install the RHEL5 oscap-scan configuration file on RHEL6 or RHEL7).<BR>
<BR>
So with these changes in place, you can simply run 'service oscap-scan start' to scan and remediate your RHEL5 system, in addition to firefox, java, and webmin packages. All in one sweep.<BR>
<BR>
Best regards,<BR>
 <BR>
<BR>
Trey Henefield, CISSP<BR>
Senior IAVA Engineer<BR>
<BR>
Ultra Electronics<BR>
Advanced Tactical Systems, Inc.<BR>
4101 Smith School Road<BR>
Building IV, Suite 100<BR>
Austin, TX 78744 USA<BR>
<BR>
<a href="mailto:Trey.Henefield@ultra-ats.com">Trey.Henefield@ultra-ats.com</a><BR>
Tel: +1 512 327 6795 ext. 647<BR>
Fax: +1 512 327 8043<BR>
Mobile: +1 512 541 6450<BR>
<BR>
<a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><BR>
<BR>
-----Original Message-----<BR>
From: Jan Lieskovsky [mailto:jlieskov@redhat.com] <BR>
Sent: Friday, December 05, 2014 6:07 AM<BR>
To: Trey Henefield; Shawn Wells<BR>
Subject: Re: SCAP Content ...<BR>
<BR>
Hey Trey, Shawn,<BR>
<BR>
----- Original Message -----<BR>
&gt; From: &quot;Shawn Wells&quot; &lt;shawn@redhat.com&gt;<BR>
&gt; To: &quot;Trey Henefield&quot; &lt;trey.henefield@ultra-ats.com&gt;<BR>
&gt; Cc: &quot;Jan Lieskovsky&quot; &lt;jlieskov@redhat.com&gt;<BR>
&gt; Sent: Thursday, December 4, 2014 7:33:37 PM<BR>
&gt; Subject: Re: SCAP Content ...<BR>
<BR>
Trey,<BR>
<BR>
  I second to Shawn. From a brief look this is a really brilliant contribution.<BR>
Thanks a lot for it!<BR>
<BR>
&gt; <BR>
&gt; This is fantastic! Skimmed the approval text, will definitely review <BR>
&gt; when I get time later today. Will approve the patch email when I see <BR>
&gt; the request come through (there's often a delay between posting and <BR>
&gt; when list moderators get the notice).<BR>
<BR>
Shawn, the email has now reached the queue (Date: December 4, 2014 6:46 PM,<BR>
Subject: scap-security-guide post from <a href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a> requires approval).<BR>
Please approve it.<BR>
<BR>
Regarding the inclusion - if you make a PR, I can review it. Or should you be busy today, just make the ticket &amp; attach the zip to it. I can make a PR during weekend &amp; you can review. Either way works for me [*].<BR>
<BR>
Thank you &amp;&amp; Regards, Jan.<BR>
--<BR>
Jan iankko Lieskovsky / Red Hat Security Technologies Team<BR>
<BR>
[*] I could make a ticket &amp; attach the zip Trey sent in different email as attachment to it.<BR>
    But to make the inclusion process more transparent &amp; for proper contribution attribution,<BR>
    IMHO it will be better to wait till the email + the attachment reaches the SSG mailing list.<BR>
<BR>
&gt; <BR>
&gt; Shawn<BR>
&gt; <BR>
&gt; --<BR>
&gt; Shawn Wells<BR>
&gt; Director, Innovation Programs<BR>
&gt; <a href="mailto:shawn@redhat.com">shawn@redhat.com</a> | 443.534.0130<BR>
&gt; @shawndwells<BR>
&gt; <BR>
&gt; &gt; On Dec 4, 2014, at 1:28 PM, Trey Henefield <BR>
&gt; &gt; &lt;trey.henefield@ultra-ats.com&gt;<BR>
&gt; &gt; wrote:<BR>
&gt; &gt; <BR>
&gt; &gt; <BR>
&gt; &gt; <BR>
&gt; &gt; Finally got export approval.<BR>
&gt; &gt;  <BR>
&gt; &gt; For your reference, here was the outcome of that:<BR>
&gt; &gt;  <BR>
&gt; &gt; “Per our conversation, the SCAP content you are proposing below is <BR>
&gt; &gt; not subject to the EAR in accordance with 15 CFR 734.3(b)(3).  It <BR>
&gt; &gt; may be released online without restriction.<BR>
&gt; &gt;  <BR>
&gt; &gt; The above-referenced section of the EAR states that the following <BR>
&gt; &gt; items are not subject to the EAR:<BR>
&gt; &gt;  <BR>
&gt; &gt; (3) Publicly available technology and software, except software <BR>
&gt; &gt; classified under ECCN 5D002 on the Commerce Control List, that:<BR>
&gt; &gt; (i) Are already published or will be published as described in &sect; <BR>
&gt; &gt; 734.7 of this part;<BR>
&gt; &gt; (ii) Arise during, or result from, fundamental research, as <BR>
&gt; &gt; described in &sect;<BR>
&gt; &gt; 734.8 of this part;<BR>
&gt; &gt; (iii) Are educational, as described in &sect; 734.9 of this part;<BR>
&gt; &gt; (iv) Are included in certain patent applications, as described in &sect; <BR>
&gt; &gt; 734.10 of this part.<BR>
&gt; &gt;  <BR>
&gt; &gt; The SCAP content is based on two publicly available technology sources:<BR>
&gt; &gt; DISA’s STIGs and NIST’s SCAP formatting requirements.  Both are publicly<BR>
&gt; &gt; available online without restriction.   There has been no addition of<BR>
&gt; &gt; controlled, US technology involved in creating this content – from <BR>
&gt; &gt; an export standpoint, it is merely a translation from one format to another.<BR>
&gt; &gt;  <BR>
&gt; &gt; There is no encryption involved in either the original content or <BR>
&gt; &gt; the end-product.<BR>
&gt; &gt;  <BR>
&gt; &gt; DISA has posted equivalent SCAP content publicly on their website.  <BR>
&gt; &gt; The only difference between that content and the content proposed <BR>
&gt; &gt; here is that this is based on more current (but still publicly <BR>
&gt; &gt; releasable) STIG content.”<BR>
&gt; &gt;  <BR>
&gt; &gt; I have just posted my content to the group. But I believe it will <BR>
&gt; &gt; require moderator approval as it exceeds the 200KB limit.<BR>
&gt; &gt;  <BR>
&gt; &gt;  <BR>
&gt; &gt; Best regards,<BR>
&gt; &gt;  <BR>
&gt; &gt; Trey Henefield, CISSP<BR>
&gt; &gt; Senior IAVA Engineer<BR>
&gt; &gt;  <BR>
&gt; &gt; Ultra Electronics<BR>
&gt; &gt; Advanced Tactical Systems, Inc.<BR>
&gt; &gt; 4101 Smith School Road<BR>
&gt; &gt; Building IV, Suite 100<BR>
&gt; &gt; Austin, TX 78744 USA<BR>
&gt; &gt;  <BR>
&gt; &gt; <a href="mailto:Trey.Henefield@ultra-ats.com">Trey.Henefield@ultra-ats.com</a><BR>
&gt; &gt; Tel: +1 512 327 6795 ext. 647<BR>
&gt; &gt; Fax: +1 512 327 8043<BR>
&gt; &gt; Mobile: +1 512 541 6450<BR>
&gt; &gt;  <BR>
&gt; &gt; <a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><BR>
&gt; &gt;  <BR>
&gt; &gt; From: Shawn Wells [mailto:shawn@redhat.com]<BR>
&gt; &gt; Sent: Tuesday, November 18, 2014 11:54 AM<BR>
&gt; &gt; To: Trey Henefield; Jan Lieskovsky<BR>
&gt; &gt; Subject: Re: SCAP Content ...<BR>
&gt; &gt;  <BR>
&gt; &gt; On 11/18/14, 12:17 PM, Trey Henefield wrote:<BR>
&gt; &gt; Hi Shawn,<BR>
&gt; &gt;  I finally got approval to submit my content changes upstream. I <BR>
&gt; &gt; just  wanted to give you a heads up that there will be allot of <BR>
&gt; &gt; wonderful  changes coming your way soon.<BR>
&gt; &gt; In addition to changes to existing content for RHEL6, I have created <BR>
&gt; &gt; content for RHEL5, Firefox, Java, and Webmin. The RHEL5 content <BR>
&gt; &gt; currently supports RHEL4 and RHEL5, as well as CentOS4 and CentOS5. <BR>
&gt; &gt; I hope that’s ok, given the debate going on about CentOS.<BR>
&gt; &gt; I am currently getting my content in sync will all the current <BR>
&gt; &gt; changes in the repo. I branched off about a year ago.<BR>
&gt; &gt; So as soon as I am done with that, I will send it your way. Because <BR>
&gt; &gt; there are so many changes, I would prefer to send them to you zipped <BR>
&gt; &gt; up via email and allow you to upload them as you approve them. I hope that’s ok.<BR>
&gt; &gt; <BR>
&gt; &gt; That's awesome Trey! I've looped in Jan to keep him fully informed.<BR>
&gt; &gt; <BR>
&gt; &gt; Content for extra applications would be most interesting, especially <BR>
&gt; &gt; around Firefox and Java. Are these OS-specific configs (e.g. Firefox <BR>
&gt; &gt; on RHEL6) or applicable to Firefox on any version of RHEL? If <BR>
&gt; &gt; agnostic we'll want to create a new top-level directory, else place <BR>
&gt; &gt; the content within input/services (or somewhere appropriate).<BR>
&gt; &gt; <BR>
&gt; &gt; RHEL4 is EOL, so I don't particularly see a need to create a new <BR>
&gt; &gt; top-level directory for it. RHEL5 makes perfect sense, though. As <BR>
&gt; &gt; for CentOS vs RHEL... perhaps leaving off CPE tags for the rules <BR>
&gt; &gt; will suffice, vs creating a CentOS top-level directory.<BR>
&gt; &gt; <BR>
&gt; &gt; Note in the last year we moved the code to GitHub. You should be <BR>
&gt; &gt; able to set an &quot;upstream&quot; remote target to rebase against, e.g.:<BR>
&gt; &gt; <BR>
&gt; &gt; $ git remote add upstream<BR>
&gt; &gt; <a href="https://github.com/OpenSCAP/scap-security-guide.git" target="_blank">https://github.com/OpenSCAP/scap-security-guide.git</a><BR>
&gt; &gt; <BR>
&gt; &gt; Then once added:<BR>
&gt; &gt; $ git checkout master<BR>
&gt; &gt; $ git fetch upstream<BR>
&gt; &gt; $ git merge upstream/master<BR>
&gt; &gt; (this will likely cause a series of merge conflicts. send a note to <BR>
&gt; &gt; the list if you need some help merging!)<BR>
&gt; &gt; <BR>
&gt; &gt; In terms of patch review, if you're not comfortable with GitHub pull <BR>
&gt; &gt; requests (which is a bit convoluted, especially the required <BR>
&gt; &gt; branching), would you be willing to post them to the mailing list? <BR>
&gt; &gt; This would allow many more eyes during the review.<BR>
&gt; &gt; <BR>
&gt; &gt; Out of curiosity, how did you get your management approval to commit <BR>
&gt; &gt; back upstream? Any lessons learned we could reuse?<BR>
&gt; &gt; <BR>
&gt; &gt; <BR>
&gt; &gt; Disclaimer<BR>
&gt; &gt; The information contained in this communication from <BR>
&gt; &gt; <a href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a> sent at 2014-12-04 13:12:26 is private<BR>
&gt; &gt; and may be legally privileged or export controlled. It is intended <BR>
&gt; &gt; solely for use by <a href="mailto:shawn@redhat.com">shawn@redhat.com</a> and others authorized to receive<BR>
&gt; &gt; it. If you are not <a href="mailto:shawn@redhat.com">shawn@redhat.com</a> you are hereby notified that any<BR>
&gt; &gt; disclosure, copying, distribution or taking action in reliance of <BR>
&gt; &gt; the contents of this information is strictly prohibited and may be unlawful.<BR>
&gt; &gt; <BR>
&gt; <BR>

    <BR>
    <BR>
 <p><font size="1"><b><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif">Disclaimer</font></b><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif"><br/>
        The information contained in this communication from </font></font><font color="#666666" size="1" face="Verdana, Arial, Helvetica, sans-serif"><b>
          trey.henefield@ultra-ats.com
          </b> sent at
          2014-12-08
          13:22:52
          is private and may be legally privileged or export controlled. It is intended solely for 
          use by <b>
            scap-security-guide@lists.fedorahosted.org
            </b> and others 
          authorized to receive it. If you are not <b>
            scap-security-guide@lists.fedorahosted.org
            </b> you are hereby notified that any disclosure, copying, distribution or 
          taking action in reliance of the contents of this information is strictly 
          prohibited and may be unlawful.</font><br>
          <br>
    </BODY></HTML>