Subject: Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability Scenario Working Session)

From: Adam Montville <[email-masked]>
Date: Thu, 02 Mar 2017 12:05:14 +0000

Yes, I agree that identifying trigger points is useful and helps with
clarity.  What does such identification do for pushing data through our
notional system?  From my perspective, getting information through the
system to answer questions is the hard part.  Triggers seem relatively
easy.  Then, perhaps I'm missing something.

On Tue, Feb 28, 2017 at 11:45 PM Jerome Athias <[email-masked]>
wrote:

> 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.
>
>
>
> 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]>
> 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]> wrote:
>
> 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
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>
> 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?
>
>
>
>
>     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.
>
>
> 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.
>
>
>
>
>     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?
>
>
> 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 :)
>
>
>
>
>
>     The "keeping pools of data in-sync" seems to be introducing extra steps
>     in the work-flow.
>
>
> 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.
>
>
>
>
>     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.
>
>
> 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.
>
>
>
>
>     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...) :)
>
>
> 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! :)
>
>
>
>
>     I just try to get a feasible grasp of the actual workflow that the
>     diagram is intended to represent.
>
>
> The most basic path through the system.
>
>
>
>     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?
>
>
> 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.
>
>
>
>
>     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.
>     >
>     > What works for our purposes?
>     >
>     > Adam
>     >
>     > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >     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]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>
>
>     <mailto:[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.
>     >
>     >         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]
>     <mailto:[email-masked]>
>
>     <mailto:[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]>
>     >             <mailto:[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 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
>     >
>     >
>     >
>     > _______________________________________________
>     > sacm mailing list
>
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/sacm
>     >
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
>
>
>

---

From: Jerome Athias <[email-masked]>
Date: Thu, 2 Mar 2017 15:33:40 +0300

no, you're right and I agree.
I was just trying to clarify that Henk and Bill assumptions were correct

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

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

---

From: Adam Montville <[email-masked]>
Date: Thu, 02 Mar 2017 12:38:33 +0000

Ah, I see.  (That's what I get for not paying attention for too long)

On Thu, Mar 2, 2017 at 6:33 AM Jerome Athias <[email-masked]> wrote:

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