Subject: [sacm] SACM well defined scope, set of requirements, charter

From: Shawn Mullen <[email-masked]>
Date: Tue, 8 Jan 2013 07:53:38 -0600

Happy New Year.   I wanted to continue on Kathleen's last email thread 
concerning preparation work for the IETF in Orlando,  March 10-15th.  In 
particular creating a well  defined scope, set of  requirements,  charter, 
 and some  supporting  drafts. 

I would like to first suggest that the way we define the scope is to 
reduce or simplified the scope.  One of the re-occurring themes during the 
Atlanta meeting and a strongly echoed concern by Sean was that the scope 
was too broad.  Therefore, it seemed very hard to crisply define, and very 
hard for Sean and attendees to grasp the problem space, strategy and 
solution. 

I suggest we focus on two primary goals/components:
- A generalized device or system security hardening method / XML. 
- A method to query a device or system for their current software install 
and patch levels. 

The major component missing from this short list is system identification 
and enumeration.  I'm suggesting this be dropped from the list for two 
reasons:
1) This topic brought up the most concern during the Atlanta meeting with 
questios about this really being a standards fit for IETF.
2)  We can achieve the two primary goals without this component. 

I'll listen for email response of endorsement or disagreement.  Then 
follow-up with a first pass on the scope definition. 

Shawn Mullen 
STSM 
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551 
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Jan 2013 14:35:07 +0000

Hi,

Thanks for the post-New Year wake-up message.

Kathleen and myself had a conversation with Sean on Monday asking his advice about how to proceed and best focus the work, so that we can have a useful meeting in Orlando followed by successful chartering short after. His guidance is that we can ask for a second BOF in Orlando, provided that in the next three weeks (the cutoff day for asking the ADs for a BOF session is 1/28) we succeed to show a reduced and focus set of goals and requirements (documented in Internet-Drafts) and a workable charter proposal. The session in Orlando will probably be shorter than in Atlanta (we now look at asking for 1.5 hours) and will focus on the primary goals and focused scope. We may discuss new contributions (if there will be such proposals) in side meetings.

So much depends on the work we can do in the next 19 days. As a contributor your suggestion makes sense to me, and I suggest that we factor in also the set of requirements proposed by Adam and the mail thread that followed.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shawn Mullen
Sent: Tuesday, January 08, 2013 3:54 PM
To: [email-masked]
Subject: [sacm] SACM well defined scope, set of requirements, charter

Happy New Year.   I wanted to continue on Kathleen's last email thread concerning preparation work for the IETF in Orlando,  March 10-15th.  In particular creating a well  defined scope, set of  requirements,  charter,  and some  supporting  drafts.

I would like to first suggest that the way we define the scope is to reduce or simplified the scope.  One of the re-occurring themes during the Atlanta meeting and a strongly echoed concern by Sean was that the scope was too broad.  Therefore, it seemed very hard to crisply define, and very hard for Sean and attendees to grasp the problem space, strategy and solution.

I suggest we focus on two primary goals/components:
- A generalized device or system security hardening method / XML.
- A method to query a device or system for their current software install and patch levels.

The major component missing from this short list is system identification and enumeration.  I'm suggesting this be dropped from the list for two reasons:
1) This topic brought up the most concern during the Atlanta meeting with questios about this really being a standards fit for IETF.
2)  We can achieve the two primary goals without this component.

I'll listen for email response of endorsement or disagreement.  Then follow-up with a first pass on the scope definition.

Shawn Mullen
STSM

cell -  (512) 914-8134

---

From: David Solin <[email-masked]>
Date: Sun, 13 Jan 2013 19:35:47 -0600

Unfortunately I was unable to attend the meeting in Atlanta, but I'm a 
little hard-pressed to understand how we can do the former without the 
latter.

I think that we can certainly propose a method and a schema for system 
identification and enumeration, without attempting to turn CPE itself 
into an IETF standard.  An SCAP datastream contains a CPE dictionary and 
OVAL content for system identification (or, at least, applicability 
detection), in addition to benchmark profiles and OVAL (and OCIL) 
definitions for the same.  XCCDF is even extensible to other arbitrary 
check systems.

Why not propose that a datastream should contain a dictionary that is 
compliant with the CPE schema, although it may potentially not be CPE?  
Such a system would at least be fully interoperable within the scope of 
a particular CPE-like dictionary.

Please let me know if my understanding is entirely off the mark.

Regards,
--David Solin

On 1/8/2013 7:53 AM, Shawn Mullen wrote:
> concerning preparation work for the IETF in Orlando,  March 10-15th. 
>  In particular creating a well  defined scope, set of  requirements, 
>  charter,  and some  supporting  drafts.
>
> reduce or simplified the scope.  One of the re-occurring themes during 
> the Atlanta meeting and a strongly echoed concern by Sean was that the 
> scope was too broad.  Therefore, it seemed very hard to crisply 
> define, and very hard for Sean and attendees to grasp the problem 
> space, strategy and solution.
>
> The major component missing from this short list is system 
> identification and enumeration.  I'm suggesting this be dropped from 
> the list for two reasons:
> 1) This topic brought up the most concern during the Atlanta meeting 
> with questios about this really being a standards fit for IETF.
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>