Re: [mile] [Issue #9] Mapping @restriction to TLP

Hi Jerome,

From a standards perspective, yes.  Three of the major national cyber controls frameworks use TLP for information release.  

This is different from access control policies, which are a separate-but-linked matter.  

regards,

Patrick

Patrick Curry
Director

British Business Federation Authority - BBFA Ltd
M: +44 786 024 9074
T:   +44 1980 620606
patrick.curry@federatedbusiness.org
www.federatedbusiness.org – a not-for-profit, self-regulating body   

On 29 Jul 2013, at 15:03, Jerome Athias <athiasjerome@gmail.com> wrote:

Hi,

It makes sense for me :)

(I will cross-post this to this STIX discution http://making-security-measurable.1364806.n2.nabble.com/STIX-Profiles-td7580626.html )

2013/7/29 Roman D. Danyliw <rdd@cert.org>
Hi!

See http://trac.tools.ietf.org/wg/mile/trac/ticket/9.

The @restriction attribute is currently defined as follows:

      1.  public.  There are no restrictions placed in the information.

      2.  need-to-know.  The information may be shared with other
          parties that are involved in the incident as determined by the
          recipient of this document (e.g., multiple victim sites can be
          informed of each other).

      3.  private.  The information may not be shared.

      4.  default.  The information can be shared according to an
          information disclosure policy pre-arranged by the
          communicating parties.

Would there be interest in migrating this definition to align with the Traffic Light Protocol originally developed by the UK National Infrastructure Security Coordination Centre, now Center for the Protection of National Infrastructure (http://www.cpni.gov.uk/)?  See the following:

US-CERT description, www.us-cert.gov/tlp

Wikipedia reference, http://en.wikipedia.org/wiki/Traffic_Light_Protocol

The current @restriction would require redefinition as the current 'need-to-know' does not map to a defined TLP category.  The proposal is to map as follows:

red   <--> private
amber <--> need-to-know
green <--> (new proposed value) partner
white <--> public

1.  public.  The information may be freely distributed without restriction.

2.  partner.  The information may be shared within a closed community of peers, partners, or affected parties, but cannot be published openly.

3.  need-to-know.  The information may be shared only with members of their own organization that have a need to know.

4.  private.  The information may not be shared.  It is intended only for the named recipients.

5.  default.  The information can be shared according to an information disclosure policy pre-arranged by the communicating parties.

6.  white.  Same as public.

7.  green.  Same as partner.

8.  amber.  Same as need-to-know.

9.  red.  Same as private.

The down-side of this proposal is that IODEFv2 (MILE) will have different semantics for an identical value present in IODEFv1 (INCH).  Any community or application accustomed to tagging data as @restriction="need-to-know" in v1 would now need to use @restriction="partner" or "green" otherwise the information will be restricted more than intended.  However, 'partner'/'green' might be too permissive depending on the definition of the consortium.

Roman
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile