Subject: [OPS-AREA] Issue 3: replacement boilerplate for management object sensitivity

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Feb 2009 10:47:28 -0500

Hi,

There is an existing boilerplate for the security consideration
section of a document defining objects of management information. This
boilerplate text discusses the read and write sensitivity of
management information in the data model. The current text is SMIv2
oriented. As the IETF moves to a strategy of supporting multiple
languages for defining management data models, the boilerplate text
should be updated to address the sensitivity of the information,
regardless of the language used to define the information. 

(This discussion is about how to update the existing boilerplate, not
whether to have such a boilerplate. Please see issue 1 if you think we
should not have boilerplate.)

OLD:
-- if you have any read-write and/or read-create objects, please
-- describe their specific sensitivity or vulnerability.
-- RFC 2669 has a very good example.

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

    <list the tables and objects and state why they are sensitive>

-- else if there are no read-write objects in your MIB module

   There are no management objects defined in this MIB module that
have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations.

-- for all MIB modules you must evaluate whether any readable objects
-- are sensitive or vulnerable (for instance, if they might reveal
-- customer information or violate personal privacy laws such as
-- those of the European Union if exposed to unathorized parties)

   Some of the readable objects in this MIB module (i.e., objects with
a
   MAX-ACCESS other than not-accessible) may be considered sensitive
or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

    <list the tables and objects and state why they are sensitive>

NEW:

-- include this paragraph if the management information can be
created, deleted, or modified:

   Some management information defined in this document can be
created, deleted, or modified by one or more management protocols.
Unauthorized or inappropriate modification could have a negative
effect on network operations or security. 

-- include the following in all documents that define management
information:

   The management information defined in this document can be
considered sensitive or lead to network vulnerabilities in some
environments. It is important to control access to this information
and possibly to encrypt the information when sending the information
over a network using a management protocol, to prevent unauthorized or
inappropriate exposure of this information. 

Following is a list of the potentially sensitive information, and why
this information is sensitive:

    <list the sensitive information elements and state why they are
sensitive to modification and exposure>

----
comments welcome

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Feb 2009 10:17:15 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'ops-area (IETF)'" <[email-masked]>
> Sent: Wednesday, February 04, 2009 7:47 AM
> Subject: [OPS-AREA] Issue 3: replacement boilerplate for management objectsensitivity
...
> NEW:
...
> sensitive to modification and exposure>
...

I prefer the approach of the old text, which split the information elements
according to concern (modification or mere exposure), rather than
lumping everything together like this, since separating them may help
in security policy formulation and sanity checking.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Feb 2009 13:27:55 -0500

Hi,

> according to concern (modification or mere exposure),

So would this work better?

    <list the sensitive information elements and state why they are
sensitive to modification>

sensitive to exposure>

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Wednesday, February 04, 2009 1:17 PM
> To: 'ops-area (IETF)'
> Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for 
> managementobjectsensitivity
> 
> Hi -
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Feb 2009 10:29:40 -0800

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; "'ops-area (IETF)'" <[email-masked]>
> Sent: Wednesday, February 04, 2009 10:27 AM
> Subject: RE: [OPS-AREA] Issue 3: replacement boilerplate for managementobjectsensitivity
>
> Hi,
> 

Yes, I think it's an improvement over the original proposal.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Feb 2009 10:01:25 +0100

I support the separation the texts and lists of writeable and readable
(only) objects. I believe that this variant works better. 

Dan

(speaking as contributor) 

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, February 04, 2009 8:28 PM
> To: 'Randy Presuhn'; 'ops-area (IETF)'
> Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate 
> formanagementobjectsensitivity
> 
> Hi,
> 
> > I prefer the approach of the old text, which split the information 
> > elements according to concern (modification or mere exposure),
> 
> -- include this paragraph if the management information can 
> be created, deleted, or modified:
> 
>    Some management information defined in this document can 
> be created, deleted, or modified by one or more management protocols.
> Unauthorized or inappropriate modification could have a 
> negative effect on network operations or security. 
> 
>     <list the sensitive information elements and state why 
> they are sensitive to modification>
> 
> considered sensitive or lead to network vulnerabilities in 
> some environments. It is important to control access to this 
> information and possibly to encrypt the information when 
> sending the information over a network using a management 
> protocol, to prevent unauthorized or inappropriate exposure 
> of this information. 
> 
> Following is a list of the potentially sensitive information, 
> and why this information is sensitive:
> 
>     <list the sensitive information elements and state why 
> they are sensitive to exposure>
>  
> 
> dbh
> 
> > I prefer the approach of the old text, which split the information 
> > elements according to concern (modification or mere 
> exposure), rather 
> > than lumping everything together like this, since 
> separating them may
> help