Undo, Automated != Ignore Users

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

Undo, Automated != Ignore Users

Vladimir Giszpenc
Hello folks,

What I don't remember seeing at developer days was much about how to undo
the damage our wonderful language ORML will allow us to wreak on
unsuspecting hosts.  I am hoping for transactions and I am hoping to know
what to do when something goes wrong.  The language should build this in
from the start otherwise, knowing what was done to a system and how to undo
it will be different from tool to tool.

A lot of attention has been given to the Windows registry.  I will try to
focus attention on files.  We are still having trouble figuring out how to
assess the state of files (textfilecontent??), I can't wait for the problems
with tweaking them.

As far as patches being trivial as one vendor posited, I think that they are
not as trivial as one might think.  They have dependencies and more
importantly, they have different dependencies than the packages they replace
which can cause existing things to break.  I believe it is short sighted to
blindly patch systems (of course windows update might not have the
capabilities of other OSes) but the language should try to do no harm.

I have a general question about user interaction.  Given that this is part
of SCAP, how much user interaction will there be?  Will it be defined in the
language?

For example, if the Modification is to do a call to

        yum Uvh foo

And it asks
        Installing foo 1.2-3
        Installing bar 4.5-6
        OK [Yes]/No

Do we make these things non interactive?
Does ORML have a prepare/propose actions to present to the user or it up to
the vendor to do/not do this?

Being the list nag I must ask, how will this content get versioned?  I
figure we are starting on the ground floor so let's do it right from the
start (and maybe we can get the rest of SCAP to follow suit).  

I read slowly so I will be quiet for a while when I get the next proposal.
;)


Cheerio,

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: Undo, Automated != Ignore Users

Ken Lassesen-3
The ability to do an undo may be limited on Windows.   Some patches are
not uninstallable....

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 07, 2008 1:18 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
Users

Hello folks,

What I don't remember seeing at developer days was much about how to
undo
the damage our wonderful language ORML will allow us to wreak on
unsuspecting hosts.  I am hoping for transactions and I am hoping to
know
what to do when something goes wrong.  The language should build this in
from the start otherwise, knowing what was done to a system and how to
undo
it will be different from tool to tool.
Reply | Threaded
Open this post in threaded view
|

Re: Undo, Automated != Ignore Users

Vladimir Giszpenc

> The ability to do an undo may be limited on Windows.   Some patches are
> not uninstallable....

I am sure there are things on Linux and elsewhere that cannot be undone.
However, since changing a registry value is undoable and so are file edits,
undo is very valuable nonetheless.  If we don't make it part of the
language, we will be handicapped.  Even your statement suggests many patches
on Windows *are* uninstallable.

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: Undo, Automated != Ignore Users

Wolfkiel, Joseph
In reply to this post by Vladimir Giszpenc
I suppose the "right" way to go about this is to capture these sorts of
requirements into a design specification of some sort.

So far, we want to be able to apply patches, provide for "undo" capabilities
where supported, delete, modify, and add files.  I imagine we also want to
be able to run executables, replace vulnerable or unwanted programs with
newer versions, and some other, as yet to be defined, things.  Also provide
the optional ability to interact with users.

Probably wouldn't hurt to build a small lexicon of terms (e.g.
"remediation": modifying a target software or hardware platform in response
to a policy non-compliant state; "modification": the making of a limited
change in something [regardless of motivation])

I can volunteer labor to do this type of work, though it may be more a
appropriate for MITRE to do it.

Any thoughts?  Maybe someone already has their requirements documented and
could contribute them as a starting point?

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: Ken Lassesen [mailto:[hidden email]]
Sent: Monday, July 07, 2008 4:24 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users


The ability to do an undo may be limited on Windows.   Some patches are
not uninstallable....

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 07, 2008 4:18 PM
To: [hidden email]
Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
Users

Hello folks,

What I don't remember seeing at developer days was much about how to undo
the damage our wonderful language ORML will allow us to wreak on
unsuspecting hosts.  I am hoping for transactions and I am hoping to know
what to do when something goes wrong.  The language should build this in
from the start otherwise, knowing what was done to a system and how to undo
it will be different from tool to tool.

A lot of attention has been given to the Windows registry.  I will try to
focus attention on files.  We are still having trouble figuring out how to
assess the state of files (textfilecontent??), I can't wait for the problems
with tweaking them.

As far as patches being trivial as one vendor posited, I think that they are
not as trivial as one might think.  They have dependencies and more
importantly, they have different dependencies than the packages they replace
which can cause existing things to break.  I believe it is short sighted to
blindly patch systems (of course windows update might not have the
capabilities of other OSes) but the language should try to do no harm.

I have a general question about user interaction.  Given that this is part
of SCAP, how much user interaction will there be?  Will it be defined in the
language?

For example, if the Modification is to do a call to

        yum Uvh foo

And it asks
        Installing foo 1.2-3
        Installing bar 4.5-6
        OK [Yes]/No

Do we make these things non interactive?
Does ORML have a prepare/propose actions to present to the user or it up to
the vendor to do/not do this?

Being the list nag I must ask, how will this content get versioned?  I
figure we are starting on the ground floor so let's do it right from the
start (and maybe we can get the rest of SCAP to follow suit).  

I read slowly so I will be quiet for a while when I get the next proposal.
;)


Cheerio,

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: Undo, Automated != Ignore Users

Robert Hollis
Undo, sub-requirement: survivability.

If we roll Undo capability into the language, the ability to undo should
survive revisions of the driving content.  In cases where there's a direct
map from old content to new, and perhaps only IDs change, then the user
should be able to undo old actions with the new content.  In cases where an
old remediation action isn't even covered in the new content, a system
restore feature should allow changes to be reverted back.

We could look at this in two ways:

1) It will be the tool's responsibility to track historical changes and
support rollback.  In this case, Undo falls out of the scope of this
project.

2) We'll also develop a standardized historical log which a tool can use to
undo/restore changes.  This is kinda/sorta the same concept as system
characteristics, but for reasons stated above... it cannot be indexed by
IDs.

There may be some pushback on the concept of Undoing with content that was
not used to drive the original action.  If so, we can branch into that
discussion because there are some use-cases to consider where we just gotta
support this (or leave it to the tools to handle).

        -rob



. -----Original Message-----
. From: Wolfkiel, Joseph [mailto:[hidden email]]
. Sent: Tuesday, July 08, 2008 6:30 AM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. I suppose the "right" way to go about this is to capture these sorts of
. requirements into a design specification of some sort.
.
. So far, we want to be able to apply patches, provide for "undo"
. capabilities
. where supported, delete, modify, and add files.  I imagine we also want to
. be able to run executables, replace vulnerable or unwanted programs with
. newer versions, and some other, as yet to be defined, things.  Also
. provide
. the optional ability to interact with users.
.
. Probably wouldn't hurt to build a small lexicon of terms (e.g.
. "remediation": modifying a target software or hardware platform in
. response
. to a policy non-compliant state; "modification": the making of a limited
. change in something [regardless of motivation])
.
. I can volunteer labor to do this type of work, though it may be more a
. appropriate for MITRE to do it.
.
. Any thoughts?  Maybe someone already has their requirements documented and
. could contribute them as a starting point?
.
. 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: Ken Lassesen [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:24 PM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
. Ignore Users
.
.
. The ability to do an undo may be limited on Windows.   Some patches are
. not uninstallable....
.
. -----Original Message-----
. From: Vladimir Giszpenc [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:18 PM
. To: [hidden email]
. Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. Hello folks,
.
. What I don't remember seeing at developer days was much about how to undo
. the damage our wonderful language ORML will allow us to wreak on
. unsuspecting hosts.  I am hoping for transactions and I am hoping to know
. what to do when something goes wrong.  The language should build this in
. from the start otherwise, knowing what was done to a system and how to
. undo
. it will be different from tool to tool.
.
. A lot of attention has been given to the Windows registry.  I will try to
. focus attention on files.  We are still having trouble figuring out how to
. assess the state of files (textfilecontent??), I can't wait for the
. problems
. with tweaking them.
.
. As far as patches being trivial as one vendor posited, I think that they
. are
. not as trivial as one might think.  They have dependencies and more
. importantly, they have different dependencies than the packages they
. replace
. which can cause existing things to break.  I believe it is short sighted
. to
. blindly patch systems (of course windows update might not have the
. capabilities of other OSes) but the language should try to do no harm.
.
. I have a general question about user interaction.  Given that this is part
. of SCAP, how much user interaction will there be?  Will it be defined in
. the
. language?
.
. For example, if the Modification is to do a call to
.
. yum Uvh foo
.
. And it asks
. Installing foo 1.2-3
. Installing bar 4.5-6
. OK [Yes]/No
.
. Do we make these things non interactive?
. Does ORML have a prepare/propose actions to present to the user or it up
. to
. the vendor to do/not do this?
.
. Being the list nag I must ask, how will this content get versioned?  I
. figure we are starting on the ground floor so let's do it right from the
. start (and maybe we can get the rest of SCAP to follow suit).
.
. I read slowly so I will be quiet for a while when I get the next proposal.
. ;)
.
.
. Cheerio,
.
. 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: Undo, Automated != Ignore Users

Quilter, Alex
I am concerned that with the group on this thread that we could talk about requirements forever; we could even document all of them in a massive requirements document; we could also all probably come to an agreement on this massive document covering what is needed.  However, this does not give me a resolution to any of my specific problems that I am looking for a standard way to resolve.

I would like to see if we can just tackle smaller pieces of the problem at a time.  I would like to see if others are more interested in incremental progress than in inventing the perfect modification language.

Grafting to OVAL seemed to me a natural, incremental step to adding remediation support for vulnerabilities.  I never increased my own scope to generic modification and state change of system settings.  To me state change is the responsibility of a change management system and not of a vulnerability assessment and remediation system.

For those of us that have been in remediation for a long time, we know the nasty business of doing system changes; however, none of us are pushing pure change management products.  HP has change management products, but my team is specifically only interested in vulnerability assessment and remediation.

I have no incentive to assist in inventing a generic modification language; I do have incentive to assist in resolving the mapping of vulnerability assessment content to vulnerability remediation content.

If the scope grows to generic system change, then we move to use our existing change management systems until such time as this new language emerges.

If the scope can be kept small and kept in the scope of vulnerability management, then we are happy to continue our same resourcing on contributions.

If we can't agree on the scope of why we are working on remediation, then we might as well focus on assessment.

-ALX

-----Original Message-----
From: Robert Hollis [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 9:19 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore Users

Undo, sub-requirement: survivability.

If we roll Undo capability into the language, the ability to undo should
survive revisions of the driving content.  In cases where there's a direct
map from old content to new, and perhaps only IDs change, then the user
should be able to undo old actions with the new content.  In cases where an
old remediation action isn't even covered in the new content, a system
restore feature should allow changes to be reverted back.

We could look at this in two ways:

1) It will be the tool's responsibility to track historical changes and
support rollback.  In this case, Undo falls out of the scope of this
project.

2) We'll also develop a standardized historical log which a tool can use to
undo/restore changes.  This is kinda/sorta the same concept as system
characteristics, but for reasons stated above... it cannot be indexed by
IDs.

There may be some pushback on the concept of Undoing with content that was
not used to drive the original action.  If so, we can branch into that
discussion because there are some use-cases to consider where we just gotta
support this (or leave it to the tools to handle).

        -rob



. -----Original Message-----
. From: Wolfkiel, Joseph [mailto:[hidden email]]
. Sent: Tuesday, July 08, 2008 6:30 AM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. I suppose the "right" way to go about this is to capture these sorts of
. requirements into a design specification of some sort.
.
. So far, we want to be able to apply patches, provide for "undo"
. capabilities
. where supported, delete, modify, and add files.  I imagine we also want to
. be able to run executables, replace vulnerable or unwanted programs with
. newer versions, and some other, as yet to be defined, things.  Also
. provide
. the optional ability to interact with users.
.
. Probably wouldn't hurt to build a small lexicon of terms (e.g.
. "remediation": modifying a target software or hardware platform in
. response
. to a policy non-compliant state; "modification": the making of a limited
. change in something [regardless of motivation])
.
. I can volunteer labor to do this type of work, though it may be more a
. appropriate for MITRE to do it.
.
. Any thoughts?  Maybe someone already has their requirements documented and
. could contribute them as a starting point?
.
. 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: Ken Lassesen [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:24 PM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
. Ignore Users
.
.
. The ability to do an undo may be limited on Windows.   Some patches are
. not uninstallable....
.
. -----Original Message-----
. From: Vladimir Giszpenc [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:18 PM
. To: [hidden email]
. Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. Hello folks,
.
. What I don't remember seeing at developer days was much about how to undo
. the damage our wonderful language ORML will allow us to wreak on
. unsuspecting hosts.  I am hoping for transactions and I am hoping to know
. what to do when something goes wrong.  The language should build this in
. from the start otherwise, knowing what was done to a system and how to
. undo
. it will be different from tool to tool.
.
. A lot of attention has been given to the Windows registry.  I will try to
. focus attention on files.  We are still having trouble figuring out how to
. assess the state of files (textfilecontent??), I can't wait for the
. problems
. with tweaking them.
.
. As far as patches being trivial as one vendor posited, I think that they
. are
. not as trivial as one might think.  They have dependencies and more
. importantly, they have different dependencies than the packages they
. replace
. which can cause existing things to break.  I believe it is short sighted
. to
. blindly patch systems (of course windows update might not have the
. capabilities of other OSes) but the language should try to do no harm.
.
. I have a general question about user interaction.  Given that this is part
. of SCAP, how much user interaction will there be?  Will it be defined in
. the
. language?
.
. For example, if the Modification is to do a call to
.
.       yum Uvh foo
.
. And it asks
.       Installing foo 1.2-3
.       Installing bar 4.5-6
.       OK [Yes]/No
.
. Do we make these things non interactive?
. Does ORML have a prepare/propose actions to present to the user or it up
. to
. the vendor to do/not do this?
.
. Being the list nag I must ask, how will this content get versioned?  I
. figure we are starting on the ground floor so let's do it right from the
. start (and maybe we can get the rest of SCAP to follow suit).
.
. I read slowly so I will be quiet for a while when I get the next proposal.
. ;)
.
.
. Cheerio,
.
. 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
|

how do I get off the list? [OVAL-REMEDIATION-DISCUSSION-LIST]

Charlotte Rickert
Hi Alex,

How do I get off the list?  I have unsubscribed about a dozen times but it never seems to work?

Thanks,

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: Tuesday, July 08, 2008 7:51 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore Users

I am concerned that with the group on this thread that we could talk about requirements forever; we could even document all of them in a massive requirements document; we could also all probably come to an agreement on this massive document covering what is needed.  However, this does not give me a resolution to any of my specific problems that I am looking for a standard way to resolve.

I would like to see if we can just tackle smaller pieces of the problem at a time.  I would like to see if others are more interested in incremental progress than in inventing the perfect modification language.

Grafting to OVAL seemed to me a natural, incremental step to adding remediation support for vulnerabilities.  I never increased my own scope to generic modification and state change of system settings.  To me state change is the responsibility of a change management system and not of a vulnerability assessment and remediation system.

For those of us that have been in remediation for a long time, we know the nasty business of doing system changes; however, none of us are pushing pure change management products.  HP has change management products, but my team is specifically only interested in vulnerability assessment and remediation.

I have no incentive to assist in inventing a generic modification language; I do have incentive to assist in resolving the mapping of vulnerability assessment content to vulnerability remediation content.

If the scope grows to generic system change, then we move to use our existing change management systems until such time as this new language emerges.

If the scope can be kept small and kept in the scope of vulnerability management, then we are happy to continue our same resourcing on contributions.

If we can't agree on the scope of why we are working on remediation, then we might as well focus on assessment.

-ALX

-----Original Message-----
From: Robert Hollis [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 9:19 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore Users

Undo, sub-requirement: survivability.

If we roll Undo capability into the language, the ability to undo should
survive revisions of the driving content.  In cases where there's a direct
map from old content to new, and perhaps only IDs change, then the user
should be able to undo old actions with the new content.  In cases where an
old remediation action isn't even covered in the new content, a system
restore feature should allow changes to be reverted back.

We could look at this in two ways:

1) It will be the tool's responsibility to track historical changes and
support rollback.  In this case, Undo falls out of the scope of this
project.

2) We'll also develop a standardized historical log which a tool can use to
undo/restore changes.  This is kinda/sorta the same concept as system
characteristics, but for reasons stated above... it cannot be indexed by
IDs.

There may be some pushback on the concept of Undoing with content that was
not used to drive the original action.  If so, we can branch into that
discussion because there are some use-cases to consider where we just gotta
support this (or leave it to the tools to handle).

        -rob



. -----Original Message-----
. From: Wolfkiel, Joseph [mailto:[hidden email]]
. Sent: Tuesday, July 08, 2008 6:30 AM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. I suppose the "right" way to go about this is to capture these sorts of
. requirements into a design specification of some sort.
.
. So far, we want to be able to apply patches, provide for "undo"
. capabilities
. where supported, delete, modify, and add files.  I imagine we also want to
. be able to run executables, replace vulnerable or unwanted programs with
. newer versions, and some other, as yet to be defined, things.  Also
. provide
. the optional ability to interact with users.
.
. Probably wouldn't hurt to build a small lexicon of terms (e.g.
. "remediation": modifying a target software or hardware platform in
. response
. to a policy non-compliant state; "modification": the making of a limited
. change in something [regardless of motivation])
.
. I can volunteer labor to do this type of work, though it may be more a
. appropriate for MITRE to do it.
.
. Any thoughts?  Maybe someone already has their requirements documented and
. could contribute them as a starting point?
.
. 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: Ken Lassesen [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:24 PM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
. Ignore Users
.
.
. The ability to do an undo may be limited on Windows.   Some patches are
. not uninstallable....
.
. -----Original Message-----
. From: Vladimir Giszpenc [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:18 PM
. To: [hidden email]
. Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. Hello folks,
.
. What I don't remember seeing at developer days was much about how to undo
. the damage our wonderful language ORML will allow us to wreak on
. unsuspecting hosts.  I am hoping for transactions and I am hoping to know
. what to do when something goes wrong.  The language should build this in
. from the start otherwise, knowing what was done to a system and how to
. undo
. it will be different from tool to tool.
.
. A lot of attention has been given to the Windows registry.  I will try to
. focus attention on files.  We are still having trouble figuring out how to
. assess the state of files (textfilecontent??), I can't wait for the
. problems
. with tweaking them.
.
. As far as patches being trivial as one vendor posited, I think that they
. are
. not as trivial as one might think.  They have dependencies and more
. importantly, they have different dependencies than the packages they
. replace
. which can cause existing things to break.  I believe it is short sighted
. to
. blindly patch systems (of course windows update might not have the
. capabilities of other OSes) but the language should try to do no harm.
.
. I have a general question about user interaction.  Given that this is part
. of SCAP, how much user interaction will there be?  Will it be defined in
. the
. language?
.
. For example, if the Modification is to do a call to
.
.       yum Uvh foo
.
. And it asks
.       Installing foo 1.2-3
.       Installing bar 4.5-6
.       OK [Yes]/No
.
. Do we make these things non interactive?
. Does ORML have a prepare/propose actions to present to the user or it up
. to
. the vendor to do/not do this?
.
. Being the list nag I must ask, how will this content get versioned?  I
. figure we are starting on the ground floor so let's do it right from the
. start (and maybe we can get the rest of SCAP to follow suit).
.
. I read slowly so I will be quiet for a while when I get the next proposal.
. ;)
.
.
. Cheerio,
.
. 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: Undo, Automated != Ignore Users

Ken Lassesen-3
In reply to this post by Quilter, Alex
Knowing Joe, we will not talk forever. As an architect, I have seen too
many systems end up with a very short life because of a lack of
requirement or worst yet, systems piecemeal together with kludges
between every component. Incremental development and other 'Web 2.0'
techniques work excellently when the probable life of a product is just
2-3 years. In this case, the life of the product will be much longer and
there is the need for backward support. The choice of quick out of the
door development/architectural patterns is not a good one IMHO

Ken

-----Original Message-----
From: Quilter, Alex [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 6:51 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users

I am concerned that with the group on this thread that we could talk
about requirements forever; we could even document all of them in a
massive requirements document; we could also all probably come to an
agreement on this massive document covering what is needed.  However,
this does not give me a resolution to any of my specific problems that I
am looking for a standard way to resolve.

I would like to see if we can just tackle smaller pieces of the problem
at a time.  I would like to see if others are more interested in
incremental progress than in inventing the perfect modification
language.

Grafting to OVAL seemed to me a natural, incremental step to adding
remediation support for vulnerabilities.  I never increased my own scope
to generic modification and state change of system settings.  To me
state change is the responsibility of a change management system and not
of a vulnerability assessment and remediation system.

For those of us that have been in remediation for a long time, we know
the nasty business of doing system changes; however, none of us are
pushing pure change management products.  HP has change management
products, but my team is specifically only interested in vulnerability
assessment and remediation.

I have no incentive to assist in inventing a generic modification
language; I do have incentive to assist in resolving the mapping of
vulnerability assessment content to vulnerability remediation content.

If the scope grows to generic system change, then we move to use our
existing change management systems until such time as this new language
emerges.

If the scope can be kept small and kept in the scope of vulnerability
management, then we are happy to continue our same resourcing on
contributions.

If we can't agree on the scope of why we are working on remediation,
then we might as well focus on assessment.

-ALX

-----Original Message-----
From: Robert Hollis [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 9:19 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users

Undo, sub-requirement: survivability.

If we roll Undo capability into the language, the ability to undo should
survive revisions of the driving content.  In cases where there's a
direct
map from old content to new, and perhaps only IDs change, then the user
should be able to undo old actions with the new content.  In cases where
an
old remediation action isn't even covered in the new content, a system
restore feature should allow changes to be reverted back.

We could look at this in two ways:

1) It will be the tool's responsibility to track historical changes and
support rollback.  In this case, Undo falls out of the scope of this
project.

2) We'll also develop a standardized historical log which a tool can use
to
undo/restore changes.  This is kinda/sorta the same concept as system
characteristics, but for reasons stated above... it cannot be indexed by
IDs.

There may be some pushback on the concept of Undoing with content that
was
not used to drive the original action.  If so, we can branch into that
discussion because there are some use-cases to consider where we just
gotta
support this (or leave it to the tools to handle).

        -rob



. -----Original Message-----
. From: Wolfkiel, Joseph [mailto:[hidden email]]
. Sent: Tuesday, July 08, 2008 6:30 AM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore
. Users
.
. I suppose the "right" way to go about this is to capture these sorts
of
. requirements into a design specification of some sort.
.
. So far, we want to be able to apply patches, provide for "undo"
. capabilities
. where supported, delete, modify, and add files.  I imagine we also
want to
. be able to run executables, replace vulnerable or unwanted programs
with
. newer versions, and some other, as yet to be defined, things.  Also
. provide
. the optional ability to interact with users.
.
. Probably wouldn't hurt to build a small lexicon of terms (e.g.
. "remediation": modifying a target software or hardware platform in
. response
. to a policy non-compliant state; "modification": the making of a
limited
. change in something [regardless of motivation])
.
. I can volunteer labor to do this type of work, though it may be more a
. appropriate for MITRE to do it.
.
. Any thoughts?  Maybe someone already has their requirements documented
and
. could contribute them as a starting point?
.
. 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: Ken Lassesen [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:24 PM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
. Ignore Users
.
.
. The ability to do an undo may be limited on Windows.   Some patches
are
. not uninstallable....
.
. -----Original Message-----
. From: Vladimir Giszpenc [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:18 PM
. To: [hidden email]
. Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. Hello folks,
.
. What I don't remember seeing at developer days was much about how to
undo
. the damage our wonderful language ORML will allow us to wreak on
. unsuspecting hosts.  I am hoping for transactions and I am hoping to
know
. what to do when something goes wrong.  The language should build this
in
. from the start otherwise, knowing what was done to a system and how to
. undo
. it will be different from tool to tool.
.
. A lot of attention has been given to the Windows registry.  I will try
to
. focus attention on files.  We are still having trouble figuring out
how to
. assess the state of files (textfilecontent??), I can't wait for the
. problems
. with tweaking them.
.
. As far as patches being trivial as one vendor posited, I think that
they
. are
. not as trivial as one might think.  They have dependencies and more
. importantly, they have different dependencies than the packages they
. replace
. which can cause existing things to break.  I believe it is short
sighted
. to
. blindly patch systems (of course windows update might not have the
. capabilities of other OSes) but the language should try to do no harm.
.
. I have a general question about user interaction.  Given that this is
part
. of SCAP, how much user interaction will there be?  Will it be defined
in
. the
. language?
.
. For example, if the Modification is to do a call to
.
.       yum Uvh foo
.
. And it asks
.       Installing foo 1.2-3
.       Installing bar 4.5-6
.       OK [Yes]/No
.
. Do we make these things non interactive?
. Does ORML have a prepare/propose actions to present to the user or it
up
. to
. the vendor to do/not do this?
.
. Being the list nag I must ask, how will this content get versioned?  I
. figure we are starting on the ground floor so let's do it right from
the
. start (and maybe we can get the rest of SCAP to follow suit).
.
. I read slowly so I will be quiet for a while when I get the next
proposal.
. ;)
.
.
. Cheerio,
.
. 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: Undo, Automated != Ignore Users

Vladimir Giszpenc
In reply to this post by Quilter, Alex
I would say that any state that can be tested for in OVAL is a good place to
start.  It seems to me that we could also have common/core things that are
applicable to ORML.  As far as doing this incrementally, I could not agree
more.  Though spending a little time on a design can't hurt either.

in independent namespace
Environment_state (un)setting an environment variable
textfilecontent54_state modify a file's contents
xmlfilecontent_state modify an xml file CRUD attributes CRUD nodes

in unix namespace
file_state setting file permissions, name, location
runlevel_state (un)schedule service to run at a runlevel

I think it makes sense to start to create ORML for SCAP (XCCDF) content that
is already out there and then build from that.  However, adding some undo
mechanics to a common/core for the above and other namespaces does not seem
out of scope to me.


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

> I am concerned that with the group on this thread that we could talk about
> requirements forever; we could even document all of them in a massive
> requirements document; we could also all probably come to an agreement on
> this massive document covering what is needed.  However, this does not
> give me a resolution to any of my specific problems that I am looking for
> a standard way to resolve.
>
> I would like to see if we can just tackle smaller pieces of the problem at
> a time.  I would like to see if others are more interested in incremental
> progress than in inventing the perfect modification language.
>
> Grafting to OVAL seemed to me a natural, incremental step to adding
> remediation support for vulnerabilities.  I never increased my own scope
> to generic modification and state change of system settings.  To me state
> change is the responsibility of a change management system and not of a
> vulnerability assessment and remediation system.
>
> For those of us that have been in remediation for a long time, we know the
> nasty business of doing system changes; however, none of us are pushing
> pure change management products.  HP has change management products, but
> my team is specifically only interested in vulnerability assessment and
> remediation.
>
> I have no incentive to assist in inventing a generic modification
> language; I do have incentive to assist in resolving the mapping of
> vulnerability assessment content to vulnerability remediation content.
>
> If the scope grows to generic system change, then we move to use our
> existing change management systems until such time as this new language
> emerges.
>
> If the scope can be kept small and kept in the scope of vulnerability
> management, then we are happy to continue our same resourcing on
> contributions.
>
> If we can't agree on the scope of why we are working on remediation, then
> we might as well focus on assessment.
>
> -ALX
>

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

Re: Undo, Automated != Ignore Users

Wolfkiel, Joseph
In reply to this post by Vladimir Giszpenc
So I put some thought into this overnight and have some other ideas on how I
suggest we proceed:

1.  When I say "requirements document", I mean that we will write all the
requirements we're discussing on the list down in a single document.  Issues
like undo features, verification, source tracking, unique identifiers,
ability to use executables, etc are all requirements we'll have to look at,
so I'm thinking a requirements document will serve mainly as a checklist to
determine which requirements we've addressed and which we haven't.  Possibly
also a place to document which requirements we didn't address, why, and what
we plan to do about them in the future.

2.  It seems we have three "themes" to work through to get to our end state.
First, what will we call the Remediation/Modification (R/M) language and
where, logically and physically, will it fit in relation to the other SCAP
languages.  Second, what medata do we want to define that describes R/Ms
(e.g. does it support undo, which CVE/CCE/CME/other finding does it
remediate, who published it, what does it do, etc).  Third, what metadata
do/should we define that tells a R/M tool how to conduct a R/M action.

As to the first theme, it appears we may have hit an impasse that will
prevent us from arriving at a consensus answer.  I think we agreed that the
R/M language shouldn't be subordinate to OVAL Definitions, but should be
referenced by it and that a definition should be capable of carrying the
associated R/M.  However, we didn't reach agreement on whether the R/M
language should be a co-equal with OVAL or at the same level, within OVAL,
of OVAL Defs, SC, and Results.

On the second theme, I think we can make progress on this one.  Without
telling a tool HOW to carry out a R/M, we can tell the tool and the user
enough information about a R/M so they can find it, assess its integrity,
evaluate it (in terms of whether it's better to perform it, or just accept
the risk of not doing it), check for pre-requesites, determine if it was
successfully executed, and address any other issues that lead up to, and
follow on to application of a R/M action.

On the third theme, I suggest we can treat R/Ms as "black boxes" for now.
If we do this, we can avoid trying to figure out how a remediation tool or
executable would go about effecting a state change and just agree that it
happens by invoking the R/M black box.  In the future, or even in a
concurrent discussion, we could delve into the different types of actions a
tool would take, what objects need to be described, and what sequencing and
content issues need to be looked at to actually encode R/M activities in a
machine-readable way.  However, we can probably fully deploy a remediation
language as part of SCAP without ever solving this problem by treating R/Ms
as either 1 - scripts that can be executed or 2 - a R/M ID and call that can
be handed off to an external R/M tool.

Feedback?

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: Ken Lassesen [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 10:23 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users


Knowing Joe, we will not talk forever. As an architect, I have seen too
many systems end up with a very short life because of a lack of
requirement or worst yet, systems piecemeal together with kludges
between every component. Incremental development and other 'Web 2.0'
techniques work excellently when the probable life of a product is just
2-3 years. In this case, the life of the product will be much longer and
there is the need for backward support. The choice of quick out of the
door development/architectural patterns is not a good one IMHO

Ken

-----Original Message-----
From: Quilter, Alex [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 6:51 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users

I am concerned that with the group on this thread that we could talk
about requirements forever; we could even document all of them in a
massive requirements document; we could also all probably come to an
agreement on this massive document covering what is needed.  However,
this does not give me a resolution to any of my specific problems that I
am looking for a standard way to resolve.

I would like to see if we can just tackle smaller pieces of the problem
at a time.  I would like to see if others are more interested in
incremental progress than in inventing the perfect modification
language.

Grafting to OVAL seemed to me a natural, incremental step to adding
remediation support for vulnerabilities.  I never increased my own scope
to generic modification and state change of system settings.  To me
state change is the responsibility of a change management system and not
of a vulnerability assessment and remediation system.

For those of us that have been in remediation for a long time, we know
the nasty business of doing system changes; however, none of us are
pushing pure change management products.  HP has change management
products, but my team is specifically only interested in vulnerability
assessment and remediation.

I have no incentive to assist in inventing a generic modification
language; I do have incentive to assist in resolving the mapping of
vulnerability assessment content to vulnerability remediation content.

If the scope grows to generic system change, then we move to use our
existing change management systems until such time as this new language
emerges.

If the scope can be kept small and kept in the scope of vulnerability
management, then we are happy to continue our same resourcing on
contributions.

If we can't agree on the scope of why we are working on remediation,
then we might as well focus on assessment.

-ALX

-----Original Message-----
From: Robert Hollis [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 9:19 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users

Undo, sub-requirement: survivability.

If we roll Undo capability into the language, the ability to undo should
survive revisions of the driving content.  In cases where there's a
direct
map from old content to new, and perhaps only IDs change, then the user
should be able to undo old actions with the new content.  In cases where
an
old remediation action isn't even covered in the new content, a system
restore feature should allow changes to be reverted back.

We could look at this in two ways:

1) It will be the tool's responsibility to track historical changes and
support rollback.  In this case, Undo falls out of the scope of this
project.

2) We'll also develop a standardized historical log which a tool can use
to
undo/restore changes.  This is kinda/sorta the same concept as system
characteristics, but for reasons stated above... it cannot be indexed by
IDs.

There may be some pushback on the concept of Undoing with content that
was
not used to drive the original action.  If so, we can branch into that
discussion because there are some use-cases to consider where we just
gotta
support this (or leave it to the tools to handle).

        -rob



. -----Original Message-----
. From: Wolfkiel, Joseph [mailto:[hidden email]]
. Sent: Tuesday, July 08, 2008 6:30 AM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore
. Users
.
. I suppose the "right" way to go about this is to capture these sorts
of
. requirements into a design specification of some sort.
.
. So far, we want to be able to apply patches, provide for "undo"
. capabilities
. where supported, delete, modify, and add files.  I imagine we also
want to
. be able to run executables, replace vulnerable or unwanted programs
with
. newer versions, and some other, as yet to be defined, things.  Also
. provide
. the optional ability to interact with users.
.
. Probably wouldn't hurt to build a small lexicon of terms (e.g.
. "remediation": modifying a target software or hardware platform in
. response
. to a policy non-compliant state; "modification": the making of a
limited
. change in something [regardless of motivation])
.
. I can volunteer labor to do this type of work, though it may be more a
. appropriate for MITRE to do it.
.
. Any thoughts?  Maybe someone already has their requirements documented
and
. could contribute them as a starting point?
.
. 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: Ken Lassesen [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:24 PM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
. Ignore Users
.
.
. The ability to do an undo may be limited on Windows.   Some patches
are
. not uninstallable....
.
. -----Original Message-----
. From: Vladimir Giszpenc [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:18 PM
. To: [hidden email]
. Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. Hello folks,
.
. What I don't remember seeing at developer days was much about how to
undo
. the damage our wonderful language ORML will allow us to wreak on
. unsuspecting hosts.  I am hoping for transactions and I am hoping to
know
. what to do when something goes wrong.  The language should build this
in
. from the start otherwise, knowing what was done to a system and how to
. undo
. it will be different from tool to tool.
.
. A lot of attention has been given to the Windows registry.  I will try
to
. focus attention on files.  We are still having trouble figuring out
how to
. assess the state of files (textfilecontent??), I can't wait for the
. problems
. with tweaking them.
.
. As far as patches being trivial as one vendor posited, I think that
they
. are
. not as trivial as one might think.  They have dependencies and more
. importantly, they have different dependencies than the packages they
. replace
. which can cause existing things to break.  I believe it is short
sighted
. to
. blindly patch systems (of course windows update might not have the
. capabilities of other OSes) but the language should try to do no harm.
.
. I have a general question about user interaction.  Given that this is
part
. of SCAP, how much user interaction will there be?  Will it be defined
in
. the
. language?
.
. For example, if the Modification is to do a call to
.
.       yum Uvh foo
.
. And it asks
.       Installing foo 1.2-3
.       Installing bar 4.5-6
.       OK [Yes]/No
.
. Do we make these things non interactive?
. Does ORML have a prepare/propose actions to present to the user or it
up
. to
. the vendor to do/not do this?
.
. Being the list nag I must ask, how will this content get versioned?  I
. figure we are starting on the ground floor so let's do it right from
the
. start (and maybe we can get the rest of SCAP to follow suit).
.
. I read slowly so I will be quiet for a while when I get the next
proposal.
. ;)
.
.
. Cheerio,
.
. 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: Undo, Automated != Ignore Users

Ken Lassesen-3
I like it, to put a simple sample on the table.
 
In OVAL we have
            <passwordpolicy_test xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.fdcc.xp:tst:18" version="1" comment="Passwords must be stored using reversible encryption for all users in the domain" check_existence="at_least_one_exists" check="all">
                  <object object_ref="oval:gov.nist.fdcc.xp:obj:8"/>
                  <state state_ref="oval:gov.nist.fdcc.xp:ste:23"/>
            </passwordpolicy_test>
 
==> becomes something like
 
            <passwordpolicy_change xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" id="oval:gov.nist.fdcc.xp:tst:18" version="1" comment="Passwords must be stored using reversible encryption for all users in the domain" check_existence="at_least_one_exists" check="all">
                  <object object_ref="oval:gov.nist.fdcc.xp:obj:8"/>
                  <state state_ref="oval:gov.nist.fdcc.xp:ste:123423"/>
                  <resource state_ref="oval:com.lumension.configure:res:123" />
                  <resource_parameter param_ref="oval:com.lumension.configure:par:123" />
            </passwordpolicy_change>
 
 
So we have clean parallelism, the resource could be an existing system Dll or exe or WMI object, or an item to install. resource_parameter would be a method and it's parameters (for a DLL) or command-line argument.
In the case of a specialized vendor component (blackbox),  we may have a <resource_package> that points to a MSI or other installation package.
 
From the above, a WMI base correction would be easy to generate a script from, similarly a call to a specific API (using reflection etc) should be little effort, and, of course, a command line change is trivial. If the fix is installing a patch file, then the resource_package contains, or points to, this patch.
 
 
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: Wed 09-Jul-08 5:33 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore Users



So I put some thought into this overnight and have some other ideas on how I
suggest we proceed:

1.  When I say "requirements document", I mean that we will write all the
requirements we're discussing on the list down in a single document.  Issues
like undo features, verification, source tracking, unique identifiers,
ability to use executables, etc are all requirements we'll have to look at,
so I'm thinking a requirements document will serve mainly as a checklist to
determine which requirements we've addressed and which we haven't.  Possibly
also a place to document which requirements we didn't address, why, and what
we plan to do about them in the future.

2.  It seems we have three "themes" to work through to get to our end state.
First, what will we call the Remediation/Modification (R/M) language and
where, logically and physically, will it fit in relation to the other SCAP
languages.  Second, what medata do we want to define that describes R/Ms
(e.g. does it support undo, which CVE/CCE/CME/other finding does it
remediate, who published it, what does it do, etc).  Third, what metadata
do/should we define that tells a R/M tool how to conduct a R/M action.

As to the first theme, it appears we may have hit an impasse that will
prevent us from arriving at a consensus answer.  I think we agreed that the
R/M language shouldn't be subordinate to OVAL Definitions, but should be
referenced by it and that a definition should be capable of carrying the
associated R/M.  However, we didn't reach agreement on whether the R/M
language should be a co-equal with OVAL or at the same level, within OVAL,
of OVAL Defs, SC, and Results.

On the second theme, I think we can make progress on this one.  Without
telling a tool HOW to carry out a R/M, we can tell the tool and the user
enough information about a R/M so they can find it, assess its integrity,
evaluate it (in terms of whether it's better to perform it, or just accept
the risk of not doing it), check for pre-requesites, determine if it was
successfully executed, and address any other issues that lead up to, and
follow on to application of a R/M action.

On the third theme, I suggest we can treat R/Ms as "black boxes" for now.
If we do this, we can avoid trying to figure out how a remediation tool or
executable would go about effecting a state change and just agree that it
happens by invoking the R/M black box.  In the future, or even in a
concurrent discussion, we could delve into the different types of actions a
tool would take, what objects need to be described, and what sequencing and
content issues need to be looked at to actually encode R/M activities in a
machine-readable way.  However, we can probably fully deploy a remediation
language as part of SCAP without ever solving this problem by treating R/Ms
as either 1 - scripts that can be executed or 2 - a R/M ID and call that can
be handed off to an external R/M tool.

Feedback?

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: Ken Lassesen [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 10:23 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users


Knowing Joe, we will not talk forever. As an architect, I have seen too
many systems end up with a very short life because of a lack of
requirement or worst yet, systems piecemeal together with kludges
between every component. Incremental development and other 'Web 2.0'
techniques work excellently when the probable life of a product is just
2-3 years. In this case, the life of the product will be much longer and
there is the need for backward support. The choice of quick out of the
door development/architectural patterns is not a good one IMHO

Ken

-----Original Message-----
From: Quilter, Alex [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 6:51 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users

I am concerned that with the group on this thread that we could talk
about requirements forever; we could even document all of them in a
massive requirements document; we could also all probably come to an
agreement on this massive document covering what is needed.  However,
this does not give me a resolution to any of my specific problems that I
am looking for a standard way to resolve.

I would like to see if we can just tackle smaller pieces of the problem
at a time.  I would like to see if others are more interested in
incremental progress than in inventing the perfect modification
language.

Grafting to OVAL seemed to me a natural, incremental step to adding
remediation support for vulnerabilities.  I never increased my own scope
to generic modification and state change of system settings.  To me
state change is the responsibility of a change management system and not
of a vulnerability assessment and remediation system.

For those of us that have been in remediation for a long time, we know
the nasty business of doing system changes; however, none of us are
pushing pure change management products.  HP has change management
products, but my team is specifically only interested in vulnerability
assessment and remediation.

I have no incentive to assist in inventing a generic modification
language; I do have incentive to assist in resolving the mapping of
vulnerability assessment content to vulnerability remediation content.

If the scope grows to generic system change, then we move to use our
existing change management systems until such time as this new language
emerges.

If the scope can be kept small and kept in the scope of vulnerability
management, then we are happy to continue our same resourcing on
contributions.

If we can't agree on the scope of why we are working on remediation,
then we might as well focus on assessment.

-ALX

-----Original Message-----
From: Robert Hollis [mailto:[hidden email]]
Sent: Tuesday, July 08, 2008 9:19 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore Users

Undo, sub-requirement: survivability.

If we roll Undo capability into the language, the ability to undo should
survive revisions of the driving content.  In cases where there's a
direct
map from old content to new, and perhaps only IDs change, then the user
should be able to undo old actions with the new content.  In cases where
an
old remediation action isn't even covered in the new content, a system
restore feature should allow changes to be reverted back.

We could look at this in two ways:

1) It will be the tool's responsibility to track historical changes and
support rollback.  In this case, Undo falls out of the scope of this
project.

2) We'll also develop a standardized historical log which a tool can use
to
undo/restore changes.  This is kinda/sorta the same concept as system
characteristics, but for reasons stated above... it cannot be indexed by
IDs.

There may be some pushback on the concept of Undoing with content that
was
not used to drive the original action.  If so, we can branch into that
discussion because there are some use-cases to consider where we just
gotta
support this (or leave it to the tools to handle).

        -rob



. -----Original Message-----
. From: Wolfkiel, Joseph [mailto:[hidden email]]
. Sent: Tuesday, July 08, 2008 6:30 AM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
Ignore
. Users
.
. I suppose the "right" way to go about this is to capture these sorts
of
. requirements into a design specification of some sort.
.
. So far, we want to be able to apply patches, provide for "undo"
. capabilities
. where supported, delete, modify, and add files.  I imagine we also
want to
. be able to run executables, replace vulnerable or unwanted programs
with
. newer versions, and some other, as yet to be defined, things.  Also
. provide
. the optional ability to interact with users.
.
. Probably wouldn't hurt to build a small lexicon of terms (e.g.
. "remediation": modifying a target software or hardware platform in
. response
. to a policy non-compliant state; "modification": the making of a
limited
. change in something [regardless of motivation])
.
. I can volunteer labor to do this type of work, though it may be more a
. appropriate for MITRE to do it.
.
. Any thoughts?  Maybe someone already has their requirements documented
and
. could contribute them as a starting point?
.
. 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: Ken Lassesen [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:24 PM
. To: [hidden email]
. Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated !=
. Ignore Users
.
.
. The ability to do an undo may be limited on Windows.   Some patches
are
. not uninstallable....
.
. -----Original Message-----
. From: Vladimir Giszpenc [mailto:[hidden email]]
. Sent: Monday, July 07, 2008 4:18 PM
. To: [hidden email]
. Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] Undo, Automated != Ignore
. Users
.
. Hello folks,
.
. What I don't remember seeing at developer days was much about how to
undo
. the damage our wonderful language ORML will allow us to wreak on
. unsuspecting hosts.  I am hoping for transactions and I am hoping to
know
. what to do when something goes wrong.  The language should build this
in
. from the start otherwise, knowing what was done to a system and how to
. undo
. it will be different from tool to tool.
.
. A lot of attention has been given to the Windows registry.  I will try
to
. focus attention on files.  We are still having trouble figuring out
how to
. assess the state of files (textfilecontent??), I can't wait for the
. problems
. with tweaking them.
.
. As far as patches being trivial as one vendor posited, I think that
they
. are
. not as trivial as one might think.  They have dependencies and more
. importantly, they have different dependencies than the packages they
. replace
. which can cause existing things to break.  I believe it is short
sighted
. to
. blindly patch systems (of course windows update might not have the
. capabilities of other OSes) but the language should try to do no harm.
.
. I have a general question about user interaction.  Given that this is
part
. of SCAP, how much user interaction will there be?  Will it be defined
in
. the
. language?
.
. For example, if the Modification is to do a call to
.
.       yum Uvh foo
.
. And it asks
.       Installing foo 1.2-3
.       Installing bar 4.5-6
.       OK [Yes]/No
.
. Do we make these things non interactive?
. Does ORML have a prepare/propose actions to present to the user or it
up
. to
. the vendor to do/not do this?
.
. Being the list nag I must ask, how will this content get versioned?  I
. figure we are starting on the ground floor so let's do it right from
the
. start (and maybe we can get the rest of SCAP to follow suit).
.
. I read slowly so I will be quiet for a while when I get the next
proposal.
. ;)
.
.
. Cheerio,
.
. 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
|

Feature request

Ken Lassesen-3
*
        remediation dependencies should be a part of the language. The ability to point to required prior remediation before a remediation can be implemented.
*
        flags governing reboot (reboot required before other remediation may be applied) --- this means we need to define a 'remediation status data store' on the PC.

 
 
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>