Subject: [nfsv4] NFSv4 Label Use Cases

From: <[email-masked]>
Date: Thu, 14 Apr 2011 10:56:25 -0400

Here's the promised initial use case material from Kathleen with some editing by yours truly (i.e., credit Kathleen for most of the content, but blame me for any mistakes that are found ...).  This is intended for further discussion on today's labeled NFS call.

ITAR Use Case
--------------
The International Traffic in Arms Regulations (ITAR) is put forth by the United States Department of State, Directorate of Defense and Trade Controls.  ITAR places strict requirements on the export and thus access of defense articles and defense services.  Organizations that manage projects with articles and services deemed as within the scope of ITAR must ensure the regulations are met.  The regulations require an assurance that ITAR information is accessed on a need-to-know basis, thus requiring strict, centrally managed access controls on items labeled as ITAR.  Additionally, organizations must be able to prove that the controls were adequately maintained and that foreign nationals were not permitted access to these defense articles or service.  ITAR control applicability may be dynamic; information may become subject to ITAR after creation (e.g., when the defense implications of technology are recognized).

Legal Hold/eDiscovery Use Case
------------------------------
Increased cases of legal holds on electronic sources of information (ESI) have resulted in organizations taking a pro-active approach to reduce the scope and thus costs associated with these activities.  ESI Data Maps are increasing in use and require support in operating systems to strictly manage access controls in the case of a legal hold.  The sizeable quantity of information involved in a legal discovery request may preclude making a copy of the information to a separate system that manages the legal hold on the copies; this results in a need to enforce the legal hold on the original information.

Organizations are taking steps to map out the sources of information that are most likely to be placed under a legal hold, these efforts result in ESI Data Maps.  ESI Data Maps specify the Electronic Source of Information and the requirements for sensitivity and criticality.  In the case of a legal hold, the ESI data map and labels can be used to ensure the legal hold is properly enforced on the predetermined set of information.  An ESI data map narrows the scope of a legal hold to the predetermined ESI.  The information must then be protected at a level of security of which the weight and admissibility of that evidence may be proved in a court of law.  Current systems use application level controls and do not adequately meet the requirements.  Labels may be used in advance when an ESI data map exercise is conducted with controls being applied at the time of a hold or labels may be applied to data sets during an eDiscovery exercise to ensure the data protections are adequate during the legal hold period.

Note that this use case requires multi-attribute labels, as both information sensitivity (e.g., to disclosure) and information criticality (e.g., to continued business operations) need to be captured. 

Courtesy of Google, here's an this example of information sensitivity and criticality classifications:

	https://www.cu.edu/policies/policies/IT_IT-Sec_UnivOps_PROC.pdf

Thanks,
--David (for David and Kathleen)

----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | [email-masked]  | EMC Corporation

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 10:09:26 -0500

> Note that this use case requires multi-attribute labels, as both information sensitivity (e.g., to disclosure) and information criticality (e.g., to continued business operations) need to be captur…

David,

Is requirement met by the current I-D?

Thanks,
Tom

---

From: Dave Quigley <[email-masked]>
Date: Thu, 14 Apr 2011 11:16:05 -0400

On 4/14/2011 11:09 AM, Thomas Haynes wrote:
> On Apr 14, 2011, at 9:56 AM,<[email-masked]>  wrote:
>
>>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
It should be. The label format isn't mandated by the NFS I-D. That is 
handled by creating a LFS for the label type you want. If they wanted to 
have a label which consisted of sensitivity and criticality they can 
make an LFS to do so. I'll be on the telecon at 1:30 EST today but I'll 
be out of contact for the next couple hours. We can talk more about it then.

Dave

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 12:03:28 -0400

I am not sure if we need to have criticality included in this labeling scheme... eDiscovery does look at this as well for data maps, but for this effort, sensitivity may be enough.

-----Original Message-----
From: Thomas Haynes [mailto:[email-masked]] 
Sent: Thursday, April 14, 2011 11:09 AM
To: Black, David
Cc: [email-masked]; Moriarty, Kathleen
Subject: Re: [nfsv4] NFSv4 Label Use Cases

David,

Thanks,
Tom

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 12:19:40 -0400

> be out of contact for the next couple hours. We can talk more about it then.

+1, especially if the XDR doesn't have a fixed limit on label size.  The current draft has the following XDR, which looks ok:

       struct sec_label_attr_info = {
         labelformat_spec4   slai_lfs;
         opaque              slai_data<>;
       };

On the call, we should discuss implementation limits on label size and how a client discovers them (e.g., I can't imagine a 1MB label being reasonable to support).  I could see the limit depending on the LFS (label format), in which case it would need to be part of the specification for the LFS, although server implementations are likely to have an upper bound that is LFS-independent.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Quigley
> Sent: Thursday, April 14, 2011 11:16 AM
> To: [email-masked]
> >> Note that this use case requires multi-attribute labels, as both information sensitivity (e.g.,
> to disclosure) and information criticality (e.g., to continued business operations) need to be
> captured.
> >
> > David,
> >