Feature Request: Allow specification of Timestamp Precision

[packet-rat]

Allow specification of Timestamp Precision for generated sightings, observered_data, etc. where assertion on the actual time of the event are made.

[StephenOTT]

Great idea💡

[StephenOTT]

@packet-rat I would like to get a bit more info about the needs.

Is the goal here to have greater precision? Or to have timestamps with 1 and 2 digits for sub-second precision ?

such as .1Z, .10Z, and .100Z ?

[packet-rat]

I can provide some real world use cases/scenarios:

(1) We are tracking Adversary attacks across a wide set of companies in a "Community of Trust" for a given sector. We are analyzing target lists, the sequencing of attack messages, etc.

Companies in this "Community of Trust" share real time logging data. Did adversary attack company A, followed by Company B, etc.
How much delay between individual messages, blocks of messages? Did adversary attack across all companies in a sector concurrently? If so what was the individual targeting pattern? For Attack Tool foot printing: what was the timing of attack messages? For Adversary identification what are the temporal patterns of there attacks across a given sector, multiple sectors, etc.

(2) We are tracking Adversary command and control traffic across multiple high speed Internet Egress points to multiple destinations.

Currently scenarios both require microsecond granularity/precision.

Full realization pre-supposses some of the other wish list items for generating specific "real world" events. For now, temporal consistency and timestamp precision for generated data sets allows testing of causality/correlation algorithms.

[StephenOTT]

Okay I understand the use case. But what is the precision implementation you need to support? You want to generate sample data with timestamps that are close together based on granularity?

You want subsecond precision beyond 3 digits?

Can you give me a few timestamp examples of the differences in precision you want to generate?

[StephenOTT]

@packet-rat support for this in inbound.

The STIX-Java library has a pending update for release that will provide nano-second precision date support. This be released soon in next few days

[StephenOTT]

https://github.com/StephenOTT/STIX-Java/pull/94

[StephenOTT]

@packet-rat would you expect to want/need to set precisions on a per field basis? Or more of a global precision?

Example if a object has three date fields, would you just want to set "9 digits of precision", or would you want to set precisions for each field?

[packet-rat]

In practice only certain types of fields require sub-millisecond precision. So one would not generally want to clutter up all timestamps. I think some of this will ultimately be driven by the current "discourse" in the CTI TC community.

I'm going through your code as time permits to figure out* "where the knobs are". If I need to generate timestamps with sub-nansecond precision is this the only module that needs changing:

src/main/java/io/digitalstate/stix/helpers/StixDataFormats.java https://github.com/StephenOTT/STIX-Java/commit/cb5f6c1083f58d997324d4c7888fc101ecec39fd#diff-e9bdf0609c89eb5ba1cdd1fc95886951

• Note: I am a neophyte with Java.

Pat Maroney

On Apr 26, 2019, at 6:01 PM, Stephen Russett notifications@github.com wrote:

@packet-rat https://github.com/packet-rat would you expect to want/need to set precisions on a per field basis? Or more of a global precision?

Example if a object has three date fields, would you just want to set "9 digits of precision", or would you want to set precisions for each field?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/StephenOTT/STIX-Faker/issues/9#issuecomment-487214717, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYSFYI364DRJGFCFJNMU4DPSN3SBANCNFSM4HGAOFPA.

[StephenOTT]

So my iteration 1 plan would be:

Make observables configurable with a lower date (what is the oldest date), and make each date field of each observable configurable for precision (number of digits).

So in the rest api, you will provide a probably query params where you can configure each fieldname with digit counts.

Likely will also convert this to supporting a Json body so eventually all fields can be configured in different ways.

The patch that was merged yesterday into STIX-Java now supports fully configurable date precision. So just need to update Faker with this support to provide configs into the date generators.

[StephenOTT]

https://github.com/StephenOTT/STIX-Java/pull/94

https://github.com/StephenOTT/STIX-Java/blob/master/src/test/groovy/stix/stixinstant/StixInstantSpec.groovy

[StephenOTT]

@packet-rat check out the first iteration of support for configurable data generation

https://github.com/StephenOTT/STIX-Faker/tree/0.8.0#observed-data

use the 0.8.0 release.

See the https://github.com/StephenOTT/STIX-Faker/blob/master/src/main/groovy/io/digitalstate/stix/faker/configs/ObservedDataGeneratorConfig.groovy for other configuration fields

[packet-rat]

Hard to keep up with you Stephen! Thanks for everything.:

Can we add a way to specify earliest_time and latest_time to bind the range of the temporally consistent timestamps?

Pat Maroney

[StephenOTT]

@packet-rat you will have to adjust the various date fields to support the times you want.

Each date field is a Instant. So it will support a ISO 8601 String such as 2019-01-01T12:00:00.000Z

See the https://github.com/StephenOTT/STIX-Faker/blob/master/src/main/groovy/io/digitalstate/stix/faker/configs/ObservedDataGeneratorConfig.groovy for the various instant fields.

as a example:

{
    "propCreatedLowerDate": "2019-01-01T12:00:00.000Z",
    "propCreatedUpperDate": "2019-01-02T12:00:00.000Z",
    "propCreatedProbability": 100,
    "propFirstObservedSubsecondPrecision": 9,
    "propLastObservedSubsecondPrecision": 6,
    "macAddressCoo": {
        "occurrence_probability": 100,
        "occurs_count_lower": 99,
        "occurs_count_upper": 100
    }
}

Like what you want to be editing is a combination of:

1. propCreatedLowerDate
2. propCreatedUpperDate
3. propFirstObservedLowerDate
4. propFirstObservedUpperDate
5. propFirstObservedSubsecondPrecision
6. propLastObservedUpperDate
7. propLastObservedSubsecondPrecision

Note: The Lower Date on Last Observed is automatically set for you (the last observed LOWER is the First Observed date.

[packet-rat]

Thanks for showing me the Knobs!

Patrick Maroney Chief Architect CyberIntel-LD Initiative Email: doc@cyberintel-ld.com Cell: (609)841-5104

On Apr 30, 2019, at 5:27 PM, Stephen Russett notifications@github.com wrote:

@packet-rat you will have to adjust the various date fields to support the times you want.

Each date field is a Instant. So it will support a ISO 8601 String such as 2019-01-01T12:00:00.000Z

See the https://github.com/StephenOTT/STIX-Faker/blob/master/src/main/groovy/io/digitalstate/stix/faker/configs/ObservedDataGeneratorConfig.groovy for the various instant fields.

as a example:

{ "propCreatedLowerDate": "2019-01-01T12:00:00.000Z", "propCreatedUpperDate": "2019-01-02T12:00:00.000Z", "propCreatedProbability": 100, "propFirstObservedSubsecondPrecision": 9, "propLastObservedSubsecondPrecision": 6, "macAddressCoo": { "occurrence_probability": 100, "occurs_count_lower": 99, "occurs_count_upper": 100 } } Like what you want to be editing is a combination of:

propCreatedLowerDate propCreatedUpperDate propFirstObservedLowerDate propFirstObservedUpperDate propFirstObservedSubsecondPrecision propLastObservedUpperDate propLastObservedSubsecondPrecision Note: The Lower Date on Last Observed is automatically set for you (the last observed LOWER is the First Observed date.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[StephenOTT]

Let me know how it works out

[StephenOTT]

@packet-rat, was just thinking about your use case you raised above: take a look at: https://github.com/StephenOTT/TAXII-springboot-bpmn. The ability to route decisions based on stix data would likely fit nicely with your analysis capabilities. So the analysis is done by your existing worker, and the decision flow and which analysis you want to conduct when / at which step, might be a good fit for you

[StephenOTT]

@packet-rat have you had a chance to test?

[packet-rat]

Sorry...changed jobs and I’ve been busy.

On May 30, 2019, at 8:18 PM, Stephen Russett notifications@github.com wrote:

@packet-rat have you had a chance to test?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.