scripting in OVAL

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

scripting in OVAL

Michael Tan-2
Hi, have we discussed about scripting support in OVAL as one of data dsicovery mechanism. What are pros and cons? I consider it's a good flexibility in case a new data type is not supported by the existing OVAL schema.

Michael
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: scripting in OVAL

Gary Gapinski-4
Michael Tan wrote:
>
> Hi, have we discussed about scripting support in OVAL as one of data
> dsicovery mechanism. What are pros and cons? I consider it's a good
> flexibility in case a new data type is not supported by the existing
> OVAL schema.
>


It has been previously discussed. I think it is an excellent idea,
though it offends the religious sensibilities of some.

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: scripting in OVAL

Mark Foster-2
Gary Gapinski wrote:

> Michael Tan wrote:
>  
>> Hi, have we discussed about scripting support in OVAL as one of data
>> dsicovery mechanism. What are pros and cons? I consider it's a good
>> flexibility in case a new data type is not supported by the existing
>> OVAL schema.
>>    
>
>
> It has been previously discussed. I think it is an excellent idea,
> though it offends the religious sensibilities of some.

I think it is a terrible idea. Wouldn't it be ironic and sad if you
introduced vulnerabilities in OVAL this way?
It should be abstracted away.

--
Realization #2031: That the "meaning of life" is now just another Google search.
Mark D. Foster <[hidden email]>  
http://mark.foster.cc/ | http://conshell.net/

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: scripting in OVAL

Jon Baker
Administrator
Michael,

Here is a link to a lengthy discussion on a proposal similar to your request.

http://n2.nabble.com/Proposed-New-Test%3A-command_test-tp22997p22997.html

If you search the list archives a bit you will find other similar conversations.

Regards,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]


>-----Original Message-----
>From: Mark Foster [mailto:[hidden email]]
>Sent: Friday, January 16, 2009 3:05 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL
>
>Gary Gapinski wrote:
>> Michael Tan wrote:
>>
>>> Hi, have we discussed about scripting support in OVAL as one of data
>>> dsicovery mechanism. What are pros and cons? I consider it's a good
>>> flexibility in case a new data type is not supported by the existing
>>> OVAL schema.
>>>
>>
>>
>> It has been previously discussed. I think it is an excellent idea,
>> though it offends the religious sensibilities of some.
>
>I think it is a terrible idea. Wouldn't it be ironic and sad if you
>introduced vulnerabilities in OVAL this way?
>It should be abstracted away.
>
>--
>Realization #2031: That the "meaning of life" is now just another Google
>search.
>Mark D. Foster <[hidden email]>
>http://mark.foster.cc/ | http://conshell.net/
>
>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 OVAL-
>[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: scripting in OVAL

Stephen.Quinn
Folks,

  I had this discussion with a vendor recently as well.  While I agree  
that there are reasons to be specific regarding OVAL; there is also a  
need to provide either a new specification (something like Open  
Command Querying Language (OCQL)), or an extension to OVAL that allows  
for command line/script execution.  While we would not want this to  
usurp the preferred authenticated checking method offered by current  
OVAL checking, we also need to be mindful of the use cases where OVAL  
may not have a presence or be applicable.

Michael Tan offered a great reason in his posting and I also offer the  
use cases of platforms that primarily offer a command line interface.

It seems to me that we can offer the ability for folks to move forward  
where scripting is applicable; while at the same time protecting the  
preferred methods current OVAL checking.

 From an SCAP use case perspective, there is great value at having  
multiple checking languages and methods to evaluate target systems.  
In cases of system compromise, the values returned through a command  
line query that differ from API query can help diagnose and categorize  
the disposition of the system.  Certain SCAP use cases would like to  
aggregate results from different checking methods, whereas other SCAP  
use cases (like compliance scanning) would tend toward the traditional  
OVAL checking.

To evaluate the value in pursuing this, can folks offer some  
additional uses cases?

Respectfully,
Steve

Quoting "Baker, Jon" <[hidden email]>:

> Michael,
>
> Here is a link to a lengthy discussion on a proposal similar to your request.
>
> http://n2.nabble.com/Proposed-New-Test%3A-command_test-tp22997p22997.html
>
> If you search the list archives a bit you will find other similar  
> conversations.
>
> Regards,
>
> Jon
>
> ============================================
> Jonathan O. Baker
> The MITRE Corporation
> Email: [hidden email]
>
>
>> -----Original Message-----
>> From: Mark Foster [mailto:[hidden email]]
>> Sent: Friday, January 16, 2009 3:05 PM
>> To: oval-developer-list OVAL Developer List/Closed Public Discussion
>> Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL
>>
>> Gary Gapinski wrote:
>>> Michael Tan wrote:
>>>
>>>> Hi, have we discussed about scripting support in OVAL as one of data
>>>> dsicovery mechanism. What are pros and cons? I consider it's a good
>>>> flexibility in case a new data type is not supported by the existing
>>>> OVAL schema.
>>>>
>>>
>>>
>>> It has been previously discussed. I think it is an excellent idea,
>>> though it offends the religious sensibilities of some.
>>
>> I think it is a terrible idea. Wouldn't it be ironic and sad if you
>> introduced vulnerabilities in OVAL this way?
>> It should be abstracted away.
>>
>> --
>> Realization #2031: That the "meaning of life" is now just another Google
>> search.
>> Mark D. Foster <[hidden email]>
>> http://mark.foster.cc/ | http://conshell.net/
>>
>> 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 OVAL-
>> [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].
>



--
Stephen Quinn
NIST

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: scripting in OVAL

Vladimir Giszpenc
Steve et al,

<hedge>
In the C# programming language there is a reserved word named "unsafe"
for doing things that are just that.  Maybe we could come up with
something similar. </hedge>  Ideally though, the OVAL language is
expanded.  

Some point against OVAL going towards scripting:
One can use scripts to evaluate the OVAL content and be guaranteed some
level of safety.  Scripts taken wholesale cannot be validated.
From an SCAP perspective, one can use a different checking system from
XCCDF.
Versioning is hard enough with OVAL.  What can of worms will scripting
open?

Always your devil's advocate,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Steve Quinn [mailto:[hidden email]]
> Sent: Tuesday, January 20, 2009 11:18 AM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL
>
> Folks,
>
>   I had this discussion with a vendor recently as well.  While I agree
> that there are reasons to be specific regarding OVAL; there is also a
> need to provide either a new specification (something like Open
> Command Querying Language (OCQL)), or an extension to OVAL that allows
> for command line/script execution.  While we would not want this to
> usurp the preferred authenticated checking method offered by current
> OVAL checking, we also need to be mindful of the use cases where OVAL
> may not have a presence or be applicable.
>
> Michael Tan offered a great reason in his posting and I also offer the
> use cases of platforms that primarily offer a command line interface.
>
> It seems to me that we can offer the ability for folks to move forward
> where scripting is applicable; while at the same time protecting the
> preferred methods current OVAL checking.
>
>  From an SCAP use case perspective, there is great value at having
> multiple checking languages and methods to evaluate target systems.
> In cases of system compromise, the values returned through a command
> line query that differ from API query can help diagnose and categorize
> the disposition of the system.  Certain SCAP use cases would like to
> aggregate results from different checking methods, whereas other SCAP
> use cases (like compliance scanning) would tend toward the traditional
> OVAL checking.
>
> To evaluate the value in pursuing this, can folks offer some
> additional uses cases?
>
> Respectfully,
> Steve
>
> Quoting "Baker, Jon" <[hidden email]>:
>
> > Michael,
> >
> > Here is a link to a lengthy discussion on a proposal similar to your
> request.
> >
> > http://n2.nabble.com/Proposed-New-Test%3A-command_test-
> tp22997p22997.html
> >
> > If you search the list archives a bit you will find other similar
> > conversations.
> >
> > Regards,
> >
> > Jon
> >
> > ============================================
> > Jonathan O. Baker
> > The MITRE Corporation
> > Email: [hidden email]
> >
> >
> >> -----Original Message-----
> >> From: Mark Foster [mailto:[hidden email]]
> >> Sent: Friday, January 16, 2009 3:05 PM
> >> To: oval-developer-list OVAL Developer List/Closed Public
Discussion

> >> Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL
> >>
> >> Gary Gapinski wrote:
> >>> Michael Tan wrote:
> >>>
> >>>> Hi, have we discussed about scripting support in OVAL as one of
> data
> >>>> dsicovery mechanism. What are pros and cons? I consider it's a
> good
> >>>> flexibility in case a new data type is not supported by the
> existing
> >>>> OVAL schema.
> >>>>
> >>>
> >>>
> >>> It has been previously discussed. I think it is an excellent idea,
> >>> though it offends the religious sensibilities of some.
> >>
> >> I think it is a terrible idea. Wouldn't it be ironic and sad if you
> >> introduced vulnerabilities in OVAL this way?
> >> It should be abstracted away.
> >>
> >> --
> >> Realization #2031: That the "meaning of life" is now just another
> Google
> >> search.
> >> Mark D. Foster <[hidden email]>
> >> http://mark.foster.cc/ | http://conshell.net/
> >>
> >> 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
> OVAL-
> >> [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].
> >
>
>
>
> --
> Stephen Quinn
> NIST
>
> 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 OVAL-
> [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: scripting in OVAL

Maneesh Jolly
Hi All,

I don't want to categorize myself as "for" or "against" OVAL going towards
scripting because I am still a newbie for all this.

I think rather than allowing direct scripting we should make use of the
concept on which WMI is based i.e. DMTF promoted management objects. Windows
provide access to their standard management objects (CIM, WBEM etc.) through
the use of WMI. In current version OVAL support WMI tests. However I am not
very sure about their equivalent in other operating systems.

If we want to include scripting for gathering information only then I don't
think we should do that because we can get almost all the information from
other standard methods or WMI in case of windows.
 
But if the proposal for including scripting is made by keeping in mind that
in future we might want to specify generation of alerts or corrective
actions through XCCDF or OVAL (may be) then we can think about scripting.

Please excuse me in case I've diverted too much from the issue being
discussed.

Regards,
Maneesh

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Tuesday, January 20, 2009 11:56 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL

Steve et al,

<hedge>
In the C# programming language there is a reserved word named "unsafe"
for doing things that are just that.  Maybe we could come up with
something similar. </hedge>  Ideally though, the OVAL language is
expanded.  

Some point against OVAL going towards scripting:
One can use scripts to evaluate the OVAL content and be guaranteed some
level of safety.  Scripts taken wholesale cannot be validated.
>From an SCAP perspective, one can use a different checking system from
XCCDF.
Versioning is hard enough with OVAL.  What can of worms will scripting
open?

Always your devil's advocate,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


> -----Original Message-----
> From: Steve Quinn [mailto:[hidden email]]
> Sent: Tuesday, January 20, 2009 11:18 AM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL
>
> Folks,
>
>   I had this discussion with a vendor recently as well.  While I agree
> that there are reasons to be specific regarding OVAL; there is also a
> need to provide either a new specification (something like Open
> Command Querying Language (OCQL)), or an extension to OVAL that allows
> for command line/script execution.  While we would not want this to
> usurp the preferred authenticated checking method offered by current
> OVAL checking, we also need to be mindful of the use cases where OVAL
> may not have a presence or be applicable.
>
> Michael Tan offered a great reason in his posting and I also offer the
> use cases of platforms that primarily offer a command line interface.
>
> It seems to me that we can offer the ability for folks to move forward
> where scripting is applicable; while at the same time protecting the
> preferred methods current OVAL checking.
>
>  From an SCAP use case perspective, there is great value at having
> multiple checking languages and methods to evaluate target systems.
> In cases of system compromise, the values returned through a command
> line query that differ from API query can help diagnose and categorize
> the disposition of the system.  Certain SCAP use cases would like to
> aggregate results from different checking methods, whereas other SCAP
> use cases (like compliance scanning) would tend toward the traditional
> OVAL checking.
>
> To evaluate the value in pursuing this, can folks offer some
> additional uses cases?
>
> Respectfully,
> Steve
>
> Quoting "Baker, Jon" <[hidden email]>:
>
> > Michael,
> >
> > Here is a link to a lengthy discussion on a proposal similar to your
> request.
> >
> > http://n2.nabble.com/Proposed-New-Test%3A-command_test-
> tp22997p22997.html
> >
> > If you search the list archives a bit you will find other similar
> > conversations.
> >
> > Regards,
> >
> > Jon
> >
> > ============================================
> > Jonathan O. Baker
> > The MITRE Corporation
> > Email: [hidden email]
> >
> >
> >> -----Original Message-----
> >> From: Mark Foster [mailto:[hidden email]]
> >> Sent: Friday, January 16, 2009 3:05 PM
> >> To: oval-developer-list OVAL Developer List/Closed Public
Discussion

> >> Subject: Re: [OVAL-DEVELOPER-LIST] scripting in OVAL
> >>
> >> Gary Gapinski wrote:
> >>> Michael Tan wrote:
> >>>
> >>>> Hi, have we discussed about scripting support in OVAL as one of
> data
> >>>> dsicovery mechanism. What are pros and cons? I consider it's a
> good
> >>>> flexibility in case a new data type is not supported by the
> existing
> >>>> OVAL schema.
> >>>>
> >>>
> >>>
> >>> It has been previously discussed. I think it is an excellent idea,
> >>> though it offends the religious sensibilities of some.
> >>
> >> I think it is a terrible idea. Wouldn't it be ironic and sad if you
> >> introduced vulnerabilities in OVAL this way?
> >> It should be abstracted away.
> >>
> >> --
> >> Realization #2031: That the "meaning of life" is now just another
> Google
> >> search.
> >> Mark D. Foster <[hidden email]>
> >> http://mark.foster.cc/ | http://conshell.net/
> >>
> >> 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
> OVAL-
> >> [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].
> >
>
>
>
> --
> Stephen Quinn
> NIST
>
> 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 OVAL-
> [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].