Subject: [sacm] SACM UC1 And Related Requirements

From: Adam Montville <[email-masked]>
Date: Tue, 11 Dec 2012 18:39:25 +0000

All:

After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far:

  *   UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties
  *   Asset representation/identification should support those delivered by a given Service Provider (SP)
  *   Supporting data formats and/or protocols should support assessment of SP-provided assets
  *   Must provide a method of defining a target system (asset identification; asset classification)
  *   Must provide a method of selecting acceptable state policy (test expression)
  *   Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation)
  *   Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation)
  *   Must provide a method of comparing actual to expected state values (test evaluation; test expression)
  *   Must provide a protocol for connecting to a content repository containing SACM content
  *   Must provide a protocol for querying SACM content held in a content repository
  *   Must provide a protocol of retrieving SACM content from a content repository
  *   Must provide a protocol for curating SACM content in a content repository

In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Controls [1] under the following controls:

  *   Critical Control 1: Inventory of Authorized and Unauthorized Devices
  *   Critical Control 2: Inventory of Authorized and Unauthorized Software
  *   Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
  *   Critical Control 4: Continuous Vulnerability Assessment and Remediation
  *   Critical Control 5: Malware Defenses
  *   Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

I have not yet parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control.  For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned.

I have this Friday (12/14) dedicated to fleshing out these requirements.  If you have contributions to make, I respectfully request that you do so before then.

Regards,

Adam

[1] http://www.sans.org/critical-security-controls/

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 12 Dec 2012 17:02:30 +0000

Adam,

Thanks for putting together this initial list of requirements. This is a good start. I do have some questions:

1)      Is BYOD in scope? I think it should be. It's a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: "or brought and owned by end users".

2)      Do we really need protocols for accessing a content repository for UC1? Why?

I'm glad to see us moving forward with this and other issues.

Take care,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: [email-masked]
Subject: [sacm] SACM UC1 And Related Requirements

All:

Regards,

Adam

---

From: Adam Montville <[email-masked]>
Date: Wed, 12 Dec 2012 17:09:12 +0000

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <[email-masked]<mailto:[email-masked]>> wrote:

Adam,

1)      Is BYOD in scope? I think it should be. It’s a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: “or brought and owned by end users”.

This change seems reasonable to me.  We can ensure we address the issue, and then leave it to organizations using implementations of the standards/guidelines we produce as to how they want to apply the technology.

It seems to me that these are likely to be "light," but are needed.  How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc.

I don't think we need anything heavy, just enough to say: If you want to get assessment content, find the content repository, and form your request like this, and you'll get your response.

Notionally, it's easy for me to see a service-oriented interface using a REST API to get this type of thing done, but that's getting the cart before the horse, I think.

I’m glad to see us moving forward with this and other issues.

Take care,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] SACM UC1 And Related Requirements

All:

Regards,

Adam

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

---

From: Gene Golovinsky <[email-masked]>
Date: Wed, 12 Dec 2012 09:13:02 -0800

Adam, I would agree that BYOD is a part of everyday life today as are SP
provided/supported assets.

The question that I will ask in this case is it really part of SP or
distinctly separate case.

I actually think it is a separate case.

So, I am in support of adding it, but not sure it is an addition to line #2
or a line #3 by itself.

Cheers.

--Gene

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Stephen
Hanna
*Sent:* Wednesday, December 12, 2012 09:03 AM
*To:* Adam Montville; [email-masked]
*Subject:* Re: [sacm] SACM UC1 And Related Requirements

Adam,

Thanks for putting together this initial list of requirements. This is a
good start. I do have some questions:

1)      Is BYOD in scope? I think it should be. It’s a fact of life in
enterprise networks today. If people agree, I would recommend changing your
second requirement to add this at the end: “or brought and owned by end
users”.

2)      Do we really need protocols for accessing a content repository for
UC1? Why?

Take care,

Steve

*From:* [email-masked]
[mailto:[email-masked]<[email-masked]>]
*On Behalf Of *Adam Montville
*Sent:* Tuesday, December 11, 2012 1:39 PM
*To:* [email-masked]
*Subject:* [sacm] SACM UC1 And Related Requirements

All:

After trolling through some of the SACM mailing list, and reviewing SACM
BoF minutes from IETF 85 and the current Use Case draft looking for
requirements, and here's what I've pulled together so far:

   - UC1 must provide coverage for enterprises of various sizes and include
   support for assets delivered by third-parties
   - Asset representation/identification should support those delivered by
   a given Service Provider (SP)
   - Supporting data formats and/or protocols should support assessment of
   SP-provided assets
   - Must provide a method of defining a target system (asset
   identification; asset classification)
   - Must provide a method of selecting acceptable state policy (test
   expression)
   - Must provide a method of retrieving data collection instructions
   (activity class: configuration, patch, vulnerability, inventory; object
   representation; state representation)
   - Must provide a method of expressing state collection values
   (collection language: technical, interrogative; object representation)
   - Must provide a method of comparing actual to expected state values
   (test evaluation; test expression)
   - Must provide a protocol for connecting to a content repository
   containing SACM content
   - Must provide a protocol for querying SACM content held in a content
   repository
   - Must provide a protocol of retrieving SACM content from a content
   repository
   - Must provide a protocol for curating SACM content in a content
   repository

In addition to the above, I would like to suggest that we take *certain
requirements* from CSIS 20 Critical Security Controls [1] under the
following controls:

   - Critical Control 1: Inventory of Authorized and Unauthorized Devices
   - Critical Control 2: Inventory of Authorized and Unauthorized Software
   - Critical Control 3: Secure Configuration for Hardware and Software on
   Mobile Devices, Laptops, Workstations, and Servers
   - Critical Control 4: Continuous Vulnerability Assessment and Remediation
   - Critical Control 5: Malware Defenses
   - Critical Control 10: Secure Configurations for Network Devices such as
   Firewalls, Routers, and Switches

I have *not yet* parsed through each of the Critical Controls, but
anticipate more detailed requirements to come out of them.  I emphasize
that we will not be seeking to meet every requirement expressed by a given
Critical Control.  For example, we may not be in a position to express
"authorizations" for software installed on an operating system in a given
context.  But, Critical Control 2 does require accurate and meaningful
asset identification (as does Critical Control 1, for that matter), which
is something with which we should be concerned.

I have this Friday (12/14) dedicated to fleshing out these requirements.
 If you have contributions to make, I respectfully request that you do so
before then.

Regards,

Adam

---

From: "Nunez, Luis K" <[email-masked]>
Date: Wed, 12 Dec 2012 17:14:26 +0000

There are two distinctive focus areas.  "Method" and "Protocol". To me the protocol for repository should be a separate but parallel effort.

-ln

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [sacm] SACM UC1 And Related Requirements

Adam,

Take care,

Steve

All:

Regards,

Adam

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

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 12 Dec 2012 17:24:31 +0000

> It seems to me that these are likely to be "light," but are needed.  How do we expect to get information from one place to the next without at least defining what an access API might look like, wha…

I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don't understand why we need a standard protocol for talking to a content repository for UC1.

Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the "data requestor") asks a second party (call it the "data collector") to gather data ("state values") relating to the security of a third party (the "target system"). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say "Send me the list of software installed on device 374629" and the data collector might respond with a list of installed software.

With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don't see any need for content repository protocols in this model.

Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don't think we'll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case.

Thanks,

Steve

From: Adam Montville [mailto:[email-masked]]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: SACM UC1 And Related Requirements

Adam,

Take care,

Steve

All:

Regards,

Adam

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 12 Dec 2012 12:29:30 -0500

Between SP-provided assets, BYOD, and the assets owned by the 
enterprise, is that likely to completely cover the scope of 
responsibility of the entity doing the security audit?

More complete, I think, to make #2 a more general statement such as 
"...all other assets within the scope of responsibility, such as those 
provided by a Service Provider (SP) or those brought and owned by end 
users."

As a note, the responsibility for performing the security assessment (or 
monitoring) of these devices may not be the responsibility of the 
enterprise, but it may still be responsible for tracking the assessment 
results, making it a case of being able to communicate the results of 
the security audit.

--gun

On 12/12/2012 12:13 PM, Gene Golovinsky wrote:
> So, I am in support of adding it, but not sure it is an addition to line
> #2 or a line #3 by itself.
>
> Cheers.
>
> --Gene
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf
> Of *Stephen Hanna
> *To:* Adam Montville; [email-masked] <mailto:[email-masked]>
> 1)Is BYOD in scope? I think it should be. It’s a fact of life in
> enterprise networks today. If people agree, I would recommend changing
> your second requirement to add this at the end: “or brought and owned by
> end users”.
>
> 2)Do we really need protocols for accessing a content repository for
> UC1? Why?
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Adam Montville
> *To:* [email-masked] <mailto:[email-masked]>
>   * UC1 must provide coverage for enterprises of various sizes and
>     include support for assets delivered by third-parties
>   * Must provide a method of retrieving data collection instructions
>     (activity class: configuration, patch, vulnerability, inventory;
>     object representation; state representation)
>   * Must provide a method of expressing state collection values
> In addition to the above, I would like to suggest that we take /_certain
> requirements_/ from CSIS 20 Critical Security Controls [1] under the
> following controls:
>
>   * Critical Control 3: Secure Configuration for Hardware and Software
>     on Mobile Devices, Laptops, Workstations, and Servers
> I have /_not yet_/ parsed through each of the Critical Controls, but
> that we will not be seeking to meet every requirement expressed by a
> given Critical Control.  For example, we may not be in a position to
> express "authorizations" for software installed on an operating system
> in a given context.  But, Critical Control 2 does require accurate and
> meaningful asset identification (as does Critical Control 1, for that
> matter), which is something with which we should be concerned.
>
>   If you have contributions to make, I respectfully request that you do
> so before then.
>
> Regards,
>
> Adam
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 12 Dec 2012 12:38:59 -0500

On 12/12/2012 12:09 PM, Adam Montville wrote:
>> your second requirement to add this at the end: “or brought and owned
>> by end users”.
>>
>
> This change seems reasonable to me.  We can ensure we address the issue,
> and then leave it to organizations using implementations of the
> standards/guidelines we produce as to how they want to apply the technology.
>
>

Strictly speaking, no, this isn't needed if you are just looking at the 
minimal subset for doing the security assessments.

In a practical sense, however, when it comes to implementing the 
resultant standards, access to the content in some manner will be 
necessary.  If that access is not defined the result will be proprietary 
solutions that must be later replaced as the scope of SACM grows.

I'm not saying that's either good or bad, just the tradeoff.

>
> It seems to me that these are likely to be "light," but are needed.  How
> do we expect to get information from one place to the next without at
> least defining what an access API might look like, what supported
> transport protocols exist for the given technology, and what identifiers
> to use, etc.
> I don't think we need anything heavy, just enough to say: If you want to
> get assessment content, find the content repository, and form your
> request like this, and you'll get your response.
> Notionally, it's easy for me to see a service-oriented interface using a
> REST API to get this type of thing done, but that's getting the cart
> before the horse, I think.
>
>> [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf
>> Of*Adam Montville
>> *Sent:*Tuesday, December 11, 2012 1:39 PM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[sacm] SACM UC1 And Related Requirements
>> All:
>> After trolling through some of the SACM mailing list, and reviewing
>> SACM BoF minutes from IETF 85 and the current Use Case draft looking
>> for requirements, and here's what I've pulled together so far:
>>
>> In addition to the above, I would like to suggest that we
>> take/_certain requirements_/from CSIS 20 Critical Security Controls
>> [1] under the following controls:
>>
>> I have/_not yet_/parsed through each of the Critical Controls, but
>> anticipate more detailed requirements to come out of them.  I
>> emphasize that we will not be seeking to meet every requirement
>> expressed by a given Critical Control.  For example, we may not be in
>> a position to express "authorizations" for software installed on an
>> operating system in a given context.  But, Critical Control 2 does
>> require accurate and meaningful asset identification (as does Critical
>> Control 1, for that matter), which is something with which we should
>> be concerned.
>> I have this Friday (12/14) dedicated to fleshing out these
>> requirements.  If you have contributions to make, I respectfully
>> request that you do so before then.
>> Regards,
>> Adam
> *
> 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/>
>
>
>
>
>
>

---

From: "Chandrashekhar B" <[email-masked]>
Date: Thu, 13 Dec 2012 12:02:17 +0530

>> It seems to me that these are likely to be "light," but are needed.  How
do we expect to get information from one place to the next without at least
defining what an access API might look like, what supported transport
protocols exist for the given technology, and what identifiers to use, etc.

> I understand why we want to have a standard protocol for conveying the
target system identification and data collection instructions to the data
collector and for getting back the state values. I just don't understand why
we need a standard protocol for talking to a content repository for UC1.

>Maybe we have a different idea of how UC1 works. I think UC1 is saying that
one party (call it the "data requestor") asks a second party (call it the
"data collector") to gather data ("state values") relating to the security
of a third party (the "target system"). So we need standard protocols and
data formats that the data requestor can use when talking to the data
collector. To give a concrete example, the data requestor might say "Send me
the list of software installed on device 374629" and the data collector
might respond with a list of installed software.

>With that model, the question of how the data collector gathers data about
the target system (through the NEA protocols or via WMI or SSH) is not our
problem. And how the data requestor determines the list of state values to
request is not our problem. Arguably, even the nature of the policies used
by the data requestor to determine whether it likes the state values may not
be our problem. But I certainly don't see any need for content repository
protocols in this model.

>Do you have a different model for UC1? I realize that this is straying into
architecture somewhat but I don't think we'll be able to come up with a set
of requirements unless we have a common model for what the actors in the
system are and how they interact to achieve the goals of the use case.

Data collector needs to have the assessment content for performing the task
the data requestor asked for. This is 4.1.4 from use case document. 

Chandra.

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <[email-masked]> wrote:

Adam,

1)      Is BYOD in scope? I think it should be. It's a fact of life in
enterprise networks today. If people agree, I would recommend changing your
second requirement to add this at the end: "or brought and owned by end
users".

This change seems reasonable to me.  We can ensure we address the issue, and
then leave it to organizations using implementations of the
standards/guidelines we produce as to how they want to apply the technology.

It seems to me that these are likely to be "light," but are needed.  How do
we expect to get information from one place to the next without at least
defining what an access API might look like, what supported transport
protocols exist for the given technology, and what identifiers to use, etc. 

I don't think we need anything heavy, just enough to say: If you want to get
assessment content, find the content repository, and form your request like
this, and you'll get your response.

Notionally, it's easy for me to see a service-oriented interface using a
REST API to get this type of thing done, but that's getting the cart before
the horse, I think.

Take care,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: [email-masked]
Subject: [sacm] SACM UC1 And Related Requirements

All:

After trolling through some of the SACM mailing list, and reviewing SACM BoF
minutes from IETF 85 and the current Use Case draft looking for
requirements, and here's what I've pulled together so far: 

*	UC1 must provide coverage for enterprises of various sizes and
include support for assets delivered by third-parties
*	Asset representation/identification should support those delivered
by a given Service Provider (SP)
*	Supporting data formats and/or protocols should support assessment
of SP-provided assets
*	Must provide a method of defining a target system (asset
identification; asset classification)
*	Must provide a method of selecting acceptable state policy (test
expression)
*	Must provide a method of retrieving data collection instructions
(activity class: configuration, patch, vulnerability, inventory; object
representation; state representation)
*	Must provide a method of expressing state collection values
(collection language: technical, interrogative; object representation)
*	Must provide a method of comparing actual to expected state values
(test evaluation; test expression)
*	Must provide a protocol for connecting to a content repository
containing SACM content
*	Must provide a protocol for querying SACM content held in a content
repository
*	Must provide a protocol of retrieving SACM content from a content
repository
*	Must provide a protocol for curating SACM content in a content
repository

In addition to the above, I would like to suggest that we take certain
requirements from CSIS 20 Critical Security Controls [1] under the following
controls:

*	Critical Control 1: Inventory of Authorized and Unauthorized Devices
*	Critical Control 2: Inventory of Authorized and Unauthorized
Software
*	Critical Control 3: Secure Configuration for Hardware and Software
on Mobile Devices, Laptops, Workstations, and Servers
*	Critical Control 4: Continuous Vulnerability Assessment and
Remediation
*	Critical Control 5: Malware Defenses
*	Critical Control 10: Secure Configurations for Network Devices such
as Firewalls, Routers, and Switches

I have not yet parsed through each of the Critical Controls, but anticipate
more detailed requirements to come out of them.  I emphasize that we will
not be seeking to meet every requirement expressed by a given Critical
Control.  For example, we may not be in a position to express
"authorizations" for software installed on an operating system in a given
context.  But, Critical Control 2 does require accurate and meaningful asset
identification (as does Critical Control 1, for that matter), which is
something with which we should be concerned.

I have this Friday (12/14) dedicated to fleshing out these requirements.  If
you have contributions to make, I respectfully request that you do so before
then.

Regards,

Adam

[1]  <http://www.sans.org/critical-security-controls/>
http://www.sans.org/critical-security-controls/

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

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

---

From: "Chandrashekhar B" <[email-masked]>
Date: Thu, 13 Dec 2012 19:17:46 +0530

UC1? Why?

>It seems to me that these are likely to be "light," but are needed.  How do
we expect to get information from >one place to the next without at least
defining what an access API might look like, what supported transport
 
>I don't think we need anything heavy, just enough to say: If you want to
get assessment content, find the content >repository, and form your request
like this, and you'll get your response.
 
>Notionally, it's easy for me to see a service-oriented interface using a
REST API to get this type of thing done, >but that's getting the cart before
the horse, I think.

Yes, we see the same too, interface for SCAP Repo is REST based:
https://www.scaprepo.com/SCAPRepoWebService 

Chandra.

 
All:

• UC1 must provide coverage for enterprises of various sizes and include
support for assets delivered by third-parties
• Asset representation/identification should support those delivered by a
given Service Provider (SP)
• Supporting data formats and/or protocols should support assessment of
SP-provided assets
• Must provide a method of defining a target system (asset identification;
asset classification)
• Must provide a method of selecting acceptable state policy (test
expression)
• Must provide a method of retrieving data collection instructions (activity
class: configuration, patch, vulnerability, inventory; object
representation; state representation)
• Must provide a method of expressing state collection values (collection
language: technical, interrogative; object representation)
• Must provide a method of comparing actual to expected state values (test
evaluation; test expression)
• Must provide a protocol for connecting to a content repository containing
SACM content
• Must provide a protocol for querying SACM content held in a content
repository
• Must provide a protocol of retrieving SACM content from a content
repository
• Must provide a protocol for curating SACM content in a content repository

• Critical Control 1: Inventory of Authorized and Unauthorized Devices
• Critical Control 2: Inventory of Authorized and Unauthorized Software
• Critical Control 3: Secure Configuration for Hardware and Software on
Mobile Devices, Laptops, Workstations, and Servers
• Critical Control 4: Continuous Vulnerability Assessment and Remediation
• Critical Control 5: Malware Defenses
• Critical Control 10: Secure Configurations for Network Devices such as
Firewalls, Routers, and Switches

 
Regards,
 
Adam

www.tripwire.com

________________________________________
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 13 Dec 2012 13:50:52 +0000

> the data requestor asked for. This is 4.1.4 from use case document.

Perhaps. If the communications between the data requestor and the data collector included all the necessary content, this interaction could take place without needing a separate content repository. Maybe this would not be efficient so it's desirable to use references to content instead of sending the content itself. Is this true?

Thanks,

Steve

From: Chandrashekhar B [mailto:[email-masked]]
Sent: Thursday, December 13, 2012 1:32 AM
To: Stephen Hanna; 'Adam Montville'
Cc: [email-masked]
Subject: RE: [sacm] SACM UC1 And Related Requirements

>Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don't think we'll be able to come up with a set of requirements unless we have a common model…

Data collector needs to have the assessment content for performing the task the data requestor asked for. This is 4.1.4 from use case document.

Chandra.

From: Adam Montville [mailto:[email-masked]]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: SACM UC1 And Related Requirements

Adam,

Take care,

Steve

All:

Regards,

Adam

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

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

---

From: "Chandrashekhar B" <[email-masked]>
Date: Thu, 13 Dec 2012 20:16:58 +0530

>Perhaps. If the communications between the data requestor and the data
collector included all the necessary >content, this interaction could take
place without needing a separate content repository. Maybe this would not
>be efficient so it's desirable to use references to content instead of
sending the content itself. Is this true? 

That could be another scenario. In which case, data requestor is behaving
like a content repository with a push model. But, it is desirable in my view
to use references so data collector could pull the content or data collector
knows how to get the content based on the instructions given by the
requestor.

Chandra.

Chandra.

 

Adam,

 

 

Take care,

Steve

All:

 

Regards,

Adam

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

 

  _____  

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 13 Dec 2012 15:04:59 +0000

Chandra wrote:
> it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor.

Chandra,

As I recall, you are the founder of a company (SecPod) that develops and provides SCAP content on a subscription basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol for accessing it. With all due respect and appreciation for your work (which I think is of the highest quality), you may have a personal bias toward standardizing a content repository protocol. Could you offer a compelling technical rationale for doing so at this time and as a part of UC1? I'd also like to hear from other SACM participants on this topic.

Thanks,

Steve

From: Chandrashekhar B [mailto:[email-masked]]
Sent: Thursday, December 13, 2012 9:47 AM
To: Stephen Hanna; 'Adam Montville'
Cc: [email-masked]
Subject: RE: [sacm] SACM UC1 And Related Requirements

>Perhaps. If the communications between the data requestor and the data collector included all the necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficient so it's desirable to use references to content instead of sending the content itself. Is this true?

That could be another scenario. In which case, data requestor is behaving like a content repository with a push model. But, it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor.

Chandra.

Chandra.

Adam,

Take care,

Steve

All:

Regards,

Adam

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

---

From: Adam Montville <[email-masked]>
Date: Thu, 13 Dec 2012 15:33:07 +0000

On Dec 13, 2012, at 7:04 AM, Stephen Hanna <[email-masked]<mailto:[email-masked]>> wrote:

Chandra,

As I recall, you are the founder of a company (SecPod) that develops and provides SCAP content on a subscription basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol for accessing it. With all due respect and appreciation for your work (which I think is of the highest quality), you may have a personal bias toward standardizing a content repository protocol. Could you offer a compelling technical rationale for doing so at this time and as a part of UC1? I’d also like to hear from other SACM participants on this topic.

Let's look at this from the end goal.  Imagine that we're "done" with Use Case 1.  A set of standards that allow us to: 1) define the target system, 2) select acceptable state policy, 3) retrieve data collection instructions, 4) collect actual state values, and 5) compare actual state values.

There are two ways we can deal with the selection and retrieval of policy and collection instructions (steps 2 and 3, respectively).  We can leave it up to specific implementations to figure it out on their own and end up with proprietary solutions, or, as presented in Atlanta, we can specify the method(s) by which implementations can connect to and interact with the storage of that information.

I ask myself this question: How useful is it to define a content-driven assessment method without providing the accompanying method of transmitting that content?  To me, it's not a benefit to the community at all without addressing the basic requirement of getting the content from one place to another.  The goal here is automation, and without that, we're keeping one of the worst manual processes around.

While this may not be a "technical" reason for keeping the content repository in scope, I really can't imagine a truly useful set of standards without one.  If there's one thing I think we've learned in the security automation community so far, it's that you can spec schema all day long, but if you don't have a good way to interoperate in an automated way with other tools and/or external entities, you're treading water.

So, I'm a strong advocate for explicitly recognizing the need for defining the method by which implementations should expect to connect to a content repository, and, therefore, for keeping that squarely in scope for UC1.

Thanks,

Steve

From: Chandrashekhar B [mailto:[email-masked]<http://secpod.com>]

>Perhaps. If the communications between the data requestor and the data collector included all the necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficient so it’s desirable to use references to content instead of sending the content itself. Is this true?

Chandra.

> I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don’t understand why we need a standard protocol for talking to a content repository for UC1.

>Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the “data requestor”) asks a second party (call it the “data collector”) to gather data (“state values”) relating to the security of a third party (the “target system”). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on device 374629” and the data collector might respond with a list of installed software.

>With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don’t see any need for content repository protocols in this model.

>Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case.

Chandra.

Adam,

Take care,

Steve

All:

Regards,

Adam

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

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

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

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 13 Dec 2012 10:58:02 -0500

Adam,

+1.  Your point is well stated IMHO.

Content management has been a significant barrier to useful adoption of security automation approaches to date.  I reviewed the TCG's IF-M for SCAP during the development of that document and raised these issues.  At the time we decided to keep content management out-of-band for the document, relying on proprietary methods to insure the delivery of content.  My concerns were around the potential mismatch between what content is expected to be on the access requestor and what content is being used to satisfy a health check. If the content is handled out-of-band, this may be a more regular occurrence and is certainly a challenge to contend with in multi-vendor interoperability scenarios.  This all works better if the content is managed properly and if both the access requestor and the policy evaluator have the same content.  Of course there are still some circumstances where it is impossible to deploy the latest content (e.g. long-term disconnection from the network), but this is a secondary issue.

The best way to ensure that content is managed properly is to keep it in scope as part of the orchestration process for collection.  To support this, we probably need to support a mechanism that allows content to be pulled by reference.  We may also need a method to "package" the content along with instructions that are exchanged over the control channel allowing a "push".  The latter would enable tightly managed clients.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, December 13, 2012 10:33 AM
To: Stephen Hanna
Cc: [email-masked]; [email-masked]
Subject: Re: [sacm] SACM UC1 And Related Requirements

Chandra,

Thanks,

Steve

Chandra.

Chandra.

Adam,

Take care,

Steve

All:

Regards,

Adam

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

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

---

From: David Solin <[email-masked]>
Date: Thu, 13 Dec 2012 09:59:40 -0600

I have an opinion, but no commercial OVAL repository I'm selling...

I do think it makes sense to introduce a standard protocol (or set of 
protocols) for interacting with a repository.  We are already covering 
the format of the content, which is the biggest problem, so why not go 
the last mile and also specify a delivery protocol?

If we do specify a protocol, it will be very easy for anyone to stand up 
their own content server that will plug-in with existing tools, to the 
immediate benefit of the entire community.  For instance, if Juniper 
decided in the future to author its own SCAP content for its products, 
it could stand up a server that implements the specification and every 
user of every compliant product would immediately be able to take 
advantage of that.

Now, having said that, I think that the protocol can be quite minimal in 
its design... but there's no need to design it unless we decide we need 
to have one, so I'll stop there!

Regards,
--David

On 12/13/2012 9:04 AM, Stephen Hanna wrote:
>
> Chandra wrote:
>
> > it is desirable in my view to use references so data collector could 
> pull the content or data collector knows how to get the content based 
> on the instructions given by the requestor.
>
> Chandra,
>
> As I recall, you are the founder of a company (SecPod) that develops 
> and provides SCAP content on a subscription basis. SecPod was the 
> first company to create an SCAP Content Repository and to provide a 
> standard protocol for accessing it. With all due respect and 
> appreciation for your work (which I think is of the highest quality), 
> you may have a personal bias toward standardizing a content repository 
> protocol. Could you offer a compelling technical rationale for doing 
> so at this time and as a part of UC1? I'd also like to hear from other 
> SACM participants on this topic.
>
> Thanks,
>
>
> Steve
>
> *From:*Chandrashekhar B [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 9:47 AM
> *To:* Stephen Hanna; 'Adam Montville'
> *Cc:* [email-masked]
> *Subject:* RE: [sacm] SACM UC1 And Related Requirements
>
> >Chandra wrote:
>
> collector included all the necessary >content, this interaction could 
> take place without needing a separate content repository. Maybe this 
> would not >be efficient so it's desirable to use references to content 
> instead of sending the content itself. Is this true?
>
> That could be another scenario. In which case, data requestor is 
> behaving like a content repository with a push model. But, it is 
> desirable in my view to use references so data collector could pull 
> the content or data collector knows how to get the content based on 
> the instructions given by the requestor.
>
> Chandra.
>
> *From:*Chandrashekhar B [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 1:32 AM
> *To:* Stephen Hanna; 'Adam Montville'
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [sacm] SACM UC1 And Related Requirements
>
> >Adam Montville wrote:
>
> >> It seems to me that these are likely to be "light," but are needed.  
> How do we expect to get information from one place to the next without 
> at least defining what an access API might look like, what supported 
> transport protocols exist for the given technology, and what 
> identifiers to use, etc.
>
> > I understand why we want to have a standard protocol for conveying 
> the target system identification and data collection instructions to 
> the data collector and for getting back the state values. I just don't 
> understand why we need a standard protocol for talking to a content 
> repository for UC1.
>
> one party (call it the "data requestor") asks a second party (call it 
> the "data collector") to gather data ("state values") relating to the 
> security of a third party (the "target system"). So we need standard 
> protocols and data formats that the data requestor can use when 
> talking to the data collector. To give a concrete example, the data 
> requestor might say "Send me the list of software installed on device 
> 374629" and the data collector might respond with a list of installed 
> software.
>
> the target system (through the NEA protocols or via WMI or SSH) is not 
> our problem. And how the data requestor determines the list of state 
> values to request is not our problem. Arguably, even the nature of the 
> policies used by the data requestor to determine whether it likes the 
> state values may not be our problem. But I certainly don't see any 
> need for content repository protocols in this model.
>
> >Do you have a different model for UC1? I realize that this is straying 
> into architecture somewhat but I don't think we'll be able to come up 
> with a set of requirements unless we have a common model for what the 
> actors in the system are and how they interact to achieve the goals of 
> the use case.
>
> Data collector needs to have the assessment content for performing the 
> task the data requestor asked for. This is 4.1.4 from use case document.
>
> Chandra.
>
> *From:*Adam Montville [mailto:[email-masked]]
> *Sent:* Wednesday, December 12, 2012 12:09 PM
> *To:* Stephen Hanna
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: SACM UC1 And Related Requirements
>
> 1)Is BYOD in scope? I think it should be. It's a fact of life in 
> your second requirement to add this at the end: "or brought and owned 
> by end users".
>
> This change seems reasonable to me.  We can ensure we address the 
> issue, and then leave it to organizations using implementations of the 
> It seems to me that these are likely to be "light," but are needed. 
>  How do we expect to get information from one place to the next 
> without at least defining what an access API might look like, what 
> supported transport protocols exist for the given technology, and what 
> identifiers to use, etc.
>
> I don't think we need anything heavy, just enough to say: If you want 
> to get assessment content, find the content repository, and form your 
> Notionally, it's easy for me to see a service-oriented interface using 
> a REST API to get this type of thing done, but that's getting the cart 
> ------------------------------------------------------------------------
>
> Checked by AVG - www.avg.com <http://www.avg.com>
> ------------------------------------------------------------------------
>
> Checked by AVG - www.avg.com <http://www.avg.com>

---

From: David Solin <[email-masked]>
Date: Thu, 13 Dec 2012 10:07:26 -0600

+1 Adam -- and I think utility does qualify as a "technical" reason.

I would add that (as someone without a repository to sell) I do think it 
makes sense to introduce a standard protocol (or set of protocols) for 
interacting with a repository.  We are already covering the format of 
the content, which is the biggest problem, so why not go the last mile 
and also specify a delivery protocol?

On the other hand, "content management" (which Dave brought up), is 
perhaps a different matter from mere transmission, and could 
substantially increase the complexity of the protocol we need to 
specify.  All we need, in my opinion, is a way to enumerate and download 
content from a repository, and probably also, to identify a delta that 
is needed to update from a previous repository snapshot.

Regards,
--David

On 12/13/2012 9:58 AM, Waltermire, David A. wrote:
> Content management has been a significant barrier to useful adoption 
> of security automation approaches to date.  I reviewed the TCG's IF-M 
> for SCAP during the development of that document and raised these 
> issues.  At the time we decided to keep content management out-of-band 
> for the document, relying on proprietary methods to insure the 
> delivery of content.  My concerns were around the potential mismatch 
> between what content is expected to be on the access requestor and 
> what content is being used to satisfy a health check. If the content 
> is handled out-of-band, this may be a more regular occurrence and is 
> certainly a challenge to contend with in multi-vendor interoperability 
> scenarios.  This all works better if the content is managed properly 
> and if both the access requestor and the policy evaluator have the 
> same content.  Of course there are still some circumstances where it 
> is impossible to deploy the latest content (e.g. long-term 
> disconnection from the network), but this is a secondary issue.
>
> The best way to ensure that content is managed properly is to keep it 
> in scope as part of the orchestration process for collection.  To 
> support this, we probably need to support a mechanism that allows 
> content to be pulled by reference.  We may also need a method to 
> "package" the content along with instructions that are exchanged over 
> the control channel allowing a "push".  The latter would enable 
> tightly managed clients.
>
> Sincerely,
>
> Dave
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Adam Montville
> *Sent:* Thursday, December 13, 2012 10:33 AM
> *To:* Stephen Hanna
> *Cc:* [email-masked]; [email-masked]
> Let's look at this from the end goal.  Imagine that we're "done" with 
> Use Case 1.  A set of standards that allow us to: 1) define the target 
> system, 2) select acceptable state policy, 3) retrieve data collection 
> instructions, 4) collect actual state values, and 5) compare actual 
> state values.
>
> There are two ways we can deal with the selection and retrieval of 
> policy and collection instructions (steps 2 and 3, respectively).  We 
> can leave it up to specific implementations to figure it out on their 
> own and end up with proprietary solutions, or, as presented in 
> Atlanta, we can specify the method(s) by which implementations can 
> connect to and interact with the storage of that information.
>
> I ask myself this question: How useful is it to define a 
> content-driven assessment method without providing the accompanying 
> method of transmitting that content?  To me, it's not a benefit to the 
> community at all without addressing the basic requirement of getting 
> the content from one place to another.  The goal here is automation, 
> and without that, we're keeping one of the worst manual processes around.
>
> While this may not be a "technical" reason for keeping the content 
> repository in scope, I really can't imagine a truly useful set of 
> standards without one.  If there's one thing I think we've learned in 
> the security automation community so far, it's that you can spec 
> schema all day long, but if you don't have a good way to interoperate 
> in an automated way with other tools and/or external entities, you're 
> treading water.
>
> So, I'm a strong advocate for explicitly recognizing the need for 
> defining the method by which implementations should expect to connect 
> to a content repository, and, therefore, for keeping that squarely in 
> scope for UC1.
>
>
>
> Thanks,
>
>
> Steve
>
> *From:*Chandrashekhar B [mailto:[email-masked] <http://secpod.com>]
> *Sent:*Thursday, December 13, 2012 9:47 AM
> *To:*Stephen Hanna; 'Adam Montville'
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*RE: [sacm] SACM UC1 And Related Requirements
>
> >Chandra wrote:
>
> *Sent:*Thursday, December 13, 2012 1:32 AM
> *To:*Stephen Hanna; 'Adam Montville'
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*RE: [sacm] SACM UC1 And Related Requirements
>
> >Adam Montville wrote:
>
> *Sent:*Wednesday, December 12, 2012 12:09 PM
> *To:*Stephen Hanna
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: SACM UC1 And Related Requirements
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked] 
> <mailto:[email-masked]>]*On Behalf Of*Adam Montville
> Checked by AVG -www.avg.com <http://www.avg.com>
> Checked by AVG -www.avg.com <http://www.avg.com>
> [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: <[email-masked]>
Date: Thu, 13 Dec 2012 16:14:54 +0000

Steve,

This is a core problem we as a community need to address very soon.  With SCAP and other content standardization efforts we are creating a situation where the content (checks, benchmarks, enumerated support information) is consumable by may different applications in multiple security technologies. Efforts like SCAP are validating if products and services process content the same way, producing the same results from the same content.  This is of benefit to the industry as it is creating a level playing field and a benefit to the customers of these products.  We are breaking down the proprietary walls that lock in information and economically tie an organization's hand to a specific vendor's product because the organization has invested so much to get a security technology fielded.  We are seeing that play out today.  While this is a great goal, there are headaches developing we have created with this approach.  That is what we hope to solve with a standardized repository interface to distributing standardized content…

So what it the problem we have/are making for ourselves…

With that standard content there is always a need to tweak, correct, update or replace the checks in the content for the local organizational needs.  Sites use that standard content format to implement their own security policy validation content that they wish to comply with and measure against.  They want to take advantage of the multiple security related products that use the standardized content so they have many different compliant products supporting various aspects of the security infrastructure.  When staff wants to make a change, they edit the content and then wish to push it out to the compliant products for use as their 'authoritative' content for evaluation.

Today, what we have seen is that each product has it's own means for distributing content.  Some use FTP, some use Sharepoint, some use web repositories, some have manual means and some have proprietary means. Operationally this has created a nightmare for the staff.  We now require the operations staff to go to each product's management facilities, insert the new checks, content, support information into that specific product's distribution mechanism and push it out.  The larger the network, the bigger the problem.  So what we have seen with SCAP is that while we have standardized content formats and consistent processing we are missing a critical piece needed to reduce the workload and increase the speed with which content updates are distributed.

A standard content repository interface to retrieve the content provides a solution to the problem we are creating. It also allows for additional capabilities to be associated, such as integrated content management (creation, edit, update) which the site could leverage.

And I have not even mentioned the need for industry organizations such as CIS to distribute their benchmarks and checks when changes are made, bugs are fixed, new platforms are supported.  I see the local issues as the most critical at this point but there are also additional capabilities needed down the road.

There is absolutely a need for this type of content repository / distribution. We have no standards around content distribution today and as the compliant products / technologies proliferate, the problem will get bigger and negatively impact the move towards standards. This is absolutely in scope for this working group.

Side note, Chandra has always been a proponent of this long before he set up his SCAP content feed service.  He is an supporter in this effort and I see nothing biased in anything he has done / stated to date.

Thanks.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 13, 2012 9:04 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] SACM UC1 And Related Requirements

Chandra,

Thanks,

Steve

Chandra.

Chandra.

Adam,

Take care,

Steve

All:

Regards,

Adam

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 13 Dec 2012 11:21:39 -0500

I have to agree with the arguments that Adam and Dave give, but I'm 
anxious to see what this boils down to as requirements are defined.

Right now it looks like there needs to be a great deal of interaction 
between the content repository, the policy evaluator, and the access 
requestor.  Noting the amount of data in current repositories and how 
quickly it grows, this approach is infeasible when talking about a 
single large repository such as Mitre/Secpod.  Even moving the 
repository within the silo of each enterprise can end up generating huge 
amounts of network traffic if it isn't done very carefully, especially 
when "continuous" is thrown into the mix.  Networks aren't built for the 
purpose of assessing networks, after all.  And some networks are 
completely disconnected from Internet access.

It sounds to me like there needs to be two types of repositories.  One 
that is as local to the point of usage as possible and another that is a 
root or definitive data source, such as is provided by vendors.

For the latter it's very much in line to seek input from commercial 
operators like Chandra to be sure that the needs of access control are 
addressed in a way that is sufficient and practical.

--gun

On 12/13/2012 10:58 AM, Waltermire, David A. wrote:
> Content management has been a significant barrier to useful adoption of
> security automation approaches to date.  I reviewed the TCG’s IF-M for
> SCAP during the development of that document and raised these issues.
> At the time we decided to keep content management out-of-band for the
> document, relying on proprietary methods to insure the delivery of
> content.  My concerns were around the potential mismatch between what
> content is expected to be on the access requestor and what content is
> being used to satisfy a health check. If the content is handled
> out-of-band, this may be a more regular occurrence and is certainly a
> challenge to contend with in multi-vendor interoperability scenarios.
> This all works better if the content is managed properly and if both the
> access requestor and the policy evaluator have the same content.  Of
> course there are still some circumstances where it is impossible to
> deploy the latest content (e.g. long-term disconnection from the
> network), but this is a secondary issue.
>
> The best way to ensure that content is managed properly is to keep it in
> scope as part of the orchestration process for collection.  To support
> this, we probably need to support a mechanism that allows content to be
> pulled by reference.  We may also need a method to “package” the content
> along with instructions that are exchanged over the control channel
> allowing a “push”.  The latter would enable tightly managed clients.
>
> Sincerely,
>
> Dave
>
> As I recall, you are the founder of a company (SecPod) that develops and
> provides SCAP content on a subscription basis. SecPod was the first
> company to create an SCAP Content Repository and to provide a standard
> protocol for accessing it. With all due respect and appreciation for
> your work (which I think is of the highest quality), you may have a
> personal bias toward standardizing a content repository protocol. Could
> you offer a compelling technical rationale for doing so at this time and
> as a part of UC1? I’d also like to hear from other SACM participants on
> this topic.
>
> own and end up with proprietary solutions, or, as presented in Atlanta,
> we can specify the method(s) by which implementations can connect to and
> interact with the storage of that information.
>
> I ask myself this question: How useful is it to define a content-driven
> assessment method without providing the accompanying method of
> transmitting that content?  To me, it's not a benefit to the community
> at all without addressing the basic requirement of getting the content
> from one place to another.  The goal here is automation, and without
> that, we're keeping one of the worst manual processes around.
>
> the security automation community so far, it's that you can spec schema
> all day long, but if you don't have a good way to interoperate in an
> automated way with other tools and/or external entities, you're treading
> water.
>
> defining the method by which implementations should expect to connect to
> a content repository, and, therefore, for keeping that squarely in scope
> for UC1.
>
>
>
> Thanks,
>
>
> Steve
>
> desirable in my view to use references so data collector could pull the
> content or data collector knows how to get the content based on the
> instructions given by the requestor.
>
> Chandra.
>
> In addition to the above, I would like to suggest that we take/_certain
> requirements_/from CSIS 20 Critical Security Controls [1] under the
> following controls:
>

---

From: David Solin <[email-masked]>
Date: Thu, 13 Dec 2012 10:23:34 -0600

+1

This is a well-stated point, and hopefully gets us all on the same 
page.  It's communication with the latter type of repository that I 
believe we're all interested in standardizing.

On 12/13/2012 10:21 AM, Gunnar Engelbach wrote:
> that is as local to the point of usage as possible and another that is 
> a root or definitive data source, such as is provided by vendors.
>

--

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 13 Dec 2012 16:36:25 +0000

I'm glad to see such a clear consensus on this topic and such an active discussion of it on the list.

David, Adam, and others have presented clear arguments (both technical and operational) for including a protocol for accessing a content repository in our work at this time. Certainly, I don't want us to create an incomplete solution that only works if additional proprietary protocols are used. And I can see that it's much more efficient to send references to content and have a separate protocol for fetching the actual content, given a reference.

David Solin raises a good question: do we need to specify a protocol for curating the content repository or is it enough to just have a protocol for retrieving content?

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Thursday, December 13, 2012 10:58 AM
To: Adam Montville; Stephen Hanna
Cc: [email-masked]; [email-masked]
Subject: Re: [sacm] SACM UC1 And Related Requirements

Adam,

Sincerely,
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, December 13, 2012 10:33 AM
To: Stephen Hanna
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM UC1 And Related Requirements

Chandra,

Thanks,

Steve

Chandra.

Chandra.

Adam,

Take care,

Steve

All:

Regards,

Adam

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

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

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 17:09:18 +0000

Let's walk before we run…  Where is the need the greatest?  From my perspective it is the operational side of an organization.  Changes are made quite often within an organization and excessive additional work, such as has having to make that same change in 9 different products on potentially many multiples of systems, seems like it will be most beneficial place to start.

Like to see your definition of curating a repository ;-) but the initial need is the retrieval of organizationally 'approved' content via a standard interface that products can incorporate for retrieval of updates, etc.

That said, it is easy to see how a protocol could be developed to not only solve the local distribution issues but the larger distribution of 'authoritative' content. By authoritative content, I mean content from policy guidance authors, such as primary source vendors, industry groups such as CIS, etc. If we are looking for initial scoping for the effort I would start with the critical local distribution means but look at the overall problem so we know where to go next.

Kent Landfield

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 13, 2012 10:36 AM
To: David Waltermire <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] SACM UC1 And Related Requirements

I’m glad to see such a clear consensus on this topic and such an active discussion of it on the list.

David, Adam, and others have presented clear arguments (both technical and operational) for including a protocol for accessing a content repository in our work at this time. Certainly, I don’t want us to create an incomplete solution that only works if additional proprietary protocols are used. And I can see that it’s much more efficient to send references to content and have a separate protocol for fetching the actual content, given a reference.

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Waltermire, David A.

Adam,

Content management has been a significant barrier to useful adoption of security automation approaches to date.  I reviewed the TCG’s IF-M for SCAP during the development of that document and raised these issues.  At the time we decided to keep content management out-of-band for the document, relying on proprietary methods to insure the delivery of content.  My concerns were around the potential mismatch between what content is expected to be on the access requestor and what content is being used to satisfy a health check. If the content is handled out-of-band, this may be a more regular occurrence and is certainly a challenge to contend with in multi-vendor interoperability scenarios.  This all works better if the content is managed properly and if both the access requestor and the policy evaluator have the same content.  Of course there are still some circumstances where it is impossible to deploy the latest content (e.g. long-term disconnection from the network), but this is a secondary issue.

The best way to ensure that content is managed properly is to keep it in scope as part of the orchestration process for collection.  To support this, we probably need to support a mechanism that allows content to be pulled by reference.  We may also need a method to “package” the content along with instructions that are exchanged over the control channel allowing a “push”.  The latter would enable tightly managed clients.

Sincerely,
Dave

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, December 13, 2012 10:33 AM
To: Stephen Hanna
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM UC1 And Related Requirements

Chandra,

Thanks,

Steve

Chandra.

Chandra.

Adam,

Take care,

Steve

All:

Regards,

Adam

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Dec 2012 17:15:05 +0000

This seems to me a good starting set. I have a few questions - see in-line.

Thanks and Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 8:39 PM
To: [email-masked]
Subject: [sacm] SACM UC1 And Related Requirements

All:

[[DR]] Assuming that the difference between 'method' and 'protocol' in the above is intentional - why is a 'protocol' considered necessary for querying SACM content? Can't this be some kind of remote procedure that can be launched and results retrieved remotely by using the same 'protocol' used for retrieving SACM content? I also assume that we agree that we need nod invent a new protocol for each one of these requirements, but rather use or extend existing protocols?

[[DR]] The use of 'continuous' here scares me. What is the time granularity we assume for assessment in SACM?

  *   Critical Control 5: Malware Defenses
  *   Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
[[DR]] By 'secure configurations' we mean that the configurations are secured, or that the configurations operations are secured, or both, or ...?

Regards,

Adam

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 13 Dec 2012 12:17:21 -0500

Both are needed, really, but with the part inside the enterprise being 
the more critical.

The content has to originate somewhere, which would be the root (or 
"source" or whatever) repositories, and which could also include a local 
source used for custom content within a single enterprise.

And with multiple source repositories there's also the possibility of 
having more than one test for the same thing, so some sort of 
deconfliction becomes beneficial.

Within an enterprise there are potentially multiple entities that need 
to be working with the same data.  The collector and evaluatator, for 
example, with possible overlap in these functions from multiple 
products.  This part is potentially very interactive and can therefore 
generate a large amount of traffic.  At the same time, simply 
replicating the contents of the repository results in a huge amount of 
data transfer and storage for data that will be mostly unused if that 
local repository is *too* local (e.g.: on every asset).

There are also odd cases like historical data.  When viewing results 
from a test that was later revised or obsoleted it would be beneficial 
to view that in the context of how it was defined at that time and not 
how it is currently defined.

With that in mind, keeping things simple for now seems to be the goal. 
For the root repositories, simple replication via pull may be 
sufficient, and we'll just assume that commercial repositories will use 
their own methods to control the level of data that can be replicated 
based on the account used.  For local repositories, perhaps something 
functionally similar to IMAP.

And as long as we're on the repository topic:  a repository can 
potentially contain multiple content types.  Not just the security 
automation benchmarks, but the source documentation for those 
benchmarks, the regulatory statutes, how-to videos, and so on.

--gun

---

From: Gary Gapinski <[email-masked]>
Date: Thu, 13 Dec 2012 13:24:21 -0500

This is a good start. Thanks for
assembling it.

Comments and questions inline. RFC2119 assumed for MUST, etc.

On 12/11/2012 01:39 PM, Adam Montville wrote:

All:

After trolling through some of the SACM mailing list, and
reviewing SACM BoF minutes from IETF 85 and the current Use Case
draft looking for requirements, and here's what I've pulled
together so far:

UC1 must provide coverage for enterprises of various sizes
and include support for assets delivered by third-parties

US DoD is a good edge case. My domestic appliances are as well
(though I do not normally consider the domicile an "enterprise").
Shall these be the approximate bounds?

This appears to be two distinct requirements, best stated
distinctly.

Asset representation/identification should support those
delivered by a given Service Provider (SP)

I am uncertain what this means. Does this mean "those schemes of
asset representation and identification adopted by a SP", or "those
assets delivered by a service provider"? I suspect the latter.

The statement implies SACM will field or adopt one (or more than
one) asset representation/identification scheme. If this implication
is correct, the statement appears to levy the requirement "the SACM
asset representation/identification schemes SHOULD support
representation/identification of any assets delivered by any service
provider".

Shall asset representation/identification schemes apply to assets
not delivered by a service provider?

Supporting data formats and/or protocols should support
assessment of SP-provided assets

This seems only a restatement of the "everything SACM applies to
assets provided directly or indirectly by the enterprise"
requirement. And weakened to a SHOULD.

Must provide a method of defining a target system (asset
identification; asset classification)

Might this a MAY? No problem as long as the term "a method" does not
preclude "methods". I'm reasonably sure there are extant
identification and classification methods already suitable in some
circumstances.

Must provide a method of selecting acceptable state policy
(test expression)

This is essential. However, I'm certain a single method will not
suffice. No problem as long as the term "a method" does not preclude
"methods"

Must provide a method of retrieving data collection
instructions (activity class: configuration, patch,
vulnerability, inventory; object representation; state
representation)

Only one method?

I have this same misgiving repeatedly, as well as the "provide"
rather than "specify" distinction. The former implies "will create",
as opposed to "will create or select", augmented by "amongst extant
standards". Please apply this misgiving to other items.

Is this simply that the multiple types of inquiries must be capable
of being typified?

Must provide a method of expressing state collection
values (collection language: technical, interrogative;
object representation)

I am unsure what this means, particularly considering the following
requirement appears to suffice.

Must provide a method of comparing actual to expected
state values (test evaluation; test expression)

How does this differ from "Must provide a method of selecting
acceptable state policy (test expression)"? This also verges on
implementation.

Must provide a protocol for connecting to a content
repository containing SACM content

There are some extant protocols which appear quite serviceable, such
as HTTP.

Must provide a protocol for querying SACM content held in
a content repository

There are some extant protocols which appear quite serviceable, such
as HTTP.

Must provide a protocol of retrieving SACM content from a
content repository

There are some extant protocols which appear quite serviceable, such
as HTTP.

Must provide a protocol for curating SACM content in a
content repository

This will likely be difficult to adequately describe, as a
repository could be as simple as a version control repository such
as one maintained using git.

Would not such a (git) repository suffice for some types of use, as
well as the explicit ways in which one can perturb content therein?

Regards,

Gary

---

From: Gary Gapinski <[email-masked]>
Date: Thu, 13 Dec 2012 19:33:12 -0500

These are very good observations overall, and in particular

> deconfliction becomes beneficial.

identifies something that has thus far been potentially beneficial,
elusive, and alluring. And probably implies a lack only of the ability
to discern (as opposed to identify and stamp out) sameness.
"Enumerations" have been proposed, but these have yet to achieve
planetary dominance.

There will of course be any number of "repositories". There may as well
be any number of "repositories" which assert primacy, uniqueness,
singularity, etc., all to no avail. The best one can expect is for a
"repository", namely, a noted and trusted source of normative content,
to be useful enough to be commonly employed, and to employ useful
characteristic descriptions for concepts of interest.

Deconfliction implies removal of duplicative effort (or of conflict, if
there is indeed such a thing); establishing how norms are duplicative is
difficult, and I'm unsure if this should be an immediate SACM goal.
Certainly worth pursuing in the longer term; we as yet lack the ability
to describe goals in a normative way suitable for identifying
duplication, much less the goals.

In any case, the first task is to devise a means to describe desired
security posture; doing so in a way that allows identification of
duplicate statements is important but not essential.

---

From: David Solin <[email-masked]>
Date: Fri, 14 Dec 2012 08:55:46 -0600

I wholeheartedly agree!  And Gary's remark gives rise to the following:

IIRC, there was a proposal on the table to derive all OVAL IDs from 
repository URIs.  I think it needed a bit of work, but to prevent the 
worst kind of "duplication" -- which would be to find some definition 
masquerading as another because it borrowed an ID (identity theft!) -- 
this is the sort of concept we need to enforce.

That is to say, if we are to allow repositories to contain content, 
itself containing references to content whose source is another 
definitive repository (which we should), and if we are to admit the 
possibility that these repositories may also furnish third-party 
definitions (which we also should) then we must create a rule in the 
specification that states how one should determine which repository is 
the DEFINITIVE one for any given ID namespace.  Perhaps an illustration 
by example would be illuminating...

Let's say SecPod hosts a specification-conformant content repository, 
and inside it there is a definition they created that references a test 
that originates from MITRE's repository.  So the first definition is 
oval:com.secpod.oval:def:X, and the second is oval:org.mitre.oval:tst:Y.

It should be possible to get both from the SecPod repository -- because 
a repository should be capable of providing working (and therefore 
complete) content.  But if MITRE's own specification-conformant content 
repository provided an oval:org.mitre.oval:tst:Y that differed from that 
in SecPod's, we need a way to decide which is authoritative.  I would 
say, probably, MITRE's should be considered authoritative.  A warning of 
some kind should be generated.

This means that any repository containing content for which it is not 
authoritative, implements a contract whereby it promises to faithfully 
mirror copies of any replicated content from their authoritative source.

If we don't have such a rule, and we don't have a mechanism to reach an 
authoritative source for a definition/test/state/object/etc. given its 
ID, then all identities are only context-sensitive, and real 
interdependencies will necessarily require duplication, which is 
potentially undesirable.

Regards,
--David Solin

--

---

From: Adam Montville <[email-masked]>
Date: Fri, 14 Dec 2012 17:05:01 +0000

All:

This has turned into a really good discussion!  I'm pleased with that.  Here's an updated list based on the feedback heard so far.   I have taken Gary's feedback to heart and taken the liberty of rewording some statements and removing others.  Also, I think I've addressed some of the "protocol vs. remote procedure" issues by stating "protocol and/or interface," with the intent of implying that we needn't reinvent the wheel (i.e. where a secured HTTP connection might be good enough), but that we still need a standardized way of expressing what we want to do (i.e. the interface).  Finally, I altered the content repository curation requirement to MAY from MUST, and added a provenance requirement.

  *   UC1 must provide coverage for enterprises of various sizes
  *   UC1 must provide support for assets delivered by third-parties
  *   Asset representation/identification should support those delivered by a given Service Provider (SP)
     *   Alternative (?) wording: Asset representation/identification schemes should support representation/identification of any assets delivered by any service provider.
  *   Asset representation/identification must support those present in a given enterprise either directly or by extension
  *   May specify at least one method or methods of defining a target system (asset identification; asset classification) amongst extant standards
  *   Must specify at least one method of selecting acceptable state policy (test expression) amongst extant standards
  *   Must specify a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation) amongst extant standards
  *   Must specify a method of expressing state collection values (collection language: technical, interrogative; object representation) amongst extant standards
  *   Must specify a protocol and/or interface for connecting to a content repository containing SACM content amongst extant standards
  *   Must specify a protocol and/or interface for querying SACM content held in a content repository amongst extant standards
  *   Must specify a protocol and/or interface to retrieve SACM content from a content repository amongst extant standards
  *   May specify a protocol and/or interface for curating SACM content in a content repository amongst extant standards
  *   Content repository methods/protocols should specify an acceptable degree of provenance for externally obtained content amongst extant standards

To address some of the concerns expressed with respect to referencing the Critical Security Controls, I can say the following: We'll need to determine what's "right" as we progress.  That said, here are specific responses to questions that Dan Romascanu had:

  *   Critical Control 4 indicates that daily or weekly vulnerability scans are required, but does not rule out the option to scan more frequently.  Keep in mind that "continuous" is not the same as "continual," so the frequency of scans will be variable from organization to organization.  Therefore, time granularity should be considered, but not dictated, by the SACM efforts.
  *   Critical Control 10 is seeking the same secure configurations as per Critical Control 3, but applied to network devices.  Think of "secure configurations" as a noun rather than a verb - the configuration must configure the running state of a network device to reasonable security standards.

Finally, as a reminder, I haven't yet parsed through each of these Critical Security Controls, but I believe they represent an important perspective to the work we intend to accomplish in SACM.

If people are feeling good about this list - it doesn't have to be perfect - I can start putting this into a draft form.  I assume that this should be an informational document that stands on its own, or we can modify the use case document to contain this information.  I personally like the idea of a stand-alone document.  That said, I'll do what the community thinks is the right approach.

I'm looking forward to the community's response.

Regards,

Adam

---

From: Gary Gapinski <[email-masked]>
Date: Fri, 14 Dec 2012 15:05:53 -0500

Zounds! (Tarnation having already been achieved.)

I had hoped to erode the perceived necessity of stamping out duplication
as well as the all too frequent propensity to uniquely number all beasts
in the security automation realm.

On 12/14/2012 09:55 AM, David Solin wrote:
> …

Instead, to my abject horror, I find I have instead agitated the
townsfolk, who have taken up torches and weapons and are marching off to
storm the twin towers of Castle Duplex, after which they will fire up
the branding irons and start molesting cattle.

So, while they are thus engaged, and things are quiet here in town, let
me try again.

I don't think duplication is a problem. Lack of content is a problem.
Paucity of expression is a problem. Unnecessary complexity is a problem.
Well-meaning but doomed enumeration schemes are a problem.

Let's select a real world - singular - example and vivisect it.

For quite some time there has been a doctrine that passwords should have
an entropy equal to or greater than some value chosen in concert with
some other considerations. The coarse nature of current configuration
and evaluation methods often results in a simpler statement: passwords
shall have a minimal length enforced by the operating system. This is
something that can be specified in a policy, arranged in a system
configuration, and the system configuration can be inspected to
determine compliance with the policy.

The length of a password can be specified and evaluated in different
ways on different platforms. Are not such differences simply facets of
the single policy? I think they are. We still have one policy, with
varying expressions.

The specific length of the password will vary amongst parties who impose
such a policy. The nature of such variation will undoubtedly spur future
debate within the group. I think it profitable to consider such
variation separate from the essence of uniqueness.

The policy can be stated in different natural languages: again, one policy.

The expression of the policy in synthetic languages suitable for
security automation can vary. I do not think this increases the number
of policies.

Various consumers of such a policy might wish to say varying things
about it. One common thing is an identifier unique in some domain. This
adds facets but does not create more policies. It also creates the task
of concordance for the seekers of oneness.

The policy with its increasingly large number of facets introduced for
the pleasure of various consumers can undergo revision. This causes the
single policy to have time-dependent variants. An added dimension.

Provenance of a policy is of interest to some. I think this is just
another facet.

These are some of the easy considerations. Here's a few harder ones, by
no means the only ones.

A copy of the policy can be made, and such copying will be routine. This
does not create a new policy. It does introduce a conundrum for those
who abhor duplication, namely, the ability to assert that two copies of
a thing are the same thing, or they are not. They are until revision occurs.

The password length policy is only one of several policies that together
determine appropriate password entropy. How shall these be connected?

Unique identifiers for as large a number of individual security policies
as will be specified are pleasant to conjecture but in my opinion not
possible. IANA registry does not cut it here. Past efforts have been
compromised as well by attempts to use other than abstract identifiers.
Ultimately, we are talking about documents representing individual
policies and compilations thereof. I suspect the definition of
duplication is elusive, and may not be as important as thought. Assuming
it can be detected, would it not be sufficient to simply assert that two
instances are duplicates and move on?

It is likely that those who fear duplication are already in despair that
not all manipulators of content will abide by a planetary injunction to
conform to a single identification scheme. H. L. Mencken's definition of
Puritanism comes to mind.

Are compilations unique?

Are revisions unique?

What about revisions to things that had previously been arbitrarily
compiled?

Arbitrary compilations of security automation content are anticipated in
the requirements. Content begets collection. Any uniqueness must be
preserved, and fans out with abandon.

I'll pause here. While it is impossible to anticipate all manner of
statements that might be made regarding security automation content, I
would hope that the standards evolve in ways that allow, rather than
prohibit, the as yet unanticipated statements.

--
Those are my principles, and if you don't like them... well, I have others.
- Julius "Groucho" Marx

---

From: David Solin <[email-masked]>
Date: Fri, 14 Dec 2012 14:54:59 -0600

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

While that eliminates the theoretical problem, it also creates practical 
ones.  But I'll leave my pitchfork in the barn and let others comment, 
as there is a certain elegance to the idea.

--

---

From: Gary Gapinski <[email-masked]>
Date: Fri, 14 Dec 2012 16:48:48 -0500

> Your position, then, Gary, is that there should be no such thing as an

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.