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

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
>