OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cti-stix] Labels versus marking


Andras (and Alexandre) I’m leaning towards Bret’s marking approach and ending question to resolve this.

 

Question: If the option of marking is kept, how would we define the marking type in the standard? Can this be extended in the current proposal?

 

-Marlon

From: Andras Iklody [mailto:andras.iklody@gmail.com]
Sent: Wednesday, September 21, 2016 3:41 PM
To: Taylor, Marlon
Cc: Jason Keirstead; Alexandre Dulaunoy; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Labels versus marking

 

This makes sense, however, Alexandre's point is that it would be useful to have a way of assigning "human parse-able" yet somewhat standardise-able information to objects that a consumer can decide to display.

 

In an ideal situation, this would allow whoever creates information to label, preferably using freely definable and reference-able terms, along with an object that could be displayed to an analyst (if it is within the scope of the target system to display it).

 

We use tags and taxonomies in MISP extensively for this reason and it allows us to easily cater to the various needs of communities that want to describe and classify information using nomenclature that is common for their community (something that can vary drastically from community to community.

 

So what we would really need to be able to convey these tags and express them in a STIX way would be:

 

1. A way to tag/label objects, hopefully including cybox observables

2. A mechanism to reference (via a url) the source of the nomenclature used - for us that would be a taxonomy (this is of course optional, but would definitely a nice to have for other eco-systems)

3. We use a standardised approach at describing these tags using a triple-tag format (with the last component being optional). Whilst we found this to be the optimal format of keeping the structure simple yet being able to describe a lot of information, this is of course a nice to have and no big deal if it stays a complete free-text field. But maybe something to consider.

 

A small example of a few such triple tags from some taxonomies:

 

circl:topic="medical"

malware_classification:malware-category="Ransomware"

iep:permitted-actions="EXTERNALLY VISIBLE INDIRECT ACTIONS"

 

The format works like this: namespace:predicate="value", where namespace describes the language used and predicate and value are the key-value pair that describe the tag.

 

Hope we can find a way to express this in STIX so that the MISP communities out there won't have to omit this information when exchanging data via STIX.

 

Best regards,

Andras

 

On Wed, Sep 21, 2016 at 2:46 PM, Taylor, Marlon <Marlon.Taylor@hq.dhs.gov> wrote:

Jason I generally agree.

Marking is a formal method of conveying something to those that receive the data.

Labels are informal and might not be used or properly understood outside of the originating entity.

I won't recommend any automated processing, without much assurance, of labels on content received externally.

-Marlon

 


From: cti-stix@lists.oasis-open.org on behalf of Jason Keirstead
Sent: Wednesday, September 21, 2016 8:38:24 AM
To: Alexandre Dulaunoy
Cc: cti-stix@lists.oasis-open.org


Subject: Re: [cti-stix] Labels versus marking

 

My own naive view of labels vs markings is this...

Data markings are meant to enforce policy, either automated or manual.

Tags, on the other hand, are meant to facilitate analysis and searching.

If you are making the data to help an analyst understad what it is, and/or find it in a tool, use labels. If you are making the data to ensure that a tool or human treats it in a certain way when they recieve it, you would use a marking.

Is my view in alignment with the community? We probably need to figure out how to describe this in STIX...

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for Alexandre Dulaunoy ---09/21/2016 06:16:04 AM---On 21/09/16 00:36, Bret Jordan (CS) wrote: > Can you gAlexandre Dulaunoy ---09/21/2016 06:16:04 AM---On 21/09/16 00:36, Bret Jordan (CS) wrote: > Can you give some examples of what you are wanting to d

From: Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>
To: cti-stix@lists.oasis-open.org
Date: 09/21/2016 06:16 AM
Subject: Re: [cti-stix] Labels versus marking
Sent by: <cti-stix@lists.oasis-open.org>





On 21/09/16 00:36, Bret Jordan (CS) wrote:
> Can you give some examples of what you are wanting to do?  
>
> The current labels property is a way of tracking the old "malware type" for example.  It also allows products to add extra labels or tags to an object for use in their classifications.  I view this as means of mimicking Evernote's or GMail's labels.

Sure. We are currently evaluating the options to support properly the taxonomy in MISP
when doing STIX import and export. The two options are marking or labels. The main issue
for us is the labels being limited to some types only and you cannot do any granular marking.

Until now, the approach we want to take is the following:

{
 "type": "marking-definition",
 "id": "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da",
 "created": "2016-08-01T00:00:00Z",
 "modified": "2016-08-01T00:00:00Z",
 "version": 1,
 "definition_type": "misp-taxonomies",
 "definition": {
   "tag": "misp:confidence-level=\"usually-confident\""
 }
}


{
 "type": "marking-definition",
 "id": "marking-definition--78ad9b3b-8113-4454-a04e-7d433dadae07",
 "created": "2016-08-01T00:00:00Z",
 "modified": "2016-08-01T00:00:00Z",
 "version": 1,
 "definition_type": "misp-taxonomies",
 "definition": {
   "tag": "adversary:infrastructure-status=\"compromised\""
 }
}



"indicators": [
   {
     "type": "indicator",
     "id": "indicator--33fe3b22-0201-47cf-85d0-97c02164528d",
     "version": 1,
     "created": "2014-05-08T09:00:00.000000Z",
  "modified": "2014-05-08T09:00:00.000000Z",
     "name": "IP Address for known C2 channel",
     "labels": ["malicious-activity"],
     "object_marking_refs": ["marking-definition--78ad9b3b-8113-4454-a04e-7d433dadae07", "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da"]
     "pattern": "ipv4addr-object:value EQ '10.0.0.0'",
  "pattern_lang": "cybox",
  "valid_from": "2014-05-08T09:00:00.000000Z"
   }
]

and if you use label (but we won't be able to do marking where we want):

"indicators": [
   {
     "type": "indicator",
     "id": "indicator--33fe3b22-0201-47cf-85d0-97c02164528d",
     "version": 1,
     "created": "2014-05-08T09:00:00.000000Z",
  "modified": "2014-05-08T09:00:00.000000Z",
     "name": "IP Address for known C2 channel",
     "labels": ["adversary:infrastructure-status=\"compromised\"", "misp:confidence-level=\"usually-confident\""],
     "pattern": "ipv4addr-object:value EQ '10.0.0.0'",
  "pattern_lang": "cybox",
  "valid_from": "2014-05-08T09:00:00.000000Z"
   }
]

The other advantage of using the marking is to ensure that parser can support directly
the taxonomies with the type defined compared to labels where this can be a series
of various, tags or machine tags.

If the option of marking is kept, how would we define the marking type in the standard?
Can this be extended in the current proposal?

Cheers

--
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
info@circl.lu - www.circl.lu

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]