New tested field for OVAL Checks
by Maura Dailey
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:filename>group</unix:filename>||
|| </unix:file_object>||
||</def-group>|
- Maura Dailey
10 years, 8 months
[PATCH 0/3] refactoring of XCCDF generation
by Jeffrey Blank
This simplifies (maybe) the translation of the fragments
into XCCDF.
Now:
Assembly of the fragments happens in one place: guide.xslt.
Translation of the shorthand into XCCDF happens in one place: shorthand2xccdf.xslt.
Basically, adding Profiles and resolving namespaces have been folded into
those transforms.
Jeffrey Blank (3):
removing calls to now-unnecessary transforms
added comment, added calls to insert Profiles
moved namespace assignment into shorthand2xccdf.xslt transform
RHEL6/Makefile | 5 +--
RHEL6/input/guide.xslt | 13 ++++-
RHEL6/transforms/shorthand2xccdf.xslt | 84 ++++++++++++++++++++++-------
RHEL6/transforms/xccdf-addnamespaces.xslt | 49 -----------------
RHEL6/transforms/xccdf-addprofiles.xslt | 37 -------------
5 files changed, 78 insertions(+), 110 deletions(-)
delete mode 100644 RHEL6/transforms/xccdf-addnamespaces.xslt
delete mode 100644 RHEL6/transforms/xccdf-addprofiles.xslt
10 years, 8 months
Common OVAL code (like for asserting for uninstalled services)
by Šimon Lukašík
Hello,
Recently we have significantly improved handling of OVAL variables in
OpenSCAP.
I believe that SSG can leverage this improved handling to avoid
redundancies (or similar code snippets). And significantly reduce the
size of the OVAL definition file (and consequently the size of OVAL
results).
I understand that it might not be a top priority, so this is just a
heads-up.
Example: There are definitions asserting that a service X is not
installed. If you manage to refactor the service X to a variable you can
the use the very same definition/test/item/object for many services. The
evaluation results will be then distinguished by @variable_instance
attribute and by tested_variable sub-element.
So, where you can start reading? Firstly, we have a general write-up
regarding variable processing at
http://www.open-scap.org/page/Documentation#Notes_on_the_Concept_of_Multi...
Secondly, there are some tests in OpenSCAP repo which demonstrate the
usage of the variables:
https://git.fedorahosted.org/cgit/openscap.git/tree/tests/API/XCCDF/varia...
Best regards,
--
Simon Lukasik
Security Technologies
10 years, 8 months
telnet section
by Stuart Green
Greetings All,
New to this list!
I think I might have found an issue with the SSG policy content.
Summary: If you do not have telnet installed on the system it causes
Rule ID: disable_telnet_service to fail.
In no place in this rule does it consider that telnet might not be
installed at all, so it fails (rather than errors, or even better does a
check as a precursor to see if its installed at all and if not passes!)
grep 'id="oval:ssg:tst:231"' ssg-rhel6-oval.xml.result.xml
<ind-def:textfilecontent54_test id="oval:ssg:tst:231" version="1"
check_existence="all_exist" check="all" comment="Disable Telnet Service">
<test test_id="oval:ssg:tst:231" version="1"
check_existence="all_exist" check="all" result="false"/>
<Rule id="disable_telnet_service" selected="false" severity="high">
<title xml:lang="en-US">Disable telnet Service</title>
<description xmlns:xhtml="http://www.w3.org/1999/xhtml"
xml:lang="en-US">
The <xhtml:code>telnet</xhtml:code> service can be disabled with
the following command:
<xhtml:pre># chkconfig telnet off</xhtml:pre>
</description>
<reference
href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-fina...">AC-17(8)</reference>
<reference
href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-fina...">CM-7</reference>
<reference
href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-fina...">IA-5(1)(c)</reference>
<reference
href="http://iase.disa.mil/cci/index.html">68</reference>
<reference
href="http://iase.disa.mil/cci/index.html">1436</reference>
<reference
href="http://iase.disa.mil/cci/index.html">197</reference>
<reference
href="http://iase.disa.mil/cci/index.html">877</reference>
<reference
href="http://iase.disa.mil/cci/index.html">888</reference>
<reference xmlns:dc="http://purl.org/dc/elements/1.1/"
href="test_attestation">
<dc:contributor>DS</dc:contributor>
<dc:date>20121026</dc:date>
</reference>
<rationale xmlns:xhtml="http://www.w3.org/1999/xhtml"
xml:lang="en-US">
The telnet protocol uses unencrypted network communication, which
means that data from the login session, including passwords and
all other information transmitted during the session, can be
stolen by eavesdroppers on the network. The telnet protocol is also
subject to man-in-the-middle attacks.
</rationale>
<ident system="http://cce.mitre.org">CCE-26836-7</ident>
<check
system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:ssg:def:230"
href="ssg-rhel6-oval.xml"/>
</check>
<check system="ocil-transitional">
<check-export export-name="the service is running"
value-id="conditional_clause"/>
<check-content xmlns:xhtml="http://www.w3.org/1999/xhtml">
To check that the <xhtml:code>telnet</xhtml:code> service is
disabled in system boot configuration, run the following command:
<xhtml:pre># chkconfig <xhtml:code>telnet</xhtml:code>
--list</xhtml:pre>
Output should indicate the <xhtml:code>telnet</xhtml:code> service
has either not been installed,
or has been disabled at all runlevels, as shown in the example below:
<xhtml:pre># chkconfig <xhtml:code>telnet</xhtml:code> --list
<xhtml:code>telnet</xhtml:code> 0:off 1:off 2:off 3:off
4:off 5:off 6:off</xhtml:pre>
Run the following command to verify <xhtml:code>telnet</xhtml:code>
is disabled through current runtime configuration:
<xhtml:pre># service telnet status</xhtml:pre>
If the service is disabled the command will return the following
output:
<xhtml:pre>telnet is stopped</xhtml:pre>
</check-content>
</check>
</Rule>
Cheers,
Stu
10 years, 8 months
PASS_MIN_LEN
by Stuart Green
Hi Again,
Another strange one on my scan (I can't find any open tickets).
It looks to me from the output http://i.imgur.com/QnhlbPl.png its
satisfied that we have minlen=12 in system-auth but dissatisfied that
PASS_MIN_LEN is not 14 in login.defs
So it looks to me as though one check is looking for the FISMA
requirement and the other is checking for the DoD requirement?
Cheers,
Stuart
10 years, 9 months