Subject: [sacm] Hackathon Goals and Stretch Goals

From: Adam Montville <[email-masked]>
Date: Tue, 02 May 2017 21:40:04 +0000

All:

Last week Dave sent a list of milestones to the list. The first of which
was for the WG to define some goals for the IETF 99 hackathon. I can see at
least one primary goal with at least one stretch goal. The primary goal is
to have running code demonstrating the basic/ideal case through our
vulnerability scenario, where a new vulnerability is discovered and we need
to reach out all the way to the endpoint to determine whether it is in fact
vulnerable. A stretch goal might be to have running code demonstrating a
"monitor for this vulnerability from now on" capability (I'm sure I'm not
stating that as well as I could).

Does anyone have additional goals? Or, are there better ways to state these
particular goals (there probably are)?

Kind regards,

Adam

---

From: Adam Montville <[email-masked]>
Date: Tue, 09 May 2017 19:29:31 +0000

All:

This week Dave and I have had an opportunity to discuss these a bit
further. We've come up with the following set of goals and outcomes:

GOAL: Running code demonstrating the communication needs between identified
components as they pertain to the on-request collection case through the
scenario, where that case is described at
https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario.
OUTCOME: We will have specific understanding of components' boundaries and
the necessary information flows (including information being communicated)
between them.

GOAL: Leverage existing collected data in a data repository. OUTCOME:
Demonstrate that previously collected data can be reused to support
vulnerability assessment

GOAL: Running code to extend that base case to include a mechanism capable
of monitoring a given set of endpoint attributes for change. OUTCOME: We
will have specific understanding of additional architectural considerations
for handling monitoring vs. on-request collection, as well as any
additional information flows required.

Does anyone care to bash these goal-ouctome pairs in the context of our
hackathon plans?  If so, please do so over the next day or two, otherwise
these will become the stated goals for our hackathon.

Kind regards,

Adam

On Tue, May 2, 2017 at 4:40 PM Adam Montville <[email-masked]>
wrote:

> Does anyone have additional goals? Or, are there better ways to state
> these particular goals (there probably are)?
>
> Kind regards,
>
> Adam
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 15 May 2017 17:57:36 +0000

I was thinking that it would be useful to have a user story to implement against for the Hackathon. How about something like the following that maps to our goals:

A vendor identifies a vulnerability in their software product. They produce a new version of their software and publish a vulnerability bulletin that indicates customers should upgrade to the new version to address the vulnerability. The product versions have both a SWID tag and a CoSWID tag. As a customer of this vendor that uses the affected products, we need to build a vulnerability assessment system that is capable of detecting what version of the software is installed and determine if that version is vulnerable using the vendor provided information. The Collector will be capable of gathering software inventory information from one or more target endpoints by:

1)      Requesting software inventory information for the affected software based on an ad-hoc request.

2)      Reporting the software inventory as software changes occur

Collected software inventory information will be stored in the Assessment Results Repository and will be compared to vulnerability detection data retrieved from the Vulnerability Detection Data Repository. The vulnerability detection data will be derived from the vendor provided information in some useful way to be determined by the Vulnerability Assessor.

How does this look?

Regards,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, May 09, 2017 3:30 PM
To: [email-masked]
Subject: Re: [sacm] Hackathon Goals and Stretch Goals

All:

This week Dave and I have had an opportunity to discuss these a bit further. We've come up with the following set of goals and outcomes:

GOAL: Running code demonstrating the communication needs between identified components as they pertain to the on-request collection case through the scenario, where that case is described at https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario.  OUTCOME: We will have specific understanding of components' boundaries and the necessary information flows (including information being communicated) between them.

GOAL: Leverage existing collected data in a data repository. OUTCOME: Demonstrate that previously collected data can be reused to support vulnerability assessment

GOAL: Running code to extend that base case to include a mechanism capable of monitoring a given set of endpoint attributes for change. OUTCOME: We will have specific understanding of additional architectural considerations for handling monitoring vs. on-request collection, as well as any additional information flows required.

Does anyone care to bash these goal-ouctome pairs in the context of our hackathon plans?  If so, please do so over the next day or two, otherwise these will become the stated goals for our hackathon.

Kind regards,

Adam

On Tue, May 2, 2017 at 4:40 PM Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:
All:

Last week Dave sent a list of milestones to the list. The first of which was for the WG to define some goals for the IETF 99 hackathon. I can see at least one primary goal with at least one stretch goal. The primary goal is to have running code demonstrating the basic/ideal case through our vulnerability scenario, where a new vulnerability is discovered and we need to reach out all the way to the endpoint to determine whether it is in fact vulnerable. A stretch goal might be to have running code demonstrating a "monitor for this vulnerability from now on" capability (I'm sure I'm not stating that as well as I could).

Does anyone have additional goals? Or, are there better ways to state these particular goals (there probably are)?

Kind regards,

Adam

---

From: Adam Montville <[email-masked]>
Date: Mon, 15 May 2017 21:27:23 +0000

I think that's a good idea. How do folks feel about this story? Is it
lacking anything? Is it too specific? What would you change about it if you
could?

On Mon, May 15, 2017 at 12:57 PM Waltermire, David A. (Fed) <
[email-masked]> wrote:

> I was thinking that it would be useful to have a user story to implement
> against for the Hackathon. How about something like the following that maps
> to our goals:
>
>
>
> A vendor identifies a vulnerability in their software product. They
> produce a new version of their software and publish a vulnerability
> bulletin that indicates customers should upgrade to the new version to
> address the vulnerability. The product versions have both a SWID tag and a
> CoSWID tag. As a customer of this vendor that uses the affected products,
> we need to build a vulnerability assessment system that is capable of
> detecting what version of the software is installed and determine if that
> version is vulnerable using the vendor provided information. The Collector
> will be capable of gathering software inventory information from one or
> more target endpoints by:
>
>
>
> Collected software inventory information will be stored in the Assessment
> Results Repository and will be compared to vulnerability detection data
> retrieved from the Vulnerability Detection Data Repository. The
> vulnerability detection data will be derived from the vendor provided
> information in some useful way to be determined by the Vulnerability
> Assessor.
>
>
>
> How does this look?
>
>
>
> Regards,
>
> Dave
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Adam Montville
> *Sent:* Tuesday, May 09, 2017 3:30 PM
> *To:* [email-masked]
> *Subject:* Re: [sacm] Hackathon Goals and Stretch Goals
>
>
>
> All:
>
>
>
> GOAL: Running code demonstrating the communication needs between
> identified components as they pertain to the on-request collection case
> through the scenario, where that case is described at

---

From: Jerome Athias <[email-masked]>
Date: Tue, 16 May 2017 03:11:42 +0000

I think it's a good idea too.
I don't know who is supposed to participate to this hackathon?
Potentially you could market it by capitalizing on real known events,
(without trolling) let's say "new critical vulnerability", "for preventing
ransomware" "FictitousCorp needs to Respond quickly and have a system to
Identify and Protect its endpoints..."

On Tue, 16 May 2017 at 00:30, Adam Montville <[email-masked]>
wrote:

>> GOAL: Running code to extend that base case to include a mechanism
>> capable of monitoring a given set of endpoint attributes for change.
>> OUTCOME: We will have specific understanding of additional architectural
>> considerations for handling monitoring vs. on-request collection, as well
>> as any additional information flows required.
>>
>>
>>
>> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Tim Harrison <[email-masked]>
Date: Mon, 15 May 2017 23:30:57 -0400

Just a passing thought, but one might recruit candidates at a known
convention and/or via a Kaizen Capture the Flag (CTF) event -
https://kaizen-ctf.com/

Cheers,
Tim

On May 15, 2017 11:14 PM, "Jerome Athias" <[email-masked]> wrote:

>>> Collected software inventory information will be stored in the
>>> Assessment Results Repository and will be compared to vulnerability
>>> detection data retrieved from the Vulnerability Detection Data Repository.
>>> The vulnerability detection data will be derived from the vendor provided
>>> On Tue, May 2, 2017 at 4:40 PM Adam Montville <
>>> [email-masked]> wrote:
>>>
>>> All:
>>>
>>>
>>>

---

From: Tim Harrison <[email-masked]>
Date: Mon, 15 May 2017 23:36:09 -0400

Apologies for the multiple emails, but there may be opportunities via
individual networks as well.

On May 15, 2017 11:30 PM, "Tim Harrison" <[email-masked]>
wrote:

>>>> I was thinking that it would be useful to have a user story to
>>>> implement against for the Hackathon. How about something like the following
>>>> that maps to our goals:
>>>>
>>>>
>>>>
>>>> https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAss
>>>> essmentScenario.  OUTCOME: We will have specific understanding of
>>>> components' boundaries and the necessary information flows (including
>>>> information being communicated) between them.
>>>>
>>>>
>>>>
>>>> Last week Dave sent a list of milestones to the list. The first of
>>>> which was for the WG to define some goals for the IETF 99 hackathon. I can
>>>> see at least one primary goal with at least one stretch goal. The primary
>>>> goal is to have running code demonstrating the basic/ideal case through our

---

From: Adam Montville <[email-masked]>
Date: Tue, 16 May 2017 12:51:37 +0000

Hi Jerome,

Well, pretty much anyone can participate - it's not a closed group or
anything like that - but it does need to be coordinated. We anticipate a
lot of work to happen before the face-to-face in Prague, and hope that the
face-to-face is really a couple of days buttoning things up.

I don't mind altering the user story a bit to take some advantage of recent
events - it's no secret that these are the sort of issues for which we
would like to provide solutions.

What do others think? Dave, you're the author of the story, what are your
thoughts?

Adam

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 16 May 2017 13:11:58 +0000

Tim,

The Hackathon is more like an interop event than a Capture the Flag (CTF) event. According to the IETF website “IETF Hackathons encourage developers to collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards.” [1] What we are planning to do would be to collaboratively develop one or more solutions within the scope of SACM that address the user story.

We need volunteers to bring running code to address an aspect of this project. For example, we are bringing 1) a ROLIE implementation that can serve as a Vulnerability Detection Data Repository, and 2) software with a bundled SWID tag and CoSWID tag to be installed on a system.

Regards,
Dave

[1] https://www.ietf.org/hackathon/

From: Tim Harrison [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:31 PM
To: Jerome Athias <[email-masked]>
Cc: [email-masked]; Adam Montville <[email-masked]>; Waltermire, David A. (Fed) <[email-masked]>
Subject: Re: [sacm] Hackathon Goals and Stretch Goals

Just a passing thought, but one might recruit candidates at a known convention and/or via a Kaizen Capture the Flag (CTF) event - https://kaizen-ctf.com/

Cheers,
Tim

On May 15, 2017 11:14 PM, "Jerome Athias" <[email-masked]<mailto:[email-masked]>> wrote:
I think it's a good idea too.
I don't know who is supposed to participate to this hackathon?
Potentially you could market it by capitalizing on real known events, (without trolling) let's say "new critical vulnerability", "for preventing ransomware" "FictitousCorp needs to Respond quickly and have a system to Identify and Protect its endpoints..."

On Tue, 16 May 2017 at 00:30, Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:
I think that's a good idea. How do folks feel about this story? Is it lacking anything? Is it too specific? What would you change about it if you could?

On Mon, May 15, 2017 at 12:57 PM Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
I was thinking that it would be useful to have a user story to implement against for the Hackathon. How about something like the following that maps to our goals:

How does this look?

Regards,
Dave

From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adam Montville
Sent: Tuesday, May 09, 2017 3:30 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Hackathon Goals and Stretch Goals

All:

Kind regards,

Adam

Kind regards,

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 May 2017 10:58:18 -0400

Hi,

Just a couple of points.  If some of you are near enough to Prague and
wanted to attend the Hackathon, but not the IETF, that is not a
problem and signup is separate from the IETF registration.  The
Hackathon is free to attend and open to the public.

David, I think Tim was just suggesting that people who attend the
capture the flag event (in Prague), may also be interested in
attending the Hackathon, so recruiting there could be fruitful.

Best regards,
Kathleen

On Tue, May 16, 2017 at 9:11 AM, Waltermire, David A. (Fed)
<[email-masked]> wrote:
> Tim,
>
>
>
> The Hackathon is more like an interop event than a Capture the Flag (CTF)
> event. According to the IETF website “IETF Hackathons encourage developers
> to collaborate and develop utilities, ideas, sample code and solutions that
> show practical implementations of IETF standards.” [1] What we are planning
> to do would be to collaboratively develop one or more solutions within the
> scope of SACM that address the user story.
>
>
>
> We need volunteers to bring running code to address an aspect of this
> project. For example, we are bringing 1) a ROLIE implementation that can
> serve as a Vulnerability Detection Data Repository, and 2) software with a
> bundled SWID tag and CoSWID tag to be installed on a system.
>
>
>
> Regards,
>
> Dave
>
>
>
> Cc: [email-masked]; Adam Montville <[email-masked]>; Waltermire,
> David A. (Fed) <[email-masked]>
>
>
> On Mon, May 15, 2017 at 12:57 PM Waltermire, David A. (Fed)
> <[email-masked]> wrote:
>
> A vendor identifies a vulnerability in their software product. They produce
> a new version of their software and publish a vulnerability bulletin that
> indicates customers should upgrade to the new version to address the
> vulnerability. The product versions have both a SWID tag and a CoSWID tag.
> As a customer of this vendor that uses the affected products, we need to
> build a vulnerability assessment system that is capable of detecting what
> version of the software is installed and determine if that version is
> vulnerable using the vendor provided information. The Collector will be
> capable of gathering software inventory information from one or more target
> endpoints by:
>
>
>
> This week Dave and I have had an opportunity to discuss these a bit further.
> We've come up with the following set of goals and outcomes:
>
>
>
> for handling monitoring vs. on-request collection, as well as any additional
> information flows required.
>
>
>
> Last week Dave sent a list of milestones to the list. The first of which was
> for the WG to define some goals for the IETF 99 hackathon. I can see at

-- 

Best regards,
Kathleen

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 16 May 2017 15:12:14 +0000

Seems like a reasonable story to focus around, for the hackathon, to me.

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Monday, May 15, 2017 11:12 PM
To: Adam Montville <[email-masked]>; Waltermire, David A. (Fed) <[email-masked]>; [email-masked]
Subject: Re: [sacm] Hackathon Goals and Stretch Goals

How does this look?

Regards,
Dave

All:

Kind regards,

Adam

Kind regards,

Adam

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 16 May 2017 17:59:46 +0200

Hello,

the general story looks like a good fit. I am little uncertain about the 
details regarding:

>> Assessment Results Repository and will be compared to
>> vulnerability detection data retrieved from the Vulnerability
>> Detection Data Repository. The vulnerability detection data will
>> be derived from the vendor provided information in some useful
>> way to be determined by the Vulnerability Assessor.

This seems to imply an iterative process, in which the Assessment 
Results Repository first only stores the "current available information" 
about software packages installed as software instances on the target 
endpoint - and then enriches that with the assessment that this software 
instance is vulnerable (has to be updated) or not. Is that correct?

This seems to merge the components "Assessment Results Repository", 
which store the current "state of things are not compliant" and the 
"Endpoint Repository", which stores the information (e.g. like a 
configuration management system) in which stores information that 
reflects what is currently installed on a target endpoint?

That's the only nit I have on the "story" :)

Also, I noticed conflicting notions about how important it is to prepare 
a message format to convey information between components. While it 
might not be as critical as "having actual component code to work with", 
interoperability is key. And if we would agree on a preliminary data 
structure (probably derived from the current IM), before we start the 
hackathon, we could save some time during the f2f on-site. It's probably 
a low hanging fruit also, as I am not talking about every IE to be 
conveyed, but about the general message structure ("the container") and 
the corresponding encoding for data in motion.

Thoughts?

Viele Grüße,

Henk

On 05/16/2017 05:12 PM, Haynes, Dan wrote:
> *From:*sacm [mailto:[email-masked]] *On Behalf Of *Jerome Athias
> *Sent:* Monday, May 15, 2017 11:12 PM
> *To:* Adam Montville <[email-masked]>; Waltermire, David A.
> (Fed) <[email-masked]>; [email-masked]
> (without trolling) let's say "new critical vulnerability", "for
> preventing ransomware" "FictitousCorp needs to Respond quickly and have
> a system to Identify and Protect its endpoints..."
>
>
>
>
>
> On Tue, 16 May 2017 at 00:30, Adam Montville <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I think that's a good idea. How do folks feel about this story? Is
>     it lacking anything? Is it too specific? What would you change about
>     it if you could?
>
>
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         implement against for the Hackathon. How about something like
>         the following that maps to our goals:
>
>
>
>         A vendor identifies a vulnerability in their software product.
>         They produce a new version of their software and publish a
>         vulnerability bulletin that indicates customers should upgrade
>         to the new version to address the vulnerability. The product
>         versions have both a SWID tag and a CoSWID tag. As a customer of
>         this vendor that uses the affected products, we need to build a
>         vulnerability assessment system that is capable of detecting
>         what version of the software is installed and determine if that
>         version is vulnerable using the vendor provided information. The
>         Collector will be capable of gathering software inventory
>         information from one or more target endpoints by:
>
>
>
>         1)      Requesting software inventory information for the
>         affected software based on an ad-hoc request.
>
>         Assessment Results Repository and will be compared to
>         vulnerability detection data retrieved from the Vulnerability
>         Detection Data Repository. The vulnerability detection data will
>         be derived from the vendor provided information in some useful
>         way to be determined by the Vulnerability Assessor.
>
>
>
>         How does this look?
>
>
>
>         Regards,
>
>         Dave
>
>
>
>         *From:*sacm [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Adam Montville
>         *To:* [email-masked] <mailto:[email-masked]>
>         This week Dave and I have had an opportunity to discuss these a
>         bit further. We've come up with the following set of goals and
>         outcomes:
>
>
>
>         identified components as they pertain to the on-request
>         collection case through the scenario, where that case is
>         described
>         at https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario.
>         OUTCOME: We will have specific understanding of components'
>         boundaries and the necessary information flows (including
>         GOAL: Leverage existing collected data in a data repository.
>         OUTCOME: Demonstrate that previously collected data can be
>         reused to support vulnerability assessment
>
>
>
>         GOAL: Running code to extend that base case to include a
>         mechanism capable of monitoring a given set of endpoint
>         attributes for change. OUTCOME: We will have specific
>         understanding of additional architectural considerations for
>         handling monitoring vs. on-request collection, as well as any
>         Does anyone care to bash these goal-ouctome pairs in the context
>         of our hackathon plans?  If so, please do so over the next day
>         or two, otherwise these will become the stated goals for our
>         hackathon.
>
>
>
>         Kind regards,
>
>
>
>         Adam
>
>
>
>         On Tue, May 2, 2017 at 4:40 PM Adam Montville
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             All:
>
>
>
>             Last week Dave sent a list of milestones to the list. The
>             first of which was for the WG to define some goals for the
>             IETF 99 hackathon. I can see at least one primary goal with
>             at least one stretch goal. The primary goal is to have
>             running code demonstrating the basic/ideal case through our
>             vulnerability scenario, where a new vulnerability is
>             discovered and we need to reach out all the way to the
>             endpoint to determine whether it is in fact vulnerable. A
>             stretch goal might be to have running code demonstrating a
>             "monitor for this vulnerability from now on" capability (I'm
>             sure I'm not stating that as well as I could).
>
>
>
>             Does anyone have additional goals? Or, are there better ways
>             to state these particular goals (there probably are)?
>
>
>
>             Kind regards,
>
>
>
>             Adam
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 16 May 2017 16:47:02 +0000

Kathleen,

Thanks for clarifying the participation model for the Hackathon. The fact that it is open to anyone is important.

As for Tim's email, which CTF event in Prague are you referring to?

I found one hosted by Accenture tomorrow, but I am not aware of one around the time of the IETF.

Regards,
Dave

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Tuesday, May 16, 2017 10:58 AM
> To: Waltermire, David A. (Fed) <[email-masked]>
> Cc: Tim Harrison <[email-masked]>; Jerome Athias
> <[email-masked]>; [email-masked]; Adam Montville
> <[email-masked]>
> wanted to attend the Hackathon, but not the IETF, that is not a problem and
> signup is separate from the IETF registration.  The Hackathon is free to attend
> and open to the public.
> 
> David, I think Tim was just suggesting that people who attend the capture
> the flag event (in Prague), may also be interested in attending the
> Hackathon, so recruiting there could be fruitful.
> 
> Best regards,
> Kathleen
> 
> > The Hackathon is more like an interop event than a Capture the Flag
> > (CTF) event. According to the IETF website “IETF Hackathons encourage
> > developers to collaborate and develop utilities, ideas, sample code
> > and solutions that show practical implementations of IETF standards.”
> > [1] What we are planning to do would be to collaboratively develop one
> > or more solutions within the scope of SACM that address the user story.
> >
> >
> >
> > project. For example, we are bringing 1) a ROLIE implementation that
> > can serve as a Vulnerability Detection Data Repository, and 2)
> > software with a bundled SWID tag and CoSWID tag to be installed on a
> system.
> >
> >
> >
> > Regards,
> >
> > Dave
> >
> >
> >
> > Cc: [email-masked]; Adam Montville <[email-masked]>;
> > Waltermire, David A. (Fed) <[email-masked]>
> >
> >
> > preventing ransomware" "FictitousCorp needs to Respond quickly and
> > have a system to Identify and Protect its endpoints..."
> >
> >
> >
> >
> >
> > lacking anything? Is it too specific? What would you change about it
> > if you could?
> >
> >
> >
> > implement against for the Hackathon. How about something like the
> > following that maps to our goals:
> >
> >
> >
> CoSWID tag.
> > As a customer of this vendor that uses the affected products, we need
> > to build a vulnerability assessment system that is capable of
> > detecting what version of the software is installed and determine if
> > that version is vulnerable using the vendor provided information. The
> > Collector will be capable of gathering software inventory information
> > from one or more target endpoints by:
> >
> >
> >
> > detection data retrieved from the Vulnerability Detection Data
> > Repository. The vulnerability detection data will be derived from the
> > vendor provided information in some useful way to be determined by the
> > Vulnerability Assessor.
> >
> >
> >
> > How does this look?
> >
> >
> >
> > Regards,
> >
> > Dave
> >
> >
> >
> further.
> > identified components as they pertain to the on-request collection
> > case through the scenario, where that case is described at
> >
> boundaries
> > and the necessary information flows (including information being
> > communicated) between them.
> >
> >
> >
> > OUTCOME: We will have specific understanding of additional
> > architectural considerations for handling monitoring vs. on-request
> > collection, as well as any additional information flows required.
> >
> >
> >
> > Does anyone care to bash these goal-ouctome pairs in the context of
> > our hackathon plans?  If so, please do so over the next day or two,
> > otherwise these will become the stated goals for our hackathon.
> >
> >
> >
> > Kind regards,
> >
> >
> >
> > Adam
> >
> >
> >
> > <[email-masked]>
> > wrote:
> >
> > All:
> >
> >
> >
> > which was for the WG to define some goals for the IETF 99 hackathon. I
> > can see at least one primary goal with at least one stretch goal. The
> > primary goal is to have running code demonstrating the basic/ideal
> > case through our vulnerability scenario, where a new vulnerability is
> > discovered and we need to reach out all the way to the endpoint to
> > determine whether it is in fact vulnerable. A stretch goal might be to
> > have running code demonstrating a "monitor for this vulnerability from
> > now on" capability (I'm sure I'm not stating that as well as I could).
> >
> >
> >

---

From: Adam Montville <[email-masked]>
Date: Tue, 16 May 2017 18:47:06 +0000

Hi Henk. I'll try inline.

> reflects what is currently installed on a target endpoint?

[AWM] Yes, I think the story could be clarified on this front. It shouldn't
merge the two components we've agreed to keep separate. If the first
sentence in your quoted text beging instead with "Collected software
inventory will be stored in the Endpoint Repository..." I think that fixes
some things.

> the corresponding encoding for data in motion.

[AWM] There are differing perspectives on this front. Yes, having a common
structure could be useful, but it may not be necessary for the purposes of
this effort. This effort is somewhat different from others that I've heard
of, in that we are not implementing a solution as much as we are
discovering one. I do expect that we will discover the structures we need
as we develop the solution. What do others think about this? Do we need to
have this information up front, or is it something we can discover as we go?

> >         at

---

From: Adam Montville <[email-masked]>
Date: Tue, 16 May 2017 18:59:23 +0000

Also, I've created a wiki page here:
https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentHackathon

At that page (version 4) I've put up a modified version of the user story
suggested earlier, hopefully making appropriate clarifications.

Kind regards,

Adam

On Tue, May 16, 2017 at 1:47 PM Adam Montville <[email-masked]>
wrote:

> [AWM] Yes, I think the story could be clarified on this front. It
> shouldn't merge the two components we've agreed to keep separate. If the
> first sentence in your quoted text beging instead with "Collected software
>> >         <[email-masked] <mailto:[email-masked]
>> >>
>> >         wrote:
>> >
>> >             All:
>> >
>> >
>> >

---

From: Ira McDonald <[email-masked]>
Date: Fri, 19 May 2017 14:39:20 -0400

Hi Adam,

Chiming in below on one point raised in this Hackathon goals conversation.

Cheers,
- Ira

On Tue, May 16, 2017 at 2:47 PM, Adam Montville <[email-masked]>
wrote:

> <...snip...>

<ira> For message wire format for the Hackathon, please consider taking the
SACM
Information Model verbatim and using that XSD for XML wire format.
Efficiency is
totally irrelevant.  So is elegance.  You're trying to do a proof of
concept.  Defining
the Hackathon wire format interactively in the room is a time waster idea,
IMO.

---

From: Adam Montville <[email-masked]>
Date: Mon, 22 May 2017 13:39:25 +0000

Ira, thank you for sharing your opinion. I am perfectly fine making such a
declaration, but I would like others to chime in also. I know at least one
other who believes doing this would be a good idea, but I'm not sure about
any sort of consensus on the issue at this point.

To your other points, I agree completely - this is proof-of-concept work,
not finished product. So, it can be an ugly, but instructional, solution.

Adam

On Fri, May 19, 2017 at 1:39 PM Ira McDonald <[email-masked]>
wrote:

> On Tue, May 16, 2017 at 2:47 PM, Adam Montville <
>> [AWM] There are differing perspectives on this front. Yes, having a
>> common structure could be useful, but it may not be necessary for the
>> purposes of this effort. This effort is somewhat different from others that
>> I've heard of, in that we are not implementing a solution as much as we are
> <ira> For message wire format for the Hackathon, please consider taking
> the SACM

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 22 May 2017 14:03:15 +0000

I am not sure we need the IM format at all, and what data elements to use is underspecified for implementation if we wanted to use it.

If the data stores are communicated with using native query languages  (e.g. SQL, SPARQL), we do not have much need for a common message format at this time. IMHO, looking at what information is exchanged over a query language will help us to identify what more is needed for exchange in this area, while allowing us to move forward from a practical perspective.

Regards,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Monday, May 22, 2017 9:39 AM
To: Ira McDonald <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [sacm] Hackathon Goals and Stretch Goals

Ira, thank you for sharing your opinion. I am perfectly fine making such a declaration, but I would like others to chime in also. I know at least one other who believes doing this would be a good idea, but I'm not sure about any sort of consensus on the issue at this point.

To your other points, I agree completely - this is proof-of-concept work, not finished product. So, it can be an ugly, but instructional, solution.

Adam
On Fri, May 19, 2017 at 1:39 PM Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adam,
Chiming in below on one point raised in this Hackathon goals conversation.
Cheers,
- Ira

On Tue, May 16, 2017 at 2:47 PM, Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:
Hi Henk. I'll try inline.
On Tue, May 16, 2017 at 11:04 AM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
<...snip...>

[AWM] There are differing perspectives on this front. Yes, having a common structure could be useful, but it may not be necessary for the purposes of this effort. This effort is somewhat different from others that I've heard of, in that we are not implementing a solution as much as we are discovering one. I do expect that we will discover the structures we need as we develop the solution. What do others think about this? Do we need to have this information up front, or is it something we can discover as we go?

<ira> For message wire format for the Hackathon, please consider taking the SACM
Information Model verbatim and using that XSD for XML wire format.  Efficiency is
totally irrelevant.  So is elegance.  You're trying to do a proof of concept.  Defining
the Hackathon wire format interactively in the room is a time waster idea, IMO.

Thoughts?

Viele Grüße,

Henk

On 05/16/2017 05:12 PM, Haynes, Dan wrote:
> *From:*sacm [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Jerome Athias
> *To:* Adam Montville <[email-masked]<mailto:[email-masked]>>; Waltermire, David A.
> (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> On Tue, 16 May 2017 at 00:30, Adam Montville <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>         *From:*sacm [mailto:[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>] *On Behalf Of *Adam Montville
>         *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>         wrote:
>
>             All:
>
>
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Haynes, Dan" <[email-masked]>
Date: Mon, 22 May 2017 14:16:20 +0000

It’s probably also worth pointing out that if we are using existing protocols such as NEA, it may not make sense to directly change the fields in its over-the-wire format to match the SACM IM (e.g. communications between endpoint and server), rather, provide a mapping. Then, when the server receives the data, it can use the mapping to store the data in the repository such that it aligns with the data described in the IM. This approach will likely be required when we want to leverage existing protocols where we may not have the ability to change them (e.g. Apple MDM and Configuration Profiles, Windows PowerShell Desired State Configuration, etc.). With all that said, the explicit approach may be more desirable when we are developing our own protocols or have significant influence and support to change existing protocols. I guess I am just trying to say we probably want to support both approaches :).

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Friday, May 19, 2017 2:39 PM
To: Adam Montville <[email-masked]>; Ira McDonald <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [sacm] Hackathon Goals and Stretch Goals

Hi Adam,

Thoughts?

Viele Grüße,

Henk

---

From: Adam Montville <[email-masked]>
Date: Mon, 22 May 2017 15:26:15 +0000

I think we'll get to the bottom of this particular question as we dive
deeper into the weeds. At this point it seems that we have identified
notional components and, in most cases, their functional counterparts with
associated contributors.

At what point do we want to start getting together on a regular basis to
make as much progress as possible before the hackathon? For example, we
need to determine our environment, where we're going to put components,
develop code, and do that sort of thing. Basically come up with a rough
plan forward, probably update the hackathon wiki and do things like that.

Who will be actively contributing?

Adam

On Mon, May 22, 2017 at 9:16 AM Haynes, Dan <[email-masked]> wrote:

> It’s probably also worth pointing out that if we are using existing
> protocols such as NEA, it may not make sense to directly change the fields
> in its over-the-wire format to match the SACM IM (e.g. communications
> between endpoint and server), rather, provide a mapping. Then, when the
> server receives the data, it can use the mapping to store the data in the
> repository such that it aligns with the data described in the IM. This
> approach will likely be required when we want to leverage existing
> protocols where we may not have the ability to change them (e.g. Apple MDM
> and Configuration Profiles, Windows PowerShell Desired State Configuration,
> etc.). With all that said, the explicit approach may be more desirable when
> we are developing our own protocols or have significant influence and
> support to change existing protocols. I guess I am just trying to say we
> probably want to support both approaches :).
>
>
>
> Thanks,
>
> Danny
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Ira McDonald
> *Sent:* Friday, May 19, 2017 2:39 PM
> *To:* Adam Montville <[email-masked]>; Ira McDonald <
> [email-masked]>
>
>
> *Cc:* Henk Birkholz <[email-masked]>; [email-masked]
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 22 May 2017 18:48:32 +0200

Hello all,

I totally agree that the method employed in Collection Tasks should not 
use the inter-component mechanism/format of distributing SACM content with.

E.g. if there is a SWID repository that is a database (there are open 
but not commonly or currently used examples for data base schemas in 
regard to the outdated 2009 version of SWID, as far as I know), of 
course an SQL query is used to collect them. In this example the 
acquisition method employed by a Collector is simply an SQL used by that 
data base. We SHOULD NOT build an alternative way to convey that 
information!

Same goes for Attributes via IF-M to address Danny's example.

Now, looking downstream, the information queried has to be composed into 
an actual tag. Most likely, a DB about tags will store the most 
important items to query tags in tables (e.g. tag_id, entity_id, 
package_name, version, etc.) and also the complete XML blob (if it fits 
into a DB value, they can be large if stored in native XML). This is the 
way that the only open source example that I actually personally know of 
does it, at least.

If you finally have that tag (re-composed or queried en'blob) collected 
and it is about a vulnerable software package that is currently 
installed as software instances on target endpoints, how to convey that 
information to other downstream components is the interesting point 
here: Partial, or as a byte blob, or mapped to IE, at least in a way 
that is not surprising to any SACM component in general.

If we do not use a common message encoding and msg structure (data 
model) here (may it even be so preliminary that we just learn to use sth 
else), how should interop with further components work? I was under the 
impression that is the point of the IM?

If nobody has the time to do this (which might be the only concern?), I 
can whip up an example using XSD and CDDL, and even YANG for YANG event 
notification, if I find more than one or two consecutive hours...

Viele Grüße,

Henk

On 05/22/2017 04:16 PM, Haynes, Dan wrote:
> protocols such as NEA, it may not make sense to directly change the
> fields in its over-the-wire format to match the SACM IM (e.g.
> communications between endpoint and server), rather, provide a mapping.
> Then, when the server receives the data, it can use the mapping to store
> the data in the repository such that it aligns with the data described
> in the IM. This approach will likely be required when we want to
> leverage existing protocols where we may not have the ability to change
> them (e.g. Apple MDM and Configuration Profiles, Windows PowerShell
> Desired State Configuration, etc.). With all that said, the explicit
> approach may be more desirable when we are developing our own protocols
> or have significant influence and support to change existing protocols.
> I guess I am just trying to say we probably want to support both
> approaches :).
>
>
>
> Thanks,
>
> Danny
>
>
>
> *From:*sacm [mailto:[email-masked]] *On Behalf Of *Ira McDonald
> *To:* Adam Montville <[email-masked]>; Ira McDonald
> <[email-masked]>
> On Tue, May 16, 2017 at 2:47 PM, Adam Montville
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Tue, May 16, 2017 at 11:04 AM Henk Birkholz
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     <...snip...>
>
>
>     common structure could be useful, but it may not be necessary for
>     the purposes of this effort. This effort is somewhat different from
>     others that I've heard of, in that we are not implementing a
>     solution as much as we are discovering one. I do expect that we will
>     discover the structures we need as we develop the solution. What do
>     others think about this? Do we need to have this information up
>     front, or is it something we can discover as we go?
>
>
>
>         <mailto:[email-masked]>] *On Behalf Of *Jerome Athias
>         > *To:* Adam Montville <[email-masked]
>         <mailto:[email-masked]>>; Waltermire, David A.
>         > (Fed) <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         > On Tue, 16 May 2017 at 00:30, Adam Montville
>         <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>         >
>         >     <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>         >
>         <mailto:[email-masked]>
>         >         <mailto:[email-masked]
>         <mailto:[email-masked]>>] *On Behalf Of *Adam Montville
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         >         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         >         wrote:
>         >
>         >             All:
>         >
>         >
>         >
>         >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 22 May 2017 18:54:11 +0200

In regard to active contribution, I think I will find at least one 
engineer that will try to create a repository that stores records  of 
every SACM component's output (results, records, etc.) and that can be 
queried at least by time, data source, data origin and IE type.

Viele Grüße,

Henk

On 05/22/2017 05:26 PM, Adam Montville wrote:
> notional components and, in most cases, their functional counterparts
> with associated contributors.
>
> On Mon, May 22, 2017 at 9:16 AM Haynes, Dan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     communications between endpoint and server), rather, provide a
>     mapping. Then, when the server receives the data, it can use the
>     mapping to store the data in the repository such that it aligns with
>     the data described in the IM. This approach will likely be required
>     when we want to leverage existing protocols where we may not have
>     the ability to change them (e.g. Apple MDM and Configuration
>     Profiles, Windows PowerShell Desired State Configuration, etc.).
>     With all that said, the explicit approach may be more desirable when
>     we are developing our own protocols or have significant influence
>     and support to change existing protocols. I guess I am just trying
>     to say we probably want to support both approaches :).____
>
>     __ __
>
>     Thanks,
>
>     Danny ____
>
>     __ __
>
>     <mailto:[email-masked]>] *On Behalf Of *Ira McDonald
>     <mailto:[email-masked]>>; Ira McDonald
>     <[email-masked] <mailto:[email-masked]>>
>
>
>     *Cc:* Henk Birkholz <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>     *Subject:* Re: [sacm] Hackathon Goals and Stretch Goals____
>
>     __ __
>
>     Hi Adam,____
>
>     Chiming in below on one point raised in this Hackathon goals
>     conversation.____
>
>     Cheers,____
>
>     - Ira____
>
>     __ __
>
>     wrote:____
>         Hi Henk. I'll try inline.____
>
>         <mailto:[email-masked]>> wrote:____
>
>         <...snip...>____
>
>
>             the corresponding encoding for data in motion.____
>
>         __ __
>
>         [AWM] There are differing perspectives on this front. Yes,
>         having a common structure could be useful, but it may not be
>         necessary for the purposes of this effort. This effort is
>         somewhat different from others that I've heard of, in that we
>         are not implementing a solution as much as we are discovering
>         one. I do expect that we will discover the structures we need as
>         we develop the solution. What do others think about this? Do we
>         need to have this information up front, or is it something we
>         can discover as we go?____
>
>     __ __
>
>     Efficiency is____
>     concept.  Defining____
>     the Hackathon wire format interactively in the room is a time waster
>     idea, IMO.____
>
>          ____
>
>
>             Thoughts?
>
>
>             Viele Grüße,
>
>             Henk
>
>
>
>
>             https://www.ietf.org/mailman/listinfo/sacm____
>
>
>         https://www.ietf.org/mailman/listinfo/sacm____
>
>     __ __
>

---

From: Jerome Athias <[email-masked]>
Date: Tue, 23 May 2017 05:12:21 -0400

So trying to add my 2c, under a PoC context

A) I do agree with Dan that Mappings would be needed (e.g. between the IEs and some XSD schemas, or interexchange format specifications, e.g. ARF, OVAL,... (XORCISM)) and so APIs or glue code can do the trick.
I agree that an SQL database can be used (it could be a central repository. One big unique database schema would be unwanted, however, it could be split (a la CAESARS Framework) (you would use UUIDs/GUIDs anyway) and orchestrated (a la IACD). This without the immediate need of an interexchange format.
Later on, when minimum required information element will be identified between 2 components, the format could be defined and optimized.
(a la IVIL: Intermediate Vulnerability Information Language)
This, when using an SQL base (so then the tables/objects with columns/attributes and relationships are defined), is really "just" a conversion of objects representation...
(It's not an approach as elegant as a purely defined Ontology but it makes it work while being interoperable)
(Note here that for near future adoption promotion of SWID, one should maybe jump into the OASIS CSAF new CVRF committee...)

B) Regarding code,
I am interested by the previous contribution offers.
I could contribute with some -components plugins- (methods?) and pointers to some other code/tools.
(Note that I'll try to update my XORCISM repo during the week-end)
Focusing mainly on Windows-based endpoints (because when it's too easy it's not fun):
I could provide:

1) VDI2VDD
PoC code that converts Microsoft Security Updates Information (VDI) into VDD (OVAL Definitions)
- This is currently work in progress, but ok for PoC
- This demonstrates (re)use of a VDD Repository information
(while this could be directly the CIS OVAL Repository [0], here i'm using 2))
- New insertion into 2) could Trigger*:
. ROLIE SDE use, Assessment
(out-of-scope note: here STIX v1 can be used for an OpenC2 COA (STIX v2 currently too limited) OR IODEF/MILE for sci;Vulnerability with NodeRole 26. assessment, etc. ...)

2) VDD Repository
- In the form of a "Data Model" as an SQL schema
https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XOVAL

- PoC code that converts the CIS (XML) OVAL Repository information [0] into XOVAL (SQL) information
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/Import_oval/Program.cs

3) VDI Collection plugin/method
- PoC code that converts&imports NVD CVD database (XML) into a (SQL) VDI Repository 4)
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/Import_all/Program.cs
- Note: New insertion into 3) could Trigger* (with use of 6))

4) VDI Repository
https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XVULNERABILITY

5) Endpoint Information Collection plugin/method
- PoC code that uses external tools for collecting Endpoints information
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/XProviderNmap/Engine.cs
- OVAL Community Tools (using OVAL Inventory Definitions) should be used, e.g. OVALdi
- One interesting simple candidate tool to use for Windows could be https://github.com/nccgroup/WMIcmd
- Other candidates for Collectors ... (API/glue with tools like BMC Remedy, or simple tools already listed by Adam, https://sourceforge.net/projects/teemip/ etc.)

6) Endpoint Information Repository
- SQL schema (small part of https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XORCISMModel )
e.g. ARF schema

7) Assessment Results Repository
- SQL schema (small part of https://github.com/athiasjerome/XORCISM/tree/master/MODELS/XORCISMModel )

8) Vulnerability Assessors
- PoC code that uses external tools for collecting Assessment Results
https://github.com/athiasjerome/XORCISM/tree/master/SOURCES/XProviderNeXpose
https://github.com/athiasjerome/XORCISM/tree/master/SOURCES/XProviderQualys
...
It is important to note that Vulnerability Assessors will collect information useful to update the 6) Endpoint Repository information (e.g. new unknown endpoints, updated information (even if just update of the timestamps), etc.)

Then of course, because we want that automated and continuous, on top of that, an 'Orchestrator' with tasks/jobs scheduler, workflow (playbook) manager and profile manager would be needed.
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/XManagerService/Engine.cs

[0] https://oval.cisecurity.org

-------- Original Message --------
Subject: Re: [sacm] Hackathon Goals and Stretch Goals
Local Time: May 22, 2017 7:48 PM
UTC Time: May 22, 2017 4:48 PM
From: [email-masked]
To: [email-masked]

Hello all,

Viele Grüße,

Henk

On 05/22/2017 04:16 PM, Haynes, Dan wrote:
> idea, IMO.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 23 May 2017 17:02:03 +0000

Hi all,

Trying to catch up on the thread….I would agree with Ira and Henk’s comments/suggestion that we should be working towards a SACM goal.  That is, SACM has been working on solidifying an IM and the IM elements which are a MUST to implement….that way we enable the interoperability across the heterogeneity of the information available.

I think there are going to be modules (or “glue”) needed to enable the current DB’s/repositories and their interfaces to be able to expose their available data in an (SACM) interoperable flow.

If Henk can provide this, then we can focus on the mappings to get the interop underway then….

	Nancy

On 5/22/17, 9:48 AM, "sacm on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hello all,

    

    

    Viele Grüße,
    
    Henk

---

From: Adam Montville <[email-masked]>
Date: Thu, 25 May 2017 13:06:08 +0000

I'm viewing the problem essentially in two parts. 1) we need to understand
the information we need between each component to inform the information
model, then 2) we will need to figure out how to best represent that
information. Solidifying the information model seems like the latter, which
cannot really be done without first understanding the former. To me, the
hackathon should be first focused on the former - learning more about the
information we really need - before it gets too far along.

This is not to say that we will not be able to address both! Instead, I am
suggesting that we, in earnest, start focusing on the first part of this
problem, and then hopefully get to the second part of the problem.

We have three distinct goals. We have a user story. Now we need a team to
come together and start working even before we get to Prague, so that we
can make some real progress. There is not very much time left...

Bill and I are committed. I believe Dave and Stephen are committed. Henk, I
think, is committed also. Who else is interested in participating? And, how
do we want to start running this? We can set up a code repo in GitHub so we
have a place to track work items, issues, etc.  Being committed to the
effort requires becoming and remaining engaged in an ongoing work effort.

Kind regards,

Adam

On Tue, May 23, 2017 at 12:02 PM Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> Hi all,
>
> Trying to catch up on the thread….I would agree with Ira and Henk’s
> comments/suggestion that we should be working towards a SACM goal.  That
> is, SACM has been working on solidifying an IM and the IM elements which
> are a MUST to implement….that way we enable the interoperability across the
> heterogeneity of the information available.
>
> I think there are going to be modules (or “glue”) needed to enable the
> current DB’s/repositories and their interfaces to be able to expose their
> available data in an (SACM) interoperable flow.
>
> On 5/22/17, 9:48 AM, "sacm on behalf of Henk Birkholz" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hello all,
>
> mapping.
> conversation.
>     >         Also, I noticed conflicting notions about how important it
> is to
>     >         prepare
>     >         hackathon, we could save some time during the f2f on-site.
> It's
>     >         probably
> having a
>     >         > Potentially you could market it by capitalizing on real
> known
>     >         events,
>     >         > preventing ransomware" "FictitousCorp needs to Respond
> quickly
>     >         and have
>     >         >     I think that's a good idea. How do folks feel about
> this
>     >         story? Is
>     >         >         I was thinking that it would be useful to have a
> user
>     >         story to
>     >         >         A vendor identifies a vulnerability in their
> software
>     >         product.
>     >         >         vulnerability bulletin that indicates customers
> should
>     >         upgrade
>     >         >         to the new version to address the vulnerability.
> The
>     >         product
>     >         >         versions have both a SWID tag and a CoSWID tag. As
> a
>     >         customer of
>     >         >         this vendor that uses the affected products, we
> need
>     >         to build a
>     >         >         2)      Reporting the software inventory as
> software
>     >         changes occur
>     >         >
>     >         >
>     >         >
>     >         >         Detection Data Repository. The vulnerability
> detection
>     >         data will
>     >         >         bit further. We've come up with the following set
> of
>     >         goals and
>     >         >         outcomes:
>     >         >
>     >         >
>     >         >
>     >         >         handling monitoring vs. on-request collection, as
> well
>     >         as any
>     >         >         Does anyone care to bash these goal-ouctome pairs
> in
>     >         the context
>     >         >         of our hackathon plans?  If so, please do so over
> the
>     >         next day
>     >         >         or two, otherwise these will become the stated
> goals
>     >         for our
>     >         >         hackathon.
>     >         >
>     >         >
>     >         >
>     >         >         Kind regards,
>     >         >
>     >         >
>     >         >
>     >         >         Adam
>     >         >
>     >         >
>     >         >
>     >         >             first of which was for the WG to define some
> goals
>     >         for the
>     >         >             IETF 99 hackathon. I can see at least one
> primary
>     >         goal with
>     >         >             Does anyone have additional goals? Or, are
> there
>     >         better ways

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Tue, 30 May 2017 10:43:27 -0400

We've been collaborating with Andreas Steffens on a SWIMA collector that
operates well with strongSwan's NEA implementation. We hope to bring both
SWIMA and strongSwan to the Hackathon.

On Thu, May 25, 2017 at 9:06 AM, Adam Montville <[email-masked]>
wrote:

> Bill and I are committed. I believe Dave and Stephen are committed. Henk,
> I think, is committed also. Who else is interested in participating? And,
> how do we want to start running this? We can set up a code repo in GitHub
> so we have a place to track work items, issues, etc.  Being committed to
> the effort requires becoming and remaining engaged in an ongoing work
> effort.
>
> Kind regards,
>
> Adam
>
>>     >         >     it lacking anything? Is it too specific? What would
>> you
>>     >         change about
>>     >         >     it if you could?
>>     >         >
>>     >         >
>>     >         >
>>     >         >         versions have both a SWID tag and a CoSWID tag.
>> As a
>>     >         customer of
>>     >         >             Last week Dave sent a list of milestones to
>> the
>>     >         list. The
>>     >         >             running code demonstrating the basic/ideal
>> case
>>     >         through our

---

From: Adam Montville <[email-masked]>
Date: Wed, 31 May 2017 12:52:30 +0000

Thanks, Jess.
On Tue, May 30, 2017 at 9:43 AM Jessica Fitzgerald-McKay <[email-masked]>
wrote:

> On Thu, May 25, 2017 at 9:06 AM, Adam Montville <
>> I'm viewing the problem essentially in two parts. 1) we need to
>> understand the information we need between each component to inform the
>> information model, then 2) we will need to figure out how to best represent
>> that information. Solidifying the information model seems like the latter,
>> which cannot really be done without first understanding the former. To me,
>> the hackathon should be first focused on the former - learning more about
>> the information we really need - before it gets too far along.
>>
>> This is not to say that we will not be able to address both! Instead, I
>> am suggesting that we, in earnest, start focusing on the first part of this
>>>     >         might not be as critical as "having actual component code
>>> to
>>>     >         work with",
>>>     >         >         vulnerability assessment system that is capable
>>> of
>>>     >         detecting
>>>     >         >         be derived from the vendor provided information
>>> in
>>>     >         some useful
>>>     >         >         bit further. We've come up with the following
>>> set of
>>>     >         goals and
>>>     >         >         outcomes:
>>>     >         >
>>>     >         >
>>>     >         >
>>>     >         >         GOAL: Running code demonstrating the
>>> communication
>>>     >         needs between
>>>     >         >         handling monitoring vs. on-request collection,
>>> as well
>>>     >         as any
>>>     >         >         Does anyone care to bash these goal-ouctome
>>> pairs in
>>>     >         the context
>>>     >         >         of our hackathon plans?  If so, please do so
>>> over the
>>>     >         next day