From mike.kuhnkey at att.net Tue Mar 1 00:02:54 2016 Content-Type: multipart/mixed; boundary="===============2396370836742924111==" MIME-Version: 1.0 From: Mike Kuhnkey To: scap-security-guide at lists.fedorahosted.org Subject: STIG_Overlay.sh: rhel6->rhel7...Any recommendations on How to contribute? Date: Tue, 01 Mar 2016 00:02:48 +0000 Message-ID: <20160301000248.26626.66461@mailman01.phx2.fedoraproject.org> --===============2396370836742924111== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable stig_overlay.sh of rhel6 appears to be same for rhel7. When completed what= will rhel7 stig_overlay look like when rhel6 references are replaced? Sho= uld I be talking with DISA FSO or have I missed something in the Wiki or bl= ogs? DISA RHEL-7 Draft STIG references to "SRG-OS-000001-GPOS-00001" are new to = me...Is this a new form of unified references? Somehow cross-referenced to= "CCI"? I need some guidance here, or is it still being sorted out? I really don't know how to phrase this question intelligently....can someon= e help me out? --===============2396370836742924111==-- From swells at redhat.com Tue Mar 1 00:27:27 2016 Content-Type: multipart/mixed; boundary="===============6419309385156057023==" MIME-Version: 1.0 From: Shawn Wells To: scap-security-guide at lists.fedorahosted.org Subject: Re: STIG_Overlay.sh: rhel6->rhel7...Any recommendations on How to contribute? Date: Mon, 29 Feb 2016 19:27:17 -0500 Message-ID: <56D4E1E5.8070300@redhat.com> In-Reply-To: 20160301000248.26626.66461@mailman01.phx2.fedoraproject.org --===============6419309385156057023== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 2/29/16 7:02 PM, Mike Kuhnkey wrote: > stig_overlay.sh of rhel6 appears to be same for rhel7. When completed wh= at will rhel7 stig_overlay look like when rhel6 references are replaced? S= hould I be talking with DISA FSO or have I missed something in the Wiki or = blogs? It's not well documented =3D/ DISA creates their own identification scheme outside of industry CCEs. = These are the RHEL-06-* identifiers you mention. They come from the = RHEL/6/input/auxiliary/stig_overlay.xml file. For example: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/au= xiliary/stig_overlay.xml#L11-L14 > ownerid=3D"RHEL-06-000004" disa=3D"137" severity=3D"low"> > > The system must use a separate file system for = > the system audit data path. > This will take the partition_for_var_log_audit rule and embed = RHEL-06-000004 into its metadata. As DISA gets closer to releasing the RHEL7 STIG, we'll update these = mappings for RHEL7 content (as by that time, DISA will have finalized = their RHEL-07-* numbering schemes). > DISA RHEL-7 Draft STIG references to "SRG-OS-000001-GPOS-00001" are new t= o me...Is this a new form of unified references? Somehow cross-referenced = to "CCI"? I need some guidance here, or is it still being sorted out? > > I really don't know how to phrase this question intelligently....can some= one help me out? You're not crazy. The SRG system is broken and going away. Until SRG = dies, the system goes something like this: Step 1: DISA attempts to interpret NIST 800-53 and selects controls they = feel are relevant for an operating system. From this, they create high = level requirements in the form of "General Purpose Operating System = Security Requirements Guide," or GPOS SRG. This is where the = SRG-OS-######-GPOS-##### numbers come from. The GPOS SRG is generic, = applicable to RHEL, Windows, OSX, etc. An example could be "Audit = Privileged User Actions." Outside of DISA, these numbers are entirely = meaningless. Step 2: Once DISA has the high-level requirements, they create = product-specific configuration guidance. This is where RHEL-07-###### = numbers come from. "Audit Privileged User Actions" might mean adding 10+ = audit rules for Linux, so we'd have RHEL-07-000000 through = RHEL-07-000010 mapped back to a single SRG-OS-GPS identifier. When RHEL = deployments attest to STIG compliance, they must show conformance to = RHEL-07-###### controls. Step 3: Once the RHEL-07-###### controls and naming schema is finalized, = we map them into the stig_overlay file. This will bind the DISA = identifiers into OpenSCAP XCCDF content. End result being DISA = identifiers show up in OpenSCAP HTML and CLI reports, looking something = like this: > Title Set Password Strength Minimum Special Characters > Rule accounts_password_pam_ocredit > Ident CCE-26409-3 > Ident DISA FSO RHEL-06-000058 > Result pass Does this help? --===============6419309385156057023== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRm LTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPC9oZWFkPgogIDxib2R5IGJnY29sb3I9 IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPgogICAgPGJyPgogICAgPGJyPgogICAgPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5PbiAyLzI5LzE2IDc6MDIgUE0sIE1pa2UgS3VobmtleSB3cm90 ZTo8YnI+CiAgICA8L2Rpdj4KICAgIDxibG9ja3F1b3RlCiAgICAgIGNpdGU9Im1pZDoyMDE2MDMw MTAwMDI0OC4yNjYyNi42NjQ2MUBtYWlsbWFuMDEucGh4Mi5mZWRvcmFwcm9qZWN0Lm9yZyIKICAg ICAgdHlwZT0iY2l0ZSI+CiAgICAgIDxwcmUgd3JhcD0iIj5zdGlnX292ZXJsYXkuc2ggb2Ygcmhl bDYgYXBwZWFycyB0byBiZSBzYW1lIGZvciByaGVsNy4gIFdoZW4gY29tcGxldGVkIHdoYXQgd2ls bCByaGVsNyBzdGlnX292ZXJsYXkgbG9vayBsaWtlIHdoZW4gcmhlbDYgcmVmZXJlbmNlcyBhcmUg cmVwbGFjZWQ/ICBTaG91bGQgSSBiZSB0YWxraW5nIHdpdGggRElTQSBGU08gb3IgaGF2ZSBJIG1p c3NlZCBzb21ldGhpbmcgaW4gdGhlIFdpa2kgb3IgYmxvZ3M/PC9wcmU+CiAgICA8L2Jsb2NrcXVv dGU+CiAgICBJdCdzIG5vdCB3ZWxsIGRvY3VtZW50ZWQgPS88YnI+CiAgICA8YnI+CiAgICBESVNB IGNyZWF0ZXMgdGhlaXIgb3duIGlkZW50aWZpY2F0aW9uIHNjaGVtZSBvdXRzaWRlIG9mIGluZHVz dHJ5CiAgICBDQ0VzLiBUaGVzZSBhcmUgdGhlIFJIRUwtMDYtKiBpZGVudGlmaWVycyB5b3UgbWVu dGlvbi4gVGhleSBjb21lCiAgICBmcm9tIHRoZSBSSEVMLzYvaW5wdXQvYXV4aWxpYXJ5L3N0aWdf b3ZlcmxheS54bWwgZmlsZS4gPGJyPgogICAgPGJyPgogICAgRm9yIGV4YW1wbGU6PGJyPgo8YSBj bGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vT3Bl blNDQVAvc2NhcC1zZWN1cml0eS1ndWlkZS9ibG9iL21hc3Rlci9SSEVMLzYvaW5wdXQvYXV4aWxp YXJ5L3N0aWdfb3ZlcmxheS54bWwjTDExLUwxNCI+aHR0cHM6Ly9naXRodWIuY29tL09wZW5TQ0FQ L3NjYXAtc2VjdXJpdHktZ3VpZGUvYmxvYi9tYXN0ZXIvUkhFTC82L2lucHV0L2F1eGlsaWFyeS9z dGlnX292ZXJsYXkueG1sI0wxMS1MMTQ8L2E+PGJyPgogICAgPG1ldGEgY2hhcnNldD0idXRmLTgi PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgIDxtZXRhIGNoYXJzZXQ9InV0Zi04 Ij4KICAgICAgPG1ldGEgY2hhcnNldD0idXRmLTgiPgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+wqDCoMKgwqDCoMKgwqAgJmx0O292ZXJsYXkgb3duZXI9ImRp c2FzdGlnIgogICAgICBydWxlaWQ9InBhcnRpdGlvbl9mb3JfdmFyX2xvZ19hdWRpdCIgb3duZXJp ZD0iUkhFTC0wNi0wMDAwMDQiCiAgICAgIGRpc2E9IjEzNyIgc2V2ZXJpdHk9ImxvdyImZ3Q7PGJy PgogICAgICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgJmx0O1ZNU2luZm8gVktleT0i Mzg0NjciIFNWS2V5PSI1MDI2NyIKICAgICAgVlJlbGVhc2U9IjEiIC8mZ3Q7PGJyPgogICAgICDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgJmx0O3RpdGxlJmd0O1RoZSBzeXN0ZW0gbXVz dCB1c2UgYSBzZXBhcmF0ZSBmaWxlCiAgICAgIHN5c3RlbSBmb3IgdGhlIHN5c3RlbSBhdWRpdCBk YXRhIHBhdGguJmx0Oy90aXRsZSZndDs8YnI+CiAgICAgIMKgwqDCoMKgwqDCoMKgICZsdDsvb3Zl cmxheSZndDs8YnI+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICBUaGlzIHdpbGwgdGFrZSB0aGUgcGFy dGl0aW9uX2Zvcl92YXJfbG9nX2F1ZGl0IHJ1bGUgYW5kIGVtYmVkCiAgICBSSEVMLTA2LTAwMDAw NCBpbnRvIGl0cyBtZXRhZGF0YS4gPGJyPgogICAgPGJyPgogICAgQXMgRElTQSBnZXRzIGNsb3Nl ciB0byByZWxlYXNpbmcgdGhlIFJIRUw3IFNUSUcsIHdlJ2xsIHVwZGF0ZSB0aGVzZQogICAgbWFw cGluZ3MgZm9yIFJIRUw3IGNvbnRlbnQgKGFzIGJ5IHRoYXQgdGltZSwgRElTQSB3aWxsIGhhdmUK ICAgIGZpbmFsaXplZCB0aGVpciBSSEVMLTA3LSogbnVtYmVyaW5nIHNjaGVtZXMpLiA8YnI+CiAg ICA8YnI+CiAgICA8YnI+CiAgICA8YmxvY2txdW90ZQogICAgICBjaXRlPSJtaWQ6MjAxNjAzMDEw MDAyNDguMjY2MjYuNjY0NjFAbWFpbG1hbjAxLnBoeDIuZmVkb3JhcHJvamVjdC5vcmciCiAgICAg IHR5cGU9ImNpdGUiPgogICAgICA8cHJlIHdyYXA9IiI+RElTQSBSSEVMLTcgRHJhZnQgU1RJRyBy ZWZlcmVuY2VzIHRvICJTUkctT1MtMDAwMDAxLUdQT1MtMDAwMDEiIGFyZSBuZXcgdG8gbWUuLi5J cyB0aGlzIGEgbmV3IGZvcm0gb2YgdW5pZmllZCByZWZlcmVuY2VzPyAgU29tZWhvdyBjcm9zcy1y ZWZlcmVuY2VkIHRvICJDQ0kiPyBJIG5lZWQgc29tZSBndWlkYW5jZSBoZXJlLCBvciBpcyBpdCBz dGlsbCBiZWluZyBzb3J0ZWQgb3V0PwoKSSByZWFsbHkgZG9uJ3Qga25vdyBob3cgdG8gcGhyYXNl IHRoaXMgcXVlc3Rpb24gaW50ZWxsaWdlbnRseS4uLi5jYW4gc29tZW9uZSBoZWxwIG1lIG91dD88 L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIFlvdSdyZSBub3QgY3JhenkuIFRoZSBTUkcgc3lz dGVtIGlzIGJyb2tlbiBhbmQgZ29pbmcgYXdheS4gVW50aWwgU1JHCiAgICBkaWVzLCB0aGUgc3lz dGVtIGdvZXMgc29tZXRoaW5nIGxpa2UgdGhpczo8YnI+CiAgICA8YnI+CiAgICBTdGVwIDE6IERJ U0EgYXR0ZW1wdHMgdG8gaW50ZXJwcmV0IE5JU1QgODAwLTUzIGFuZCBzZWxlY3RzIGNvbnRyb2xz CiAgICB0aGV5IGZlZWwgYXJlIHJlbGV2YW50IGZvciBhbiBvcGVyYXRpbmcgc3lzdGVtLiBGcm9t IHRoaXMsIHRoZXkKICAgIGNyZWF0ZSBoaWdoIGxldmVsIHJlcXVpcmVtZW50cyBpbiB0aGUgZm9y bSBvZiAiR2VuZXJhbCBQdXJwb3NlCiAgICBPcGVyYXRpbmcgU3lzdGVtIFNlY3VyaXR5IFJlcXVp cmVtZW50cyBHdWlkZSwiIG9yIEdQT1MgU1JHLiBUaGlzIGlzCiAgICB3aGVyZSB0aGUgU1JHLU9T LSMjIyMjIy1HUE9TLSMjIyMjIG51bWJlcnMgY29tZSBmcm9tLiBUaGUgR1BPUyBTUkcKICAgIGlz IGdlbmVyaWMsIGFwcGxpY2FibGUgdG8gUkhFTCwgV2luZG93cywgT1NYLCBldGMuIEFuIGV4YW1w bGUgY291bGQKICAgIGJlICJBdWRpdCBQcml2aWxlZ2VkIFVzZXIgQWN0aW9ucy4iIE91dHNpZGUg b2YgRElTQSwgdGhlc2UgbnVtYmVycwogICAgYXJlIGVudGlyZWx5IG1lYW5pbmdsZXNzLjxicj4K ICAgIDxicj4KICAgIFN0ZXAgMjogT25jZSBESVNBIGhhcyB0aGUgaGlnaC1sZXZlbCByZXF1aXJl bWVudHMsIHRoZXkgY3JlYXRlCiAgICBwcm9kdWN0LXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gZ3Vp ZGFuY2UuIFRoaXMgaXMgd2hlcmUKICAgIFJIRUwtMDctIyMjIyMjIG51bWJlcnMgY29tZSBmcm9t LiAiQXVkaXQgUHJpdmlsZWdlZCBVc2VyIEFjdGlvbnMiCiAgICBtaWdodCBtZWFuIGFkZGluZyAx MCsgYXVkaXQgcnVsZXMgZm9yIExpbnV4LCBzbyB3ZSdkIGhhdmUKICAgIFJIRUwtMDctMDAwMDAw IHRocm91Z2ggUkhFTC0wNy0wMDAwMTAgbWFwcGVkIGJhY2sgdG8gYSBzaW5nbGUKICAgIFNSRy1P Uy1HUFMgaWRlbnRpZmllci4gV2hlbiBSSEVMIGRlcGxveW1lbnRzIGF0dGVzdCB0byBTVElHCiAg ICBjb21wbGlhbmNlLCB0aGV5IG11c3Qgc2hvdyBjb25mb3JtYW5jZSB0byBSSEVMLTA3LSMjIyMj IyBjb250cm9scy48YnI+CiAgICA8YnI+CiAgICBTdGVwIDM6IE9uY2UgdGhlIFJIRUwtMDctIyMj IyMjIGNvbnRyb2xzIGFuZCBuYW1pbmcgc2NoZW1hIGlzCiAgICBmaW5hbGl6ZWQsIHdlIG1hcCB0 aGVtIGludG8gdGhlIHN0aWdfb3ZlcmxheSBmaWxlLiBUaGlzIHdpbGwgYmluZAogICAgdGhlIERJ U0EgaWRlbnRpZmllcnMgaW50byBPcGVuU0NBUCBYQ0NERiBjb250ZW50LiBFbmQgcmVzdWx0IGJl aW5nCiAgICBESVNBIGlkZW50aWZpZXJzIHNob3cgdXAgaW4gT3BlblNDQVAgSFRNTCBhbmQgQ0xJ IHJlcG9ydHMsIGxvb2tpbmcKICAgIHNvbWV0aGluZyBsaWtlIHRoaXM6PGJyPgogICAgPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+VGl0bGXCoMKgIFNldCBQYXNzd29yZCBTdHJlbmd0aCBNaW5pbXVt CiAgICAgIFNwZWNpYWwgQ2hhcmFjdGVyczxicj4KICAgICAgUnVsZcKgwqDCoCBhY2NvdW50c19w YXNzd29yZF9wYW1fb2NyZWRpdDxicj4KICAgICAgSWRlbnTCoMKgIENDRS0yNjQwOS0zPGJyPgog ICAgICBJZGVudMKgwqAgRElTQSBGU08gUkhFTC0wNi0wMDAwNTg8YnI+CiAgICAgIFJlc3VsdMKg IHBhc3M8YnI+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+CiAgICBEb2VzIHRoaXMgaGVscD8K ICA8L2JvZHk+CjwvaHRtbD4K --===============6419309385156057023==-- From mike.kuhnkey at att.net Tue Mar 1 13:49:01 2016 Content-Type: multipart/mixed; boundary="===============2885275294521654696==" MIME-Version: 1.0 From: Mike Kuhnkey To: scap-security-guide at lists.fedorahosted.org Subject: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Tue, 01 Mar 2016 13:48:54 +0000 Message-ID: <20160301134854.15046.6018@mailman01.phx2.fedoraproject.org> --===============2885275294521654696== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Yes. Greatly! Red Hat responds to industry generated CCE's while DISA will= eventually generate CCI's mapped to their current STIG release? Both SRG & CCI references appear to be falling from grace as far as providi= ng stability for shared rule references (multi-platform from a Red Hat pers= pective),and ...we can only guess for DISA. I have an unrelated question t= o XCCDF_POLICY engine which I'll put in another thread. Thank you for clar= ification! --===============2885275294521654696==-- From swells at redhat.com Wed Mar 2 06:22:49 2016 Content-Type: multipart/mixed; boundary="===============1796294550459707890==" MIME-Version: 1.0 From: Shawn Wells To: scap-security-guide at lists.fedorahosted.org Subject: Re: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Wed, 02 Mar 2016 01:22:36 -0500 Message-ID: <56D686AC.5080803@redhat.com> In-Reply-To: 20160301134854.15046.6018@mailman01.phx2.fedoraproject.org --===============1796294550459707890== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 3/1/16 8:48 AM, Mike Kuhnkey wrote: > Yes. Greatly! Red Hat responds to industry generated CCE's while DISA wi= ll eventually generate CCI's mapped to their current STIG release? NIST gives vendors an assignment of CCEs to pair with configuration = guidance. OpenSCAP/SSG serves as Red Hat's configuration community, so = within SSG we assign CCEs to specific XCCDF rules. In the past DISA has used CCIs, however those should be abstracted away = from end-users. With RHEL7 STIG content, you'll likely need to attest to = either the RHEL-07-##### control (from DISA), or more SCA's will want = users will attest against the CCE (which maps back to NIST 800-53). > Both SRG & CCI references appear to be falling from grace as far as provi= ding stability for shared rule references (multi-platform from a Red Hat pe= rspective),and ...we can only guess for DISA. I have an unrelated question= to XCCDF_POLICY engine which I'll put in another thread. Thank you for cl= arification! In recent times the SRGs are meant to reflect DISA's control selections = and refinements from NIST 800-53. DISA CCI's then come along and provide = the "ability to trace security requirements from their origin to their = low-level implementation" [0]... aka specific implementation guidance = for a product. Sprinkled in are the RHEL-07-##### identifiers. And then = we have CCEs that are assigned by NIST/vendors. What controls do you = need to actually document compliance against during system = accreditation? It's confusing as hell. Within SSG, we map each XCCDF rule to a CCE. That CCE is then mapped to = regulatory identifiers. To make all this real, we can look at the RHEL6 = "audit_rules_time_watch_localtime" rule: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/xc= cdf/system/auditing.xml#L637-L660 It contains this snippet of code: so from that, we can see: - XCCDF rule "audit_rules_time_watch_localtime" is mapped to Red Hat = CCE-27172-6 - CCE-27172-6 is further mapped against * NIST 800-53 AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), = AU-12(a), AU-12(c), IR-5 * DISA CCI's 1487 and 169 When OpenSCAP verifies compliance with CCE-27172-6, we're able to = generate reports that show conformance with the above DISA CCIs and = document configuration against the NIST controls. That mapping is how we generate the sample RTMs, such as the RHEL6 NIST = table: http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/table-rhe= l6-nistrefs-common.html [0] http://iase.disa.mil/stigs/cci/Pages/index.aspx -- = Shawn Wells Chief Security Strategist U.S. Public Sector shawn(a)redhat.com | 443.534.0130 --===============1796294550459707890== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRm LTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPC9oZWFkPgogIDxib2R5IGJnY29sb3I9 IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPgogICAgPGJyPgogICAgPGJyPgogICAgPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5PbiAzLzEvMTYgODo0OCBBTSwgTWlrZSBLdWhua2V5IHdyb3Rl Ojxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUKICAgICAgY2l0ZT0ibWlkOjIwMTYwMzAx MTM0ODU0LjE1MDQ2LjYwMThAbWFpbG1hbjAxLnBoeDIuZmVkb3JhcHJvamVjdC5vcmciCiAgICAg IHR5cGU9ImNpdGUiPgogICAgICA8cHJlIHdyYXA9IiI+WWVzLiBHcmVhdGx5ISAgUmVkIEhhdCBy ZXNwb25kcyB0byBpbmR1c3RyeSBnZW5lcmF0ZWQgQ0NFJ3Mgd2hpbGUgRElTQSB3aWxsIGV2ZW50 dWFsbHkgZ2VuZXJhdGUgQ0NJJ3MgbWFwcGVkIHRvIHRoZWlyIGN1cnJlbnQgU1RJRyByZWxlYXNl PzwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyPgogICAgTklTVCBnaXZlcyB2ZW5kb3Jz IGFuIGFzc2lnbm1lbnQgb2YgQ0NFcyB0byBwYWlyIHdpdGggY29uZmlndXJhdGlvbgogICAgZ3Vp ZGFuY2UuIE9wZW5TQ0FQL1NTRyBzZXJ2ZXMgYXMgUmVkIEhhdCdzIGNvbmZpZ3VyYXRpb24gY29t bXVuaXR5LAogICAgc28gd2l0aGluIFNTRyB3ZSBhc3NpZ24gQ0NFcyB0byBzcGVjaWZpYyBYQ0NE RiBydWxlcy48YnI+CiAgICA8YnI+CiAgICBJbiB0aGUgcGFzdCBESVNBIGhhcyB1c2VkIENDSXMs IGhvd2V2ZXIgdGhvc2Ugc2hvdWxkIGJlIGFic3RyYWN0ZWQKICAgIGF3YXkgZnJvbSBlbmQtdXNl cnMuIFdpdGggUkhFTDcgU1RJRyBjb250ZW50LCB5b3UnbGwgbGlrZWx5IG5lZWQgdG8KICAgIGF0 dGVzdCB0byBlaXRoZXIgdGhlIFJIRUwtMDctIyMjIyMgY29udHJvbCAoZnJvbSBESVNBKSwgb3Ig bW9yZQogICAgU0NBJ3Mgd2lsbCB3YW50IHVzZXJzIHdpbGwgYXR0ZXN0IGFnYWluc3QgdGhlIEND RSAod2hpY2ggbWFwcyBiYWNrCiAgICB0byBOSVNUIDgwMC01MykuIDxicj4KICAgIDxicj4KICAg IDxibG9ja3F1b3RlCiAgICAgIGNpdGU9Im1pZDoyMDE2MDMwMTEzNDg1NC4xNTA0Ni42MDE4QG1h aWxtYW4wMS5waHgyLmZlZG9yYXByb2plY3Qub3JnIgogICAgICB0eXBlPSJjaXRlIj4KICAgICAg PHByZSB3cmFwPSIiPkJvdGggU1JHICZhbXA7IENDSSByZWZlcmVuY2VzIGFwcGVhciB0byBiZSBm YWxsaW5nIGZyb20gZ3JhY2UgYXMgZmFyIGFzIHByb3ZpZGluZyBzdGFiaWxpdHkgZm9yIHNoYXJl ZCBydWxlIHJlZmVyZW5jZXMgKG11bHRpLXBsYXRmb3JtIGZyb20gYSBSZWQgSGF0IHBlcnNwZWN0 aXZlKSxhbmQgLi4ud2UgY2FuIG9ubHkgZ3Vlc3MgZm9yIERJU0EuICBJIGhhdmUgYW4gdW5yZWxh dGVkIHF1ZXN0aW9uIHRvIFhDQ0RGX1BPTElDWSBlbmdpbmUgd2hpY2ggSSdsbCBwdXQgaW4gYW5v dGhlciB0aHJlYWQuICBUaGFuayB5b3UgZm9yIGNsYXJpZmljYXRpb24hPC9wcmU+CiAgICA8L2Js b2NrcXVvdGU+CiAgICA8YnI+CiAgICBJbiByZWNlbnQgdGltZXMgdGhlIFNSR3MgYXJlIG1lYW50 IHRvIHJlZmxlY3QgRElTQSdzIGNvbnRyb2wKICAgIHNlbGVjdGlvbnMgYW5kIHJlZmluZW1lbnRz IGZyb20gTklTVCA4MDAtNTMuIERJU0EgQ0NJJ3MgdGhlbiBjb21lCiAgICBhbG9uZyBhbmQgcHJv dmlkZSB0aGUgImFiaWxpdHkgdG8gdHJhY2Ugc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZyb20KICAg IHRoZWlyIG9yaWdpbiB0byB0aGVpciBsb3ctbGV2ZWwgaW1wbGVtZW50YXRpb24iIFswXS4uLiBh a2Egc3BlY2lmaWMKICAgIGltcGxlbWVudGF0aW9uIGd1aWRhbmNlIGZvciBhIHByb2R1Y3QuIFNw cmlua2xlZCBpbiBhcmUgdGhlCiAgICBSSEVMLTA3LSMjIyMjIGlkZW50aWZpZXJzLiBBbmQgdGhl biB3ZSBoYXZlIENDRXMgdGhhdCBhcmUgYXNzaWduZWQKICAgIGJ5IE5JU1QvdmVuZG9ycy4gV2hh dCBjb250cm9scyBkbyB5b3UgbmVlZCB0byBhY3R1YWxseSBkb2N1bWVudAogICAgY29tcGxpYW5j ZSBhZ2FpbnN0IGR1cmluZyBzeXN0ZW0gYWNjcmVkaXRhdGlvbj8gSXQncyBjb25mdXNpbmcgYXMK ICAgIGhlbGwuPGJyPgogICAgPGJyPgogICAgV2l0aGluIFNTRywgd2UgbWFwIGVhY2ggWENDREYg cnVsZSB0byBhIENDRS4gVGhhdCBDQ0UgaXMgdGhlbiBtYXBwZWQKICAgIHRvIHJlZ3VsYXRvcnkg aWRlbnRpZmllcnMuIDxicj4KICAgIDxicj4KICAgIFRvIG1ha2UgYWxsIHRoaXMgcmVhbCwgd2Ug Y2FuIGxvb2sgYXQgdGhlIFJIRUw2CiAgICAiYXVkaXRfcnVsZXNfdGltZV93YXRjaF9sb2NhbHRp bWUiIHJ1bGU6PGJyPgo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vT3BlblNDQVAvc2NhcC1zZWN1cml0eS1ndWlkZS9ibG9iL21hc3Rlci9S SEVMLzYvaW5wdXQveGNjZGYvc3lzdGVtL2F1ZGl0aW5nLnhtbCNMNjM3LUw2NjAiPmh0dHBzOi8v Z2l0aHViLmNvbS9PcGVuU0NBUC9zY2FwLXNlY3VyaXR5LWd1aWRlL2Jsb2IvbWFzdGVyL1JIRUwv Ni9pbnB1dC94Y2NkZi9zeXN0ZW0vYXVkaXRpbmcueG1sI0w2MzctTDY2MDwvYT48YnI+CiAgICA8 YnI+CiAgICBJdCBjb250YWlucyB0aGlzIHNuaXBwZXQgb2YgY29kZTo8YnI+CiAgICA8dGFibGUg Y2xhc3M9ImhpZ2hsaWdodCB0YWItc2l6ZSBqcy1maWxlLWxpbmUtY29udGFpbmVyIgogICAgICBk YXRhLXRhYi1zaXplPSI4IiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgYm9yZGVyLWNv bGxhcHNlOgogICAgICBjb2xsYXBzZTsgYm9yZGVyLXNwYWNpbmc6IDBweDsgdGFiLXNpemU6IDg7 IGNvbG9yOiByZ2IoNTEsIDUxLAogICAgICA1MSk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIGFy aWFsLCBuaW1idXNzYW5zbCwgbGliZXJhdGlvbnNhbnMsCiAgICAgIGZyZWVzYW5zLCBjbGVhbiwg c2Fucy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJCiAgICAgIEVtb2ppJywg J1NlZ29lIFVJIFN5bWJvbCc7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOwog ICAgICBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsKICAgICAgbGluZS1oZWlnaHQ6IDE4LjJweDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7CiAgICAgIHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOwogICAgICB3aWRvd3M6IDE7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7CiAgICAgIGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPgogICAgICA8dGJvZHkgc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7Ij4KICAgICAgICA8dHIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1i b3g7Ij4KICAgICAgICAgIDx0ZCBpZD0iTEM2NTciIGNsYXNzPSJibG9iLWNvZGUgYmxvYi1jb2Rl LWlubmVyIGpzLWZpbGUtbGluZSIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IHBhZGRp bmc6IDBweCAxMHB4OyBwb3NpdGlvbjogcmVsYXRpdmU7IHZlcnRpY2FsLWFsaWduOiB0b3A7IG92 ZXJmbG93OiB2aXNpYmxlOyBmb250LWZhbWlseTogQ29uc29sYXMsICdMaWJlcmF0aW9uIE1vbm8n LCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IGNvbG9yOiByZ2Io NTEsIDUxLCA1MSk7IHdvcmQtd3JhcDogbm9ybWFsOyB3aGl0ZS1zcGFjZTogcHJlOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjQ4LCAyMzgsIDE5OSk7Ij4mbHQ7PHNwYW4gY2xhc3M9InBsLWVudCIg c3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoOTksIDE2MywgOTIpOyI+ aWRlbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJwbC1lIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVy LWJveDsgY29sb3I6IHJnYigxMjEsIDkzLCAxNjMpOyI+Y2NlPC9zcGFuPj08c3BhbiBjbGFzcz0i cGwtcyIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMjQsIDU0LCAx NDUpOyI+PHNwYW4gY2xhc3M9InBsLXBkcyIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7 IGNvbG9yOiByZ2IoMjQsIDU0LCAxNDUpOyI+Ijwvc3Bhbj4yNzE3Mi02PHNwYW4gY2xhc3M9InBs LXBkcyIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMjQsIDU0LCAx NDUpOyI+Ijwvc3Bhbj48L3NwYW4+ICA8c3BhbiBjbGFzcz0icGwtZSIgc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMTIxLCA5MywgMTYzKTsiPnN0aWc8L3NwYW4+PTxz cGFuIGNsYXNzPSJwbC1zIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgY29sb3I6IHJn YigyNCwgNTQsIDE0NSk7Ij48c3BhbiBjbGFzCiBzPSJwbC1wZHMKIiBzdHlsZT0iYm94LXNpemlu ZzogYm9yZGVyLWJveDsgY29sb3I6IHJnYigyNCwgNTQsIDE0NSk7Ij4iPC9zcGFuPlJIRUwtMDYt MDAwMTczPHNwYW4gY2xhc3M9InBsLXBkcyIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7 IGNvbG9yOiByZ2IoMjQsIDU0LCAxNDUpOyI+Ijwvc3Bhbj48L3NwYW4+IC8mZ3Q7CiZsdDs8c3Bh biBjbGFzcz0icGwtZW50IiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgY29sb3I6IHJn Yig5OSwgMTYzLCA5Mik7Ij5vdmFsPC9zcGFuPiA8c3BhbiBjbGFzcz0icGwtZSIgc3R5bGU9ImJv eC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMTIxLCA5MywgMTYzKTsiPmlkPC9zcGFu Pj08c3BhbiBjbGFzcz0icGwtcyIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9y OiByZ2IoMjQsIDU0LCAxNDUpOyI+PHNwYW4gY2xhc3M9InBsLXBkcyIgc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMjQsIDU0LCAxNDUpOyI+Ijwvc3Bhbj5hdWRpdF9y dWxlc190aW1lX3dhdGNoX2xvY2FsdGltZTxzcGFuIGNsYXNzPSJwbC1wZHMiIHN0eWxlPSJib3gt c2l6aW5nOiBib3JkZXItYm94OyBjb2xvcjogcmdiKDI0LCA1NCwgMTQ1KTsiPiI8L3NwYW4+PC9z cGFuPiAvJmd0OzwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7Ij4KICAgICAgICAgIDx0ZCBpZD0iTEM2NTgiIGNsYXNzPSJibG9iLWNv ZGUgYmxvYi1jb2RlLWlubmVyIGpzLWZpbGUtbGluZSIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRl ci1ib3g7IHBhZGRpbmc6IDBweCAxMHB4OyBwb3NpdGlvbjogcmVsYXRpdmU7IHZlcnRpY2FsLWFs aWduOiB0b3A7IG92ZXJmbG93OiB2aXNpYmxlOyBmb250LWZhbWlseTogQ29uc29sYXMsICdMaWJl cmF0aW9uIE1vbm8nLCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7 IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IHdvcmQtd3JhcDogbm9ybWFsOyB3aGl0ZS1zcGFjZTog cHJlOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ4LCAyMzgsIDE5OSk7Ij4mbHQ7PHNwYW4gY2xh c3M9InBsLWVudCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoOTks IDE2MywgOTIpOyI+cmVmPC9zcGFuPiA8c3BhbiBjbGFzcz0icGwtZSIgc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMTIxLCA5MywgMTYzKTsiPm5pc3Q8L3NwYW4+PTxz cGFuIGNsYXNzPSJwbC1zIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgY29sb3I6IHJn YigyNCwgNTQsIDE0NSk7Ij48c3BhbiBjbGFzcz0icGwtcGRzIiBzdHlsZT0iYm94LXNpemluZzog Ym9yZGVyLWJveDsgY29sb3I6IHJnYigyNCwgNTQsIDE0NSk7Ij4iPC9zcGFuPkFDLTMoMTApLEFV LTEoYiksQVUtMihhKSxBVS0yKGMpLEFVLTIoZCksQVUtMTIoYSksQVUtMTIoYyksSVItNTxzcGFu IGNsYXNzPSJwbC1wZHMiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBjb2xvcjogcmdi KDI0LCA1NCwgMTQ1KTsiPiI8L3NwYW4+PC9zcGFuPiAvJmd0OzwvdGQ+CiAgICAgICAgPC90cj4K ICAgICAgICA8dHIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7Ij4KICAgICAgICAgIDx0 ZCBpZD0iTEM2NTkiIGNsYXNzPSJibG9iLWNvZGUgYmxvYi1jb2RlLWlubmVyIGpzLWZpbGUtbGlu ZSIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IHBhZGRpbmc6IDBweCAxMHB4OyBwb3Np dGlvbjogcmVsYXRpdmU7IHZlcnRpY2FsLWFsaWduOiB0b3A7IG92ZXJmbG93OiB2aXNpYmxlOyBm b250LWZhbWlseTogQ29uc29sYXMsICdMaWJlcmF0aW9uIE1vbm8nLCBNZW5sbywgQ291cmllciwg bW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IHdvcmQt d3JhcDogbm9ybWFsOyB3aGl0ZS1zcGFjZTogcHJlOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ4 LCAyMzgsIDE5OSk7Ij4mbHQ7PHNwYW4gY2xhc3M9InBsLWVudCIgc3R5bGU9ImJveC1zaXppbmc6 IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoOTksIDE2MywgOTIpOyI+cmVmPC9zcGFuPiA8c3BhbiBj bGFzcz0icGwtZSIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMTIx LCA5MywgMTYzKTsiPmRpc2E8L3NwYW4+PTxzcGFuIGNsYXNzPSJwbC1zIiBzdHlsZT0iYm94LXNp emluZzogYm9yZGVyLWJveDsgY29sb3I6IHJnYigyNCwgNTQsIDE0NSk7Ij48c3BhbiBjbGFzcz0i cGwtcGRzIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgY29sb3I6IHJnYigyNCwgNTQs IDE0NSk7Ij4iPC9zcGFuPjE0ODcsMTY5PHNwYW4gY2xhc3M9InBsLXBkcyIgc3R5bGU9ImJveC1z aXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoMjQsIDU0LCAxNDUpOyI+Ijwvc3Bhbj48L3Nw YW4+IC8mZ3Q7PC90ZD4KICAgICAgICA8L3RyPgogICAgICA8L3Rib2R5PgogICAgPC90YWJsZT4K ICAgIDxicj4KICAgIHNvIGZyb20gdGhhdCwgd2UgY2FuIHNlZTo8YnI+CiAgICAtIFhDQ0RGIHJ1 bGUgImF1ZGl0X3J1bGVzX3RpbWVfd2F0Y2hfbG9jYWx0aW1lIiBpcyBtYXBwZWQgdG8gUmVkIEhh dAogICAgQ0NFLTI3MTcyLTY8YnI+CiAgICAtIENDRS0yNzE3Mi02IGlzIGZ1cnRoZXIgbWFwcGVk IGFnYWluc3Q8YnI+CiAgICDCoMKgwqAgwqDCoMKgICogTklTVCA4MDAtNTMgQUMtMygxMCksIEFV LTEoYiksIEFVLTIoYSksIEFVLTIoYyksIEFVLTIoZCksCiAgICBBVS0xMihhKSwgQVUtMTIoYyks IElSLTU8YnI+CiAgICDCoMKgwqAgwqDCoMKgICogRElTQSBDQ0kncyAxNDg3IGFuZCAxNjk8YnI+ CiAgICA8YnI+CiAgICBXaGVuIE9wZW5TQ0FQIHZlcmlmaWVzIGNvbXBsaWFuY2Ugd2l0aCBDQ0Ut MjcxNzItNiwgd2UncmUgYWJsZSB0bwogICAgZ2VuZXJhdGUgcmVwb3J0cyB0aGF0IHNob3cgY29u Zm9ybWFuY2Ugd2l0aCB0aGUgYWJvdmUgRElTQSBDQ0lzIGFuZAogICAgZG9jdW1lbnQgY29uZmln dXJhdGlvbiBhZ2FpbnN0IHRoZSBOSVNUIGNvbnRyb2xzLjxicj4KICAgIDxicj4KICAgIFRoYXQg bWFwcGluZyBpcyBob3cgd2UgZ2VuZXJhdGUgdGhlIHNhbXBsZSBSVE1zLCBzdWNoIGFzIHRoZSBS SEVMNgogICAgTklTVCB0YWJsZTo8YnI+CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQi IGhyZWY9Imh0dHA6Ly9wZW9wbGUucmVkaGF0LmNvbS9zd2VsbHMvc2NhcC1zZWN1cml0eS1ndWlk ZS9SSEVMLzYvb3V0cHV0L3RhYmxlLXJoZWw2LW5pc3RyZWZzLWNvbW1vbi5odG1sIj5odHRwOi8v cGVvcGxlLnJlZGhhdC5jb20vc3dlbGxzL3NjYXAtc2VjdXJpdHktZ3VpZGUvUkhFTC82L291dHB1 dC90YWJsZS1yaGVsNi1uaXN0cmVmcy1jb21tb24uaHRtbDwvYT48YnI+CiAgICA8YnI+CiAgICBb MF0gPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL2lhc2UuZGlz YS5taWwvc3RpZ3MvY2NpL1BhZ2VzL2luZGV4LmFzcHgiPmh0dHA6Ly9pYXNlLmRpc2EubWlsL3N0 aWdzL2NjaS9QYWdlcy9pbmRleC5hc3B4PC9hPjxicj4KICAgIDxicj4KICAgIDxwcmUgY2xhc3M9 Im1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSAKU2hhd24gV2VsbHMKQ2hpZWYgU2VjdXJpdHkg U3RyYXRlZ2lzdApVLlMuIFB1YmxpYyBTZWN0b3IKPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnNoYXduQHJlZGhhdC5jb20iPnNoYXduQHJlZGhhdC5jb208 L2E+IHwgNDQzLjUzNC4wMTMwIDwvcHJlPgogIDwvYm9keT4KPC9odG1sPgo= --===============1796294550459707890==-- From mike.kuhnkey at att.net Wed Mar 2 18:01:28 2016 Content-Type: multipart/mixed; boundary="===============7600035074805324375==" MIME-Version: 1.0 From: Mike Kuhnkey To: scap-security-guide at lists.fedorahosted.org Subject: Re: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Wed, 02 Mar 2016 17:40:33 +0000 Message-ID: <20160302174033.23493.60794@mailman01.phx2.fedoraproject.org> In-Reply-To: 56D686AC.5080803@redhat.com --===============7600035074805324375== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Severe "info headache"...think ice cream....but one more scoop: Who/What g= enerates OVAL content? DISA? NIST? Contributors? Red Hat?=20 --===============7600035074805324375==-- From blakefrantz at gmail.com Thu Mar 3 04:27:05 2016 Content-Type: multipart/mixed; boundary="===============2429970743856422411==" MIME-Version: 1.0 From: Blake Frantz To: scap-security-guide at lists.fedorahosted.org Subject: Re: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Wed, 02 Mar 2016 20:26:52 -0800 Message-ID: In-Reply-To: 20160302174033.23493.60794@mailman01.phx2.fedoraproject.org --===============2429970743856422411== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable List of public OVAL producing orgs: https://oval.cisecurity.org/repository/registry > On Mar 2, 2016, at 9:40 AM, Mike Kuhnkey wrote: > = > Severe "info headache"...think ice cream....but one more scoop: Who/What= generates OVAL content? DISA? NIST? Contributors? Red Hat? = > -- > SCAP Security Guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/scap-security-guide(a)lists.fe= dorahosted.org > https://github.com/OpenSCAP/scap-security-guide/ --===============2429970743856422411==-- From jason.w.mackanick.civ at mail.mil Thu Mar 3 15:13:47 2016 Content-Type: multipart/mixed; boundary="===============8051636639006280113==" MIME-Version: 1.0 From: Mackanick, Jason W CIV DISA RE (US) To: scap-security-guide at lists.fedorahosted.org Subject: Re: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Thu, 03 Mar 2016 14:44:43 +0000 Message-ID: <20160303144443.22267.86625@mailman01.phx2.fedoraproject.org> In-Reply-To: 20160302174033.23493.60794@mailman01.phx2.fedoraproject.org --===============8051636639006280113== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable DISA produces OVAL content to align with the STIGS. Some of the content ma= y come from community repositories as a source. DISA maintained content ca= n be found at http://iase.disa.mil/stigs/scap/Pages/index.aspx. --===============8051636639006280113==-- From jason.w.mackanick.civ at mail.mil Thu Mar 3 15:36:34 2016 Content-Type: multipart/mixed; boundary="===============7310215626183406122==" MIME-Version: 1.0 From: Mackanick, Jason W CIV DISA RE (US) To: scap-security-guide at lists.fedorahosted.org Subject: Re: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Thu, 03 Mar 2016 15:05:05 +0000 Message-ID: <20160303150505.22438.42928@mailman01.phx2.fedoraproject.org> In-Reply-To: 20160301134854.15046.6018@mailman01.phx2.fedoraproject.org --===============7310215626183406122== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Mike, Actually just the opposite is occurring with SRG's and CCI's. NIST IR 8011= which is out in draft specifically discusses the same context of using "co= ntrol items" for granularity. CCI's are decomposed 800-53 controls which = are normally more targeted to being measurable. The same CCI may be met in= various operating systems by different methods. They were not intended to= be standard "rule" language. The document I was referencing can be review= ed at http://csrc.nist.gov/publications/drafts/nistir-8011/nistir_8011_ipd-= draft_vol1_overview.pdf DISA actually starts from the CCI's for requirements instead of doing a rev= erse mapping. This provides us a better picture in relation to risk or unm= et requirements which are levied down from the federal government through N= IST in the 800-53 controls and then into the DoD through the CNSS 1253 base= lines. DoD systems must be authorized and accredited based off of those ba= selines in accordance with how they categorize their information systems in= a similar process defined in the NIST 800-60. --===============7310215626183406122==-- From jlieskov at redhat.com Tue Mar 8 10:35:58 2016 Content-Type: multipart/mixed; boundary="===============7784123950151177624==" MIME-Version: 1.0 From: Jan Lieskovsky To: scap-security-guide at lists.fedorahosted.org Subject: Something less than a week left yet to register for SSG Contributor WorkShop #3 Date: Tue, 08 Mar 2016 05:35:45 -0500 Message-ID: <1274720752.36991756.1457433345131.JavaMail.zimbra@redhat.com> In-Reply-To: 2038617443.36990599.1457432849097.JavaMail.zimbra@redhat.com --===============7784123950151177624== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello folks, this is just a reminder there's still time to register for the upcoming SCAP Security Guide Contributor WorkShop #3: * When: Monday, March 14-th 10:00am - 12:00pm EDT * Topic: SSG content customization for Red Hat Satellite * Refs: - https://www.open-scap.org/ [1] - http://goo.gl/forms/p2jPy1kccl - https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guid= e-Contributor-WorkShop Looking forward to see you there && raise questions. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team [1] I would like to use this opportunity to thank Lenka Horakova for creati= ng the banner for this event on the open-scap.org portal page --===============7784123950151177624==-- From isimluk at fedoraproject.org Wed Mar 9 12:57:41 2016 Content-Type: multipart/mixed; boundary="===============2388494816486683275==" MIME-Version: 1.0 From: =?utf-8?q?=C5=A0imon_Luka=C5=A1=C3=ADk_=3Cisimluk_at_fedoraproject=2Eorg?= =?utf-8?q?=3E?= To: scap-security-guide at lists.fedorahosted.org Subject: Re: DISA STIG Release: What's purpose of "stig_refs.sh"? Date: Wed, 09 Mar 2016 13:58:42 +0100 Message-ID: <56E01E02.8050903@fedoraproject.org> In-Reply-To: 20160217141431.21097.47891@mailman01.phx2.fedoraproject.org --===============2388494816486683275== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/17/2016 03:14 PM, Mike Kuhnkey wrote: > Has someone checked out the script in DISA's STIG Release? ->U_Red_Hat_E= nterprise_Linux_7_V1R0-1_Manual_STIG/Test/stig_refs.sh > I find the instructions alarming on how to use the script. > It is to be placed in the RHEL 5 folder (scap-security-guide project) and= run..... > ....am I off in left field here? > What happens during make rhel7-dist -> content? > Is this where/how the DRAFT was created? More exactly the script reads: > # Extract the xccdf file into the root project folder (i.e. RHEL\5), I think we should replace "i.e." with "e.g." here. Given the script is = no longer used exclusive for RHEL-5. Thoughts? ~=C5=A1. --===============2388494816486683275==-- From swells at redhat.com Wed Mar 9 19:48:27 2016 Content-Type: multipart/mixed; boundary="===============0490648089322126386==" MIME-Version: 1.0 From: Shawn Wells To: scap-security-guide at lists.fedorahosted.org Subject: Re: DISA STIG Release: What's purpose of "stig_refs.sh"? Date: Wed, 09 Mar 2016 14:48:15 -0500 Message-ID: <56E07DFF.1070807@redhat.com> In-Reply-To: 56E01E02.8050903@fedoraproject.org --===============0490648089322126386== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 3/9/16 7:58 AM, =C5=A0imon Luka=C5=A1=C3=ADk wrote: > On 02/17/2016 03:14 PM, Mike Kuhnkey wrote: >> Has someone checked out the script in DISA's STIG Release? = >> ->U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_STIG/Test/stig_refs.sh >> I find the instructions alarming on how to use the script. >> It is to be placed in the RHEL 5 folder (scap-security-guide project) = >> and run..... >> ....am I off in left field here? >> What happens during make rhel7-dist -> content? >> Is this where/how the DRAFT was created? The PR that merged this was from Trey, almost a year ago: https://github.com/OpenSCAP/scap-security-guide/pull/452 IIRC, it's meant for content authoring, ensuring alignment between SSG = and FSO XCCDF rules. > More exactly the script reads: > > > # Extract the xccdf file into the root project folder (i.e. RHEL\5), > > I think we should replace "i.e." with "e.g." here. Given the script is = > no longer used exclusive for RHEL-5. Thoughts? Makes sense. --===============0490648089322126386==-- From mike.kuhnkey at att.net Wed Mar 9 21:09:19 2016 Content-Type: multipart/mixed; boundary="===============5087122105717657855==" MIME-Version: 1.0 From: Mike Kuhnkey To: scap-security-guide at lists.fedorahosted.org Subject: Re: How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams? Date: Wed, 09 Mar 2016 21:09:09 +0000 Message-ID: <20160309210909.25934.26676@mailman01.phx2.fedoraproject.org> In-Reply-To: 20160303150505.22438.42928@mailman01.phx2.fedoraproject.org --===============5087122105717657855== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable How does one reconcile (STIG) Cat-1, Cat-2, Cat-3 severity codes with, for = example Profile nist-cl-il-al (available in rhel-6)? Does oscap Profile = nist-cl-il-al qualify as a "collector" as discussed in the referenced nisti= r_8011_ipd-draft? --===============5087122105717657855==-- From jason.w.mackanick.civ at mail.mil Wed Mar 16 18:27:17 2016 Content-Type: multipart/mixed; boundary="===============1895926920445796760==" MIME-Version: 1.0 From: Mackanick, Jason W CIV DISA RE (US) To: scap-security-guide at lists.fedorahosted.org Subject: Potential SELinux inclusion in RHEL7 STIG Date: Wed, 16 Mar 2016 18:26:20 +0000 Message-ID: <8F1A307207E4214D943A26BA98F9ACB19882CD76@UMECHPA7F.easf.csd.disa.mil> --===============1895926920445796760== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I am here with Shawn Wells today and we would like your help in developing = the requirements for a possible inclusion of SELinux requirements to be in= cluded in the RHEL7 STIG. As we move away from legacy file permissions to = type enforcement, we would like to work with the community to understand se= curity relevant configuration options such as SELinux Booleans used in oper= ational environments. To calm any fears associated with SELinux, we are o= nly considering targeted policy and not the MLS enablement. Shawn will be = working to gather your input. Any of your input would be appreciated if we= could get it by Tuesday March 22, 2016 at the end of business. =20 --===============1895926920445796760==-- From isimluk at fedoraproject.org Mon Mar 21 14:43:04 2016 Content-Type: multipart/mixed; boundary="===============1265506315790597950==" MIME-Version: 1.0 From: =?utf-8?q?=C5=A0imon_Luka=C5=A1=C3=ADk_=3Cisimluk_at_fedoraproject=2Eorg?= =?utf-8?q?=3E?= To: scap-security-guide at lists.fedorahosted.org Subject: Re: Potential SELinux inclusion in RHEL7 STIG Date: Mon, 21 Mar 2016 15:44:21 +0100 Message-ID: <56F008C5.9010105@fedoraproject.org> In-Reply-To: 8F1A307207E4214D943A26BA98F9ACB19882CD76@UMECHPA7F.easf.csd.disa.mil --===============1265506315790597950== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote: > I am here with Shawn Wells today and we would like your help in developin= g the requirements for a possible inclusion of SELinux requirements to be = included in the RHEL7 STIG. As we move away from legacy file permissions t= o type enforcement, we would like to work with the community to understand = security relevant configuration options such as SELinux Booleans used in op= erational environments. To calm any fears associated with SELinux, we are= only considering targeted policy and not the MLS enablement. Shawn will b= e working to gather your input. Any of your input would be appreciated if = we could get it by Tuesday March 22, 2016 at the end of business. = > = Hello Jason, After talking with selinux crew here in Red Hat, I have learned that defaults for selinux booleans are set rather defensively. The default is always the more secure unless too generic use-case would be restricted. There is over 300 houndred selinux booleans in Red Hat Enterprise Linux 7. I wonder where we can start. Or do you have some specific booleans in mind? Perhaps it makes sense to go through these 300 hundreds and put them into some kind of buckets? Something like booleans that should absolutely always be true booleans that should always be false booleans that default to true, but operators may often need to turn them false ... booleans that default to true, but stig advices to keep them false ... Thoughts? ~=C5=A1. --===============1265506315790597950==-- From shawn at redhat.com Mon Mar 21 16:12:42 2016 Content-Type: multipart/mixed; boundary="===============1128516273211335904==" MIME-Version: 1.0 From: Shawn Wells To: scap-security-guide at lists.fedorahosted.org Subject: Re: Potential SELinux inclusion in RHEL7 STIG Date: Mon, 21 Mar 2016 12:12:23 -0400 Message-ID: <56F01D67.6070909@redhat.com> In-Reply-To: 56F008C5.9010105@fedoraproject.org --===============1128516273211335904== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 3/21/16 10:44 AM, =C5=A0imon Luka=C5=A1=C3=ADk wrote: > On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote: >> I am here with Shawn Wells today and we would like your help in developi= ng the requirements for a possible inclusion of SELinux requirements to be= included in the RHEL7 STIG. As we move away from legacy file permissions = to type enforcement, we would like to work with the community to understand= security relevant configuration options such as SELinux Booleans used in o= perational environments. To calm any fears associated with SELinux, we ar= e only considering targeted policy and not the MLS enablement. Shawn will = be working to gather your input. Any of your input would be appreciated if= we could get it by Tuesday March 22, 2016 at the end of business. >> > Hello Jason, > > After talking with selinux crew here in Red Hat, I have learned that > defaults for selinux booleans are set rather defensively. The default is > always the more secure unless too generic use-case would be restricted. > > There is over 300 houndred selinux booleans in Red Hat Enterprise Linux > 7. I wonder where we can start. Or do you have some specific booleans in > mind? > > Perhaps it makes sense to go through these 300 hundreds and put them > into some kind of buckets? Something like > > booleans that should absolutely always be true > booleans that should always be false > > booleans that default to true, but operators may often need to turn > them false > ... > > booleans that default to true, but stig advices to keep them false > ... > > Thoughts? To ensure everyone is on the same page of booleans, here's a list of the = ~300 RHEL7 booleans (output of 'semanage boolean -l'): http://people.redhat.com/swells/boolean_list.txt One of the things discussed with DISA was proper scoping of what a RHEL7 = STIG looks like. In the past, the RHEL STIGs have been a catch-all and = included configuration settings for things like OpenLDAP Server, HTTPD, = and other 3rd party software (defined as non Operation System = functionality). An example is the "all software library files must be {owned grouped = chmod'd}" rules. In such a case, the RHEL STIG *should* cover = RHEL-provided library files under /usr/lib/{kernel systemd} directories, = but not /usr/lib/3rd_party_app. Part of this descoping is the reflection that DISA's Application SRG = [0][1] has been maturing. 3rd party software deployments, such as java = middleware servers, should be covered by the Application SRG = requirements. Not lumped into the Operating System STIG. RHEL7 may ship SELinux booleans for 3rd party software (e.g. = httpd_can_connect_mythtv, or ftpd_connect_db) however their existence = doesn't correlate to inclusion in the *operating system* STIG. The above = booleans would appropriately placed in the Apache STIG or FTP Server = STIG, while the RHEL STIG should ensure SELinux is enforcing and should = have system-level booleans set (e.g. selinuxuser_execmod, = use_ecryptfs_home_dirs, staff_exec_content). Your buckets idea is really great. Through the above lens, perhaps we = can modify the groupings to something like below: - Operating System booleans that should be true - Operating System booleans that should be false - Non-OS booleans to include in 3rd party STIGs (helping DISA identify = these will expedite their inclusion in things like Apache and JBoss STIGs). When writing XCCDF rules, their description tag will included cases = where modification of setting may be called for. The OVAL side can use = selinuxboolean_test to automate everything. Thankfully remediation is a = bash 1-liner. [0] = http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SRG= .zip [1] = http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_me= mo.pdf --===============1128516273211335904== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRm LTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPC9oZWFkPgogIDxib2R5IGJnY29sb3I9 IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPgogICAgPGJyPgogICAgPGJyPgogICAgPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5PbiAzLzIxLzE2IDEwOjQ0IEFNLCDFoGltb24gTHVrYcWhw61r CiAgICAgIHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjU2 RjAwOEM1LjkwMTAxMDVAZmVkb3JhcHJvamVjdC5vcmciCiAgICAgIHR5cGU9ImNpdGUiPgogICAg ICA8cHJlIHdyYXA9IiI+T24gMDMvMTYvMjAxNiAwNzoyNiBQTSwgTWFja2FuaWNrLCBKYXNvbiBX IENJViBESVNBIFJFIChVUykgd3JvdGU6CjwvcHJlPgogICAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4KICAgICAgICA8cHJlIHdyYXA9IiI+SSBhbSBoZXJlIHdpdGggU2hhd24gV2VsbHMgdG9k YXkgYW5kIHdlIHdvdWxkIGxpa2UgeW91ciBoZWxwIGluIGRldmVsb3BpbmcgdGhlIHJlcXVpcmVt ZW50cyBmb3IgYSBwb3NzaWJsZSBpbmNsdXNpb24gb2YgIFNFTGludXggcmVxdWlyZW1lbnRzIHRv IGJlIGluY2x1ZGVkIGluIHRoZSBSSEVMNyBTVElHLiAgQXMgd2UgbW92ZSBhd2F5IGZyb20gbGVn YWN5IGZpbGUgcGVybWlzc2lvbnMgdG8gdHlwZSBlbmZvcmNlbWVudCwgd2Ugd291bGQgbGlrZSB0 byB3b3JrIHdpdGggdGhlIGNvbW11bml0eSB0byB1bmRlcnN0YW5kIHNlY3VyaXR5IHJlbGV2YW50 IGNvbmZpZ3VyYXRpb24gb3B0aW9ucyBzdWNoIGFzIFNFTGludXggQm9vbGVhbnMgdXNlZCBpbiBv cGVyYXRpb25hbCBlbnZpcm9ubWVudHMuICAgVG8gY2FsbSBhbnkgZmVhcnMgYXNzb2NpYXRlZCB3 aXRoIFNFTGludXgsIHdlIGFyZSBvbmx5IGNvbnNpZGVyaW5nIHRhcmdldGVkIHBvbGljeSBhbmQg bm90IHRoZSBNTFMgZW5hYmxlbWVudC4gIFNoYXduIHdpbGwgYmUgd29ya2luZyB0byBnYXRoZXIg eW91ciBpbnB1dC4gIEFueSBvZiB5b3VyIGlucHV0IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHdl IGNvdWxkIGdldCBpdCBieSBUdWVzZGF5IE1hcmNoIDIyLCAyMDE2IGF0IHRoZSBlbmQgb2YgYnVz aW5lc3MuICAKCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0iIj4K SGVsbG8gSmFzb24sCgpBZnRlciB0YWxraW5nIHdpdGggc2VsaW51eCBjcmV3IGhlcmUgaW4gUmVk IEhhdCwgSSBoYXZlIGxlYXJuZWQgdGhhdApkZWZhdWx0cyBmb3Igc2VsaW51eCBib29sZWFucyBh cmUgc2V0IHJhdGhlciBkZWZlbnNpdmVseS4gVGhlIGRlZmF1bHQgaXMKYWx3YXlzIHRoZSBtb3Jl IHNlY3VyZSB1bmxlc3MgdG9vIGdlbmVyaWMgdXNlLWNhc2Ugd291bGQgYmUgcmVzdHJpY3RlZC4K ClRoZXJlIGlzIG92ZXIgMzAwIGhvdW5kcmVkIHNlbGludXggYm9vbGVhbnMgaW4gUmVkIEhhdCBF bnRlcnByaXNlIExpbnV4CjcuIEkgd29uZGVyIHdoZXJlIHdlIGNhbiBzdGFydC4gT3IgZG8geW91 IGhhdmUgc29tZSBzcGVjaWZpYyBib29sZWFucyBpbgptaW5kPwoKUGVyaGFwcyBpdCBtYWtlcyBz ZW5zZSB0byBnbyB0aHJvdWdoIHRoZXNlIDMwMCBodW5kcmVkcyBhbmQgcHV0IHRoZW0KaW50byBz b21lIGtpbmQgb2YgYnVja2V0cz8gU29tZXRoaW5nIGxpa2UKCiAgYm9vbGVhbnMgdGhhdCBzaG91 bGQgYWJzb2x1dGVseSBhbHdheXMgYmUgdHJ1ZQogIGJvb2xlYW5zIHRoYXQgc2hvdWxkIGFsd2F5 cyBiZSBmYWxzZQoKICBib29sZWFucyB0aGF0IGRlZmF1bHQgdG8gdHJ1ZSwgYnV0IG9wZXJhdG9y cyBtYXkgb2Z0ZW4gbmVlZCB0byB0dXJuCnRoZW0gZmFsc2UKICAuLi4KCiAgYm9vbGVhbnMgdGhh dCBkZWZhdWx0IHRvIHRydWUsIGJ1dCBzdGlnIGFkdmljZXMgdG8ga2VlcCB0aGVtIGZhbHNlCiAg Li4uCgpUaG91Z2h0cz88L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIDxicj4KICAgIFRvIGVu c3VyZSBldmVyeW9uZSBpcyBvbiB0aGUgc2FtZSBwYWdlIG9mIGJvb2xlYW5zLCBoZXJlJ3MgYSBs aXN0IG9mCiAgICB0aGUgfjMwMCBSSEVMNyBib29sZWFucyAob3V0cHV0IG9mICdzZW1hbmFnZSBi b29sZWFuIC1sJyk6PGJyPgogICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iaHR0cDovL3Blb3BsZS5yZWRoYXQuY29tL3N3ZWxscy9ib29sZWFuX2xpc3QudHh0Ij5odHRw Oi8vcGVvcGxlLnJlZGhhdC5jb20vc3dlbGxzL2Jvb2xlYW5fbGlzdC50eHQ8L2E+PGJyPgogICAg PGJyPgogICAgT25lIG9mIHRoZSB0aGluZ3MgZGlzY3Vzc2VkIHdpdGggRElTQSB3YXMgcHJvcGVy IHNjb3Bpbmcgb2Ygd2hhdCBhCiAgICBSSEVMNyBTVElHIGxvb2tzIGxpa2UuIEluIHRoZSBwYXN0 LCB0aGUgUkhFTCBTVElHcyBoYXZlIGJlZW4gYQogICAgY2F0Y2gtYWxsIGFuZCBpbmNsdWRlZCBj b25maWd1cmF0aW9uIHNldHRpbmdzIGZvciB0aGluZ3MgbGlrZQogICAgT3BlbkxEQVAgU2VydmVy LCBIVFRQRCwgYW5kIG90aGVyIDNyZCBwYXJ0eSBzb2Z0d2FyZSAoZGVmaW5lZCBhcyBub24KICAg IE9wZXJhdGlvbiBTeXN0ZW0gZnVuY3Rpb25hbGl0eSkuIDxicj4KICAgIDxicj4KICAgIEFuIGV4 YW1wbGUgaXMgdGhlICJhbGwgc29mdHdhcmUgbGlicmFyeSBmaWxlcyBtdXN0IGJlIHtvd25lZCBn cm91cGVkCiAgICBjaG1vZCdkfSIgcnVsZXMuIEluIHN1Y2ggYSBjYXNlLCB0aGUgUkhFTCBTVElH ICpzaG91bGQqIGNvdmVyCiAgICBSSEVMLXByb3ZpZGVkIGxpYnJhcnkgZmlsZXMgdW5kZXIgL3Vz ci9saWIve2tlcm5lbCBzeXN0ZW1kfQogICAgZGlyZWN0b3JpZXMsIGJ1dCBub3QgL3Vzci9saWIv M3JkX3BhcnR5X2FwcC48YnI+CiAgICA8YnI+CiAgICBQYXJ0IG9mIHRoaXMgZGVzY29waW5nIGlz IHRoZSByZWZsZWN0aW9uIHRoYXQgRElTQSdzIEFwcGxpY2F0aW9uIFNSRwogICAgWzBdWzFdIGhh cyBiZWVuIG1hdHVyaW5nLiAzcmQgcGFydHkgc29mdHdhcmUgZGVwbG95bWVudHMsIHN1Y2ggYXMK ICAgIGphdmEgbWlkZGxld2FyZSBzZXJ2ZXJzLCBzaG91bGQgYmUgY292ZXJlZCBieSB0aGUgQXBw bGljYXRpb24gU1JHCiAgICByZXF1aXJlbWVudHMuIE5vdCBsdW1wZWQgaW50byB0aGUgT3BlcmF0 aW5nIFN5c3RlbSBTVElHLjxicj4KICAgIDxicj4KICAgIFJIRUw3IG1heSBzaGlwIFNFTGludXgg Ym9vbGVhbnMgZm9yIDNyZCBwYXJ0eSBzb2Z0d2FyZSAoZS5nLgogICAgaHR0cGRfY2FuX2Nvbm5l Y3RfbXl0aHR2LCBvciBmdHBkX2Nvbm5lY3RfZGIpIGhvd2V2ZXIgdGhlaXIKICAgIGV4aXN0ZW5j ZSBkb2Vzbid0IGNvcnJlbGF0ZSB0byBpbmNsdXNpb24gaW4gdGhlICpvcGVyYXRpbmcgc3lzdGVt KgogICAgU1RJRy4gVGhlIGFib3ZlIGJvb2xlYW5zIHdvdWxkIGFwcHJvcHJpYXRlbHkgcGxhY2Vk IGluIHRoZSBBcGFjaGUKICAgIFNUSUcgb3IgRlRQIFNlcnZlciBTVElHLCB3aGlsZSB0aGUgUkhF TCBTVElHIHNob3VsZCBlbnN1cmUgU0VMaW51eAogICAgaXMgZW5mb3JjaW5nIGFuZCBzaG91bGQg aGF2ZSBzeXN0ZW0tbGV2ZWwgYm9vbGVhbnMgc2V0IChlLmcuCiAgICBzZWxpbnV4dXNlcl9leGVj bW9kLCB1c2VfZWNyeXB0ZnNfaG9tZV9kaXJzLCBzdGFmZl9leGVjX2NvbnRlbnQpLgogICAgPG1l dGEgY2hhcnNldD0idXRmLTgiPgogICAgPGJyPgogICAgPGJyPgogICAgPG1ldGEgY2hhcnNldD0i dXRmLTgiPgogICAgPG1ldGEgY2hhcnNldD0idXRmLTgiPgogICAgWW91ciBidWNrZXRzIGlkZWEg aXMgcmVhbGx5IGdyZWF0LiBUaHJvdWdoIHRoZSBhYm92ZSBsZW5zLCBwZXJoYXBzCiAgICB3ZSBj YW4gbW9kaWZ5IHRoZSBncm91cGluZ3MgdG8gc29tZXRoaW5nIGxpa2UgYmVsb3c6PGJyPgogICAg PGJyPgogICAgLSBPcGVyYXRpbmcgU3lzdGVtIGJvb2xlYW5zIHRoYXQgc2hvdWxkIGJlIHRydWUg PGJyPgogICAgLSBPcGVyYXRpbmcgU3lzdGVtIGJvb2xlYW5zIHRoYXQgc2hvdWxkIGJlIGZhbHNl PGJyPgogICAgLSBOb24tT1MgYm9vbGVhbnMgdG8gaW5jbHVkZSBpbiAzcmQgcGFydHkgU1RJR3Mg KGhlbHBpbmcgRElTQQogICAgaWRlbnRpZnkgdGhlc2Ugd2lsbCBleHBlZGl0ZSB0aGVpciBpbmNs dXNpb24gaW4gdGhpbmdzIGxpa2UgQXBhY2hlCiAgICBhbmQgSkJvc3MgU1RJR3MpLjxicj4KICAg IDxicj4KICAgIFdoZW4gd3JpdGluZyBYQ0NERiBydWxlcywgdGhlaXIgZGVzY3JpcHRpb24gdGFn IHdpbGwgaW5jbHVkZWQgY2FzZXMKICAgIHdoZXJlIG1vZGlmaWNhdGlvbiBvZiBzZXR0aW5nIG1h eSBiZSBjYWxsZWQgZm9yLiBUaGUgT1ZBTCBzaWRlIGNhbgogICAgdXNlCiAgICA8bWV0YSBjaGFy c2V0PSJ1dGYtOCI+CiAgICBzZWxpbnV4Ym9vbGVhbl90ZXN0IHRvIGF1dG9tYXRlIGV2ZXJ5dGhp bmcuIFRoYW5rZnVsbHkgcmVtZWRpYXRpb24KICAgIGlzIGEgYmFzaCAxLWxpbmVyLjxicj4KICAg IDxicj4KICAgIFswXQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw Oi8vaWFzZWNvbnRlbnQuZGlzYS5taWwvc3RpZ3MvemlwL09jdDIwMTUvVV9BcHBsaWNhdGlvbl9T ZXJ2ZXJfVjJSMl9TUkcuemlwIj5odHRwOi8vaWFzZWNvbnRlbnQuZGlzYS5taWwvc3RpZ3Mvemlw L09jdDIwMTUvVV9BcHBsaWNhdGlvbl9TZXJ2ZXJfVjJSMl9TUkcuemlwPC9hPjxicj4KICAgIFsx XQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vaWFzZS5kaXNh Lm1pbC9zdGlncy9Eb2N1bWVudHMvdV9hcHBsaWNhdGlvbl9zZXJ2ZXJfc3JnX3YyX3JlbGVhc2Vf bWVtby5wZGYiPmh0dHA6Ly9pYXNlLmRpc2EubWlsL3N0aWdzL0RvY3VtZW50cy91X2FwcGxpY2F0 aW9uX3NlcnZlcl9zcmdfdjJfcmVsZWFzZV9tZW1vLnBkZjwvYT48YnI+CiAgPC9ib2R5Pgo8L2h0 bWw+Cg== --===============1128516273211335904==-- From brandon at quarksecurity.com Mon Mar 21 16:37:33 2016 Content-Type: multipart/mixed; boundary="===============3773489042466457272==" MIME-Version: 1.0 From: Brandon Whalen To: scap-security-guide at lists.fedorahosted.org Subject: Re: Potential SELinux inclusion in RHEL7 STIG Date: Mon, 21 Mar 2016 12:37:19 -0400 Message-ID: In-Reply-To: 56F01D67.6070909@redhat.com --===============3773489042466457272== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Mar 21, 2016, at 12:12 PM, Shawn Wells wrote: > = > = > = > On 3/21/16 10:44 AM, =C5=A0imon Luka=C5=A1=C3=ADk wrote: >> On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote: >> = >>> I am here with Shawn Wells today and we would like your help in develop= ing the requirements for a possible inclusion of SELinux requirements to b= e included in the RHEL7 STIG. As we move away from legacy file permissions= to type enforcement, we would like to work with the community to understan= d security relevant configuration options such as SELinux Booleans used in = operational environments. To calm any fears associated with SELinux, we a= re only considering targeted policy and not the MLS enablement. Shawn will= be working to gather your input. Any of your input would be appreciated i= f we could get it by Tuesday March 22, 2016 at the end of business. = >>> = >>> = >> Hello Jason, >> = >> After talking with selinux crew here in Red Hat, I have learned that >> defaults for selinux booleans are set rather defensively. The default is >> always the more secure unless too generic use-case would be restricted. >> = >> There is over 300 houndred selinux booleans in Red Hat Enterprise Linux >> 7. I wonder where we can start. Or do you have some specific booleans in >> mind? >> = >> Perhaps it makes sense to go through these 300 hundreds and put them >> into some kind of buckets? Something like >> = >> booleans that should absolutely always be true >> booleans that should always be false >> = >> booleans that default to true, but operators may often need to turn >> them false >> ... >> = >> booleans that default to true, but stig advices to keep them false >> ... >> = >> Thoughts? >> = > = > To ensure everyone is on the same page of booleans, here's a list of the = ~300 RHEL7 booleans (output of 'semanage boolean -l'): > http://people.redhat.com/swells/boolean_list.txt > = > One of the things discussed with DISA was proper scoping of what a RHEL7 = STIG looks like. In the past, the RHEL STIGs have been a catch-all and incl= uded configuration settings for things like OpenLDAP Server, HTTPD, and oth= er 3rd party software (defined as non Operation System functionality). = > = > An example is the "all software library files must be {owned grouped chmo= d'd}" rules. In such a case, the RHEL STIG *should* cover RHEL-provided lib= rary files under /usr/lib/{kernel systemd} directories, but not /usr/lib/3r= d_party_app. > = > Part of this descoping is the reflection that DISA's Application SRG [0][= 1] has been maturing. 3rd party software deployments, such as java middlewa= re servers, should be covered by the Application SRG requirements. Not lump= ed into the Operating System STIG. > = > RHEL7 may ship SELinux booleans for 3rd party software (e.g. httpd_can_co= nnect_mythtv, or ftpd_connect_db) however their existence doesn't correlate= to inclusion in the *operating system* STIG. The above booleans would appr= opriately placed in the Apache STIG or FTP Server STIG, while the RHEL STIG= should ensure SELinux is enforcing and should have system-level booleans s= et (e.g. selinuxuser_execmod, use_ecryptfs_home_dirs, staff_exec_content). = > = > Your buckets idea is really great. Through the above lens, perhaps we can= modify the groupings to something like below: > = > - Operating System booleans that should be true = > - Operating System booleans that should be false > - Non-OS booleans to include in 3rd party STIGs (helping DISA identify th= ese will expedite their inclusion in things like Apache and JBoss STIGs). > = > When writing XCCDF rules, their description tag will included cases where= modification of setting may be called for. The OVAL side can use selinuxbo= olean_test to automate everything. Thankfully remediation is a bash 1-liner. > = > [0] http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2= R2_SRG.zip > [1] http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_rele= ase_memo.pdf We have customers that must meet the STIG requirements but also need to hav= e custom policy written. Who is the intended audience that must meet this r= equirement? I would assume it=E2=80=99s all federal systems running RHEL 7.= I have some concerns about failing STIG checks and getting push back becau= se of it. I know that for the majority of the government these STIG checks = will actually be a good thing and will help them ensure that the SELinux po= licy is the most =E2=80=9Csecure" state possible given their environment. H= owever, I want to understand how this change might impact those of us that = do more customization of the policy or completely replace it with one of ou= r own. I=E2=80=99d imagine that it would just be a documentation exercise t= o state that the solution has custom policy but hopefully the audience on t= his list can validate that assumption. > -- > SCAP Security Guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/scap-security-guide(a)lists.fe= dorahosted.org > https://github.com/OpenSCAP/scap-security-guide/ --===============3773489042466457272==-- From dan.warburton at jvncomm.com Wed Mar 23 10:12:19 2016 Content-Type: multipart/mixed; boundary="===============5564133468003449916==" MIME-Version: 1.0 From: Dan Warburton To: scap-security-guide at lists.fedorahosted.org Subject: cnssi No 1253 profile needed Date: Tue, 22 Mar 2016 15:36:27 -0400 Message-ID: <2134980131.181930.b96bf386-6bf5-48b2-b57a-c7a52ad2110f.open-xchange@email.1and1.com> In-Reply-To: 8F1A307207E4214D943A26BA98F9ACB19882CD76@UMECHPA7F.easf.csd.disa.mil --===============5564133468003449916== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --===============5564133468003449916== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PCFET0NUWVBFIGh0bWw+CjxodG1sPjxoZWFkPgogICAgPG1ldGEgY2hhcnNldD0iVVRGLTgiPgo8 L2hlYWQ+PGJvZHk+PHA+PGJyPjwvcD48cD5odHRwOi8vc3RhdGljLm9wZW4tc2NhcC5vcmcvc3Nn LWd1aWRlcy9zc2ctcmhlbDYtZ3VpZGUtbmlzdC1jbC1pbC1hbC5odG1sPC9wPjxwPjxlbT5JIGNh bm5vdCBsb2NhdGUgdGhpcyBndWlkZS4gSSBoYXZlIHJlZGhhdCBzY2FwLXNlY3VyaXR5LWd1aWRl IDAuMTAuMjEtMy5lbDYgd2hpY2ggeXVtIHNheXMgaXMgdGhlIGxhdGVzdC48L2VtPjxicj48L3A+ PHA+PGVtPkkgdGhpbmsgdGhlIHByb2ZpbGUgZm9yIE5hdGlvbmFsIFNlY3VyaXR5IFN5c3RlbXMg SW5zdHJ1Y3Rpb24gKENOU1NJKSBOby4gMTI1MywgJiMzNDtTZWN1cml0eSBDYXRlZ29yaXphdGlv biBhbmQgQ29udHJvbCBTZWxlY3Rpb24gZm9yIE5hdGlvbmFsIFNlY3VyaXR5IFN5c3RlbXMmIzM0 OyYjMzQ7PGJyPjwvZW0+PC9wPjxwPjxlbT48YnI+PC9lbT48L3A+PHA+PGVtPkhvdyBjYW4gSSBn ZXQgdGhpcz8gcnBtIHByZWZlcnJlZDxicj48L2VtPjwvcD48cD48ZW0+PGJyPjwvZW0+PC9wPjxw PjxlbT5UaGFua3MuPGJyPjwvZW0+PC9wPjwvYm9keT48L2h0bWw+CiA= --===============5564133468003449916==-- From jlieskov at redhat.com Wed Mar 23 10:25:35 2016 Content-Type: multipart/mixed; boundary="===============2253692051094402393==" MIME-Version: 1.0 From: Jan Lieskovsky To: scap-security-guide at lists.fedorahosted.org Subject: Re: cnssi No 1253 profile needed Date: Wed, 23 Mar 2016 06:25:21 -0400 Message-ID: <2027304069.45114192.1458728721372.JavaMail.zimbra@redhat.com> In-Reply-To: 2134980131.181930.b96bf386-6bf5-48b2-b57a-c7a52ad2110f.open-xchange@email.1and1.com --===============2253692051094402393== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Daniel, thank you for contacting us. ----- Original Message ----- > From: "Dan Warburton" > To: "SCAP Security Guide" > Sent: Tuesday, March 22, 2016 8:36:27 PM > Subject: cnssi No 1253 profile needed > = > = > = > = > = > = > http://static.open-scap.org/ssg-guides/ssg-rhel6-guide-nist-cl-il-al.html > = > I cannot locate this guide. I have redhat scap-security-guide 0.10.21-3.e= l6 > which yum says is the latest. This (CNSSI No. 1253) profile has been introduced starting from upstream scap-security-guide-0.1.27 release: [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.27 thus as such is not included in scap-security-guide-0.1.21-3.el6 version yet you mention above. > = > = > I think the profile for National Security Systems Instruction (CNSSI) No. > 1253, "Security Categorization and Control Selection for National Security > Systems"" > = > = > = > = > = > How can I get this? rpm preferred AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM ba= sed on upstream 0.1.28 version already: http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-now-= available therefore you can obtain the updated scap-security-guide RPM from that rele= ase for now, till the moment Red Hat Enterprise Linux 6 Update 8 is generally available. Hope this helps. Let us know if we can be of any further guidance. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > = > = > = > = > = > Thanks. > = > -- > SCAP Security Guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/scap-security-guide(a)lists.fe= dorahosted.org > https://github.com/OpenSCAP/scap-security-guide/ >=20 --===============2253692051094402393==-- From lhorakov at redhat.com Wed Mar 23 10:45:02 2016 Content-Type: multipart/mixed; boundary="===============1516250112904630346==" MIME-Version: 1.0 From: Lenka Horakova To: scap-security-guide at lists.fedorahosted.org Subject: OpenSCAP asking for your feedback Date: Wed, 23 Mar 2016 06:36:40 -0400 Message-ID: <1722928888.73146125.1458729400858.JavaMail.zimbra@redhat.com> In-Reply-To: 1859736276.73139508.1458728912320.JavaMail.zimbra@redhat.com --===============1516250112904630346== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello everyone, = OpenSCAP team is going to collect user feedback about SCAP Workbench GUI to= ol . If you are SCAP Workbench user, we would like to hear from you regardi= ng your experiences with the product. = If you are interested, please subscribe here: = http://goo.gl/forms/kmb1OolUdR = Once we receive your contact information, we will let you know about differ= ent feedback opportunities. = Have a nice day everyone, = Lenka Hor=C3=A1kov=C3=A1 = Associate Software Engineer, UX = Red Hat = --===============1516250112904630346== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWw+PGJvZHk+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbiwgbmV3 IHlvcmssIHRpbWVzLCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCI+PGRp dj5IZWxsbyBldmVyeW9uZSw8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PcGVuU0NBUCB0 ZWFtIGlzIGdvaW5nIHRvIGNvbGxlY3QgdXNlcjxzdHJvbmc+IGZlZWRiYWNrIGFib3V0IFNDQVAg V29ya2JlbmNoIEdVSSB0b29sPC9zdHJvbmc+LiBJZiB5b3UgYXJlIFNDQVAgV29ya2JlbmNoIHVz ZXIsIHdlIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIHlvdSByZWdhcmRpbmcgeW91ciBleHBlcmll bmNlcyB3aXRoIHRoZSBwcm9kdWN0Ljxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIHlv dSBhcmUgaW50ZXJlc3RlZCwgcGxlYXNlIHN1YnNjcmliZSBoZXJlOjxicj48YSB0YXJnZXQ9Il9i bGFuayIgaHJlZj0iaHR0cDovL2dvby5nbC9mb3Jtcy9rbWIxT29sVWRSIiBkYXRhLW1jZS1ocmVm PSJodHRwOi8vZ29vLmdsL2Zvcm1zL2ttYjFPb2xVZFIiPmh0dHA6Ly9nb28uZ2wvZm9ybXMva21i MU9vbFVkUjwvYT4gPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+T25jZSB3ZSByZWNlaXZl IHlvdXIgY29udGFjdCBpbmZvcm1hdGlvbiwgd2Ugd2lsbCBsZXQgeW91IGtub3cgYWJvdXQgZGlm ZmVyZW50IGZlZWRiYWNrIG9wcG9ydHVuaXRpZXMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5IYXZlIGEgbmljZSBkYXkgZXZlcnlvbmUsPGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+TGVua2EgSG9yw6Frb3bDoTxicj48L2Rpdj48ZGl2PkFzc29jaWF0ZSBTb2Z0 d2FyZSBFbmdpbmVlciwgVVg8YnI+PC9kaXY+PGRpdj5SZWQgSGF0PGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --===============1516250112904630346==-- From shawn at redhat.com Thu Mar 24 16:48:31 2016 Content-Type: multipart/mixed; boundary="===============4232596262878760055==" MIME-Version: 1.0 From: Shawn Wells To: scap-security-guide at lists.fedorahosted.org Subject: Re: cnssi No 1253 profile needed Date: Thu, 24 Mar 2016 12:48:20 -0400 Message-ID: <56F41A54.6030205@redhat.com> In-Reply-To: 2027304069.45114192.1458728721372.JavaMail.zimbra@redhat.com --===============4232596262878760055== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 3/23/16 6:25 AM, Jan Lieskovsky wrote: > Hello Daniel, > > thank you for contacting us. > > ----- Original Message ----- >> >From: "Dan Warburton" >> >To: "SCAP Security Guide" >> >Sent: Tuesday, March 22, 2016 8:36:27 PM >> >Subject: cnssi No 1253 profile needed >> > >> > >> > >> > >> > >> > >> >http://static.open-scap.org/ssg-guides/ssg-rhel6-guide-nist-cl-il-al.ht= ml >> > >> >I cannot locate this guide. I have redhat scap-security-guide 0.10.21-3= .el6 >> >which yum says is the latest. > This (CNSSI No. 1253) profile has been introduced starting from upstream > scap-security-guide-0.1.27 release: > [1]https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.27 > > thus as such is not included in scap-security-guide-0.1.21-3.el6 version = yet > you mention above. > >> > >> > >> >I think the profile for National Security Systems Instruction (CNSSI) N= o. >> >1253, "Security Categorization and Control Selection for National Secur= ity >> >Systems"" >> > >> > >> > >> > >> > >> >How can I get this? rpm preferred > AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM = based on > upstream 0.1.28 version already: > > http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-n= ow-available > > therefore you can obtain the updated scap-security-guide RPM from that re= lease for now, > till the moment Red Hat Enterprise Linux 6 Update 8 is generally availabl= e. > > > Hope this helps. > > Let us know if we can be of any further guidance. Direct link to the beta RPM: https://access.redhat.com/downloads/content/rhel---6/x86_64/160/scap-securi= ty-guide/0.1.28-2.el6/noarch/f21541eb/package In regards to a CNSSI profile, we're trying to sort out what that'd = actually mean. NSA's CNSSI 12-53 is different than NRO, which is = different than DISA... who's CNSSI 12-53 overlay to we follow? What = would be most useful/applicable? --===============4232596262878760055==--