From: scap-security-guide-bounces(a)lists.fedorahosted.org [scap-security-guide-bounces(a)lists.fedorahosted.org] on >behalf of Kevin Spargur [kspargur(a)redhat.com] Sent: Thursday, March 15, 2012 10:01 AM To: scap-security-guide(a)lists.fedorahosted.org Subject: SSG M1 Objectives Hey all, I've done a quick review of the SSG as far as were we stand in comparison milestone 1 objectives. We are missing roughly 195/634 or about 31% of the line items needed to meet milestone 1. The exact line items missing are specified in the attached. I've opened tickets for each piece up on the SSG site (https://fedorahosted.org/scap-security-guide/report/2). If your working on a section it would be great if you took the ticket so we can try and avoid duplication of effort where possible. Thanks, Kevin Spargur

> It looks like if we want to achieve the "prose guide, with desktop and server profiles > and content" milestones, content needs to be added to a couple of places: > > 1) The prose and rationale need to be added to rhel6/src/input/services or > rhel6/src/input/system, depending upon what's being addressed. Yes, this meets the M1.1 objective to have a "human-readable prose guide, with level of completeness and quality similar to the NSA SNAC RHEL 5 guide" as well as the M1.3 objective to have rationale for all rules in the desktop and server profiles.

On 03/20/2012 03:40 PM, Michael Palmiotto wrote: >>> It looks like if we want to achieve the "prose guide, with desktop >>> and server profiles >>> and content" milestones, content needs to be added to a couple of >>> places: >>> >>> 1) The prose and rationale need to be added to >>> rhel6/src/input/services or >>> rhel6/src/input/system, depending upon what's being addressed. >> Yes, this meets the M1.1 objective to have a "human-readable prose >> guide, with level of completeness and quality similar to the NSA SNAC >> RHEL 5 guide" as well as the M1.3 objective to have rationale for all >> rules in the desktop and server profiles. > Just for clarification: > If a service Group has a Rule with system settings (ie Group: > "Configure Squid" > and Rule: "Configure iptables to Allow Access to the Proxy Server") > should the Group > be added to both rhel6/src/input/service and system? > > Or would the Rule just be added to service? It seems like we'd want > some way of > relating system settings prose back to the service that necessitates it. I'd only add the group and rule to the service. We definitely want to avoid duplication of rules in different sections. Remember that the files in the service and and system directories are all merged together into a single xccdf via make at the end state. The breakdown into various folders and files is really just a means to facilitate collaboration. -Kevin > > --Mike > >> -Kevin >>> --Mike _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide

To aid in the automation of OVAL checks, I've written a script that generates the check.xmls to test for lines being properly added to config files. Attached you'll find the example template and the output for 2.6.2.4.6 Record Attempts to Alter Process and Session Initiation Information. The file "test_input_1_entry" has the relevant lines for the addition of a test: oval_id: title: "Title of Check" cces: "CCE-#, CCE-#" desc: "Description of check" tests: test_name_1: filepath: "Path of file to be checked" filename: "Name of file to be checked" line: "Text that needs to be added to the file" The template file, "template_file_entries" is similar to the current template files, with tags for oval_id, title, cces, desc, tests, etc: <def-group> <!-- THIS FILE IS GENERATED by create_file_entries.py. DO NOT EDIT. --> <definition class="compliance" id="TESTID" version="1"> <metadata> <title>TESTTITLE</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <reference ref_id="CCE_ID" source="CCE" /> <description>DESC</description> </metadata> <criteria operator = "AND"> <criterion comment="" test_ref="test_TESTID_TESTNAME" /> </criteria> </definition> <ind:textfilecontent54_test check="all" comment="" id="test_TESTID_TESTNAME" version="1"> <ind:object object_ref="object_TESTID_TESTNAME" /> </ind:textfilecontent54_test> <ind:textfilecontent54_object id="object_TESTID_TESTNAME" version="1"> <ind:filepath>FILEPATH</ind:filepath> <ind:filename>FILENAME</ind:filename> <ind:pattern operation="pattern match">FILE_LINE</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object> </def-group> Any feedback on this would be greatly appreciated. I've attached the script and a test input file. --Mike _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide

Hey all, I've done a quick review of the SSG as far as were we stand in comparison milestone 1 objectives. We are missing roughly 195/634 or about 31% of the line items needed to meet milestone 1. The exact line items missing are specified in the attached. I've opened tickets for each piece up on the SSG site (https://fedorahosted.org/scap-security-guide/report/2). If your working on a section it would be great if you took the ticket so we can try and avoid duplication of effort where possible. Thanks, Kevin Spargur _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide

These are some great points. Any objection to modifying the wiki to incorporate them? -Kevin On 03/16/2012 04:27 PM, Jeffrey Blank wrote: > Wow, that's a great list. However, I am (slightly) worried about high > speed copy-paste from the RHEL 5 SNAC guide into the project. > > A few quick notes: > > 1) > If a section seems to have been completed previously (by me) but > something is oddly missing, ask. There may be reasons some things were > not moved. > > 2) > If there is a section in the SNAC guide that is instructive but which > cannot possibly have an OVAL check (such as for BIOS settings), just > put the information into an XCCDF Group. Later, we can create OCIL > content to handle things that will absolutely require manual > inspection (or relate to policy/procedures). > > Similarly, if a section has discussed doing something that is > necessary/relevant but on its own is really a configuration action > (and not a security setting), such as installing some network service, > this should be in an XCCDF Group and not a Rule. Rules are only for > compliance checking. For example, I don't think we need to verify that > httpd is installed, even if a system is being evaluated against a web > server profile (and please let's save the "value of checking for > packaged vs unpackaged software" discussion for another time). > > 3) > In general, please try to perform a positive and negative test for > each item. I'd really appreciate one round of QA prior to a commit/push. > > 4) > Feel free to reorganize if you can improve on the original logical > structure (but ask the list if it's significant). > > And of course, everything's negotiable. But these were some of my > personal guidelines when committing content earlier, and I think they > will serve us well. > > Jeff > > > > On 03/15/2012 10:01 AM, Kevin Spargur wrote: >> Hey all, >> >> I've done a quick review of the SSG as far as were we stand in >> comparison milestone 1 objectives. We are missing roughly 195/634 or >> about 31% of the line items needed to meet milestone 1. The exact line >> items missing are specified in the attached. I've opened tickets for >> each piece up on the SSG site >> (https://fedorahosted.org/scap-security-guide/report/2). If your working >> on a section it would be great if you took the ticket so we can try and >> avoid duplication of effort where possible. >> >> Thanks, >> >> Kevin Spargur >> >> >> _______________________________________________ >> scap-security-guide mailing list >> scap-security-guide(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide

> If there is a section in the SNAC guide that is instructive but which > cannot possibly have an OVAL check (such as for BIOS settings), just > put the information into an XCCDF Group. Later, we can create OCIL > content to handle things that will absolutely require manual > inspection (or relate to policy/procedures). There is a down side to this in that we can't attach ident/ref's to groups. We could always just list the controls in the description for these but it seems very kludgy. Putting rules in for these and making do with the unknown in the results would probably serve us better in the long run. Any and all unknown results should be reviewed manually anyway.