Telecon to discuss CPE direction

[Andrew Buttner]

I would like to hold a telecon next Thursday (June 7) at 10AM (EDT).  I
apologize in advance for those on the west coast.  The purpose of this
telecon is to discuss in more detail the open thread on the CPE list
regarding the possibility of splitting CPE into two separate efforts,
one to be a list of common names, the other to be a language used to
create complex custom names.

I will send out a more specific agenda / talking points early next
week.  My intention is to stop the call after an hour, if another call
is needed then we will schedule it, but I don't want this call to run
too long.

Date/Time:  June 07, 2007 at 10:00 AM America/New_York
Length:     60  (minutes)
Meeting ID: 5327

Phone Numbers:
703-983-6338 in Washington DC
781-271-6338 in Bedford, MA
866-648-7367 Toll Free

Toll Free number is for North America callers only.  Other countries
must dial either the Washington or Bedford numbers to attend.

Thanks
Drew

---------

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

[Andrew Buttner]

Just want to remind everyone about the CPE call tomorrow (Thursday) at
10AM EDT.  The purpose for this call is to discuss some proposals that
have been made regarding the CPE Specification.  In general, the
specification has proven to have some holes in it that has made the
creation of names difficult.  I would like to discuss these proposals
and get feedback from the community.

Agenda
------
* review use cases
   - are there others?
* should CPE Names focus on simpler objects
   - i.e. just windows xp instead of windows w/ office installed
   - use a language to create complex names
* tag proposal

>Date/Time:  June 07, 2007 at 10:00 AM America/New_York
>Length:     60  (minutes)
>Meeting ID: 5327
>
>Phone Numbers:
>703-983-6338 in Washington DC
>781-271-6338 in Bedford, MA
>866-648-7367 Toll Free
>
>Toll Free number is for North America callers only.  Other countries
>must dial either the Washington or Bedford numbers to attend.

I have tried to give some details about each topic either below.  If
you have comments before the call, please don't hesitate to send.
Especially if you can think of additional use cases.  Thanks!



===============
== USE CASES ==
===============

1) One tool marks a statement/result as applicable to a certain type of
platform(s).  A second tool imports the statement/result and takes a
specific action based on the type of platform(s).  The second tool must
be able to understand what the first tool is 'saying' regarding the
platform type so it can know which action to perform.

2) A specific CPE Name is determined for an actual system.  This name
is then used to determine if other names 'match'.  For instance, a
guide might only be applicable for all versions of a platform and be
assigned a CPE Name that represents this.  A tool might query a system
and determine a more specific CPE Name that includes an exact version.
When the guide is evaluated, the tool must be able to determine that
the CPE Name of the system is a member of the more general CPE Name
assigned to the guide.  This use case keeps us from having to list a
large number of CPE Names for each guide, instead we can just list a
single high-level name.




====================
== SIMPLER OBJECT ==
====================

A lot of the problems that we are running into regards complex platform
types.  Things like names with multiple applications, or statements
that OR applications, or those requiring earlier than or later than
logic.  To solve this, it was proposed to split CPE into an enumeration
for simple platform types, and a language for combining those
enumeration together to form complex platform statements.  The goal is
that by limiting the enumeration to simple platform types (names like
'Red Hat Enterprise Linux 5' or 'Intel Pentium') that we can do a
better job of creating a spec that is easy to follow.  For example,
right now there is no direction about what order to use when defining a
platform type with multiple applications.  Both cpe:///IE7;office2003
and cpe:///office2003;IE7 are valid.  Which one is official?





==================
== TAG PROPOSAL ==
==================

An even grander proposal that has been made is to change the CPE Name
to represent a list of tags and their values.  The goal of this would
be remove the dependency of a hierarchy (you can use any applicable
tag, not bound to a specific order) and also to allow the expression of
the CPE Name to take many different forms.  For those that need to use
strings there is a URI expression, for those that need XML there is an
XML expression, etc.  Of course users will have to agree on the
expression they will use before communicating.

This would be a radical shift in CPE.  What are people's initial
reactions to it?


CPE Name
--------------
A collection of applicable name/value pairs representing information
about the platform type.  For example:

    type: operating_system
    vendor: microsoft
    product: windows
    major_version: 5
    minor_version: 1


CPE Dictionary
---------------
The dictionary would be a collection of known platform types and their
associated name/value tags.  The CPE Dictionary would be used to
provide additional information about a particular CPE.  A CPE does not
have to be in the dictionary to be used, think of a new platform that
has different values for the tags.  But by adding a CPE to the
dictionary, we keep a central repository about information related to
that CPE.

    id (CPE-123)
    title  (Microsoft Windows XP)
    collection of tags
    references (OVAL definition)


CPE Expression
---------------
A representation of the CPE Name for use in exchanging the name between
tools.  It is possible to express the name in different formats with
the CPE Specification defining how to build each.  For example:

   URI:

 
cpe:type=operating_system&vendor=microsoft&product=windows&major_versio
n&5&minor_version=1

   XML:

      <cpe>
        <type>operating_system</type>
        <vendor>microsoft</vendor>
        <product>windows</product>
        <major_version>5</major_version>
        <minor_version>1</minor_version>
      <cpe>

   ID:

      CPE-123

Note that the ID expression would require the use of the dictionary to
look up what that CPE represented.


CPE Language
--------------
A simple language (XML) used to build complex platform types.  Provides
a means for combining CPE Names using logical operators.  Enables
statements like "Intel Pentium with Microsoft Windows XP and Adobe
Reader installed".  This language would be based around some of the old
XCCDF-P markup, obviously need to think about the exact structure some
more:

    <platform>
                <title></title>
                <logical-test operator="AND" negate="0">
                        <fact-ref cpe_name=""/>
                        <fact-ref cpe_name=""/>
                </logical-test>
        </platform>


CPE Matching
--------------
The process of determining if a given name is contained by another
name.  Matching could be done either between different collections of
tags, or between tags and a complex name defined by the language, or
between two complex names each defined by the language.




---------

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

[Tim Erlin-2]

Drew,

I plan on attending this call. Just FYI.

--Tim Erlin

Buttner, Drew wrote:

> Just want to remind everyone about the CPE call tomorrow (Thursday) at
> 10AM EDT.  The purpose for this call is to discuss some proposals that
> have been made regarding the CPE Specification.  In general, the
> specification has proven to have some holes in it that has made the
> creation of names difficult.  I would like to discuss these proposals
> and get feedback from the community.
>
> Agenda
> ------
> * review use cases
>    - are there others?
> * should CPE Names focus on simpler objects
>    - i.e. just windows xp instead of windows w/ office installed
>    - use a language to create complex names
> * tag proposal
>
>
>
>> Date/Time:  June 07, 2007 at 10:00 AM America/New_York
>> Length:     60  (minutes)
>> Meeting ID: 5327
>>
>> Phone Numbers:
>> 703-983-6338 in Washington DC
>> 781-271-6338 in Bedford, MA
>> 866-648-7367 Toll Free
>>
>> Toll Free number is for North America callers only.  Other countries
>> must dial either the Washington or Bedford numbers to attend.
>
>
>
> I have tried to give some details about each topic either below.  If
> you have comments before the call, please don't hesitate to send.
> Especially if you can think of additional use cases.  Thanks!
>
>
>
> ===============
> == USE CASES ==
> ===============
>
> 1) One tool marks a statement/result as applicable to a certain type of
> platform(s).  A second tool imports the statement/result and takes a
> specific action based on the type of platform(s).  The second tool must
> be able to understand what the first tool is 'saying' regarding the
> platform type so it can know which action to perform.
>
> 2) A specific CPE Name is determined for an actual system.  This name
> is then used to determine if other names 'match'.  For instance, a
> guide might only be applicable for all versions of a platform and be
> assigned a CPE Name that represents this.  A tool might query a system
> and determine a more specific CPE Name that includes an exact version.
> When the guide is evaluated, the tool must be able to determine that
> the CPE Name of the system is a member of the more general CPE Name
> assigned to the guide.  This use case keeps us from having to list a
> large number of CPE Names for each guide, instead we can just list a
> single high-level name.
>
>
>
>
> ====================
> == SIMPLER OBJECT ==
> ====================
>
> A lot of the problems that we are running into regards complex platform
> types.  Things like names with multiple applications, or statements
> that OR applications, or those requiring earlier than or later than
> logic.  To solve this, it was proposed to split CPE into an enumeration
> for simple platform types, and a language for combining those
> enumeration together to form complex platform statements.  The goal is
> that by limiting the enumeration to simple platform types (names like
> 'Red Hat Enterprise Linux 5' or 'Intel Pentium') that we can do a
> better job of creating a spec that is easy to follow.  For example,
> right now there is no direction about what order to use when defining a
> platform type with multiple applications.  Both cpe:///IE7;office2003
> and cpe:///office2003;IE7 are valid.  Which one is official?
>
>
>
>
>
> ==================
> == TAG PROPOSAL ==
> ==================
>
> An even grander proposal that has been made is to change the CPE Name
> to represent a list of tags and their values.  The goal of this would
> be remove the dependency of a hierarchy (you can use any applicable
> tag, not bound to a specific order) and also to allow the expression of
> the CPE Name to take many different forms.  For those that need to use
> strings there is a URI expression, for those that need XML there is an
> XML expression, etc.  Of course users will have to agree on the
> expression they will use before communicating.
>
> This would be a radical shift in CPE.  What are people's initial
> reactions to it?
>
>
> CPE Name
> --------------
> A collection of applicable name/value pairs representing information
> about the platform type.  For example:
>
>     type: operating_system
>     vendor: microsoft
>     product: windows
>     major_version: 5
>     minor_version: 1
>
>
> CPE Dictionary
> ---------------
> The dictionary would be a collection of known platform types and their
> associated name/value tags.  The CPE Dictionary would be used to
> provide additional information about a particular CPE.  A CPE does not
> have to be in the dictionary to be used, think of a new platform that
> has different values for the tags.  But by adding a CPE to the
> dictionary, we keep a central repository about information related to
> that CPE.
>
>     id (CPE-123)
>     title  (Microsoft Windows XP)
>     collection of tags
>     references (OVAL definition)
>
>
> CPE Expression
> ---------------
> A representation of the CPE Name for use in exchanging the name between
> tools.  It is possible to express the name in different formats with
> the CPE Specification defining how to build each.  For example:
>
>    URI:
>
>  
> cpe:type=operating_system&vendor=microsoft&product=windows&major_versio
> n&5&minor_version=1
>
>    XML:
>
>       <cpe>
>         <type>operating_system</type>
>         <vendor>microsoft</vendor>
>         <product>windows</product>
>         <major_version>5</major_version>
>         <minor_version>1</minor_version>
>       <cpe>
>
>    ID:
>
>       CPE-123
>
> Note that the ID expression would require the use of the dictionary to
> look up what that CPE represented.
>
>
> CPE Language
> --------------
> A simple language (XML) used to build complex platform types.  Provides
> a means for combining CPE Names using logical operators.  Enables
> statements like "Intel Pentium with Microsoft Windows XP and Adobe
> Reader installed".  This language would be based around some of the old
> XCCDF-P markup, obviously need to think about the exact structure some
> more:
>
>     <platform>
> <title></title>
> <logical-test operator="AND" negate="0">
> <fact-ref cpe_name=""/>
> <fact-ref cpe_name=""/>
> </logical-test>
> </platform>
>
>
> CPE Matching
> --------------
> The process of determining if a given name is contained by another
> name.  Matching could be done either between different collections of
> tags, or between tags and a complex name defined by the language, or
> between two complex names each defined by the language.
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515

--
------------------------------
-| Tim Erlin, CISSP
-| Principal Product Manager
-| nCircle Network Security
-| 101 2nd Street, Suite 400
-| San Francisco, CA 94105
-| Office: [phone]
-| www.ncircle.com
-| blog.ncircle.com
-------------------------------

[Andrew Buttner]

Thank you again for those that attended the CPE telecon today.  Below
is a list of attendees and a short summary of what was discussed.


Attendees
--------------------------------------

Kent Landfield - McAfee
Scott Carpenter - Secure Elements
Ken Lassesen - Patchlink
Gary Gaplinski - NASA
Tim Erlin - nCircle
TK Keanini - nCircle
Jay Graver - nCircle
Sheldon Malm - nCircle
Neal Ziring - DOD
Joe Wolfkiel - DOD
Jim Ronayne - DOD
Dave Waltermire - Booz Allen
Roy Cavender - JTFGNO
Drew Buttner - MITRE
Jon Baker - MITRE
Matt Wojik - MITRE
Matt Burton - MITRE



Notes
-----------------------------------------

** Opened with a review of existing 2 use cases.  It was noted that
these should be added to the specification as a new section.

- A comment about the language of a particular platform was made.  When
dealing with patching applications, it is important to be able to call
out which language the platform supports or is intended for.  It was
agreed that this should be added to the requirements section of the
specification.

** Conversation shifted to a discussion about splitting CPE into an
enumeration of simple platform types and a language for complex
platform types.  The basic conflict in the current spec is between the
need to keep the enumeration simple and the need to express complex
platforms.

- In general there was support for this move.  Simplifying the
enumeration piece will allow us to move forward in creation a rich
dictionary of CPE Names.  This will also allow CPE to eliminate some of
the trouble spots with the current spec.

- The language to be added will be based off of the work done in
XCCDF-P.

** The last topic of conversation was regarding the "tag proposal".
The general consensus was that we should avoid making radical changes
to the current spec as there is a short term need in the community for
CPE and we have a solution that meet 80% of this need.  Let's solidify
the current spec before exploring extreme modifications.

- There was support for looking further into this proposal at a later
date though.


---------

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

[Sheldon Malm]

Drew: thanks for putting the call together today.  We got together at
the nCircle offices after the call for some candid discussion among the
4 of us.  The consensus (among other items) was that it was a very
productive meeting that should help the effort move forward while some
of the more complex items are sorted out by the group over time.  I'm
sure TK will address this in more depth in his response.

One item that we discussed after the call was the notion of community
and how the separation of simple and complex objects should give a
positive feedback loop in a more community-based process.  

Essentially, we agree that the simple objects should be more like a
"taxonomy" or categorization approach as was supported in the call
today.  This gives a stable basis for members of the community
(including nCircle) to build on without tearing down and building up ad
nauseum.  This is key, given that so many of us have practical uses for
this today.

We also agree that the language-based approach to the more complex
objects makes more sense.  When you get outside of the basic elements,
it is impossible to be all things to all people (or attempt to enumerate
an infinite set, as someone on the call mentioned a couple of times).
This is where I see the largest value to the community-based approach -
not warm and fuzzy community per se, but one driven by need, expertise,
and a willingness to contribute.  As customization is required to meet a
specific need for complex objects (let's say for interoperability
between IP360 and another vendor solution), we as a participant have 2
options:
- write the customization for exclusive use and keep it between us and
our partner(s)
- make it available to the community for reuse where applicable

If we make it available to the community, it may become a defacto
standard because of our initiative or it may be stored in a library of
available, optional components that allow a subscribe/unsubscribe
approach to use/non-use.  This can be determined over time, by the
community, and does not need to hold up the process of advancing and
institutionalizing the core standard.  If we choose to not share it with
the community, we run the risk of a new standard for this purpose being
written, thus potentially obsoleting our customization.  This is the
positive feedback loop that we believe is required in the "complex
object" portion.

We are also in agreement about the need to support multiple
representations.  I believe the two that were highlighted on the call
were xml-based and string-based representations.  This is reminiscent of
SDDL in Microsoft technologies, which allows one to easily represent
more complex data in a string format for consumption by tools such as
IP360.

Finally (from my feedback), we're looking forward to exploring the
tagging option at some time in the future.  While we do not necessarily
believe that it is required for the simple objects, this is an option
for the complex objects that has a lot of potential.

Sincere thanks to everyone else on the call today.  This was an
excellent discussion that brought much more resolution that I was
expecting.



Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, June 07, 2007 1:28 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

Thank you again for those that attended the CPE telecon today.  Below is
a list of attendees and a short summary of what was discussed.


Attendees
--------------------------------------

Kent Landfield - McAfee
Scott Carpenter - Secure Elements
Ken Lassesen - Patchlink
Gary Gaplinski - NASA
Tim Erlin - nCircle
TK Keanini - nCircle
Jay Graver - nCircle
Sheldon Malm - nCircle
Neal Ziring - DOD
Joe Wolfkiel - DOD
Jim Ronayne - DOD
Dave Waltermire - Booz Allen
Roy Cavender - JTFGNO
Drew Buttner - MITRE
Jon Baker - MITRE
Matt Wojik - MITRE
Matt Burton - MITRE



Notes
-----------------------------------------

** Opened with a review of existing 2 use cases.  It was noted that
these should be added to the specification as a new section.

- A comment about the language of a particular platform was made.  When
dealing with patching applications, it is important to be able to call
out which language the platform supports or is intended for.  It was
agreed that this should be added to the requirements section of the
specification.

** Conversation shifted to a discussion about splitting CPE into an
enumeration of simple platform types and a language for complex platform
types.  The basic conflict in the current spec is between the need to
keep the enumeration simple and the need to express complex platforms.

- In general there was support for this move.  Simplifying the
enumeration piece will allow us to move forward in creation a rich
dictionary of CPE Names.  This will also allow CPE to eliminate some of
the trouble spots with the current spec.

- The language to be added will be based off of the work done in
XCCDF-P.

** The last topic of conversation was regarding the "tag proposal".
The general consensus was that we should avoid making radical changes to
the current spec as there is a short term need in the community for CPE
and we have a solution that meet 80% of this need.  Let's solidify the
current spec before exploring extreme modifications.

- There was support for looking further into this proposal at a later
date though.


---------

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

[Ken Lassesen-2]

from us here too, thanks.

For the basic items, if there is a requirement that an OVAL definition
be required to provide precise clarity  on what is being referred to
there are multiple paybacks:
* With an evolution (i.e. next major version) of OVAL, the OS specific
tests could be dropped from the test section in many cases, and the
CPE's listed in the definition would be implicitly included in the
testing -- in complex cases, the test could be a 'cpe_test'. This would
allow filtering of tests by specific OS reliably (and mechanically!) -
at present the mechanisms in OVAL for filtering reliably is just
available at the highest level of OS(i.e. Windows, Mac OS ). To us,
filtering the definitions reduces the number of tests that need to be
performed (thus reducing client load, and time to execute the test).

* Some items may need a touch of clarity, for example, to see it is
Windows (all dialects), I suspect that the definition may be just
checking for something silly in the Windows name space [same apply to
the other OS's for the very top most layer].
* If the definitions are well done (minimial, consistant with reuse),
then hierarchies between items can be inferred by just examining the
tests. i.e. cpe-A uses  test A1, cpe-B uses test A1 And A2, thus CPE-A
includes (parent of ) CPE-B etc. This would be strict, demonstratable
and clear with parsing the test logic determining the appropriate
hierachical (or relational) placement of any item.

Many thanks again

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Thursday, June 07, 2007 8:59 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

Drew: thanks for putting the call together today.  

[Sheldon Malm]

This was another discussion point for us, Ken.  We get the importance
and value of OVAL, we just don't agree that the OVAL definition should
be a requirement.  Perhaps we're closer on this than it seems.  We
believe that OVAL checks enable detection and help to describe the
definition, but don't agree that they are *required* in the strictest
sense.  

I would hate to see important items lag in CPE enumeration because the
OVAL definitions have not been completed.  If something "must be able to
be described in OVAL" to have a CPE, then I agree with you.  If the
development and release of an OVAL test is in the workflow as a required
componenet before a CPE is created, then I disagree.

 


Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Friday, June 08, 2007 9:34 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

from us here too, thanks.

For the basic items, if there is a requirement that an OVAL definition
be required to provide precise clarity  on what is being referred to
there are multiple paybacks:
* With an evolution (i.e. next major version) of OVAL, the OS specific
tests could be dropped from the test section in many cases, and the
CPE's listed in the definition would be implicitly included in the
testing -- in complex cases, the test could be a 'cpe_test'. This would
allow filtering of tests by specific OS reliably (and mechanically!) -
at present the mechanisms in OVAL for filtering reliably is just
available at the highest level of OS(i.e. Windows, Mac OS ). To us,
filtering the definitions reduces the number of tests that need to be
performed (thus reducing client load, and time to execute the test).

* Some items may need a touch of clarity, for example, to see it is
Windows (all dialects), I suspect that the definition may be just
checking for something silly in the Windows name space [same apply to
the other OS's for the very top most layer].
* If the definitions are well done (minimial, consistant with reuse),
then hierarchies between items can be inferred by just examining the
tests. i.e. cpe-A uses  test A1, cpe-B uses test A1 And A2, thus CPE-A
includes (parent of ) CPE-B etc. This would be strict, demonstratable
and clear with parsing the test logic determining the appropriate
hierachical (or relational) placement of any item.

Many thanks again

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email] mailto:[hidden email]
CONFIDENTIALITY NOTICE The information contained in this electronic
message may contain confidential and privileged information and is
intended only for use by the individual(s) or entity(ies) to whom it was
addressed. Any unauthorized review, use, disclosure, or distribution of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Thursday, June 07, 2007 8:59 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

Drew: thanks for putting the call together today.  

[Ken Lassesen-2]

Let us change it to 'strongly encouraged'. It is not required to
issue/define a CPE, but it should be assumed that an OVAL definition
would be promptly created (by any party -- the definition should be
submited to the OVAL repository and become 'public domain'). More
important, once an OVAL definition ID is assigned, it is fixed (i.e.
corrections are done in the OVAL definition to match the CPE intent).

Does that work for you?

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Friday, June 08, 2007 7:13 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

This was another discussion point for us, Ken.  We get the importance
and value of OVAL, we just don't agree that the OVAL definition should
be a requirement.  Perhaps we're closer on this than it seems.  We
believe that OVAL checks enable detection and help to describe the
definition, but don't agree that they are *required* in the strictest
sense.  

I would hate to see important items lag in CPE enumeration because the
OVAL definitions have not been completed.  If something "must be able to
be described in OVAL" to have a CPE, then I agree with you.  If the
development and release of an OVAL test is in the workflow as a required
componenet before a CPE is created, then I disagree.

 


Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Friday, June 08, 2007 9:34 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

from us here too, thanks.

For the basic items, if there is a requirement that an OVAL definition
be required to provide precise clarity  on what is being referred to
there are multiple paybacks:
* With an evolution (i.e. next major version) of OVAL, the OS specific
tests could be dropped from the test section in many cases, and the
CPE's listed in the definition would be implicitly included in the
testing -- in complex cases, the test could be a 'cpe_test'. This would
allow filtering of tests by specific OS reliably (and mechanically!) -
at present the mechanisms in OVAL for filtering reliably is just
available at the highest level of OS(i.e. Windows, Mac OS ). To us,
filtering the definitions reduces the number of tests that need to be
performed (thus reducing client load, and time to execute the test).

* Some items may need a touch of clarity, for example, to see it is
Windows (all dialects), I suspect that the definition may be just
checking for something silly in the Windows name space [same apply to
the other OS's for the very top most layer].
* If the definitions are well done (minimial, consistant with reuse),
then hierarchies between items can be inferred by just examining the
tests. i.e. cpe-A uses  test A1, cpe-B uses test A1 And A2, thus CPE-A
includes (parent of ) CPE-B etc. This would be strict, demonstratable
and clear with parsing the test logic determining the appropriate
hierachical (or relational) placement of any item.

Many thanks again

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email] mailto:[hidden email]
CONFIDENTIALITY NOTICE The information contained in this electronic
message may contain confidential and privileged information and is
intended only for use by the individual(s) or entity(ies) to whom it was
addressed. Any unauthorized review, use, disclosure, or distribution of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Thursday, June 07, 2007 8:59 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

Drew: thanks for putting the call together today.  

[Sheldon Malm]

That is perfect.  Thanks Ken.


Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Friday, June 08, 2007 10:34 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

Let us change it to 'strongly encouraged'. It is not required to
issue/define a CPE, but it should be assumed that an OVAL definition
would be promptly created (by any party -- the definition should be
submited to the OVAL repository and become 'public domain'). More
important, once an OVAL definition ID is assigned, it is fixed (i.e.
corrections are done in the OVAL definition to match the CPE intent).

Does that work for you?

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email] mailto:[hidden email]
CONFIDENTIALITY NOTICE The information contained in this electronic
message may contain confidential and privileged information and is
intended only for use by the individual(s) or entity(ies) to whom it was
addressed. Any unauthorized review, use, disclosure, or distribution of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Friday, June 08, 2007 7:13 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

This was another discussion point for us, Ken.  We get the importance
and value of OVAL, we just don't agree that the OVAL definition should
be a requirement.  Perhaps we're closer on this than it seems.  We
believe that OVAL checks enable detection and help to describe the
definition, but don't agree that they are *required* in the strictest
sense.  

I would hate to see important items lag in CPE enumeration because the
OVAL definitions have not been completed.  If something "must be able to
be described in OVAL" to have a CPE, then I agree with you.  If the
development and release of an OVAL test is in the workflow as a required
componenet before a CPE is created, then I disagree.

 


Sheldon Malm
Director
Security Research & Development
nCircle VERT

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: Ken Lassesen [mailto:[hidden email]]
Sent: Friday, June 08, 2007 9:34 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

from us here too, thanks.

For the basic items, if there is a requirement that an OVAL definition
be required to provide precise clarity  on what is being referred to
there are multiple paybacks:
* With an evolution (i.e. next major version) of OVAL, the OS specific
tests could be dropped from the test section in many cases, and the
CPE's listed in the definition would be implicitly included in the
testing -- in complex cases, the test could be a 'cpe_test'. This would
allow filtering of tests by specific OS reliably (and mechanically!) -
at present the mechanisms in OVAL for filtering reliably is just
available at the highest level of OS(i.e. Windows, Mac OS ). To us,
filtering the definitions reduces the number of tests that need to be
performed (thus reducing client load, and time to execute the test).

* Some items may need a touch of clarity, for example, to see it is
Windows (all dialects), I suspect that the definition may be just
checking for something silly in the Windows name space [same apply to
the other OS's for the very top most layer].
* If the definitions are well done (minimial, consistant with reuse),
then hierarchies between items can be inferred by just examining the
tests. i.e. cpe-A uses  test A1, cpe-B uses test A1 And A2, thus CPE-A
includes (parent of ) CPE-B etc. This would be strict, demonstratable
and clear with parsing the test logic determining the appropriate
hierachical (or relational) placement of any item.

Many thanks again

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email] mailto:[hidden email]
CONFIDENTIALITY NOTICE The information contained in this electronic
message may contain confidential and privileged information and is
intended only for use by the individual(s) or entity(ies) to whom it was
addressed. Any unauthorized review, use, disclosure, or distribution of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Sheldon Malm [mailto:[hidden email]]
Sent: Thursday, June 07, 2007 8:59 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction

Drew: thanks for putting the call together today.  

[Andrew Buttner]

This is the path that is currently taken.  We recognize the connection
between OVAL and CPE and would love in an ideal world to have an OVAL
Definition for every CPE.  But we know that the creation of such
content would slow things down.  So instead, the position is that if an
OVAL Definition exists, we have a place to reference it, but a new CPE
can be created in the absence of one.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, June 08, 2007 10:34 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction
>
>Let us change it to 'strongly encouraged'. It is not required to
>issue/define a CPE, but it should be assumed that an OVAL definition
>would be promptly created (by any party -- the definition should be
>submited to the OVAL repository and become 'public domain'). More
>important, once an OVAL definition ID is assigned, it is fixed (i.e.
>corrections are done in the OVAL definition to match the CPE intent).
>
>Does that work for you?
>
>Ken Lassesen,
>HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
>IM: [hidden email]  [hidden email]
>mailto:[hidden email]
>CONFIDENTIALITY NOTICE
>The information contained in this electronic message may contain
>confidential and privileged information and is intended only for use

by

>the individual(s) or entity(ies) to whom it was addressed. Any
>unauthorized review, use, disclosure, or distribution of this
>communication is strictly prohibited. If you are not the intended
>recipient, please contact the sender by reply email and permanently
>delete and destroy the original message.
>
>
>-----Original Message-----
>From: Sheldon Malm [mailto:[hidden email]]
>Sent: Friday, June 08, 2007 7:13 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction
>
>This was another discussion point for us, Ken.  We get the importance
>and value of OVAL, we just don't agree that the OVAL definition should
>be a requirement.  Perhaps we're closer on this than it seems.  We
>believe that OVAL checks enable detection and help to describe the
>definition, but don't agree that they are *required* in the strictest
>sense.  
>
>I would hate to see important items lag in CPE enumeration because the
>OVAL definitions have not been completed.  If something "must
>be able to
>be described in OVAL" to have a CPE, then I agree with you.  If the
>development and release of an OVAL test is in the workflow as
>a required
>componenet before a CPE is created, then I disagree.
>
>  
>
>
>Sheldon Malm
>Director
>Security Research & Development
>nCircle VERT
>
>Check out the VERT daily post
>http://blog.ncircle.com/vert
>
>
>
>-----Original Message-----
>From: Ken Lassesen [mailto:[hidden email]]
>Sent: Friday, June 08, 2007 9:34 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction
>
>From us here too, thanks.
>
>For the basic items, if there is a requirement that an OVAL definition
>be required to provide precise clarity  on what is being referred to
>there are multiple paybacks:
>* With an evolution (i.e. next major version) of OVAL, the OS specific
>tests could be dropped from the test section in many cases, and the
>CPE's listed in the definition would be implicitly included in the
>testing -- in complex cases, the test could be a 'cpe_test'. This

would

>allow filtering of tests by specific OS reliably (and mechanically!) -
>at present the mechanisms in OVAL for filtering reliably is just
>available at the highest level of OS(i.e. Windows, Mac OS ). To us,
>filtering the definitions reduces the number of tests that need to be
>performed (thus reducing client load, and time to execute the test).
>
>* Some items may need a touch of clarity, for example, to see it is
>Windows (all dialects), I suspect that the definition may be just
>checking for something silly in the Windows name space [same apply to
>the other OS's for the very top most layer].
>* If the definitions are well done (minimial, consistant with reuse),
>then hierarchies between items can be inferred by just examining the
>tests. i.e. cpe-A uses  test A1, cpe-B uses test A1 And A2, thus CPE-A
>includes (parent of ) CPE-B etc. This would be strict, demonstratable
>and clear with parsing the test logic determining the appropriate
>hierachical (or relational) placement of any item.
>
>Many thanks again
>
>Ken Lassesen,
>HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
>IM: [hidden email]  [hidden email] mailto:[hidden email]
>CONFIDENTIALITY NOTICE The information contained in this electronic
>message may contain confidential and privileged information and is
>intended only for use by the individual(s) or entity(ies) to
>whom it was
>addressed. Any unauthorized review, use, disclosure, or distribution

of

>this communication is strictly prohibited. If you are not the intended
>recipient, please contact the sender by reply email and permanently
>delete and destroy the original message.
>
>
>-----Original Message-----
>From: Sheldon Malm [mailto:[hidden email]]
>Sent: Thursday, June 07, 2007 8:59 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Telecon to discuss CPE direction
>
>Drew: thanks for putting the call together today.  
>