Hello OVAL developers, suppose the following snippet of definition: <criteria operator="OR"> <criterion comment='x' test_ref='test_1' /> <criterion comment='y' test_ref='test_2' /> </criteria> Since in the moment 'test_1' evaluated to TRUE, it would be possible to bail out evaluation of 'test_2' entity (and all the necessary OVAL entities required for it - object, and states), is it possible to optimize the evaluation in the OVAL scanner implementation this way? Similarly / alternatively for the "AND" operator case, if 'test_1' evaluated to FALSE, is it possible the scanner not to evaluate the 'test_2' (and all entities related to it), and return 'FAIL' immediately? (since it could save some CPU cycles and also memory otherwise used for storing of OVAL entities for the 'test_2') Is the "complete OVAL entities" evaluation required by the standard somewhere? Any hints / pointers? Thank you for your time in advance. Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team ...

Hi Jan, There is nothing in the specification that requires you to not take this short-cut. However, I believe there are two reasons that OVAL implementations tend to eschew it: 1) OVAL has traditionally had a system_characteristics producer use-case, that logically separates collection from evaluation. Of course, you can perform a logically complete evaluation from an incomplete set of system_characteristics, which is what you’re proposing to do. But a pure system_characteristics producer would not want to do this, and most products implement both use-cases. Perhaps the concept of a system_characteristics producer is outdated, though, and no longer worth performing? 2) Generally in compliance systems, it’s useful to know all the reasons that a compliance check has failed, rather than just the first reason. This is for practical purposes, as nobody wants to have to perform a check again and again and again, without knowing what the next failure condition will be, multiplied across all the many checks that might fail. I believe #2 is the most compelling reason, and why we didn’t take the approach you’re talking about. However, there are some cases where we will truncate the set of items collected for an object (if it reaches a threshold and returns “too many” results), and we’ll mark that object as incomplete, and perform the evaluation accordingly (which sometimes means getting an “unknown” result). Best regards, —David A. Solin > On Aug 4, 2016, at 11:16 AM, Jan Lieskovsky <jlieskov@REDHAT.COM> wrote: > > > Hello OVAL developers, > > suppose the following snippet of definition: > > <criteria operator="OR"> > <criterion comment='x' test_ref='test_1' /> > <criterion comment='y' test_ref='test_2' /> > </criteria> > > Since in the moment 'test_1' evaluated to TRUE, it would be possible > to bail out evaluation of 'test_2' entity (and all the necessary OVAL > entities required for it - object, and states), is it possible to > optimize the evaluation in the OVAL scanner implementation this way? > > Similarly / alternatively for the "AND" operator case, if 'test_1' evaluated > to FALSE, is it possible the scanner not to evaluate the 'test_2' (and all > entities related to it), and return 'FAIL' immediately? (since it could > save some CPU cycles and also memory otherwise used for storing of OVAL entities > for the 'test_2') > > Is the "complete OVAL entities" evaluation required by the standard somewhere? > > Any hints / pointers? > > Thank you for your time in advance. > > Regards, Jan > -- > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > ... > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org ...

FYI, the following thread has quite a bit of discussion on this topic. http://making-security-measurable.1364806.n2.nabble.com/Regarding-logical-operator-in-criteria-element-and-test-dependency-tp23507.html Thanks, Danny > -----Original Message----- > From: OVAL_Developer [mailto:oval_developer- > bounces@lists.cisecurity.org] On Behalf Of David Solin > Sent: Thursday, August 04, 2016 1:16 PM > To: Jan Lieskovsky <jlieskov@REDHAT.COM> > Cc: OVAL Developer List <oval_developer@lists.cisecurity.org> > Subject: Re: [OVAL DEVELOPER] [RFC] Is it possible to optimize <criteria> > evaluation for logical operators? > > Hi Jan, > > There is nothing in the specification that requires you to not take this short- > cut. However, I believe there are two reasons that OVAL implementations > tend to eschew it: > > 1) OVAL has traditionally had a system_characteristics producer use-case, > that logically separates collection from evaluation. Of course, you can > perform a logically complete evaluation from an incomplete set of > system_characteristics, which is what you’re proposing to do. But a pure > system_characteristics producer would not want to do this, and most > products implement both use-cases. Perhaps the concept of a > system_characteristics producer is outdated, though, and no longer worth > performing? > > 2) Generally in compliance systems, it’s useful to know all the reasons that a > compliance check has failed, rather than just the first reason. This is for > practical purposes, as nobody wants to have to perform a check again and > again and again, without knowing what the next failure condition will be, > multiplied across all the many checks that might fail. > > I believe #2 is the most compelling reason, and why we didn’t take the > approach you’re talking about. However, there are some cases where we > will truncate the set of items collected for an object (if it reaches a threshold > and returns “too many” results), and we’ll mark that object as incomplete, > and perform the evaluation accordingly (which sometimes means getting an > “unknown” result). > > Best regards, > —David A. Solin > > > > > > On Aug 4, 2016, at 11:16 AM, Jan Lieskovsky <jlieskov@REDHAT.COM> > wrote: > > > > > > Hello OVAL developers, > > > > suppose the following snippet of definition: > > > > <criteria operator="OR"> > > <criterion comment='x' test_ref='test_1' /> > > <criterion comment='y' test_ref='test_2' /> </criteria> > > > > Since in the moment 'test_1' evaluated to TRUE, it would be possible > > to bail out evaluation of 'test_2' entity (and all the necessary OVAL > > entities required for it - object, and states), is it possible to > > optimize the evaluation in the OVAL scanner implementation this way? > > > > Similarly / alternatively for the "AND" operator case, if 'test_1' > > evaluated to FALSE, is it possible the scanner not to evaluate the > > 'test_2' (and all entities related to it), and return 'FAIL' > > immediately? (since it could save some CPU cycles and also memory > > otherwise used for storing of OVAL entities for the 'test_2') > > > > Is the "complete OVAL entities" evaluation required by the standard > somewhere? > > > > Any hints / pointers? > > > > Thank you for your time in advance. > > > > Regards, Jan > > -- > > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > > ... > > > > _______________________________________________ > > OVAL_Developer mailing list > > OVAL_Developer@lists.cisecurity.org > > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cise > > curity.org > > ... > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.or > g ...