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_Multiple...
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/variable...
Best regards,
-- Simon Lukasik Security Technologies
This looks quite nice, Simon.
I have not yet had a chance to do a detailed inspection, but a question arises.
Would such techniques fail for (other than OpenSCAP) compliance scanners that employ ovaldi rather than a strict OVAL implementation?
I have attached an example showing definition re-use with multiple XCCDF variables.
Regards,
Gary
On Thursday, August 01, 2013 01:59:18 PM Gary Gapinski wrote:
This looks quite nice, Simon.
I have not yet had a chance to do a detailed inspection, but a question arises.
Would such techniques fail for (other than OpenSCAP) compliance scanners that employ ovaldi rather than a strict OVAL implementation?
OVAL variable support is a certification requirement for any SCAP 1.2 scanner. Its in the 7511 as SCAP.T.2000.5. So, any validated scanner should handle it.
-Steve
On 08/01/2013 02:11 PM, Steve Grubb wrote:
OVAL variable support is a certification requirement for any SCAP 1.2 scanner. Its in the 7511 as SCAP.T.2000.5. So, any validated scanner should handle it.
Perhaps. I would expect that had my expectations not been previously negatively calibrated.
Please take a close look at the example I provided. It is an acid test for proper evaluation in the context of a single OVAL external variable assuming two values for two invocations of a definition. I do not believe such usage is precluded by XCCDF or OVAL. Nor does a cursory scan of SCAP 1.1 (§3.2.5.2 appears to be the only applicable section) or SCAP 1.2 (§3.2.5).
Such re-use allows great economy of expression. It can, be extended to check settings such as those specified using sysctl, e.g., net.ipv4.ip_forward = 0.
Regards,
Gary
Hello Gary,
I am not sure if I am following your concerns.
On 08/01/2013 08:38 PM, Gary Gapinski wrote:
On 08/01/2013 02:11 PM, Steve Grubb wrote:
OVAL variable support is a certification requirement for any SCAP 1.2 scanner. Its in the 7511 as SCAP.T.2000.5. So, any validated scanner should handle it.
Perhaps. I would expect that had my expectations not been previously negatively calibrated.
Please take a close look at the example I provided. It is an acid test for proper evaluation in the context of a single OVAL external variable assuming two values for two invocations of a definition.
I took closer look. This use case is supported by OpenSCAP.
I do not
believe such usage is precluded by XCCDF or OVAL. Nor does a cursory scan of SCAP 1.1 (§3.2.5.2 appears to be the only applicable section) or SCAP 1.2 (§3.2.5).
There is couple of places where the multiple variable values are described. However, the exact use case use shared with us is part of requirement SCAP.T.2000.5 within NISTIR-7511. (The automated test suite for SCAP.T.2000.5 contains the very same example as yours).
I cannot speak for other scanners. And I don't know if it is supported by ovaldi. Nevertheless, I wanted to raise this functionality to your attention.
Perhaps, there is indeed a risk of inter-operability loss assigned with usage of advanced concepts of SCAP. If so, then the standard needs to be more explicit next time.
Such re-use allows great economy of expression. It can, be extended to check settings such as those specified using sysctl, e.g., net.ipv4.ip_forward = 0.
Regards,
Gary
On Monday, August 05, 2013 01:23:47 PM Simon Lukasik wrote:
I do not believe such usage is precluded by XCCDF or OVAL. Nor does a cursory scan of SCAP 1.1 (§3.2.5.2 appears to be the only applicable section) or SCAP 1.2 (§3.2.5).
There is couple of places where the multiple variable values are described. However, the exact use case use shared with us is part of requirement SCAP.T.2000.5 within NISTIR-7511. (The automated test suite for SCAP.T.2000.5 contains the very same example as yours).
I cannot speak for other scanners. And I don't know if it is supported by ovaldi. Nevertheless, I wanted to raise this functionality to your attention.
Ovaldi was never intended to be a 100% complete and functional implementation. If it were, then nobody would be wasting time and money making other scanners. Its intention is to demonstrate many of the concepts in the OVAL language so that people writing a scanner can compare their against it for the things it has implemented. So, anyone pinning their hopes on doing complex things in ovaldi is likely to be in a hard spot.
Perhaps, there is indeed a risk of inter-operability loss assigned with usage of advanced concepts of SCAP. If so, then the standard needs to be more explicit next time.
It can always be better specified, but I don't think that helps in this situation. Everyone that needs reliable results must use a certified scanner. The purpose of certification is to make that scanners can do what's asked of them. If you do not use a certified scanner, then there is nothing to guarantee that the implementation is correct. This is why we are putting openscap through an evaluation...to be able to say it implements everything required in the standard to the extent that validation tests it.
-Steve
On 8/1/13 12:37 PM, Simon Lukasik wrote:
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_Multiple...
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/variable...
In reviewing the example code, it looks like if we had 20 variable elements (e.g. 20 service names), there would need to be 20 corresponding XCCDF rules:
| <Rule id="xccdf_moc.elpmaxe.www_rule_2" selected="false"> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-export value-id="xccdf_moc.elpmaxe.www_value_1" export-name="oval:com.example.www:var:1"/> <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/> </check>
</Rule> <Rule id="xccdf_moc.elpmaxe.www_rule_3" selected="false"> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-export value-id="xccdf_moc.elpmaxe.www_value_2" export-name="oval:com.example.www:var:1"/> <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/> </check> </Rule>|
Is it possible for a SCAP scanner to parse all variables in a single XCCDF rule? e.g.:
| <Rule id="xccdf_moc.elpmaxe.www_rule_2" selected="false"> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-export value-id="xccdf_moc.elpmaxe.www_value_[@]" export-name="oval:com.example.www:var:1"/> <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/> </check>
</Rule> |
On 08/05/2013 03:22 PM, Shawn Wells wrote:
On 8/1/13 12:37 PM, Simon Lukasik wrote:
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_Multiple...
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/variable...
In reviewing the example code, it looks like if we had 20 variable elements (e.g. 20 service names), there would need to be 20 corresponding XCCDF rules:
| <Rule id="xccdf_moc.elpmaxe.www_rule_2" selected="false"> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-export value-id="xccdf_moc.elpmaxe.www_value_1" export-name="oval:com.example.www:var:1"/> <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/> </check>
</Rule> <Rule id="xccdf_moc.elpmaxe.www_rule_3" selected="false"> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-export value-id="xccdf_moc.elpmaxe.www_value_2" export-name="oval:com.example.www:var:1"/> <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/> </check> </Rule>|
Is it possible for a SCAP scanner to parse all variables in a single XCCDF rule? e.g.:
| <Rule id="xccdf_moc.elpmaxe.www_rule_2" selected="false"> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-export value-id="xccdf_moc.elpmaxe.www_value_[@]" export-name="oval:com.example.www:var:1"/> <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/> </check>
</Rule> |
Yes, that could be possible (although I did not test).
You can use one xccdf:check with 20 <check-export> elements. All of them will bind different XCCDF values to the very same OVAL variable.
<check (...) <check-export value-id="xccdf_moc.elpmaxe.www_value_1" export-name="oval:com.example.www:var:1"/> <check-export value-id="xccdf_moc.elpmaxe.www_value_2" export-name="oval:com.example.www:var:1"/> <check-export value-id="xccdf_moc.elpmaxe.www_value_3" export-name="oval:com.example.www:var:1"/> (...) <check-content-ref href="my-oval.xml" name="oval:com.example.www:def:1"/> </check>
Then, if you generate OVAL variables document from such XCCDF (# oscap xccdf export-oval-variables), it will give you something like:
<variable id="oval:com.example.www:var:1"/> <value>abrt</value> <value>acpid</value> <value>certmonger</value> (...) </variable>
Then, You only need to write OVAL definition with meaning: None of the services given by variable is installed/enabled. While that is possible, I would not recommend that. Having a single XCCDF Rule per service seems to be good choice of granularity to me.
Best regards,
-- Simon Lukasik Security Technologies
scap-security-guide@lists.fedorahosted.org