Subject: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt

From: David Harrington <[email-masked]>
Date: Sat, 10 Aug 2013 17:50:44 +0200

Hi,

I cut the terminology from use-cases and created a terminology doc.
This is an individual draft; the WG will need to decide whether to accept
it as a wg draft to start the wg's terminology doc.

--
David Harrington
[email-masked]
+1-603-828-1401

On 8/10/13 3:11 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-dbh-sacm-terminology-00.txt
>has been successfully submitted by David Waltermire and posted to the
>IETF repository.
>
>Filename:	 draft-dbh-sacm-terminology
>Revision:	 00
>Title:		 Terminology for Security Assessment
>Creation date:	 2013-08-10
>Group:		 Individual Submission
>Number of pages: 7
>URL:             
>http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology
>Htmlized:        http://tools.ietf.org/html/draft-dbh-sacm-terminology-00
>
>
>Abstract:
>   This memo documents terminology used in the documents produced by the
>   SACM WG (Security Automation and Continuous Monitoring).
>
>                  
>        
>
>
>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.
>
>The IETF Secretariat
>

---

From: Adam Montville <[email-masked]>
Date: Sun, 11 Aug 2013 02:00:43 +0000

David,

Thanks for putting this together.  I know that, if the WG decides to adopt the draft, there are at least two individuals interested in maintaining it, so you wouldn't necessarily have to.  

I know the draft doesn't *need* more than one editor, but it could be good to have two to handle reaction time (i.e. when a new term is needed, the draft can be updated quickly).  Anyone have thoughts on this?

Regards,

Adam

________________________________________
From: [email-masked] [[email-masked]] on behalf of David Harrington [[email-masked]]
Sent: Saturday, August 10, 2013 8:58 AM
To: [email-masked]
Subject: [sacm] FW: New Version Notification for        draft-dbh-sacm-terminology-00.txt

Hi,

--
David Harrington
[email-masked]
+1-603-828-1401

>until the htmlized version and diff are available at tools.ietf.org.

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

...

. . .

---

From: David Harrington <[email-masked]>
Date: Sun, 11 Aug 2013 12:06:09 +0200

Hi,

I THINK, but am not sure, that the tools team has made it possible for a
WG to use subversion or another SCCS so editors can simultaneously edit
shared WG drafts.
I have asked Tero, but have not yet gotten a reply. Henrick is on vacation.
My sources are in a BOX location, in the cloud, so I can share the
document with a list of other editors.

I think the best approach would be having the editors of the other
documents, the documents that will use the terminology, maintain the
terminology draft jointly.
That way, we ar enot adding a delay in processing having to wait for
somebody else to update the document so we can reference it.
We have a rather tight deadline, and adding unnecessary delay could hurt
meeting our deadlines.

I am sure we can find work for those who want to volunteer, but I think
inserting them into the critical path would be a mistake.
We can add them to the editing team for the terminology doc, but what
terminology would they add that wasn't driven by usage in the other
documents?
We don't need terminology for the sake of terminology; we need terminology
needed by the other docs.
The editors of the other docs are in the best position to know what that
is.

These volunteers can review the drafts and the terminology draft and find
terms we have not yet included.
They can open debates about whether the terminology we have is
appropriate/accurate, and so on.

--
David Harrington
[email-masked]
+1-603-828-1401

On 8/11/13 4:00 AM, "Adam Montville" <[email-masked]> wrote:

>David,
>
>Thanks for putting this together.  I know that, if the WG decides to
>adopt the draft, there are at least two individuals interested in
>maintaining it, so you wouldn't necessarily have to.
>
>I know the draft doesn't *need* more than one editor, but it could be
>good to have two to handle reaction time (i.e. when a new term is needed,
>the draft can be updated quickly).  Anyone have thoughts on this?
>
>Regards,
>
>Adam
>
>This message and attachments may contain confidential information. If it
>appears that this message was sent to you by mistake, any retention,
>dissemination, distribution or copying of this message and attachments is
>strictly prohibited. Please notify the sender immediately and permanently
>delete the message and any attachments.
>
>. . .

---

From: Stephen Hanna <[email-masked]>
Date: Sun, 11 Aug 2013 11:13:15 +0000

+1

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: Sunday, August 11, 2013 6:06 AM
> To: Adam Montville; [email-masked]
> Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-
> terminology-00.txt
> 
> Hi,
>

---

From: Adam Montville <[email-masked]>
Date: Sun, 11 Aug 2013 13:33:51 +0000

A couple of comments inline.  The bottom line is that the WG needs to work effectively and the WG is in the best position to determine how that looks.

> From: David Harrington [mailto:[email-masked]]
> Sent: Sunday, August 11, 2013 3:07 AM
> I THINK, but am not sure, that the tools team has made it possible for a WG
> to use subversion or another SCCS so editors can simultaneously edit shared
> WG drafts.
> My sources are in a BOX location, in the cloud, so I can share the document
> with a list of other editors.
> 
> 

The way I was looking at this is that terms are likely to be discussed on this list before they're added to and defined in a draft and it seems most critical to have the use cases, requirements, and architecture drafts unhindered by their respective authors/editors needing to maintain or co-maintain a tangential draft.  

> inserting them into the critical path would be a mistake.

While all of this is somewhat academic, I think the terminology draft itself should not be in the critical path at all.  Instead, the terminology draft should be something that "falls out" of the others and does not hinder forward progress.

> We don't need terminology for the sake of terminology; we need
> terminology needed by the other docs.
> The editors of the other docs are in the best position to know what that is.
> 
> >good to have two to handle reaction time (i.e. when a new term is
> >needed, the draft can be updated quickly).  Anyone have thoughts on this?
> >
> >Regards,
> >
> >Adam
> >
> >This is an individual draft; the WG will need to decide whether to
> >accept it as a wg draft to start the wg's terminology doc.
> >
> >
> >--
> >David Harrington
> >[email-masked]
> >+1-603-828-1401
> >
> >
> >
> >
> >
> >>A new version of I-D, draft-dbh-sacm-terminology-00.txt has been
> >>successfully submitted by David Waltermire and posted to the IETF
> >>repository.
> >>
> >>submission until the htmlized version and diff are available at
> >>tools.ietf.org.
> >>
> >>The IETF Secretariat
> >>
> >
> >
> >This message and attachments may contain confidential information. If
> >it appears that this message was sent to you by mistake, any retention,
> >dissemination, distribution or copying of this message and attachments
> >is strictly prohibited. Please notify the sender immediately and
> >permanently delete the message and any attachments.
> >
> >. . .
> 
> 
> 
> ...

. . .

---

From: Luis Nunez <[email-masked]>
Date: Sun, 11 Aug 2013 18:40:09 -0400

+1 on "I think the terminology draft itself should not be in the critical path at all.  Instead, the terminology draft should be something that "falls out" of the others and does not hinder forward progress."

I believe the terminology doc will evolve as we get consensus on the use cases and requirements.  With that I think we will eventually need the following definitions:
- Vulnerability
- Remediation
- Mitigation

-ln

---

From: David Harrington <[email-masked]>
Date: Mon, 12 Aug 2013 09:35:12 +0200

Can you provide text, or better yet, a reference to an existing document
that contains such definitions?

-- 
David Harrington
[email-masked]
+1-603-828-1401

On 8/12/13 12:40 AM, "Luis Nunez" <[email-masked]> wrote:

>+1 on "I think the terminology draft itself should not be in the critical
>path at all.  Instead, the terminology draft should be something that
>"falls out" of the others and does not hinder forward progress."
>
>I believe the terminology doc will evolve as we get consensus on the use
>cases and requirements.  With that I think we will eventually need the
>following definitions:
>- Vulnerability
>- Remediation
>- Mitigation
>
>
>-ln   
>
>> A couple of comments inline.  The bottom line is that the WG needs to
>>work effectively and the WG is in the best position to determine how
>>that looks.
>> 
>> The way I was looking at this is that terms are likely to be discussed
>>on this list before they're added to and defined in a draft and it seems
>>most critical to have the use cases, requirements, and architecture
>>drafts unhindered by their respective authors/editors needing to
>>maintain or co-maintain a tangential draft.
>> 
>>> 
>> While all of this is somewhat academic, I think the terminology draft
>>itself should not be in the critical path at all.  Instead, the
>>terminology draft should be something that "falls out" of the others and
>>does not hinder forward progress.
>> 
>>>>> Htmlized:    
>>>>>http://tools.ietf.org/html/draft-dbh-sacm-terminology-00
>>>>> 
>>>>> 
>>>>> Abstract:

---

From: "Nunez, Luis K" <[email-masked]>
Date: Mon, 12 Aug 2013 11:48:59 +0000

Here is a good reference from the NIST IR 7670 for vulnerability,
remediation and misconfigurations.  Mitigation is not listed and is
something we could define.    

A vulnerability is an error, flaw, or mistake in computer software that
permits or causes an unintended behavior or side effect to occur. 

A remediation is defined as a security-related set of actions that results
in a change to a computer's state and may consist of changes motivated by
the need to enforce organizational security policies, address discovered
vulnerabilities, or correct misconfigurations.

A misconfiguration is a configuration setting that violates organizational
security policies, introduces a possible security weakness in a system, or
permits or causes unintended behavior that may impact the security posture
of a system. 

Reference:
Waltermire, D., Johnson, C., Kerr, M., Wojcik, M., & Wunder, J. Proposed
Open Specifications for Enterprise Information Security Remediation - Draft
(NIST Interagency Report 7670). NIST, 2011
http://csrc.nist.gov/publications/drafts/nistir-7670/Draft-NISTIR-7670_Feb20
11.pdf

-ln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Harrington
Sent: Monday, August 12, 2013 3:35 AM
To: Luis Nunez; Adam Montville
Cc: David Harrington; [email-masked]
Subject: Re: [sacm] FW: New Version Notification for
draft-dbh-sacm-terminology-00.txt

-- 
David Harrington
[email-masked]
+1-603-828-1401

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 15 Aug 2013 10:44:30 -0700

A nit: under "asset" definition,

"to be*protect*  by a countermeasure"should be"to be*protected*  by a countermeasure".RFC4949 had it right.

Thanks.

- Jarrett