johnwunder

{
  "type": "bundle",
  "kill_chains": [
    {
      "type": "kill-chain",
      "id": "kill-chain--47cbe0e4-c4f6-4e0f-a67e-1851168c492b",
      "spec_version": "2.0",
      "created_time": "2016-05-27T15:35:07Z",
      "modified_time": "2016-05-27T15:35:07Z",
      "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

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

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

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

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