Subject: Re: [sacm] sacm Next Steps

From: Shawn Mullen <[email-masked]>
Date: Mon, 14 Jan 2013 22:54:53 -0600

David,

If you want to get it started I'd be happy to help carry the torch until 
your return. 

In response to David Solin concern that CPE dictionary is required in this 
process let me clarify my thoughts.
To elaborate on my point about not have a CPE dictionary or even a 
reference to CPE, let me say CPE and its value is good for security and IT 
management, but not necessary for security configuration automation. 
Operating Systems and network attached devices all have very similar 
security features and capabilities.  Industry, government and corporate 
security compliance requirements are written around these general finite 
set of features.   Whether it is a toaster or a Cray we'd want a simple 
way of saying, "Set your minimum password to 8."  Kind of like TCP/IP; I 
don't care how you implement TCP/IP I just want you to just speak it 
correctly. 
Of course we're talking about the security of system and need some 
understanding of how this was accomplished, so I am advocating an approach 
similar to ACEML: 
http://blog.opengroup.org/2011/07/19/the-open-group-releases-o-aceml-standard-automates-compliance-configuration/ 
   <- high level description
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12351 
 <- low level description 

ACEML simplifies the authoring of compliance rules and flow.  Each rule 
has 3 sectionand flows like this:

Section 1 "High level security setting rule"
| set your password length to 8 |
This is sent directly to the device be it a toaster or Cray.

Section 2 "Mapping of High level security setting to an actionable command 
or setting" 
The endpoint device knows who they are and what security commands they 
have, so they write the command back into the xml file, and they execute 
the command.  Now the xml rule looks like:
| set your password length to 8 |
| set toaster_passwd = 8             |

Section 3 "Result of executing or checking the actionable command"
The result of the command (be it setting or checking) is written into the 
xml file.  Now the xml rule looks like:
| set your password length to 8 |
| set/chk toaster_passwd = 8     |
| success                                          |

The completed xml is sent back to the central security management point 
and it contains all of the artifacts need for a security auditor. 

One of the biggest benefits I see is that it allows in the little guys, 
the toasters.   Customer want one and only one central security management 
solution for their heterogeneous environments.   These security solutions 
will support the Windows and IBM big market end points, not the too 
expensive to test small toasters.  If SACM protocol is the common language 
between the console and endpoint it can be independent like TCP: I speak 
TCP, I can talk on the network.  I talk SACM you can send security 
configuration settings to me.  If I cannot do a particular setting then 
the audit may fail. 

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:   [email-masked]
To:     [email-masked]
Date:   01/14/2013 09:57 AM
Subject:        sacm Digest, Vol 11, Issue 5
Sent by:        [email-masked]

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/sacm

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send sacm mailing list submissions to
                 [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
                 https://www.ietf.org/mailman/listinfo/sacm
or, via email, send a message with subject or body 'help' to
                 [email-masked]

You can reach the person managing the list at
                 [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sacm digest..."
Today's Topics:

   1. Re: SACM UC1 And Related Requirements - Next steps
      (Adam Montville)
   2. Re: SACM UC1 And Related Requirements - Next steps
      (Waltermire, David A.)

----- Message from Adam Montville <[email-masked]> on Mon, 14 Jan 
2013 15:04:09 +0000 -----
To:
"Moriarty, Kathleen" <[email-masked]>
cc:
"[email-masked]" <[email-masked]>
Subject:
Re: [sacm] SACM UC1 And Related Requirements - Next steps

Kathleen, 

I can put the requirements in the UC document. I may not be able to 
complete that until February however - I'll be out of pocket for about the 
next two weeks.

Adam

On Jan 13, 2013, at 4:24 PM, "Moriarty, Kathleen" <
[email-masked]> wrote:

Thank you all for the great discussion on requirements and to Adam for 
keeping the discussion organized!

Adam, could you take the requirements as they are now and put them into 
the use case document?  Some IETF folks will want to see these in an 
actual document and the use case document will work.

The next steps that we agreed to previously was to work on an architecture 
document.  I think Dave Waltermire had some ideas here, but we wanted to 
make sure it was first based on requirements.  WOuld it be possible to 
start that discussion now and have a document before the deadline for the 
Orlando meeting?  The date for -00 drafts is 2/28/13.

Thank you!
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gary 
Gapinski [[email-masked]]
Sent: Friday, December 14, 2012 4:48 PM
To: David Solin
Cc: [email-masked]
Subject: Re: [sacm] SACM UC1 And Related Requirements

On 12/14/2012 03:54 PM, David Solin wrote:
Your position, then, Gary, is that there should be no such thing as an
external reference?

No (assuming I understand the nature of "external" references. I presume
external references are those from from one document to another.). I
think there should be as many as desired. I had hoped to express this by
stating "Various consumers of such a policy might wish to say varying
things about it. One common thing is an identifier unique in some 
domain.".

I expect that creators of security automation content will declare
references amongst all the things they deem worthwhile. I hope they do.

However, if such references are declared within the content itself
(i.e., in a document describing a policy), as opposed to separate and
separately maintained statements of such association, it casts the
reference in a role that is then subject to considerations at least of
revision. Such considerations are manageable if revision enjoys adequate
treatment within SACM.

I must also caution that external references do not imply the ability to
discern anything other than relation.

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

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

Adam W. Montville | Security and Compliance Architect
Direct: 503 276-7661
Mobile: 360 471-7815 

TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

----- Message from "Waltermire, David A." <[email-masked]> on 
Mon, 14 Jan 2013 10:52:59 -0500 -----
To:
Adam Montville <[email-masked]>, "Moriarty, Kathleen" 
<[email-masked]>
cc:
"[email-masked]" <[email-masked]>
Subject:
Re: [sacm] SACM UC1 And Related Requirements - Next steps

I’d be happy to help with this in the short-run, since Adam will be out of 
pocket.
Dave
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Adam Montville
Sent: Monday, January 14, 2013 10:04 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [sacm] SACM UC1 And Related Requirements - Next steps
 
Kathleen, 
 
I can put the requirements in the UC document. I may not be able to 
complete that until February however - I'll be out of pocket for about the 
next two weeks.
 
Adam
 
On Jan 13, 2013, at 4:24 PM, "Moriarty, Kathleen" <
[email-masked]> wrote:

Thank you all for the great discussion on requirements and to Adam for 
keeping the discussion organized!

Adam, could you take the requirements as they are now and put them into 
the use case document?  Some IETF folks will want to see these in an 
actual document and the use case document will work.

The next steps that we agreed to previously was to work on an architecture 
document.  I think Dave Waltermire had some ideas here, but we wanted to 
make sure it was first based on requirements.  WOuld it be possible to 
start that discussion now and have a document before the deadline for the 
Orlando meeting?  The date for -00 drafts is 2/28/13.

Thank you!
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gary 
Gapinski [[email-masked]]
Sent: Friday, December 14, 2012 4:48 PM
To: David Solin
Cc: [email-masked]
Subject: Re: [sacm] SACM UC1 And Related Requirements

On 12/14/2012 03:54 PM, David Solin wrote:

Your position, then, Gary, is that there should be no such thing as an
external reference?

No (assuming I understand the nature of "external" references. I presume
external references are those from from one document to another.). I
think there should be as many as desired. I had hoped to express this by
stating "Various consumers of such a policy might wish to say varying
things about it. One common thing is an identifier unique in some 
domain.".

I expect that creators of security automation content will declare
references amongst all the things they deem worthwhile. I hope they do.

However, if such references are declared within the content itself
(i.e., in a document describing a policy), as opposed to separate and
separately maintained statements of such association, it casts the
reference in a role that is then subject to considerations at least of
revision. Such considerations are manageable if revision enjoys adequate
treatment within SACM.

I must also caution that external references do not imply the ability to
discern anything other than relation.

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

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

Adam W. Montville | Security and Compliance Architect
Direct: 503 276-7661
Mobile: 360 471-7815 

TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

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

---

From: David Solin <[email-masked]>
Date: Tue, 15 Jan 2013 12:10:33 -0600

That is all well and good, but there are two reasons to have something 
like CPE:

The first is that allows you to define applicability criteria for a 
security benchmark, that are tied to inventory definitions expressed in 
OVAL.

The second is that, in a multi-SCAP-datastream scenario, it allows you 
to define multiple benchmarks that have defined applicability 
relationships to a set of "platforms" with known inventory definitions 
(in OVAL).

What I think is potentially disposable is the idea that we must codify a 
universal enumeration that everyone on Earth (and perhaps beyond) is 
required to share as part of our standard.  But I think it is essential 
that we should be able to express enumerations and associated inventory 
definitions that are potentially shareable between different 
users/systems/implementations.

Without this, we'll end up having no automated way to determine whether 
it makes any sense to run certain checks on a system (e.g., Windows 
registry checks on a toaster running QNX).

Regards,
--David

On 1/14/2013 10:54 PM, Shawn Mullen wrote:
> David,
>
> If you want to get it started I'd be happy to help carry the torch 
> until your return.
>
> In response to David Solin**concern that CPE dictionary is required in 
> this process let me clarify my thoughts.
> reference to CPE, let me say CPE and its value is good for security 
> and IT management, but not necessary for security configuration 
> automation.  Operating Systems and network attached devices all have 
> very similar security features and capabilities.  Industry, government 
> and corporate security compliance requirements are written around 
> these general finite set of features.   Whether it is a toaster or a 
> Cray we'd want a simple way of saying, "Set your minimum password to 
> 8."  Kind of like TCP/IP; I don't care how you implement TCP/IP I just 
> want you to just speak it correctly.
> understanding of how this was accomplished, so I am advocating an 
> approach similar to ACEML:
> https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12351 <- 
> low level description
>
> ACEML simplifies the authoring of compliance rules and flow.  Each 
> rule has 3 sectionand flows like this:
>
> Section 2 "Mapping of High level security setting to an actionable 
> command or setting"
> have, so they write the command back into the xml file, and they 
> execute the command.  Now the xml rule looks like:
> The result of the command (be it setting or checking) is written into 
> the xml file.  Now the xml rule looks like:
> The completed xml is sent back to the central security management 
> point and it contains all of the artifacts need for a security auditor.
>
> One of the biggest benefits I see is that it allows in the little 
> guys, the toasters.   Customer want one and only one central security 
> management solution for their heterogeneous environments.   These 
> security solutions will support the Windows and IBM big market end 
> points, not the too expensive to test small toasters.  If SACM 
> protocol is the common language between the console and endpoint it 
> can be independent like TCP: I speak TCP, I can talk on the network. 
>  I talk SACM you can send security configuration settings to me.  If I 
> cannot do a particular setting then the audit may fail.
>
> Shawn Mullen
> STSM
> ------------------------------------------------------------------------
>
>
>
> ----- Message from Adam Montville <[email-masked]> on Mon, 14 
> Jan 2013 15:04:09 +0000 -----
> *To:*
> 	
> *cc:*
> *Subject:*
> complete that until February however - I'll be out of pocket for about 
> the next two weeks.
>
> Adam
>
> On Jan 13, 2013, at 4:24 PM, "Moriarty, Kathleen" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Adam, could you take the requirements as they are now and put them 
> into the use case document?  Some IETF folks will want to see these in 
> an actual document and the use case document will work.
>
> The next steps that we agreed to previously was to work on an 
> architecture document.  I think Dave Waltermire had some ideas here, 
> but we wanted to make sure it was first based on requirements.  WOuld 
> it be possible to start that discussion now and have a document before 
> the deadline for the Orlando meeting?  The date for -00 drafts is 2/28/13.
>
> Thank you!
> Kathleen
> From: [email-masked] 
> <mailto:[email-masked]>[[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Gary Gapinski 
> [[email-masked] <mailto:[email-masked]>]
> Cc: [email-masked] <mailto:[email-masked]>
> sacm mailing list_
> [email-masked] <mailto:[email-masked]>
> *
> Adam W. Montville *| Security and Compliance Architect
> Direct: 503 276-7661
> Mobile: 360 471-7815
> *
> TRIPWIRE* | CONFIDENCE: *SECURED*_
> __www.tripwire.com_ <http://www.tripwire.com/>
>
>
>
>
>
> ----- Message from "Waltermire, David A." <[email-masked]> 
> on Mon, 14 Jan 2013 10:52:59 -0500 -----
> *To:*
> 	
> *cc:*
> *Subject:*
> I'd be happy to help with this in the short-run, since Adam will be 
> out of pocket.
> Dave
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Adam Montville*
> Sent:* Monday, January 14, 2013 10:04 AM*
> To:* Moriarty, Kathleen*
> Cc:* [email-masked]*
> Subject:* Re: [sacm] SACM UC1 And Related Requirements - Next steps
>
> Kathleen,
>
> complete that until February however - I'll be out of pocket for about 
> the next two weeks.
>
> Adam
>
> On Jan 13, 2013, at 4:24 PM, "Moriarty, Kathleen" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> Adam, could you take the requirements as they are now and put them 
> into the use case document?  Some IETF folks will want to see these in 
> an actual document and the use case document will work.
>
> The next steps that we agreed to previously was to work on an 
> architecture document.  I think Dave Waltermire had some ideas here, 
> but we wanted to make sure it was first based on requirements.  WOuld 
> it be possible to start that discussion now and have a document before 
> the deadline for the Orlando meeting?  The date for -00 drafts is 2/28/13.
>
> Thank you!
> Kathleen
> From: [email-masked] 
> <mailto:[email-masked]>[[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Gary Gapinski 
> [[email-masked] <mailto:[email-masked]>]
> Cc: [email-masked] <mailto:[email-masked]>
> 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_
>
> *
> Adam W. Montville *| Security and Compliance Architect
>
> Direct: 503 276-7661
> Mobile: 360 471-7815
>
> *
> TRIPWIRE* | CONFIDENCE: *SECURED*_
> __www.tripwire.com_ <http://www.tripwire.com/>
>
>

-- 

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

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 18 Jan 2013 22:44:59 -0500

I agree, although the solution we use doesn't have to be CPE.  The ISO 19770-2 Software ID tagging standard is a valid alternative.  It may be possible to build an applicability language around its use.  It is also possible to generate CPE Names from SWID tags so they both can co-exist.  Here is a good explanation:

http://tagvault.org/Automating_CPE_name_creation

Attached is a set of slides I developed illustrating how the current applicability language can be extended to support SWID tags.  This approach would also enable any policy/asset attribute to be used as well.  I'd appreciate any feedback.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Solin
Sent: Tuesday, January 15, 2013 1:11 PM
To: [email-masked]
Subject: Re: [sacm] sacm Next Steps

That is all well and good, but there are two reasons to have something like CPE:

The first is that allows you to define applicability criteria for a security benchmark, that are tied to inventory definitions expressed in OVAL.

The second is that, in a multi-SCAP-datastream scenario, it allows you to define multiple benchmarks that have defined applicability relationships to a set of "platforms" with known inventory definitions (in OVAL).

What I think is potentially disposable is the idea that we must codify a universal enumeration that everyone on Earth (and perhaps beyond) is required to share as part of our standard.  But I think it is essential that we should be able to express enumerations and associated inventory definitions that are potentially shareable between different users/systems/implementations.

Without this, we'll end up having no automated way to determine whether it makes any sense to run certain checks on a system (e.g., Windows registry checks on a toaster running QNX).

Regards,
--David

If you want to get it started I'd be happy to help carry the torch until your return.

In response to David Solin concern that CPE dictionary is required in this process let me clarify my thoughts.
To elaborate on my point about not have a CPE dictionary or even a reference to CPE, let me say CPE and its value is good for security and IT management, but not necessary for security configuration automation.  Operating Systems and network attached devices all have very similar security features and capabilities.  Industry, government and corporate security compliance requirements are written around these general finite set of features.   Whether it is a toaster or a Cray we'd want a simple way of saying, "Set your minimum password to 8."  Kind of like TCP/IP; I don't care how you implement TCP/IP I just want you to just speak it correctly.
Of course we're talking about the security of system and need some understanding of how this was accomplished, so I am advocating an approach similar to ACEML:
http://blog.opengroup.org/2011/07/19/the-open-group-releases-o-aceml-standard-automates-compliance-configuration/    <- high level description
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12351  <- low level description

ACEML simplifies the authoring of compliance rules and flow.  Each rule has 3 sectionand flows like this:

Section 2 "Mapping of High level security setting to an actionable command or setting"
The endpoint device knows who they are and what security commands they have, so they write the command back into the xml file, and they execute the command.  Now the xml rule looks like:
| set your password length to 8 |
| set toaster_passwd = 8             |

Section 3 "Result of executing or checking the actionable command"
The result of the command (be it setting or checking) is written into the xml file.  Now the xml rule looks like:
| set your password length to 8 |
| set/chk toaster_passwd = 8     |
| success                                          |

The completed xml is sent back to the central security management point and it contains all of the artifacts need for a security auditor.

One of the biggest benefits I see is that it allows in the little guys, the toasters.   Customer want one and only one central security management solution for their heterogeneous environments.   These security solutions will support the Windows and IBM big market end points, not the too expensive to test small toasters.  If SACM protocol is the common language between the console and endpoint it can be independent like TCP: I speak TCP, I can talk on the network.  I talk SACM you can send security configuration settings to me.  If I cannot do a particular setting then the audit may fail.

Shawn Mullen
STSM

cell -  (512) 914-8134

From:        [email-masked]<mailto:[email-masked]>
To:        [email-masked]<mailto:[email-masked]>
Date:        01/14/2013 09:57 AM
Subject:        sacm Digest, Vol 11, Issue 5
Sent by:        [email-masked]<mailto:[email-masked]>
________________________________

Send sacm mailing list submissions to
                [email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
                https://www.ietf.org/mailman/listinfo/sacm
or, via email, send a message with subject or body 'help' to
                [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
                [email-masked]<mailto:[email-masked]>

----- Message from Adam Montville <[email-masked]><mailto:[email-masked]> on Mon, 14 Jan 2013 15:04:09 +0000 -----
To:

"Moriarty, Kathleen" <[email-masked]><mailto:[email-masked]>

cc:

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

Subject:

Kathleen,

I can put the requirements in the UC document. I may not be able to complete that until February however - I'll be out of pocket for about the next two weeks.

Adam

On Jan 13, 2013, at 4:24 PM, "Moriarty, Kathleen" <[email-masked]<mailto:[email-masked]>> wrote:

Thank you all for the great discussion on requirements and to Adam for keeping the discussion organized!

Adam, could you take the requirements as they are now and put them into the use case document?  Some IETF folks will want to see these in an actual document and the use case document will work.

The next steps that we agreed to previously was to work on an architecture document.  I think Dave Waltermire had some ideas here, but we wanted to make sure it was first based on requirements.  WOuld it be possible to start that discussion now and have a document before the deadline for the Orlando meeting?  The date for -00 drafts is 2/28/13.

Thank you!
Kathleen
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Gary Gapinski [[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 14, 2012 4:48 PM
To: David Solin
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM UC1 And Related Requirements

things about it. One common thing is an identifier unique in some domain.".

_______________________________________________
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

TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com<http://www.tripwire.com/>

----- Message from "Waltermire, David A." <[email-masked]><mailto:[email-masked]> on Mon, 14 Jan 2013 10:52:59 -0500 -----
To:

Adam Montville <[email-masked]><mailto:[email-masked]>, "Moriarty, Kathleen" <[email-masked]><mailto:[email-masked]>

cc:

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

Subject:

I'd be happy to help with this in the short-run, since Adam will be out of pocket.
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Monday, January 14, 2013 10:04 AM
To: Moriarty, Kathleen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM UC1 And Related Requirements - Next steps

Kathleen,

I can put the requirements in the UC document. I may not be able to complete that until February however - I'll be out of pocket for about the next two weeks.

Adam

On Jan 13, 2013, at 4:24 PM, "Moriarty, Kathleen" <[email-masked]<mailto:[email-masked]>> wrote:

Thank you all for the great discussion on requirements and to Adam for keeping the discussion organized!

Adam, could you take the requirements as they are now and put them into the use case document?  Some IETF folks will want to see these in an actual document and the use case document will work.

The next steps that we agreed to previously was to work on an architecture document.  I think Dave Waltermire had some ideas here, but we wanted to make sure it was first based on requirements.  WOuld it be possible to start that discussion now and have a document before the deadline for the Orlando meeting?  The date for -00 drafts is 2/28/13.

Thank you!
Kathleen
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Gary Gapinski [[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 14, 2012 4:48 PM
To: David Solin
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM UC1 And Related Requirements

things about it. One common thing is an identifier unique in some domain.".

_______________________________________________
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

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com<http://www.tripwire.com/>

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

sacm mailing list

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

--

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

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 19 Jan 2013 07:34:54 -0500

On 2013-01-18 10:44 PM, Waltermire, David A. wrote:
>
> I agree, although the solution we use doesn't have to be CPE. The ISO 
> 19770-2 Software ID tagging standard is a valid alternative.  It may 
> be possible to build an applicability language around its use.  It is 
> also possible to generate CPE Names from SWID tags so they both can 
> co-exist.  Here is a good explanation:
>
> Attached is a set of slides I developed illustrating how the current 
> applicability language can be extended to support SWID tags.  This 
> approach would also enable any policy/asset attribute to be used as 
> well.  I'd appreciate any feedback.
>
> Sincerely,
>
> Dave
>
>

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 19 Jan 2013 07:52:34 -0500

Dave,

You should be aware that 3GPP this past year
brought together the major hardware and software
vendors to examine a SWID like approach which
they rejected.  Instead they worked with the major
OS vendors to adopted a common signature approach
that does not require a massive set of global registries
which doesn't exactly scale.

Their alternative has been adopted by all the relevant
3GPP committees and is included in Rel.11 of the
GSM standard for global deployment.  I believe the
OMA has also adopted the same approach.  This
was also discussed at the IT-SAC in November.

You can also pull the spec off the 3GPP standards
site for free rather than paying out money to ISO. :-)

--t

---

From: Gary Gapinski <[email-masked]>
Date: Sat, 19 Jan 2013 08:28:51 -0500

> which doesn't exactly scale.

I'm quite pleased to hear this. Mobile devices continue to displace the
ones having had previous SACM attention at an ever increasing pace, and
have been ill-served thus far by security automation.

It is appropriate for the creators of things to identify those things.

> site for free rather than paying out money to ISO. :-)

Can you supply a hint (series) of where in those standards one should
look for this?

Regards,

Gary

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 22 Jan 2013 09:40:28 -0500

Tony,

What requirements are 3GPP addressing by using a common signature approach?  I'd like to understand more about this decision and what is accomplished by the signature approach so we are comparing apples-to-apples.  SWID (ISO/IEC 19770-2) directly supports product naming/identification, identification of entitlements (licenses) relative to the software, software inventory, software integrity checking, and others if the necessary properties are provided.  Many of these use cases go beyond CPE's capabilities minus software applicability to support the larger domain of software asset management and license management (further addressed by the future 19770-3).  Any additional info or pointers to related documents would be appreciated.

Sincerely,
Dave

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Saturday, January 19, 2013 7:53 AM
To: Waltermire, David A.
Cc: David Solin; [email-masked]
Subject: Re: [sacm] sacm Next Steps

Dave,

--t

Sincerely,
Dave

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 23 Jan 2013 09:45:25 -0500

Hi Dave,

They are addressing identical needs. This work
has been done over the past 18 months and there
are many standards contributions over more than
a dozen meetings. I'll pull together something
comprehensive, but one of the key early documents
is attached.

At the ITSAC discussion on this in November and
other the many other venues where app identity
has been visited, the vendors and others in the field
do not seem to support the SWID approach.

Could you share the relevant 19770 documents?

--tony

On 1/22/2013 9:40 AM, Waltermire, David A. wrote:
>
> What requirements are 3GPP addressing by using a common signature 
> approach? I’d like to understand more about this decision and what is 
> accomplished by the signature approach so we are comparing 
> apples-to-apples. SWID (ISO/IEC 19770-2) directly supports product 
> naming/identification, identification of entitlements (licenses) 
> relative to the software, software inventory, software integrity 
> checking, and others if the necessary properties are provided. Many of 
> these use cases go beyond CPE’s capabilities minus software 
> applicability to support the larger domain of software asset 
> management and license management (further addressed by the future 
> 19770-3). Any additional info or pointers to related documents would 
> be appreciated.
>