Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

From: [email-masked]
Date: Mon, 10 Sep 2012 08:42:01 -0500 (CDT)

To all:

The document appears very good to me.

Comments:

3.3.1.  Goal “   Continuous assessment of the implementation and effectiveness of

security controls based on machine processable content.”  PHENOMENAL!

Paragraph 9. Acknowledgementss:  Mispelled word “thier” change to “their”.

Suggestions:

The mature state of automation makes it worthwhile to introduce new associated terms to address future situations.

Automatable (adverb):  The condition of a process that can be implemented with security automation mechanisms.  For instance, “configuration compliance is an automatable process”

Non-automatable (adverb):  The condition of a process that cannot be implemented with security automation mechanisms.  For instance, “conflicting  policy resolution is a non-automatable process”.

Semi-automatable (adverb):  The condition of a process which can be partially implemented or supported with security automation mechanisms.  For example “Some semi-automatable processes can be supported with SCAM specifications such as the Open Checklist Interactive Language (OCIL)”.

A few questions come to mind (perhaps due to my lack of familiarity with the modus operandi of the IETF).

1.       What happens with the document at the end of March 2013?

2.       Where does the model in Figure 1 come from?

3.       Why are only other RFCs acceptable references?

4.       Why are acronyms without definitions used (ORM, IRM)?

David Oliva

On 09/07/12, Waltermire, David A.<[email-masked]> wrote:

I just posted an updated use cases document (see below) that reduces the scope to UC1-3 and adds a lot of new content. Many thanks to Adam Montville for all his hard work on this revision.

Comments are appreciated.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 07, 2012 3:49 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

A new version of I-D, draft-waltermire-sacm-use-cases-02.txt
has been successfully submitted by David Waltermire and posted to the IETF repository.

Filename: draft-waltermire-sacm-use-cases
Revision: 02
Title: Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases
Creation date: 2012-09-07
WG ID: Individual Submission
Number of pages: 23
URL: http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-02.txt
Status: http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases
Htmlized: http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02
Diff: http://www.ietf.org/rfcdiff?url2=draft-waltermire-sacm-use-cases-02

Abstract:
This document identifies foundational use cases, derived functional
capabilities and requirements, architectural components, and the
supporting standards needed to define an interoperable,
automation\infrastructure required to support timely, accurate and
actionable situational awareness over an organization's IT systems.
Automation tools implementing a continuous monitoring approach will
utilize this infrastructure together with existing and emerging
event, incident and network management standards to provide
visibility into the state of assets, user activities and network
\behavior. Stakeholders will be able to use these tools to aggregate
and analyze relevant security and operational data to understand the
organizations security posture, quantify business risk, and make
informed decisions that support organizational objectives while
protecting critical information. Organizations will be able to use
these tools to augment and automate information sharing activities to
collaborate with partners to identify and mitigate threats. Other
automation tools will be able to integrate with these capabilities to
enforce policies based on human decisions to harden systems, prevent
misuse and reduce the overall attack surface.

The IETF Secretariat

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

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Sep 2012 13:58:30 +0000

David,

Thank you for the comments!  I made most of these changes to the document so far, so I think I can address many of your questions – inline.

Regards,

Adam

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 10, 2012 6:42 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

To all:

Thanks!

Comments:

Good catch, thank you.  I need to run a spell-check ;-)

Suggestions:

So, these are suggestions for the (presently incomplete) terms and definitions section.  Excellent!  I might suggest some rewording.

I'm not sure I understand the choice of the word "condition" in this context (this comment applies to the following suggestions as well).  Would "steps" be more appropriate?  Also, I might argue in favor of removing "security" from the definition.  In our context we're looking at security automation mechanisms, but the term "automatable" is applicable beyond our domain – in fact, this term is already defined abstractly as "to make automatic."

Also, because "security automation" is used, we'll want to define that as well.  I'm not sure that it has been defined anywhere at this point.  Any suggestions?

I don't know.  One of the more experienced IETFers needs to answer that question.  I imagine that we can update or, perhaps, resubmit this document, or let it be, as it's informational.

This is my doing and it comes from no official source.  It does, however, represent a useful perspective for SACM and other security automation efforts.

I don't know that only RFCs are acceptable.  We should be able to reference anything, but only certain sources would be considered normative rather than informative.

My mistake.  They are abbreviations of Operational Risk Management and Information Risk Management respectively, which are introduced in Figure 1.  I can either update the figure or spell it out in the prose of the document, or both.

David Oliva

On 09/07/12, Waltermire, David A.<[email-masked]<mailto:[email-masked]>> wrote:

Sincerely,
Dave

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, September 07, 2012 3:49 PM
To: Waltermire, David A.
Cc: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

Abstract:

The IETF Secretariat

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

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 10 Sep 2012 10:01:59 -0400

Hi David,

Great questions & thanks for the review!  I'll start with #4, but am limited to an iPhone at the moment.

Standards development organizations (SDOs) have requirements to ensure the stability of documents for "normative references".  Other SDOs are valid locations for normative references as the reference is to a document as opposed to a link.  A link can change/disappear, the content can change, and therefore the document may not be stable.

The next set of issues are around IP.  If the document is at an SDO, the IP is clear even if there were IP disclosures submitted for that document.

If a document is hosted by a vendor, even if that document is open, adoption would increase of something that can be shared if it is at an SDO.  The submitted still shows the thought leadership with the contribution and other vendors can site compliance to a standards document as opposed to something from another vendor.

Examples of other SDOs include ISO, IEEE, W3C, ITU, OASIS, etc.  While NIST is not an SDO in the same sense, their documents are accepted as valid normative references from mist of the SDOs.

Steve Hanna or others - do you have any other reasons to add?

I hope this is helpful!
Kathleen

Sent from my iPhone

On Sep 10, 2012, at 9:45 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

To all:

Comments:

Suggestions:

Sincerely,
Dave

-----Original Message-----
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]]
Sent: Friday, September 07, 2012 3:49 PM
To: Waltermire, David A.
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

Filename: draft-waltermire-sacm-use-cases
Revision: 02
Title: Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases
Creation date: 2012-09-07
WG ID: Individual Submission
Number of pages: 23
URL: <http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-02.txt> http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-02.txt
Status: <http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases> http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases
Htmlized: <http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02> http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02
Diff: <http://www.ietf.org/rfcdiff?url2=draft-waltermire-sacm-use-cases-02> http://www.ietf.org/rfcdiff?url2=draft-waltermire-sacm-use-cases-02

Abstract:

The IETF Secretariat

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

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Sep 2012 15:21:36 +0000

From: <Moriarty>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 10, 2012 7:01 AM
To: "[email-masked]<mailto:[email-masked]>" <[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] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

Hi David,

#3 is what I believe Kathleen meant.

I hope this is helpful!
Kathleen

Sent from my iPhone

To all:

Comments:

Suggestions:

Sincerely,
Dave

-----Original Message-----
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]]
Sent: Friday, September 07, 2012 3:49 PM
To: Waltermire, David A.
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

Abstract:

The IETF Secretariat

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 10 Sep 2012 21:30:04 -0400

I agree with Kathleen’s comments on question 3 but I’d also suggest that SACM participants review sections 4.2.4, 7, and 10 of RFC 2026, especially section 7. That section contains a good explanation of the difference between open standards and other specifications, how the IETF should deal with these categories of specifications, and why. This issue seems to be especially critical for SACM.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Monday, September 10, 2012 10:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sacm] FW: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

Hi David,

I hope this is helpful!
Kathleen

Sent from my iPhone

Comments:

Suggestions:

Sincerely,
Dave

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, September 07, 2012 3:49 PM
To: Waltermire, David A.
Cc: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-waltermire-sacm-use-cases-02.txt

Abstract:

The IETF Secretariat