Questions about win-def:port_test

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions about win-def:port_test

dpeddicord
All,
Looking at the win-def:port_test (actually the port_object)  I notice that:
1. The protocol element is restricted to TCP,UDP, and empty string.
In the following snippet:
.......
<port_object id="oval:org.mitre.oval.test:obj:1074" version="1" comment="Retrieve the port objects with the local_address not equal to '127.0.0.1', the local_port less than or equal to '65535', and the protocol that matches the regular expression '^U[D]P$'." xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows">
      <local_address operation="not equal">127.0.0.1</local_address>
      <local_port datatype="int" operation="less than or equal">65535</local_port>
      <protocol operation="pattern match" var_ref="oval:org.mitre.oval.test:var:968" var_check="all"/>
    </port_object>

<constant_variable id="oval:org.mitre.oval.test:var:968" version="1" comment="This variable utilizes the work-around to use the pattern match operation on an enumeration. This variable is referenced in the object 'oval:org.mitre.oval.test:obj:1074'. This regular expression matches the string 'UDP'." datatype="string">
      <value>^U[D]P$</value>
    </constant_variable>
................

It seems to me that schema validation should fail (although it may not be detectable by Xerces, xmlint)  as ^U[D]P$ is not in the restricted  values.
However <value>UDP</value>  would be OK as it is.
I  think my question has to do with pattern matches and enumerated values. Which is evaluated (regex or result) first, in an object, I am not sure this makes any sense.


Don Peddicord
 
Reply | Threaded
Open this post in threaded view
|

Re: Questions about win-def:port_test

wmunyan
Don,
The schema validation the example you provide should work just fine.  The enumerated types defined in the OVAL schemas include the empty string, most of the time with the documentation of "allow empty string for use in variable references".  So what is being validated in the schema is really the empty string, which is an allowed value in the enumeration.

If anything, I think this would fall under the realm of a schematron validation, ensuring the variable resolves to a value contained in the enumeration.  Unfortunately, due to the complexities in variables and variables referencing other variables, etc, trying to build this would be just about impossible.

Hope that helps,
-Bill M.

-----Original Message-----
From: Peddicord, Don [mailto:[hidden email]]
Sent: Wednesday, March 11, 2015 10:16 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test

All,
Looking at the win-def:port_test (actually the port_object)  I notice that:
1. The protocol element is restricted to TCP,UDP, and empty string.
In the following snippet:
.......
<port_object id="oval:org.mitre.oval.test:obj:1074" version="1" comment="Retrieve the port objects with the local_address not equal to '127.0.0.1', the local_port less than or equal to '65535', and the protocol that matches the regular expression '^U[D]P$'." xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows">
      <local_address operation="not equal">127.0.0.1</local_address>
      <local_port datatype="int" operation="less than or equal">65535</local_port>
      <protocol operation="pattern match" var_ref="oval:org.mitre.oval.test:var:968" var_check="all"/>
    </port_object>

<constant_variable id="oval:org.mitre.oval.test:var:968" version="1" comment="This variable utilizes the work-around to use the pattern match operation on an enumeration. This variable is referenced in the object 'oval:org.mitre.oval.test:obj:1074'. This regular expression matches the string 'UDP'." datatype="string">
      <value>^U[D]P$</value>
    </constant_variable>
................

It seems to me that schema validation should fail (although it may not be detectable by Xerces, xmlint)  as ^U[D]P$ is not in the restricted  values.
However <value>UDP</value>  would be OK as it is.
I  think my question has to do with pattern matches and enumerated values. Which is evaluated (regex or result) first, in an object, I am not sure this makes any sense.


Don Peddicord


...
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . .
Reply | Threaded
Open this post in threaded view
|

Re: Questions about win-def:port_test

dpeddicord
Thanks Bill,
My question is more along the lines of whether this is valid OVAL?  I don't think it is.  The value in the var is not one of the enumerated values.  I question  how useful would a pattern match be in such a situation?

Don

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of William Munyan
Sent: Wednesday, March 11, 2015 10:46 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test

Don,
The schema validation the example you provide should work just fine.  The enumerated types defined in the OVAL schemas include the empty string, most of the time with the documentation of "allow empty string for use in variable references".  So what is being validated in the schema is really the empty string, which is an allowed value in the enumeration.

If anything, I think this would fall under the realm of a schematron validation, ensuring the variable resolves to a value contained in the enumeration.  Unfortunately, due to the complexities in variables and variables referencing other variables, etc, trying to build this would be just about impossible.

Hope that helps,
-Bill M.

-----Original Message-----
From: Peddicord, Don [mailto:[hidden email]]
Sent: Wednesday, March 11, 2015 10:16 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test

All,
Looking at the win-def:port_test (actually the port_object)  I notice that:
1. The protocol element is restricted to TCP,UDP, and empty string.
In the following snippet:
.......
<port_object id="oval:org.mitre.oval.test:obj:1074" version="1" comment="Retrieve the port objects with the local_address not equal to '127.0.0.1', the local_port less than or equal to '65535', and the protocol that matches the regular expression '^U[D]P$'." xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows">
      <local_address operation="not equal">127.0.0.1</local_address>
      <local_port datatype="int" operation="less than or equal">65535</local_port>
      <protocol operation="pattern match" var_ref="oval:org.mitre.oval.test:var:968" var_check="all"/>
    </port_object>

<constant_variable id="oval:org.mitre.oval.test:var:968" version="1" comment="This variable utilizes the work-around to use the pattern match operation on an enumeration. This variable is referenced in the object 'oval:org.mitre.oval.test:obj:1074'. This regular expression matches the string 'UDP'." datatype="string">
      <value>^U[D]P$</value>
    </constant_variable>
................

It seems to me that schema validation should fail (although it may not be detectable by Xerces, xmlint)  as ^U[D]P$ is not in the restricted  values.
However <value>UDP</value>  would be OK as it is.
I  think my question has to do with pattern matches and enumerated values. Which is evaluated (regex or result) first, in an object, I am not sure this makes any sense.


Don Peddicord


...
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . .
Reply | Threaded
Open this post in threaded view
|

Re: Questions about win-def:port_test

joval
It’s valid OVAL.  And, it will match ‘UDP’, which is one of the permitted values — so it’s potentially even useful.

There are other cases where a pattern may be more useful used in conjunction with an enumeration.  But with enumerations, it may be more illustrative in the content to use a multi-valued variable, with an equals operator and a var_check of ‘only one’.

Regards,
David Solin
[hidden email]



> On Mar 12, 2015, at 6:23 AM, Peddicord, Don <[hidden email]> wrote:
>
> Thanks Bill,
> My question is more along the lines of whether this is valid OVAL?  I don't think it is.  The value in the var is not one of the enumerated values.  I question  how useful would a pattern match be in such a situation?
>
> Don
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of William Munyan
> Sent: Wednesday, March 11, 2015 10:46 AM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test
>
> Don,
> The schema validation the example you provide should work just fine.  The enumerated types defined in the OVAL schemas include the empty string, most of the time with the documentation of "allow empty string for use in variable references".  So what is being validated in the schema is really the empty string, which is an allowed value in the enumeration.
>
> If anything, I think this would fall under the realm of a schematron validation, ensuring the variable resolves to a value contained in the enumeration.  Unfortunately, due to the complexities in variables and variables referencing other variables, etc, trying to build this would be just about impossible.
>
> Hope that helps,
> -Bill M.
>
> -----Original Message-----
> From: Peddicord, Don [mailto:[hidden email]]
> Sent: Wednesday, March 11, 2015 10:16 AM
> To: [hidden email]
> Subject: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test
>
> All,
> Looking at the win-def:port_test (actually the port_object)  I notice that:
> 1. The protocol element is restricted to TCP,UDP, and empty string.
> In the following snippet:
> .......
> <port_object id="oval:org.mitre.oval.test:obj:1074" version="1" comment="Retrieve the port objects with the local_address not equal to '127.0.0.1', the local_port less than or equal to '65535', and the protocol that matches the regular expression '^U[D]P$'." xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows">
>      <local_address operation="not equal">127.0.0.1</local_address>
>      <local_port datatype="int" operation="less than or equal">65535</local_port>
>      <protocol operation="pattern match" var_ref="oval:org.mitre.oval.test:var:968" var_check="all"/>
>    </port_object>
>
> <constant_variable id="oval:org.mitre.oval.test:var:968" version="1" comment="This variable utilizes the work-around to use the pattern match operation on an enumeration. This variable is referenced in the object 'oval:org.mitre.oval.test:obj:1074'. This regular expression matches the string 'UDP'." datatype="string">
>      <value>^U[D]P$</value>
>    </constant_variable>
> ................
>
> It seems to me that schema validation should fail (although it may not be detectable by Xerces, xmlint)  as ^U[D]P$ is not in the restricted  values.
> However <value>UDP</value>  would be OK as it is.
> I  think my question has to do with pattern matches and enumerated values. Which is evaluated (regex or result) first, in an object, I am not sure this makes any sense.
>
>
> Don Peddicord
>
>
> ...
> This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
>
> . . .

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: Questions about win-def:port_test

dpeddicord
David,
I am not sure I see the utility of a regex that can only match UDP or TCP or an empty string, I'll continue chewing on that.
However, my question is really about a pattern match 'replacing' an enumerated value, which makes sense logically, and was answered.
Thanks,
Don  


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Solin
Sent: Thursday, March 12, 2015 9:07 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test

It’s valid OVAL.  And, it will match ‘UDP’, which is one of the permitted values — so it’s potentially even useful.

There are other cases where a pattern may be more useful used in conjunction with an enumeration.  But with enumerations, it may be more illustrative in the content to use a multi-valued variable, with an equals operator and a var_check of ‘only one’.

Regards,
David Solin
[hidden email]



> On Mar 12, 2015, at 6:23 AM, Peddicord, Don <[hidden email]> wrote:
>
> Thanks Bill,
> My question is more along the lines of whether this is valid OVAL?  I don't think it is.  The value in the var is not one of the enumerated values.  I question  how useful would a pattern match be in such a situation?
>
> Don
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> William Munyan
> Sent: Wednesday, March 11, 2015 10:46 AM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test
>
> Don,
> The schema validation the example you provide should work just fine.  The enumerated types defined in the OVAL schemas include the empty string, most of the time with the documentation of "allow empty string for use in variable references".  So what is being validated in the schema is really the empty string, which is an allowed value in the enumeration.
>
> If anything, I think this would fall under the realm of a schematron validation, ensuring the variable resolves to a value contained in the enumeration.  Unfortunately, due to the complexities in variables and variables referencing other variables, etc, trying to build this would be just about impossible.
>
> Hope that helps,
> -Bill M.
>
> -----Original Message-----
> From: Peddicord, Don [mailto:[hidden email]]
> Sent: Wednesday, March 11, 2015 10:16 AM
> To: [hidden email]
> Subject: [OVAL-DEVELOPER-LIST] Questions about win-def:port_test
>
> All,
> Looking at the win-def:port_test (actually the port_object)  I notice that:
> 1. The protocol element is restricted to TCP,UDP, and empty string.
> In the following snippet:
> .......
> <port_object id="oval:org.mitre.oval.test:obj:1074" version="1" comment="Retrieve the port objects with the local_address not equal to '127.0.0.1', the local_port less than or equal to '65535', and the protocol that matches the regular expression '^U[D]P$'." xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows">
>      <local_address operation="not equal">127.0.0.1</local_address>
>      <local_port datatype="int" operation="less than or equal">65535</local_port>
>      <protocol operation="pattern match" var_ref="oval:org.mitre.oval.test:var:968" var_check="all"/>
>    </port_object>
>
> <constant_variable id="oval:org.mitre.oval.test:var:968" version="1" comment="This variable utilizes the work-around to use the pattern match operation on an enumeration. This variable is referenced in the object 'oval:org.mitre.oval.test:obj:1074'. This regular expression matches the string 'UDP'." datatype="string">
>      <value>^U[D]P$</value>
>    </constant_variable>
> ................
>
> It seems to me that schema validation should fail (although it may not be detectable by Xerces, xmlint)  as ^U[D]P$ is not in the restricted  values.
> However <value>UDP</value>  would be OK as it is.
> I  think my question has to do with pattern matches and enumerated values. Which is evaluated (regex or result) first, in an object, I am not sure this makes any sense.
>
>
> Don Peddicord
>
>
> ...
> This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
>
> . . .

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message.  If you have difficulties, write to [hidden email].