Subject: [sacm] Getting to Specific Deliverables

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 18:14:06 +0000

As I just discussed with Dave on the list, we need to
agree on exactly what this deliverable means:

- Standards Track documents specifying communication protocols and
  data formats used for security assessment of systems

I've seen several rough cuts (from Adam and Gunnar
and others) but I don't think we're there yet. We
don't have agreement on the list.

I suggest the following steps to get to agreement:

1) Remove the last four deliverables from our charter for
   now. These are specific deliverables pertaining to assets
   and platforms. That's nice but we don't understand and
   agree on the requirements and architecture for SACM yet.
   We're not ready to identify specific deliverables.

2) Discuss the SACM architecture thoroughly on the list.
   Maybe we can start with Gunnar's email from yesterday.
   Anyway, let's get to the point where we can agree on
   specifics. Exactly which specs do we need?

3) Once we agree on specific deliverables, add those to
   the charter and remove the abstract deliverable that
   we have there now.

What do you think of this approach?

Thanks,

Steve

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 17 Jan 2013 13:32:56 -0500

I think that sounds like a good plan.  I agree with removing the items on assets and platforms as it is leading and the requirements and architecture should guide the approach instead.

Best regards,
Kathleen

Sent from my iPhone

On Jan 17, 2013, at 1:20 PM, "Stephen Hanna" <[email-masked]> wrote:

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 17 Jan 2013 13:54:34 -0500

It seems to me the starting point is to identify all the individual 
entities involved (ignoring for the moment the content repository, since 
that's a separate milestone).  From that will shake out the 
communications that need to happen.  I'll stand up a strawman.

Breaking that completely apart, my entity list would be

  [CTR] Controller
  [CFE] Controller front end (UI)
  [RDS] Results data store
  [RVW] Results viewer
  [DC]  Data collector
  [EV]  Benchmark evaluator

Most of the time I expect that many of these entities will be combined. 
  The Results viewer, controller, and controller front end, for example. 
  Some entities will not need to talk to other entities.

What I end up with, then, is a chart something like this, where each "X" 
represents a two-way (asymmetrical) communication that needs to happen:

	CTR	CFE	RDS	RVW	DC	EV
CTR	 -	 X	 1	 -	 -	 X

CFE	 X	 -	 -	 -	 -	 -

RDS	 1	 -	 -	 X	 -	 2

RVW	 -	 -	 X	 -	 -	 -

  DC	 -	 -	 -	 -	 -	 X

  EV	 X	 -	 2	 -	 X	 -

1) Having the controller broker results between the evaluator and the 
results data store is a more consistent model, but adds a step in the 
communication without necessarily adding any value.

2) Communicating directly from the entity that produces the result set 
is more efficient, but could raise other needs such as which data store 
to report to.

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 Jan 2013 13:57:56 -0500

This sounds good to me.  I posted a rough architecture proposal back in November along with a rough drawing (attached).  Here is the link:

http://www.ietf.org/mail-archive/web/sacm/current/msg00731.html

This might be a good place to start to get to specifics.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Thursday, January 17, 2013 1:14 PM
To: [email-masked]'
Subject: [sacm] Getting to Specific Deliverables

As I just discussed with Dave on the list, we need to agree on exactly what this deliverable means:

I've seen several rough cuts (from Adam and Gunnar and others) but I don't think we're there yet. We don't have agreement on the list.

Thanks,

Steve

---

From: Gary Gapinski <[email-masked]>
Date: Thu, 17 Jan 2013 14:15:45 -0500

>    We're not ready to identify specific deliverables.

I agree.

This means that asset description format is retained, and asset
identification is removed. I expect that adequate asset description
subsumes the latter.

The other three are platform naming|matching|applicability, and I expect
that assets will have "platform" as a (likely multi-valued) part of
their description (and thus "platform" is subsumed in asset description).

> What do you think of this approach?

It should work well.

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 17 Jan 2013 14:20:42 -0500

Nuts.  If I had kept up with my email back in November I could have 
skipped my last message and gone off to an early lunch instead.

Still, encouraging to see how convergent both are.

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 22:55:19 +0000

Gary,

I meant to suggest removing the last FIVE deliverables
not the last FOUR ones. Sorry about that mistake.

Quite possibly, we will need to have a standard asset
description format, among other things. But I think
we should determine that based on our architecture.

Thanks,

Steve

> From: Gary Gapinski [mailto:[email-masked]]
> Sent: Thursday, January 17, 2013 2:16 PM
> To: Stephen Hanna
> Cc: [email-masked]'
> Subject: Re: [sacm] Getting to Specific Deliverables
>

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 17 Jan 2013 18:42:34 -0500

I agree we are not ready to identify specific deliverables yet.
I would expect the list of participants/contributors to change a bit once
SACM is approved as a WG.
And new participants might have views about the specifics of the
deliverables.
So I wouldn't try to "concrete-ize" what the solution looks like before
establishing the WG.
I think we can start the WG with a good idea of the scope of the problem
that needs solving.
And we could start with a proposed architecture.
But until we have some WG consensus on the architecture, detailing the parts
in the charter would seem premature.
And the IESG might not want to pre-approve deliverables without a WG
discussion of the proposed architecture first.
(Such architecture discussions would probably include discussion of needed
protocols, data models, etc.)

I would recommend an initial charter that includes use cases, requirements,
and architecture 
plus a deliverable of a proposed re-charter to address specific deliverables
beyond that.
Delivering use cases, requirements, and architecture in a timely manner
would demonstrate to the responsible AD that the WG has an active community
of participants, can deliver documents, and can reach consensus on a
strategic direction. 
Given that, the IESG approving a re-charter is a piece of cake.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Hanna
Sent: Thursday, January 17, 2013 1:14 PM
To: [email-masked]'
Subject: [sacm] Getting to Specific Deliverables

As I just discussed with Dave on the list, we need to agree on exactly what
this deliverable means:

I've seen several rough cuts (from Adam and Gunnar and others) but I don't
think we're there yet. We don't have agreement on the list.

Thanks,

Steve

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 18 Jan 2013 00:17:21 -0500

I agree that the IETF cares more about protocols than architectures.
I have a concern that there is an assumption a NEW protocol is needed.
But the IETF has existing protocols for configuration and configuration
monitoring (e.g., netconf).
So I would caution against adding a bullet item to develop a protocol before
the use cases or requirements or architecture are documented.
We might want to document the use cases, requirements, and proposed
architecture first so the IETF can decide whether a new protocol is needed
or not.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, January 17, 2013 6:54 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sacm] Getting to Specific Deliverables

One caution.  I think IETF usually cares more about useful protocols (and
running code, etc.) than architectures.
So, the Use Cases, Requirements, and Architecture are fine, but I would put
a proposed protocol document as the end goal in mind.
We don't have to be too specific, just identify that we know there are at
least two nodes between which a certain type of information needs to be
sent.

What needs to be concrete is that there is a definite need to transfer
something.  
The charter just doesn't need to get concrete about what that is prior to
the meetings of the WG.
So, I would include the need for one protocol document.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ietfdbh
Sent: Thursday, January 17, 2013 3:43 PM
To: 'Stephen Hanna'; [email-masked]
Subject: Re: [sacm] Getting to Specific Deliverables

I would recommend an initial charter that includes use cases, requirements,
and architecture plus a deliverable of a proposed re-charter to address
specific deliverables beyond that.
Delivering use cases, requirements, and architecture in a timely manner
would demonstrate to the responsible AD that the WG has an active community
of participants, can deliver documents, and can reach consensus on a
strategic direction. 
Given that, the IESG approving a re-charter is a piece of cake.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----

Thanks,

Steve

---

From: Gary Gapinski <[email-masked]>
Date: Fri, 18 Jan 2013 02:29:39 -0500

> not the last FOUR ones. Sorry about that mistake.

No problem. I did think it a bit odd it would be retained while the
others weren't. The enumerators can stand down for now.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 18 Jan 2013 07:48:06 -0500

Hi David,

Yes, I think there is agreement on using existing protocols where possible.  The charter stated that at one point.  We will likely need relationships to some existing protocols to gather data from systems beyond windows and to talk to devices so that we may use one language across all platforms without trying to get vendors to conform.  It's just more practical.

Thanks,
Kathleen 

Sent from my iPhone

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 18 Jan 2013 14:10:01 +0000

Kathleen Moriarty said:
> Yes, I think there is agreement on using existing protocols where
> possible.  The charter stated that at one point.

The current charter says in two places:

> Define, either by normative reference, adoption, or creation, a set
> of standards for [...]

I think that covers the issue but if we want to strengthen this
we can add language that says we'll prefer reuse of existing
protocols when feasible. Opinions on whether that's needed?

Thanks,

Steve

> Moriarty, Kathleen
> Sent: Friday, January 18, 2013 7:48 AM
> To: ietfdbh
> Cc: Stephen Hanna; Michael Hammer; [email-masked]
> Yes, I think there is agreement on using existing protocols where
> possible.  The charter stated that at one point.  We will likely need
> relationships to some existing protocols to gather data from systems
> beyond windows and to talk to devices so that we may use one language
> across all platforms without trying to get vendors to conform.  It's
> just more practical.
> 
> Thanks,
> Kathleen
> 
> Sent from my iPhone
>

---

From: Gary Gapinski <[email-masked]>
Date: Fri, 18 Jan 2013 09:24:07 -0500

> protocols when feasible. Opinions on whether that's needed?

Not needed. Regular strength as opposed to extra strength.