Subject: Re: [sacm] [Non-DoD Source] Re: IM Issue #27 - Selecting an Information Model Representation

From: Chris Inacio <[email-masked]>
Date: Tue, 1 Dec 2015 13:11:21 +0000

You create an interesting thought for me.  Your system is self-consistent – but how does it exchange information with other systems?  (Maybe the answer is:  “it doesn’t, and it will not.)  But for example, your system is US DoD - what if you had to exchange inventory / posture information with US Commerce or with a NATO ally, e.g. Turkey DoD.  How would you know what the definition of operating systems are in “their” management system?

Does the group expect cross enterprise/organizational information / posture exchange?  I assume the US DHS does; since they’ve been driving toward that very goal for quite some time.

personal curiosity:

Can anyone update the “enumeration” of operating systems?  Can any system administrator go into the system and “delete” Windows, for example?

--
Chris Inacio
[email-masked]

> On Nov 30, 2015, at 9:55 AM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]> wrote:
> 
> That makes sense then.  I suppose the question back to the SACM team is whether they (we?) want to track enumerations through versioning or timestamps with change logs.  Maybe some combination of both, based on the expected frequency of change.  It may be worthwhile to identify a few places in the expected information model where enumerations are expected to play heavily.
> 
> Possible examples:  
> - Compliance results (e.g. Pass, Fail, Not Checked, Error, Fixed, Not Selected, etc)
> - Device Roles (e.g. server, workstation, router, switch, etc)
> - Device Form Factors (Tower, mini-tower, Blade, tablet, Phablet, virtual, etc)
> - Device Functions (routing, switching, file server, web server, database server, email server, email client, hypervisor, etc)
> - Software functions (word processing, spreadsheet automation, database management, calculator, Jabber Client, email client,  etc.)
> - Severity Enumerations (high, med-high, med, med-low, low)
> - Colors (red, orange, yellow, green, blue, indigo, violet, etc)
> - Logical network location (Direct Internet connected, direct private WAN connected, DMZ, protected network connected, etc)
> - Government organization names (US, UK, France, ... Maybe look at ISO names?)
> - Geopolitical location names
> - Human Security Roles (Approving Authority, System Administrator, Network Administrator, etc)
> - Directory systems (DNS, AD,X.500, etc)
> - Operating System Names (Windows, Android, Apple IOS, Cisco IOS, Linux, etc [though we still need to decide if those are "names" or not])
> 
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Fort Meade DISA Acquisiton Bldg Cube A4A58E
> Work: (301) 225-8820
> Gov Cell: (571) 814-8231
> [email-masked]
> 
> 
> 
> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
> Sent: Monday, November 30, 2015 9:36 AM
> To: Wolfkiel, Joseph L CIV DISA ID (US)
> Cc: Gunnar Engelbach; Haynes, Dan; [email-masked]
> Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation
> 
> 
> Your point is valid.
> It's optional in my system.
> 
> 
> 
> On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-mailto:[email-masked] > > wrote:
> 
> 
> 	Is that in addition to versioning?  Seems like the complexity would ultimately make maintaining all the historical information and business logic difficult to scale, particularly when you try to do something smart with respect to reconciling versions vs status of enumeration entries.
> 	
> 	Joseph L. Wolfkiel
> 	SCM Engineering Lead
> 	DISA ID52
> 	Fort Meade DISA Acquisiton Bldg Cube A4A58E
> 	Work: (301) 225-8820
> 	Gov Cell: (571) 814-8231
> 	[email-masked] < javascript:; > 
> 	
> 	
> 	
> 	-----Original Message-----
> 	From: sacm [Caution-mailto:[email-masked] < javascript:; > ] On Behalf Of Jerome Athias
> 	Sent: Monday, November 30, 2015 9:03 AM
> 	To: Wolfkiel, Joseph L CIV DISA ID (US)
> 	Cc: Gunnar Engelbach; Haynes, Dan; [email-masked] < javascript:; > 
> 	Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation
> 	
> 	I have implemented something like this with the use of 2 objects
> 	A CreationRecord and a ChangeRecord objects attached to all the other objects
> 	Everything is time stamped + traceable in terms of who did what when + confidence level, trust level...
> 	
> 	On Monday, 30 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < javascript:; >  < Caution-Caution-mailto:[email-masked] < javascript:; >  > > wrote:
> 	
> 	
> 	        If there is actually interest in this topic, we can discuss in detail.  One of the reasons I didn't go with a version-based implementation is usability.  In general, our name maintenance system is a real-time system where users can go in, update a hierarchy with new locations, organizations, or system names, then immediately download the updated list.  As you can imagine, if multiple users are doing this over the course of a day, then trying to track versions becomes onerous to maintain and understand.  In the system we're using, the downloaded hierarchy contains a timestamp of when it was downloaded.  Since all changes (additions, modifications, deletions) are included and timestamped, you can walk back through time by just selecting the modifications that happened before the time you're concerned with.  This is implemented as an alternative to versioning.  The timestamp approach also allows consumers to do incremental downloads where they only receive changes sinc!
> e the las
> t time a download was made instead of having to download an entire version of each enumeration/taxonomy.
> 	
> 	        Joseph L. Wolfkiel
> 	        SCM Engineering Lead
> 	        DISA ID52
> 	        Fort Meade DISA Acquisiton Bldg Cube A4A58E
> 	        Work: (301) 225-8820
> 	        Gov Cell: (571) 814-8231
> 	        [email-masked] < javascript:; >  < javascript:; >
> 	
> 	
> 	
> 	        -----Original Message-----
> 	        From: Jerome Athias [Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; > ]
> 	        Sent: Friday, November 27, 2015 10:15 PM
> 	        To: Gunnar Engelbach
> 	        Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked] < javascript:; >  < javascript:; >
> 	        Subject: [Non-DoD Source] Re: [sacm] IM Issue #27 - Selecting an Information Model Representation
> 	
> 	
> 	        In XORCISM I am managing the enumerations using what I call Vocabularies:
> 	        Vocabulary has a relationship to Organisation(s)
> 	        (Gives you the name space)
> 	
> 	        Vocabulary has versioning
> 	
> 	        Vocabulary supports various enumerations hierarchy
> 	
> 	        Vocabulary's enumeration could be deprecated (better than just deleting one item, and in case you don't want to increase the version)
> 	
> 	        Vocabularies have a mapping (when needed) allowing switching or direct retrieval of equivalents (v1/v2 or org1/org2, etc.)
> 	
> 	
> 	
> 	        On Tuesday, 24 November 2015, Gunnar Engelbach <[email-masked] < javascript:; >  < javascript:; >  < Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  > > wrote:
> 	
> 	
> 	
> 	                An enumeration, then, becomes another type of content.  It needs an authoritative source, plus the abilities to create notifications when it changes and be distributed to all points of usage.
> 	
> 	
> 	                --gun
> 	
> 	
> 	                On 11/24/2015 10:21 AM, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
> 	
> 	
> 	                        For the DoD, I've implemented an enumeration maintenance system, a standard XML schema, and a restful web service for maintaining enumerations.  Something similar may work for SACM.  Enumeration maintenance ends up being a special challenge in and of itself since enumerations can be flat lists, hierarchies, or have the ability to support multiple hierarchies.  Enumeration items can be added, deleted, modified, and merged over time, so different users of the enumerations may be using different lists based on when they were last updated.I doubt SACM considers enumeration management to be within its charter as a generalized solution, but full interoperability will probably involve the ability to maintain and evolve some set of enumerations over time. Joseph L. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:; >  < javascript:; >  < jav!
> ascript:_
> e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Tuesday, November 24, 2015 10:12 AMTo: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Subject: Re: [sacm] [Non-DoD Source] IM Issue #27 - Selecting an Information Model RepresentationAll active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.  ----Thanks for the feedback Joe.  Once we have a way to represent the information that we care about in our!
> IM, imple
> menters are free to use XML, JSON, or maybe something else todocument/implement the IM via the creation of data model.  I think it wouldalso be acceptable for them to generate UML diagrams if they would like.Yeah, the point about enumerations is a good one given the may change morefrequently.  Does anyone have any thoughts on how to best handle what wouldbe enumerations in the Information Model?  Would it be best to document theenumerations in separate document that would change over time and the IMcould just reference out to it?Agree, I am going to add a track that points to this thread and the previousthread regarding whether or not a network interface is hardware, software,or something else.  That way we can refer back to the relevant discussionswhen it comes time to design it in the IM.Thanks,Danny-----Original Message-----From: Wolfkiel, Joseph L CIV DISA ID (US)[Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  <!
>  javascri
> pt:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; > '); > ] Sent: Friday, November 20, 2015 8:53 AMTo: Haynes, Dan <[email-masked] < javascript:; >  < javascript:; > > < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > ; [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Subject: RE: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel Representation+1 here for something like option 1.  I personally like using XML schema todocument this type of thing in a machine-readable manner.  JSON schema andUML class diagrams should also be considered.  For this particular example, I suggest that enumerations be maintainedseparately from the data model since they are subject to change over time.This specific example also highlights an issue that merits consideration.There !
> are aspec
> ts of endpoints that are ephemeral and some that arepersistent.  For example, a hardware Network Interface *card* is persistentand discoverable.  However, a virtual network interface card (for example, anetwork interface generated by a VPN client) may come and go, so the modelshould be able to identify both, along with any metadata required to notethat a given component existed for a given time period.Also, a "network interface" could be understood to describe a logicalconnection to a specific network and would address issues like IP/MACaddresses, network name, default gateway, DNS Name, initial connection time,address "lease", and other issues.  It's good that the data model helps tounderstand that saying "network interface" doesn't actually mean the samething to everyone talking about it.Joseph L. WolfkielSCM Engineering LeadDISA ID52Fort Meade DISA Acquisiton Bldg Cube A4A58EWork: (301) 225-8820Gov Cell: (571) [email-masked] < javascript:; >  < ja!
> vascript:
> ; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > -----Original Message-----From: sacm [Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml','Caution-Caution-Caution-Caution-mailto:[email-masked] < javascript:; >  < javascript:; > '); > ] On Behalf Of Haynes, DanSent: Friday, November 20, 2015 6:57 AMTo: [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Subject: [Non-DoD Source] [sacm] IM Issue #27 - Selecting an InformationModel RepresentationHi Everyone,During the Information Model Update [1] at the IETF 94 Meeting, we discussedvarious modeling syntax options for our Information Model elements.  Thiscorresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted toinclude all the options so the group could review them. Specifically, we discu!
> ssed the 
> following options which provided on the list.Please note that I used the example below because it was very convenient :).It does not represent any agreed upon model for a network interface.Furthermore, it does not mean a decision has been made around whether or nota network interface is a hardware component, software component, both, orsomething else.  That decision is currently being worked out on the list[3]. ---------- OPTION 1 (RFC 7326 - Energy Management Framework [4]):     CLASS NetworkInterface EXTENDS HardwareComponent {        name            : string        index           : int        hardwareAddress : MACAddress        type            : enum {ether, fddi, loopback, .}        flags [0..n]    : enum {up, broadcast, debug, .}    }     Network Interface (Class):         name               string        The name of the interface.         index              int           The index of the interface.         hardwareAddress    MACAddress    The IEEE 802 MAC address.   !
>       typ
> e               Enumeration   Describes the type of the networkinterface.         flags [0..n]       Enumeration   Describes the flags set on theinterface. ---------- OPTION 2 (Information Model for Large-Scale Measurement Platforms [5]):     Definition of network-interface-obj     object {        string name;        int index;        mac-address-obj hardware-address;        string type;         string flags<0..n>;    } network-interface-obj;     A network-interface-object consists of the following elements:       name:               The name of the interface.    index:              The index of the interface.    hardwareAddress:    The IEEE 802 MAC address.    type:               Describes the type of the network interface. Thevalue 'ether' indicates.    flags:              Describes the flags set on the interface. The value'up' indicates. ---------- OPTION 3 (Unified Modeling Language [6]):     +-------------------+    | HardwareComponent |    +-------------------+    | .!
> 
>         |    +-------------------+             ^             |    +---------------------+    | NetworkInterface    |    +---------------------+    | string name         |    | int    index        |    | enum   type         |    | enum   flags [0..n] |<>----[ MACAddress ]    +---------------------+                                           The aggregate class that constitutes a NetworkInterface is:         MACAddress             One. The IEEE 802 MAC address.     The Network Interface class has four attributes:         name             Required. String. The name of the interface.         index             Required. Int. The index of the interface.         type             Required. Enum. Describes the type of network interface.         flags             Optional. 0..n. Describes the flags set on the interface. ---------- OPTION 4 (Entity-Relationship Diagram [7]):     +-------------------+    | HardwareComponent |    +-------------------+             |         < IS-A >      !
>        | 
>    +------------------+    | NetworkInterface |--------    +------------------+       |             |----( name )     |             |----( index )    |             |----( type )     |             |----(( flags ))  |                               |         +------------+        |        | MACAddress |----< HAS-A >        +------------+              The NetworkInterface entity IS-A HardwareComponent and HAS-A MACAddress.     It has four attributes:     name        Required. String. The name of the interface.    index        Required. Int. The index of the interface.    type        Required. Enum. Describes the type of network interface.    flags        Optional. 0..n. Describes the flags set on the interface. ---------- Lastly, during the meeting the Kerberos information model was suggested asanother option so that has been added to the list. ----------OPTION 5 (RFC 6880 - An Information Model for Kerberos Version 5 [8]):     1.1 NetworkInterface            The NetworkInterfa!
> ce repres
> ents an network interface card...TheNetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in animplementation.     1.1.1 NetworkInterface : Attributes     1.1.1.1 name        The name of the network interface card. It MUST be provided...                1.1.1.2 index        The index of the interface.  It MUST be provided...     1.1.1.2 type        The type of the interface.  It MUST be provided...     1.1.1.2 flags        The flags set on the interface.  It MAY be provided...     1.1.2 NetworkInterface : Associations         Each NetworkInterface MUST be associated with a single MACAddress.The MACAddress is represented in this model below... ---------- During the meeting, there seemed to be consensus around OPTION 1.  There wasalso a suggestion by Jim Schaad that we will want to use a syntax that canbe checked in some automated fashion.  It would be great to learn more aboutthat. Anyways, please let me know, by  December 1st, what option you prefer sothat we!
>  can reac
> h a decision on how to represent our Information Model. Please let me know if you have any questions. Thanks,Danny [1] Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  < Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  < Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  > < Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  < Caution-Ca!
> ution-htt
> ps://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  < Caution-Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  < Caution-Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf < Caution-https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf >  >  >  > [2]Caution-Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  < Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-!
> informati
> on-model/issues/2 >  < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  > 7 <Caution-Caution-Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  < Caution-Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/2 >  >  > 7 > [3] Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/mail-ar!
> chive/web
> /sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  < Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  > < Caution-Caution-Caution-Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  < Caution-Caution-Caution-https://!
> www.ietf.
> org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >  >  >[4] Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  >  <Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rf!
> c7326/ < 
> Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc7326/ < Caution-https://datatracker.ietf.org/doc/rfc7326/ >  >  >  > [5]Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracke!
> r.ietf.or
> g/doc/draft-burbridge-lmap-information-model/ >  >  >  <Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  < Caution-Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ < Caution-https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/ >  >  >  > [6] Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.!
> uml-diagr
> ams.org/ >  >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  >  <Caution-Caution-Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  < Caution-Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  < Caution-Caution-http://www.uml-diagrams.org/ < Caution-http://www.uml-diagrams.org/ >  >  >  > [7] Caution-Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  < Caution-Caution-Caution-https://en!
> .wikipedi
> a.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  > < Caution-Caution-Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  < Caution-Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  < Caution-Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model < Caution-https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model >  >  >  > [8] Caution-Caution-Cau!
> tion-Caut
> ion-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >  <Caution-Caution-Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  < Caution-Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  < Caution-Caution-https://datatracker.ietf.org/doc/rfc6880/ < Caution-https://datatracker.ietf.org/doc/rfc6880/ >  >  >  >
> 	
> 	
> 	
> 	                        _______________________________________________sacm mailing [email-masked] < javascript:; >  < javascript:; >  < javascript:_e(%7B%7D,'cvml',[email-masked] < javascript:; >  < javascript:; > '); > Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  >  < Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  >  >
> 	
> 	
> 	
> 	
> 	
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Jerome Athias <[email-masked]>
Date: Tue, 1 Dec 2015 18:45:05 +0300

Because of the dead line, sharing this "as is"

My XORCISM research had one objective to build a PoC to demonstrate
and validate the
value.
A "platform-dependent" PoC was built were:
- A Relational Database schema(s) (my "Cyber Model") (one way of
materializing the UMLs (NB: I bypassed the UML step))
is representing a "Cyber Ontology"
- The Database/Ontology was built based on (Common) Languages and
Formats, Specifications, Standards
- The technical interoperability is demonstrated/validated by tools
interacting with the Enumerations and the Database
- The tools are making use of an "API" where all the -Objects- can be
manipulated
- The "API" (Classes) (Semantic Interoperability) was generated automatically
from the Database/Ontology, and so the Objects inherit from their
representation (constructs) found in the Common Languages/Models
- The Knowledge Repositories are directly stored in the Database
- The data stored in the Database are Making Security instantly Measurable

(Again, it's just a PoC.)

A better representation for the Ontology is possible.
BUT, all the advantages and benefits would be obtained, only, -IF-,
the "(structured) raw data" can be easily and 'directly' mapped with
the Ontology.

It is possible easily to generate the classes from the database schema
It is quite easy to obtain (partial but usable) UML diagrams from the
database schemas (not shared because too big...)
It is possible (but not so easy) to generate a entity-relationship
model "poster" from the database (I did it once a long time ago so old
version: http://www.frhack.org/research/XORCISM_0.7_Jerome_Athias_Poster.pdf
)
It is possible "quite easily" to split the data model (done in current
version with multiple database schemas linkable together)
Parts of the PoC: https://github.com/athiasjerome/XORCISM

PS: I found a lot of optimizations (and missing relationships) for a
lot of Data Models while working on XORCISM... (reflected in the model
but not documented and often not even shared with the entities who
produced the models*)

PS: *lack of time for documentation but I could handle questions

At this point, I think, that a Cyber Ontology is possible, and is the way to go

2015-11-20 14:56 GMT+03:00 Haynes, Dan <[email-masked]>:
> Hi Everyone,
>
>
> During the Information Model Update [1] at the IETF 94 Meeting, we discussed
> various modeling syntax options for our Information Model elements.  This
> corresponds to IM issue #27 [2].  Sorry for the long email, but, I wanted to
> include all the options so the group could review them.
>
>
>
> Specifically, we discussed the following options which provided on the list.
> Please note that I used the example below because it was very convenient :).
> It does not represent any agreed upon model for a network interface.
> Furthermore, it does not mean a decision has been made around whether or not
> a network interface is a hardware component, software component, both, or
> something else.  That decision is currently being worked out on the list
> [3].
>
>
>
> ----------
>
>
>
> OPTION 1 (RFC 7326 – Energy Management Framework [4]):
>
>
>
>     CLASS NetworkInterface EXTENDS HardwareComponent {
>
>         name            : string
>
>         index           : int
>
>         hardwareAddress : MACAddress
>
>         type            : enum {ether, fddi, loopback, …}
>
>         flags [0..n]    : enum {up, broadcast, debug, …}
>
>     }
>
>
>
>     Network Interface (Class):
>
>          name               string        The name of the interface.
>
>          index              int           The index of the interface.
>
>          hardwareAddress    MACAddress    The IEEE 802 MAC address.
>
>          type               Enumeration   Describes the type of the network
> interface.
>
>          flags [0..n]       Enumeration   Describes the flags set on the
> interface.
>
>
>
> ----------
>
>
>
> OPTION 2 (Information Model for Large-Scale Measurement Platforms [5]):
>
>
>
>     Definition of network-interface-obj
>
>
>
>     object {
>
>         string name;
>
>         int index;
>
>         mac-address-obj hardware-address;
>
>         string type;
>
>         string flags<0..n>;
>
>     } network-interface-obj;
>
>
>
>     A network-interface-object consists of the following elements:
>
>
>
>     name:               The name of the interface.
>
>     index:              The index of the interface.
>
>     hardwareAddress:    The IEEE 802 MAC address.
>
>     type:               Describes the type of the network interface. The
> value 'ether' indicates…
>
>     flags:              Describes the flags set on the interface. The value
> 'up' indicates…
>
>
>
> ----------
>
>
>
> OPTION 3 (Unified Modeling Language [6]):
>
>
>
>     +-------------------+
>
>     | HardwareComponent |
>
>     +-------------------+
>
>     | …                 |
>
>     +-------------------+
>
>              ^
>
>              |
>
>     +---------------------+
>
>     | NetworkInterface    |
>
>     +---------------------+
>
>     | string name         |
>
>     | int    index        |
>
>     | enum   type         |
>
>     | enum   flags [0..n] |<>----[ MACAddress ]
>
>     +---------------------+
>
>
>
>     The aggregate class that constitutes a NetworkInterface is:
>
>          MACAddress
>
>              One. The IEEE 802 MAC address.
>
>
>
>     The Network Interface class has four attributes:
>
>          name
>
>              Required. String. The name of the interface.
>
>          index
>
>              Required. Int. The index of the interface.
>
>          type
>
>              Required. Enum. Describes the type of network interface.
>
>          flags
>
>              Optional. 0..n. Describes the flags set on the interface.
>
>
>
> ----------
>
>
>
> OPTION 4 (Entity-Relationship Diagram [7]):
>
>
>
>     +-------------------+
>
>     | HardwareComponent |
>
>     +-------------------+
>
>              |
>
>          < IS-A >
>
>              |
>
>     +------------------+
>
>     | NetworkInterface |--------
>
>     +------------------+       |
>
>              |----( name )     |
>
>              |----( index )    |
>
>              |----( type )     |
>
>              |----(( flags ))  |
>
>                                |
>
>          +------------+        |
>
>         | MACAddress |----< HAS-A >
>
>         +------------+
>
>
>
>     The NetworkInterface entity IS-A HardwareComponent and HAS-A MACAddress.
>
>
>
>     It has four attributes:
>
>
>
>     name
>
>         Required. String. The name of the interface.
>
>     index
>
>         Required. Int. The index of the interface.
>
>     type
>
>         Required. Enum. Describes the type of network interface.
>
>     flags
>
>         Optional. 0..n. Describes the flags set on the interface.
>
>
>
> ----------
>
>
>
> Lastly, during the meeting the Kerberos information model was suggested as
> another option so that has been added to the list.
>
>
>
> ----------
>
> OPTION 5 (RFC 6880 – An Information Model for Kerberos Version 5 [8]):
>
>
>
>     1.1 NetworkInterface
>
>             The NetworkInterface represents an network interface card...The
> NetworkInterface MUST be implemented in full and MUST NOT be OPTIONAL in an
> implementation.
>
>
>
>     1.1.1 NetworkInterface : Attributes
>
>
>
>     1.1.1.1 name
>
>         The name of the network interface card. It MUST be provided...
>
>
>
>     1.1.1.2 index
>
>         The index of the interface.  It MUST be provided...
>
>
>
>     1.1.1.2 type
>
>         The type of the interface.  It MUST be provided...
>
>
>
>     1.1.1.2 flags
>
>         The flags set on the interface.  It MAY be provided...
>
>
>
>     1.1.2 NetworkInterface : Associations
>
>         Each NetworkInterface MUST be associated with a single MACAddress.
> The MACAddress is represented in this model below...
>
>
>
> ----------
>
>
>
> During the meeting, there seemed to be consensus around OPTION 1.  There was
> also a suggestion by Jim Schaad that we will want to use a syntax that can
> be checked in some automated fashion.  It would be great to learn more about
> that.
>
>
>
> Anyways, please let me know, by  December 1st, what option you prefer so
> that we can reach a decision on how to represent our Information Model.
>
>
>
> Please let me know if you have any questions.
>
>
>
> Thanks,
>
> Danny
>
>
>
> [1] https://www.ietf.org/proceedings/94/slides/slides-94-sacm-3.pdf
>
> [2] https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27
>
> [3] https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html
>
> [4] https://datatracker.ietf.org/doc/rfc7326/
>
> [5] https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/
>
> [6] http://www.uml-diagrams.org/
>
> [7] https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
>
> [8] https://datatracker.ietf.org/doc/rfc6880/
>
>
>
>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 1 Dec 2015 18:09:32 +0100

Isn't an ontology more on the data model side of things? Or are you
referring only to the terminological component (TBox) of on ontology?
>From the top of my head, I am not aware of a TBox representation that is
not looking like a data model (e.g. OWL). But maybe there is one?

Semantic representations, such as ontologies, can most certainly express
everything SACM requires. Alas, there is also a - at least strongly
perceived - steep learning curve, I suppose. One reason for this is
probably the fact that common representations (in e.g. XML or RDF) are
difficult to read for humans and tools are pretty much required to
compose and understand those.

Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 1 Dec 2015 18:50:50 +0100

As I was trying to get hands-on experience with option #1, two questions
came up (which might be a little bit down the rabbit hole, though):

1) Can the IM #1 (as it is) express constraints such as "at least one of
those two information elements is required"? If not, would it be
feasible to add more complex constraints to the IM?

2) Would it be better to represent categorization via subclasses or via
the relationship class? Analogously, would it be okay to have empty
classes (with no elements) that only get extended?

Grüße,

Henk

On 11/20/2015 12:56 PM, Haynes, Dan wrote:
> Hi Everyone,
> 
> 
> During the Information Model Update [1] at the IETF 94 Meeting, we
> discussed various modeling syntax options for our Information Model
> elements.  This corresponds to IM issue #27 [2].  Sorry for the long
> email, but, I wanted to include all the options so the group could
> review them.
> 
>  
> 
> Specifically, we discussed the following options which provided on the
> list.  Please note that I used the example below because it was very
> convenient :). It does not represent any agreed upon model for a network
> interface.  Furthermore, it does not mean a decision has been made
> around whether or not a network interface is a hardware component,
> software component, both, or something else.  That decision is currently
> being worked out on the list [3].
> 
>  
> 
> ----------
> 
>  
> 
>          type               Enumeration   Describes the type of the
> network interface.
> 
>     flags:              Describes the flags set on the interface. The
> value 'up' indicates…
> 
>  
> 
> ----------
> 
>  
> 
> Lastly, during the meeting the Kerberos information model was suggested
> as another option so that has been added to the list.
> 
>  
> 
> ----------
> 
>             The NetworkInterface represents an network interface
> card...The NetworkInterface MUST be implemented in full and MUST NOT be
> OPTIONAL in an implementation.
> 
>  
> 
>         Each NetworkInterface MUST be associated with a single
> MACAddress. The MACAddress is represented in this model below...
> 
>  
> 
> ----------
> 
>  
> 
> During the meeting, there seemed to be consensus around OPTION 1.  There
> was also a suggestion by Jim Schaad that we will want to use a syntax
> that can be checked in some automated fashion.  It would be great to
> learn more about that.
> 
>  
> 
> Anyways, please let me know, by  December 1^st , what option you prefer
> so that we can reach a decision on how to represent our Information Model.
> 
>  
>

---

From: Jerome Athias <[email-masked]>
Date: Wed, 2 Dec 2015 04:56:53 +0300

You are probably right.
My point is more kind of a general observation after reviewing a lot of
data/info models.
Nowadays you can find various models and representation of the same things
for cyber security, and everybody try to come up with THE best model, but
none I have seen cover everything. None gives you the full picture.
There is a ton of models and representation but so far I never seen a
complete cybersecurity ontology. (Or model)
And I think if some were focusing on this we would produce better models
and faster after.

On Tuesday, 1 December 2015, Henk Birkholz <[email-masked]>
wrote:

> > version:
> http://www.frhack.org/research/XORCISM_0.7_Jerome_Athias_Poster.pdf
> > )
> > 2015-11-20 14:56 GMT+03:00 Haynes, Dan <[email-masked] <javascript:;>
> >:
> >> Hi Everyone,
> >>
> >>
> discussed
> list.
> network
> value
> as
> card...The
> MACAddress.
> >> [2]
> https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/27
> >>
> >> [5]
> https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/
> >>
> >> [email-masked] <javascript:;>
> > [email-masked] <javascript:;>