Question about the intent of the time_difference function

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

Question about the intent of the time_difference function

rhuffman
The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.


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].
Reply | Threaded
Open this post in threaded view
|

Re: Question about the intent of the time_difference function

joval
Then there would be no way to write a rule that says something should be less than a month old (for example).

On 3/28/2013 10:12 AM, Robert Huffman wrote:
The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.


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: SCAP Simplified.
Learn More | Features | Download

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: Question about the intent of the time_difference function

rhuffman
I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.


On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:
Then there would be no way to write a rule that says something should be less than a month old (for example).


On 3/28/2013 10:12 AM, Robert Huffman wrote:
The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.


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: SCAP Simplified.
Learn More | Features | Download


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].
Reply | Threaded
Open this post in threaded view
|

Re: Question about the intent of the time_difference function

joval
For your use-case, one could provide an external variable containing the timestamp of the s-c file, and build an appropriate test.  Of course I suppose one could similarly pass the current timestamp in using an external variable.

But I would think, when using an old s-c file, one is inherently asking the question: "if these were the current settings, what is my compliance posture?", and not "what would my compliance posture have been back when these settings were collected".

On 3/28/2013 10:45 AM, Robert Huffman wrote:
I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.


On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:
Then there would be no way to write a rule that says something should be less than a month old (for example).


On 3/28/2013 10:12 AM, Robert Huffman wrote:
The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.


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: SCAP Simplified.
Learn More | Features | Download


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: SCAP Simplified.
Learn More | Features | Download

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: Question about the intent of the time_difference function

lutton

Interesting arguments… essentially, the meaning of ‘now’.

 

I find the argument that ‘now’ is related more to the collection process is more compelling than the argument that it is related to the ‘evaluation’ process.  The SC file inherently represents a snapshot in time – the value ‘now’ should be part of that snapshot.  In particular, if feels ‘wrong’ that the results of evaluating system characteristics depend on when that evaluation is done.

 

Other thoughts?

 

Tnx,

Bill L.

 

 

From: David Solin [mailto:[hidden email]]
Sent: Thursday, March 28, 2013 9:56 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

For your use-case, one could provide an external variable containing the timestamp of the s-c file, and build an appropriate test.  Of course I suppose one could similarly pass the current timestamp in using an external variable.

But I would think, when using an old s-c file, one is inherently asking the question: "if these were the current settings, what is my compliance posture?", and not "what would my compliance posture have been back when these settings were collected".

On 3/28/2013 10:45 AM, Robert Huffman wrote:

I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

 

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.

 

On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:

Then there would be no way to write a rule that says something should be less than a month old (for example).

 

On 3/28/2013 10:12 AM, Robert Huffman wrote:

The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

 

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

 

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.

 

 

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: SCAP Simplified.
Learn More | Features | Download

 

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: SCAP Simplified.
Learn More | Features | Download

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].

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].
Reply | Threaded
Open this post in threaded view
|

Re: Question about the intent of the time_difference function

joval
If one wants to capture "NOW" in a system-characteristics file, couldn't you create a variable_object that points to a variable with a time_difference today?  The associated item would capture the time, and the value would be frozen.

The question we (jOVAL) originally had with the meaning of "NOW" was, should we use the system time on the scan host, or the system time on the target machine (we chose to use the latter).

On 3/28/2013 11:14 AM, Bill Lutton wrote:

Interesting arguments… essentially, the meaning of ‘now’.

 

I find the argument that ‘now’ is related more to the collection process is more compelling than the argument that it is related to the ‘evaluation’ process.  The SC file inherently represents a snapshot in time – the value ‘now’ should be part of that snapshot.  In particular, if feels ‘wrong’ that the results of evaluating system characteristics depend on when that evaluation is done.

 

Other thoughts?

 

Tnx,

Bill L.

 

 

From: David Solin [[hidden email]]
Sent: Thursday, March 28, 2013 9:56 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

For your use-case, one could provide an external variable containing the timestamp of the s-c file, and build an appropriate test.  Of course I suppose one could similarly pass the current timestamp in using an external variable.

But I would think, when using an old s-c file, one is inherently asking the question: "if these were the current settings, what is my compliance posture?", and not "what would my compliance posture have been back when these settings were collected".

On 3/28/2013 10:45 AM, Robert Huffman wrote:

I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

 

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.

 

On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:

Then there would be no way to write a rule that says something should be less than a month old (for example).

 

On 3/28/2013 10:12 AM, Robert Huffman wrote:

The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

 

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

 

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.

 

 

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: SCAP Simplified.
Learn More | Features | Download

 

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: SCAP Simplified.
Learn More | Features | Download

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].

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: SCAP Simplified.
Learn More | Features | Download

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: Question about the intent of the time_difference function

Ronayne, James K.-2
In reply to this post by lutton

I agree with David.  I think “now” is more relevant to the evaluation time.  When I collect the SC file and evaluate it some time later I am essentially assuming it still represents the state of the device.  Consider the case where I have a rule to check the date on my AV dat file.  If my rule is looking for a dat file that is less than a week old I care about whether I pass now.  I don’t care if I passed last week.  If I find that I failed at evaluation time that might tell me I need more current data or it might tell me I have an AV dat problem.  Is there a case where I care about compliance in the past?  I think compliance now is what matters.  I am more concerned that I might have a false negative (I was compliant last week but I’m not now and the evaluator says I passed) than I am about a false positive (I was compliant last week and I am still compliant now but the evaluator says I failed).

 

In your file example below I agree that the February evaluation doesn’t tell you anything about the true state of the system but this is because the data is old.  You have no idea what happened on the system in the last month.

 

In any case, time_difference is defined in the oval definitions schema.  It is not part of the sc schema.  Would there be value in adding an option in time_difference to use the timestamp from the SC generator section?  I would still prefer the default be left as is.

 

Jim

 

 

From: Bill Lutton [mailto:[hidden email]]
Sent: Thursday, March 28, 2013 12:14 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

Interesting arguments… essentially, the meaning of ‘now’.

 

I find the argument that ‘now’ is related more to the collection process is more compelling than the argument that it is related to the ‘evaluation’ process.  The SC file inherently represents a snapshot in time – the value ‘now’ should be part of that snapshot.  In particular, if feels ‘wrong’ that the results of evaluating system characteristics depend on when that evaluation is done.

 

Other thoughts?

 

Tnx,

Bill L.

 

 

From: David Solin [mailto:[hidden email]]
Sent: Thursday, March 28, 2013 9:56 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

For your use-case, one could provide an external variable containing the timestamp of the s-c file, and build an appropriate test.  Of course I suppose one could similarly pass the current timestamp in using an external variable.

But I would think, when using an old s-c file, one is inherently asking the question: "if these were the current settings, what is my compliance posture?", and not "what would my compliance posture have been back when these settings were collected".

On 3/28/2013 10:45 AM, Robert Huffman wrote:

I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

 

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.

 

On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:

Then there would be no way to write a rule that says something should be less than a month old (for example).

 

On 3/28/2013 10:12 AM, Robert Huffman wrote:

The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

 

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

 

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.

 

 

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: SCAP Simplified.
Learn More | Features | Download

 

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: SCAP Simplified.
Learn More | Features | Download

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].

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].

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].
Reply | Threaded
Open this post in threaded view
|

Re: Question about the intent of the time_difference function

lutton

Thanks for jumping in, Jim.  I think I see the point you are trying to make, but I think it came out a bit fuzzy…   In your first paragraph, you make the case that an SC file less than a week old can be ‘assumed’ to still represent the state of the system.  In your next paragraph, you make the case that a month old SC file doesn’t meaningfully represent the state of the system.

 

I guess I fall more in line with your latter point… if an SC file is ‘old’ one has no real confidence that it represents anything about the current state of the system.  Thus any evaluation of the SC can only ever (by definition almost) make a judgment about the state of a system at the point in time when the SC was collected. 

 

It feels like allowing the evaluation of SC results to come out different based on when the evaluation was done doesn’t add any value and has the potential of creating confusion (which is ‘right’).  I certainly do agree with your point that one cares about compliance now (rather than at some point in the past).  And I agree that evaluating an ‘old’ SC file is not a good way to know about compliance now. 

 

I like your idea of an option to specify the ‘source of now’.  Mostly because it would eliminate the uncertainty about what ‘now’ means during evaluation.  No matter what gets decided about ‘now’, it seems we’d all be better off if different tools didn’t have the freedom to do it differently.

 

Best regards,

Bill L.

 

 

From: Ronayne, James K. [mailto:[hidden email]]
Sent: Thursday, March 28, 2013 11:44 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

I agree with David.  I think “now” is more relevant to the evaluation time.  When I collect the SC file and evaluate it some time later I am essentially assuming it still represents the state of the device.  Consider the case where I have a rule to check the date on my AV dat file.  If my rule is looking for a dat file that is less than a week old I care about whether I pass now.  I don’t care if I passed last week.  If I find that I failed at evaluation time that might tell me I need more current data or it might tell me I have an AV dat problem.  Is there a case where I care about compliance in the past?  I think compliance now is what matters.  I am more concerned that I might have a false negative (I was compliant last week but I’m not now and the evaluator says I passed) than I am about a false positive (I was compliant last week and I am still compliant now but the evaluator says I failed).

 

In your file example below I agree that the February evaluation doesn’t tell you anything about the true state of the system but this is because the data is old.  You have no idea what happened on the system in the last month.

 

In any case, time_difference is defined in the oval definitions schema.  It is not part of the sc schema.  Would there be value in adding an option in time_difference to use the timestamp from the SC generator section?  I would still prefer the default be left as is.

 

Jim

 

 

From: Bill Lutton [[hidden email]]
Sent: Thursday, March 28, 2013 12:14 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

Interesting arguments… essentially, the meaning of ‘now’.

 

I find the argument that ‘now’ is related more to the collection process is more compelling than the argument that it is related to the ‘evaluation’ process.  The SC file inherently represents a snapshot in time – the value ‘now’ should be part of that snapshot.  In particular, if feels ‘wrong’ that the results of evaluating system characteristics depend on when that evaluation is done.

 

Other thoughts?

 

Tnx,

Bill L.

 

 

From: David Solin [[hidden email]]
Sent: Thursday, March 28, 2013 9:56 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

For your use-case, one could provide an external variable containing the timestamp of the s-c file, and build an appropriate test.  Of course I suppose one could similarly pass the current timestamp in using an external variable.

But I would think, when using an old s-c file, one is inherently asking the question: "if these were the current settings, what is my compliance posture?", and not "what would my compliance posture have been back when these settings were collected".

On 3/28/2013 10:45 AM, Robert Huffman wrote:

I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

 

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.

 

On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:

Then there would be no way to write a rule that says something should be less than a month old (for example).

 

On 3/28/2013 10:12 AM, Robert Huffman wrote:

The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

 

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

 

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.

 

 

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: SCAP Simplified.
Learn More | Features | Download

 

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: SCAP Simplified.
Learn More | Features | Download

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].

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].

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].

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].
Reply | Threaded
Open this post in threaded view
|

Re: Question about the intent of the time_difference function

Ronayne, James K.-2

My point is that we are forced to assume the file we have represents the current state of the system.  We have no other choice because we have no other data.  In reality it doesn’t meaningfully represent the true state of the system because it is old. 

 

The SC file isn’t a judgment of the system.  It merely records the state of objects at a point in time.  The evaluation of the SC is making a judgment. 

 

I don’t think tools have the option to do it differently today.  The time_diff function is part of the evaluation (definition) and it specifies the current time.  At a minimum maybe it would help to add clarification to the description. 

 

Jim

 

 

 

From: Bill Lutton [mailto:[hidden email]]
Sent: Thursday, March 28, 2013 3:44 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

Thanks for jumping in, Jim.  I think I see the point you are trying to make, but I think it came out a bit fuzzy…   In your first paragraph, you make the case that an SC file less than a week old can be ‘assumed’ to still represent the state of the system.  In your next paragraph, you make the case that a month old SC file doesn’t meaningfully represent the state of the system.

 

I guess I fall more in line with your latter point… if an SC file is ‘old’ one has no real confidence that it represents anything about the current state of the system.  Thus any evaluation of the SC can only ever (by definition almost) make a judgment about the state of a system at the point in time when the SC was collected. 

 

It feels like allowing the evaluation of SC results to come out different based on when the evaluation was done doesn’t add any value and has the potential of creating confusion (which is ‘right’).  I certainly do agree with your point that one cares about compliance now (rather than at some point in the past).  And I agree that evaluating an ‘old’ SC file is not a good way to know about compliance now. 

 

I like your idea of an option to specify the ‘source of now’.  Mostly because it would eliminate the uncertainty about what ‘now’ means during evaluation.  No matter what gets decided about ‘now’, it seems we’d all be better off if different tools didn’t have the freedom to do it differently.

 

Best regards,

Bill L.

 

 

From: Ronayne, James K. [mailto:[hidden email]]
Sent: Thursday, March 28, 2013 11:44 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

I agree with David.  I think “now” is more relevant to the evaluation time.  When I collect the SC file and evaluate it some time later I am essentially assuming it still represents the state of the device.  Consider the case where I have a rule to check the date on my AV dat file.  If my rule is looking for a dat file that is less than a week old I care about whether I pass now.  I don’t care if I passed last week.  If I find that I failed at evaluation time that might tell me I need more current data or it might tell me I have an AV dat problem.  Is there a case where I care about compliance in the past?  I think compliance now is what matters.  I am more concerned that I might have a false negative (I was compliant last week but I’m not now and the evaluator says I passed) than I am about a false positive (I was compliant last week and I am still compliant now but the evaluator says I failed).

 

In your file example below I agree that the February evaluation doesn’t tell you anything about the true state of the system but this is because the data is old.  You have no idea what happened on the system in the last month.

 

In any case, time_difference is defined in the oval definitions schema.  It is not part of the sc schema.  Would there be value in adding an option in time_difference to use the timestamp from the SC generator section?  I would still prefer the default be left as is.

 

Jim

 

 

From: Bill Lutton [[hidden email]]
Sent: Thursday, March 28, 2013 12:14 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

Interesting arguments… essentially, the meaning of ‘now’.

 

I find the argument that ‘now’ is related more to the collection process is more compelling than the argument that it is related to the ‘evaluation’ process.  The SC file inherently represents a snapshot in time – the value ‘now’ should be part of that snapshot.  In particular, if feels ‘wrong’ that the results of evaluating system characteristics depend on when that evaluation is done.

 

Other thoughts?

 

Tnx,

Bill L.

 

 

From: David Solin [[hidden email]]
Sent: Thursday, March 28, 2013 9:56 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Question about the intent of the time_difference function

 

For your use-case, one could provide an external variable containing the timestamp of the s-c file, and build an appropriate test.  Of course I suppose one could similarly pass the current timestamp in using an external variable.

But I would think, when using an old s-c file, one is inherently asking the question: "if these were the current settings, what is my compliance posture?", and not "what would my compliance posture have been back when these settings were collected".

On 3/28/2013 10:45 AM, Robert Huffman wrote:

I'm not sure that addresses my point, though. If you collected the system_characteristics at 3:00 AM on January 1, and your test to see if a file was less than a month old passed, great.

 

However, if you run that same system characteristics file through OVALDI at 3:00 AM on February 1, your test will now fail. However, I assert it does not tell you anything about the true state of your system. All you can really say for sure is that when those system characteristics were collected, your test passed. Saying it fails just because your ran the exact same file through your evaluator  month later may be a false negative.

 

On Thu, Mar 28, 2013 at 8:36 AM, David Solin <[hidden email]> wrote:

Then there would be no way to write a rule that says something should be less than a month old (for example).

 

On 3/28/2013 10:12 AM, Robert Huffman wrote:

The time_difference function can have one or two components. If it has a single component, the specification says the value of that component should be subtracted from the "current time".

 

This seems a bit odd to me. Take a tool like OVALDI that lets you specify a system characteristics file as input without actually running the scan. If one of the definitions uses a time_difference function with a single component, then the result of the definition will depend on the time the system characteristics are being evaluated. This means that evaluating the same system characteristics file can produce different result values depending on the time of the evaluation.

 

Perhaps this was the intent. However, if not, shouldn't the specification say the first operand should be something like the timestamp from the generator element of the system characteristics? That way the results would be deterministic.

 

 

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: SCAP Simplified.
Learn More | Features | Download

 

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: SCAP Simplified.
Learn More | Features | Download

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].

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].

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].

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].

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].