Subject: Re: [sacm] Terms and Definitions (was RE: SACM Charter Focused)

From: Sean Turner <[email-masked]>
Date: Sat, 26 Jan 2013 22:41:06 -0500

rfc 4949 also defines asset.

Spt

Sent from my iPhone

On Jan 22, 2013, at 9:50 PM, "Waltermire, David A." <[email-masked]> wrote:

> I stubbed out a glossary section for the Use Cases document, but didn't include it in the most recent draft since I didn't have any associated definitions.  There is a mixture of terminology used within the draft.  It would be useful to tighten down the terms used to a smaller set.  The following terms/definitions would go a long way to addressing this and would also set us up to talk more succinctly relative to the use case and architecture documents.
> 
> * Asset - ISO/IEC 27001:2005 defines an asset as: "Any tangible or intangible thing that has value to an organization."
> 
> Short and sweet.  Got this off a web reference.  I don't have a copy of the doc right now.  I'll double check it tomorrow.
> 
> We use a similar definition at NIST in NISTIR 7693 section 2.1 (http://csrc..nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf): "Anything that has value to an organization, including, but not limited to, another organization, person, computing device, information technology (IT) system, IT network, IT circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualized computing), and related hardware (e.g., locks, cabinets, keyboards)."
> 
> Also from SP 800-30r1 (http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf) relative to "organizational assets": "The term organizational assets can have a very wide scope of applicability to include, for example, high-impact programs, physical plant, mission-critical information systems, personnel, equipment, or a logically related group of systems. More broadly, organizational assets represent any resource or set of resources which the organization values, including intangible assets such as image or reputation.
> 
> This encompasses software and endpoints as assets.
> 
> * Endpoint - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition: "Any computing device that can be connected to a network. [snip] This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address."
> 
> * Posture - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition:  "Configuration and/or status of hardware or softw

---

From: "ietfdbh" <[email-masked]>
Date: Sun, 27 Jan 2013 07:38:57 -0500

Hi Sean,

Would there be any issues introduced by a dependency on rfc4949, which is
deliberately only Informational?
(I'm sure you and the IESG have run into this question before)

I don't know the current thinking on how to handle that vis-à-vis rfc4949.
When rfc4949 was approved, it was not made a standard because there were
many existing or in-process IETF standards-track docs that didn't use
rfc4949 terminology.
(oddly for me, SNMPv3 comes to mind ;-)
Trying to synchronize existing and in-process IETF standards to comply would
have been a massive undertaking, and changing the in-use terminology (such
as SNMP's use of "privacy" to mean confidentiality) would be confusing.
I believe new standards-track docs have been strongly encouraged to use
rfc4949 terminology.
I notice you are not requiring us to use rfc4949, merely suggesting it as
one approach.

The SACM effort appears to have lots of input from people working across
SDOs.
Other SDOs sometimes require standards-track status if their docs will
reference IETF docs.
(Maybe that has been resolved and I don't recall the outcome of such
discussions)
Is using rfc4949 to define terms likely to cause inter-SDO issues?
I would like to avoid inter-SDO issues.

OTOH, I am very aware that definitions of terms by different SDOs often have
slightly (and sometimes not-so-slightly) different semantics.
In addition, the semantics of a definition by an SDO can change over time,
without full consideration by another SDO of how such a change they make
might impact existing or in-process IETF standards.
So I hesitate to use a definition from another SDO normatively.
I also have concerns if the other-SDO document is not freely available (let
me stress the free), whereas rfc4949 is freely available.
My preference is to use rfc4949 for the terminology used in the sacm IETF
effort to make sure the reference document is freely available, and
change-control over the definitions used by IETF sacm standards is
maintained by IETF - easier to keep them in sync.

I just want to an early discussion of any potential problems that might
arise due to the Informational status of rfc4949, and the cross-SDO nature
of this work.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean
Turner
Sent: Saturday, January 26, 2013 10:41 PM
To: Waltermire, David A.
Cc: Stephen Hanna; Allan Thomson (althomso); [email-masked]
Subject: Re: [sacm] Terms and Definitions (was RE: SACM Charter Focused)

Spt

Sent from my iPhone

On Jan 22, 2013, at 9:50 PM, "Waltermire, David A."
<[email-masked]> wrote:

> I stubbed out a glossary section for the Use Cases document, but didn't
include it in the most recent draft since I didn't have any associated
definitions.  There is a mixture of terminology used within the draft.  It
would be useful to tighten down the terms used to a smaller set.  The
following terms/definitions would go a long way to addressing this and would
also set us up to talk more succinctly relative to the use case and
architecture documents.
> 
> * Asset - ISO/IEC 27001:2005 defines an asset as: "Any tangible or
intangible thing that has value to an organization."
> 
> Short and sweet.  Got this off a web reference.  I don't have a copy of
the doc right now.  I'll double check it tomorrow.
> 
> We use a similar definition at NIST in NISTIR 7693 section 2.1
(http://csrc..nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf):
"Anything that has value to an organization, including, but not limited to,
another organization, person, computing device, information technology (IT)
system, IT network, IT circuit, software (both an installed instance and a
physical instance), virtual computing platform (common in cloud and
virtualized computing), and related hardware (e.g., locks, cabinets,
keyboards)."
> Also from SP 800-30r1
(http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf)
relative to "organizational assets": "The term organizational assets can
have a very wide scope of applicability to include, for example, high-impact
programs, physical plant, mission-critical information systems, personnel,
equipment, or a logically related group of systems. More broadly,
organizational assets represent any resource or set of resources which the
organization values, including intangible assets such as image or
reputation.
> * Endpoint - Reference RFC 5209 section 2
(http://tools.ietf.org/html/rfc5209#section-2) definition: "Any computing
device that can be connected to a network. [snip] This includes: laptops,
desktops, servers, cell phones, or any device that may have an IP address."
> 
> * Posture - Reference RFC 5209 section 2
(http://tools.ietf.org/html/rfc5209#section-2) definition:  "Configuration
and/or status of hardware or softw

---

From: Sean Turner <[email-masked]>
Date: Sun, 27 Jan 2013 19:33:37 -0500

> (I'm sure you and the IESG have run into this question before)

It depends.  If the document that includes the reference is standards 
track and the reference is informative, then there's no problem.  If the 
document that includes the reference is standards track and the 
reference is normative, then we could follow the downref procedure in 
RFC 3967.  If the document that includes the reference is informative, 
then it doesn't matter whether the reference is normative or informative.

> (oddly for me, SNMPv3 comes to mind ;-)

People love to hate RFC 4949 ;)

> I notice you are not requiring us to use rfc4949, merely suggesting it as

Yep.  I was just throwing out there that asset had been defined before 
and I'm sure asset and probably endpoint have been defined elsewhere. 
BTW what's there is:

  $ asset
    (I) A system resource that is (a) required to be protected by an
    information system's security policy, (b) intended to be protected
    by a countermeasure, or (c) required for a system's mission.

For giggles I went looking to see if asset had been defined elsewhere. 
I stumbled across FYI 8/RFC 2196 there's a great section in there on 
identifying assets ;)

> I would like to avoid inter-SDO issues.

I'd really like to avoid them too.

> arise due to the Informational status of rfc4949, and the cross-SDO nature

Almost all RFCs have both informative and normative references and I'm 
pretty sure you're not suggesting that all the references have to be 
normative in all of the drafts produced.

Besides, I think somebody could make the case that the reference 
could/would be informative because there's nothing to implement.

spt

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