RE: XCCDF Profiles within SCAP

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

RE: XCCDF Profiles within SCAP

Ronayne, James K.

I think rev 1 of 800-126 allows the platform tag to be applied to
profiles, groups, and rules (800-126 r1 sect 4.2.2) instead of just the
benchmark as required in SCAP 1.0 (800-126 sect 4.1.2).

I think it would be useful to allow additional tags to define the
applicability of benchmarks, profiles, groups, and rules.  Right now any
applicability statement for these items is limited to the platform tag
and a string description.  If we were to allow more attributes of these
items then scanners that might have either collected data or stored
manually entered data would be in a better position to automatically
determine which items apply to which target systems.  For example, could
we tag a profile with the target role of domain controller (where DC is
an actual attribute instead of just free text in the description)?
Could we tag a profile to apply to systems that are Internet facing or
have high CIA requirements (instead of defining a profile for "high
security" we might define it for systems that have CIA requirements of
high)?  If an asset management system already knows some of this
information then an integrated scanner could use the data it knows to
automatically determine which items to run (or which items to require in
the case of post processing data with a particular scoring algorithm).
This might be a good place to add an extension point in XCCDF.  If we
could include a generic asset or network schema then we could more
clearly define applicability for each item.  I think we have mentioned
these ideas in past developer days discussions but I'm not sure we have
taken any action.

Jim



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Buttner,
Drew
Sent: Thursday, September 16, 2010 8:22 AM
To: Multiple recipients of list
Subject: XCCDF Profiles within SCAP


I have a question about the use of XCCDF profiles within SCAP content.
800-126 defines the characteristics / requirements of valid SCAP
content.  Does 800-126 place a requirement that profiles shall only
represent different policies that apply to single defined benchmark
platform?  Or can profiles be used to represent a more detailed platform
from a more general benchmark platform?

In other words, is it valid SCAP to have:

Benchmark = Windows
  Profile 1 = Windows XP High Security
  Profile 2 = Windows XP Low Security
  Profile 3 = Windows Vista High Security
  Profile 4 = Windows Vista Low Security
  Profile 5 = Windows 7 High Security
  Profile 6 = Windows 7 Low Security

This is valid under XCCDF, but does 800-126 allow this?  Or does SCAP
require:

Benchmark = Windows XP
  Profile 1 = High Security
  Profile 2 = Low Security

Benchmark = Windows Vista
  Profile 1 = High Security
  Profile 2 = Low Security

Benchmark = Windows 7
  Profile 1 = High Security
  Profile 2 = Low Security

I think the text in section 3.1.1 of 800-126 is where the confusion
lies.  It mentions how "profiles can be used to express multiple polices
within a single benchmark".  Given the example that follows and the FDCC
and USGCB content has been developed, I think that there may be some
confusion as to what is allowed under SCAP regarding profiles.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515



---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe scap-dev" in the body. You

will need to send this from the email account that you used to initially

subscribe to scap-dev.



---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Reply | Threaded
Open this post in threaded view
|

RE: XCCDF Profiles within SCAP

Matthew N. Wojcik

[Pulling in emerging-specs as well, as that's the forum-of-record for work on the Remediation specifications.  Apologies for the cross-post to everybody who's on all three.]

I think there will also be demand for the ability to include such functional tags in the eventual Remediation Policy Language specification.  We're really only at the stage there of collecting proposed requirements, for vetting with the community (come to the Remediation workshop sessions on Wednesday of ITSAC to hear more).  But I can't imagine us *not* wanting the ability to specify the same sort of criteria for target machine types in remediation policy.  So I think we should make sure we work together on considering this proposal.  Though I think it very likely there will be differences in how they're acted on in assessment vs. remediation...

I'm cautiously in favor of this idea of more functional (and hence potentially automatable) descriptions of the targets of assessment and remediation policy.  But I have to caution that we're proposing an attempt to standardize names/IDs for a whole new domain of fuzzily-defined concepts, used differently by different practitioners.  That's true whether we realise it, or acknowledge it!  This is just as complex an area as CVE, CPE, CWE, CRE...you name it.[1]

Humans deal relatively well with the ambiguity in calling a machine a "Domain Controller"...is meant to be a domain controller?  Is it acting as one?  Is it running software that means it's capable of being one?  Do I care whether it's a primary in the context that I said "domain controller"?  In fact, we very often *depend* on that ambiguity to enable our communication.  Computers, of course, deal with it very poorly indeed.  David Mann has done very important work researching this topic and how it applies to the identifier schemes in our standards suites.  Any time we contemplate adding a new standard for identifying something, we should be forced to have a long conversation with him first, to be sure we know what we're getting into. :)

[1] Suggesting "we can add these into an expanded CPE" doesn't make the problem any easier...it probably makes it harder. :)

Cheers,

--Woj                  Matthew N. Wojcik                 [hidden email]
781 271-8056 office                        Remediation Standardization
617 872-6247 mobile                                   CCE Project Lead

TO UNSUBSCRIBE FROM THE EMERGING-SPECS LIST, SEE:
http://scap.nist.gov/community.html


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Ronayne, James K.
> Sent: Thursday, September 16, 2010 9:27 AM
> To: Multiple recipients of list
> Subject: RE: XCCDF Profiles within SCAP
>
>
> I think rev 1 of 800-126 allows the platform tag to be applied to
> profiles, groups, and rules (800-126 r1 sect 4.2.2) instead of just the
> benchmark as required in SCAP 1.0 (800-126 sect 4.1.2).
>
> I think it would be useful to allow additional tags to define the
> applicability of benchmarks, profiles, groups, and rules.  Right now
> any
> applicability statement for these items is limited to the platform tag
> and a string description.  If we were to allow more attributes of these
> items then scanners that might have either collected data or stored
> manually entered data would be in a better position to automatically
> determine which items apply to which target systems.  For example,
> could
> we tag a profile with the target role of domain controller (where DC is
> an actual attribute instead of just free text in the description)?
> Could we tag a profile to apply to systems that are Internet facing or
> have high CIA requirements (instead of defining a profile for "high
> security" we might define it for systems that have CIA requirements of
> high)?  If an asset management system already knows some of this
> information then an integrated scanner could use the data it knows to
> automatically determine which items to run (or which items to require
> in
> the case of post processing data with a particular scoring algorithm).
> This might be a good place to add an extension point in XCCDF.  If we
> could include a generic asset or network schema then we could more
> clearly define applicability for each item.  I think we have mentioned
> these ideas in past developer days discussions but I'm not sure we have
> taken any action.
>
> Jim
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Buttner,
> Drew
> Sent: Thursday, September 16, 2010 8:22 AM
> To: Multiple recipients of list
> Subject: XCCDF Profiles within SCAP
>
>
> I have a question about the use of XCCDF profiles within SCAP content.
> 800-126 defines the characteristics / requirements of valid SCAP
> content.  Does 800-126 place a requirement that profiles shall only
> represent different policies that apply to single defined benchmark
> platform?  Or can profiles be used to represent a more detailed
> platform
> from a more general benchmark platform?
>
> In other words, is it valid SCAP to have:
>
> Benchmark = Windows
>   Profile 1 = Windows XP High Security
>   Profile 2 = Windows XP Low Security
>   Profile 3 = Windows Vista High Security
>   Profile 4 = Windows Vista Low Security
>   Profile 5 = Windows 7 High Security
>   Profile 6 = Windows 7 Low Security
>
> This is valid under XCCDF, but does 800-126 allow this?  Or does SCAP
> require:
>
> Benchmark = Windows XP
>   Profile 1 = High Security
>   Profile 2 = Low Security
>
> Benchmark = Windows Vista
>   Profile 1 = High Security
>   Profile 2 = Low Security
>
> Benchmark = Windows 7
>   Profile 1 = High Security
>   Profile 2 = Low Security
>
> I think the text in section 3.1.1 of 800-126 is where the confusion
> lies.  It mentions how "profiles can be used to express multiple
> polices
> within a single benchmark".  Given the example that follows and the
> FDCC
> and USGCB content has been developed, I think that there may be some
> confusion as to what is allowed under SCAP regarding profiles.
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>
> ---------------------------------------------------------------
>
> To unsubscribe from this mailing list, please send an e-mail to
> [hidden email] with the words "unsubscribe scap-dev" in the body.
> You
>
> will need to send this from the email account that you used to
> initially
>
> subscribe to scap-dev.
>
>
>
> ---------------------------------------------------------------
>
> To unsubscribe from this mailing list, please send an e-mail to
> [hidden email] with the words "unsubscribe scap-dev" in the body.
> You
> will need to send this from the email account that you used to
> initially
> subscribe to scap-dev.



---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Reply | Threaded
Open this post in threaded view
|

RE: XCCDF Profiles within SCAP

Waltermire, David A.

Today we have a CPE Language that defines a statement of applicability based on products/platforms.  It seems to me that there might be a quick win if we could add a new fact type to this language, perhaps through extension, that would allow a check to be executed to examine system state to determine applicability.  Such a change may not require a modifcation to the XCCDF schema/specifcation.  This would address detecting if the system is configured to be a domain controller, but not if it SHOULD be a domain controller.  Organizational intent and other non-system state dependent attributes would require additional standardization that might not be a good fit for XCCDF.  For example, if you wanted to target a checklist to a high-security zone or a collection of hosts, it might make sense to describe this checklist application policy separate from the checklist itself.  That way multiple organizations can target checklists in different ways.  This meta-policy language could al!
 so be used to require that a specific CRE be used to correct a CVE/CCE for specific hosts.  We have been developing an asset identification model which could provide a foundation for such meta-policy language.  We will be discussing this during some of the sessions and workshops at the IT Security Automation Conference (http://scap.nist.gov/events/index.html).

Sincerely,
 
David Waltermire
SCAP Architect
National Institute of Standards and Technology
(301) 975-3390
[hidden email]

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Wojcik, Matthew N.
> Sent: Thursday, September 16, 2010 10:19 AM
> To: Multiple recipients of list
> Subject: RE: XCCDF Profiles within SCAP
>
>
> [Pulling in emerging-specs as well, as that's the forum-of-record for
> work on the Remediation specifications.  Apologies for the cross-post
> to everybody who's on all three.]
>
> I think there will also be demand for the ability to include such
> functional tags in the eventual Remediation Policy Language
> specification.  We're really only at the stage there of collecting
> proposed requirements, for vetting with the community (come to the
> Remediation workshop sessions on Wednesday of ITSAC to hear more).  But
> I can't imagine us *not* wanting the ability to specify the same sort
> of criteria for target machine types in remediation policy.  So I think
> we should make sure we work together on considering this proposal.
> Though I think it very likely there will be differences in how they're
> acted on in assessment vs. remediation...
>
> I'm cautiously in favor of this idea of more functional (and hence
> potentially automatable) descriptions of the targets of assessment and
> remediation policy.  But I have to caution that we're proposing an
> attempt to standardize names/IDs for a whole new domain of fuzzily-
> defined concepts, used differently by different practitioners.  That's
> true whether we realise it, or acknowledge it!  This is just as complex
> an area as CVE, CPE, CWE, CRE...you name it.[1]
>
> Humans deal relatively well with the ambiguity in calling a machine a
> "Domain Controller"...is meant to be a domain controller?  Is it acting
> as one?  Is it running software that means it's capable of being one?
> Do I care whether it's a primary in the context that I said "domain
> controller"?  In fact, we very often *depend* on that ambiguity to
> enable our communication.  Computers, of course, deal with it very
> poorly indeed.  David Mann has done very important work researching
> this topic and how it applies to the identifier schemes in our
> standards suites.  Any time we contemplate adding a new standard for
> identifying something, we should be forced to have a long conversation
> with him first, to be sure we know what we're getting into. :)
>
> [1] Suggesting "we can add these into an expanded CPE" doesn't make the
> problem any easier...it probably makes it harder. :)
>
> Cheers,
>
> --Woj                  Matthew N. Wojcik                 [hidden email]
> 781 271-8056 office                        Remediation Standardization
> 617 872-6247 mobile                                   CCE Project Lead
>
> TO UNSUBSCRIBE FROM THE EMERGING-SPECS LIST, SEE:
> http://scap.nist.gov/community.html
>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On Behalf Of
> > Ronayne, James K.
> > Sent: Thursday, September 16, 2010 9:27 AM
> > To: Multiple recipients of list
> > Subject: RE: XCCDF Profiles within SCAP
> >
> >
> > I think rev 1 of 800-126 allows the platform tag to be applied to
> > profiles, groups, and rules (800-126 r1 sect 4.2.2) instead of just
> the
> > benchmark as required in SCAP 1.0 (800-126 sect 4.1.2).
> >
> > I think it would be useful to allow additional tags to define the
> > applicability of benchmarks, profiles, groups, and rules.  Right now
> > any
> > applicability statement for these items is limited to the platform
> tag
> > and a string description.  If we were to allow more attributes of
> these
> > items then scanners that might have either collected data or stored
> > manually entered data would be in a better position to automatically
> > determine which items apply to which target systems.  For example,
> > could
> > we tag a profile with the target role of domain controller (where DC
> is
> > an actual attribute instead of just free text in the description)?
> > Could we tag a profile to apply to systems that are Internet facing
> or
> > have high CIA requirements (instead of defining a profile for "high
> > security" we might define it for systems that have CIA requirements
> of
> > high)?  If an asset management system already knows some of this
> > information then an integrated scanner could use the data it knows to
> > automatically determine which items to run (or which items to require
> > in
> > the case of post processing data with a particular scoring
> algorithm).
> > This might be a good place to add an extension point in XCCDF.  If we
> > could include a generic asset or network schema then we could more
> > clearly define applicability for each item.  I think we have
> mentioned
> > these ideas in past developer days discussions but I'm not sure we
> have
> > taken any action.
> >
> > Jim
> >
> >
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On Behalf Of
> > Buttner,
> > Drew
> > Sent: Thursday, September 16, 2010 8:22 AM
> > To: Multiple recipients of list
> > Subject: XCCDF Profiles within SCAP
> >
> >
> > I have a question about the use of XCCDF profiles within SCAP
> content.
> > 800-126 defines the characteristics / requirements of valid SCAP
> > content.  Does 800-126 place a requirement that profiles shall only
> > represent different policies that apply to single defined benchmark
> > platform?  Or can profiles be used to represent a more detailed
> > platform
> > from a more general benchmark platform?
> >
> > In other words, is it valid SCAP to have:
> >
> > Benchmark = Windows
> >   Profile 1 = Windows XP High Security
> >   Profile 2 = Windows XP Low Security
> >   Profile 3 = Windows Vista High Security
> >   Profile 4 = Windows Vista Low Security
> >   Profile 5 = Windows 7 High Security
> >   Profile 6 = Windows 7 Low Security
> >
> > This is valid under XCCDF, but does 800-126 allow this?  Or does SCAP
> > require:
> >
> > Benchmark = Windows XP
> >   Profile 1 = High Security
> >   Profile 2 = Low Security
> >
> > Benchmark = Windows Vista
> >   Profile 1 = High Security
> >   Profile 2 = Low Security
> >
> > Benchmark = Windows 7
> >   Profile 1 = High Security
> >   Profile 2 = Low Security
> >
> > I think the text in section 3.1.1 of 800-126 is where the confusion
> > lies.  It mentions how "profiles can be used to express multiple
> > polices
> > within a single benchmark".  Given the example that follows and the
> > FDCC
> > and USGCB content has been developed, I think that there may be some
> > confusion as to what is allowed under SCAP regarding profiles.
> >
> > Thanks
> > Drew
> >
> > ---------
> >
> > Andrew Buttner
> > The MITRE Corporation
> > [hidden email]
> > 781-271-3515
> >
> >
> >
> > ---------------------------------------------------------------
> >
> > To unsubscribe from this mailing list, please send an e-mail to
> > [hidden email] with the words "unsubscribe scap-dev" in the body.
> > You
> >
> > will need to send this from the email account that you used to
> > initially
> >
> > subscribe to scap-dev.
> >
> >
> >
> > ---------------------------------------------------------------
> >
> > To unsubscribe from this mailing list, please send an e-mail to
> > [hidden email] with the words "unsubscribe scap-dev" in the body.
> > You
> > will need to send this from the email account that you used to
> > initially
> > subscribe to scap-dev.
>
>
>
> ---------------------------------------------------------------
>
> To unsubscribe from this mailing list, please send an e-mail to
> [hidden email] with the words "unsubscribe xccdf-dev" in the
> body. You will need to send this from the email account that you
> used to initially subscribe to xccdf-dev.



---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.