James Hansen quoted the CCE Overview paper then asserted:
>> "In general, the scope of CCE-IDs is determined by the ability of an
> automated process to check the parameter of a particular configuration
> issue. For example, if a configuration statement can be verified by an
> assessment tool or applied by configuration management system, it
> should be assigned a CCE-ID."
>> Checking for existence of P2P software satisfies each element of
>> this definition.
To which, Joe Wolfkiel replied:
> My original thought would be that the ID would be a CPE
> ID, not a CCE ID.
I agree with Joe and with Woj on this.
Statements of this kind should (potentially) be associated with
CPE IDs or CCIs (forth coming from DISA?)
Unfortunately (for me since I wrote it), the pasage from
the CCE paper is a bit vague and open to interpretation.
The context that I was attempting to achieve but didn't
was that "assessment" here meant "configuration assessment".
Indeed, there is a whole host of things that can be assessed
given that you have credentialed access to a system, including
but not limited to: patches, software inventory, vulnerabilities,
configurations, user rights, malware and so forth.
CCE can not create IDs for all things that can be verified by
all credentialed assessment tools.
Note, there is underlaying ambiguity about what constitutes a
"platform" or "system" (single installable product or a combination
of products) and what constitutes a "configuration issue"
For CCE, we define system as a platform group. Relative to this
a control is any configurable aspect of that platform group
as defined by what ships in its standard distribution.
For some platform groups, like Red Hat EL5 or Windows Server 2008,
some components or packages can be installed or not as a part of
the configuration management *of that platform group* (as distinct
from a business system which may include other packages installed
in conjunction with the base OS). In these cases, we have
created CCEs of the form "The [such and such package] should be
installed as appropriate". Observe that in this context,
the version of the package is somewhat ambiguous and not
much can be asserted beyond the version that ships with the
But in general, statements of the form "The [such and such product]
should be installed as appropriate." have been excluded from CCE.
I would suggest that the creation of IDs for such statements
could follow 2 paths based on intended usage and level of abstraction.
If the goal is to say something along the lines of "Allow or disallow
any and all P2P programs as appropriate.", then this is similar
to a statement like "Have strong passwords." This sounds to me
like what DISA has been talking about for CCI -- harmonizing
higher level policy statements.
If the goal is to say something like "Bittorrent v1.2 should
not be installed", then I think this gets tagged with a CPE.
HUGE CAVEAT - this assumes that CPE can be used to identify
an installable piece of software. How this can be achieved
remains a point of discussion in the CPE Working Group.
If the goal here is to create white list/black list
for P2P (or any other software type), I would suggest
moving the discussion to the cpe list.
David Mann | CVE & CCE Project | The MITRE Corporation
e-mail:[hidden email] | cell:781.424.6003
|Free forum by Nabble||Edit this page|