Subject: [sacm] Components for Vulnerability Assessment

From: Adam Montville <[email-masked]>
Date: Tue, 18 Apr 2017 13:03:55 +0000

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/SacmVulnerabilityAssessmentScenario

[2]
https://www.ietf.org/proceedings/98/slides/slides-98-sacm-vulnerability-scenario-discussion-00.pdf

[3] https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00.txt

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 18 Apr 2017 14:21:22 +0000

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:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, April 18, 2017 9:04 AM
To: [email-masked]
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:

For reference, see our wiki [1] and/or the slides from IETF 98 [2] and/or the minutes from IETF 98 [3]

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/SacmVulnerabilityAssessmentScenario
[2] https://www.ietf.org/proceedings/98/slides/slides-98-sacm-vulnerability-scenario-discussion-00.pdf
[3] https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00.txt

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Apr 2017 16:48:38 +0200

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:[email-masked]] *On Behalf Of *Adam Montville
> *Sent:* Tuesday, April 18, 2017 9:04 AM
> *To:* [email-masked]
> *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:
>
>
>
> 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
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 18 Apr 2017 14:55:27 +0000

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.

Thanks,

Danny

> -----Original Message-----
> From: Henk Birkholz [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2017 10:49 AM
> To: Haynes, Dan <[email-masked]>; Adam Montville
> <[email-masked]>; [email-masked]
> Subject: Re: [sacm] Components for Vulnerability Assessment
> 
> Hello Danny,
> 
> 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?
> 
> software component. Despite the fact that it looks simpler to just add the
> "Assessment Result" to the ""Endpoint Characterization Records"
> 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.
> 
> > 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]

---

From: Adam Montville <[email-masked]>
Date: Tue, 18 Apr 2017 15:27:34 +0000

On Tue, Apr 18, 2017 at 9:55 AM Haynes, Dan <[email-masked]> 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:
> 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.
> 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>
>

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.

> Results
> the

---

From: Carl-Heinz Genzel <[email-masked]>
Date: Wed, 19 Apr 2017 07:47:41 +0200

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 <[email-masked]
> <mailto:[email-masked]>> 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.
>     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>
> 
> 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.
> 
> 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
> 
>     > From: Henk Birkholz [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > To: Haynes, Dan <[email-masked] <mailto:[email-masked]>>;
>     Adam Montville
>     > <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>     Asset/Inventory
>     > > *From:*sacm [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Adam
>     > > Montville
>     > > *To:* [email-masked] <mailto:[email-masked]>
>     > > [3]
>     https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00.txt
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > [email-masked] <mailto:[email-masked]>

-- 
______________________________________________________________________________________

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.:  +49 421 5905 5442
mobil: +49 179 1636844
email: [email-masked]
___________________________________________________________________________

---

From: Muhammad Nasir Mumtaz Bhutta <[email-masked]>
Date: Wed, 19 Apr 2017 05:50:08 +0000

Hi every one, 
I have joined this group recently and want to know more about the discussion topic. It looks like some architecture is being discussed in the thread. 

>From where should I get more information about this so that I can participate and contribute my thoughts as well. 

Thanks. 

Regards,
===============================================
Muhammad Nasir Mumtaz Bhutta, PhD
Assistant Professor,
Information Systems Dept
College of Computer Sciences and Information Technology
King Faisal University
Saudi Arabia 
Alahssa 31982 P.O. Box 400
Tel  + 966 (013) 589 9207
Fax + 966 (013) 589 9236

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, April 18, 2017 5:55 PM
To: Henk Birkholz <[email-masked]>; Adam Montville <[email-masked]>; [email-masked]
Subject: Re: [sacm] Components for Vulnerability Assessment

Hi Henk,

---
Per Slide 7:

Thanks,

Danny

> > I think this is a good list for me, but, should the assessment 
> > results repository be merged into the endpoint repository?
> >
> > Thanks,
> >
> > Danny
> >
> >
> >
> > Thursday, wherever you may be), so that we can generate some 
> > momentum on this effort.
> >
> >
> >
> > Kind regards,
> >
> >
> >
> > Adam
> >
> >
> >
> > [1]
> > https://www.ietf.org/proceedings/98/slides/slides-98-sacm-vulnerabil
> > it
> > y-scenario-discussion-00.pdf
> >
> > [3]

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 19 Apr 2017 12:34:11 +0000

Hi Muhammad,

You will want to check out the Vulnerability Assessment Scenario first which can be found here (https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario). You can also find additional information in this thread (https://www.ietf.org/mail-archive/web/sacm/current/msg04698.html).

Hope this helps!

Thanks,

Danny

> From: Muhammad Nasir Mumtaz Bhutta [mailto:[email-masked]]
> Sent: Wednesday, April 19, 2017 1:50 AM
> To: Haynes, Dan <[email-masked]>; Henk Birkholz
> <[email-masked]>; Adam Montville
> Subject: RE: [sacm] Components for Vulnerability Assessment
> 
> Hi every one,
> I have joined this group recently and want to know more about the discussion
> topic. It looks like some architecture is being discussed in the thread.
> 
> College of Computer Sciences and Information Technology King Faisal University
> Saudi Arabia Alahssa 31982 P.O. Box 400 Tel  + 966 (013) 589 9207 Fax + 966
> (013) 589 9236
> 
> 
> 
> To: Henk Birkholz <[email-masked]>; Adam Montville
> (https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00) it says:
> 
> ---
> Per Slide 7:
> 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.

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 19 Apr 2017 12:36:03 +0000

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

> From: sacm [mailto:[email-masked]] On Behalf Of Carl-Heinz Genzel
> Sent: Wednesday, April 19, 2017 1:48 AM
> To: [email-masked]
> > 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
> >
> >     results
> >     momentum
> Hochschule Bremen / University of Applied Sciences Flughafenallee 10, 28199
> Bremen, Germany
> tel.:  +49 421 5905 5442
> mobil: +49 179 1636844

---

From: Adam Montville <[email-masked]>
Date: Wed, 19 Apr 2017 18:22:21 +0000

+1, thanks Danny.

On Wed, Apr 19, 2017 at 7:34 AM Haynes, Dan <[email-masked]> wrote:

> Hi Muhammad,
>
> You will want to check out the Vulnerability Assessment Scenario first
> which can be found here (
> https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario).
> You can also find additional information in this thread (
> https://www.ietf.org/mail-archive/web/sacm/current/msg04698.html).
>
> Hope this helps!
>
> Thanks,
>
> Danny
>
> > From where should I get more information about this so that I can
> participate
> > and contribute my thoughts as well.
> >
> > Thanks.
> >
> >
> > Regards,
> > Saudi Arabia Alahssa 31982 P.O. Box 400 Tel  + 966 (013) 589 9207
> <+966%2013%20589%209207> Fax + 966
> > (013) 589 9236
> >
> >
> >
> functional
> we
> data
> > Comment: (Adam Montville): The "results repository" will now go into the
> "end-
> > point repository.
> > ---
> >

---

From: Adam Montville <[email-masked]>
Date: Wed, 19 Apr 2017 18:25:44 +0000

Thanks for pointing that out. Yeah, IIRC, we were talking about the
differences between the two sequence diagrams, so it might well be the case
that the "affirmation" was about the diagram and not about any consensus in
the room.

Adam

On Wed, Apr 19, 2017 at 7:36 AM Haynes, Dan <[email-masked]> wrote:

> 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
>
> > >     Comment: (Adam Montville): The "results repository" will now go
> into
> > >     the "end-point repository.
> > >     ---
> > >
> > >     > software component. Despite the fact that it looks simpler to
> just
> > >     add the
> > >     > > For reference, see our wiki [1] and/or the slides from IETF 98
> [2]
> > >     > > and/or the minutes from IETF 98 [3]
> > >     > >
> > >     > >
> > >     > >
> > tel.:  +49 421 5905 5442 <+49%20421%2059055442>
> > mobil: +49 179 1636844 <+49%20179%201636844>

---

From: Adam Montville <[email-masked]>
Date: Fri, 21 Apr 2017 13:00:49 +0000

Hello Everyone,

After some discussion on this topic, I feel like we've got no real
objection to this proposed list of components. As such, this brings us back
to the second version of the sequence diagram that some of us were working
with not too long ago (see attached PDF vector diagram).

Given that set of components, we can now start talking about the expected
communications between them in an ideal case through the system. Remember
that the VDI (vulnerability information) is assumed to have been
transformed and placed into the VDD (vulnerability detection) Repository.
I've numbered the flows in the attached sequence diagram to show the
proposed order and so that we can talk about each flow by that number.

Does this flow feel right to everyone on the list? What needs to be
different? What alternate flows may exist for the basic case of checking
inventory against a new vulnerability?

Let's carry this discussion on for a week or so. (Do we need longer?)

Kind regards,

Adam

On Tue, Apr 18, 2017 at 8:03 AM Adam Montville <[email-masked]>
wrote:

> vulnerability assessment scenario (focusing on the narrowest "ideal case"
> through the scenario for the time being.
>
> These are:
>
> https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario
> [2]