Re: Decoupling does not mean n o reusing

[Wolfkiel, Joseph]

For the record, I like ORML (Open Remediation and Modification Language).
The "remediation" implies the ability to react to vulnerabilities or weak
settings (remedy), while the "modification" implies that the ability to
impose modifications independent of discovered state (e.g. allow for FDCC
settings that are not vulnerability related, such as automatic shutoff).  It
is also pronounceable -- like a name you'd find on a can of chili.

As an aside, it's probably time to give up on getting everyone to pronounce
SCAP as "ess-cap."  Might as well pronounce it like it's spelled.

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 [phone]


-----Original Message-----
From: Quilter, Alex [mailto:alex.quilter@...]
Sent: Monday, July 07, 2008 12:00 PM
To: OVAL-REMEDIATION-DISCUSSION-LIST@...
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Decoupling does not mean
no reusing


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

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

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

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

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

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

Anyway...

-ALX

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

Thanks Vladimir,

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

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

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

??

NIST has it as OVRL on their web site.

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

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
kent_landfield@...
www.mcafee.com


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

Hello all,

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

Where will the remediation content live?

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

Should ORML reuse OVAL?

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

How can they be separate?

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

Is referring to an OVAL test OK?

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

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

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

[Kent Landfield]

Pronounced "or MuL" ?  Close to normal. :-)  This makes sense to me and
does a better job of indicating what its intentions are.

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
kent_landfield@...
www.mcafee.com
 

-----Original Message-----
From: Wolfkiel, Joseph [mailto:j.wolfki@...]
Sent: Monday, July 07, 2008 1:14 PM
To: OVAL-REMEDIATION-DISCUSSION-LIST@...
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Decoupling does not mean
n o reusing

For the record, I like ORML (Open Remediation and Modification
Language).
The "remediation" implies the ability to react to vulnerabilities or
weak
settings (remedy), while the "modification" implies that the ability to
impose modifications independent of discovered state (e.g. allow for
FDCC
settings that are not vulnerability related, such as automatic shutoff).
It
is also pronounceable -- like a name you'd find on a can of chili.

As an aside, it's probably time to give up on getting everyone to
pronounce
SCAP as "ess-cap."  Might as well pronounce it like it's spelled.

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 [phone]


-----Original Message-----
From: Quilter, Alex [mailto:alex.quilter@...]
Sent: Monday, July 07, 2008 12:00 PM
To: OVAL-REMEDIATION-DISCUSSION-LIST@...
Subject: Re: [OVAL-REMEDIATION-DISCUSSION-LIST] Decoupling does not mean
no reusing


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

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

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

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

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

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

Anyway...

-ALX

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

Thanks Vladimir,

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

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

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

??

NIST has it as OVRL on their web site.

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

--
Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
kent_landfield@...
www.mcafee.com


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

Hello all,

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

Where will the remediation content live?

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

Should ORML reuse OVAL?

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

How can they be separate?

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

Is referring to an OVAL test OK?

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

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

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]