Re: [sacm] Components for Vulnerability Assessment

["Haynes, Dan" <[e-mail]>]

Thanks Carl-Heinz, it looks like I missed that.  With that said, I will keep quiet and let someone who was there clarify :).

Thanks,

Danny

> -----Original Message-----
> From: sacm [mailto:[e-mail]] On Behalf Of Carl-Heinz Genzel
> Sent: Wednesday, April 19, 2017 1:48 AM
> To: [e-mail]
> Subject: Re: [sacm] Components for Vulnerability Assessment
> 
> Hello All,
> 
> The comment mentioned by Danny becomes obsolete in the next section "Per
> slide 8", where it seems to me that it is agreed upon to not combine the
> repositories. However, I wasn't there.
> 
> Best Regards,
> Carl-Heinz Genzel
> 
> Am 18.04.2017 um 17:27 schrieb Adam Montville:
> >
> >
> > On Tue, Apr 18, 2017 at 9:55 AM Haynes, Dan <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Henk,
> >
> >     The reasoning behind my comment was that in the IETF 98 notes
> >     (https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00) it
> >     says:
> >
> >     ---
> >     Per Slide 7:
> >     Q: (Adam Montville): Is the vulnerability assessor talk to the
> >     repository or talking directly to the collector?
> >     A: (Jessica Fitzgerald-McKay): I could see an implementer combining
> >     the collector and end-point repository into one.  If we're treating
> >     them as functional components I'm not sure we need to be that specific.
> >     A: (Dave Waltermire): We want this architecture to be
> >     de-composable.  If we treat the end-point repository as a proxy, we
> >     might be making things too complicated. It might be simpler to treat
> >     the end-point repository as a data store.
> >     A: (Adam Montville): Agreed.
> >
> >     Q: (Dave Waltermire) Are there any concerns with separating the
> >     end-point repository and the collector being the component
> >     responsible for collection?
> >     A: <no response>
> >
> >     Comment: (Adam Montville): The "results repository" will now go into
> >     the "end-point repository.
> >     ---
> >
> >     Given that, I thought there was some consensus around making that
> >     change.
> >
> >
> > Hm...  FWIW, I don't feel I would have said that as a personal
> > opinion, but maybe that there was some agreement in the room.  Of
> > course, the list is what counts.
> >
> > Without a chair hat on, I happen to agree with Henk. What we are
> > calling components are "compose-able function groups" in some sense,
> > and that they should be treated separately, but are likely to be
> > implemented in some composed manner.
> >
> >
> >
> >
> >     Thanks,
> >
> >     Danny
> >
> >     > -----Original Message-----
> >     > From: Henk Birkholz [mailto:[e-mail]
> >     <mailto:[e-mail]>]
> >     > Sent: Tuesday, April 18, 2017 10:49 AM
> >     > To: Haynes, Dan <[e-mail] <mailto:[e-mail]>>;
> >     Adam Montville
> >     > <[e-mail]
> <mailto:[e-mail]>>;
> >     [e-mail] <mailto:[e-mail]>
> >     > Subject: Re: [sacm] Components for Vulnerability Assessment
> >     >
> >     > Hello Danny,
> >     >
> >     > the "Assessment Results Repository" and "Endpoint Repository" are two
> >     > different components with different functions. The "Endpoint
> >     Repository"
> >     > of course is the provider for the consumer that is the "Assessment
> >     Results
> >     > Repository".
> >     >
> >     > Most certainly, both components can be running on the same
> >     endpoint or be
> >     > composed in a single service that merges both components. I
> >     suppose that is
> >     > what you meant?
> >     >
> >     > For the sake of show-casing how the architecture is working. I would
> >     > recommend to start with each SACM component instantiated as a
> separate
> >     > software component. Despite the fact that it looks simpler to just
> >     add the
> >     > "Assessment Result" to the ""Endpoint Characterization Records"
> >     > retained in an "Endpoint Repository".
> >     >
> >     > Ultimately, people will want to use existing software and
> >     Asset/Inventory
> >     > Management Software is a big candidate to provide the functions of an
> >     > "Endpoint Repository". In consequence, I would keep these components
> >     > instantiated separately in the first iteration.
> >     >
> >     > What does the group think?
> >     >
> >     > Viele Grüße,
> >     >
> >     > Henk
> >     >
> >     > On 04/18/2017 04:21 PM, Haynes, Dan wrote:
> >     > > Hi Adam,
> >     > >
> >     > >
> >     > >
> >     > > I think this is a good list for me, but, should the assessment
> >     results
> >     > > repository be merged into the endpoint repository?
> >     > >
> >     > > Thanks,
> >     > >
> >     > > Danny
> >     > >
> >     > >
> >     > >
> >     > > *From:*sacm [mailto:[e-mail]
> >     <mailto:[e-mail]>] *On Behalf Of *Adam
> >     > > Montville
> >     > > *Sent:* Tuesday, April 18, 2017 9:04 AM
> >     > > *To:* [e-mail] <mailto:[e-mail]>
> >     > > *Subject:* [sacm] Components for Vulnerability Assessment
> >     > >
> >     > >
> >     > >
> >     > > Hi All:
> >     > >
> >     > >
> >     > >
> >     > > We've got a list of components we think we care about for our
> >     > > vulnerability assessment scenario (focusing on the narrowest "ideal
> >     > > case" through the scenario for the time being.
> >     > >
> >     > >
> >     > >
> >     > > These are:
> >     > >
> >     > >
> >     > >
> >     > > * Vulnerability Detection Data Repository
> >     > >
> >     > > * Vulnerability Assessor
> >     > >
> >     > > * Endpoint Repository
> >     > >
> >     > > * Collector
> >     > >
> >     > > * Target Endpoint
> >     > >
> >     > > * Assessment Results Repository
> >     > >
> >     > >
> >     > >
> >     > > For reference, see our wiki [1] and/or the slides from IETF 98 [2]
> >     > > and/or the minutes from IETF 98 [3]
> >     > >
> >     > >
> >     > >
> >     > > Question to the WG: Is this an appropriate initial list of
> >     components?
> >     > >
> >     > >
> >     > >
> >     > > Please opine within the next few days (say by end of your day on
> >     > > Thursday, wherever you may be), so that we can generate some
> >     momentum
> >     > > on this effort.
> >     > >
> >     > >
> >     > >
> >     > > Kind regards,
> >     > >
> >     > >
> >     > >
> >     > > Adam
> >     > >
> >     > >
> >     > >
> >     > > [1]
> >     > >
> >     https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenar
> >     > > io
> >     > >
> >     > > [2]
> >     > >
> >     https://www.ietf.org/proceedings/98/slides/slides-98-sacm-vulnerabilit
> >     > > y-scenario-discussion-00.pdf
> >     > >
> >     > > [3]
> >     https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00.txt
> >     > >
> >     > >
> >     > >
> >     > >
> >     > >
> >     > >
> >     > >
> >     > > _______________________________________________
> >     > > sacm mailing list
> >     > > [e-mail] <mailto:[e-mail]>
> >     > > https://www.ietf.org/mailman/listinfo/sacm
> >     > >
> >
> >
> >
> > _______________________________________________
> > sacm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sacm
> >
> 
> --
> _________________________________________________________________
> _____________________
> 
> Carl-Heinz Genzel
> Wissenschaftlicher Mitarbeiter
> Rechnernetze / Informationssicherheit
> Institut für Informatik und Automation
> Hochschule Bremen / University of Applied Sciences Flughafenallee 10, 28199
> Bremen, Germany
> tel.:  [phone]
> mobil: [phone]
> email: [e-mail]
> _________________________________________________________________
> __________
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm