Subject: [sacm] information model

From: Chris Inacio <[email-masked]>
Date: Sun, 16 Nov 2014 04:00:33 +0000

I’ve been thinking a bit harder about the information model and where we stand as a group.  So I have a “lay your cards” on the table questions for the group:  (1) I believe that various participants have some type of data model that is envisioned to be supported by SACM.  So, the question, what data format do you want included in the SACM system?  What role do you expect that data format to provide?

(2) Second question:  What other protocols/standards do you expect SACM to build upon, leverage, or work in parallel with?  (In other words, what would you say is a solved problem by using already standardized X, Y, or Z that will narrow the scope of SACM?)  I expect NEA to show up here, and to provide a certain set of capabilities.

My follow on to this stuff will hopefully to think more clearly about the information model.  The nice thing about working for a university, I don’t particularly have any cards to lay on the table here.  I don’t have any expectations for question 1 or 2.  But I have been thinking about the various possibilities for an information model and the negotiation capabilities.  Right now, my personal feeling is that the SACM protocol is really a wrapper / negotiation protocol that allows disparate systems to decide how to talk - BUT it leaves the giant mandatory to implement hanging over our heads.  (The wrapper would allow all the proxy/security/auth/etc. to happen even with protocols / data formats that don’t include that notion.  That said, this is very far from my first preference in design.)  Secondly, I’m mostly opposed to a strict graph model.  I think you can take the nature of the data (at least as I see it) and turn it into a directed graph – but I’m not in favor of a model that would require a graph representation in order to function. 

--
Chris Inacio
[email-masked]

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 17 Nov 2014 12:26:37 -0500

> (2) Second question:  What other protocols/standards do you expect SACM to build upon, leverage, or work in parallel with?  (In other words, what would you say is a solved problem by using already…

To put it simply, I haven't seen any standards that are better suited to 
this purpose than the combination of XCCDF and OVAL.

And that also determines the answer to your first question.

>
>
> My follow on to this stuff will hopefully to think more clearly about the information model.  The nice thing about working for a university, I don’t particularly have any cards to lay on the table here.  I don’t have any expectations for question 1 or 2.  But I have been thinking about the various possibilities for an information model and the negotiation capabilities.  Right now, my personal feeling is that the SACM protocol is really a wrapper / negotiation protocol that allows disparate systems to decide how to talk - BUT it leaves the giant mandatory to implement hanging over our heads.  (The wrapper would allow all the proxy/security/auth/etc. to happen even with protocols / data formats that don’t include that notion.  That said, this is very far from my first preference in design.)  Secondly, I’m mostly opposed to a strict graph model.  I think you can take the nature of the data (at least as I see it) and turn it into a directed graph – but I’m not in favor of 
a model that would require a graph representation in order to function.
>
>
> --
> Chris Inacio
> [email-masked]
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 20 Nov 2014 13:01:13 -0600

> On Nov 17, 2014, at 11:26 AM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> 
> To put it simply, I haven't seen any standards that are better suited to this purpose than the combination of XCCDF and OVAL.
> 

FWIW, I’ve thought (and mentioned to several in the group on the side) that leveraging SCAP 1.2 specifications (i.e. SCAP 1.2 data streams) would be a useful way to exercise the communication fabric once we start to get that established.  The goal here would *not* be to import the specifications to the working group, but rather to draft something that says “this is how you use the SACM protocol/fabric with SCAP 1.2 data streams” - such a draft would only reference existing specifications.  

I think this could be useful in a couple of ways, but most immediate is that it would: 1) allow a “spike” through the fabric to ensure it’s what we expect, and 2) would provide a cleaner migration path for vendors who are implementing or have implemented SCAP 1.2 already in their products.

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 20 Nov 2014 16:09:20 -0500

On 11/20/2014 2:01 PM, Adam W. Montville wrote:
>
>> On Nov 17, 2014, at 11:26 AM, Gunnar Engelbach
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>> I’ve been thinking a bit harder about the information model and where
>>> we stand as a group.  So I have a “lay your cards” on the table
>>> questions for the group:  (1) I believe that various participants
>>> have some type of data model that is envisioned to be supported by
>>> SACM.  So, the question, what data format do you want included in the
>>> SACM system?  What role do you expect that data format to provide?
>>>
>>>
>>>
>>> (2) Second question:  What other protocols/standards do you expect
>>> SACM to build upon, leverage, or work in parallel with? (In other
>>> words, what would you say is a solved problem by using already
>>> standardized X, Y, or Z that will narrow the scope of SACM?)  I
>>> expect NEA to show up here, and to provide a certain set of capabilities.
>>
>>
>> To put it simply, I haven't seen any standards that are better suited
>> to this purpose than the combination of XCCDF and OVAL.
>>
> FWIW, I’ve thought (and mentioned to several in the group on the side)
> that leveraging SCAP 1.2 specifications (i.e. SCAP 1.2 data streams)
> would be a useful way to exercise the communication fabric once we start
> to get that established.  The goal here would *not* be to import the
> specifications to the working group, but rather to draft something that
> says “this is how you use the SACM protocol/fabric with SCAP 1.2 data
> streams” - such a draft would only reference existing specifications.
>
> I think this could be useful in a couple of ways, but most immediate is
> that it would: 1) allow a “spike” through the fabric to ensure it’s what
> we expect, and 2) would provide a cleaner migration path for vendors who
> are implementing or have implemented SCAP 1.2 already in their products.

The implication here, if I'm understanding you correctly, is that SCAP 
will be a nice test use for the fabric, but will *not* be part of the 
final SACM specification.

And that's fine, because there's a lot about SCAP that is non-ideal, but 
if that's the case I think we also need to be realistic about the time 
scale until SACM has something that can be used to perform security 
automation.

--gun

>
>
>>
>>
>>
>>>
>>>
>>> My follow on to this stuff will hopefully to think more clearly about
>>> the information model.  The nice thing about working for a
>>> university, I don’t particularly have any cards to lay on the table
>>> here.  I don’t have any expectations for question 1 or 2.  But I have
>>> been thinking about the various possibilities for an information
>>> model and the negotiation capabilities.  Right now, my personal
>>> feeling is that the SACM protocol is really a wrapper / negotiation
>>> protocol that allows disparate systems to decide how to talk - BUT it
>>> leaves the giant mandatory to implement hanging over our heads.  (The
>>> wrapper would allow all the proxy/security/auth/etc. to happen even
>>> with protocols / data formats that don’t include that notion.  That
>>> said, this is very far from my first preference in design.)
>>>  Secondly, I’m mostly opposed to a strict graph model.  I think you
>>> can take the nature of the data (at least as I see it) and turn it
>>> into a directed graph – but I’m not in favor of
>>> [email-masked] <mailto:[email-masked]>
>>>
>>>
>>>

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 20 Nov 2014 15:24:58 -0600

> On Nov 20, 2014, at 3:09 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> 
> The implication here, if I'm understanding you correctly, is that SCAP will be a nice test use for the fabric, but will *not* be part of the final SACM specification.
> 
> And that's fine, because there's a lot about SCAP that is non-ideal, but if that's the case I think we also need to be realistic about the time scale until SACM has something that can be used to perform security automation.
> 

You are understanding me correctly, and I’d like to ask you a question about your response.  Can you elaborate on what it means to you to be realistic about time scale?

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 20 Nov 2014 16:35:19 -0500

> You are understanding me correctly, and I’d like to ask you a question about your response.  Can you elaborate on what it means to you to be realistic about time scale?

I'm looking at how long it has taken so far to work on the "fabric" part 
of SACM and how much more has to be done beyond that before it has 
enough parts to be able to automate security assessments.  The majority 
of the work is yet to be done, so let's be realistic about that.