Standardized Vulnerability Remediation and System Modification

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

Standardized Vulnerability Remediation and System Modification

Kevin Sitto
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the establishment of an addendum to OVAL which specifies language allowing for vulnerability remediation and system modification for community review and comment

 

The OVAL suite of standards currently consists of three standards:

* OVAL Definitions
* OVAL System Characteristics
* OVAL Results

 

We propose the addition of an OVAL Modifications standard to the OVAL standards suite.  This standard defines a structure for vulnerability remediation and system modification integrating with many of the design paradigms established by other OVAL standards.

 

The basic addendum consists of the addition of a modifications element as a child to the oval_definitions element.  

This modifications element contains a list of modification elements which each specify:

* A unique modification identifier
* Typical metadata regarding the modification (author, timestamp, description, etc)
* References to other scap identifiers (OVAL tests/criteria, CXE, etc) relating the goal of the modification.
* References may also optionally exist from within OVAL Definition elements to OVAL modifications.
* Operation specific data (if its a registry modification a reference to the key/value to be modified and the desired value)

 

This specification builds on top of current community proposals and discussion to fulfill the requirements defined below.  

o        The standard shall allow for specification of action to be performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition (Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition (Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple remediations/modifications tied to a single action specification (What are my options to mitigate a vulnerability?)

 

There are benefits and risks associated with coupling remediation within the OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one file to maintain)

§         Marketing Merit  significant manpower has been put into public awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation (large, monolithic file)

·         We are assuming this will be mitigated as the availability and quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content creation tools continue to mature

 

We are making some assumptions moving forward relating to the continuing maturity of the OVAL specification, but believe this is the way to proceed which provides the highest amount of benefit while mitigating as much impact on content authors, consumers and tool vendors as possible.

 

Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd Dolinsky, Yuzheng Zhou

 


-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----


PGPexch.htm.pgp (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Kent Landfield
So what you have come up with is that we are going to integrate a full remediation language directly into OVAL?  Correct?

Wasn't this discussed at Developer Days and the consensus was this was a bad thing because it forced certification issues on every OVAL vendor and remediation required much more than OVAL was capable of? The fact that the stated efforts of OVAL was to provide all operations captured in the OVAL language and adding features such as scripting extensions was not desirable by Mitre.  Maybe I am remembering wrong but it was felt then that it would be better to have a dedicated remediation language that would not be encumbered by OVAL limitations but could use OVAL checks for dependency checking and remediation validation.

So now we are going 180 degrees and stuffing this back into OVAL?  Wow.

And as a Remediation Vendor for the past 5 years, remediation content that is accurate and complete is not simplistic.

Benefits???  The OVAL Brand?  I am looking for a real solution here not a perceived "brand".  The branding will work itself out when the standard itself works and is adopted widely by vendors and customers. That really isn't a benefit for determining the proper technical approach to the problem in my opinion.

So what of the uses and users for OVAL who do not want to do remediation?  Do they have to have remediation content in their files?  Do they have to code around it to ignore what they do not wish to do? One file contains everything?  Why is that a real benefit?  Should XCCDF have all the checks for OVAL in it? Would that be beneficial?

The community size?? SCAP is driving things not OVAL.  OVRL or what ever you want to call it will be successful if it is a) useful and b) flexible enough to deal with the nuances and minutia of remediations that are extremely diverse and complicated at times.  Community size is being driven by mandates from the federal government and their checkbook.   If the effort was setup totally independent of Mitre and OVAL, the community participating in it would roughly be the same.

While producing a language that can use existing OVAL checks to do dependency checking and remediation validation is a good thing and should be encouraged, OVAL is really not the basis for a flexible language for remediation.

This is a mistake and will do little to enhance either the OVAL effort as it exists today or a remediation standard that is sorely needed. This will defocus both and cause a great deal more in delays in getting something useful that vendors (open source or commercial) can incorporate.  

I would have expected some requirements that described the scope of the technical items to be addressed by the effort. That would have been a better place to start; then we could look at where it might fit. This needs to be addressed as a technical problem that needs to be solved and not a political football as to who owns it or who is funded by it.

As an OVAL Board Member I will vote against the proposal as documented below.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com
 
-----Original Message-----
From: Kevin Sitto [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 12:48 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the establishment of an addendum to OVAL which specifies language allowing for vulnerability remediation and system modification for community review and comment

 

The OVAL suite of standards currently consists of three standards:

* OVAL Definitions
* OVAL System Characteristics
* OVAL Results

 

We propose the addition of an OVAL Modifications standard to the OVAL standards suite.  This standard defines a structure for vulnerability remediation and system modification integrating with many of the design paradigms established by other OVAL standards.

 

The basic addendum consists of the addition of a modifications element as a child to the oval_definitions element.  

This modifications element contains a list of modification elements which each specify:

* A unique modification identifier
* Typical metadata regarding the modification (author, timestamp, description, etc)
* References to other scap identifiers (OVAL tests/criteria, CXE, etc) relating the goal of the modification.
* References may also optionally exist from within OVAL Definition elements to OVAL modifications.
* Operation specific data (if its a registry modification a reference to the key/value to be modified and the desired value)

 

This specification builds on top of current community proposals and discussion to fulfill the requirements defined below.  

o        The standard shall allow for specification of action to be performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition (Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition (Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple remediations/modifications tied to a single action specification (What are my options to mitigate a vulnerability?)

 

There are benefits and risks associated with coupling remediation within the OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one file to maintain)

§         Marketing Merit  significant manpower has been put into public awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation (large, monolithic file)

·         We are assuming this will be mitigated as the availability and quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content creation tools continue to mature

 

We are making some assumptions moving forward relating to the continuing maturity of the OVAL specification, but believe this is the way to proceed which provides the highest amount of benefit while mitigating as much impact on content authors, consumers and tool vendors as possible.

 

Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd Dolinsky, Yuzheng Zhou

 


-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Ken Lassesen-3
To put something else on the table that is related.

In the Windows world, a lot of stuff in compliance is handled by WMI.
One of the things that I have been both taught and seen, is that the
path of least resistance results in higher probability of adoption....
and learning new skills/approaches usually have high inertia
resistance...

Thus I would toss out the suggestion of an "OVAL_Remediation" WMI object
(or Object Set) and even suggest reflecting on a "OVAL_Detection_???"
(equivalent to OVALDI) WMI Object set.

This is very much a windows specific solution --- so I hope that it
would be extendable into other Oss.  

I realize that it is likely a bit orthogonal, but as of late, I am
finding WMI more and more sweet as a pattern...

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 2:04 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification

So what you have come up with is that we are going to integrate a full
remediation language directly into OVAL?  Correct?
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Wolfkiel, Joseph
In reply to this post by Kevin Sitto
Discussion group members,

I had a chance to talk with Kent last Thursday about the rationale behind
not wanting to have modification join the OVAL family of languages.  (I'm
really regretting that I didn't make it to Developer Days this year.)

At any rate, part of the reason we suggested keeping the modification
language within the OVAL family was so we could re-use much of the OVAL
language, particularly System Characteristics.  Logically, if OVAL is now
made up of a query language (OVAL Definitions), a data structure language
(System Characteristics), and a results format language (OVAL Results), it
seems logical to put the execution/modification language at the same level.
This would also potentially facilitate carrying remediations within OVAL
definition files so they could be distributed as single files.

Backing up a bit further, if OVAL isn't tightly integrated, I wonder what
would prevent us from replacing any of the separate pieces of OVAL with
other languages.  For example, it seems reasonable that you could get much
of OVAL's current functionality by running XQUERY against OVAL System
Characteristics, or even running SQL against WMI (Microsoft's implementation
of CIM -- apparently a direct competitor with System Characteristics).  I'm
aware of OVAL's origins as a database representation of different operating
systems that could be queried using SQL.

I had originally thought that deciding where the final home for the
modification language would be was a good logical first step.  Now I'm not
so sure.

I'll go back into huddle with the guys and talk about a reasonable way
forward.  Probably the easiest is to manage the development of a
remediation/modification language as a separate issue from the other OVAL
languages, while ensuring we preserve the capability to carry remediations
as part of OVAL definition files.  Once we have a workable construct, we can
revisit whether it should be part of the OVAL language, or a stand-alone
language with its own acronym (ORML?/OVRL?...whatever)

I also talked with Kent about whether we should ask NIST to set aside a
couple of half-day sessions to talk about 1) a modification/remediation
language and 2) SCAP integration problems.  He thought that was a good idea
and I agree.  I'm curious if there is broad support from the list for these
two topics.  Let me know.

My apologies for any ruffled feathers.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 5:04 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification


So what you have come up with is that we are going to integrate a full
remediation language directly into OVAL?  Correct?

Wasn't this discussed at Developer Days and the consensus was this was a bad
thing because it forced certification issues on every OVAL vendor and
remediation required much more than OVAL was capable of? The fact that the
stated efforts of OVAL was to provide all operations captured in the OVAL
language and adding features such as scripting extensions was not desirable
by Mitre.  Maybe I am remembering wrong but it was felt then that it would
be better to have a dedicated remediation language that would not be
encumbered by OVAL limitations but could use OVAL checks for dependency
checking and remediation validation.

So now we are going 180 degrees and stuffing this back into OVAL?  Wow.

And as a Remediation Vendor for the past 5 years, remediation content that
is accurate and complete is not simplistic.

Benefits???  The OVAL Brand?  I am looking for a real solution here not a
perceived "brand".  The branding will work itself out when the standard
itself works and is adopted widely by vendors and customers. That really
isn't a benefit for determining the proper technical approach to the problem
in my opinion.

So what of the uses and users for OVAL who do not want to do remediation?
Do they have to have remediation content in their files?  Do they have to
code around it to ignore what they do not wish to do? One file contains
everything?  Why is that a real benefit?  Should XCCDF have all the checks
for OVAL in it? Would that be beneficial?

The community size?? SCAP is driving things not OVAL.  OVRL or what ever you
want to call it will be successful if it is a) useful and b) flexible enough
to deal with the nuances and minutia of remediations that are extremely
diverse and complicated at times.  Community size is being driven by
mandates from the federal government and their checkbook.   If the effort
was setup totally independent of Mitre and OVAL, the community participating
in it would roughly be the same.

While producing a language that can use existing OVAL checks to do
dependency checking and remediation validation is a good thing and should be
encouraged, OVAL is really not the basis for a flexible language for
remediation.

This is a mistake and will do little to enhance either the OVAL effort as it
exists today or a remediation standard that is sorely needed. This will
defocus both and cause a great deal more in delays in getting something
useful that vendors (open source or commercial) can incorporate.  

I would have expected some requirements that described the scope of the
technical items to be addressed by the effort. That would have been a better
place to start; then we could look at where it might fit. This needs to be
addressed as a technical problem that needs to be solved and not a political
football as to who owns it or who is funded by it.

As an OVAL Board Member I will vote against the proposal as documented
below.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com
 
-----Original Message-----
From: Kevin Sitto [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 12:48 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability
Remediation and System Modification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the
establishment of an addendum to OVAL which specifies language allowing for
vulnerability remediation and system modification for community review and
comment

 

The OVAL suite of standards currently consists of three standards:

* OVAL Definitions
* OVAL System Characteristics
* OVAL Results

 

We propose the addition of an OVAL Modifications standard to the OVAL
standards suite.  This standard defines a structure for vulnerability
remediation and system modification integrating with many of the design
paradigms established by other OVAL standards.

 

The basic addendum consists of the addition of a modifications element as a
child to the oval_definitions element.  

This modifications element contains a list of modification elements which
each specify:

* A unique modification identifier
* Typical metadata regarding the modification (author, timestamp,
description, etc)
* References to other scap identifiers (OVAL tests/criteria, CXE, etc)
relating the goal of the modification.
* References may also optionally exist from within OVAL Definition
elements to OVAL modifications.
* Operation specific data (if its a registry modification a reference
to the key/value to be modified and the desired value)

 

This specification builds on top of current community proposals and
discussion to fulfill the requirements defined below.  

o        The standard shall allow for specification of action to be
performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the
distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition
(Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition
(Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple
remediations/modifications tied to a single action specification (What are
my options to mitigate a vulnerability?)

 

There are benefits and risks associated with coupling remediation within the
OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual
OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one
file to maintain)

§         Marketing Merit  significant manpower has been put into public
awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has
gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation
(large, monolithic file)

·         We are assuming this will be mitigated as the availability and
quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the
addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content
creation tools continue to mature

 

We are making some assumptions moving forward relating to the continuing
maturity of the OVAL specification, but believe this is the way to proceed
which provides the highest amount of benefit while mitigating as much impact
on content authors, consumers and tool vendors as possible.

 

Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd
Dolinsky, Yuzheng Zhou

 


-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Wolfkiel, Joseph
In reply to this post by Kevin Sitto
Clarification:  The half-day sessions would be directly before or after the
September SCAP conference.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, July 07, 2008 7:58 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification


Discussion group members,

I had a chance to talk with Kent last Thursday about the rationale behind
not wanting to have modification join the OVAL family of languages.  (I'm
really regretting that I didn't make it to Developer Days this year.)

At any rate, part of the reason we suggested keeping the modification
language within the OVAL family was so we could re-use much of the OVAL
language, particularly System Characteristics.  Logically, if OVAL is now
made up of a query language (OVAL Definitions), a data structure language
(System Characteristics), and a results format language (OVAL Results), it
seems logical to put the execution/modification language at the same level.
This would also potentially facilitate carrying remediations within OVAL
definition files so they could be distributed as single files.

Backing up a bit further, if OVAL isn't tightly integrated, I wonder what
would prevent us from replacing any of the separate pieces of OVAL with
other languages.  For example, it seems reasonable that you could get much
of OVAL's current functionality by running XQUERY against OVAL System
Characteristics, or even running SQL against WMI (Microsoft's implementation
of CIM -- apparently a direct competitor with System Characteristics).  I'm
aware of OVAL's origins as a database representation of different operating
systems that could be queried using SQL.

I had originally thought that deciding where the final home for the
modification language would be was a good logical first step.  Now I'm not
so sure.

I'll go back into huddle with the guys and talk about a reasonable way
forward.  Probably the easiest is to manage the development of a
remediation/modification language as a separate issue from the other OVAL
languages, while ensuring we preserve the capability to carry remediations
as part of OVAL definition files.  Once we have a workable construct, we can
revisit whether it should be part of the OVAL language, or a stand-alone
language with its own acronym (ORML?/OVRL?...whatever)

I also talked with Kent about whether we should ask NIST to set aside a
couple of half-day sessions to talk about 1) a modification/remediation
language and 2) SCAP integration problems.  He thought that was a good idea
and I agree.  I'm curious if there is broad support from the list for these
two topics.  Let me know.

My apologies for any ruffled feathers.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 5:04 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification


So what you have come up with is that we are going to integrate a full
remediation language directly into OVAL?  Correct?

Wasn't this discussed at Developer Days and the consensus was this was a bad
thing because it forced certification issues on every OVAL vendor and
remediation required much more than OVAL was capable of? The fact that the
stated efforts of OVAL was to provide all operations captured in the OVAL
language and adding features such as scripting extensions was not desirable
by Mitre.  Maybe I am remembering wrong but it was felt then that it would
be better to have a dedicated remediation language that would not be
encumbered by OVAL limitations but could use OVAL checks for dependency
checking and remediation validation.

So now we are going 180 degrees and stuffing this back into OVAL?  Wow.

And as a Remediation Vendor for the past 5 years, remediation content that
is accurate and complete is not simplistic.

Benefits???  The OVAL Brand?  I am looking for a real solution here not a
perceived "brand".  The branding will work itself out when the standard
itself works and is adopted widely by vendors and customers. That really
isn't a benefit for determining the proper technical approach to the problem
in my opinion.

So what of the uses and users for OVAL who do not want to do remediation?
Do they have to have remediation content in their files?  Do they have to
code around it to ignore what they do not wish to do? One file contains
everything?  Why is that a real benefit?  Should XCCDF have all the checks
for OVAL in it? Would that be beneficial?

The community size?? SCAP is driving things not OVAL.  OVRL or what ever you
want to call it will be successful if it is a) useful and b) flexible enough
to deal with the nuances and minutia of remediations that are extremely
diverse and complicated at times.  Community size is being driven by
mandates from the federal government and their checkbook.   If the effort
was setup totally independent of Mitre and OVAL, the community participating
in it would roughly be the same.

While producing a language that can use existing OVAL checks to do
dependency checking and remediation validation is a good thing and should be
encouraged, OVAL is really not the basis for a flexible language for
remediation.

This is a mistake and will do little to enhance either the OVAL effort as it
exists today or a remediation standard that is sorely needed. This will
defocus both and cause a great deal more in delays in getting something
useful that vendors (open source or commercial) can incorporate.  

I would have expected some requirements that described the scope of the
technical items to be addressed by the effort. That would have been a better
place to start; then we could look at where it might fit. This needs to be
addressed as a technical problem that needs to be solved and not a political
football as to who owns it or who is funded by it.

As an OVAL Board Member I will vote against the proposal as documented
below.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com
 
-----Original Message-----
From: Kevin Sitto [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 12:48 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability
Remediation and System Modification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the
establishment of an addendum to OVAL which specifies language allowing for
vulnerability remediation and system modification for community review and
comment

 

The OVAL suite of standards currently consists of three standards:

* OVAL Definitions
* OVAL System Characteristics
* OVAL Results

 

We propose the addition of an OVAL Modifications standard to the OVAL
standards suite.  This standard defines a structure for vulnerability
remediation and system modification integrating with many of the design
paradigms established by other OVAL standards.

 

The basic addendum consists of the addition of a modifications element as a
child to the oval_definitions element.  

This modifications element contains a list of modification elements which
each specify:

* A unique modification identifier
* Typical metadata regarding the modification (author, timestamp,
description, etc)
* References to other scap identifiers (OVAL tests/criteria, CXE, etc)
relating the goal of the modification.
* References may also optionally exist from within OVAL Definition
elements to OVAL modifications.
* Operation specific data (if its a registry modification a reference
to the key/value to be modified and the desired value)

 

This specification builds on top of current community proposals and
discussion to fulfill the requirements defined below.  

o        The standard shall allow for specification of action to be
performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the
distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition
(Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition
(Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple
remediations/modifications tied to a single action specification (What are
my options to mitigate a vulnerability?)

 

There are benefits and risks associated with coupling remediation within the
OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual
OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one
file to maintain)

§         Marketing Merit  significant manpower has been put into public
awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has
gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation
(large, monolithic file)

·         We are assuming this will be mitigated as the availability and
quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the
addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content
creation tools continue to mature

 

We are making some assumptions moving forward relating to the continuing
maturity of the OVAL specification, but believe this is the way to proceed
which provides the highest amount of benefit while mitigating as much impact
on content authors, consumers and tool vendors as possible.

 

Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd
Dolinsky, Yuzheng Zhou

 


-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Andrew Buttner
Administrator
In reply to this post by Kent Landfield
>Wasn't this discussed at Developer Days and the consensus was this was
a
>bad thing because it forced certification issues on every OVAL vendor
>and remediation required much more than OVAL was capable of? The fact
>that the stated efforts of OVAL was to provide all operations captured
>in the OVAL language and adding features such as scripting extensions
>was not desirable by Mitre.  Maybe I am remembering wrong but it was
>felt then that it would be better to have a dedicated remediation
>language that would not be encumbered by OVAL limitations but could
use
>OVAL checks for dependency checking and remediation validation.
>
>So now we are going 180 degrees and stuffing this back into OVAL?
Wow.

I took away Developer Days that we recognized that the remediation
logic and testing logic were closely related since when doing
remediation you also need to run the test to perform verification that
the remediation worked.  We also recognized that the two sets of logic
had to be kept separated since this will help make the content easier
to verify.

I think the above can be solved by either a separate modification
schema within OVAL, or a separate language outside of OVAL.  We just
have to watch how tightly we wrap things together.

Thanks
Drew
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Ken Lassesen-3
In reply to this post by Wolfkiel, Joseph
Nice sumary. You have support from this quarter.
 
There is both inertia resistance as well as 'sunk costs' resistance to be expected from those that have an "investment" in an existing solution which will likely be a constant factor as we get this thing rolling.
 
Many thanks!
 
Ken Lassesen
Home Office: 360-724-3190 Cell: 360-509-2402   Fax: 952-516-5077  Skype: Ken.Lassesen
IM: [hidden email] <mailto:[hidden email]>  
Web Cam: http://www.wunderground.com/webcams/Lassesen/1/show.html <http://www.wunderground.com/webcams/Lassesen/1/show.html>
Site Weather http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=KWABELLI19 <http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=KWABELLI19>

________________________________

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Mon 07-Jul-08 4:58 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification



Discussion group members,

I had a chance to talk with Kent last Thursday about the rationale behind
not wanting to have modification join the OVAL family of languages.  (I'm
really regretting that I didn't make it to Developer Days this year.)

At any rate, part of the reason we suggested keeping the modification
language within the OVAL family was so we could re-use much of the OVAL
language, particularly System Characteristics.  Logically, if OVAL is now
made up of a query language (OVAL Definitions), a data structure language
(System Characteristics), and a results format language (OVAL Results), it
seems logical to put the execution/modification language at the same level.
This would also potentially facilitate carrying remediations within OVAL
definition files so they could be distributed as single files.

Backing up a bit further, if OVAL isn't tightly integrated, I wonder what
would prevent us from replacing any of the separate pieces of OVAL with
other languages.  For example, it seems reasonable that you could get much
of OVAL's current functionality by running XQUERY against OVAL System
Characteristics, or even running SQL against WMI (Microsoft's implementation
of CIM -- apparently a direct competitor with System Characteristics).  I'm
aware of OVAL's origins as a database representation of different operating
systems that could be queried using SQL.

I had originally thought that deciding where the final home for the
modification language would be was a good logical first step.  Now I'm not
so sure.

I'll go back into huddle with the guys and talk about a reasonable way
forward.  Probably the easiest is to manage the development of a
remediation/modification language as a separate issue from the other OVAL
languages, while ensuring we preserve the capability to carry remediations
as part of OVAL definition files.  Once we have a workable construct, we can
revisit whether it should be part of the OVAL language, or a stand-alone
language with its own acronym (ORML?/OVRL?...whatever)

I also talked with Kent about whether we should ask NIST to set aside a
couple of half-day sessions to talk about 1) a modification/remediation
language and 2) SCAP integration problems.  He thought that was a good idea
and I agree.  I'm curious if there is broad support from the list for these
two topics.  Let me know.

My apologies for any ruffled feathers.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 5:04 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification


So what you have come up with is that we are going to integrate a full
remediation language directly into OVAL?  Correct?

Wasn't this discussed at Developer Days and the consensus was this was a bad
thing because it forced certification issues on every OVAL vendor and
remediation required much more than OVAL was capable of? The fact that the
stated efforts of OVAL was to provide all operations captured in the OVAL
language and adding features such as scripting extensions was not desirable
by Mitre.  Maybe I am remembering wrong but it was felt then that it would
be better to have a dedicated remediation language that would not be
encumbered by OVAL limitations but could use OVAL checks for dependency
checking and remediation validation.

So now we are going 180 degrees and stuffing this back into OVAL?  Wow.

And as a Remediation Vendor for the past 5 years, remediation content that
is accurate and complete is not simplistic.

Benefits???  The OVAL Brand?  I am looking for a real solution here not a
perceived "brand".  The branding will work itself out when the standard
itself works and is adopted widely by vendors and customers. That really
isn't a benefit for determining the proper technical approach to the problem
in my opinion.

So what of the uses and users for OVAL who do not want to do remediation?
Do they have to have remediation content in their files?  Do they have to
code around it to ignore what they do not wish to do? One file contains
everything?  Why is that a real benefit?  Should XCCDF have all the checks
for OVAL in it? Would that be beneficial?

The community size?? SCAP is driving things not OVAL.  OVRL or what ever you
want to call it will be successful if it is a) useful and b) flexible enough
to deal with the nuances and minutia of remediations that are extremely
diverse and complicated at times.  Community size is being driven by
mandates from the federal government and their checkbook.   If the effort
was setup totally independent of Mitre and OVAL, the community participating
in it would roughly be the same.

While producing a language that can use existing OVAL checks to do
dependency checking and remediation validation is a good thing and should be
encouraged, OVAL is really not the basis for a flexible language for
remediation.

This is a mistake and will do little to enhance either the OVAL effort as it
exists today or a remediation standard that is sorely needed. This will
defocus both and cause a great deal more in delays in getting something
useful that vendors (open source or commercial) can incorporate.

I would have expected some requirements that described the scope of the
technical items to be addressed by the effort. That would have been a better
place to start; then we could look at where it might fit. This needs to be
addressed as a technical problem that needs to be solved and not a political
football as to who owns it or who is funded by it.

As an OVAL Board Member I will vote against the proposal as documented
below.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

-----Original Message-----
From: Kevin Sitto [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 12:48 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability
Remediation and System Modification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the
establishment of an addendum to OVAL which specifies language allowing for
vulnerability remediation and system modification for community review and
comment



The OVAL suite of standards currently consists of three standards:

*       OVAL Definitions
*       OVAL System Characteristics
*       OVAL Results



We propose the addition of an OVAL Modifications standard to the OVAL
standards suite.  This standard defines a structure for vulnerability
remediation and system modification integrating with many of the design
paradigms established by other OVAL standards.



The basic addendum consists of the addition of a modifications element as a
child to the oval_definitions element.

This modifications element contains a list of modification elements which
each specify:

*       A unique modification identifier
*       Typical metadata regarding the modification (author, timestamp,
description, etc)
*       References to other scap identifiers (OVAL tests/criteria, CXE, etc)
relating the goal of the modification.
*       References may also optionally exist from within OVAL Definition
elements to OVAL modifications.
*       Operation specific data (if its a registry modification a reference
to the key/value to be modified and the desired value)



This specification builds on top of current community proposals and
discussion to fulfill the requirements defined below.

o        The standard shall allow for specification of action to be
performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the
distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition
(Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition
(Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple
remediations/modifications tied to a single action specification (What are
my options to mitigate a vulnerability?)



There are benefits and risks associated with coupling remediation within the
OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual
OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one
file to maintain)

§         Marketing Merit  significant manpower has been put into public
awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has
gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation
(large, monolithic file)

·         We are assuming this will be mitigated as the availability and
quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the
addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content
creation tools continue to mature



We are making some assumptions moving forward relating to the continuing
maturity of the OVAL specification, but believe this is the way to proceed
which provides the highest amount of benefit while mitigating as much impact
on content authors, consumers and tool vendors as possible.



Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd
Dolinsky, Yuzheng Zhou




-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Decoupling does not mean no reusing

Vladimir Giszpenc
In reply to this post by Andrew Buttner
Hello all,

Looking for a compromise, I see that we are not that far from each other.

Where will the remediation content live?

As I see it, it is part of the SCAP data stream.  Another file(set) that can
be referenced in the XCCDF makes the most sense.  This content already is
much more than one file.  Remediation should start at the Rule.  It sort of
does now, but seriously, it should start there more legitimately.  For those
that want one file, they can probably inline the OVAL and ORML right into
the XCCDF.  I am guessing no one will actually do that.

Should ORML reuse OVAL?

It will need to reuse a checking system for sure.  Since OVAL is the SCAP
preferred checking system, it will reuse it (by convention).  OVAL should
not be so closely coupled as to disallow other checking systems though.  It
should have the same flexibility as XCCDF.  Decoupling allows the languages
to mature independently.  So a precondition check and post condition check
that would look like XCCDF checks could use OVAL but would not be restricted
to that checking system.

How can they be separate?

Why can't we add the ability to reference OVAL ids that live in other files
the way XCCDF does?  This would also be useful with integrating CPE with
OVAL.  Once the ability exists, we can by convention (or officially) keep
the remediation content separate and still reuse OVAL definitions, tests,
etc.  

Is referring to an OVAL test OK?  

We said no at developer days, but we also said it was a convention and
nothing can stop someone outside OVAL from doing so.  I am of the opinion
that duplicating the data (e.g. test) in the ORML and OVAL is worse than
keeping OVAL's interface only definitions.

The fireworks are exciting.  Though I look forward to a quick solution.

Best regards,

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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Quilter, Alex
In reply to this post by Ken Lassesen-3
Maybe we should just use PERL or PYTHON for remediation; they are both already cross-platform and can support any nuance of remediation.  The content can even be standard .pl or .py files.   In fact, we could use them for assessment as well.

(This should be read as a joke).

-ALX

-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Monday, July 07, 2008 8:58 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification

Nice sumary. You have support from this quarter.

There is both inertia resistance as well as 'sunk costs' resistance to be expected from those that have an "investment" in an existing solution which will likely be a constant factor as we get this thing rolling.

Many thanks!

Ken Lassesen
Home Office: 360-724-3190 Cell: 360-509-2402   Fax: 952-516-5077  Skype: Ken.Lassesen
IM: [hidden email] <mailto:[hidden email]>
Web Cam: http://www.wunderground.com/webcams/Lassesen/1/show.html <http://www.wunderground.com/webcams/Lassesen/1/show.html>
Site Weather http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=KWABELLI19 <http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=KWABELLI19>

________________________________

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Mon 07-Jul-08 4:58 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification



Discussion group members,

I had a chance to talk with Kent last Thursday about the rationale behind
not wanting to have modification join the OVAL family of languages.  (I'm
really regretting that I didn't make it to Developer Days this year.)

At any rate, part of the reason we suggested keeping the modification
language within the OVAL family was so we could re-use much of the OVAL
language, particularly System Characteristics.  Logically, if OVAL is now
made up of a query language (OVAL Definitions), a data structure language
(System Characteristics), and a results format language (OVAL Results), it
seems logical to put the execution/modification language at the same level.
This would also potentially facilitate carrying remediations within OVAL
definition files so they could be distributed as single files.

Backing up a bit further, if OVAL isn't tightly integrated, I wonder what
would prevent us from replacing any of the separate pieces of OVAL with
other languages.  For example, it seems reasonable that you could get much
of OVAL's current functionality by running XQUERY against OVAL System
Characteristics, or even running SQL against WMI (Microsoft's implementation
of CIM -- apparently a direct competitor with System Characteristics).  I'm
aware of OVAL's origins as a database representation of different operating
systems that could be queried using SQL.

I had originally thought that deciding where the final home for the
modification language would be was a good logical first step.  Now I'm not
so sure.

I'll go back into huddle with the guys and talk about a reasonable way
forward.  Probably the easiest is to manage the development of a
remediation/modification language as a separate issue from the other OVAL
languages, while ensuring we preserve the capability to carry remediations
as part of OVAL definition files.  Once we have a workable construct, we can
revisit whether it should be part of the OVAL language, or a stand-alone
language with its own acronym (ORML?/OVRL?...whatever)

I also talked with Kent about whether we should ask NIST to set aside a
couple of half-day sessions to talk about 1) a modification/remediation
language and 2) SCAP integration problems.  He thought that was a good idea
and I agree.  I'm curious if there is broad support from the list for these
two topics.  Let me know.

My apologies for any ruffled feathers.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 5:04 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification


So what you have come up with is that we are going to integrate a full
remediation language directly into OVAL?  Correct?

Wasn't this discussed at Developer Days and the consensus was this was a bad
thing because it forced certification issues on every OVAL vendor and
remediation required much more than OVAL was capable of? The fact that the
stated efforts of OVAL was to provide all operations captured in the OVAL
language and adding features such as scripting extensions was not desirable
by Mitre.  Maybe I am remembering wrong but it was felt then that it would
be better to have a dedicated remediation language that would not be
encumbered by OVAL limitations but could use OVAL checks for dependency
checking and remediation validation.

So now we are going 180 degrees and stuffing this back into OVAL?  Wow.

And as a Remediation Vendor for the past 5 years, remediation content that
is accurate and complete is not simplistic.

Benefits???  The OVAL Brand?  I am looking for a real solution here not a
perceived "brand".  The branding will work itself out when the standard
itself works and is adopted widely by vendors and customers. That really
isn't a benefit for determining the proper technical approach to the problem
in my opinion.

So what of the uses and users for OVAL who do not want to do remediation?
Do they have to have remediation content in their files?  Do they have to
code around it to ignore what they do not wish to do? One file contains
everything?  Why is that a real benefit?  Should XCCDF have all the checks
for OVAL in it? Would that be beneficial?

The community size?? SCAP is driving things not OVAL.  OVRL or what ever you
want to call it will be successful if it is a) useful and b) flexible enough
to deal with the nuances and minutia of remediations that are extremely
diverse and complicated at times.  Community size is being driven by
mandates from the federal government and their checkbook.   If the effort
was setup totally independent of Mitre and OVAL, the community participating
in it would roughly be the same.

While producing a language that can use existing OVAL checks to do
dependency checking and remediation validation is a good thing and should be
encouraged, OVAL is really not the basis for a flexible language for
remediation.

This is a mistake and will do little to enhance either the OVAL effort as it
exists today or a remediation standard that is sorely needed. This will
defocus both and cause a great deal more in delays in getting something
useful that vendors (open source or commercial) can incorporate.

I would have expected some requirements that described the scope of the
technical items to be addressed by the effort. That would have been a better
place to start; then we could look at where it might fit. This needs to be
addressed as a technical problem that needs to be solved and not a political
football as to who owns it or who is funded by it.

As an OVAL Board Member I will vote against the proposal as documented
below.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

-----Original Message-----
From: Kevin Sitto [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 12:48 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability
Remediation and System Modification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the
establishment of an addendum to OVAL which specifies language allowing for
vulnerability remediation and system modification for community review and
comment



The OVAL suite of standards currently consists of three standards:

*       OVAL Definitions
*       OVAL System Characteristics
*       OVAL Results



We propose the addition of an OVAL Modifications standard to the OVAL
standards suite.  This standard defines a structure for vulnerability
remediation and system modification integrating with many of the design
paradigms established by other OVAL standards.



The basic addendum consists of the addition of a modifications element as a
child to the oval_definitions element.

This modifications element contains a list of modification elements which
each specify:

*       A unique modification identifier
*       Typical metadata regarding the modification (author, timestamp,
description, etc)
*       References to other scap identifiers (OVAL tests/criteria, CXE, etc)
relating the goal of the modification.
*       References may also optionally exist from within OVAL Definition
elements to OVAL modifications.
*       Operation specific data (if its a registry modification a reference
to the key/value to be modified and the desired value)



This specification builds on top of current community proposals and
discussion to fulfill the requirements defined below.

o        The standard shall allow for specification of action to be
performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the
distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition
(Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition
(Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple
remediations/modifications tied to a single action specification (What are
my options to mitigate a vulnerability?)



There are benefits and risks associated with coupling remediation within the
OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual
OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one
file to maintain)

§         Marketing Merit  significant manpower has been put into public
awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has
gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation
(large, monolithic file)

·         We are assuming this will be mitigated as the availability and
quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the
addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content
creation tools continue to mature



We are making some assumptions moving forward relating to the continuing
maturity of the OVAL specification, but believe this is the way to proceed
which provides the highest amount of benefit while mitigating as much impact
on content authors, consumers and tool vendors as possible.



Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd
Dolinsky, Yuzheng Zhou




-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Charlotte Rickert
Look at Configuresoft for this www.configuresoft.com :)

Charlotte Rickert I National Account Manager- Rocky Mt Region I Configuresoft, Inc. I Security, Compliance & Control for the Virtualized World I Tel: 719.310.2151 I Fax: 719.447.4607 I [hidden email]


-----Original Message-----
From: Quilter, Alex [mailto:[hidden email]]
Sent: Monday, July 07, 2008 7:32 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification

Maybe we should just use PERL or PYTHON for remediation; they are both already cross-platform and can support any nuance of remediation.  The content can even be standard .pl or .py files.   In fact, we could use them for assessment as well.

(This should be read as a joke).

-ALX

-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Monday, July 07, 2008 8:58 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification

Nice sumary. You have support from this quarter.

There is both inertia resistance as well as 'sunk costs' resistance to be expected from those that have an "investment" in an existing solution which will likely be a constant factor as we get this thing rolling.

Many thanks!

Ken Lassesen
Home Office: 360-724-3190 Cell: 360-509-2402   Fax: 952-516-5077  Skype: Ken.Lassesen
IM: [hidden email] <mailto:[hidden email]>
Web Cam: http://www.wunderground.com/webcams/Lassesen/1/show.html <http://www.wunderground.com/webcams/Lassesen/1/show.html>
Site Weather http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=KWABELLI19 <http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=KWABELLI19>

________________________________

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Mon 07-Jul-08 4:58 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability Remediation and System Modification



Discussion group members,

I had a chance to talk with Kent last Thursday about the rationale behind
not wanting to have modification join the OVAL family of languages.  (I'm
really regretting that I didn't make it to Developer Days this year.)

At any rate, part of the reason we suggested keeping the modification
language within the OVAL family was so we could re-use much of the OVAL
language, particularly System Characteristics.  Logically, if OVAL is now
made up of a query language (OVAL Definitions), a data structure language
(System Characteristics), and a results format language (OVAL Results), it
seems logical to put the execution/modification language at the same level.
This would also potentially facilitate carrying remediations within OVAL
definition files so they could be distributed as single files.

Backing up a bit further, if OVAL isn't tightly integrated, I wonder what
would prevent us from replacing any of the separate pieces of OVAL with
other languages.  For example, it seems reasonable that you could get much
of OVAL's current functionality by running XQUERY against OVAL System
Characteristics, or even running SQL against WMI (Microsoft's implementation
of CIM -- apparently a direct competitor with System Characteristics).  I'm
aware of OVAL's origins as a database representation of different operating
systems that could be queried using SQL.

I had originally thought that deciding where the final home for the
modification language would be was a good logical first step.  Now I'm not
so sure.

I'll go back into huddle with the guys and talk about a reasonable way
forward.  Probably the easiest is to manage the development of a
remediation/modification language as a separate issue from the other OVAL
languages, while ensuring we preserve the capability to carry remediations
as part of OVAL definition files.  Once we have a workable construct, we can
revisit whether it should be part of the OVAL language, or a stand-alone
language with its own acronym (ORML?/OVRL?...whatever)

I also talked with Kent about whether we should ask NIST to set aside a
couple of half-day sessions to talk about 1) a modification/remediation
language and 2) SCAP integration problems.  He thought that was a good idea
and I agree.  I'm curious if there is broad support from the list for these
two topics.  Let me know.

My apologies for any ruffled feathers.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 5:04 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
Vulnerability Remediation and System Modification


So what you have come up with is that we are going to integrate a full
remediation language directly into OVAL?  Correct?

Wasn't this discussed at Developer Days and the consensus was this was a bad
thing because it forced certification issues on every OVAL vendor and
remediation required much more than OVAL was capable of? The fact that the
stated efforts of OVAL was to provide all operations captured in the OVAL
language and adding features such as scripting extensions was not desirable
by Mitre.  Maybe I am remembering wrong but it was felt then that it would
be better to have a dedicated remediation language that would not be
encumbered by OVAL limitations but could use OVAL checks for dependency
checking and remediation validation.

So now we are going 180 degrees and stuffing this back into OVAL?  Wow.

And as a Remediation Vendor for the past 5 years, remediation content that
is accurate and complete is not simplistic.

Benefits???  The OVAL Brand?  I am looking for a real solution here not a
perceived "brand".  The branding will work itself out when the standard
itself works and is adopted widely by vendors and customers. That really
isn't a benefit for determining the proper technical approach to the problem
in my opinion.

So what of the uses and users for OVAL who do not want to do remediation?
Do they have to have remediation content in their files?  Do they have to
code around it to ignore what they do not wish to do? One file contains
everything?  Why is that a real benefit?  Should XCCDF have all the checks
for OVAL in it? Would that be beneficial?

The community size?? SCAP is driving things not OVAL.  OVRL or what ever you
want to call it will be successful if it is a) useful and b) flexible enough
to deal with the nuances and minutia of remediations that are extremely
diverse and complicated at times.  Community size is being driven by
mandates from the federal government and their checkbook.   If the effort
was setup totally independent of Mitre and OVAL, the community participating
in it would roughly be the same.

While producing a language that can use existing OVAL checks to do
dependency checking and remediation validation is a good thing and should be
encouraged, OVAL is really not the basis for a flexible language for
remediation.

This is a mistake and will do little to enhance either the OVAL effort as it
exists today or a remediation standard that is sorely needed. This will
defocus both and cause a great deal more in delays in getting something
useful that vendors (open source or commercial) can incorporate.

I would have expected some requirements that described the scope of the
technical items to be addressed by the effort. That would have been a better
place to start; then we could look at where it might fit. This needs to be
addressed as a technical problem that needs to be solved and not a political
football as to who owns it or who is funded by it.

As an OVAL Board Member I will vote against the proposal as documented
below.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

-----Original Message-----
From: Kevin Sitto [mailto:[hidden email]]
Sent: Thursday, July 03, 2008 12:48 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized Vulnerability
Remediation and System Modification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

G2, HP, and ThreatGuard submit the following proposal which calls for the
establishment of an addendum to OVAL which specifies language allowing for
vulnerability remediation and system modification for community review and
comment



The OVAL suite of standards currently consists of three standards:

*       OVAL Definitions
*       OVAL System Characteristics
*       OVAL Results



We propose the addition of an OVAL Modifications standard to the OVAL
standards suite.  This standard defines a structure for vulnerability
remediation and system modification integrating with many of the design
paradigms established by other OVAL standards.



The basic addendum consists of the addition of a modifications element as a
child to the oval_definitions element.

This modifications element contains a list of modification elements which
each specify:

*       A unique modification identifier
*       Typical metadata regarding the modification (author, timestamp,
description, etc)
*       References to other scap identifiers (OVAL tests/criteria, CXE, etc)
relating the goal of the modification.
*       References may also optionally exist from within OVAL Definition
elements to OVAL modifications.
*       Operation specific data (if its a registry modification a reference
to the key/value to be modified and the desired value)



This specification builds on top of current community proposals and
discussion to fulfill the requirements defined below.

o        The standard shall allow for specification of action to be
performed (Which state am I transitioning to?)

o        The standard shall allow for a machine actionable statement of the
distinct actions to be performed (What steps do I need to run?)

o        The standard shall allow for specification of asset precondition
(Which state do I need to be in to execute?)

o        The standard shall allow for specification of asset postcondition
(Which state will I be in after successful execution?)

o        The standard shall allow for specification of multiple
remediations/modifications tied to a single action specification (What are
my options to mitigate a vulnerability?)



There are benefits and risks associated with coupling remediation within the
OVAL standard as follows

o        Benefits

§         Ability to perform very granular remediation, based on individual
OVAL criteria which may have no CXE equivalent

§         One file has all content related to detection and remediation (one
file to maintain)

§         Marketing Merit  significant manpower has been put into public
awareness of the OVAL brand

§         Community Size  OVAL has a sizable community, some of which has
gone through arduous authorization processes to participate.

o        Risks

§         One file has all content related to detection and remediation
(large, monolithic file)

·         We are assuming this will be mitigated as the availability and
quality of the OVAL repositories and related APIs continues to improve

§         OVAL, as a standard, is already very large and complex before the
addition of relatively simplistic remediation content.

·         We are assuming this will be mitigated as the OVAL content
creation tools continue to mature



We are making some assumptions moving forward relating to the continuing
maturity of the OVAL specification, but believe this is the way to proceed
which provides the highest amount of benefit while mitigating as much impact
on content authors, consumers and tool vendors as possible.



Thanks,

Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd
Dolinsky, Yuzheng Zhou




-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d
t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK
cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU
yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ
G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT
DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g==
=ytlJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Decoupling does not mean no reusing

Kent Landfield
In reply to this post by Vladimir Giszpenc
Thanks Vladimir,

This is the type of discussion that I would have expected.  This was
also the approach that I thought we came out of Developer Days with.
The OVML/OVRL needs to be an integral part of the SCAP component
standards suite and as such should be able to use the other component
standards for including references and checking state dependencies,
remediation success/failure, etc.  This also allows OVRL/OVML to become
a building block standard just as all the others are. There is no reason
to change a successful architectural model now.

Also, on a non-important note...  What is it?

OVRL - Open Vulnerability Remediation Language
OVML - Open Vulnerability Modification Language

??

NIST has it as OVRL on their web site.

Like I said, not really important. Neither are too easy to pronounce...
;-)

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com
 

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 07, 2008 8:28 AM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Decoupling does not mean no
reusing

Hello all,

Looking for a compromise, I see that we are not that far from each
other.

Where will the remediation content live?

As I see it, it is part of the SCAP data stream.  Another file(set) that
can
be referenced in the XCCDF makes the most sense.  This content already
is
much more than one file.  Remediation should start at the Rule.  It sort
of
does now, but seriously, it should start there more legitimately.  For
those
that want one file, they can probably inline the OVAL and ORML right
into
the XCCDF.  I am guessing no one will actually do that.

Should ORML reuse OVAL?

It will need to reuse a checking system for sure.  Since OVAL is the
SCAP
preferred checking system, it will reuse it (by convention).  OVAL
should
not be so closely coupled as to disallow other checking systems though.
It
should have the same flexibility as XCCDF.  Decoupling allows the
languages
to mature independently.  So a precondition check and post condition
check
that would look like XCCDF checks could use OVAL but would not be
restricted
to that checking system.

How can they be separate?

Why can't we add the ability to reference OVAL ids that live in other
files
the way XCCDF does?  This would also be useful with integrating CPE with
OVAL.  Once the ability exists, we can by convention (or officially)
keep
the remediation content separate and still reuse OVAL definitions,
tests,
etc.  

Is referring to an OVAL test OK?  

We said no at developer days, but we also said it was a convention and
nothing can stop someone outside OVAL from doing so.  I am of the
opinion
that duplicating the data (e.g. test) in the ORML and OVAL is worse than
keeping OVAL's interface only definitions.

The fireworks are exciting.  Though I look forward to a quick solution.

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959
Reply | Threaded
Open this post in threaded view
|

Re: Decoupling does not mean no reusing

Quilter, Alex
Why not pull the V out; it is fairly clear that the scope of these discussions is strongly diverging from the scoping provided by "vulnerability" to generic actions on target platforms.  This is probably true of OVAL at this point as well. (open assessment language)

I think remediation makes sense for the vulnerability context; I think modification makes sense for the generic purpose.

I have the same issue with SCAP (is the "S" really for "security" or is it for "system").

I have a feeling that most people on in this discussion are not specifically limited in thinking about security or vulnerability but to system and state change.

To me, the focus on vulnerability and security has been important, and the farther remediation moves away from vulnerability the less focused the requirements become around vulnerability.

If we want general purpose open languages for state assessment and state change, then that is fine; however, even in this case why would there be a different language for assessment (RO) and change (RW)?

Anyway...

-ALX

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Monday, July 07, 2008 10:24 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Decoupling does not mean no reusing

Thanks Vladimir,

This is the type of discussion that I would have expected.  This was
also the approach that I thought we came out of Developer Days with.
The OVML/OVRL needs to be an integral part of the SCAP component
standards suite and as such should be able to use the other component
standards for including references and checking state dependencies,
remediation success/failure, etc.  This also allows OVRL/OVML to become
a building block standard just as all the others are. There is no reason
to change a successful architectural model now.

Also, on a non-important note...  What is it?

OVRL - Open Vulnerability Remediation Language
OVML - Open Vulnerability Modification Language

??

NIST has it as OVRL on their web site.

Like I said, not really important. Neither are too easy to pronounce...
;-)

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com


-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 07, 2008 8:28 AM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Decoupling does not mean no
reusing

Hello all,

Looking for a compromise, I see that we are not that far from each
other.

Where will the remediation content live?

As I see it, it is part of the SCAP data stream.  Another file(set) that
can
be referenced in the XCCDF makes the most sense.  This content already
is
much more than one file.  Remediation should start at the Rule.  It sort
of
does now, but seriously, it should start there more legitimately.  For
those
that want one file, they can probably inline the OVAL and ORML right
into
the XCCDF.  I am guessing no one will actually do that.

Should ORML reuse OVAL?

It will need to reuse a checking system for sure.  Since OVAL is the
SCAP
preferred checking system, it will reuse it (by convention).  OVAL
should
not be so closely coupled as to disallow other checking systems though.
It
should have the same flexibility as XCCDF.  Decoupling allows the
languages
to mature independently.  So a precondition check and post condition
check
that would look like XCCDF checks could use OVAL but would not be
restricted
to that checking system.

How can they be separate?

Why can't we add the ability to reference OVAL ids that live in other
files
the way XCCDF does?  This would also be useful with integrating CPE with
OVAL.  Once the ability exists, we can by convention (or officially)
keep
the remediation content separate and still reuse OVAL definitions,
tests,
etc.

Is referring to an OVAL test OK?

We said no at developer days, but we also said it was a convention and
nothing can stop someone outside OVAL from doing so.  I am of the
opinion
that duplicating the data (e.g. test) in the ORML and OVAL is worse than
keeping OVAL's interface only definitions.

The fireworks are exciting.  Though I look forward to a quick solution.

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959
Reply | Threaded
Open this post in threaded view
|

Re: Standardized Vulnerability Remediation and System Modification

Andrew Buttner
Administrator
In reply to this post by Wolfkiel, Joseph
I'd like to follow up on the conversation from yesterday about where
this remediation/modification language lives going forward,
specifically about if it becomes its own project or stays as part of
OVAL.  As Lt Col Wolfkiel mentioned, this technically doesn't have to
be decided right now, but we think it would be good to have this
decided sooner rather than later.  Mainly because OVAL needs to plan
its version 6.0 development.  

First off, MITRE and the OVAL Team are very excited about the level of
interest in developing a new remediation/modification language,
regardless of where it ends up living.  However. we do see this as a
natural progression of OVAL though, which started with just definitions
and has since grown to include sys characteristic and then results as
needs arose.  Remediation is the next step.

We feel that having remediation/modification under OVAL will help keep
the new language following similar constructs as the existing schemas
which should help users understand things easier.  We also feel that it
will make for a cleaner solution that will fit well together.  Having a
separate initiative will open up the possibility of development
following different trends and formats.  However, we are in agreement
that whatever is developed should not cloud the current oval definition
schema and content.

We will discuss this issue again with the OVAL Board to get their
guidance, and we hope that in the time being the great conversation
that has already taken place continues.

Thanks
Drew





>-----Original Message-----
>From: Wolfkiel, Joseph [mailto:[hidden email]]
>Sent: Monday, July 07, 2008 7:58 AM
>To: oval-remediation-discussion-list Open Remediation Language Commu
>Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
>Vulnerability Remediation and System Modification
>
>Discussion group members,
>
>I had a chance to talk with Kent last Thursday about the rationale
>behind not wanting to have modification join the OVAL family of
>languages. (I'm really regretting that I didn't make it to
>Developer Days this year.)
>
>At any rate, part of the reason we suggested keeping the modification
>language within the OVAL family was so we could re-use much of the
OVAL
>language, particularly System Characteristics.  Logically, if OVAL is
>now
>made up of a query language (OVAL Definitions), a data structure
>language
>(System Characteristics), and a results format language (OVAL
Results),
>it
>seems logical to put the execution/modification language at the same
>level.
>This would also potentially facilitate carrying remediations within
OVAL
>definition files so they could be distributed as single files.
>
>Backing up a bit further, if OVAL isn't tightly integrated, I wonder
>what
>would prevent us from replacing any of the separate pieces of OVAL
with

>other languages.  For example, it seems reasonable that you could get
>much
>of OVAL's current functionality by running XQUERY against OVAL System
>Characteristics, or even running SQL against WMI (Microsoft's
>implementation
>of CIM -- apparently a direct competitor with System Characteristics).
>I'm
>aware of OVAL's origins as a database representation of different
>operating
>systems that could be queried using SQL.
>
>I had originally thought that deciding where the final home for the
>modification language would be was a good logical first step.  Now I'm
>not
>so sure.
>
>I'll go back into huddle with the guys and talk about a reasonable way
>forward.  Probably the easiest is to manage the development of a
>remediation/modification language as a separate issue from the other
>OVAL
>languages, while ensuring we preserve the capability to carry
>remediations
>as part of OVAL definition files.  Once we have a workable construct,
we
>can
>revisit whether it should be part of the OVAL language, or a
stand-alone
>language with its own acronym (ORML?/OVRL?...whatever)
>
>I also talked with Kent about whether we should ask NIST to set aside
a
>couple of half-day sessions to talk about 1) a
modification/remediation

>language and 2) SCAP integration problems.  He thought that was a good
>idea
>and I agree.  I'm curious if there is broad support from the list for
>these
>two topics.  Let me know.
>
>My apologies for any ruffled feathers.
>
>Lt Col Joseph L. Wolfkiel
>
>Director, Computer Network Defense Research & Technology (CND R&T)
>Program
>Management Office
>
>9800 Savage Rd Ste 6767
>Ft Meade, MD 20755-6767
>Commercial 410-854-5401 DSN 244-5401
>Fax 410-854-6700
>
>
>-----Original Message-----
>From: Kent Landfield [mailto:[hidden email]]
>Sent: Thursday, July 03, 2008 5:04 PM
>To: [hidden email]
>Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Standardized
>Vulnerability Remediation and System Modification
>
>
>So what you have come up with is that we are going to integrate a full
>remediation language directly into OVAL?  Correct?
>
>Wasn't this discussed at Developer Days and the consensus was this was
a

>bad
>thing because it forced certification issues on every OVAL vendor and
>remediation required much more than OVAL was capable of? The fact that
>the
>stated efforts of OVAL was to provide all operations captured in the
>OVAL
>language and adding features such as scripting extensions was not
>desirable
>by Mitre.  Maybe I am remembering wrong but it was felt then that it
>would
>be better to have a dedicated remediation language that would not be
>encumbered by OVAL limitations but could use OVAL checks for
dependency
>checking and remediation validation.
>
>So now we are going 180 degrees and stuffing this back into OVAL?
Wow.
>
>And as a Remediation Vendor for the past 5 years, remediation content
>that
>is accurate and complete is not simplistic.
>
>Benefits???  The OVAL Brand?  I am looking for a real solution here
not
>a
>perceived "brand".  The branding will work itself out when the
standard
>itself works and is adopted widely by vendors and customers. That
really
>isn't a benefit for determining the proper technical approach to the
>problem
>in my opinion.
>
>So what of the uses and users for OVAL who do not want to do
>remediation?
>Do they have to have remediation content in their files?  Do they have
>to
>code around it to ignore what they do not wish to do? One file
contains
>everything?  Why is that a real benefit?  Should XCCDF have all the
>checks
>for OVAL in it? Would that be beneficial?
>
>The community size?? SCAP is driving things not OVAL.  OVRL or what
ever
>you
>want to call it will be successful if it is a) useful and b) flexible
>enough
>to deal with the nuances and minutia of remediations that are
extremely

>diverse and complicated at times.  Community size is being driven by
>mandates from the federal government and their checkbook.   If the
>effort
>was setup totally independent of Mitre and OVAL, the community
>participating
>in it would roughly be the same.
>
>While producing a language that can use existing OVAL checks to do
>dependency checking and remediation validation is a good thing and
>should be
>encouraged, OVAL is really not the basis for a flexible language for
>remediation.
>
>This is a mistake and will do little to enhance either the OVAL effort
>as it
>exists today or a remediation standard that is sorely needed. This
will
>defocus both and cause a great deal more in delays in getting
something
>useful that vendors (open source or commercial) can incorporate.
>
>I would have expected some requirements that described the scope of
the
>technical items to be addressed by the effort. That would have been a
>better
>place to start; then we could look at where it might fit. This needs
to

>be
>addressed as a technical problem that needs to be solved and not a
>political
>football as to who owns it or who is funded by it.
>
>As an OVAL Board Member I will vote against the proposal as documented
>below.
>
>--
>Kent Landfield
>Director, Risk and Compliance Security Research
>McAfee, Inc.
>+1 972.963.7096 Direct
>+1 214.385.1138 Mobile
>[hidden email]
>www.mcafee.com