johnwunder

Sightings and Observations Options

Option 1: Current Approach (Sighting as special relationship)

In the current approach (consensus at the DC3 F2F), sighting is essentially just a special relationship between observation and indicator (or, other object types that can be sighted). Thus, it doesn't have many data fields itself other than those just to link things between observations.

Pros and Cons

• Has a sighting object and an observation object: Kind of a pro because people talk about these things, kind of a con because other people get confused by the distinction
• count/start/end only on observation, so you don't have to deal with it in two places, or figure out how to handle inconsistencies

johnwunder

What are our design goals?

Simple things should be simple, complicated things should be complicated. For translations, to me that means:

• Single language (any language, not just English) content should be as easy as possible
• Representing multiple translations for content should be as easy as possible, in particular for common use cases.
• Enable edge cases and more complicated things via extensions/custom properties
• Let things that can be done by implementations be done by implementations. Don't design more in the specification than what needs to be there.

Given those goals, I have two thoughts on the existing proposals. First, the hash-based approach may not be necessary. Second, if it is the best solution, using a single-key map to represent the language for an individual field is probably not the best approach (see second file).

johnwunder

{
  "type": "package",
  "id": "package--67d45a1e-5e50-49e6-abee-863863b9e313",
  "spec_version": "2.0",
  "created_at": "2016-02-17T12:31:12Z",
  "created_by_ref": "identity--444ab458-1808-43bf-ba2f-2f2cdf880689",
  "reports": [
    {
      "type": "report",
      "id": "report--4ab5867b-85e4-4314-b58f-d54e3bd66bd6",

johnwunder

{
  "type": "package",
  "id": "package--44af6c39-c09b-49c5-9de2-394224b04982",
  "sources": [
    {
      "type": "information-source",
      "id": "information-source--8ae20dde-83d4-4218-88fd-41ef0dabf9d1",
      "name": "mitre.org"
    },
    {

johnwunder

{
  "type": "package",
  "id": "package--7342007e-2b76-4a08-a5db-33b09089b602",
  "sources": [
    {
      "type": "information-source",
      "id": "information-source--8ae20dde-83d4-4218-88fd-41ef0dabf9d1",
      "name": "mitre.org"
    }
  ],

johnwunder

[
  {
    "id": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d",
    "type": "report",
    "lang": "en",
    "created_at": "2016-01-29T21:18:33Z",
    "title": "Hi, this text is in English",
    "description": "So is this"
  },
  {

johnwunder

[
  {
    "foobar": "value-from-default"
  },
  {
    "foobar": "value-from-default",
    "foobar_ext": {
      "value": "value-not-in-default-but-kinda-maps",
      "vocab_name": "my-custom-vocab"
    }

johnwunder

Suggestion

[object-type]:[UUID]

Why

• UUID is very unique. "In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%."
• There are some concerns about using poor entropy, in particular generated from different types of systems

johnwunder

{
  "type": "relationship",
  "id": "example.com:relationship:7bc8d066-acc2-4bfb-bc08-acbeb0f52c6b",
  "producer_ref": "example.com:information-source:example",
  "created_at": "2014-05-08T09:00:00.000000+00:00",
  "source_ref": "example.com:incident:dd955e08-16d0-6f08-5064-50d9e7a3104d",
  "target_ref": "example.com:asset:a0777daa-84bf-41e7-89a2-30d7ebb8018d",
  "extended_properties": [
    {
      "type": "incident-impact-extension",

johnwunder

IP Watchlist Use Case Profile

This use case profile describes how one organization can share an IP watchlist (list of IPs that may be malicious) with another organization via a list of STIX indicators. It does not describe how to return sightings or provide feedback on the indicators.

Version: 0.1draft
ID: ipwatchlist
STIX Version: 2.0
TAXII Version: 2.0