Subject: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

From: [email-masked]
Date: Tue, 24 Mar 2015 08:38:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Security Automation and Continuous Monitoring Working Group of the IETF.

        Title           : Endpoint Security Posture Assessment - Enterprise Use Cases
        Authors         : David Waltermire
                          David Harrington
	Filename        : draft-ietf-sacm-use-cases-09.txt
	Pages           : 29
	Date            : 2015-03-24

Abstract:
   This memo documents a sampling of use cases for securely aggregating
   configuration and operational data and evaluating that data to
   determine an organization's security posture.  From these operational
   use cases, we can derive common functional capabilities and
   requirements to guide development of vendor-neutral, interoperable
   standards for aggregating and evaluating data relevant to security
   posture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sacm-use-cases-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Tue, 24 Mar 2015 20:26:52 +0000

I reviewed the document and have a concern that it needs to specifically address the ability to provide persistent identification of devices over time and correlation of device identities between sensors.  Has this issue already been addressed?

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 24, 2015 11:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

Abstract:

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

---

From: Chris Inacio <[email-masked]>
Date: Thu, 26 Mar 2015 15:31:30 +0000

We are actively working on that issue.  The endpoint identity sub team meets weekly to work on solving this issue.

--
Chris Inacio
[email-masked]

> On Mar 24, 2015, at 3:26 PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]> wrote:
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Mar 2015 15:35:10 +0000

... and everybody who is interested and believes he/she can help is welcome to join this effort. 

Thanks and Regards,

Dan

> From: sacm [mailto:[email-masked]] On Behalf Of Chris Inacio
> Sent: Thursday, March 26, 2015 5:32 PM
> To: Wolfkiel, Joseph L CIV DISA ID (US)
> Cc: [email-masked]
> Subject: Re: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt
> 
> 
> > I reviewed the document and have a concern that it needs to specifically
> address the ability to provide persistent identification of devices over time
> and correlation of device identities between sensors.  Has this issue already
> been addressed?
> >
> > Joseph L. Wolfkiel
> > SCM Engineering Lead
> > DISA ID52
> > (301) 225-8820
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> > org_doc_draft-2Dietf-2Dsacm-2Duse-
> 2Dcases_&d=AwICAg&c=BFpWQw8bsuKpl1Sg
> > iZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=NCVTg-
> tLUOwFk_T
> >
> HQ3uGcdcnfZPdeMWiHcYgNVfiKQg&s=aD7XII9TdJlYt0m9R_66MeIDEnD_bK_
> qWRYnVMM
> > Zr78&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_htm
> > l_draft-2Dietf-2Dsacm-2Duse-2Dcases-
> 2D09&d=AwICAg&c=BFpWQw8bsuKpl1SgiZ
> > H64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=NCVTg-
> tLUOwFk_THQ
> > 3uGcdcnfZPdeMWiHcYgNVfiKQg&s=DkKIiMcYM-
> zo8bWd6PYmV6GYhxAsBdLmG00AdKhi_
> > lo&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ietf.org_rfcdi
> > ff-3Furl2-3Ddraft-2Dietf-2Dsacm-2Duse-2Dcases-
> 2D09&d=AwICAg&c=BFpWQw8b
> >
> suKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=N
> CVTg-t
> >
> LUOwFk_THQ3uGcdcnfZPdeMWiHcYgNVfiKQg&s=EqzdIs1Ij4GhgFU6CVIRIrR
> RVrvKBAO
> > zQtitqXMMt90&e=
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern
> > et-
> 2Ddrafts_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJf
> Qzvls
> > iLQfucBXRucPvdrphpBsFA&m=NCVTg-
> tLUOwFk_THQ3uGcdcnfZPdeMWiHcYgNVfiKQg&s
> > =vFj6SPDmfjV1R_1AoqzSeqlHb8V3elCw9HCSN9ojzzo&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> >
> man_listinfo_sacm&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJf
> > QzvlsiLQfucBXRucPvdrphpBsFA&m=NCVTg-
> tLUOwFk_THQ3uGcdcnfZPdeMWiHcYgNVfi
> > KQg&s=oa9NQJzo6LB8M-pUBrAXhm5TSsVzU7SCD4fGi-Cik4s&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> >
> man_listinfo_sacm&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJf
> > QzvlsiLQfucBXRucPvdrphpBsFA&m=NCVTg-
> tLUOwFk_THQ3uGcdcnfZPdeMWiHcYgNVfi
> > KQg&s=oa9NQJzo6LB8M-pUBrAXhm5TSsVzU7SCD4fGi-Cik4s&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_sacm&d=AwICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=NCVTg-
> tLUOwFk_THQ3uGcdcnfZPdeMWiHcYgNVfiKQg&s=oa9NQJzo6LB8M-
> pUBrAXhm5TSsVzU7SCD4fGi-Cik4s&e=

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 26 Mar 2015 15:49:08 +0000

Can you help me with finding the meeting details?  I'd like to listen in on the meeting, if my schedule permits.  After reading the draft, I've also prepared a use case for consideration that addresses some of the more challenging asset identification and characterization problems I've been working while developing business logic for continuous monitoring.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Chris Inacio
Sent: Thursday, March 26, 2015 11:32 AM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: [email-masked]
Subject: Re: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

--
Chris Inacio
[email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Mar 2015 16:11:31 +0000

Hi Joseph,

Please follow the SACM WG list. Future calls will be announced on the mail list. 

Would it be possible to submit your contributions as individual submission Internet-Drafts? Of course, your contributions will be considered in any format, but I-Ds are the default in the IETF, they allow for archiving, ease later searches, etc. 

Thanks and Regards,

Dan

> From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L
> CIV DISA ID (US)
> Sent: Thursday, March 26, 2015 5:49 PM
> To: Chris Inacio
> Cc: [email-masked]
> Can you help me with finding the meeting details?  I'd like to listen in on the
> meeting, if my schedule permits.  After reading the draft, I've also prepared a
> use case for consideration that addresses some of the more challenging
> asset identification and characterization problems I've been working while
> developing business logic for continuous monitoring.
> 
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> (301) 225-8820
> iZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_5nnWOhi
> fAUcZCJ
> >
> BvOPQ8TbZxYQZOxR43lUett4SGoU&s=OfnrmmWqMbw7wJ1MUYPJwANQu
> K3xrwYcrlSgd6R
> > wzS4&e=
> >
> H64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_5nnWOhif
> AUcZCJBv
> >
> OPQ8TbZxYQZOxR43lUett4SGoU&s=ROW4gHiDxFt8yiIcjeUIQ25TTZrGk4PFW
> YzpoW-Tx
> > 8U&e=
> >
> suKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_
> 5nnWOh
> > ifAUcZCJBvOPQ8TbZxYQZOxR43lUett4SGoU&s=B-
> PqJOctrqyfe5v7t7_MNBweqKP00fZ
> > yZE-2xwgGPuM&e=
> >
> >
> iLQfucBXRucPvdrphpBsFA&m=_5nnWOhifAUcZCJBvOPQ8TbZxYQZOxR43lUe
> tt4SGoU&s
> > =ScKG6BIAR999xzprDzBjc4ss03vp7vMFwsCE2GOeAIs&e=
> >
> QzvlsiLQfucBXRucPvdrphpBsFA&m=_5nnWOhifAUcZCJBvOPQ8TbZxYQZOxR4
> 3lUett4S
> > GoU&s=kyS9yfQ6HxI2E42mj-f3lLvwm_o00hyGyeZU4u1p5mU&e=
> QzvlsiLQfucBXRucPvdrphpBsFA&m=_5nnWOhifAUcZCJBvOPQ8TbZxYQZOxR4
> 3lUett4S
> > GoU&s=kyS9yfQ6HxI2E42mj-f3lLvwm_o00hyGyeZU4u1p5mU&e=
> 
> 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_5nnW
> OhifAUcZCJBvOPQ8TbZxYQZOxR43lUett4SGoU&s=kyS9yfQ6HxI2E42mj-
> f3lLvwm_o00hyGyeZU4u1p5mU&e=

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 26 Mar 2015 11:51:18 -0500

Here’s the post with the meeting information.

https://www.ietf.org/mail-archive/web/sacm/current/msg02498.html <https://www.ietf.org/mail-archive/web/sacm/current/msg02498.html>

> On Mar 26, 2015, at 11:11 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> 
> Hi Joseph,
> 
>> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Wolfkiel, Joseph L
>> CIV DISA ID (US)
>> Cc: [email-masked] <mailto:[email-masked]>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf>.
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_htm <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_htm>
>>> https://urldefense.proofpoint.com/v2/url?u=http- <https://urldefense.proofpoint.com/v2/url?u=http->
>> 3A__www.ietf.org_rfcdi
>>> submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern>
>>> et-
>>> [email-masked] <mailto:[email-masked]>
>>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
>> 3A__www.ietf.org_mail
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
>> 3A__www.ietf.org_mail
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 26 Mar 2015 18:37:37 +0000

Joe,

Thanks for submitting the use case example. After reading through the document, it appears that what you are describing is essentially two instances of usage scenarios 2.2.1 thru 2.2.4, 2.2.6, and 2.2.7 in the SACM Use Cases draft:

In both the PROD and BCP/COOP cases, a common baseline is being used.

Are there specific areas where you see a difference from what is describe in the Use Cases draft?

Thanks,
Dave

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L CIV DISA ID (US)
Sent: Thursday, March 26, 2015 10:49 AM
To: Chris Inacio
Cc: [email-masked]
Subject: Re: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Chris Inacio
Sent: Thursday, March 26, 2015 11:32 AM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: [email-masked]
Subject: Re: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

--
Chris Inacio
[email-masked]

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 26 Mar 2015 20:12:27 +0000

I discussed the use case with Dave Waltermire and we determined that pursuing that particular use case would probably not be value-added given that the use case document is too close to publication to entertain adding new cases.

What may be valuable instead is to specifically address the issues the use case was built to highlight.  Here they are:

1.  Since the VMs are identical clones, the hostnames, MAC addresses, and possibly IP addresses are identical, so they can't be used as unique device identifiers.  This would force you to use BIOS GUID or monitoring software agent GUIDs to differentiate.  This is an outcome I saw in one of our production systems.  The only way you could tell they were two different systems was because their AV Agent GUIDs were different and their locations were different.

2.  Since the vulnerability scanner and asset manager hit different interfaces from different domains, they may not see the same fully qualified domain names.  This is a problem between our AV product and our vulnerability scanner product.  The AV product uses the Microsoft NetBIOS domain name and the vulnerability scanner collects the DNS name.  In our production environment, the same host names are re-used all over the place, so you have to use the FQDN, or you end up with lots of incorrect matches. For example, I counted 6 different systems yesterday that all had the host name "SQL1"

3.  The devices have to be identified across time so that trends can be captured.  This is more of a problem with the vulnerability scanner because it sees different levels of detail and (potentially) different IP and MAC addresses over time for the same device, so one day it may report against a host name, one day against a MAC address, on a different day it will report against an IP address.  The continuous monitoring system has to be able to fingerprint the device information to determine that the devices are or aren't the same ones.  Even then, some of the data is received out of order, so you have to track timestamps to ensure that older data doesn't overwrite more current data.

4.  The rollup functionality is a requirement not covered in any use cases, as well as the fact that you have to capture who administers, who owns, where located, and system affiliation 

5.  The ability to designate a baseline and compare other devices against it is, I think, a new requirement

6.  The ability to capture data to enforce SLA compliance, which may drive funding, may lead to a requirement for trusted paths or some other data integrity constraint.  Otherwise, you may not be able to legally hold your hosting environment company accountable for SLA non-compliance.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 26 Mar 2015 16:52:37 -0400

Joe,

Your first three items are related to asset identification, and there is 
a side group working on exactly that.

Strictly speaking, however, this level of asset identification is not 
necessary in order to perform a security assessment.  It's a reasonable 
requirement set for enterprise security management, but that's not to 
say that it should be in scope for SACM at this point.

Similarly, four is about enterprise security management.  It would be 
reasonable to expect that an enterprise management system based on SACM 
would include that capability, but that does not necessarily mean that 
it should be included as a SACM requirement at this point.

Likewise, five is a reasonable function to expect from a security 
management system, but given SACM's initial charter, it doesn't appear 
to be in scope.

For six, the intersection between your service level agreement and those 
items that are security related are certainly possible, but I don't see 
that this creates an new requirements for SACM. Non-security related 
items like average uptime would not be in scope for SACM, and those 
items that are security related would already be covered by existing 
SACM requirements.

However, the SLA item is worth keeping in mind, because there are 
security considerations that are not immediately obvious.  Requiring 
that the hosting organization only run certain software within a 
specific geopolitical boundary, for example, meaning that SACM needs to 
consider the ability to collect attributes from the hosting provider to 
determine that.

--gun

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 26 Mar 2015 21:26:02 +0000

Thanks for the clarifications.  I just got on the list this week, so I'm spinning up on what scope limitations the SACM group has placed on itself. 

I'm primarily concerned with enterprise security management so I'm concerned that it will be hard to go back and fix asset identification later if it isn't done to meet known use cases initially.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Thursday, March 26, 2015 4:53 PM
To: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]
Cc: Waltermire, David A.
Subject: Re: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

Joe,

Your first three items are related to asset identification, and there is a side group working on exactly that.

Strictly speaking, however, this level of asset identification is not necessary in order to perform a security assessment.  It's a reasonable requirement set for enterprise security management, but that's not to say that it should be in scope for SACM at this point.

Similarly, four is about enterprise security management.  It would be reasonable to expect that an enterprise management system based on SACM would include that capability, but that does not necessarily mean that it should be included as a SACM requirement at this point.

Likewise, five is a reasonable function to expect from a security management system, but given SACM's initial charter, it doesn't appear to be in scope.

For six, the intersection between your service level agreement and those items that are security related are certainly possible, but I don't see that this creates an new requirements for SACM.  Non-security related items like average uptime would not be in scope for SACM, and those items that are security related would already be covered by existing SACM requirements.

However, the SLA item is worth keeping in mind, because there are security considerations that are not immediately obvious.  Requiring that the hosting organization only run certain software within a specific geopolitical boundary, for example, meaning that SACM needs to consider the ability to collect attributes from the hosting provider to determine that.

--gun

	

	

	
	
	Joseph L. Wolfkiel
	SCM Engineering Lead
	DISA ID52
	(301) 225-8820

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 26 Mar 2015 16:41:12 -0500

> On Mar 26, 2015, at 3:52 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> Joe,
> 

+1

> Similarly, four is about enterprise security management.  It would be reasonable to expect that an enterprise management system based on SACM would include that capability, but that does not necess…

+1

> Likewise, five is a reasonable function to expect from a security management system, but given SACM's initial charter, it doesn't appear to be in scope.

I’m not sure I fully understood what “designate a baseline” meant.  Was the intended meaning: 1) To apply an expressed baseline to different devices (we’re covering this), 2) to configure one device to compliance and then compare another device to it, 3) compare assessment results about one device against the assessment results of another device, or 4) something else I’m not imagining?

> For six, the intersection between your service level agreement and those items that are security related are certainly possible, but I don't see that this creates an new requirements for SACM.  Non…

+/- 1.  If average uptime is something we can grab as state/status/attribute, we would be able to accommodate it.  Also, at some point in the future, average uptime might well be security relevant (if it’s not already today in terms of resource availability).  

While we are certainly rooted in the security space, the point of SACM is to use the same collected data for a variety of purposes, and where we can expect what is or is not “security relevant” to change over time.

As a note, the only instance of “security-relevant” (or variants) I can find in WG-adopted drafts is in draft-ietf-sacm-information-model-01, and then the instance is in an appendix explaining IF-MAP.  

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

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 26 Mar 2015 16:49:14 -0500

> On Mar 26, 2015, at 4:26 PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]> wrote:
> 

I believe we share your concern.

One of our overarching general requirements (GEN-001, in fact) is to provide extensibility:  The data models, protocols, and transports defined by SACM MUST be extensible to allow support for non-standard and future extensions.

We’ve also recognized (as part of our ongoing endpoint identification work) that endpoint attributes used for identity are simply endpoint attributes.  Another way to look at this is that any attribute for an endpoint could be used to assist in that endpoint’s identification.

So, if we later discover we’ve missed something, we can extend to bring it into the fold.  We would also have the option to update the standard, if the need presented itself.

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 26 Mar 2015 21:53:10 +0000

The baseline intent was to compare the posture of a risk-accepted "baseline" device against deployed instances.  Sort of the union between your options 2 and 3.  This is a configuration management baseline control "baseline", with the measurable security-related configurations treated as "configuration items".

For the SLA stuff, I'm thinking more like "keep antivirus updated to within 2 days of the vendor's signature updates" or "provide encryption of sensitive data at rest" as service level issues that would be security specific, sensor measurable, and state-based.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Thursday, March 26, 2015 5:41 PM
To: Gunnar Engelbach
Cc: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]; Dave Waltermire
Subject: Re: [sacm] I-D Action: draft-ietf-sacm-use-cases-09.txt

	Joe,

+1

+1

I'm not sure I fully understood what "designate a baseline" meant.  Was the intended meaning: 1) To apply an expressed baseline to different devices (we're covering this), 2) to configure one device to compliance and then compare another device to it, 3) compare assessment results about one device against the assessment results of another device, or 4) something else I'm not imagining?

+/- 1.  If average uptime is something we can grab as state/status/attribute, we would be able to accommodate it.  Also, at some point in the future, average uptime might well be security relevant (if it's not already today in terms of resource availability).  

While we are certainly rooted in the security space, the point of SACM is to use the same collected data for a variety of purposes, and where we can expect what is or is not "security relevant" to change over time.

As a note, the only instance of "security-relevant" (or variants) I can find in WG-adopted drafts is in draft-ietf-sacm-information-model-01, and then the instance is in an appendix explaining IF-MAP.  

	--gun

		

		

		
		
		Joseph L. Wolfkiel
		SCM Engineering Lead
		DISA ID52
		(301) 225-8820

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 26 Mar 2015 19:04:51 -0400

On 3/26/2015 5:41 PM, Adam W. Montville wrote:
>
>> On Mar 26, 2015, at 3:52 PM, Gunnar Engelbach 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Joe,
>>
>> necessary in order to perform a security assessment.  It's a 
>> reasonable requirement set for enterprise security management, but 
>> that's not to say that it should be in scope for SACM at this point.
>>
>
> +1
>
>> reasonable to expect that an enterprise management system based on 
>> SACM would include that capability, but that does not necessarily 
>> mean that it should be included as a SACM requirement at this point.
>
> +1
>
>>
>> management system, but given SACM's initial charter, it doesn't 
>> appear to be in scope.
>
> I’m not sure I fully understood what “designate a baseline” meant. 
>  Was the intended meaning: 1) To apply an expressed baseline to 
> different devices (we’re covering this), 2) to configure one device to 
> compliance and then compare another device to it, 3) compare 
> assessment results about one device against the assessment results of 
> another device, or 4) something else I’m not imagining?
>
>>
>> For six, the intersection between your service level agreement and 
>> those items that are security related are certainly possible, but I 
>> don't see that this creates an new requirements for SACM.  
>> Non-security related items like average uptime would not be in scope 
>> for SACM, and those items that are security related would already be 
>> covered by existing SACM requirements.
>
> +/- 1.  If average uptime is something we can grab as 
> state/status/attribute, we would be able to accommodate it.  Also, at 
> some point in the future, average uptime might well be security 
> relevant (if it’s not already today in terms of resource availability).
>
> While we are certainly rooted in the security space, the point of SACM 
> is to use the same collected data for a variety of purposes, and where 
> we can expect what is or is not “security relevant” to change over time.
>
> As a note, the only instance of “security-relevant” (or variants) I 
> can find in WG-adopted drafts is 
> in draft-ietf-sacm-information-model-01, and then the instance is in 
> an appendix explaining IF-MAP.

It goes back to priorities.

Having SACM define a collection action not perceived of as security 
related and then expecting everybody to implement it would make that 
item a very low priority.

However, if an existing collection ability can be used to collect 
non-security related attributes and somebody can make use of that, 
fantastic.

For that matter, if somebody want to extend SACM collection abilities on 
their into non-security related items they should feel free to do so.  
Just don't expect everybody else to also implement it.