Going forward, we're going to use <reference> tags inside of OVAL checks to track if they've been tested. An example is as follows:
|<reference ||source="MED" ref_id="20130731" ref_url="test_attestation" />|
Source should uniquely identify the tester (here, I used my initials); ref_id should be in the format YYYYMMDD. We'll probably be adding empty tags into all the checks to get everyone started. This is similar to the <tested> tag in XCCDF, which is converted into an XCCDF <reference> tag during our build process.
Here is an example of the <reference> tag in an existing check. Note that it comes just after the description tag, inside of <metadata>.
|<def-group>|| || <definition class="compliance" id="file_permissions_etc_group" version="1">|| || <metadata>|| || <title>Verify permissions on 'group' file</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>File permissions for /etc/group should be set correctly.</description>|| || <reference source="MED" ref_id="20130731" ref_url="test_attestation"/>|| || </metadata>|| || <criteria>|| || <criterion test_ref="file_permissions_etc_group_test" />|| || </criteria>|| || </definition>|| || <unix:file_test check="all" check_existence="all_exist" comment="Testing /etc/group permissions" id="file_permissions_etc_group_test" version="1">|| || <unix:object object_ref="file_permissions_etc_group_object" />|| || <unix:state state_ref="file_permissions_etc_group_state" />|| || </unix:file_test>|| || <unix:file_state id="file_permissions_etc_group_state" version="1">|| || <unix:uread datatype="boolean">true</unix:uread>|| || <unix:uwrite datatype="boolean">true</unix:uwrite>|| || <unix:uexec datatype="boolean">false</unix:uexec>|| || <unix:gread datatype="boolean">true</unix:gread>|| || <unix:gwrite datatype="boolean">false</unix:gwrite>|| || <unix:gexec datatype="boolean">false</unix:gexec>|| || <unix:oread datatype="boolean">true</unix:oread>|| || <unix:owrite datatype="boolean">false</unix:owrite>|| || <unix:oexec datatype="boolean">false</unix:oexec>|| || </unix:file_state>|| || <unix:file_object comment="/etc/group" id="file_permissions_etc_group_object" version="1">|| || unix:path/etc</unix:path>|| || unix:filenamegroup</unix:filename>|| || </unix:file_object>|| ||</def-group>|
- Maura Dailey
Looks great!
I'll see if I can throw some Python (or bash?) together to add empty elements for the sake of convenience (unless Shawn would like to?). Next, I'll try to update an existing transform to show a list of requirements from a Profile (such as the STIG), along with indicators (using green) about which have been tested.
Before long, we should have a nice publicly-viewable worksheet showing progress on OVAL testing.
On 07/31/2013 05:30 PM, Maura Dailey wrote:
Going forward, we're going to use <reference> tags inside of OVAL checks to track if they've been tested. An example is as follows:
|<reference ||source="MED" ref_id="20130731" ref_url="test_attestation" />|
Source should uniquely identify the tester (here, I used my initials); ref_id should be in the format YYYYMMDD. We'll probably be adding empty tags into all the checks to get everyone started. This is similar to the <tested> tag in XCCDF, which is converted into an XCCDF <reference> tag during our build process.
Here is an example of the <reference> tag in an existing check. Note that it comes just after the description tag, inside of <metadata>.
|<def-group>|| || <definition class="compliance" id="file_permissions_etc_group" version="1">|| || <metadata>|| || <title>Verify permissions on 'group' file</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>File permissions for /etc/group should be set correctly.</description>|| || <reference source="MED" ref_id="20130731" ref_url="test_attestation"/>|| || </metadata>|| || <criteria>|| || <criterion test_ref="file_permissions_etc_group_test" />|| || </criteria>|| || </definition>|| || <unix:file_test check="all" check_existence="all_exist" comment="Testing /etc/group permissions" id="file_permissions_etc_group_test" version="1">|| || <unix:object object_ref="file_permissions_etc_group_object" />|| || <unix:state state_ref="file_permissions_etc_group_state" />|| || </unix:file_test>|| || <unix:file_state id="file_permissions_etc_group_state" version="1">|| || <unix:uread datatype="boolean">true</unix:uread>|| || <unix:uwrite datatype="boolean">true</unix:uwrite>|| || <unix:uexec datatype="boolean">false</unix:uexec>|| || <unix:gread datatype="boolean">true</unix:gread>|| || <unix:gwrite datatype="boolean">false</unix:gwrite>|| || <unix:gexec datatype="boolean">false</unix:gexec>|| || <unix:oread datatype="boolean">true</unix:oread>|| || <unix:owrite datatype="boolean">false</unix:owrite>|| || <unix:oexec datatype="boolean">false</unix:oexec>|| || </unix:file_state>|| || <unix:file_object comment="/etc/group" id="file_permissions_etc_group_object" version="1">|| || unix:path/etc</unix:path>|| || unix:filenamegroup</unix:filename>|| || </unix:file_object>|| ||</def-group>|
- Maura Dailey
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 7/31/13 7:07 PM, Jeffrey Blank wrote:
Looks great!
I'll see if I can throw some Python (or bash?) together to add empty elements for the sake of convenience (unless Shawn would like to?).
I'll likely have time to take a stab on Saturday afternoon, so feel free to take first crack if that's to far off!
Next, I'll try to update an existing transform to show a list of requirements from a Profile (such as the STIG), along with indicators (using green) about which have been tested.
Before long, we should have a nice publicly-viewable worksheet showing progress on OVAL testing.
Would it be trivial to add a column indicating if a fix is present? Since the fixes are net-new (vs inhereted from things like USGCB), committed through the peer review process, their existence should be enough to warrant a green box.
I'll see if I can throw some Python (or bash?) together to add empty elements for the sake of convenience (unless Shawn would like to?).
I'll likely have time to take a stab on Saturday afternoon, so feel free to take first crack if that's to far off!
Yup -- will do.
Next, I'll try to update an existing transform to show a list of requirements from a Profile (such as the STIG), along with indicators (using green) about which have been tested.
Before long, we should have a nice publicly-viewable worksheet showing progress on OVAL testing.
Would it be trivial to add a column indicating if a fix is present? Since the fixes are net-new (vs inhereted from things like USGCB), committed through the peer review process, their existence should be enough to warrant a green box.
Sure, that's fair. It also gets us out of having to somehow tag them!
Plus, it will let me see at a glance whether anybody has committed a fix for a Rule without vetting the OVAL, which is extremely undesirable from the automation perspective.
On 8/1/13 4:50 PM, Jeffrey Blank wrote:
I'll see if I can throw some Python (or bash?) together to add empty elements for the sake of convenience (unless Shawn would like to?).
I'll likely have time to take a stab on Saturday afternoon, so feel free to take first crack if that's to far off!
Yup -- will do.
So.... I didn't end up having time this weekend =/
Next, I'll try to update an existing transform to show a list of requirements from a Profile (such as the STIG), along with indicators (using green) about which have been tested.
Before long, we should have a nice publicly-viewable worksheet showing progress on OVAL testing.
Would it be trivial to add a column indicating if a fix is present? Since the fixes are net-new (vs inhereted from things like USGCB), committed through the peer review process, their existence should be enough to warrant a green box.
Sure, that's fair. It also gets us out of having to somehow tag them!
Plus, it will let me see at a glance whether anybody has committed a fix for a Rule without vetting the OVAL, which is extremely undesirable from the automation perspective.
Question for Leland on the OVAL signoff tags -- will it be possible for FSO to create patches to reflect which OVAL checks they've tested, in preparation for OVAL shipping in the STIG?
scap-security-guide@lists.fedorahosted.org