Subject: Re: [sacm] Status Update Request

From: Tim Keanini <[email-masked]>
Date: Mon, 9 Apr 2012 13:14:07 -0700

We will certainly need a few ascii diagrams so let me share this link:
http://www.asciiflow.com/

--tk

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Monday, April 09, 2012 2:04 PM
To: Adam Montville; [email-masked]'
Subject: Re: [sacm] Status Update Request

I can take a stab at that.  It will be useful at minimum to start some
discussion.
Dave

> -----Original Message-----
> From: Adam Montville [mailto:[email-masked]]
> Sent: Monday, April 09, 2012 2:48 PM
> To: Waltermire, David A.; [email-masked]'
> Subject: Re: Status Update Request
> 
> Hi Dave,
> 
> Thanks for sending this out.  I like the abstract and the structure of

> the document so far, so no further comments from me on the abstract.
> Are you planning to create a first pass at a complete list of use 
> cases for the document?
> 
> Adam
> 
> On 4/9/12 11:41 AM, "Waltermire, David A." <[email-masked]>
> wrote:
> 
> >Please find a skeleton I-D of the use case document attached with 
> >updates to the abstract based on the feedback to date.  If there are
> no
> >other comments on the abstract I'll start work on the introduction 
> >and we can start breaking out use cases and authors for each use
case.
> >
> >Sincerely,
> >Dave
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Adam Montville
> >> Sent: Monday, April 09, 2012 2:33 PM
> >> To: [email-masked]'
> >> Subject: [sacm] Status Update Request
> >>
> >> All:
> >>
> >> The list seems to be rather quiet since the close of IETF 83 more 
> >> than a week ago.  Actions coming out of the side meeting held on 
> >> March 24
> >> included:
> >>
> >> 1. Use Case document first draft by middle of April 2. Use Case 
> >> initial revision by end of April 3. Start of a charter discussion 
> >> around middle of April (after first draft Use Case release)
> >>
> >> Dave Waltermire has offered to lead development of the Use Case 
> >> document and Kent Landfield has offered to lead the subsequent 
> >> charter discussion.
> >>
> >> Dave/Kent: Do either of you have an update you can share?
> >>
> >> Adam
> >>
> >>
> >>
> >> _______________________________________________
> >> sacm mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sacm
> 

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 9 Apr 2012 16:22:25 -0400

I wish someone would have told me this 14 RFCs ago....

Tim
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Tim Keanini [[email-masked]]
Sent: Monday, April 09, 2012 4:14 PM
To: Waltermire, David A.; Adam Montville; [email-masked]
Subject: Re: [sacm] Status Update Request

--tk

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

case.

---

From: <[email-masked]>
Date: Mon, 9 Apr 2012 15:43:02 -0500

What do you know….  SACM is already being valuable. ;-)

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: "Polk, William T." <[email-masked]<mailto:[email-masked]>>
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini <[email-masked]<mailto:[email-masked]>>, David Waltermire <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Status Update Request

Tim
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Tim Keanini [[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 09, 2012 4:14 PM
To: Waltermire, David A.; Adam Montville; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Status Update Request

--tk

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Monday, April 09, 2012 2:04 PM
To: Adam Montville; [email-masked]<mailto:[email-masked]>'
Subject: Re: [sacm] Status Update Request

-----Original Message-----
From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; [email-masked]<mailto:[email-masked]>'
Subject: Re: Status Update Request

Hi Dave,

Adam

no
case.
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
>> Behalf Of Adam Montville
>> To: [email-masked]<mailto:[email-masked]>'
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: <[email-masked]>
Date: Mon, 9 Apr 2012 18:05:04 -0400

Wow, I wish I knew about that sooner as well.

Thanks, TK!

Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, April 09, 2012 4:43 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Status Update Request

What do you know....  SACM is already being valuable. ;-)

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Tim

--tk

-----Original Message-----
From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; [email-masked]<mailto:[email-masked]>'
Subject: Re: Status Update Request

Hi Dave,

Adam

no
case.

---

From: David Solin <[email-masked]>
Date: Mon, 09 Apr 2012 17:38:23 -0500

That is very neat, but I also have a question on the original topic...

Was there any discussion at the meeting in Paris on Asset Identification 
vs. CIM, or has anyone identified a use-case for AI for which CIM is not 
appropriate?  For the sake of making SACM easily adoptable by large 
enterprises with existing CMDB implementations, I strongly advocate 
abandoning AI in favor of CIM.  I'd be happy to discuss how BMC, IBM, 
HP, CA, etc. have been making CIM the centerpiece of their systems 
management offerings for most of the past decade.

Regards,
--David Solin

-- 

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

On 4/9/2012 3:43 PM, [email-masked] wrote:
> *Kent Landfield*
> *McAfee | An Intel Company*
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> To: Tim Keanini <[email-masked] <mailto:[email-masked]>>, 
> David Waltermire <[email-masked] 
> <mailto:[email-masked]>>, Adam Montville 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     From: [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] On Behalf
>     Of Tim Keanini [[email-masked] <mailto:[email-masked]>]
>     <mailto:[email-masked]>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] On Behalf Of
>     Waltermire, David A.
>     To: Adam Montville; [email-masked] <mailto:[email-masked]>'
>         To: Waltermire, David A.; [email-masked]
>         <mailto:[email-masked]>'
>         On 4/9/12 11:41 AM, "Waltermire, David A."
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>         >> From: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]] On
>         >> Behalf Of Adam Montville
>         >> To: [email-masked] <mailto:[email-masked]>'
>         >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Mon, 9 Apr 2012 23:01:31 +0000

Hi David,

I would be interested in learning more about CIM and any benefit it may offer our efforts.  I anticipate that there will be many similar discussions along these lines, and we will all benefit from a deeper understanding of existing standards/specifications, specifically where they overlap and where they differ.

In that spirit, can you provide more detail about where you see the overlap between CIM and AI for the list?

Regards,

Adam

From: David Solin <[email-masked]<mailto:[email-masked]>>
Organization: jOVAL
Date: Mon, 9 Apr 2012 17:38:23 -0500
To: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Status Update Request

Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate?  For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade.

Regards,
--David Solin

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>

On 4/9/2012 3:43 PM, [email-masked]<mailto:[email-masked]> wrote:
What do you know….  SACM is already being valuable. ;-)

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Tim

--tk

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Monday, April 09, 2012 2:04 PM
To: Adam Montville; [email-masked]<mailto:[email-masked]>'
Subject: Re: [sacm] Status Update Request

-----Original Message-----
From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; [email-masked]<mailto:[email-masked]>'
Subject: Re: Status Update Request

Hi Dave,

Adam

no
case.
>> To: [email-masked]<mailto:[email-masked]>'

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________ sacm mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sacm

---

From: David Solin <[email-masked]>
Date: Mon, 09 Apr 2012 20:08:54 -0500

Hi Adam,

Certainly!  NIST describes what AI is supposed to be all about as follows:

"Asset identification plays an important role in an organization's 
ability to quickly correlate different sets of information about assets. 
This specification provides the necessary constructs to uniquely 
identify assets based on known identifiers and/or known information 
about the assets. This specification describes the purpose of asset 
identification, a data model for identifying assets, methods for 
identifying assets, and guidance on how to use asset identification. It 
also identifies a number of known use cases for asset identification."

Large systems management vendors and their customers have had the same 
problem for many years.  A vendor may sell a number of different 
products (which were developed by companies they acquired), such as an 
asset management system, an automation system, a change management 
system, a monitoring and event management system, a helpdesk system, and 
so on.  Since, in the case of every large systems management product 
vendor, these products were developed independent of one-another, there 
has always been a fairly strong need to be able to correlate information 
between them.  For instance, if a user creates a helpdesk ticket because 
he's having problem with email, there is a need for an IT administrator 
to be able to correlate events that might be happening on an Exchange 
Server, with an automated patch distribution job, with the owning 
organization for those assets (for chargeback purposes), and back to the 
helpdesk ticket -- so that response times established in service level 
agreements can be tracked and measured appropriately.

The large ISVs have addressed this market need by taking direction from 
ITIL and creating (so-called) CMDB products.  These products provide an 
authoritative system of record about (1) configuration items (AKA a CI; 
in ITIL, any object whose configuration must be managed independently of 
other CIs is a CI), and (2) relationships between CIs, particularly 
service models/service dependencies.  The individual point products in a 
"solution" generally sync up with a "federated" CMDB using an ETL 
process, and must complete a two-way exchange of information that makes 
it possible to: (1) associate any item in the product with any item in 
the CMDB, and (2) vice-versa.  (A number of factors -- scale, legacy 
install base, organizational inertia, individual point-product market 
requirements, interoperability with 3rd-party products, etc. -- make it 
more or less impossible for all the applications to use the same CMDB 
natively).

So, while most of the information about CIs will still reside in the 
individual point products, at least the CMDB can function as a central 
registry containing all the IT services, their SLAs, their relationships 
to CIs, and CI asset (i.e., ownership) information.

It seems to me, therefore, that any use-case that exists for Asset 
Identification must already exist for CMDBs.  At the same time, while I 
am aware of no products currently using AI for any purpose, I am aware 
of several particularly large ones that include CMDBs 
(BMC/Remedy/BladeLogic, HP/Opsware, IBM/Tivoli, CA/Unicenter ... and all 
of their partners), and furthermore, every one of these CMDB products is 
based on a CIM schema.  So there is a standard model for describing 
everything from services, to the objects and configurations upon which 
they depend, to their consumers.  Given the breadth of the protocols 
included in SCAP, CIM would seem like a ready-made model that is not 
only capable of tying everything together, but with the added advantage 
of already being widely used in enterprise systems management product 
suites.

If we do not use CIM natively for these purposes, we will need to create 
a bridge to translate from AI to CIM so that users will be able to 
correlate security automation information with assets and services that 
are already described in their CMDB systems.

Best regards,
--David Solin

On 4/9/2012 6:01 PM, Adam Montville wrote:
> From: David Solin<[email-masked]<mailto:[email-masked]>>
> Organization: jOVAL
> To:<[email-masked]<mailto:[email-masked]>>
> From: "Polk, William T."<[email-masked]<mailto:[email-masked]>>
> To: Tim Keanini<[email-masked]<mailto:[email-masked]>>, David Waltermire<[email-masked]<mailto:[email-masked]>>, Adam Montville<[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> On 4/9/12 11:41 AM, "Waltermire, David A."<[email-masked]<mailto:[email-masked]>>
> wrote:
>

--

---

From: Tim Keanini <[email-masked]>
Date: Tue, 10 Apr 2012 08:36:34 -0700

There are at least two considerations: 

-          Inter-domain multi-sensor data fusion and synthesis

-          Limitations of discovery (instance data resolution)

Inter-domain multi-sensor data fusion and synthesis

This is for all practical purposes the inverse-functional-property or
primary key syntax match problem.

The metadata in AI is designed with the other SCAP metadata in mind
whereas CIM was not and while they may share common keys like IP address
to perform a join, more and more this is not a stable characteristic of
the asset in either domain.  Another consideration here is that CIM
would not have in it something like a CPE identifier, very common key
for synthesis across domains within the SCAP family.  My suggestion here
is that we not look for a single domain to identify an asset but to
ensure that all the data domains (AI, CIM, etc) have in them enough
boundary objects to "join" or synthesize multiple domains.  We should
ensure that all information domains have in it a rich set of stable
characteristics that afford syntactical matching of the metadata for the
purposes of Inter-domain multi-sensor data fusion and synthesis

Limitations of discovery (instance data resolution): Authenticated and
Unauthenticated Discovery 

Remote automated scanning comes in at least two flavors,
authenticated-scanning and unauthenticated-scanning.  We must keep this
in mind as we look to the design or borrow these metadata formats (AI,
CIM, etc).  Most if not all CMDB assumes the old network management
mindset of nodes-under-management and node-not-under-management.  The
former having an agent installed or some authentication/authorization
provided, the latter assumes an assessment of the target via its target
surface in an unauthenticated manner.  I raise this issue once again
because OVAL for example makes no provision for the assessment to take
place in an unauthenticated manner.   We need to keep this in mind as we
look to populate the metadata of AI as certain fields will only be valid
for authenticated scanning or an agent.  I'm a vendor that has both
types of scanners and I must say that for reasons I will not get into
here, customers deploy unauthenticated scanners across their entire
enterprise and authenticated scanners in targeted scopes.  I raise this
issue because time and time again, customers come back to us with the
unauthenticated scanners having much more identification of end-point
assets than any other authenticated scanner.  This is a sidebar but I
wanted to share this experience having been a supplier of this
technology for the past 12 years.    

--

Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722
...

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Solin
Sent: Monday, April 09, 2012 5:38 PM
To: [email-masked]
Subject: Re: [sacm] Status Update Request

Regards,
--David Solin

-- 

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/> 

From: "Polk, William T." <[email-masked]
<mailto:[email-masked]> >
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini <[email-masked] <mailto:[email-masked]> >,
David Waltermire <[email-masked]
<mailto:[email-masked]> >, Adam Montville
<[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [sacm] Status Update Request

	Tim

	From: [email-masked] [[email-masked]] On Behalf Of
Tim Keanini [[email-masked]]

	We will certainly need a few ascii diagrams so let me share this
link:

	--tk

	--

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

Behalf Of

	Waltermire, David A.

	To: Adam Montville; [email-masked] <mailto:[email-masked]> '

	I can take a stab at that.  It will be useful at minimum to
start some

	discussion.

	Dave

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

		To: Waltermire, David A.; [email-masked]
<mailto:[email-masked]> '

		Hi Dave,

		Thanks for sending this out.  I like the abstract and
the structure of

		the document so far, so no further comments from me on
the abstract.

		Are you planning to create a first pass at a complete
list of use

		cases for the document?

		Adam

		On 4/9/12 11:41 AM, "Waltermire, David A."
<[email-masked]>

		no

	case.

		>> To: [email-masked] <mailto:[email-masked]> '

	 

	sacm mailing list

	[email-masked]

	sacm mailing list

	[email-masked]

	sacm mailing list

	[email-masked]

---

From: David Solin <[email-masked]>
Date: Tue, 10 Apr 2012 11:49:35 -0500

Hi Tim,

Addressing the problem of uniqueness certainly does not require an 
entirely new data model.  Existing CMDBs have to solve the problem of 
multiple discovery sources, as each product interacting with it is 
potentially another discovery source.  BMC's Atrium CMDB, for instance, 
extends the CIM schema with a reconciliation ID that is used for this 
purpose, and I imagine that's probably not an uncommon solution.  
There's no reason we can't have an Asset Identification specification 
that consists purely of an extension of CIM -- where we can add, for 
instance, a CPE property to existing classes (e.g., OperatingSystem, 
DatabaseSystem ... or perhaps just to the System parent class?).  
Indeed, perhaps that's what you're suggesting?

To my eye, the AI specification looks largely like a subset of CIM, 
except with the addition of the specialized ai:website object (which 
feels like it should be unnecessary).  Why do we want to reinvent the wheel?

Regards,
--David

On 4/10/2012 10:36 AM, Tim Keanini wrote:
> -Inter-domain multi-sensor data fusion and synthesis
>
> -Limitations of discovery (instance data resolution)
>
> *Inter-domain multi-sensor data fusion and synthesis*
>
> whereas CIM was not and while they may share common keys like IP 
> address to perform a join, more and more this is not a stable 
> characteristic of the asset in either domain.  Another consideration 
> here is that CIM would not have in it something like a CPE identifier, 
> very common key for synthesis across domains within the SCAP family.  
> My suggestion here is that we not look for a single domain to identify 
> an asset but to ensure that all the data domains (AI, CIM, etc) have 
> in them enough boundary objects to "join" or synthesize multiple 
> domains.  We should ensure that all information domains have in it a 
> rich set of stable characteristics that afford syntactical matching of 
> the metadata for the purposes of Inter-domain multi-sensor data fusion 
> and synthesis
>
> *Limitations of discovery (instance data resolution): Authenticated 
> and Unauthenticated Discovery *
>
> authenticated-scanning and unauthenticated-scanning.  We must keep 
> this in mind as we look to the design or borrow these metadata formats 
> (AI, CIM, etc).  Most if not all CMDB assumes the old network 
> management mindset of nodes-under-management and 
> node-not-under-management.  The former having an agent installed or 
> some authentication/authorization provided, the latter assumes an 
> assessment of the target via its target surface in an unauthenticated 
> manner.  I raise this issue once again because OVAL for example makes 
> no provision for the assessment to take place in an unauthenticated 
> manner.   We need to keep this in mind as we look to populate the 
> metadata of AI as certain fields will only be valid for authenticated 
> scanning or an agent.  I'm a vendor that has both types of scanners 
> and I must say that for reasons I will not get into here, customers 
> deploy unauthenticated scanners across their entire enterprise and 
> authenticated scanners in targeted scopes.  I raise this issue because 
> time and time again, customers come back to us with the 
> Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 
> 328-2722  ...
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> 
> *On Behalf Of *David Solin
> *Sent:* Monday, April 09, 2012 5:38 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sacm] Status Update Request
>
> Was there any discussion at the meeting in Paris on Asset 
> Identification vs. CIM, or has anyone identified a use-case for AI for 
> which CIM is not appropriate?  For the sake of making SACM easily 
> adoptable by large enterprises with existing CMDB implementations, I 
> strongly advocate abandoning AI in favor of CIM.  I'd be happy to 
> discuss how BMC, IBM, HP, CA, etc. have been making CIM the 
> centerpiece of their systems management offerings for most of the past 
> decade.
>
> Regards,
> --David Solin
>
> -- 
>
> Learn More <http://www.joval.org>| Features 
> <http://www.joval.org/features/>| Download 
> On 4/9/2012 3:43 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
>
> *From: *"Polk, William T." <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Mon, 9 Apr 2012 15:22:25 -0500
> *To: *Tim Keanini <[email-masked] 
> <mailto:[email-masked]>>, David Waltermire 
> <[email-masked] <mailto:[email-masked]>>, Adam 
> Montville <[email-masked] <mailto:[email-masked]>>, 
> *Subject: *Re: [sacm] Status Update Request
>

--

---

From: Tim Keanini <[email-masked]>
Date: Thu, 19 Apr 2012 13:05:34 -0700

I would argue that it is not a problem of uniqueness but a machine
learning problem of computing inter-domain equivalence (which may or may
not be unique).  I say this only because in these case we are talking
about computing the syntactical equivalence but certainly in the future
we could also do this based on semantic equivalence.  

And you are so right in that CIM would require more schema to aid in the
task of synthesis with sacm/scap.  I'm completely in agreement at the
technical level.    In fact, most of the fields in AI can be computed
from the CIM model (being a subset).  

What I am sensitive to here is the administrative realms and political
realms of both standards.  If the solution couples the two standards
such that one is impaired by the others progress or dormancy, bad
design, no donut.  

--tk

--

From: David Solin [mailto:[email-masked]] On Behalf Of
David Solin
Sent: Tuesday, April 10, 2012 11:50 AM
To: Tim Keanini
Cc: [email-masked]
Subject: Re: [sacm] Status Update Request

Hi Tim,

To my eye, the AI specification looks largely like a subset of CIM,
except with the addition of the specialized ai:website object (which
feels like it should be unnecessary).  Why do we want to reinvent the
wheel?

Regards,
--David

 

 

--

On Behalf Of David Solin
To: [email-masked] <mailto:[email-masked]> 

Regards,
--David Solin

-- 

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

	Tim

	--tk

	--

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

	Waltermire, David A.

	discussion.

	Dave

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

		Hi Dave,

		cases for the document?

		Adam

		no

	case.

	 

	sacm mailing list

	[email-masked]

	sacm mailing list

	[email-masked]

	sacm mailing list

	[email-masked]

 

--

---

From: David Solin <[email-masked]>
Date: Tue, 24 Apr 2012 16:51:34 -0500

All I'm saying is that CIM is already widely used for exactly the 
purposes and use-cases specified by AI.  From what I can determine, AI 
is not inherently capable of dealing with issues like reconciliation, 
but there are existing well-known practices around CIM.  If CIM's 
attributes are insufficient for our needs, it is extensible by design.  
But I think the CIM class model is more than sufficient for anything we 
can dream up.

If every potential user designs a new standard, then there are, in 
effect, no standards.  My opinion is that since we can choose between an 
immature proposal (AI), and a mature widely-adopted standard (CIM), the 
choice should be obvious.

Anyway, are Tim and I the only people with thoughts on the matter?  I 
was hoping that perhaps David Waltermire might be able to explain the 
rationale behind proposing a new standard.

Regards,
--David Solin

On 4/19/2012 3:05 PM, Tim Keanini wrote:
> learning problem of computing inter-domain equivalence (which may or 
> may not be unique).  I say this only because in these case we are 
> talking about computing the syntactical equivalence but certainly in 
> the future we could also do this based on semantic equivalence.
>
> And you are so right in that CIM would require more schema to aid in 
> the task of synthesis with sacm/scap.  I'm completely in agreement at 
> the technical level.    In fact, most of the fields in AI can be 
> computed from the CIM model (being a subset).
>
> *From:*David Solin [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]> *On Behalf Of *David Solin
> *Sent:* Tuesday, April 10, 2012 11:50 AM
> *To:* Tim Keanini
> *Cc:* [email-masked] <mailto:[email-masked]>
> potentially another discovery source.  BMC's Atrium CMDB, for 
> instance, extends the CIM schema with a reconciliation ID that is used 
> for this purpose, and I imagine that's probably not an uncommon 
> solution.  There's no reason we can't have an Asset Identification 
> specification that consists purely of an extension of CIM -- where we 
> can add, for instance, a CPE property to existing classes (e.g., 
> OperatingSystem, DatabaseSystem ... or perhaps just to the System 
> parent class?).  Indeed, perhaps that's what you're suggesting?
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]>*On Behalf Of *David Solin

--

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 25 Apr 2012 00:13:15 -0400

Ok.  I'll bite. ;-)  First off, I am not interested in creating a new standard that competes with CIM or any of the other data models capturing asset information.  If fact, if there is a better solution I'd like to explore it.  This thread has been useful in exploring some possibilities.

Speaking to Asset Identification, one of the major reasons we created the specification was to provide a mapping mechanism that can synthesize data across any underlying systems management protocol (e.g. WEBM, SNMP, NetConf, etc) and data format (e.g. CIM, MIB, Yang, SCAP, etc.)  We wanted something that would be information domain neutral.  In my mind the controlled vocabulary approach used in Asset Identification provides part of a semantic abstraction over all of these things.  It enables data synthesis within a heterogeneous environment of tools implementing a variety of standards-based approaches.

I hope this provides more context.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Solin
Sent: Tuesday, April 24, 2012 5:52 PM
To: Tim Keanini
Cc: [email-masked]
Subject: Re: [sacm] Status Update Request

All I'm saying is that CIM is already widely used for exactly the purposes and use-cases specified by AI.  From what I can determine, AI is not inherently capable of dealing with issues like reconciliation, but there are existing well-known practices around CIM.  If CIM's attributes are insufficient for our needs, it is extensible by design.  But I think the CIM class model is more than sufficient for anything we can dream up.

If every potential user designs a new standard, then there are, in effect, no standards.  My opinion is that since we can choose between an immature proposal (AI), and a mature widely-adopted standard (CIM), the choice should be obvious.

Anyway, are Tim and I the only people with thoughts on the matter?  I was hoping that perhaps David Waltermire might be able to explain the rationale behind proposing a new standard.

Regards,
--David Solin

On 4/19/2012 3:05 PM, Tim Keanini wrote:
I would argue that it is not a problem of uniqueness but a machine learning problem of computing inter-domain equivalence (which may or may not be unique).  I say this only because in these case we are talking about computing the syntactical equivalence but certainly in the future we could also do this based on semantic equivalence.

And you are so right in that CIM would require more schema to aid in the task of synthesis with sacm/scap.  I'm completely in agreement at the technical level.    In fact, most of the fields in AI can be computed from the CIM model (being a subset).

What I am sensitive to here is the administrative realms and political realms of both standards.  If the solution couples the two standards such that one is impaired by the others progress or dormancy, bad design, no donut.

--tk

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722  ...

From: David Solin [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of David Solin
Sent: Tuesday, April 10, 2012 11:50 AM
To: Tim Keanini
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Status Update Request

Hi Tim,

Addressing the problem of uniqueness certainly does not require an entirely new data model.  Existing CMDBs have to solve the problem of multiple discovery sources, as each product interacting with it is potentially another discovery source.  BMC's Atrium CMDB, for instance, extends the CIM schema with a reconciliation ID that is used for this purpose, and I imagine that's probably not an uncommon solution.  There's no reason we can't have an Asset Identification specification that consists purely of an extension of CIM -- where we can add, for instance, a CPE property to existing classes (e.g., OperatingSystem, DatabaseSystem ... or perhaps just to the System parent class?).  Indeed, perhaps that's what you're suggesting?

To my eye, the AI specification looks largely like a subset of CIM, except with the addition of the specialized ai:website object (which feels like it should be unnecessary).  Why do we want to reinvent the wheel?

Regards,
--David

Inter-domain multi-sensor data fusion and synthesis
This is for all practical purposes the inverse-functional-property or primary key syntax match problem.
The metadata in AI is designed with the other SCAP metadata in mind whereas CIM was not and while they may share common keys like IP address to perform a join, more and more this is not a stable characteristic of the asset in either domain.  Another consideration here is that CIM would not have in it something like a CPE identifier, very common key for synthesis across domains within the SCAP family.  My suggestion here is that we not look for a single domain to identify an asset but to ensure that all the data domains (AI, CIM, etc) have in them enough boundary objects to "join" or synthesize multiple domains.  We should ensure that all information domains have in it a rich set of stable characteristics that afford syntactical matching of the metadata for the purposes of Inter-domain multi-sensor data fusion and synthesis

Limitations of discovery (instance data resolution): Authenticated and Unauthenticated Discovery
Remote automated scanning comes in at least two flavors, authenticated-scanning and unauthenticated-scanning.  We must keep this in mind as we look to the design or borrow these metadata formats (AI, CIM, etc).  Most if not all CMDB assumes the old network management mindset of nodes-under-management and node-not-under-management.  The former having an agent installed or some authentication/authorization provided, the latter assumes an assessment of the target via its target surface in an unauthenticated manner.  I raise this issue once again because OVAL for example makes no provision for the assessment to take place in an unauthenticated manner.   We need to keep this in mind as we look to populate the metadata of AI as certain fields will only be valid for authenticated scanning or an agent.  I'm a vendor that has both types of scanners and I must say that for reasons I will not get into here, customers deploy unauthenticated scanners across their entire enterprise and authenticated scanners in targeted scopes.  I raise this issue because time and time again, customers come back to us with the unauthenticated scanners having much more identification of end-point assets than any other authenticated scanner.  This is a sidebar but I wanted to share this experience having been a supplier of this technology for the past 12 years.

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722  ...

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of David Solin
Sent: Monday, April 09, 2012 5:38 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Status Update Request

Regards,
--David Solin

--

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Tim

--tk

-----Original Message-----
From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; [email-masked]<mailto:[email-masked]>'
Subject: Re: Status Update Request

Hi Dave,

Adam

no
case.

sacm mailing list

--

--