Subject: Re: [sacm] IETF 97 Follow-Up: Using the Vulnerability Assessment Scenario to Make Progress on the Architecture and IM

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 3 Jan 2017 17:57:12 +0000

I just wanted to check in and see if anyone had thoughts on this proposed work item? Does it seem like a worthwhile effort to help make progress on the Architecture and IM? Please let me know if you have any questions.
Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Monday, December 19, 2016 1:55 PM
To: [email-masked]
Subject: [sacm] IETF 97 Follow-Up: Using the Vulnerability Assessment Scenario to Make Progress on the Architecture and IM

Hi Everyone,

In an effort to address the roadblocks associated with the architecture and scope of the information model, it was suggested at IETF 97 that the WG go through the Vulnerability Assessment Scenario and define the minimum set of interfaces, operations, and information elements necessary execute the scenario. Focusing on the Vulnerability Assessment Scenario will help keep the discussions concrete and very focused. The end result of this work will inform decisions on the architecture and information model that will allow the WG to move forward with a basic set of capabilities and build out additional capabilities as needed. The following is a first pass at what this work might look like and how we might want to approach it as a WG. Ideally, several members of the WG would drive this effort forward.

Objectives

*         Identify the tasks that are necessary to execute the Vulnerability Assessment Scenario and define their inputs and outputs

*         Identify the interactions between components in the Vulnerability Assessment Scenario and define the interfaces and operations required to support those interactions

*         Identify the information elements necessary to facilitate the communication of security automation data between components in the Vulnerability Assessment Scenario

*         Validate tasks, interfaces, operations, and information elements by exercising the Vulnerability Assessment Scenario using multiple CVEs

Approach

To ensure the WG can make quick progress, this work should be broken up into multiple phases that gradually build on the previous phase.

Phase 1

*         Assume components are configured to communicate with each other (i.e. ignore discovery for now)

*         Create a diagram that shows the components and their interactions with each other. Highlight which interactions are required and which interactions are optional.

*         Identify where different tasks occur in the diagram

Phase 2

*         For each component, identify the information elements needed to carry out the required interactions. For each interaction, define the necessary interfaces and operations.

*         Validate using CVEs

Phase 3

*         Identify the information elements needed to carry out the optional interactions. Define the necessary interfaces and operations for those interactions.

*         Validate using CVEs

Phase 4

*         Add support for discovery of components and capabilities by other components

*         Validate using CVEs

Deliverables

*         Updated IM that contains the minimum set of IEs necessary for the Vulnerability Assessment Scenario

*         Updated Architecture that defines the interfaces and operations required for the Vulnerability Assessment Scenario

*         Multiple examples that use CVEs to validate the Vulnerability Assessment Scenario

Does this seem like a reasonable summary of this work? Are there things that are missing or should be removed from this work?

Please let me know if you have any questions.

Thanks,

Danny

---

From: Adam Montville <[email-masked]>
Date: Thu, 05 Jan 2017 18:38:42 +0000

Thanks for pinging on this, Danny - maybe the original needed a kick back
to the top of the pile given typical holiday delays...  Speaking as a
contributor and as a chair I like this idea.  It seems like a good path to
start working so we can continue making meaningful progress in the group.
I would like to hear what others think of the approach, and I would like to
know who is willing to actively contribute to the exercise.

Kind regards,

Adam

On Tue, Jan 3, 2017 at 11:57 AM Haynes, Dan <[email-masked]> wrote:

> I just wanted to check in and see if anyone had thoughts on this proposed
> work item? Does it seem like a worthwhile effort to help make progress on
> the Architecture and IM? Please let me know if you have any questions.
>
> Thanks,
>
> Danny
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Haynes, Dan
> *Sent:* Monday, December 19, 2016 1:55 PM
> *To:* [email-masked]
> *Subject:* [sacm] IETF 97 Follow-Up: Using the Vulnerability Assessment
> Scenario to Make Progress on the Architecture and IM
>
>
>
> Hi Everyone,
>
>
>
> In an effort to address the roadblocks associated with the architecture
> and scope of the information model, it was suggested at IETF 97 that the WG
> go through the Vulnerability Assessment Scenario and define the minimum set
> of interfaces, operations, and information elements necessary execute the
> scenario. Focusing on the Vulnerability Assessment Scenario will help keep
> the discussions concrete and very focused. The end result of this work will
> inform decisions on the architecture and information model that will allow
> the WG to move forward with a basic set of capabilities and build out
> additional capabilities as needed. The following is a first pass at what
> this work might look like and how we might want to approach it as a WG.
> Ideally, several members of the WG would drive this effort forward.
>
>
> Objectives
>
> ·         Identify the tasks that are necessary to execute the
> Vulnerability Assessment Scenario and define their inputs and outputs
>
> ·         Identify the interactions between components in the
> Vulnerability Assessment Scenario and define the interfaces and operations
> required to support those interactions
>
> ·         Identify the information elements necessary to facilitate the
> communication of security automation data between components in the
> Vulnerability Assessment Scenario
>
> ·         Validate tasks, interfaces, operations, and information
> elements by exercising the Vulnerability Assessment Scenario using multiple
> CVEs
>
>
> Approach
>
> To ensure the WG can make quick progress, this work should be broken up
> into multiple phases that gradually build on the previous phase.
>
>
> Phase 1
>
> ·         Assume components are configured to communicate with each other
> (i.e. ignore discovery for now)
>
> ·         Create a diagram that shows the components and their
> interactions with each other. Highlight which interactions are required and
> which interactions are optional.
>
> ·         Identify where different tasks occur in the diagram
> Phase 2
>
> ·         For each component, identify the information elements needed to
> carry out the required interactions. For each interaction, define the
> necessary interfaces and operations.
>
> ·         Validate using CVEs
> Phase 3
>
> ·         Identify the information elements needed to carry out the
> optional interactions. Define the necessary interfaces and operations for
> those interactions.
>
> ·         Validate using CVEs
> Phase 4
>
> ·         Add support for discovery of components and capabilities by
> other components
>
> ·         Validate using CVEs
> Deliverables
>
> ·         Updated IM that contains the minimum set of IEs necessary for
> the Vulnerability Assessment Scenario
>
> ·         Updated Architecture that defines the interfaces and operations
> required for the Vulnerability Assessment Scenario
>
> ·         Multiple examples that use CVEs to validate the Vulnerability
> Assessment Scenario
>
> Does this seem like a reasonable summary of this work? Are there things
> that are missing or should be removed from this work?
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 5 Jan 2017 15:47:29 -0800

Hi Danny,

Your suggested phased approach makes sense to me. Does your suggestion 
also implies picking an over the wire protocol for two components to 
communicate? Hope this will allow WG to make forward progress and 
produce some running code. The experience should help us when revisiting 
the IM and architecture drafts.

Thanks.

- Jarrett

On 12/19/16 10:54 AM, Haynes, Dan wrote:
>
> Hi Everyone,
>
> In an effort to address the roadblocks associated with the 
> architecture and scope of the information model, it was suggested at 
> IETF 97 that the WG go through the Vulnerability Assessment Scenario 
> and define the minimum set of interfaces, operations, and information 
> elements necessary execute the scenario. Focusing on the Vulnerability 
> Assessment Scenario will help keep the discussions concrete and very 
> focused. The end result of this work will inform decisions on the 
> architecture and information model that will allow the WG to move 
> forward with a basic set of capabilities and build out additional 
> capabilities as needed. The following is a first pass at what this 
> work might look like and how we might want to approach it as a WG. 
> ·Identify the tasks that are necessary to execute the Vulnerability 
> Assessment Scenario and define their inputs and outputs
>
> ·Identify the interactions between components in the Vulnerability 
> Assessment Scenario and define the interfaces and operations required 
> to support those interactions
>
> ·Identify the information elements necessary to facilitate the 
> ·Validate tasks, interfaces, operations, and information elements by 
> exercising the Vulnerability Assessment Scenario using multiple CVEs
>
>
>     Approach
>
> To ensure the WG can make quick progress, this work should be broken 
> up into multiple phases that gradually build on the previous phase.
>
>
>         Phase 1
>
> ·Assume components are configured to communicate with each other (i.e. 
> ignore discovery for now)
>
> ·Create a diagram that shows the components and their interactions 
> with each other. Highlight which interactions are required and which 
> interactions are optional.
>
> ·Identify where different tasks occur in the diagram
>
>
>         Phase 2
>
> ·For each component, identify the information elements needed to carry 
> out the required interactions. For each interaction, define the 
> ·Validate using CVEs
> ·Identify the information elements needed to carry out the optional 
> interactions. Define the necessary interfaces and operations for those 
> interactions.
>
> ·Validate using CVEs
>
>
>         Phase 4
>
> ·Add support for discovery of components and capabilities by other 
> components
>
> ·Validate using CVEs
>
>
>     Deliverables
>
> ·Updated IM that contains the minimum set of IEs necessary for the 
> ·Updated Architecture that defines the interfaces and operations 
> ·Multiple examples that use CVEs to validate the Vulnerability 
> Assessment Scenario
>
> Does this seem like a reasonable summary of this work? Are there 
> things that are missing or should be removed from this work?
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 6 Jan 2017 00:45:06 +0000

Hi Jarrett,
That's correct. Once we have a better idea of which interfaces and operations must occur between components and the corresponding data, we should have a better idea of which over the wire protocols will satisfy our needs.
Thanks,

Danny
From: sacm [mailto:[email-masked]] On Behalf Of Jarrett Lu
Sent: Thursday, January 05, 2017 6:47 PM
To: [email-masked]
Subject: Re: [sacm] IETF 97 Follow-Up: Using the Vulnerability Assessment Scenario to Make Progress on the Architecture and IM

Hi Danny,

Your suggested phased approach makes sense to me. Does your suggestion also implies picking an over the wire protocol for two components to communicate? Hope this will allow WG to make forward progress and produce some running code. The experience should help us when revisiting the IM and architecture drafts.

Thanks.

- Jarrett

Hi Everyone,

Objectives

Approach

Phase 1

Phase 2

*         Validate using CVEs

Phase 3

*         Validate using CVEs

Phase 4

*         Validate using CVEs

Deliverables

Thanks,

Danny

sacm mailing list

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

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 7 Jan 2017 15:19:42 +0100

Hello Danny, Jarret,

+1

it is my hope that component definitions or and even implementations 
resulting from early phases can be build upon and do not require 
significant refactoring or even have to be discarded in later phases.

If I understand the approach correctly, similar sets of phases will be 
iterated in the SACM WG for other objectives as well. Is that a correct 
assumption?

In regard to the underlying transport: in early phases, it could be 
chosen as simple as possible to support the corresponding interaction 
model and data model. My assumption is, that latest in Phase 4 the 
underlying transport will have to get way more specific and feature rich.

Viele Grüße,

Henk

On 01/06/2017 12:47 AM, Jarrett Lu wrote:
>> Vulnerability Assessment Scenario and define the interfaces and
>> operations required to support those interactions
>>
>> ·         Identify the information elements necessary to facilitate
>> the communication of security automation data between components in
>> elements by exercising the Vulnerability Assessment Scenario using
>> multiple CVEs
>>
>>
>>
>>
>>     Approach
>>
>> ·         Assume components are configured to communicate with each
>> other (i.e. ignore discovery for now)
>>
>> interactions with each other. Highlight which interactions are
>> required and which interactions are optional.
>>
>> ·         For each component, identify the information elements needed
>> to carry out the required interactions. For each interaction, define
>> the necessary interfaces and operations.
>>
>> ·         Validate using CVEs
>>
>>
>>         Phase 3
>>
>> optional interactions. Define the necessary interfaces and operations
>> for those interactions.
>>
>> ·         Validate using CVEs
>>
>>
>>         Phase 4
>>
>> ·         Updated IM that contains the minimum set of IEs necessary
>> for the Vulnerability Assessment Scenario
>>
>> ·         Updated Architecture that defines the interfaces and
>> operations required for the Vulnerability Assessment Scenario
>>
>> ·         Multiple examples that use CVEs to validate the

---

From: "Haynes, Dan" <[email-masked]>
Date: Mon, 9 Jan 2017 14:49:27 +0000

Hi Henk,

Yes, I think if this approach works well for the group, it would be good to take the same approach when tackling other WG objectives.

Yes, I agree Phase 4 would be more complicated. I was thinking that we could iteratively build up our capabilities (through the phases) and once complete select a solution transport that provides those capabilities.

Thanks,

Danny

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Henk Birkholz
> Sent: Saturday, January 07, 2017 9:20 AM
> To: [email-masked]
> Subject: Re: [sacm] IETF 97 Follow-Up: Using the Vulnerability Assessment
> resulting from early phases can be build upon and do not require significant
> refactoring or even have to be discarded in later phases.
> 
> If I understand the approach correctly, similar sets of phases will be iterated
> in the SACM WG for other objectives as well. Is that a correct assumption?
> 
> In regard to the underlying transport: in early phases, it could be chosen as
> simple as possible to support the corresponding interaction model and data
> model. My assumption is, that latest in Phase 4 the underlying transport will
> have to get way more specific and feature rich.
> 
> Viele Grüße,
> 
> Henk
> 
> > produce some running code. The experience should help us when
> > revisiting the IM and architecture drafts.
> >
> > Thanks.
> >
> > - Jarrett
> >
> >
> >> elements necessary execute the scenario. Focusing on the
> >> Vulnerability Assessment Scenario will help keep the discussions
> >> concrete and very focused. The end result of this work will inform
> >> decisions on the architecture and information model that will allow
> >> additional capabilities as needed. The following is a first pass at
> >> what this work might look like and how we might want to approach it as a
> WG.