Subject: Re: [mile] contemplating data sharing restrictions/markings

From: <[email-masked]>
Date: Tue, 24 May 2011 09:29:50 -0400

Hi Pat,

Thanks for the response.  I actually asked what are the thoughts on TLP, not necessarily saying that we should use it yet (that may the or part of the answer).  The reason for this is to find out if TLP needed to be integrated in the Policy layer of RID (RFC6045).  For me, it was just to get an idea of what this list thought of TLP as I am starting to see it come up in more places.  TLP was added to the ITU-T CYBEX (x.1500) specification and I was trying to get a feel for where it fits in.  It was also mentioned in the context of CloudSIRT and FS-ISAC.  RID does account for consortiums or groups of users and where data passes as part of the policy already, so the use case of one group versus another's policy can already be factored in the routing.

I copied the mile mailing list here as well.  The mile mailing list is just getting started to figure out what may need to be extended and won't initially be focused on this problem, but more on extensions that need to be standardized for IODEF and how to make IODEF communications easier to understand, etc.  The scope may need to include some adjustments to RID and it would be good to get a handle on that as well in the long run.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of patrick cain
Sent: Monday, May 23, 2011 11:34 PM
To: [email-masked]
Subject: Re: contemplating data sharing restrictions/markings

Hi Bryon and Kathleen,
 
..who both said "why don't you use TLP"?

---

TLP is the 'traffic light protocol', which uses three colours to specify the
sharing rules to the received party. So one gets three ways to express how
to share the data. IODEF has *four* ways, which I can't get to work, and now
you want me to use *three*? :(

I'm hesitant to use TLP for two reasons (at least):

In the TLP-enabled groups that I participate in, probably 50% of the message
pick a colour -- and then add a sentence or two explanation or additional
info at the end. The 'additional info' makes automatically processing the
data kind of hard. So I've been watching what people put in that extra data
and expanded the set of three colors to six or seven. Note that there is no
reason for another group (e.g., 'fs-isac' or 'Kathleen's-group') to not
specify THEIR rules as red, yellow and green. And maybe 'white', too (but I
don't see many traffic lights with that color. :) ) The goal is to let a
sharing group decide the processing rules instead of trying to smush them
all into three or four colors/levels/extensions. Although this makes the
sharing-rules universal more complex, I'm guessing that DHS' red is
different from fs-isac's red which is surely different than apwg's red, so
keeping it simple might also lead to confusion.

We also need some extra attributes for our data. For example, is there an
embargo date, or can the data be shared with another group or LEAs. These
attributes are hard to show in both the current IODEF markings and the TLP
system. But if we make the sharing rules a sequence of groups with
attributes one can cover all these odd cases quite easily.

Note that I do not expect everyone to follow my idea. I am aware that a
handful of groups are trying to solve the same set of problems and it would
be good if we all understood what the other guys were doing (since we're
probably gonna exchange data at some point).

Pat Cain

---

From: John Howie <[email-masked]>
Date: Tue, 24 May 2011 07:55:47 -0700

Hi Pat,

For CloudSIRT (a Cloud Security Alliance initiative) we settled on the four color TLP. I agree that the TLP is somewhat limited, but it is perfect for use by humans. I would say that it is not appropriate for automated systems, as it lacks many of the attributes that you have observed codified into email messages and verbal instructions in an ad hoc fashion. Additionally, automated systems are perfect for controlling the dissemination of information through technologies such as DRM and DLP, both which require the use of attributes or metadata to communicate policy surrounding the information.

What this means is you need two systems - one for humans and one for automated systems. There needs to be some parity between the systems, and an easy conversion mechanism. For example, when I read a bulletin from an automated system I want the policy attached to that information translated into the TLP or equivalent system, and I want to be able to easily select policy based on the TLP or equivalent when I create a bulletin (in other words, I do not want to specify a number of attributes I do not fully understand).

Regards,

John

Sent from my iPad.

On May 24, 2011, at 6:29 AM, <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Tue, 24 May 2011 11:03:44 -0400

Thanks, John.  

I think a review of the Policy elements in RID may be in order as part of the charter for this proposed working group.  RID Policy does not cover TLP right now, but this could easily be added if it is the right thing to do.  ID takes it the next step to help automation, wrapping the IODEF message and proving the security, policy, and privacy needed for sharing incident information.  I'll add this to the working charter for MILE and we can discuss and figure out what is needed as we progress.  I have had other requests to use RID to help with the secure exchange of other XML report types (not just incidents), so I need to look at this anyway.

If there are other missing elements for IODEF/RID that we need to consider, please mention it!

Thank you,
Kathleen

-----Original Message-----
From: John Howie [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2011 10:56 AM
To: Moriarty, Kathleen
Cc: <[email-masked]>; <[email-masked]>; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi Pat,

Regards,

John

Sent from my iPad.

---

From: Katherine S Goodier <[email-masked]>
Date: Tue, 24 May 2011 18:28:29 +0000 (GMT+00:00)

I certainly agree that the systems for humans and systems for automated systems can and 
should differ. In fact, I imagine that as we review the Policy elements in RID with an eye to Cloud-based incident data sharing there may be even other data dissemination diatinctions that we may need to make.  

For example, each country has security markings that they use for assured information sharing.  The problems with these security markings in cloud storage and dissemination systems is that these markings can easily float away from the data that they are required to safeguard.  When this "security marked" data is disseminated on a public cloud, folks tend to go to jail.  This is very bad, and somewhat preventable.

Cryptographically inding these security and digital provenance markings to the safeguarded data is a critical best practice for assured incident data sharing in the cloud, I would think.  

I like the idea that ID enhances automation by wrapping the IODEF message and proving the security, policy, and privacy needed for sharing incident information. I suggest that for a small subset of incident metadata and data, cryptographic binding is an additional next step. 

Dr. Katherine Goodier 

Senior Computer Programmer/System Engineer 
Stratis/L-3 Communications 
Center of Excellence Lab, 5th floor 
supporting Unified Cross Domain Management Office (UCDMO) 
Army Research Lab, Bldg 601, Room 110 
  
lab - 301-575-3759 
unclass - 240-373-1714 
class - 763-2477 
cell - 240-515-4791 

----- Original Message -----
From: "kathleen moriarty" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Tuesday, May 24, 2011 11:03:44 AM
Subject: Re: [mile] contemplating data sharing restrictions/markings

Thanks, John.  

Thank you,
Kathleen

-----Original Message-----
From: John Howie [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2011 10:56 AM
To: Moriarty, Kathleen
Cc: <[email-masked]>; <[email-masked]>; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi Pat,

Regards,

John

Sent from my iPad.

---

From: <[email-masked]>
Date: Fri, 27 May 2011 10:50:56 -0400

It sounds like we have interest in reviewing RIDPolicy to include TLP from CloudSirt, FS-ISAC, and a US Government perspective.  FS-ISAC also mentioned PII/NPI markings, so we can review to ensure the crypto controls cover the needs or determine what may need to be adjusted if anything for this requirement.  

Is there interest from other sectors or additional areas in existing standards that should be reviewed?

Thank you,
Kathleen

-----Original Message-----
From: Katherine S Goodier [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2011 2:28 PM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Dr. Katherine Goodier 

lab - 301-575-3759 
unclass - 240-373-1714 
class - 763-2477 
cell - 240-515-4791 

----- Original Message -----
From: "kathleen moriarty" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Tuesday, May 24, 2011 11:03:44 AM
Subject: Re: [mile] contemplating data sharing restrictions/markings

Thanks, John.  

Thank you,
Kathleen

-----Original Message-----
From: John Howie [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2011 10:56 AM
To: Moriarty, Kathleen
Cc: <[email-masked]>; <[email-masked]>; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi Pat,

Regards,

John

Sent from my iPad.

---

From: John Howie <[email-masked]>
Date: Fri, 27 May 2011 13:32:17 -0700

> Hi Kathleen,
> 
> Privacy is always an issue when PII in included in information. For example, in the EU the term personal data is used instead of PII (as defined in the EU Data Protection Directive - 95/46/EC), and IP addresses of natural persons (data subjects) are considered personal data. Therefor any communication of information that contains IP addresses could be construed as in-scope for the DPD, requiring the data controller and data processor to comply with EU law if the data pertains to an EU resident.
> 
> Privacy in the US is a patchwork of laws and regulations, some conflicting with each other. However the group will need to understand the potential implications of information sharing and, worse, breaches of information (which could lead to breach notifications).
> 
> Ultimately, RIDPolicy needs to ensure that parties can share information in compliance with applicable statute and regulation, but it is up to the users of RIDPolicy to ensure that they are compliant.
> 
> I am in favor and second the FS-ISAC proposal.
> 
> Regards,
> 
> John
> 

> On Fri, May 27, 2011 at 7:50 AM, <[email-masked]> wrote:
>

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 27 May 2011 17:04:48 -0400

There is more involved here than just privacy.  The EU
Data Retention Directive requires that vast arrays of
communication related information be captured, tagged,
and bagged for significant periods of time.  Increasingly,
the judicial authorities of countries are imposing similar
requirements for eDiscovery purposes.  There are in fact
many requirements today related to the structured exchange
of incident forensics, and the associated policy requirements
are frequently incoherent and irreconcilable.  Developing
structured schema for all the variables and practices doesn't
seem feasible.

You can see how Rec. X.1500 - which is a kind of meta
construct for cybersecurity information exchange, including
RID - handled the PII admonition in the Scope clause.

--tony

On 5/27/2011 4:32 PM, John Howie wrote:
>
> Privacy is always an issue when PII in included in information. For 
> example, in the EU the term personal data is used instead of PII (as 
> defined in the EU Data Protection Directive - 95/46/EC), and IP 
> addresses of natural persons (data subjects) are considered personal 
> data. Therefor any communication of information that contains IP 
> addresses could be construed as in-scope for the DPD, requiring the 
> data controller and data processor to comply with EU law if the data 
> pertains to an EU resident.
>

---

From: <[email-masked]>
Date: Fri, 27 May 2011 17:14:51 -0400

Thanks John and Tony!  Those are great points.

What we can put in the charter is a review of the settings.  I think we may have what we need from a technical standpoint in RID, but would like to know if we are enabling enough options for flexibility for information exchanges.  If you want to provide feedback now, we can see if any changes are needed or not.  RID is just at the technical policy level and you would need to have another level for each organization to interpret the tags provided.  RID also calls out encryption capabilities (encrypt all or sections of an IODEF document), digital signatures (to prove where it came from), and lets you leave out content or anonymize it based on the organization or consortium's policy.  It does not have TLP specifically included, so that may be an addition.

The x.1500 CYBEX document Tony shared is one of the reasons I raised the question initially to find out the views on TLP, then PII/NPI was also raised.  In terms of fitting together all of the CYBEX pieces, I was trying to reconcile where TLP fits.  I think if it is needed, it goes with RIDPolicy.

Best regards,
Kathleen

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Friday, May 27, 2011 5:05 PM
To: John Howie
Cc: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

--tony

---

From: Brian Trammell <[email-masked]>
Date: Mon, 30 May 2011 10:02:29 +0200

Greetings, all, 

In PRISM (http://www.fp7-prism.eu, though the site seems down at the moment, I'm looking into it), we built knowledge of the jurisdiction, as well as the restrictions placed on data processing, sharing, and storage by that jurisdiction, into the access control system of an online network monitoring and measurement platform. As an EU project, we of course had to support compliance with 95/46/EC and 2006/24/EC. However, due to the somewhat labyrinthine way EU law works, the directives must then be implemented by national law. The national laws themselves have some latitude in how the directives are implemented. So while you could, for example, say "the data in this report contains no 95/46/EC PII, and should be retained for N days in accordance with 2006/24/EC", that _still_ doesn't mean you're compliant with data protection law in every one of the EU member states; other states, for example, could have more restrictive definitions of PII.

Add cross-border exchange with the US, and things get even sillier.

With respect to RIDPolicy, there's probably two ways to go here. One would be a big ontology effort to try and cover each of the conceivable aspects of each jurisdictions' and organizations' policies on transmission, retention, etc. Another would be to reference policies and jursidictions by name or codepoint within RIDPolicy, and require/trust the transmitter and recipient of a RID message to correctly label reports and to correctly handle reports WRT their labels. The latter is much easier to implement. The former would appear more flexible at first glance, but the details are very difficult to get right. 

We're trying to get around this mess with a follow-on project, DEMONS, http://www.fp7-demons.eu/, on which I'll write a longer message to this list later today or tomorrow. The problems we're solving are a bit different - sharing of monitoring data and results as opposed to reports, but we do plan to apply RID to interdomain cooperative incident mitigation...

Best regards,

Brian

---

From: <[email-masked]>
Date: Tue, 31 May 2011 07:49:15 -0500

I thought TLP was perfect for humans too, until I watched them use it in
exercises and then in real world sharing practices.
People can't even agree on what RED means - may be one case where the
abstraction layer/mnemonic that the colors ostensibly provide is
actually an obstacle to understanding the system.

BTW John, I missed majordomo yelling at me so your cross-list posting
didn't go through. Would you like me to sub you to the IDXWG as well?

 - Tom Millar, US-CERT

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Howie
Sent: Tuesday, May 24, 2011 10:56 AM
To: <[email-masked]>
Cc: <[email-masked]>; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi Pat,

For CloudSIRT (a Cloud Security Alliance initiative) we settled on the
four color TLP. I agree that the TLP is somewhat limited, but it is
perfect for use by humans. I would say that it is not appropriate for
automated systems, as it lacks many of the attributes that you have
observed codified into email messages and verbal instructions in an ad
hoc fashion. Additionally, automated systems are perfect for controlling
the dissemination of information through technologies such as DRM and
DLP, both which require the use of attributes or metadata to communicate
policy surrounding the information.

What this means is you need two systems - one for humans and one for
automated systems. There needs to be some parity between the systems,
and an easy conversion mechanism. For example, when I read a bulletin
from an automated system I want the policy attached to that information
translated into the TLP or equivalent system, and I want to be able to
easily select policy based on the TLP or equivalent when I create a
bulletin (in other words, I do not want to specify a number of
attributes I do not fully understand).

Regards,

John

Sent from my iPad.

On May 24, 2011, at 6:29 AM, <[email-masked]> wrote:

> Hi Pat,
> 
> Thanks for the response.  I actually asked what are the thoughts on
TLP, not necessarily saying that we should use it yet (that may the or
part of the answer).  The reason for this is to find out if TLP needed
to be integrated in the Policy layer of RID (RFC6045).  For me, it was
just to get an idea of what this list thought of TLP as I am starting to
see it come up in more places.  TLP was added to the ITU-T CYBEX
(x.1500) specification and I was trying to get a feel for where it fits
in.  It was also mentioned in the context of CloudSIRT and FS-ISAC.  RID
does account for consortiums or groups of users and where data passes as
part of the policy already, so the use case of one group versus
another's policy can already be factored in the  routing.
> 
> I copied the mile mailing list here as well.  The mile mailing list is
just getting started to figure out what may need to be extended and
won't initially be focused on this problem, but more on extensions that
need to be standardized for IODEF and how to make IODEF communications
easier to understand, etc.  The scope may need to include some
adjustments to RID and it would be good to get a handle on that as well
in the long run.
> TLP is the 'traffic light protocol', which uses three colours to 
> specify the sharing rules to the received party. So one gets three 
> ways to express how to share the data. IODEF has *four* ways, which I 
> can't get to work, and now you want me to use *three*? :(
> 
> In the TLP-enabled groups that I participate in, probably 50% of the 
> message pick a colour -- and then add a sentence or two explanation or

> additional info at the end. The 'additional info' makes automatically 
> processing the data kind of hard. So I've been watching what people 
> put in that extra data and expanded the set of three colors to six or 
> seven. Note that there is no reason for another group (e.g., 'fs-isac'

> or 'Kathleen's-group') to not specify THEIR rules as red, yellow and 
> green. And maybe 'white', too (but I don't see many traffic lights 
> with that color. :) ) The goal is to let a sharing group decide the 
> processing rules instead of trying to smush them all into three or 
> four colors/levels/extensions. Although this makes the sharing-rules 
> universal more complex, I'm guessing that DHS' red is different from 
> fs-isac's red which is surely different than apwg's red, so keeping it
simple might also lead to confusion.
> 
> We also need some extra attributes for our data. For example, is there

> an embargo date, or can the data be shared with another group or LEAs.

> These attributes are hard to show in both the current IODEF markings 
> and the TLP system. But if we make the sharing rules a sequence of 
> groups with attributes one can cover all these odd cases quite easily.
> 
> Note that I do not expect everyone to follow my idea. I am aware that 
> a handful of groups are trying to solve the same set of problems and 
> it would be good if we all understood what the other guys were doing 
> (since we're probably gonna exchange data at some point).
> 
> Pat Cain
> 
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 31 May 2011 09:00:36 -0400

Interesting, thanks.  I am reading through the PolicyRegion section of RID again and think it is covering the same idea as TLP where it states the expected boundaries of an incident to be shared.  It is not quite the same and doesn't use the color scheme, but that could be mapped out in a product interface if needed.

In terms of scope for this pre-WG charter to see if anything does need to be changed here, those interested in TLP support could you read through RID's Policy region description and see if a mapping in a software interface will suffice?  This would prevent the need to change the protocol and I think the same capabilities are present.  The way it is now may be more straightforward to hit on Tom's point below.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2011 8:49 AM
To: [email-masked]; Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] contemplating data sharing restrictions/markings

 - Tom Millar, US-CERT

-----Original Message-----

Hi Pat,

Regards,

John

Sent from my iPad.

---

From: <[email-masked]>
Date: Tue, 31 May 2011 09:10:35 -0400

Hi Gaus,

Right now, we have IODEF, extensions to IODEF, and then RID for communication of IODEF documents with their extensions.  If the TLP should stay in the IODEF document, they could be in an extension to IODEF.  However, if it is used only during the communication process, it should be in RID.  Now, we could have products map from TLP to the RID PolicyRegion or represent both (that may be redundant, but I am interested to hear if others agree or disagree on that point).

RID is also extensible.  I think if we were to map in TLP, it is not complex, so it probably should be right in RID.  This may be an option for other possible extensions.

If TLP were separate, where do you see it fitting in?  RID would need to wrap both IODEF and a TLP schema.

RID[TLP, IODEF, IODEF ext.]

Thanks,
Kathleen

-----Original Message-----
From: Damir Rajnovic [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2011 8:49 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi,

Sorry for being Gaus come late but I am on the road which took its tool.

Just one point, instead of incorporating TLP (or similar) into RID how
about making it a separate document. To make TLP (or similar) a standalone
schema so that it can be reused in multiple places independantly from
RID.

Thanks,

Gaus

> > probably gonna exchange data at some point).

==============
Damir Rajnovic <[email-masked]>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution? 

http://www.ciscopress.com/bookstore/product.asp?isbn=1587052644

- - - -
Cisco.com - http://www.cisco.com/global/UK

This e-mail may contain confidential and privileged material for the sole 
use of the intended recipient. Any review, use, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or 
authorized to receive for the recipient), please contact the sender by reply 
e-mail and delete all copies of this message.

Cisco Systems Limited (Company Number: 02558939), is registered in England 
and Wales with its registered office at 1 Callaghan Square, Cardiff, 
South Glamorgan CF10 5BT

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Damir Rajnovic <[email-masked]>
Date: Tue, 31 May 2011 13:49:13 +0100

Hi,

Thanks,

Gaus

==============

- - - -

---

From: <[email-masked]>
Date: Tue, 31 May 2011 09:31:27 -0400

Hello,

Thanks for the additional insight.  

I am wondering is a third option would be suitable.  Enterprises typically rely on their legal counsel and compliance officers to interpret regulations and the interpretations vary from one organization to another.  As you point out, PII cross-borders is concerned not only with transport, but storage and processing.  Regulations also change periodically, which complicates any static markers further (name of regulations or their specific requirements).

The set of applicable regulations may differ as the data moves, as may the requirements.  

A third option may be to have an extension to IODEF that lists data type (PII/NPI, PCI, etc.) and the origin of that data using the country codes.  It would be up the sending/receiving and processing systems to handle according to the appropriate regulations and interpretation of those regulations.  This would mean that applications would have to be aware of their policies for the organization and the applications would need to be able to act on the policy.

The managing application could use the information to set the RID PolicyRegion and the XML digital signature and encryption functions on the data as appropriate.  RID already specifies various ways the IODEF and RID data can be encrypted (fully or sections of a document).

I am open to see if RID needs to be changed, but also want to figure out if we just need to provide use case guidance.  Or if the changes are better handled in other places like an IODEF extension since we need the marker for processing and storage?

It was mentioned several times that additional use case guidance is needed for IODEF.  I know we have at least one volunteer who is interested to write up some guidance for a specific use case from the ITU-T CYBEX project (Yuri).

Any thoughts?

Thanks!
Kathleen

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Monday, May 30, 2011 4:02 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Greetings, all, 

Best regards,

Brian

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 31 May 2011 09:58:33 -0400

Hi Kathleen,

The exchange of this information is similar to another effort
that has occurred in the identity management arena - namely
exchanging assurance information.  Indeed, the two are arguably
intertwined.

Because so much of the IdM work is being driven by EU
initiatives, the EC tasked ENISA to produce a specification
that articulated an ontology for assurance and an associated
schema for exchanging that information.

For the past two years in the CYBEX work, we've been
searching for something equivalent for cybersecurity
information exchange - without luck - although there have
been occasional rumors that the US DOD produced a
classified spec of this nature.  This of course highlights
a related problem - whether it is possible to have interoperability
with schema within highly compartmentalized communities.

As a first order attempt to deal with this subject, it would
be useful to ferret out any attempts at an ontology - perhaps
by Japan's NICT organization.

--tony

---

From: <[email-masked]>
Date: Tue, 31 May 2011 10:10:52 -0400

Hi Tony,

Thank you!  Brian, are you or colleagues involved in the EU effort that Tony mentions?  If anyone on the list can provide details, that would be helpful.

Folks from Japan (or other countries) on the list, are you aware of any efforts?

Then, in terms of charter discussions for this group, if an extension is needed, would it be better to have this to IODEF rather than RID so it stays with the document?  The considerations (that I can come up with quickly - there may be others) would be that the information may be encrypted for the recipient, so it would not necessarily be accessible at the RID layer if it were nested into an IODEF extension, but would be included in the incident for processing and storage.  RID security and privacy options could be used and decisions made on the information if it were in either location.

It would be good to see how others are handling this use case as Tony points out by reviewing their ontology efforts.  My preference would be for something flexible that can live a long time and possibly handle use cases we have not encountered yet.

Thanks,
Kathleen

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2011 9:59 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi Kathleen,

--tony

---

From: Brian Trammell <[email-masked]>
Date: Tue, 31 May 2011 16:55:53 +0200

Hi, Kathleen, all,

Indeed, since it is the _data_ in IODEF that carries handling restrictions, and not the semantics of what to do with it (RID), placing the restriction markings on IODEF directly would seem to make more sense. Care would need to be taken to ensure consistency between IODEF handling markings and RIDPolicy, which probably requires update to RID anyway, at least to provide such guidance.

Technically speaking, this should probably be an element with reference to polic(y|ies) via name in some defined namespace, and/or a URL to a document containing an authoritative human-readable reference on the policy.

Best regards,

Brian

---

From: <[email-masked]>
Date: Tue, 31 May 2011 15:52:26 -0400

Hi,

Does everyone agree with the approach of having markers in an IODEF extension for this use case?  One of the other use cases mentioned was TLP, with a possible answer of mapping it to RID PolicyRegion.  Catherine also brought up classification markings for the government, could that be an IODEF extension (or several of these in the same extension)?

Do folks agree or should we be looking at changes to RID in scope?  I'd like to see if there is consensus as we work toward a charter.

Thank you!
Kathleen

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2011 10:56 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi, Kathleen, all,

Best regards,

Brian

---

From: <[email-masked]>
Date: Tue, 31 May 2011 17:03:22 -0500

I knew I remembered reading something that seemed pertinent to all this:

http://tcipg.org/publications?tag=291 (various publications tagged
"trust negotiation")

I don't know Winslett or Lee, but their problem space seems very similar
to that under discussion.

I would really be interested to see if Pat's attribute-based approach is
achievable using some of the proof of concept technologies discussed in
their work at the above link. Clouseau, from "towards an efficient and
language-agnostic compliance checker etc" seems like it could achieve
some if not all of the checks that would be necessary.

At that point, it isn't about broad strokes as much as it is ensuring
your constituency/partners all agree on whatever certificate or token
scheme you employ as "proofs" that a user fits the mold you identify as
privileged or trusted.

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, May 31, 2011 10:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

Hi Tony,

Thank you!  Brian, are you or colleagues involved in the EU effort that
Tony mentions?  If anyone on the list can provide details, that would be
helpful.

Folks from Japan (or other countries) on the list, are you aware of any
efforts?

Then, in terms of charter discussions for this group, if an extension is
needed, would it be better to have this to IODEF rather than RID so it
stays with the document?  The considerations (that I can come up with
quickly - there may be others) would be that the information may be
encrypted for the recipient, so it would not necessarily be accessible
at the RID layer if it were nested into an IODEF extension, but would be
included in the incident for processing and storage.  RID security and
privacy options could be used and decisions made on the information if
it were in either location.

It would be good to see how others are handling this use case as Tony
points out by reviewing their ontology efforts.  My preference would be
for something flexible that can live a long time and possibly handle use
cases we have not encountered yet.

Thanks,
Kathleen

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]]
Sent: Tuesday, May 31, 2011 9:59 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked];
[email-masked]

Hi Kathleen,

The exchange of this information is similar to another effort that has
occurred in the identity management arena - namely exchanging assurance
information.  Indeed, the two are arguably intertwined.

Because so much of the IdM work is being driven by EU initiatives, the
EC tasked ENISA to produce a specification that articulated an ontology
for assurance and an associated schema for exchanging that information.

For the past two years in the CYBEX work, we've been searching for
something equivalent for cybersecurity information exchange - without
luck - although there have been occasional rumors that the US DOD
produced a classified spec of this nature.  This of course highlights a
related problem - whether it is possible to have interoperability with
schema within highly compartmentalized communities.

As a first order attempt to deal with this subject, it would be useful
to ferret out any attempts at an ontology - perhaps by Japan's NICT
organization.

--tony

On 5/31/2011 9:31 AM, [email-masked] wrote:
> The managing application could use the information to set the RID
PolicyRegion and the XML digital signature and encryption functions on
the data as appropriate.  RID already specifies various ways the IODEF
and RID data can be encrypted (fully or sections of a document).
>
> I am open to see if RID needs to be changed, but also want to figure
out if we just need to provide use case guidance.  Or if the changes are
better handled in other places like an IODEF extension since we need the
marker for processing and storage?
>
> It was mentioned several times that additional use case guidance is
needed for IODEF.  I know we have at least one volunteer who is
interested to write up some guidance for a specific use case from the
ITU-T CYBEX project (Yuri).

---

From: Gabriel Iovino <[email-masked]>
Date: Tue, 31 May 2011 21:47:29 -0400

On 5/31/2011 6:03 PM, [email-masked] wrote:
> achievable 

+1

What Pat described is very similar to what we have discussed trying to
implement within the REN-ISAC community so we can better share
information outside of the REN-ISAC membership.

I would like to highlight two potentially different sets of data we may
be trying to share:

1. Identified miscreant infrastruture (e.g. C&C's, Phishing URLs,
Malware download infrastructure, etc)

2. PII data (e.g. CC #s, SS #s, username/password, etc)

The REN-ISAC community shares miscreant infrastructure for the purpose
of operational protection and response without much concern with
breaking information disclosure laws and regulation as I am not aware of
anything that says you cannot share an identified malicious C&C.

(note: I am not well versed in EU laws)

On the other hand, we do not share PII data on a regular basis as there
are laws and regulations that need to be taken into consideration AND I
am not sure how much operational protection value this data has.

(of course one would like to tell the account owner/holder they have had
a breach but I view this differently than sharing miscreant infrastructure)

There may be value in trying to come up with some agreed upon
nomenclature to share PII data but I would hate to see us fail on this
endeavor due to the complexities of PII when in reality a lot of us want
and need to share miscreant infrastructure data sets.

> it isn't about broad strokes as much as it is ensuring

+1

Gabe

- --
Gabriel Iovino
Principal Security Engineer, REN-ISAC
http://www.ren-isac.net
24x7 Watch Desk +1(317)278-6630