Subject: [sacm] sacm Next Steps containing scope

From: Shawn Mullen <[email-masked]>
Date: Wed, 16 Jan 2013 15:33:49 -0600

Dave,

I agree OVAL has benefits.  However, I'm proposing that we are to focus on 
core functionality of security hardening and patching,  The simple 
hardening method bit of shift in thinking. 

The way I see the vast majority of customer security process is:
1) They security harden a system and test the heck out of it (run 
applications, run pen tests, reviews, etc)
2) Then they capture the policy based on this system (xml) and stamp it on 
all similar systems/workloads (Note: Linux PCI, will be different from 
Linux DMZ workloads)

When the auditor comes:
1) they review the security policy, it's OK
2) run the automated check  and ensure the security xml is set on all of 
similar workloads 

Your Windows registry check is a good example.  The simple protocol will 
not prescribe a detail command like "run windows Scanreg.exe" it will say 
"run registry checks".   Registry checks are a good security precaution. 
In a windows environment the xml would return
<high level requirement> run registry checks </high level requirment>
<endpoint mapping>  scanreg.exe <\endpoint mapping> 
<cmd result> success <\cmd result> 
In a linux environment the mapping would expect to fail or moreover would 
not be part of its policy. 

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)

> 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

> 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. 
> 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

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

> -- 
> jOVAL.org: SCAP Simplified.
> Learn More | Features | Download 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm