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
From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on >behalf of Kevin Spargur [kspargur@redhat.com] Sent: Thursday, March 15, 2012 10:01 AM To: scap-security-guide@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
I'm working on some of the Incomplete Guidance tickets (#40, #23, 26), and I just wanted to verify that I've got a handle on what needs to be done. Correct me if there's something I'm missing.
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.
2) A check xml needs to be added to rhel6/src/input/checks, with the id matching the file name.
3) The proper idref needs to be added to an xml in rhel6/src/input/profiles
When does a new xml file need to be added to rhel6/src/input/profiles/ (as was done with ftp)?
--Mike
On 03/16/2012 10:49 AM, Michael Palmiotto wrote:
From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on>behalf of Kevin Spargur [kspargur@redhat.com] Sent: Thursday, March 15, 2012 10:01 AM To: scap-security-guide@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
I'm working on some of the Incomplete Guidance tickets (#40, #23, 26), and I just wanted to verify that I've got a handle on what needs to be done. Correct me if there's something I'm missing.
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:
- 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.
- A check xml needs to be added to rhel6/src/input/checks, with the id matching
the file name.
Per the M1.2 objective we need associated SCAP content (selected by XCCDF profiles, and fully automated with OVAL) for server and desktop profiles. This raises the question of what specifically should be in those profiles. In my mind, they should at least have all the system setting rules as well as obsolete and base services. From there we can add as appropriate, such as X for desktop, but I think that would provide a strong base.
- The proper idref needs to be added to an xml in rhel6/src/input/profiles
When does a new xml file need to be added to rhel6/src/input/profiles/ (as was done with ftp)?
This ties back into the M1.2 requirement where we need profiles for server and desktop. Adding the ftp profile is actually beyond the scope of what is needed for the first milestone. There was discussion about releasing an alpha when we hit that milestone and the ftp profile springs from those talks. The alpha release would be significantly more useful if a few common deployments had profiles available. The suggestion was made that including ftp and httpd profiles would help to get more people involved.
-Kevin
--Mike
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:
- 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.
--Mike
-Kevin
--Mike
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:
- 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
Yes, exactly. It was just a means of logical organization; there's nothing else to it. And some choices were arbitrary/arguable.
Here was the basic thinking:
A service (rc script) that's tied to truly essential system-wide functionality (such audit, logging, and network), and which also has other configuration discussion, can go into input/system. All the others can go into Services. (One could argue cron either way, of course, but looks like it landed into services.)
I noticed that a duplicate or two may have sneaked into services/base.xml (like auditd). That one (and any other dups) should be removed from there. "Base services" was really just a means of grouping potpourri that may not call for lengthier discussion (due to limited configuration options, or limited importance).
If you think something should be placed elsewhere, lemme know. The idea is that the resulting document order (whether prose or a table) should group semantically-related things together.
On 03/20/2012 04:18 PM, Kevin Spargur wrote:
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:
- 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@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:filepathFILEPATH</ind:filepath> ind:filenameFILENAME</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
A few things (and changing subject properly):
1) Is this solving a problem we really have right now? I don't really think it is, but I'm open to being corrected.
2) This is also too clever. The clean_line function (in the patch) has regexes to edit regexes. The script is also doing its own parsing of its own format (instead of using existing parsers for JSON or XML or CSV or whatever).
For now I don't see this simplifying the creation of content more than it complicates the maintenance/comprehension overhead. If we suddenly need to do more line edits, let's revisit. I also have a draft XSLT that might fit the bill (but I'm also not convinced it solves more problems than it creates).
On 03/30/2012 02:48 PM, Michael Palmiotto wrote:
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 3/16/12 10:49 AM, Michael Palmiotto wrote:
From:scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on>behalf of Kevin Spargur [kspargur@redhat.com]
Sent: Thursday, March 15, 2012 10:01 AM To:scap-security-guide@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
I'm working on some of the Incomplete Guidance tickets (#40, #23, 26), and I just wanted to verify that I've got a handle on what needs to be done. Correct me if there's something I'm missing.
Thanks for jumping in Michael! Can you assign those tickets to yourself?
(1) Head to https://fedorahosted.org/scap-security-guide/report/1 (2) Click on your ticket (3) Click on modify (top right) (4) Near the bottom, under "Action" panel, select "accept" then Submit Changes
I'd reassign them to you, but I don't know your fedora username.
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@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:
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.
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).
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.
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
No objections, please go for it.
The "How to make XCCDF/OVAL" wiki pages are a bit out of date; the OVAL, in particular, does not mention the templates/ directory which is used to make a lot of the checks. Adding in expectations is also a great idea. (We generally expect soundness but not necessarily completeness, which is itself difficult to define.)
If there's concern about the level of completeness of research about security-relevant settings for a particular service (and it be sound-but-not-necessarily-complete), making another ticket for further research is always a good idea.
On 03/16/2012 11:00 PM, Kevin Spargur wrote:
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:
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.
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).
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.
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
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:
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.
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.
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).
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.
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@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.
You're right. These should probably be things which are Rules, but which are really awaiting OCIL checks. I'd forgotten to mention that that's where we really want to go.
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Kevin Spargur -
Mike Palmiotto -
Shawn Wells