High Level ORML Requirements Ideas

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

High Level ORML Requirements Ideas

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

Hi,

 

Theres been some talk on the mailing list about putting together some ORML requirements as a stepping stone to building out a language.  Weve tried to incorporate the comments from this list along with analysis of the various remediation tools on the market into the draft list of requirements below.

 

How should these requirements be prioritized  what are the core things you need to be able to express in order to automate remediation/modification?  Also, is there any data you would need in order to remediate vulnerabilities that isnt in this list?

 

    User Actionable Information

1.1.    Unique Identification - The standard shall provide for the simple identification of a unique modification

1.2.    Description - The standard shall provide for a human readable description of the modification

1.3.    Dependencies - The standard shall provide for a human readable description of all dependencies for application of the modification

1.4.    Behavioral Parameters - The standard shall provide for a human readable enumeration of all behavioral parameters, such as reboot requirement or device locks, associated with a modification

1.5.    Applicability - The standard shall provide for an enumeration of the CPEs the modification applies to

1.6.    Basis - The standard shall provide for the enumeration SCAP compatible identifiers (CVE, CCE, OVAL ID, etc) which represent findings that would server as the basis for applying a given modification

1.7.    Error/Status Messages - The standard shall provide for the description of error and status messages which may be returned as a result of the attempted application of a modification

1.8.    Switches/Controls - The standard shall provide for the listing and description of all interactive parameters which may be provided to the modification, including such metadata as data types, filters and default values.

1.9.    User Interactions - The standard shall provide for the description of required/allowed user interactivity to occur during the application of the modification.

1.10.Integrity Controls - The standard shall provide for some mechanism, such as a digital signature, to provide assurance as to the integrity of the modification.

1.11.Executables and Scripts - The standard shall provide for the encapsulation of encoded binary payloads using such mechanisms as base64 encoding.

1.12.Supersedence - The standard shall provide for a user readable enumeration of all ORML content superseded by a given modification.

1.13.Deprecation - The standard shall provide for the specification of a Boolean value designating whether a given modification has been deprecated.

1.14.Undo - The standard shall provide for the specification of the metadata required to undo a modification.  This includes a flag specifying if the undo capability is supported and the reference to a modification capable of performing the undo if appropriate.

1.15.Alternatives - The standard shall provide for the specification of many modifications associated with a given applicability/basis combination.

1.16.Side Effects - The standard shall provide for the human readable specification of any secondary effects resulting from the application of a given modification.

2.       System Actionable Information

2.1.    Binary Payload and Execution - The standard shall provide for the encapsulation and execution of arbitrary binary content.

2.2.    Parameterization - The standard shall provide for the specification and usage of runtime evaluation of parameters.

2.3.    External Data - The standard shall provide for the reference to external content, such as scripts and executables.

2.4.    Compatibility with OVAL System Characteristics - The standard shall provide for the specification of OVAL System Characteristics as a desired state.  For example, the ability to create, delete, modify, and overwrite files using OVAL System Characteristics style data.

2.5.    Administrator Provided Switches and Controls - The standard shall provide for the ability to accept switches/controls passed from a system administrator prior to deployment and execution.

2.6.    Status Updates and Error Messages - The standard shall provide for the ability to sent status updates/error messages based on the success of a modification.

2.7.    Multiple Action Modifications - The standard shall provide for the specification of multiple discrete actions and the sequence in which those actions shall run within the scope of a single modification.

2.8.    Action Chains - The standard shall provide for the specification of the capability for an action which may otherwise require a reboot upon completion to be chained together with other actions.

2.9.    Pre-requisites - The standard shall provide for the system actionable specification of SCAP compatible identifiers are pre-requisites for the application of a modification or execution of an action.

3.       OVAL Addendums

3.1.    Relating Findings to Modifications - OVAL shall provide for the specification of modifications related to OVAL definitions and criterion.

3.2.    Modification Metadata - OVAL shall provide for the specification of metadata about modifications capable of remediating a finding.

3.3.    Modification Encapsulation - OVAL shall provide for the encapsulation of a modification.

3.4.    Modification Success - OVAL shall provide for the assessment of the success of the attempted application of a modification.

 


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

wsBVAwUBSIDO6Z3xz8BLNKAgAQi7eQf/TugHX7Et9AckEGKKOSZpeqxepTFMc9fC
koxqTMKGhgYV5oQSQBmY8CLWfMzkbuLnd+Vbo/DpmvzXhvIWtGcfpjo+GoIV491F
mOJriD4efZsHWpzdC96mX+DDUKsZw6er7Ql7c32xOPE7fFVDthvQumZlq9V7P3AF
LRC8JHnbaWRMFUC7e4wW++/a0djFbXKY8WMvE0A/WvLWujF1lqczy7//03kKP+ZP
AdNi11OJRtkcuXzBEQ8AmmHmdyvHSbJ1W8Tk4VPPNWPJX5xb2b1mbi/VYYun1LeW
FKZ0GJgtIBuBezkjv8J3S+0pI4H96xhidYGsN4ymFjvSA6tnKA/NkQ==
=KahQ
-----END PGP SIGNATURE-----


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

Re: High Level ORML Requirements Ideas

Vladimir Giszpenc
Hi,

It has been a long time.  Apparently we tried to bite off more than we could
chew.  We are all scared of remediation because to do it right is so
complicated.

Let's simplify!  K.I.S.S.!

Can we roll out version 1.0 that is for registry keys only.  I don't care
about Windows as some of you might know, but it seems that we should start
somewhere.  How hard can it really be to say that the state should be "such
and such a key should have such and such a value of type blah."  This would
cover a LARGE percent of the FDCC content.  Then we go after the next low
hanging fruit.

If it requires reboot or anything complicated, then let it wait for a future
version.  It seems irresponsible for us to have no standard year after year.
If a vendor wants to implement undo, or anything else not defined, then let
only that stuff be proprietary.

I just want to consume content, but content won't exist if no standard
exists...  If it is possible to come up with something that does more than
registry keys (or there is lower hanging fruit, then let's do that.  Is an
evolutionary approach possible?  Or is our waterfall behind a dam and there
is nothing that can be done?

Best regards,


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

> -----Original Message-----
> From: Kevin Sitto
> Sent: Friday, July 18, 2008 1:12 PM
> To: [hidden email]
> Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML
> Requirements Ideas
>
> Hi,
>
>
>
> Theres been some talk on the mailing list about putting together some
> ORML requirements as a stepping stone to building out a language.  Weve
> tried to incorporate the comments from this list along with analysis of
> the various remediation tools on the market into the draft list of
> requirements below.
>
>
>
> How should these requirements be prioritized  what are the core things
> you need to be able to express in order to automate
> remediation/modification?  Also, is there any data you would need in
> order to remediate vulnerabilities that isnt in this list?
>
>
>
>     User Actionable Information
>
> 1.1.    Unique Identification - The standard shall provide for the
> simple identification of a unique modification
>
> 1.2.    Description - The standard shall provide for a human readable
> description of the modification
>
> 1.3.    Dependencies - The standard shall provide for a human readable
> description of all dependencies for application of the modification
>
> 1.4.    Behavioral Parameters - The standard shall provide for a human
> readable enumeration of all behavioral parameters, such as reboot
> requirement or device locks, associated with a modification
>
> 1.5.    Applicability - The standard shall provide for an enumeration
> of the CPEs the modification applies to
>
> 1.6.    Basis - The standard shall provide for the enumeration SCAP
> compatible identifiers (CVE, CCE, OVAL ID, etc) which represent
> findings that would server as the basis for applying a given
> modification
>
> 1.7.    Error/Status Messages - The standard shall provide for the
> description of error and status messages which may be returned as a
> result of the attempted application of a modification
>
> 1.8.    Switches/Controls - The standard shall provide for the listing
> and description of all interactive parameters which may be provided to
> the modification, including such metadata as data types, filters and
> default values.
>
> 1.9.    User Interactions - The standard shall provide for the
> description of required/allowed user interactivity to occur during the
> application of the modification.
>
> 1.10.Integrity Controls - The standard shall provide for some
> mechanism, such as a digital signature, to provide assurance as to the
> integrity of the modification.
>
> 1.11.Executables and Scripts - The standard shall provide for the
> encapsulation of encoded binary payloads using such mechanisms as
> base64 encoding.
>
> 1.12.Supersedence - The standard shall provide for a user readable
> enumeration of all ORML content superseded by a given modification.
>
> 1.13.Deprecation - The standard shall provide for the specification of
> a Boolean value designating whether a given modification has been
> deprecated.
>
> 1.14.Undo - The standard shall provide for the specification of the
> metadata required to undo a modification.  This includes a flag
> specifying if the undo capability is supported and the reference to a
> modification capable of performing the undo if appropriate.
>
> 1.15.Alternatives - The standard shall provide for the specification of
> many modifications associated with a given applicability/basis
> combination.
>
> 1.16.Side Effects - The standard shall provide for the human readable
> specification of any secondary effects resulting from the application
> of a given modification.
>
> 2.       System Actionable Information
>
> 2.1.    Binary Payload and Execution - The standard shall provide for
> the encapsulation and execution of arbitrary binary content.
>
> 2.2.    Parameterization - The standard shall provide for the
> specification and usage of runtime evaluation of parameters.
>
> 2.3.    External Data - The standard shall provide for the reference to
> external content, such as scripts and executables.
>
> 2.4.    Compatibility with OVAL System Characteristics - The standard
> shall provide for the specification of OVAL System Characteristics as a
> desired state.  For example, the ability to create, delete, modify, and
> overwrite files using OVAL System Characteristics style data.
>
> 2.5.    Administrator Provided Switches and Controls - The standard
> shall provide for the ability to accept switches/controls passed from a
> system administrator prior to deployment and execution.
>
> 2.6.    Status Updates and Error Messages - The standard shall provide
> for the ability to sent status updates/error messages based on the
> success of a modification.
>
> 2.7.    Multiple Action Modifications - The standard shall provide for
> the specification of multiple discrete actions and the sequence in
> which those actions shall run within the scope of a single
> modification.
>
> 2.8.    Action Chains - The standard shall provide for the
> specification of the capability for an action which may otherwise
> require a reboot upon completion to be chained together with other
> actions.
>
> 2.9.    Pre-requisites - The standard shall provide for the system
> actionable specification of SCAP compatible identifiers are pre-
> requisites for the application of a modification or execution of an
> action.
>
> 3.       OVAL Addendums
>
> 3.1.    Relating Findings to Modifications - OVAL shall provide for the
> specification of modifications related to OVAL definitions and
> criterion.
>
> 3.2.    Modification Metadata - OVAL shall provide for the
> specification of metadata about modifications capable of remediating a
> finding.
>
> 3.3.    Modification Encapsulation - OVAL shall provide for the
> encapsulation of a modification.
>
> 3.4.    Modification Success - OVAL shall provide for the assessment of
> the success of the attempted application of a modification.


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

Re: High Level ORML Requirements Ideas

Wolfkiel, Joseph
NIST has just assumed the lead for this effort, so I anticipate seeing some
activity in the near future.

I agree the easiest way to go would be to just work through some body of
content (FDCC checklist/CVEs for a common OS or app) and make a list of
remediations that could be used to bring non-compliant findings into
compliance.  This information, coupled with a way to identify which devices
they should be applied to, is probably the minimum required info for a
remediation tool to do anything.


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: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, February 23, 2009 3:50 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML Requirements
Ideas

Hi,

It has been a long time.  Apparently we tried to bite off more than we could
chew.  We are all scared of remediation because to do it right is so
complicated.

Let's simplify!  K.I.S.S.!

Can we roll out version 1.0 that is for registry keys only.  I don't care
about Windows as some of you might know, but it seems that we should start
somewhere.  How hard can it really be to say that the state should be "such
and such a key should have such and such a value of type blah."  This would
cover a LARGE percent of the FDCC content.  Then we go after the next low
hanging fruit.

If it requires reboot or anything complicated, then let it wait for a future
version.  It seems irresponsible for us to have no standard year after year.
If a vendor wants to implement undo, or anything else not defined, then let
only that stuff be proprietary.

I just want to consume content, but content won't exist if no standard
exists...  If it is possible to come up with something that does more than
registry keys (or there is lower hanging fruit, then let's do that.  Is an
evolutionary approach possible?  Or is our waterfall behind a dam and there
is nothing that can be done?

Best regards,


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

> -----Original Message-----
> From: Kevin Sitto
> Sent: Friday, July 18, 2008 1:12 PM
> To: [hidden email]
> Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML
> Requirements Ideas
>
> Hi,
>
>
>
> Theres been some talk on the mailing list about putting together some
> ORML requirements as a stepping stone to building out a language.  
> Weve tried to incorporate the comments from this list along with
> analysis of the various remediation tools on the market into the draft
> list of requirements below.
>
>
>
> How should these requirements be prioritized  what are the core things
> you need to be able to express in order to automate
> remediation/modification?  Also, is there any data you would need in
> order to remediate vulnerabilities that isnt in this list?
>
>
>
>     User Actionable Information
>
> 1.1.    Unique Identification - The standard shall provide for the
> simple identification of a unique modification
>
> 1.2.    Description - The standard shall provide for a human readable
> description of the modification
>
> 1.3.    Dependencies - The standard shall provide for a human readable
> description of all dependencies for application of the modification
>
> 1.4.    Behavioral Parameters - The standard shall provide for a human
> readable enumeration of all behavioral parameters, such as reboot
> requirement or device locks, associated with a modification
>
> 1.5.    Applicability - The standard shall provide for an enumeration
> of the CPEs the modification applies to
>
> 1.6.    Basis - The standard shall provide for the enumeration SCAP
> compatible identifiers (CVE, CCE, OVAL ID, etc) which represent
> findings that would server as the basis for applying a given
> modification
>
> 1.7.    Error/Status Messages - The standard shall provide for the
> description of error and status messages which may be returned as a
> result of the attempted application of a modification
>
> 1.8.    Switches/Controls - The standard shall provide for the listing
> and description of all interactive parameters which may be provided to
> the modification, including such metadata as data types, filters and
> default values.
>
> 1.9.    User Interactions - The standard shall provide for the
> description of required/allowed user interactivity to occur during the
> application of the modification.
>
> 1.10.Integrity Controls - The standard shall provide for some
> mechanism, such as a digital signature, to provide assurance as to the
> integrity of the modification.
>
> 1.11.Executables and Scripts - The standard shall provide for the
> encapsulation of encoded binary payloads using such mechanisms as
> base64 encoding.
>
> 1.12.Supersedence - The standard shall provide for a user readable
> enumeration of all ORML content superseded by a given modification.
>
> 1.13.Deprecation - The standard shall provide for the specification of
> a Boolean value designating whether a given modification has been
> deprecated.
>
> 1.14.Undo - The standard shall provide for the specification of the
> metadata required to undo a modification.  This includes a flag
> specifying if the undo capability is supported and the reference to a
> modification capable of performing the undo if appropriate.
>
> 1.15.Alternatives - The standard shall provide for the specification
> of many modifications associated with a given applicability/basis
> combination.
>
> 1.16.Side Effects - The standard shall provide for the human readable
> specification of any secondary effects resulting from the application
> of a given modification.
>
> 2.       System Actionable Information
>
> 2.1.    Binary Payload and Execution - The standard shall provide for
> the encapsulation and execution of arbitrary binary content.
>
> 2.2.    Parameterization - The standard shall provide for the
> specification and usage of runtime evaluation of parameters.
>
> 2.3.    External Data - The standard shall provide for the reference to
> external content, such as scripts and executables.
>
> 2.4.    Compatibility with OVAL System Characteristics - The standard
> shall provide for the specification of OVAL System Characteristics as
> a desired state.  For example, the ability to create, delete, modify,
> and overwrite files using OVAL System Characteristics style data.
>
> 2.5.    Administrator Provided Switches and Controls - The standard
> shall provide for the ability to accept switches/controls passed from
> a system administrator prior to deployment and execution.
>
> 2.6.    Status Updates and Error Messages - The standard shall provide
> for the ability to sent status updates/error messages based on the
> success of a modification.
>
> 2.7.    Multiple Action Modifications - The standard shall provide for
> the specification of multiple discrete actions and the sequence in
> which those actions shall run within the scope of a single
> modification.
>
> 2.8.    Action Chains - The standard shall provide for the
> specification of the capability for an action which may otherwise
> require a reboot upon completion to be chained together with other
> actions.
>
> 2.9.    Pre-requisites - The standard shall provide for the system
> actionable specification of SCAP compatible identifiers are pre-
> requisites for the application of a modification or execution of an
> action.
>
> 3.       OVAL Addendums
>
> 3.1.    Relating Findings to Modifications - OVAL shall provide for the
> specification of modifications related to OVAL definitions and
> criterion.
>
> 3.2.    Modification Metadata - OVAL shall provide for the
> specification of metadata about modifications capable of remediating a
> finding.
>
> 3.3.    Modification Encapsulation - OVAL shall provide for the
> encapsulation of a modification.
>
> 3.4.    Modification Success - OVAL shall provide for the assessment of
> the success of the attempted application of a modification.


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

Re: High Level ORML Requirements Ideas

Chandrashekhar B
Hello,

We had some experience building a remediation engine. In general, on a
Windows system, we'll need access to,
 
Registry - Create, Modify, Delete keys/values
File - remove certain files, permissions
Patch - Apply/remove hotfixes
Policy - apply security policy templates
Service - start/stop services

Additionally, we may need access to specific service such as IIS, AD etc. In
IIS, for example, to un-map an ISAPI extension, disable FSO, access to
metabase properties is required.

I think the initial versions could go with the basic list and then enhance
thereon.

Thanks,

Chandrashekhar B.
CTO and Founder
SecPod - an Information Security company

L-16, 3rd Cross, 26th Main Road,
1st Phase, JP Nagar,
Bangalore - 560078
Tel: 91-80- 41214020
Fax: 91-80-41214020
www.secpod.com


-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Tuesday, February 24, 2009 3:48 AM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML Requirements
Ideas

NIST has just assumed the lead for this effort, so I anticipate seeing some
activity in the near future.

I agree the easiest way to go would be to just work through some body of
content (FDCC checklist/CVEs for a common OS or app) and make a list of
remediations that could be used to bring non-compliant findings into
compliance.  This information, coupled with a way to identify which devices
they should be applied to, is probably the minimum required info for a
remediation tool to do anything.


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: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, February 23, 2009 3:50 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML Requirements
Ideas

Hi,

It has been a long time.  Apparently we tried to bite off more than we could
chew.  We are all scared of remediation because to do it right is so
complicated.

Let's simplify!  K.I.S.S.!

Can we roll out version 1.0 that is for registry keys only.  I don't care
about Windows as some of you might know, but it seems that we should start
somewhere.  How hard can it really be to say that the state should be "such
and such a key should have such and such a value of type blah."  This would
cover a LARGE percent of the FDCC content.  Then we go after the next low
hanging fruit.

If it requires reboot or anything complicated, then let it wait for a future
version.  It seems irresponsible for us to have no standard year after year.
If a vendor wants to implement undo, or anything else not defined, then let
only that stuff be proprietary.

I just want to consume content, but content won't exist if no standard
exists...  If it is possible to come up with something that does more than
registry keys (or there is lower hanging fruit, then let's do that.  Is an
evolutionary approach possible?  Or is our waterfall behind a dam and there
is nothing that can be done?

Best regards,


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

> -----Original Message-----
> From: Kevin Sitto
> Sent: Friday, July 18, 2008 1:12 PM
> To: [hidden email]
> Subject: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML
> Requirements Ideas
>
> Hi,
>
>
>
> Theres been some talk on the mailing list about putting together some
> ORML requirements as a stepping stone to building out a language.  
> Weve tried to incorporate the comments from this list along with
> analysis of the various remediation tools on the market into the draft
> list of requirements below.
>
>
>
> How should these requirements be prioritized  what are the core things
> you need to be able to express in order to automate
> remediation/modification?  Also, is there any data you would need in
> order to remediate vulnerabilities that isnt in this list?
>
>
>
>     User Actionable Information
>
> 1.1.    Unique Identification - The standard shall provide for the
> simple identification of a unique modification
>
> 1.2.    Description - The standard shall provide for a human readable
> description of the modification
>
> 1.3.    Dependencies - The standard shall provide for a human readable
> description of all dependencies for application of the modification
>
> 1.4.    Behavioral Parameters - The standard shall provide for a human
> readable enumeration of all behavioral parameters, such as reboot
> requirement or device locks, associated with a modification
>
> 1.5.    Applicability - The standard shall provide for an enumeration
> of the CPEs the modification applies to
>
> 1.6.    Basis - The standard shall provide for the enumeration SCAP
> compatible identifiers (CVE, CCE, OVAL ID, etc) which represent
> findings that would server as the basis for applying a given
> modification
>
> 1.7.    Error/Status Messages - The standard shall provide for the
> description of error and status messages which may be returned as a
> result of the attempted application of a modification
>
> 1.8.    Switches/Controls - The standard shall provide for the listing
> and description of all interactive parameters which may be provided to
> the modification, including such metadata as data types, filters and
> default values.
>
> 1.9.    User Interactions - The standard shall provide for the
> description of required/allowed user interactivity to occur during the
> application of the modification.
>
> 1.10.Integrity Controls - The standard shall provide for some
> mechanism, such as a digital signature, to provide assurance as to the
> integrity of the modification.
>
> 1.11.Executables and Scripts - The standard shall provide for the
> encapsulation of encoded binary payloads using such mechanisms as
> base64 encoding.
>
> 1.12.Supersedence - The standard shall provide for a user readable
> enumeration of all ORML content superseded by a given modification.
>
> 1.13.Deprecation - The standard shall provide for the specification of
> a Boolean value designating whether a given modification has been
> deprecated.
>
> 1.14.Undo - The standard shall provide for the specification of the
> metadata required to undo a modification.  This includes a flag
> specifying if the undo capability is supported and the reference to a
> modification capable of performing the undo if appropriate.
>
> 1.15.Alternatives - The standard shall provide for the specification
> of many modifications associated with a given applicability/basis
> combination.
>
> 1.16.Side Effects - The standard shall provide for the human readable
> specification of any secondary effects resulting from the application
> of a given modification.
>
> 2.       System Actionable Information
>
> 2.1.    Binary Payload and Execution - The standard shall provide for
> the encapsulation and execution of arbitrary binary content.
>
> 2.2.    Parameterization - The standard shall provide for the
> specification and usage of runtime evaluation of parameters.
>
> 2.3.    External Data - The standard shall provide for the reference to
> external content, such as scripts and executables.
>
> 2.4.    Compatibility with OVAL System Characteristics - The standard
> shall provide for the specification of OVAL System Characteristics as
> a desired state.  For example, the ability to create, delete, modify,
> and overwrite files using OVAL System Characteristics style data.
>
> 2.5.    Administrator Provided Switches and Controls - The standard
> shall provide for the ability to accept switches/controls passed from
> a system administrator prior to deployment and execution.
>
> 2.6.    Status Updates and Error Messages - The standard shall provide
> for the ability to sent status updates/error messages based on the
> success of a modification.
>
> 2.7.    Multiple Action Modifications - The standard shall provide for
> the specification of multiple discrete actions and the sequence in
> which those actions shall run within the scope of a single
> modification.
>
> 2.8.    Action Chains - The standard shall provide for the
> specification of the capability for an action which may otherwise
> require a reboot upon completion to be chained together with other
> actions.
>
> 2.9.    Pre-requisites - The standard shall provide for the system
> actionable specification of SCAP compatible identifiers are pre-
> requisites for the application of a modification or execution of an
> action.
>
> 3.       OVAL Addendums
>
> 3.1.    Relating Findings to Modifications - OVAL shall provide for the
> specification of modifications related to OVAL definitions and
> criterion.
>
> 3.2.    Modification Metadata - OVAL shall provide for the
> specification of metadata about modifications capable of remediating a
> finding.
>
> 3.3.    Modification Encapsulation - OVAL shall provide for the
> encapsulation of a modification.
>
> 3.4.    Modification Success - OVAL shall provide for the assessment of
> the success of the attempted application of a modification.
Reply | Threaded
Open this post in threaded view
|

Re: High Level ORML Requirements Ideas

Vladimir Giszpenc
In reply to this post by Wolfkiel, Joseph
Lt Col. Wolfkiel,

We still don't even have the distinction of being an emerging standard.
Ouch!  
How can I help?  

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


> NIST has just assumed the lead for this effort, so I anticipate seeing
> some
> activity in the near future.
>
> I agree the easiest way to go would be to just work through some body
> of
> content (FDCC checklist/CVEs for a common OS or app) and make a list
of

> remediations that could be used to bring non-compliant findings into
> compliance.  This information, coupled with a way to identify which
> devices
> they should be applied to, is probably the minimum required info for a
> remediation tool to do anything.
>
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: High Level ORML Requirements Ideas

Roark, Neal
Please stop emailing me.

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, March 09, 2009 2:03 PM
To: [hidden email]
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] High Level ORML Requirements Ideas

Lt Col. Wolfkiel,

We still don't even have the distinction of being an emerging standard.
Ouch!  
How can I help?  

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


> NIST has just assumed the lead for this effort, so I anticipate seeing
> some
> activity in the near future.
>
> I agree the easiest way to go would be to just work through some body
> of
> content (FDCC checklist/CVEs for a common OS or app) and make a list
of

> remediations that could be used to bring non-compliant findings into
> compliance.  This information, coupled with a way to identify which
> devices
> they should be applied to, is probably the minimum required info for a
> remediation tool to do anything.
>
>
> 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