Subject: Re: [sacm] Notes on Vulnerability Scenario Working Session

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 16:28:07 +0000

Hi Everyone.  A few of us were able to make the vulnerability scenario call
today and I think we had a good, though at times spirited, discussion.  We
did record the meeting, which is available at [1].  We discussed the
attached (annotated with some meeting notes) UML-ish sequence diagram.  I
had created that diagram to start a conversation (mission accomplished on
that front I think) -- a conversation that would lead us toward identifying
the discrete components, interfaces, and information required to be sent
over those interfaces.  The UML-ish diagram represents a *single* flow
through the system -- a "one-time" flow through the system.  It ignores,
for the time being, the continuous aspect of our charter in favor of
getting started with the basics.  Once we have a good understanding of the
basics -- the components, interfaces, and information required -- we can
start look at a continuous monitoring sequence (which could be represented
as a distinct diagram) to determine what more we need.  Then, I think, we
can start drafting solutions.

One of the first issues is that we need to figure out if the components in
the base flow are accurate.  The main suggestion we've tossed around so far
is to combine the Endpoint Repository with the Assessment Result Repository.

We talked briefly about what interface we could use for the VDD Repository,
and naturally ROLIE came up as an option.

We talked a little bit about the first "get endpoints" operation between
the Vulnerability Assessor and the Endpoint Repository -- specifically
about whether we should represent on this sequence diagram that information
supporting a judgement of "stale" would be needed.

We left open the time when we would next meet, favoring to work that out
on-list.  Next week is TCG, so that may be difficult; the following week is
RSA, so that may be difficult.

For those who were in attendance today, please add to this note with your
comments/corrections.

Kind regards,

Adam

[1] https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E

On Mon, Jan 30, 2017 at 11:21 AM Adam Montville <[email-masked]>
wrote:

> Hi everyone.  Just a friendly reminder that we are planning to meet again
> this Thursday at the same time (2/2 @ 10am Eastern/3pm UTC) using SACM's
> meeting room at https://ietf.webex.com/meet/sacm.
>
> Kind regards,
>
> Adam
>
>
> On Thu, Jan 19, 2017 at 11:35 AM Adam Montville <
> [email-masked]> wrote:
>
> Hello. A few of us met informally today to discuss the vulnerability
> scenario in some more detail with the goal of maintaining the narrow focus
> on a vulnerability assessment slice through our notional environment.  We
> are tending to look at major components as black boxes with interfaces and
> data format expectations, and we are not necessarily concerned with how
> those components do things internally/behind the scenes.
>
> The meeting was recorded (you can find it with today's date at [1]).  The
> topic of discussion was primarily in the "phase 1" area of what Danny sent
> to the list not very long ago [2], and resulted in a *starting point*
> diagram [3].
>
> The group who met today are (roughly) agreed on the six main "components"
> represented in that diagram, but also see that we have some work ahead.
> Specifically, we quickly recognized that some of the assumptions the
> vulnerability draft makes may be assumptions we cannot afford to make and
> need to include in the exploration.
>
> We thought it would be a good idea to have another informal discussion in
> a couple of weeks (February 2) at the same time (10am Eastern / 3pm UTC),
> using the same WebEx [4].   At that time we intend to roll through the
> vulnerability assessment scenario assumptions in an effort to determine
> which ones can be left as assumptions and which ones cannot.  Then we'll
> take another look at the diagram and work on its next version.
>
> Stay tuned.
>
> Thanks to Danny, Stephen, and Jerome for joining and contributing!
>
> Kind regards,
>
> Adam
>
>
> [1] https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
> [2] https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU58MXDM
> [3] https://drive.google.com/open?id=0B8Wf9Un5FdCbMU5pdTRjejJtNHc
> [4] https://ietf.webex.com/meet/sacm
>
>

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 16:40:49 +0000

Once folks have had an opportunity to review the vulnerability scenario
information we've been working on, what are your thoughts on the main
components we're presently focused on for this narrowly scoped exercise?
These are:

Vulnerability Detection Data Repository
Vulnerability Assessor
Endpoint Repository
Collector
Assessment Result Repository
Endpoint

On Thu, Feb 2, 2017 at 10:28 AM Adam Montville <[email-masked]>
wrote:

> Hi Everyone.  A few of us were able to make the vulnerability scenario
> call today and I think we had a good, though at times spirited,
> discussion.  We did record the meeting, which is available at [1].  We
> discussed the attached (annotated with some meeting notes) UML-ish sequence
> diagram.  I had created that diagram to start a conversation (mission
> accomplished on that front I think) -- a conversation that would lead us
> toward identifying the discrete components, interfaces, and information
> required to be sent over those interfaces.  The UML-ish diagram represents
> a *single* flow through the system -- a "one-time" flow through the
> system.  It ignores, for the time being, the continuous aspect of our
> charter in favor of getting started with the basics.  Once we have a good
> understanding of the basics -- the components, interfaces, and information
> required -- we can start look at a continuous monitoring sequence (which
> could be represented as a distinct diagram) to determine what more we
> need.  Then, I think, we can start drafting solutions.
>
> We talked briefly about what interface we could use for the VDD
> Repository, and naturally ROLIE came up as an option.
>
> On Mon, Jan 30, 2017 at 11:21 AM Adam Montville <

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 2 Feb 2017 17:53:37 +0100

## A Few Comments

* I agree that the diagram pretty much captures a "one time snapshot".
* Collapsing the highlighted components seems to be a feasible idea.
* I agree that the diagram could be implemented given an appropriate set 
of initial data.
* I suppose there is the risk that one has to scrap everything 
implemented when we start trying to make it a continuous process.
* I'd recommend to start with a generic block of PoC code that provides 
the functions of a SACM component to get input and create output (maybe 
using dbus, chained event-loops, blocking waits on fifos, or IP over 
loopback? A better coder than me should bash these suggestions).

## One, Two, or Three Tasks

* Creating component code that can create the (downstream?) flow of 
information is urgent and important, I think.
* Enhancing the diagram to represent the continuous cycle with at least 
one trigger (as illustrated by Bill; new software, new VDI, new 
endpoints, stale results, etc.) is important, but not as urgent. It 
might save time though by reducing the afore mentioned risk to shoot 
your self in the foot by creating a too specific proof of concept of the 
one time snapshot approach, I think.
* Selecting a set of initial data derived from OVAL to be used in the 
one shot snapshot seems to be a feasible approach to me, but I am not 
sure how the group thinks about that.

Does that assessment represent the general opinion, or is that just mine?

Viele Grüße,

Henk

On 02/02/2017 05:28 PM, Adam Montville wrote:
> discussed the attached (annotated with some meeting notes) UML-ish
> sequence diagram.  I had created that diagram to start a conversation
> (mission accomplished on that front I think) -- a conversation that
> would lead us toward identifying the discrete components, interfaces,
> and information required to be sent over those interfaces.  The UML-ish
> diagram represents a *single* flow through the system -- a "one-time"
> flow through the system.  It ignores, for the time being, the continuous
> aspect of our charter in favor of getting started with the basics.  Once
> we have a good understanding of the basics -- the components,
> interfaces, and information required -- we can start look at a
> continuous monitoring sequence (which could be represented as a distinct
> diagram) to determine what more we need.  Then, I think, we can start
> drafting solutions.
>
> One of the first issues is that we need to figure out if the components
> in the base flow are accurate.  The main suggestion we've tossed around
> so far is to combine the Endpoint Repository with the Assessment Result
> Repository.
>
> about whether we should represent on this sequence diagram that
> information supporting a judgement of "stale" would be needed.
>
> on-list.  Next week is TCG, so that may be difficult; the following week
> is RSA, so that may be difficult.
>
> For those who were in attendance today, please add to this note with
> your comments/corrections.
>
> Kind regards,
>
> Adam
>
> On Mon, Jan 30, 2017 at 11:21 AM Adam Montville
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi everyone.  Just a friendly reminder that we are planning to meet
>     again this Thursday at the same time (2/2 @ 10am Eastern/3pm UTC)
>     using SACM's meeting room at https://ietf.webex.com/meet/sacm.
>
>     Kind regards,
>
>     Adam
>
>
>     On Thu, Jan 19, 2017 at 11:35 AM Adam Montville
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hello. A few of us met informally today to discuss the
>         vulnerability scenario in some more detail with the goal of
>         maintaining the narrow focus on a vulnerability assessment slice
>         through our notional environment.  We are tending to look at
>         major components as black boxes with interfaces and data format
>         expectations, and we are not necessarily concerned with how
>         The meeting was recorded (you can find it with today's date at
>         [1]).  The topic of discussion was primarily in the "phase 1"
>         area of what Danny sent to the list not very long ago [2], and
>         resulted in a *starting point* diagram [3].
>
>         The group who met today are (roughly) agreed on the six main
>         "components" represented in that diagram, but also see that we
>         have some work ahead.  Specifically, we quickly recognized that
>         some of the assumptions the vulnerability draft makes may be
>         assumptions we cannot afford to make and need to include in the
>         exploration.
>
>         We thought it would be a good idea to have another informal
>         discussion in a couple of weeks (February 2) at the same time
>         (10am Eastern / 3pm UTC), using the same WebEx [4].   At that
>         time we intend to roll through the vulnerability assessment
>         scenario assumptions in an effort to determine which ones can be
>         left as assumptions and which ones cannot.  Then we'll take
>         another look at the diagram and work on its next version.
>
>         Stay tuned.
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 17:44:46 +0000

Thanks for the feedback!  I've attached a modified version of the diagram
that collapses the endpoint and assessment result repositories (by keeping
the endpoint repository).  Where would you propose we focus on enhancing
the diagram?  Remember that it's a sequence diagram, which might do well
with some more specific details captured in text or a different form of
diagram.

What do folks think about using one or more OVAL definitions as a starting
point?

Adam

On Thu, Feb 2, 2017 at 10:53 AM Henk Birkholz <
[email-masked]> wrote:

> >         [1]
> https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
> >         [2]
> https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU58MXDM
> >         [3]
> https://drive.google.com/open?id=0B8Wf9Un5FdCbMU5pdTRjejJtNHc

---

From: Bill Munyan <[email-masked]>
Date: Thu, 2 Feb 2017 12:57:00 -0500

Is it worth noting in the diagram (if not, I think it needs to be noted
somewhere nonetheless) that the steps of "get endpoints" and subsequent
"evaluate" should be making some determination of whether or not to collect
for an endpoint?  For example, if an endpoint has no assessment results or
the assessment results are considered "stale", then the collection step
would take place.  I understand that could be too much detail for the scope
of the diagram, but I just wanted to note it somewhere.

Cheers,
-Bill M.

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 17:59:53 +0000

Yes! Noting that information is critical, but if we set out to put all of
that in the diagram, we'll lose.  What if we agree to the sequence at the
high level, then number the steps, and then write about those steps in the
wiki after talking about them here and in informal sessions for the win?

On Thu, Feb 2, 2017 at 11:57 AM Bill Munyan <[email-masked]>
wrote:

> On Thu, Feb 2, 2017 at 12:44 PM, Adam Montville <

---

From: Bill Munyan <[email-masked]>
Date: Thu, 2 Feb 2017 13:01:21 -0500

+1

On Thu, Feb 2, 2017 at 12:59 PM, Adam Montville <[email-masked]>
wrote:

>> What do folks think about using one or more OVAL definitions as a
>> starting point?
>>
>> Adam
>>
>>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 2 Feb 2017 18:34:04 +0000

Is the operation “get endpoints” a single operation or is it multiple operations “get endpoint characteristics” and “get previously collected data”, or even “query if there is previously collected data that matches X in timeframe Y?” It would be helpful to be more specific here since the information exchanges may differ.

Should the “collect” between vulnerability assessor and collector should be “request collection (for a set of endpoints)”?

The first “evaluate” (from the top) could be thought of as an applicability / staleness evaluation. This drives what gaps in information and endpoints should be targeted for collection.

The second “(re)evaluate” is the actual posture evaluation we are working to support. Right?

Regards,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Bill Munyan
Sent: Thursday, February 02, 2017 12:57 PM
To: Adam Montville <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [sacm] Notes on Vulnerability Scenario Working Session

Is it worth noting in the diagram (if not, I think it needs to be noted somewhere nonetheless) that the steps of "get endpoints" and subsequent "evaluate" should be making some determination of whether or not to collect for an endpoint?  For example, if an endpoint has no assessment results or the assessment results are considered "stale", then the collection step would take place.  I understand that could be too much detail for the scope of the diagram, but I just wanted to note it somewhere.

Cheers,
-Bill M.

On Thu, Feb 2, 2017 at 12:44 PM, Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the feedback!  I've attached a modified version of the diagram that collapses the endpoint and assessment result repositories (by keeping the endpoint repository).  Where would you propose we focus on enhancing the diagram?  Remember that it's a sequence diagram, which might do well with some more specific details captured in text or a different form of diagram.

What do folks think about using one or more OVAL definitions as a starting point?

Adam

On Thu, Feb 2, 2017 at 10:53 AM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
## A Few Comments

Viele Grüße,

Henk

On 02/02/2017 05:28 PM, Adam Montville wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> [email-masked]<mailto:[email-masked]>

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

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 19:06:58 +0000

Will try inline...

On Thu, Feb 2, 2017 at 12:34 PM Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Is the operation “get endpoints” a single operation or is it multiple
> operations “get endpoint characteristics” and “get previously collected
> data”, or even “query if there is previously collected data that matches X
> in timeframe Y?” It would be helpful to be more specific here since the
> information exchanges may differ.
>

Don't know yet - this is exactly the sort of conversation we should be
having! What if we numbered them as is, then discuss each in turn, if for
no other reason than tracking what we need to do and what we've done?

>
>
> Should the “collect” between vulnerability assessor and collector should
> be “request collection (for a set of endpoints)”?
>

I don't see why not.  That was the intent -- request or otherwise invoke
collection.

>
>
> The first “evaluate” (from the top) could be thought of as an
> applicability / staleness evaluation. This drives what gaps in information
> and endpoints should be targeted for collection.
>

Yes, that was the intent.  Evaluate what we can with available on-hand
information.

> The second “(re)evaluate” is the actual posture evaluation we are working

Yep, that's my take.

>
>
> Regards,
>
> Dave
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Bill Munyan
> *Sent:* Thursday, February 02, 2017 12:57 PM
> *To:* Adam Montville <[email-masked]>
> *Cc:* Henk Birkholz <[email-masked]>; [email-masked]
>
>
> *Subject:* Re: [sacm] Notes on Vulnerability Scenario Working Session
>
>
>

---

From: Carl-Heinz Genzel <[email-masked]>
Date: Thu, 2 Feb 2017 20:21:22 +0100

Hello Everybody,

you all may have seen my name in the WebEx today. However I didn't
introduce myself yet. I apologize for that. Please don't hold that
against me. I just didn't want to hinder the discussion, since I am very
new to this work group and the IETF work in general.

My name is Carl-Heinz Genzel and I am a research assistant at the
University of Applied Sciences Bremen (Germany) usually working on
topics around security, smart grids, and trusted computing.

I find the SACM WG very interesting, however I am not certain at the
moment about how I'm be able to contribute. However I enjoyed your
discussion to day.

There may be one thing, I like to comment about the diagram. I hope I do
understand the SACM drafts as well as the diagram correctly, and will
not sound absurd.

For me it seems that a direct call from the vulnerability assessor to
the collector would raise a question about separation of concerns, since
the endpoint repository is the central component for endpoint
information. In this regard, should not the endpoint repository call
collect as consequence of the get endpoints call instead of a direct
call to the collector, if information is stale or missing?

Best Regards,
Carl-Heinz Genzel

Am 02.02.2017 um 18:44 schrieb Adam Montville:
> Thanks for the feedback!  I've attached a modified version of the
> diagram that collapses the endpoint and assessment result repositories
> (by keeping the endpoint repository).  Where would you propose we focus
> on enhancing the diagram?  Remember that it's a sequence diagram, which
> might do well with some more specific details captured in text or a
> different form of diagram.
> 
> On Thu, Feb 2, 2017 at 10:53 AM Henk Birkholz
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     ## A Few Comments
> 
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >     <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     > [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: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 20:05:50 +0000

> topics around security, smart grids, and trusted computing.

We're happy to have you here, thank you for joining.

> call to the collector, if information is stale or missing?

This seems reasonable.  I am interested in what others think about the
suggestion as well.

In practice today, many vulnerability assessors are themselves collectors.
Still, it seams feasible for the vulnerability assessor to react after
initial evaluation by telling the endpoint repository that it has not
enough information, which could then cause the endpoint repository to
trigger additional collection.

I am not sure it is written that way in our draft, which does not mean that
we can't change...

> tel.:  +49 421 5905 5442 <+49%20421%2059055442>
> mobil: +49 179 1636844 <+49%20179%201636844>

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 21:11:56 +0000

Just to follow up on this, I've attached an alternate to v3, which puts the
Endpoint Repository between the Vulnerability Assessor and Collector.

Also, for what it's worth, here's the sentence I based the diagram on in
the first place: "If the data possessed by the endpoint management
capabilities is insufficient, a Collection Task is triggered and the
necessary data is collected from the target endpoint".

Adam

On Thu, Feb 2, 2017 at 2:05 PM Adam Montville <[email-masked]>
wrote:

> In practice today, many vulnerability assessors are themselves
> collectors.  Still, it seams feasible for the vulnerability assessor to
> react after initial evaluation by telling the endpoint repository that it
> has not enough information, which could then cause the endpoint repository
> to trigger additional collection.
>
> I am not sure it is written that way in our draft, which does not mean
> that we can't change...
>
>
>
>
>
> Best Regards,
> Carl-Heinz Genzel
>
>
>
>
>
>
>

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Feb 2017 21:12:26 +0000

This time with the attachment.

On Thu, Feb 2, 2017 at 3:11 PM Adam Montville <[email-masked]>
wrote:

> Just to follow up on this, I've attached an alternate to v3, which puts
> the Endpoint Repository between the Vulnerability Assessor and Collector.
>

---

From: Adam Montville <[email-masked]>
Date: Fri, 03 Feb 2017 16:43:59 +0000

I thought I'd try to break this discussion out of it's former thread into
one of its own, in case that makes it easier for folks to opine.  The list
of "components" or "function groups" seems reasonable to me.  In practice,
there *may* be a desire to have that software acting as an endpoint
repository also act as the repository for assessment results.  Or, these
could be implemented in distinct services.

What works for our purposes?

Adam

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 3 Feb 2017 17:41:06 +0000

That works for me.

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, February 02, 2017 1:00 PM
To: Bill Munyan <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [sacm] Notes on Vulnerability Scenario Working Session

Yes! Noting that information is critical, but if we set out to put all of that in the diagram, we'll lose.  What if we agree to the sequence at the high level, then number the steps, and then write about those steps in the wiki after talking about them here and in informal sessions for the win?

On Thu, Feb 2, 2017 at 11:57 AM Bill Munyan <[email-masked]<mailto:[email-masked]>> wrote:
Is it worth noting in the diagram (if not, I think it needs to be noted somewhere nonetheless) that the steps of "get endpoints" and subsequent "evaluate" should be making some determination of whether or not to collect for an endpoint?  For example, if an endpoint has no assessment results or the assessment results are considered "stale", then the collection step would take place.  I understand that could be too much detail for the scope of the diagram, but I just wanted to note it somewhere.

Cheers,
-Bill M.

Adam

Viele Grüße,

Henk

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 3 Feb 2017 17:52:41 +0000

I will try some more comments inline ;).

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, February 02, 2017 2:07 PM
To: Waltermire, David A. (Fed) <[email-masked]>; Bill Munyan <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [sacm] Notes on Vulnerability Scenario Working Session

Will try inline...
On Thu, Feb 2, 2017 at 12:34 PM Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
Is the operation “get endpoints” a single operation or is it multiple operations “get endpoint characteristics” and “get previously collected data”, or even “query if there is previously collected data that matches X in timeframe Y?” It would be helpful to be more specific here since the information exchanges may differ.

Don't know yet - this is exactly the sort of conversation we should be having! What if we numbered them as is, then discuss each in turn, if for no other reason than tracking what we need to do and what we've done?

[danny] is it possible that it depends on how the data is stored/organized in the “endpoint repository”? For example, one vendor might make endpoints its own table whereas another vendor might have the data spread across multiple tables and require multiple queries to get the endpoints. With that said, do we care if it takes one query or many queries as long as we (1) have a standard interface to query the repository and (2) get the resulting data in a format that we understand (in this case a list of endpoints)?
Should the “collect” between vulnerability assessor and collector should be “request collection (for a set of endpoints)”?

I don't see why not.  That was the intent -- request or otherwise invoke collection.

[danny] works for me.

Yes, that was the intent.  Evaluate what we can with available on-hand information.

[danny] agree.

[danny] agree here too.

Regards,
Dave

From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bill Munyan
Sent: Thursday, February 02, 2017 12:57 PM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: Henk Birkholz <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Cheers,
-Bill M.

Adam

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 3 Feb 2017 22:25:01 +0100

Hi group,

to recap my understanding:

There will be trigger conditions that initiate collections of fresh 
endpoint attributes (from which endpoint posture can be derived) from a 
target endpoint.

The obvious trigger condition that an asserting component (in every 
diagram, I think, that is the Vulnerability Assessor. This assumption is 
based on the interpretation of the diagram, not based on the name of the 
component). From my point of view, in order to assert that a known 
record is, for example, "stale" (aka does not satisfy an declarative 
guidance that expresses the quality of freshness) or, as another 
example, is not yet created the Vulnerability Assessor requires an 
always up-to-date and exhaustive list of all Assessment Result records.

In consequence, I would assume that either the the Assessment Result 
Repository component collapses with the Vulnerability Assessor or the 
Vulnerability Assessor always retains a complete in-sync copy of the 
Assessment Result Repository.

Alternatively, the Assessment Result Repository component is collapsed 
with the Endpoint Repository (as proposed in diagram v3), in which case 
now the Vulnerability Assessor to retain an continuously in-sync copy of 
the Endpoint Repository? If it is to trigger on the "stale" condition?

The "keeping pools of data in-sync" seems to be introducing extra steps 
in the work-flow.

A pro for this would be that there could be multiple additional 
consumers of Assessment Results that justify an interface that provides 
that data to multiple parties.

A con for this is the universal "redundant data stores always pose a 
source of complexity and hence risk of inconsistency" argument.

Another point of view could be that the "evaluation task" is independent 
from the "trigger collection" (I just made that one up) task? Or maybe 
it is associated with the worn component?

Multiple emerging architectures include an orchestration component that 
consumes notification of changes and derives appropriate actions that it 
can trigger or even conduct. Please note, I am not advocating to 
introduce yet another component type (which would again add complexity, 
error, scope creep...) :)

I just try to get a feasible grasp of the actual workflow that the 
diagram is intended to represent.

What am I missing? I actually am surprised that the Assessment Result 
Repository merges with the Endpoint Repository and not the Vulnerability 
Assessor. What is the advantage?

Best,

Henk

On 02/03/2017 05:43 PM, Adam Montville wrote:
> I thought I'd try to break this discussion out of it's former thread
> into one of its own, in case that makes it easier for folks to opine.
> The list of "components" or "function groups" seems reasonable to me.
> In practice, there *may* be a desire to have that software acting as an
> endpoint repository also act as the repository for assessment results.
> Or, these could be implemented in distinct services.
>
> On Thu, Feb 2, 2017 at 10:40 AM Adam Montville
>     Once folks have had an opportunity to review the vulnerability
>     scenario information we've been working on, what are your thoughts
>     on the main components we're presently focused on for this narrowly
>     scoped exercise?  These are:
>
>     On Thu, Feb 2, 2017 at 10:28 AM Adam Montville
>         Hi Everyone.  A few of us were able to make the vulnerability
>         scenario call today and I think we had a good, though at times
>         spirited, discussion.  We did record the meeting, which is
>         available at [1].  We discussed the attached (annotated with
>         some meeting notes) UML-ish sequence diagram.  I had created
>         that diagram to start a conversation (mission accomplished on
>         that front I think) -- a conversation that would lead us toward
>         identifying the discrete components, interfaces, and information
>         required to be sent over those interfaces.  The UML-ish diagram
>         represents a *single* flow through the system -- a "one-time"
>         flow through the system.  It ignores, for the time being, the
>         continuous aspect of our charter in favor of getting started
>         with the basics.  Once we have a good understanding of the
>         basics -- the components, interfaces, and information required
>         -- we can start look at a continuous monitoring sequence (which
>         could be represented as a distinct diagram) to determine what
>         more we need.  Then, I think, we can start drafting solutions.
>
>         One of the first issues is that we need to figure out if the
>         components in the base flow are accurate.  The main suggestion
>         we've tossed around so far is to combine the Endpoint Repository
>         with the Assessment Result Repository.
>
>         We talked a little bit about the first "get endpoints" operation
>         between the Vulnerability Assessor and the Endpoint Repository
>         -- specifically about whether we should represent on this
>         sequence diagram that information supporting a judgement of
>         "stale" would be needed.
>
>         We left open the time when we would next meet, favoring to work
>         that out on-list.  Next week is TCG, so that may be difficult;
>         the following week is RSA, so that may be difficult.
>
>         For those who were in attendance today, please add to this note
>         with your comments/corrections.
>
>         Kind regards,
>
>         Adam
>
>             Hi everyone.  Just a friendly reminder that we are planning
>             to meet again this Thursday at the same time (2/2 @ 10am
>             Eastern/3pm UTC) using SACM's meeting room at
>             https://ietf.webex.com/meet/sacm.
>
>             Kind regards,
>
>             Adam
>
>
>             <mailto:[email-masked]>> wrote:
>
>                 vulnerability scenario in some more detail with the goal
>                 of maintaining the narrow focus on a vulnerability
>                 assessment slice through our notional environment.  We
>                 are tending to look at major components as black boxes
>                 with interfaces and data format expectations, and we are
>                 not necessarily concerned with how those components do
>                 things internally/behind the scenes.
>
>                 The meeting was recorded (you can find it with today's
>                 date at [1]).  The topic of discussion was primarily in
>                 the "phase 1" area of what Danny sent to the list not
>                 very long ago [2], and resulted in a *starting point*
>                 diagram [3].
>
>                 The group who met today are (roughly) agreed on the six
>                 main "components" represented in that diagram, but also
>                 see that we have some work ahead.  Specifically, we
>                 quickly recognized that some of the assumptions the
>                 vulnerability draft makes may be assumptions we cannot
>                 afford to make and need to include in the exploration.
>
>                 We thought it would be a good idea to have another
>                 informal discussion in a couple of weeks (February 2) at
>                 the same time (10am Eastern / 3pm UTC), using the same
>                 WebEx [4].   At that time we intend to roll through the
>                 vulnerability assessment scenario assumptions in an
>                 effort to determine which ones can be left as
>                 assumptions and which ones cannot.  Then we'll take

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 3 Feb 2017 23:19:45 +0100

Also inline. I hope it is still readable.

On 02/03/2017 10:55 PM, Adam Montville wrote:
> Thanks for chiming in Henk.  I'll go inline.  Nothing being said as
> chair.  Just making observations.
>
> On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz
> I would disagree.  I have a record from the endpoint repository that it
> timestamped as 3 days old.  My policy says I should not rely on anything
> older than 2 days old.  Then the information is stale, and I instruct to
> collect anew.

If the "I" is the Vulnerability Assessor, how does it always have the 
Assessment Result records to check that declarative guidance? Or do you 
propose (in v3) that the Endpoint Repository is checking that freshness 
continuously and notifying the Vulnerability Assessor?

> I would again disagree.  It may well be that actual software collapses
> these components into one, but it may be that there is a results
> repository, which is used downstream from vulnerability assessment, into
> which the assessor dumps results.

Yes, downstream records are dumped as a result in the corresponding 
repo. But how does the information of not satisfying declarative 
guidance (a result got stale) makes it "upstream" again to trigger 
collection - including imperative guidance what to collect (what just 
got stale)?

>
> Consider when we have configuration assessment down the road.  Would we
> then have a vulnerability assessor and a configuration assessor each
> with their own repository conceptually, or would we be better off with
> one "results repository"?  I think the one.

It depends on scalability, I guess, but in the bare-bone first proof of 
concept it seems to be feasible to collapse related pools of data into 
justthe one, as there are no multiple consumers?

>
> In practice, applications can choose to implement more than one
> conceptual component.

Yes, that is why it is not a problem to collapse sets of functions into 
a single component, in general. I hope this will remain a core feature 
of the architecture at all time.

> Again, I am not necessarily in favor of this viewpoint (and I'm not
> necessarily against).  The endpoint repository represents an interface
> to acquire information about endpoints, which does not necessarily need
> to include assessment results pertaining to those endpoints entirely.

But isn't that what is depicted in the diagram v3: the assessment 
results repo is merged with endpoint repo? Maybe I am actually a little 
bit dense right now :)

> Is it really data in sync?  I understand what you're saying, but to me
> the endpoint repository component is where we find assertions about the
> endpoints, the assessors take those assertions and apply some logic to
> pass judgement on the endpoint, and that judgement is stored in the
> assessment results repository component.

I simply did not assume that a repository is more than a data store. If 
it does continuous assessments of endpoint records it contains, it most 
certainly can trigger a collection. Maybe the label of the component is 
just misleading me here.

> Yes!  There are in practice.  Assessment results have downstream uses
> outside the scope of our charter.

I thought so, but it is of course not part of the single snapshot 
diagram and is therefore only implied at best.

> Bill mentioned something to me offline yesterday about orchestration.
> In the vulnerability scenario, the orchestration is really being
> performed by the assessor.

I think that in the reply above you illustrated that the Endpoint Repo 
also does this assessment by checking for staleness? Or would it "just" 
notify the Assessor to trigger a task? Why not trigger the collector 
directly? What about the imperative guidance what to actually collect again?

It seems that I really have a difficult time to wrap my head around the 
proposal still. Please stay patient with me! :)

> The most basic path through the system.
>
>
>
> I think we're still talking this one through.  What's the advantage to
> collapsing them at all?

Collapsing redundant pools of data is reducing redundancy :) Tasks that 
depend on data that has to be acquired to be conducted benefit from high 
availability and low latency. But I totally understand the "multiple 
consumer" argument.

>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >         wrote:
>     >

---

From: Bill Munyan <[email-masked]>
Date: Mon, 6 Feb 2017 09:17:26 -0500

I wanted to clarify one assumption I have been making when viewing the
diagram.  I am viewing the overall vulnerability scenario as a series of
event-driven use-cases, with this diagram simply depicting one of those
use-cases:  When new VDD is introduced into the scenario.

Feasibly, a number of different events could trigger entry into the
vulnerability scenario, such as a "staleness trigger", or a "new endpoint
added trigger", and many more.  Each of these events could (and should)
have their own diagram outlining how the components interact to request
new/updated VDD, determine the endpoints which should be assessed, and what
to do with their results.  As such, each of the components in the diagrams
can be seen as conceptual, allowing for implementers to determine how best
to consolidate components for their use.

Please bash my thought process if I'm way off on this, but I thought it
might help in this discussion, because it seems like some of the
"disagreement" in the diagram is stemming from "events" which aren't
necessarily applicable to this particular "event use-case".

Cheers,
-Bill M.

On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkholz <
[email-masked]> wrote:

> Yes, downstream records are dumped as a result in the corresponding repo.
> But how does the information of not satisfying declarative guidance (a
> result got stale) makes it "upstream" again to trigger collection -
> including imperative guidance what to collect (what just got stale)?
>
>
> Yes, that is why it is not a problem to collapse sets of functions into a
> single component, in general. I hope this will remain a core feature of the
> architecture at all time.
>
>
>>
>>
> But isn't that what is depicted in the diagram v3: the assessment results
> repo is merged with endpoint repo? Maybe I am actually a little bit dense
> right now :)
>
>
>>
>>
>>
> I simply did not assume that a repository is more than a data store. If it
> does continuous assessments of endpoint records it contains, it most
> I thought so, but it is of course not part of the single snapshot diagram
> and is therefore only implied at best.
>
>
>>
>>
>>     <mailto:[email-masked] <mailto:[email-masked]
>> >>>
>>     >         wrote:
>>     >

---

From: Adam Montville <[email-masked]>
Date: Mon, 06 Feb 2017 17:22:15 +0000

Thanks, Bill.  I agree with your thought process on this.

And, to get back to Henk's questions, I have been thinking of the endpoint
repository as one piece of a larger endpoint management capability.
Whether that endpoint management capability actively or passively collects
such endpoint state information is never explicitly stated in the
vulnerability scenario.  However, I see that going both ways.

Also, I was suggesting that not all pools of data would be redundant.
Endpoint repository doesn't have to store assessment results any more than
assessment results has to store every detail about endpoints.

---

From: Jerome Athias <[email-masked]>
Date: Tue, 28 Feb 2017 13:38:45 +0300

Greetings,

So taking IACD (Ref [0] Appendix A1) as an example for illustration, would
that help to first list triggering "events"/preconditions?

Regards

[0]
https://secwww.jhuapl.edu/iacdcommunityday/Resources/IACD%20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf

On Mon, Feb 6, 2017 at 5:17 PM, Bill Munyan <[email-masked]>
wrote:

>>>     >                 Thanks to Danny, Stephen, and Jerome for joining
>>> and
>>>     >                 contributing!
>>>     >
>>>     >                 Kind regards,
>>>     >
>>>     >                 Adam
>>>     >
>>>     >
>>>     >                 [1]

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 28 Feb 2017 18:31:19 +0000

Jerome,

IMHO, we need to identify the places within the workflow where triggers may occur. These are the workflow entry points. It would also be useful to identify the events that may cause these triggers for clarity sake.

Is this what you are saying?

Regards,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Tuesday, February 28, 2017 5:39 AM
To: Bill Munyan <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; <[email-masked]> <[email-masked]>; Adam Montville <[email-masked]>
Subject: Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability Scenario Working Session)

Greetings,

So taking IACD (Ref [0] Appendix A1) as an example for illustration, would that help to first list triggering "events"/preconditions?

Regards

[0] https://secwww.jhuapl.edu/iacdcommunityday/Resources/IACD%20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf

On Mon, Feb 6, 2017 at 5:17 PM, Bill Munyan <[email-masked]<mailto:[email-masked]>> wrote:
I wanted to clarify one assumption I have been making when viewing the diagram.  I am viewing the overall vulnerability scenario as a series of event-driven use-cases, with this diagram simply depicting one of those use-cases:  When new VDD is introduced into the scenario.

Feasibly, a number of different events could trigger entry into the vulnerability scenario, such as a "staleness trigger", or a "new endpoint added trigger", and many more.  Each of these events could (and should) have their own diagram outlining how the components interact to request new/updated VDD, determine the endpoints which should be assessed, and what to do with their results.  As such, each of the components in the diagrams can be seen as conceptual, allowing for implementers to determine how best to consolidate components for their use.

Please bash my thought process if I'm way off on this, but I thought it might help in this discussion, because it seems like some of the "disagreement" in the diagram is stemming from "events" which aren't necessarily applicable to this particular "event use-case".

Cheers,
-Bill M.

On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Also inline. I hope it is still readable.

On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz
<[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi group,

If the "I" is the Vulnerability Assessor, how does it always have the Assessment Result records to check that declarative guidance? Or do you propose (in v3) that the Endpoint Repository is checking that freshness continuously and notifying the Vulnerability Assessor?

Yes, downstream records are dumped as a result in the corresponding repo. But how does the information of not satisfying declarative guidance (a result got stale) makes it "upstream" again to trigger collection - including imperative guidance what to collect (what just got stale)?

It depends on scalability, I guess, but in the bare-bone first proof of concept it seems to be feasible to collapse related pools of data into justthe one, as there are no multiple consumers?

Yes, that is why it is not a problem to collapse sets of functions into a single component, in general. I hope this will remain a core feature of the architecture at all time.

But isn't that what is depicted in the diagram v3: the assessment results repo is merged with endpoint repo? Maybe I am actually a little bit dense right now :)

I simply did not assume that a repository is more than a data store. If it does continuous assessments of endpoint records it contains, it most certainly can trigger a collection. Maybe the label of the component is just misleading me here.

I thought so, but it is of course not part of the single snapshot diagram and is therefore only implied at best.

I think that in the reply above you illustrated that the Endpoint Repo also does this assessment by checking for staleness? Or would it "just" notify the Assessor to trigger a task? Why not trigger the collector directly? What about the imperative guidance what to actually collect again?

It seems that I really have a difficult time to wrap my head around the proposal still. Please stay patient with me! :)

Collapsing redundant pools of data is reducing redundancy :) Tasks that depend on data that has to be acquired to be conducted benefit from high availability and low latency. But I totally understand the "multiple consumer" argument.

    Best,

    Henk

    On 02/03/2017 05:43 PM, Adam Montville wrote:
    > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    <mailto:[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
    >     <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>
    <mailto:[email-masked]<mailto:[email-masked]>

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

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

---

From: Jerome Athias <[email-masked]>
Date: Wed, 1 Mar 2017 08:45:39 +0300

Yes correct.
I concur with your recommended approach of identifying the workflow entry
points.

An example is a change in the endpoint repository, lets say event: a new
device is connected, one would want to trigger an assessment "a la NAC"

On Tue, Feb 28, 2017 at 9:31 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Jerome,
>
>
>
> IMHO, we need to identify the places within the workflow where triggers
> may occur. These are the workflow entry points. It would also be useful to
> identify the events that may cause these triggers for clarity sake.
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Jerome Athias
> *Sent:* Tuesday, February 28, 2017 5:39 AM
> *To:* Bill Munyan <[email-masked]>
> *Cc:* Henk Birkholz <[email-masked]>; <[email-masked]> <
> [email-masked]>; Adam Montville <[email-masked]>
> *Subject:* Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability
> Scenario Working Session)
>
>
>
> Greetings,
>
>
>
> [0] https://secwww.jhuapl.edu/iacdcommunityday/Resources/
> IACD%20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf
>
>
>
>
>
>
>