Re: [Xccdf-dev] XCCDF update proposal

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

Re: [Xccdf-dev] XCCDF update proposal

David Solin-3
Hi Dragos (and XCCDF-dev and SCAP-dev users),

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

Best regards,
—David Solin


David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin




On Feb 12, 2016, at 10:05 AM, Dragos Prisaca <[hidden email]> wrote:

Hello David,

 

I am updating the issues list for XCCDF and I think you’ve suggested to correct the “fix” tags to accommodate multiple fix systems, but I can’t locate the email tread. Do you recall anything about this? I may be wrong, but I wanted to double check.

 

Thanks,
_Dragos.


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

xccdf_1.3.xsd (172K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Landfield, Kent B
Hi David,

Appreciate the proposed XCCDF additions. There are others as well that have been proposed over the last 4+ years.  I expect we will need to either see the IETF SACM WG become the official maintenance org for the ISO XCCDF standard or the changes will need to go into an ISO update process.  That is a NIST/SCAM topic that needs to be hashed out before approaching the ISO folks.
---
Kent Landfield
+1.817.637.8026

From: <[hidden email]<mailto:[hidden email]>> on behalf of David Solin <[hidden email]<mailto:[hidden email]>>
Date: Thursday, February 18, 2016 at 1:36 PM
To: Dragos Prisaca <[hidden email]<mailto:[hidden email]>>
Cc: SCAP-DEV <[hidden email]<mailto:[hidden email]>>, "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [scap-dev] XCCDF update proposal

Hi Dragos (and XCCDF-dev and SCAP-dev users),

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

Best regards,
—David Solin



David A. Solin
Co-Founder, Research & Technology
[hidden email]<mailto:[hidden email]>

[Joval Continuous Monitoring]<http://jovalcm.com>

[Facebook] <https://www.facebook.com/jovalcm> [Linkedin] <https://www.linkedin.com/company/joval-continuous-monitoring>


On Feb 12, 2016, at 10:05 AM, Dragos Prisaca <[hidden email]<mailto:[hidden email]>> wrote:

Hello David,



I am updating the issues list for XCCDF and I think you’ve suggested to correct the “fix” tags to accommodate multiple fix systems, but I can’t locate the email tread. Do you recall anything about this? I may be wrong, but I wanted to double check.



Thanks,
_Dragos.


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Tony Rutkowski
Hi Kent,

It was already adopted as an international standard
via ITU-T X.1500 and a virtual link to the source
material.  Why would anyone ever hand it over to
ISO?  That's the kiss of death in the information
standards world.

--tony

On 2016-02-18 2:55 PM, Landfield, Kent B wrote:
Hi David,

Appreciate the proposed XCCDF additions. There are others as well that have been proposed over the last 4+ years.  I expect we will need to either see the IETF SACM WG become the official maintenance org for the ISO XCCDF standard or the changes will need to go into an ISO update process.  That is a NIST/SCAM topic that needs to be hashed out before approaching the ISO folks.
---
Kent Landfield
+1.817.637.8026

From: <[hidden email][hidden email]> on behalf of David Solin <[hidden email][hidden email]>
Date: Thursday, February 18, 2016 at 1:36 PM
To: Dragos Prisaca <[hidden email][hidden email]>
Cc: SCAP-DEV <[hidden email][hidden email]>, "[hidden email][hidden email]" <[hidden email][hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

Hi Dragos (and XCCDF-dev and SCAP-dev users),

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

Best regards,
—David Solin



David A. Solin
Co-Founder, Research & Technology
[hidden email][hidden email]

[Joval Continuous Monitoring]<http://jovalcm.com>

[Facebook] <https://www.facebook.com/jovalcm> [Linkedin] <https://www.linkedin.com/company/joval-continuous-monitoring>


On Feb 12, 2016, at 10:05 AM, Dragos Prisaca <[hidden email][hidden email]> wrote:

Hello David,



I am updating the issues list for XCCDF and I think you’ve suggested to correct the “fix” tags to accommodate multiple fix systems, but I can’t locate the email tread. Do you recall anything about this? I may be wrong, but I wanted to double check.



Thanks,
_Dragos.


_______________________________________________
scap-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

--

________________________________

Anthony Michael Rutkowski

EVP, Industry Standards & Regulatory Affairs

[hidden email]

<a href="tel:+1%20703%20999%208270">+1 703 999 8270

________________________________

Yaana Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 USA


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Tony Rutkowski
In reply to this post by Landfield, Kent B
Kent,

SCAM appears to be the appropriate acronym.

Now let me understand this...Although XCCDF was
already adopted virtually as an international
standard via an ITU-T pointer mechanism for free,
this USG intellectual property was handed over
to a Swiss-based non-profit standards publishing
organization to sell that intellectual property
back to U.S. industry and the public for $180 - with
the objective of furthering U.S. cybersecurity??
https://webstore.iec.ch/publication/10664&preview=1

This doesn't even get to the constraints imposed
on the evolution of the standard by what is arguably
the worst standards development process in the world.

This kind of behavior deserves to be noticed before
Congress.  It's a good thing the new Cybersecurity
Act gives the go forward responsibilities to the DHS,
DNI, and DOJ together with DOD.

--tony



On 2016-02-18 2:55 PM, Landfield, Kent B wrote:
> XCCDF standard or the changes will need to go into an ISO update process.  That is a NIST/SCAM topic that needs to be hashed out before approaching the ISO folks.



_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Landfield, Kent B
Yep, that’s what you get when you type fast…  I was not involved with that so I’ll let others answer your questions.
---
Kent Landfield
+1.817.637.8026







On 2/18/16, 3:38 PM, "Tony Rutkowski" <[hidden email]> wrote:

>Kent,
>
>SCAM appears to be the appropriate acronym.
>
>Now let me understand this...Although XCCDF was
>already adopted virtually as an international
>standard via an ITU-T pointer mechanism for free,
>this USG intellectual property was handed over
>to a Swiss-based non-profit standards publishing
>organization to sell that intellectual property
>back to U.S. industry and the public for $180 - with
>the objective of furthering U.S. cybersecurity??
>https://webstore.iec.ch/publication/10664&preview=1
>
>This doesn't even get to the constraints imposed
>on the evolution of the standard by what is arguably
>the worst standards development process in the world.
>
>This kind of behavior deserves to be noticed before
>Congress.  It's a good thing the new Cybersecurity
>Act gives the go forward responsibilities to the DHS,
>DNI, and DOJ together with DOD.
>
>--tony
>
>
>
>On 2016-02-18 2:55 PM, Landfield, Kent B wrote:
>> XCCDF standard or the changes will need to go into an ISO update process.  That is a NIST/SCAM topic that needs to be hashed out before approaching the ISO folks.
>
>

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Landfield, Kent B
In reply to this post by Landfield, Kent B
Before we get 30+ “can you remove me” messages…..

To unsubscribe from either of these lists, please go to http://scap.nist.gov/community.html and do it yourself.

Thanks.
---
Kent Landfield
+1.817.637.8026

From: "Pere, Daniel@CHP" <[hidden email]<mailto:[hidden email]>>
Date: Thursday, February 18, 2016 at 3:58 PM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>, Kent Landfield <[hidden email]<mailto:[hidden email]>>, David Solin <[hidden email]<mailto:[hidden email]>>, Dragos Prisaca <[hidden email]<mailto:[hidden email]>>
Cc: SCAP-DEV <[hidden email]<mailto:[hidden email]>>, "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: RE: [scap-dev] XCCDF update proposal

Please remove me from your distribution list



Sent from my T-Mobile 4G LTE Device


-------- Original message --------
From: Tony Rutkowski <[hidden email]<mailto:[hidden email]>>
Date: 2/18/2016 1:42 PM (GMT-08:00)
To: "Landfield, Kent B" <[hidden email]<mailto:[hidden email]>>, David Solin <[hidden email]<mailto:[hidden email]>>, Dragos Prisaca <[hidden email]<mailto:[hidden email]>>
Cc: SCAP-DEV <[hidden email]<mailto:[hidden email]>>, [hidden email]<mailto:[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

Kent,

SCAM appears to be the appropriate acronym.

Now let me understand this...Although XCCDF was
already adopted virtually as an international
standard via an ITU-T pointer mechanism for free,
this USG intellectual property was handed over
to a Swiss-based non-profit standards publishing
organization to sell that intellectual property
back to U.S. industry and the public for $180 - with
the objective of furthering U.S. cybersecurity??
https://webstore.iec.ch/publication/10664&preview=1

This doesn't even get to the constraints imposed
on the evolution of the standard by what is arguably
the worst standards development process in the world.

This kind of behavior deserves to be noticed before
Congress.  It's a good thing the new Cybersecurity
Act gives the go forward responsibilities to the DHS,
DNI, and DOJ together with DOD.

--tony



On 2016-02-18 2:55 PM, Landfield, Kent B wrote:
> XCCDF standard or the changes will need to go into an ISO update process.  That is a NIST/SCAM topic that needs to be hashed out before approaching the ISO folks.



_______________________________________________
scap-dev mailing list
[hidden email]<mailto:[hidden email]>
To unsubscribe, send an email message to [hidden email]<mailto:[hidden email]>.

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Waltermire, David A.
In reply to this post by David Solin-3

David,

 

Thanks for posting this.

 

Looking at your schema changes, a couple of things jump out at me:

 

1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?

2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.

3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.

4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?

5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?

6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.

7)      What is inline-export used for?

 

Thanks,

Dave

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi Dragos (and XCCDF-dev and SCAP-dev users),

 

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

 

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

 

Best regards,

—David Solin

 

 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin

 


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

David Solin-3
Hi David, thanks for the feedback!  Please see below…

—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:

David,
 
Thanks for posting this.
 
Looking at your schema changes, a couple of things jump out at me:
 
1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?

That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.

2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.

We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?

3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.

I’ll do a diff and check that out; it was inadvertent.

4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?

That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.

5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?

I honestly have no idea where that came from.

6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.

We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.

7)      What is inline-export used for?

I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.

Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?

After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.


 
Thanks,
Dave
 
From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi Dragos (and XCCDF-dev and SCAP-dev users),
 
I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.
 
I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.
 
Best regards,
—David Solin
 
 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Waltermire, David A.

Thanks for the quick response. Additional comments are inline below.

 

Thanks,

Dave

 

From: David Solin [mailto:[hidden email]]
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi David, thanks for the feedback!  Please see below…

 

—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin

 

On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:

 

David,

 

Thanks for posting this.

 

Looking at your schema changes, a couple of things jump out at me:

 

1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?

 

That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.


I thought so. Seems cleaner the way I was suggesting.

 

2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.

 

We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?

 

 

Not sure. Do you see a need to adjust the order of operations based on the “hint”?

 



3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.

 

I’ll do a diff and check that out; it was inadvertent.



4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?

 

That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.

 

 

Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link.

 



5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?

 

I honestly have no idea where that came from.


This is also not found in the 1.2 schema.

 

6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.

 

We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.


This makes sense.

 

7)      What is inline-export used for?

 

I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.

 

Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?

 

After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.

 

 

If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?



 

Thanks,

Dave

 

From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi Dragos (and XCCDF-dev and SCAP-dev users),

 

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

 

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

 

Best regards,

—David Solin

 

 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin

 


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Vishal Palkar

UNSUBSCRIBE



From: [hidden email] <[hidden email]> on behalf of Waltermire, David A. <[hidden email]>
Sent: Friday, February 19, 2016 09:04 AM
To: David Solin
Cc: XCCDF-DEV; SCAP-DEV; Dragos Prisaca
Subject: Re: [scap-dev] XCCDF update proposal
 

Thanks for the quick response. Additional comments are inline below.

 

Thanks,

Dave

 

From: David Solin [mailto:[hidden email]]
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi David, thanks for the feedback!  Please see below…

 

—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin

 

On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:

 

David,

 

Thanks for posting this.

 

Looking at your schema changes, a couple of things jump out at me:

 

1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?

 

That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.


I thought so. Seems cleaner the way I was suggesting.

 

2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.

 

We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?

 

 

Not sure. Do you see a need to adjust the order of operations based on the “hint”?

 



3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.

 

I’ll do a diff and check that out; it was inadvertent.



4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?

 

That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.

 

 

Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link.

 



5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?

 

I honestly have no idea where that came from.


This is also not found in the 1.2 schema.

 

6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.

 

We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.


This makes sense.

 

7)      What is inline-export used for?

 

I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.

 

Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?

 

After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.

 

 

If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?



 

Thanks,

Dave

 

From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi Dragos (and XCCDF-dev and SCAP-dev users),

 

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

 

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

 

Best regards,

—David Solin

 

 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin

 


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Jan Lieskovsky
In reply to this post by Waltermire, David A.

Hello DavidS,

  thank you for the proposal. I will comment on some of the previous
DavidW points below.

  But prior doing that slight wondering -- should the XCCDF v1.3 proposal
add support for the SWID tags? (besides of existing CPE v2.3 support):
* http://csrc.nist.gov/news_events/cif_2015/security-automation/day2_security-automation_330-420.pdf
* http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-8060
* http://csrc.nist.gov/publications/drafts/nistir-8060/nistir_8060_draft_fourth.pdf
* http://standards.iso.org/iso/19770/-2/2015/schema.xsd

I am not completely familiar with the process of creation of new XCCDF
standard version (maybe if these DavidS proposals would get accepted, the
schema version would be increased to XCCDF 1.2.1, and not 1.3?)

I understand the concept of SWID tags being in the state of just draft now,
but should we consider adding something like 'tech-preview' support for them
in XCCDF standard?

----- Original Message -----

> From: "David A. Waltermire" <[hidden email]>
> To: "David Solin" <[hidden email]>
> Cc: "XCCDF-DEV" <[hidden email]>, "SCAP-DEV" <[hidden email]>, "Dragos Prisaca" <[hidden email]>
> Sent: Friday, February 19, 2016 4:34:03 AM
> Subject: Re: [scap-dev] XCCDF update proposal
>
>
>
> Thanks for the quick response. Additional comments are inline below.
>
>
>
> Thanks,
>
> Dave
>
>
>
>
> From: David Solin [mailto:[hidden email]]
> Sent: Thursday, February 18, 2016 10:17 PM
> To: Waltermire, David A. <[hidden email]>
> Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>;
> XCCDF-DEV <[hidden email]>
> Subject: Re: [scap-dev] XCCDF update proposal
>
>
>
>
> Hi David, thanks for the feedback! Please see below…
>
>
>
>
>
> —David
>
>
> David A. Solin
> Co-Founder, Research & Technology
> [hidden email]
>
>
>
>
>
>
>
>
>
>
>
>
> On Feb 18, 2016, at 8:21 PM, Waltermire, David A. < [hidden email]
> > wrote:
>
>
>
>
>
> David,
>
>
>
>
>
> Thanks for posting this.
>
>
>
>
>
> Looking at your schema changes, a couple of things jump out at me:
>
>
>
>
>
> 1) The current design of the schema (i.e., 1.2.1, your proposal) involves a
> proliferation of “default” elements on the Value children. Could this be
> simplified by removing the default elements from the schema and by adding a
> “default” attribute that may only be set on one of the value, complex-value,
> or import-value elements?
>
>
>
>
>
> That’s certainly a possibility! Functionally it would be equivalent, of
> course. Both elements reference the same typedefs.
>
>
>
> I thought so. Seems cleaner the way I was suggesting.
>
>
>
>
>
>
> 2) How would import-value impact the processing order defined in the
> specification? It seems like the import-value elements would need to be
> evaluated before any profiles attempt to select it or any rules attempt to
> export it.
>
>
>
>
>
> We certainly wouldn’t want that, particularly if one were about to scan
> thousands of machines using some profile, as the values are target-specific.
> So, perhaps we should add a “hint” attribute that would be used as a
> placeholder in a selection UI. WDYT?
>
>
>
>
>
>
> Not sure. Do you see a need to adjust the order of operations based on the
> “hint”?
>
>
>
>
>
>
>
>
>
>
> 3) The documentation on the Benchmark element appears to be removed. There
> are some other documentation missing on other elements, attributes, and
> enumerations as well.
>
>
>
>
>
> I’ll do a diff and check that out; it was inadvertent.
>
>
>
>
>
>
>
>
>
> 4) You added a profileIdKeyRef. This enforces that a test result must
> reference a profile in the same document. Doesn’t this break profiles from
> external tailoring files being referenced?
>
>
>
>
>
> That wasn’t me! Someone added that in 2010, according to the log at the
> bottom. You’re right, though, that looks like it would cause a validation
> error in ARF XML files containing (using/referencing) tailorings.
>
>
>
>
>
>
> Weird. I did a diff against your schema and the one posted on the XCCDF page:
> http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd . The “ profileIdKeyRef”
> is not in the 1.2 schema found at this link.
>
>
>
>
>
>
>
>
>
>
> 5) You added a complexType “overrideableIdrefType”, which doesn’t appear to
> be used. Did I miss something?
>
>
>
>
>
> I honestly have no idea where that came from.
>
>
>
> This is also not found in the 1.2 schema.
>
>
>
>
>
>
> 6) You removed fix-text from Rule elements and moved the attributes to the
> fix element. I guess if fix content is not required, the new construct is
> simpler without a need for a reference between fix and fixtext? This seems
> like an improvement if I am getting it right.
>
>
>
>
>
> We believe every fix should have a text description (or a title at the very
> least) associated with it. There is still an allowance for fix content; we
> moved it into its own type (fixContentType) — now a child of fixType
> (analogous to checkContentType). That will help people to select which
> one(s) they might want to perform in the event of a rule failure.
>
>
>
> This makes sense.

+1 on this. Looks reasonable to me.

>
>
>
>
>
>
> 7) What is inline-export used for?
>
>
>
>
>
> I wanted a way to support exporting values to the checks used by the
> newly-introduced import-value type. But I didn’t want the mind-boggling
> complexity associated with pointing to other potentially imported check
> values (and possibly having infinite loops). So, I introduced this type and
> crafted the schema so that it would be the only way to export a value to the
> check in a selImportType.
>
>
>
>
>
> Basically, if you’re importing a value from a check to use elsewhere in the
> XCCDF, then you have to statically define any value that’s exported to that
> check “inline” with the definition of that imported value. Make sense?

Can you hopefully provide a simple example here? IIGIR this enhancement would
introduce a second way how values can be defined:
* first way is the currently existing one (a value is defined, then it's re-used /
  referenced somewhere in the XCCDF),
* the second way would be this 'inline-export' one, where by value definition
  the content author would specify also the ID of the check it should be exported
  into?

  Maybe an analogy to understand the difference - current XCCDF allows to define
"global values" referencable anywhere. Your proposal is introducing "per-check
specific values" to be reused in other checks. Such a 'per-check specific value'
could be later re-used by one check, or by multiple checks (by cascading the
inline value definitions). Is this understanding right?

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

>
>
>
>
>
> After all, if you need to have a value whose computed value by a check system
> depends on yet another computed value by a check system — then you should be
> possible to stuff it all into the logic for a single check, and point to
> that, without requiring the checklist processor manage all the tangled
> back-and-forth.
>
>
>
>
>
>
>
> If Value elements are processed pre-check resolution, how would such a loop
> exist? Is this not the assumption you are working under?
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
>
> Dave
>
>
>
>
>
> From: [hidden email] [ mailto:[hidden email] ] On
> Behalf Of David Solin
> Sent: Thursday, February 18, 2016 2:36 PM
> To: Dragos Prisaca < [hidden email] >
> Cc: SCAP-DEV < [hidden email] >; XCCDF-DEV < [hidden email] >
> Subject: Re: [scap-dev] XCCDF update proposal
>
>
>
>
>
> Hi Dragos (and XCCDF-dev and SCAP-dev users),
>
>
>
>
>
> I’ve attached a proposed schema for XCCDF 1.3. This builds upon the new types
> I proposed earlier for xccdf:Values based on check-imports, and also aligns
> the structure of the fixType with that of the checkType. It would be fairly
> simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to
> this new version.
>
>
>
>
>
> I know Dave Waltermire indicated that changes to XCCDF are probably not in
> scope for SCAP 1.3, but I wanted to make everyone aware of these ideas
> nevertheless, and solicit any feedback.
>
>
>
>
>
> Best regards,
>
>
> —David Solin
>
>
>
>
>
>
>
>
> David A. Solin
> Co-Founder, Research & Technology
> [hidden email]
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> scap-dev mailing list
> [hidden email]
> To unsubscribe, send an email message to [hidden email].

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

David Solin-3
In reply to this post by Waltermire, David A.
Hi Dave,

Re #7, values are processed prior to checks, except these are values that themselves refer to checks (let’s call those value-checks).  So, the value-checks are evaluated before the rest of the checks.  The question was, in my mind, did I want a value-check to have to potentially depend on another Value, which could potentially be another value-check, and so on.  The answer was no — and the solution was to allow only statically-defined exports to the value-checks.

I hope that makes some sense?

As for the XCCDF schema I started from, I’ll have to try and determine where we got it originally.  Perhaps it was from the validation utility.  In any case, I didn’t mean to introduce any of the changes I’m not familiar with.  I'll re-submit my changes based on the “clean” version of the schema (at the URL you referenced) later today.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 18, 2016, at 9:34 PM, Waltermire, David A. <[hidden email]> wrote:

Thanks for the quick response. Additional comments are inline below.
 
Thanks,
Dave
 
From: David Solin [[hidden email]] 
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi David, thanks for the feedback!  Please see below…
 
—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring
 
On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:
 
David,
 
Thanks for posting this.
 
Looking at your schema changes, a couple of things jump out at me:
 
1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?
 
That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.

I thought so. Seems cleaner the way I was suggesting.
 
2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.
 
We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?
 
 
Not sure. Do you see a need to adjust the order of operations based on the “hint”?
 


3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.
 
I’ll do a diff and check that out; it was inadvertent.


4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?
 
That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.
 
 
Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link. 
 


5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?
 
I honestly have no idea where that came from.

This is also not found in the 1.2 schema.
 
6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.
 
We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.

This makes sense.
 
7)      What is inline-export used for?
 
I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.
 
Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?
 
After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.
 
 
If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?


 
Thanks,
Dave
 
From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi Dragos (and XCCDF-dev and SCAP-dev users),
 
I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.
 
I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.
 
Best regards,
—David Solin
 
 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

pinnaclesystemsgroup
Hi David

I'd like to chime in on the dialog here regarding the proposed changes to the XCDDF Schema. Perhaps 
I'm not understanding all of the rationale for the value elements/attributes for automated checks. I'll go back and read over all the prior posts on this thread again and your proposal to confirm I'm getting what you're after here. If I've missed something there apologies in advance for any mistakes in my comments- I'll  correct them in my next post to this thread. 

First architecturally, your proposed changes appear to create a new Schema "type" which is actually metadata on the value-check element in the current XCDDF.  This raises the issue of how to link these new type values to other element/attribute values in the Schema. This linking attempts to simplify the value check or at least bound its value in an obvious way. 

My comment is are you taking "cohesion" and the dependency between what's in the value -check and their platform representation (are these really metadata, and not actual check values) into account? How will the value-checks "bind" and be validated by the Schema check ? 

My next comment is are you refractoring the default  values in the 'import values" elements and are these new XSD types being defined or complex types built upon other Schema values which are a actually more metadata representations of those values?

Prince Riley
Pinnacle Systems Group, LLC.  








On February 19, 2016 at 8:08:26 AM EST, David Solin <[hidden email]> wrote:
Hi Dave,

Re #7, values are processed prior to checks, except these are values that themselves refer to checks (let’s call those value-checks).  So, the value-checks are evaluated before the rest of the checks.  The question was, in my mind, did I want a value-check to have to potentially depend on another Value, which could potentially be another value-check, and so on.  The answer was no — and the solution was to allow only statically-defined exports to the value-checks.

I hope that makes some sense?

As for the XCCDF schema I started from, I’ll have to try and determine where we got it originally.  Perhaps it was from the validation utility.  In any case, I didn’t mean to introduce any of the changes I’m not familiar with.  I'll re-submit my changes based on the “clean” version of the schema (at the URL you referenced) later today.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 18, 2016, at 9:34 PM, Waltermire, David A. <[hidden email]> wrote:

Thanks for the quick response. Additional comments are inline below.
 
Thanks,
Dave
 
From: David Solin [[hidden email]] 
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi David, thanks for the feedback!  Please see below…
 
—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring
 
On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:
 
David,
 
Thanks for posting this.
 
Looking at your schema changes, a couple of things jump out at me:
 
1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?
 
That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.

I thought so. Seems cleaner the way I was suggesting.
 
2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.
 
We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?
 
 
Not sure. Do you see a need to adjust the order of operations based on the “hint”?
 


3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.
 
I’ll do a diff and check that out; it was inadvertent.


4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?
 
That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.
 
 
Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link. 
 


5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?
 
I honestly have no idea where that came from.

This is also not found in the 1.2 schema.
 
6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.
 
We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.

This makes sense.
 
7)      What is inline-export used for?
 
I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.
 
Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?
 
After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.
 
 
If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?


 
Thanks,
Dave
 
From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi Dragos (and XCCDF-dev and SCAP-dev users),
 
I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.
 
I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.
 
Best regards,
—David Solin
 
 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

David Solin-3
Hi Prince,

No, these are not intended to be metadata.  These are intended to be actual values that are exported to an external check system.  I designed them to be used as the exclusive mechanism for exporting values to checks that are used to set a globally-defined value that can be used elsewhere across the XCCDF and exported to other checks.

(I believe Jan has picked up on the difference exactly.  Normally, values are global in scope.  But these inline values are defined in the context of a specific export to an external check system, and apply only to the check or fix with which they are immediately associated.)

I previously made a proposal regarding the use of external check systems to import vales, for use in other checks.  This was originally intended to address a use-case for SPAWAR, but could potentially have other applications as well.  This proposal extends those same concepts to the fixType enhancements I’m also proposing.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 19, 2016, at 7:39 AM, Pinnacle Systems Group <[hidden email]> wrote:

Hi David

I'd like to chime in on the dialog here regarding the proposed changes to the XCDDF Schema. Perhaps 
I'm not understanding all of the rationale for the value elements/attributes for automated checks. I'll go back and read over all the prior posts on this thread again and your proposal to confirm I'm getting what you're after here. If I've missed something there apologies in advance for any mistakes in my comments- I'll  correct them in my next post to this thread. 

First architecturally, your proposed changes appear to create a new Schema "type" which is actually metadata on the value-check element in the current XCDDF.  This raises the issue of how to link these new type values to other element/attribute values in the Schema. This linking attempts to simplify the value check or at least bound its value in an obvious way. 

My comment is are you taking "cohesion" and the dependency between what's in the value -check and their platform representation (are these really metadata, and not actual check values) into account? How will the value-checks "bind" and be validated by the Schema check ? 

My next comment is are you refractoring the default  values in the 'import values" elements and are these new XSD types being defined or complex types built upon other Schema values which are a actually more metadata representations of those values?

Prince Riley
Pinnacle Systems Group, LLC.  








On February 19, 2016 at 8:08:26 AM EST, David Solin <[hidden email]> wrote:
Hi Dave,

Re #7, values are processed prior to checks, except these are values that themselves refer to checks (let’s call those value-checks).  So, the value-checks are evaluated before the rest of the checks.  The question was, in my mind, did I want a value-check to have to potentially depend on another Value, which could potentially be another value-check, and so on.  The answer was no — and the solution was to allow only statically-defined exports to the value-checks.

I hope that makes some sense?

As for the XCCDF schema I started from, I’ll have to try and determine where we got it originally.  Perhaps it was from the validation utility.  In any case, I didn’t mean to introduce any of the changes I’m not familiar with.  I'll re-submit my changes based on the “clean” version of the schema (at the URL you referenced) later today.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 18, 2016, at 9:34 PM, Waltermire, David A. <[hidden email]> wrote:

Thanks for the quick response. Additional comments are inline below.
 
Thanks,
Dave
 
From: David Solin [[hidden email]] 
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi David, thanks for the feedback!  Please see below…
 
—David
David A. Solin
Co-Founder, Research & Technology
[hidden email]
Joval Continuous Monitoring
 
On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:
 
David,
 
Thanks for posting this.
 
Looking at your schema changes, a couple of things jump out at me:
 
1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?
 
That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.

I thought so. Seems cleaner the way I was suggesting.
 
2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.
 
We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?
 
 
Not sure. Do you see a need to adjust the order of operations based on the “hint”?
 


3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.
 
I’ll do a diff and check that out; it was inadvertent.


4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?
 
That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.
 
 
Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link. 
 


5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?
 
I honestly have no idea where that came from.

This is also not found in the 1.2 schema.
 
6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.
 
We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.

This makes sense.
 
7)      What is inline-export used for?
 
I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.
 
Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?
 
After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.
 
 
If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?


 
Thanks,
Dave
 
From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi Dragos (and XCCDF-dev and SCAP-dev users),
 
I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.
 
I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.
 
Best regards,
—David Solin
 
 
David A. Solin
Co-Founder, Research & Technology
[hidden email]
Joval Continuous Monitoring

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

David Solin-3
In reply to this post by Waltermire, David A.
Hi David,

The attached schema addresses the extraneous changes you pointed out and adds the “hint” attribute I mentioned; hopefully a diff will only yield the meaningful changes now.  I also changed the version number back to XCCDF 1.2 for now, only to make it easier for me to produce running code with the schema for any ongoing discussion/modifications.

The only change I didn’t make was to add a boolean “default” attribute and eliminate the default elements… only because I’m somewhat indifferent to it.  I don’t think I want to add a “default” attribute to the selStringType, selImportType or selComplexValueType, so I’d have to create new wrapper elements to contain the new attribute, and that just felt like it would involve more pain than reward.

Best regards,
—David Solin




David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 18, 2016, at 9:34 PM, Waltermire, David A. <[hidden email]> wrote:

Thanks for the quick response. Additional comments are inline below.
 
Thanks,
Dave
 
From: David Solin [[hidden email]] 
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi David, thanks for the feedback!  Please see below…
 
—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring
 
On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:
 
David,
 
Thanks for posting this.
 
Looking at your schema changes, a couple of things jump out at me:
 
1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?
 
That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.

I thought so. Seems cleaner the way I was suggesting.
 
2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.
 
We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?
 
 
Not sure. Do you see a need to adjust the order of operations based on the “hint”?
 


3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.
 
I’ll do a diff and check that out; it was inadvertent.


4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?
 
That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.
 
 
Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link. 
 


5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?
 
I honestly have no idea where that came from.

This is also not found in the 1.2 schema.
 
6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.
 
We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.

This makes sense.
 
7)      What is inline-export used for?
 
I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.
 
Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?
 
After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.
 
 
If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?


 
Thanks,
Dave
 
From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi Dragos (and XCCDF-dev and SCAP-dev users),
 
I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.
 
I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.
 
Best regards,
—David Solin
 
 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

xccdf_1.2.xsd (415K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

David Solin-3
Sorry, Dave, I forgot to remove fixTextType from that one.  Attached is an updated copy of the XSD (this one with the new URI; I’ll stop being lazy about producing a working build), and also an XSL that can be used to convert from XCCDF 1.2 to this new version.

Best regards,
—David Solin

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin





On Feb 19, 2016, at 6:02 PM, David Solin <[hidden email]> wrote:

Hi David,

The attached schema addresses the extraneous changes you pointed out and adds the “hint” attribute I mentioned; hopefully a diff will only yield the meaningful changes now.  I also changed the version number back to XCCDF 1.2 for now, only to make it easier for me to produce running code with the schema for any ongoing discussion/modifications.

The only change I didn’t make was to add a boolean “default” attribute and eliminate the default elements… only because I’m somewhat indifferent to it.  I don’t think I want to add a “default” attribute to the selStringType, selImportType or selComplexValueType, so I’d have to create new wrapper elements to contain the new attribute, and that just felt like it would involve more pain than reward.

Best regards,
—David Solin


<xccdf_1.2.xsd>

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin


On Feb 18, 2016, at 9:34 PM, Waltermire, David A. <[hidden email]> wrote:

Thanks for the quick response. Additional comments are inline below.
 
Thanks,
Dave
 
From: David Solin [[hidden email]] 
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi David, thanks for the feedback!  Please see below…
 
—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring
 
On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:
 
David,
 
Thanks for posting this.
 
Looking at your schema changes, a couple of things jump out at me:
 
1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?
 
That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.

I thought so. Seems cleaner the way I was suggesting.
 
2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.
 
We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?
 
 
Not sure. Do you see a need to adjust the order of operations based on the “hint”?
 


3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.
 
I’ll do a diff and check that out; it was inadvertent.


4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?
 
That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.
 
 
Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link. 
 


5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?
 
I honestly have no idea where that came from.

This is also not found in the 1.2 schema.
 
6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.
 
We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.

This makes sense.
 
7)      What is inline-export used for?
 
I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.
 
Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?
 
After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.
 
 
If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?


 
Thanks,
Dave
 
From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
 
Hi Dragos (and XCCDF-dev and SCAP-dev users),
 
I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.
 
I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.
 
Best regards,
—David Solin
 
 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring



_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

xccdf_1.3.xsd (410K) Download Attachment
xccdf_convert_1.2_to_1.3.xsl (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [scap-dev] XCCDF update proposal

Geo PC
In reply to this post by Vishal Palkar

UNSUBSCRIBE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Boucher P (Pierre) at Aera
Sent: 23 February 2016 06:23
To: Vishal Palkar; Waltermire, David A.; David Solin
Cc: XCCDF-DEV; SCAP-DEV
Subject: Re: [scap-dev] XCCDF update proposal

 

UNSUBSCRIBE

 

 

 

From: [hidden email] [[hidden email]] On Behalf Of Vishal Palkar
Sent: Friday, February 19, 2016 12:35 AM
To: Waltermire, David A. <[hidden email]>; David Solin <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal
Importance: High

 

UNSUBSCRIBE

 


From: [hidden email] <[hidden email]> on behalf of Waltermire, David A. <[hidden email]>
Sent: Friday, February 19, 2016 09:04 AM
To: David Solin
Cc: XCCDF-DEV; SCAP-DEV; Dragos Prisaca
Subject: Re: [scap-dev] XCCDF update proposal

 

Thanks for the quick response. Additional comments are inline below.

 

Thanks,

Dave

 

From: David Solin [[hidden email]]
Sent: Thursday, February 18, 2016 10:17 PM
To: Waltermire, David A. <[hidden email]>
Cc: Dragos Prisaca <[hidden email]>; SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi David, thanks for the feedback!  Please see below…

 

—David

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

Facebook Linkedin

 

On Feb 18, 2016, at 8:21 PM, Waltermire, David A. <[hidden email]> wrote:

 

David,

 

Thanks for posting this.

 

Looking at your schema changes, a couple of things jump out at me:

 

1)      The current design of the schema (i.e., 1.2.1, your proposal) involves a proliferation of “default” elements on the Value children. Could this be simplified by removing the default elements from the schema and by adding a “default” attribute that may only be set on one of the value, complex-value, or import-value elements?

 

That’s certainly a possibility!  Functionally it would be equivalent, of course.  Both elements reference the same typedefs.


I thought so. Seems cleaner the way I was suggesting.

 

2)      How would import-value impact the processing order defined in the specification? It seems like the import-value elements would need to be evaluated before any profiles attempt to select it or any rules attempt to export it.

 

We certainly wouldn’t want that, particularly if one were about to scan thousands of machines using some profile, as the values are target-specific.  So, perhaps we should add a “hint” attribute that would be used as a placeholder in a selection UI.  WDYT?

 

 

Not sure. Do you see a need to adjust the order of operations based on the “hint”?

 

 

3)      The documentation on the Benchmark element appears to be removed. There are some other documentation missing on other elements, attributes, and enumerations as well.

 

I’ll do a diff and check that out; it was inadvertent.

 

4)      You added a profileIdKeyRef. This enforces that a test result must reference a profile in the same document. Doesn’t this break profiles from external tailoring files being referenced?

 

That wasn’t me!  Someone added that in 2010, according to the log at the bottom.  You’re right, though, that looks like it would cause a validation error in ARF XML files containing (using/referencing) tailorings.

 

 

Weird. I did a diff against your schema and the one posted on the XCCDF page: http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd. The “profileIdKeyRef” is not in the 1.2 schema found at this link.

 

 

5)      You added a complexType “overrideableIdrefType”, which doesn’t appear to be used. Did I miss something?

 

I honestly have no idea where that came from.


This is also not found in the 1.2 schema.

 

6)      You removed fix-text from Rule elements and moved the attributes to the fix element. I guess if fix content is not required, the new construct is simpler without a need for a reference between fix and fixtext? This seems like an improvement if I am getting it right.

 

We believe every fix should have a text description (or a title at the very least) associated with it.  There is still an allowance for fix content; we moved it into its own type (fixContentType) — now a child of fixType (analogous to checkContentType).  That will help people to select which one(s) they might want to perform in the event of a rule failure.


This makes sense.

 

7)      What is inline-export used for?

 

I wanted a way to support exporting values to the checks used by the newly-introduced import-value type.  But I didn’t want the mind-boggling complexity associated with pointing to other potentially imported check values (and possibly having infinite loops).  So, I introduced this type and crafted the schema so that it would be the only way to export a value to the check in a selImportType.

 

Basically, if you’re importing a value from a check to use elsewhere in the XCCDF, then you have to statically define any value that’s exported to that check “inline” with the definition of that imported value.  Make sense?

 

After all, if you need to have a value whose computed value by a check system depends on yet another computed value by a check system — then you should be possible to stuff it all into the logic for a single check, and point to that, without requiring the checklist processor manage all the tangled back-and-forth.

 

 

If Value elements are processed pre-check resolution, how would such a loop exist? Is this not the assumption you are working under?

 

 

Thanks,

Dave

 

From: [hidden email] [[hidden email]] On Behalf Of David Solin
Sent: Thursday, February 18, 2016 2:36 PM
To: Dragos Prisaca <[hidden email]>
Cc: SCAP-DEV <[hidden email]>; XCCDF-DEV <[hidden email]>
Subject: Re: [scap-dev] XCCDF update proposal

 

Hi Dragos (and XCCDF-dev and SCAP-dev users),

 

I’ve attached a proposed schema for XCCDF 1.3.  This builds upon the new types I proposed earlier for xccdf:Values based on check-imports, and also aligns the structure of the fixType with that of the checkType.  It would be fairly simple to create an XSL transform to upgrade XCCDF benchmarks from v1.2 to this new version.

 

I know Dave Waltermire indicated that changes to XCCDF are probably not in scope for SCAP 1.3, but I wanted to make everyone aware of these ideas nevertheless, and solicit any feedback.

 

Best regards,

—David Solin

 

 

David A. Solin
Co-Founder, Research & Technology
[hidden email]

Joval Continuous Monitoring

 


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

[Xccdf-dev] unsubscribe

Robb Delaney

unsubscribe


Thank you,

Robb Delaney
Call Architect
HighPoint
M:(317) 605-7780
O: (443) 316-5253
[hidden email]



_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].