{"id":16119567,"url":"https://github.com/stephenott/stix-java","last_synced_at":"2025-03-17T18:30:49.468Z","repository":{"id":43425695,"uuid":"157734309","full_name":"StephenOTT/STIX-Java","owner":"StephenOTT","description":"STIX 2.x Java Library","archived":false,"fork":false,"pushed_at":"2022-11-16T12:21:13.000Z","size":2376,"stargazers_count":29,"open_issues_count":48,"forks_count":13,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-02-28T03:22:48.818Z","etag":null,"topics":["cti","cyber-threat-intelligence","cybersecurity","intelligence","oasis","stix","stix2"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/StephenOTT.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-11-15T15:39:44.000Z","updated_at":"2024-11-13T23:51:52.000Z","dependencies_parsed_at":"2023-01-22T19:31:13.730Z","dependency_job_id":null,"html_url":"https://github.com/StephenOTT/STIX-Java","commit_stats":null,"previous_names":[],"tags_count":21,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StephenOTT%2FSTIX-Java","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StephenOTT%2FSTIX-Java/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StephenOTT%2FSTIX-Java/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StephenOTT%2FSTIX-Java/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/StephenOTT","download_url":"https://codeload.github.com/StephenOTT/STIX-Java/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243878439,"owners_count":20362432,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cti","cyber-threat-intelligence","cybersecurity","intelligence","oasis","stix","stix2"],"created_at":"2024-10-09T20:54:28.190Z","updated_at":"2025-03-17T18:30:49.009Z","avatar_url":"https://github.com/StephenOTT.png","language":"Java","readme":"# STIX 2.x Java library\n\n[![Build Status](https://travis-ci.org/StephenOTT/STIX-Java.svg?branch=master)](https://travis-ci.org/StephenOTT/STIX-Java)\n\nThe library aims to provide a flexible full implementation of [STIX 2.x](https://oasis-open.github.io/cti-documentation/resources#stix-20-specification).  \nThis means that a default implementation is provided that meets the STIX JSON specification and the core objects \nand properties are provided in such a way as you can easily override and extend any implementation detail to meet your \nvariation of the specification.\n\nDe/Serilization is provided with Jackson.\n\nCurrent Spec Target: **2.0**\n\n\n## Other Implementations\n\n### TAXII-springboot-bpmn\n\nTaxii server based on springboot and backed by bpmn automation.\nThis taxii server implements the this STIX-Java library. \n\nhttps://github.com/StephenOTT/TAXII-springboot-bpmn\n \n### stix2 (Gson based implementation)\n\nIf you are looking for a gson based implementation, [CS-AWARE](https://cs-aware.eu) provides a [gson based implementation of the Stix2 library](https://github.com/cs-aware/stix2).\n\n\n## Sub-Second Precision Support\n\nSTIX-Java supports zero to 9 digit nanosecond precision with any date that is parsed by STIX-Java.  \nThis means that while a date that was sourced/generated by the STIX-Java library will be at sub-second precision of 3 digits, \nif you are parsing JSON with greater precision, or you supply a custom Instant with greater precision for a specific field, \nSTIX-Java will support this and store the extra precision.\n\nGeneral rules to understand:\n\n1. By default, timestamps generated natively by the STIX-Java library will be be with 3 digits of sub-second precision (millisecond precision).\n1. Sub-second precision from 0 to 9 digits (9 digits its nano second precision: `hh:mm:ss.999999999`) is supported.  This means you can omit sub-seconds if you choose.\n1. The StixInstant.class supports a `toString()` method that will generate a STIX Spec Date with the original precision preserved\n1. Json parsing of JSON strings will support all of the above rules. \n\n\n-----\n\n## Java Usage\n\nExample unit test showing usage.\n\n```groovy\nimport io.digitalstate.stix.bundle.Bundle\nimport io.digitalstate.stix.bundle.BundleObject\nimport io.digitalstate.stix.bundle.BundleableObject\nimport io.digitalstate.stix.common.StixParsers\nimport io.digitalstate.stix.sdo.objects.AttackPattern\nimport io.digitalstate.stix.sdo.objects.Malware\nimport io.digitalstate.stix.sro.objects.Relationship\nimport spock.lang.Specification\n\nimport java.time.Instant\n\nclass BundleSpec extends Specification {\n\n    def \"Basic 'uses' Relationship object and addition to bundle\"(){\n        when: \"Create a Relationship with Attack Pattern and Malware\"\n\n        Relationship usesRel = Relationship.builder()\n                .relationshipType(\"uses\")\n                .created(Instant.now())\n                .sourceRef(AttackPattern.builder()\n                        .name(\"Some Attack Pattern 1\")\n                        .build())\n                .targetRef(Malware.builder()\n                        .name(\"dog\")\n                        .addLabels(\"worm\")\n                        .build())\n                .build()\n\n        then: \"print the JSON string version of the created relationship object\"\n        println usesRel.toJsonString()\n\n        then: \"parse the string back into a relationship object\"\n        BundleableObject parsedRelationship = StixParsers.parseObject(usesRel.toJsonString())\n        assert parsedRelationship instanceof Relationship\n\n        Relationship typedRelation = (Relationship)parsedRelationship\n\n        and: \"print the parsed relation\"\n        println typedRelation\n\n        then: \"ensure the original JSON matches the new JSON\"\n        assert usesRel.toJsonString() == typedRelation.toJsonString()\n\n        then: \"add the relationship into a bundle\"\n        Bundle bundle = Bundle.builder()\n                .addObjects(usesRel)\n                .build()\n\n        and: \"print the bundle json\"\n        println bundle.toJsonString()\n\n        then: \"parse json bundle back into object\"\n        BundleObject parsedBundle = StixParsers.parseBundle(bundle.toJsonString())\n        assert parsedBundle instanceof Bundle\n        Bundle typedBundle = (Bundle)parsedBundle\n\n        then: \"ensure original bundle and parsed bundles match in their json forms\"\n        assert bundle.toJsonString() == typedBundle.toJsonString()\n\n    }\n\n    def \"bundleable object parsing\"(){\n        when: \"setup parser and object\"\n        String attackPatternString = AttackPattern.builder()\n                                        .name(\"Some Attack Pattern 1\")\n                                        .build().toJsonString()\n\n        then: \"can parse the json back into a attack Pattern\"\n        BundleableObject parsedAttackPatternBo = StixParsers.parseObject(attackPatternString)\n        assert parsedAttackPatternBo instanceof AttackPattern\n\n        AttackPattern parsedAttackPattern = (AttackPattern)StixParsers.parseObject(attackPatternString)\n        println parsedAttackPattern.toJsonString()\n    }\n}\n```\n\n\n## JSON\n\n1. All objects (Bundles, SDO, SRO, and Marking Definitions; anything that is a \"bundleable object\" + bundle) are able \nto be individually converted into their json equivalent.\n\n1. All objects (Bundles, SDO, SRO, and Marking Definitions; anything that is a \"bundleable object\" + bundle) can be \nindividually parsed from Json into a object.\n\n1. Object references within out objects (for example a \"object_markings\" property), will create \"dehydrated\" objects \nwhen parsing from json into objects.  This means that the object will detect the \"type\" based on the Id value, \nextract the type, and create a object of the specified type with the \"hydrated\" attribute marked as false.\n\n\n\n## STIX Marking Definitions and Granular Markings Data Redaction\n\nThis library implements a redaction feature to support JSON redaction during serialization. \nThis feature allows the execution of Marking Definitions (`object_marking_refs`) and Granular Markings (`granular_marking_refs`). \n\nCurrent execution rules:\n\n1. Object Markings Refs are executed as a \"Entire Object\" rule.\n1. Granular Markings are executed as \"property value masks\" and \"property removal\".\n1. Properties that are \"required\" (Minimum properties needed to init the specific object) are Redacted using a mask.\n1. Properties that are \"optional\" (Properties that are not required to init the specific object) are Redacted using property removal.\n1. UNDER REVIEW: Nested objects cannot be redacted within the nested object.  They must be redacted at the parent object level using the property in the parent that holds the child object.  \n\nMarking Definitions and Granular Markings are enforced through a \"Subject\" security pattern: A Subject is defined at the \ntime of serialization of a Bundle or bundleable object.\nA subject is characteristics about a subject that define the security rules.  In STIX's  most basic form a subject has a \nlist of \"Object Markings\" (TLP and Statements).  This markings are used as the Subject's context to define what markings \nthe subject \"has\" at the time of serialization.  \n\nWhen serialization occurs a the Subject's context \n(a set of object markings) are passed into the serialization process.  For each item in `object_marking_refs` and \n`granular_marking_refs`, the Subject's context is used for evaluation.  If the subject does not have all of the required \nObject Markings, then redaction is actioned.  \n\n`object_marking_refs` are executed first, and if the subject is denied, \nthen granular markings will be ignored, and the entire object will be redacted (removed and returned as `{}`).  \nIn the case of a serialization of a Bundle, a redacted object would result in it be omitted from the \nBundle's `objects` array. \n\nIf the subject passes all `object_marking_refs` validation, then `granular_marking_refs` are validated.  \nFor each Granular Marking object, the Object Marking is validated, and if denied, the Granular Marking's Selectors \nare actioned for redaction.  Once all `granular_marking_refs` objects have been processed, then resulting object is returned.\n\n\nConsider the following example:\n\n```groovy\nTlp tlp = Tlp.builder().tlp(\"red\").build()\nMarkingDefinition markingDefinition = MarkingDefinition.builder()\n        .definition(tlp)\n        .definitionType(\"tlp\")\n        .build()\n\nGranularMarking granularMarking = GranularMarking.builder()\n        .markingRef(markingDefinition)\n        .addSelectors(\"granular_markings\", \"created_by_ref\")\n        .addSelectors(\"created\")\n        .build()\n\nAttackPattern attackPattern = AttackPattern.builder()\n        .name(\"some Attack Pattern\")\n        .addGranularMarkings(granularMarking)\n        .createdByRef(Identity.builder()\n            .name(\"some Identity\")\n            .identityClass(\"individual\")\n            .build())\n        .build()\n```\n\nThe above serialized with a Subject context that only contains a TLP=White Object Marking would result in the following JSON:\n\n```json\n{\n  \"type\": \"bundle\",\n  \"id\": \"bundle--3d6bdcdd-2137-4e97-a8a4-8020dd30bc8d\",\n  \"spec_version\": \"2.0\",\n  \"objects\": [\n    {\n      \"type\": \"attack-pattern\",\n      \"id\": \"attack-pattern--0f4d3058-f4de-4743-ae4c-988645309d92\",\n      \"created_by_ref\": \"identity--__REDACTED__\",\n      \"created\": \"██REDACTED██\",\n      \"modified\": \"2018-12-19T20:49:06.403Z\",\n      \"revoked\": false,\n      \"name\": \"some Attack Pattern\"\n    }\n  ]\n}\n```\n\nThe internal implementation is configured as follows:\n\n```java\nclass SomeClass {\n//...\n    @JsonProperty(\"created_by_ref\") @JsonInclude(value = NON_EMPTY, content = NON_EMPTY)\n    @JsonIdentityInfo(generator= ObjectIdGenerators.PropertyGenerator.class, property=\"id\")\n    @JsonIdentityReference(alwaysAsId=true)\n    @JsonDeserialize(converter = DomainObjectOptionalConverter.class)\n    @Redactable(useMask = true, redactionMask = \"identity--__REDACTED__\")\n    Optional\u003cIdentitySdo\u003e getCreatedByRef();\n    \n    @NotNull\n    @JsonProperty(\"created\")\n    @Value.Default\n    @Redactable(useMask = true)\n    default Instant getCreated(){\n        return Instant.now();\n    }\n    \n    @NotNull\n    @JsonProperty(\"granular_markings\") @JsonInclude(NON_EMPTY)\n    @Redactable\n    Set\u003cGranularMarkingDm\u003e getGranularMarkings();\n//...\n}\n```\n\nNotice the varying usage of the `@Redactable` annotation.\n\nIf `object_marking_refs` were used and a bundle was generated with the Attack Pattern, the resulting bundle would contain:\n```json\n{\n  \"type\": \"bundle\",\n  \"id\": \"bundle--3d6bdcdd-2137-4e97-a8a4-8020dd30bc8d\",\n  \"spec_version\": \"2.0\",\n  \"objects\": []\n}\n```\n\n`objects` is empty because the Attack Pattern would have been redacted at the object level.\n\n\nFuture Improvements:\n\n1. Customizable redactions passed in based on the toJsonString() method and the Subject's context\n1. Config for Throwing errors when redactions cannot be processed\n1. Config for Ignoring errors when redactions cannot be process \n\n\n# STIX Graph Support / Network Graph\n\nThis feature is currently a active work in progress, and is subject to change.\n\nThis library provides the ability to generate cytoscape.js compliant json that can be imported into a cytoscape instance, and visualized.\n\n![stix-graph-example1](./docs/images/stix-graph-example1.png)\n\nThe above image shows a web-app that consumes a STIX Bundle, passes it to the STIX-Java libary through a HTTP-request, \nand the request returns the Cytoscape compliant json for Network graph rendering. \n\n## Example json output\n\nThis library will consume a STIX Bundle, and convert it into Cytoscape.js nodes/edges json, such as:\n\nOutput was generated from the [BundleGraphSpec](./src/test/groovy/stix/bundle/BundleGraphSpec.groovy)\n\n```json\n[\n  {\n    \"data\": {\n      \"id\": \"ref-89093428-585b-4754-8a6d-8cb0e6ca0a60\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"7ac69a4d-a984-4c19-a54b-13e3dd1d80e8--60cddb5b-9ea2-4855-82b7-f54eca297214\",\n      \"label\": \"ipv4-addr\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-8dca6278-645f-4737-9a56-f56c8cbb44a2\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"95a14320-0d63-4d97-9173-1994c2ed7b77--a3456ae7-cddb-45de-b366-d5b56b0c3ee0\",\n      \"label\": \"ipv4-addr\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-a076819b-1e6e-4d3d-822c-96f215444f23\",\n      \"type\": \"ref\",\n      \"source\": \"sighting--16103a5c-22e9-46ec-91bc-0ae521c60206\",\n      \"target\": \"attack-pattern--4acfe66e-587f-42e4-8daa-4d9da233f7c9\",\n      \"label\": \"sighting-of\",\n      \"ref_type\": \"sighting_of_ref\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-2f53e5f1-9897-45cd-a1ca-12671419a021\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"1366d1a7-ffef-4155-af4e-18cef6517502--c427ea06-8615-49ed-9701-d9e7c04c7aea\",\n      \"label\": \"ipv4-addr\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"c0bedd31-6d9f-48b7-afe5-762c13da69a3--8bbe16e2-8128-4cde-973f-15ac7d32aaa2\",\n      \"type\": \"coo-domain-name\",\n      \"stix\": {\n        \"type\": \"domain-name\",\n        \"value\": \"http://google.com\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-3901a3de-a38a-4bea-b784-3a08caef4c5f\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"f8647fdf-9011-4f7b-a240-462a20c1a29d--5f13f5fd-19f8-4e04-a53a-fd03dd54a1a2\",\n      \"label\": \"ipv4-addr\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"attack-pattern--cd482a80-3e47-4eed-9542-bbcf69da9405\",\n      \"type\": \"attack-pattern\",\n      \"stix\": {\n        \"type\": \"attack-pattern\",\n        \"id\": \"attack-pattern--cd482a80-3e47-4eed-9542-bbcf69da9405\",\n        \"created\": \"2019-06-05T22:49:29.813Z\",\n        \"modified\": \"2019-06-05T22:49:29.813Z\",\n        \"name\": \"attk2\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"sighting--16103a5c-22e9-46ec-91bc-0ae521c60206\",\n      \"type\": \"sighting\",\n      \"stix\": {\n        \"type\": \"sighting\",\n        \"id\": \"sighting--16103a5c-22e9-46ec-91bc-0ae521c60206\",\n        \"created\": \"2019-06-05T22:49:30.798Z\",\n        \"modified\": \"2019-06-05T22:49:30.798Z\",\n        \"first_seen\": \"2019-06-05T22:49:30.76Z\",\n        \"last_seen\": \"2019-06-05T22:49:30.788Z\",\n        \"count\": 1,\n        \"sighting_of_ref\": \"attack-pattern--4acfe66e-587f-42e4-8daa-4d9da233f7c9\",\n        \"observed_data_refs\": [\n          \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\"\n        ]\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"1366d1a7-ffef-4155-af4e-18cef6517502--c427ea06-8615-49ed-9701-d9e7c04c7aea\",\n      \"type\": \"coo-ipv4-addr\",\n      \"stix\": {\n        \"type\": \"ipv4-addr\",\n        \"value\": \"10.10.10.14\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-6b0818cf-9edf-4073-ade4-827df72de27a\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"c31c8cbf-7bd3-4865-8e89-7bbe1962d9af--34337862-99fd-46e0-a8c3-3fc7a774114e\",\n      \"label\": \"ipv4-addr\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"f8647fdf-9011-4f7b-a240-462a20c1a29d--5f13f5fd-19f8-4e04-a53a-fd03dd54a1a2\",\n      \"type\": \"coo-ipv4-addr\",\n      \"stix\": {\n        \"type\": \"ipv4-addr\",\n        \"value\": \"10.10.10.15\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"attack-pattern--4acfe66e-587f-42e4-8daa-4d9da233f7c9\",\n      \"type\": \"attack-pattern\",\n      \"stix\": {\n        \"id\": \"attack-pattern--4acfe66e-587f-42e4-8daa-4d9da233f7c9\",\n        \"type\": \"attack-pattern\",\n        \"created\": \"2019-06-05T22:49:28.455Z\",\n        \"modified\": \"2019-06-05T22:49:28.455Z\",\n        \"name\": \"attk1\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"relationship--70fca22d-4385-4194-a093-3a7cdb1a2a85\",\n      \"type\": \"relationship\",\n      \"source\": \"attack-pattern--4acfe66e-587f-42e4-8daa-4d9da233f7c9\",\n      \"target\": \"attack-pattern--cd482a80-3e47-4eed-9542-bbcf69da9405\",\n      \"stix\": {\n        \"type\": \"relationship\",\n        \"id\": \"relationship--70fca22d-4385-4194-a093-3a7cdb1a2a85\",\n        \"created\": \"2019-06-05T22:49:29.897Z\",\n        \"modified\": \"2019-06-05T22:49:29.897Z\",\n        \"relationship_type\": \"related-to\",\n        \"source_ref\": \"attack-pattern--4acfe66e-587f-42e4-8daa-4d9da233f7c9\",\n        \"target_ref\": \"attack-pattern--cd482a80-3e47-4eed-9542-bbcf69da9405\"\n      },\n      \"label\": \"related-to\",\n      \"relationship_type\": \"related-to\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"95a14320-0d63-4d97-9173-1994c2ed7b77--a3456ae7-cddb-45de-b366-d5b56b0c3ee0\",\n      \"type\": \"coo-ipv4-addr\",\n      \"stix\": {\n        \"type\": \"ipv4-addr\",\n        \"value\": \"10.10.10.11\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"type\": \"observed-data\",\n      \"stix\": {\n        \"id\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n        \"type\": \"observed-data\",\n        \"created\": \"2019-06-05T22:49:30.479Z\",\n        \"modified\": \"2019-06-05T22:49:30.479Z\",\n        \"first_observed\": \"2019-06-05T22:49:30.47Z\",\n        \"last_observed\": \"2019-06-05T22:49:30.472Z\",\n        \"number_observed\": 2,\n        \"objects\": {\n          \"c0bedd31-6d9f-48b7-afe5-762c13da69a3\": {\n            \"type\": \"domain-name\",\n            \"value\": \"http://google.com\"\n          },\n          \"7ac69a4d-a984-4c19-a54b-13e3dd1d80e8\": {\n            \"type\": \"ipv4-addr\",\n            \"value\": \"10.10.10.10\"\n          },\n          \"95a14320-0d63-4d97-9173-1994c2ed7b77\": {\n            \"type\": \"ipv4-addr\",\n            \"value\": \"10.10.10.11\"\n          },\n          \"c31c8cbf-7bd3-4865-8e89-7bbe1962d9af\": {\n            \"type\": \"ipv4-addr\",\n            \"value\": \"10.10.10.12\"\n          },\n          \"59d133cc-d29c-4056-aeeb-6791842c0b75\": {\n            \"type\": \"ipv4-addr\",\n            \"value\": \"10.10.10.13\"\n          },\n          \"1366d1a7-ffef-4155-af4e-18cef6517502\": {\n            \"type\": \"ipv4-addr\",\n            \"value\": \"10.10.10.14\"\n          },\n          \"f8647fdf-9011-4f7b-a240-462a20c1a29d\": {\n            \"type\": \"ipv4-addr\",\n            \"value\": \"10.10.10.15\"\n          }\n        }\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"59d133cc-d29c-4056-aeeb-6791842c0b75--c1efba8b-7ef4-4b12-a768-4b1d99d82eb7\",\n      \"type\": \"coo-ipv4-addr\",\n      \"stix\": {\n        \"type\": \"ipv4-addr\",\n        \"value\": \"10.10.10.13\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-029c8857-f9e0-49c6-bdaf-d3391acfbd61\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"59d133cc-d29c-4056-aeeb-6791842c0b75--c1efba8b-7ef4-4b12-a768-4b1d99d82eb7\",\n      \"label\": \"ipv4-addr\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"7ac69a4d-a984-4c19-a54b-13e3dd1d80e8--60cddb5b-9ea2-4855-82b7-f54eca297214\",\n      \"type\": \"coo-ipv4-addr\",\n      \"stix\": {\n        \"type\": \"ipv4-addr\",\n        \"value\": \"10.10.10.10\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"c31c8cbf-7bd3-4865-8e89-7bbe1962d9af--34337862-99fd-46e0-a8c3-3fc7a774114e\",\n      \"type\": \"coo-ipv4-addr\",\n      \"stix\": {\n        \"type\": \"ipv4-addr\",\n        \"value\": \"10.10.10.12\"\n      }\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-a8cfe6f7-6d73-4e38-9199-0919fd6c3b74\",\n      \"type\": \"ref\",\n      \"source\": \"sighting--16103a5c-22e9-46ec-91bc-0ae521c60206\",\n      \"target\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"label\": \"observed-data\",\n      \"ref_type\": \"observed_data\"\n    }\n  },\n  {\n    \"data\": {\n      \"id\": \"ref-0ef21e43-1451-4b0a-8f8e-866e01b91eb0\",\n      \"type\": \"ref\",\n      \"source\": \"observed-data--14ab5c4d-a696-483d-8792-f5686d61b2b4\",\n      \"target\": \"c0bedd31-6d9f-48b7-afe5-762c13da69a3--8bbe16e2-8128-4cde-973f-15ac7d32aaa2\",\n      \"label\": \"domain-name\",\n      \"ref_type\": \"cyber_observable\"\n    }\n  }\n]\n```\n\n\n\n\n# Charon Data Flow\n\n![Charon data flow](./docs/Diagrams/Generic-Data-Flow.png)\n\n# Workflow / BPM / BPMN\n\n## Example Process Usage\n\n![course of action processing 1](./docs/BPMN/course_of_action_1.png)\n\n![taxii collection updates](./docs/BPMN/taxii_collection_propagation.png)\n\n![process example 1](./docs/BPMN/sample_processes_1.png)\n\n![Report Review Process 1](./docs/BPMN/report_review.png)\n\n![Translation Process](./docs/BPMN/stix_data_translation.png)\n\n![Cyber Observable Processing](./docs/BPMN/cyber-observable-processing-1.png)\n\n-----\n\n# Raw notes\n\nThis project is a packaging of multiple components that will be split into individual projects at some point.\n\n1. A full [CTI STIX](https://oasis-open.github.io/cti-documentation/) (Structured Threat Information Expression Language) Java8 implementation. (`io.digitalstate.stix`).  The goal is for flexibility and reuse by other Java projects.\n1. Charon Application (\"Charon Server\"):\n    1. A SpringBoot based instance of [Camunda BPM](https://docs.camunda.org/manual/7.9/)\n    1. Possible: A [TAXII](https://oasis-open.github.io/cti-documentation/taxii/intro) server implemented in SpringBoot, tied to the Camunda BPM SpringBoot instance.\n    1. A bridge of CTI STIX with Camunda BPM BPMN Java-Delegates and Scripting Usage.\n    1. Possible: Mongo Spring Data Mapping from the STIX Java8 implementation to Mongo Documents.\n    1. Possible: Additional REST APIs in addition to the TAXII API that provide missing functionality that is available from using Camunda.\n    1. Monitoring of BPMN and STIX data usage with [Prometheus Camunda Plugin](https://github.com/StephenOTT/camunda-prometheus-process-engine-plugin) \n    \n\n**Overall Concept:** Enable organizations working with CTI and STIX to have the \"application\" \n(Charon) easily adapt to the organizations internal or standardized security processes.  \nAn organization should not have to change their security models for a \"vendor\".\n\nFurther Notes:\n\nBy Using STIX as a common language for CTI, automated and manual workflows can be created for multi-system use:\nWhere each CTI system can generate STIX data and the downstream workflows can process the CTI for whatever purpose \nwithout the need to understand the upstream CTI system (whether it be new and shinny, old and legacy, or \nsome customized CTI DB that has little understanding outside of the specific domain-usage).\n\nLeverage CTI's Who, Why, Where, How, What data to process data into meaningful automation and iterate as needed with the Charon engine.\nWhen you need manual intervention, with human eyes and hands, you can continue to leverage Charon to process those human tasks.\n\n - Process Information\n - Detection\n - Artifact storage and processing\n - Analyze\n - Respond\n \n \n Share CTI across the CTI network with the common exchange format, and enrich the data with STIX Data Enrichment from downstream enrichment processes.\n \n \"Automation Engine\" with OSS.\n \n Initiate Translation Services through the automation: When translation of CTI is required, it can be packaged as a \n STIX bundle and processed into a workflow for processing: automatically or with human intervention.\n\n\nShare Workflows (Shareable Workflows) across organizations and within the organization.  Allowing standardization regardless of the specific engine being used.\n\nMonitor and Track real-time events from your upstream incident response system, and process those events in STIX for \ndownstream CTI event processing by actors that may not have access or want access to the upstream incident response system.\n\nIntegration ML and AI at any point within the automation.  Do not tightly couple the ML and AI into the workflows: \nThis allows easy swapping of ML and AI technologies, products, and innovations as a underlying capability / \nforce multiplier without having to integration \"a whole other system\".\n\nEnable third-party organizations to deploy the same engine within your network, collect data, \nand stream it upstream to central CTI processors.  Enable the third-parties to implement their specific CTI processing \nprocesses directly in the engine without the need to \"conform to how the upstream system wants to do things\".\nThen when the upstream system receives the STIX CTI, it can be processed based on your knowledge of that third-party \nsystems processes: to which you can have transparency into with reviewing their \"processes\" defined in the engine.\n\nImplement organization HR conditions into the workflows: If someone does not response or review in X time, if someone is on holidays, etc\n\nPush out IOCs and Attack patterns to downstream consumers: Consumers can establish business rules that outline their \nsystems and networks, and as IOCs and APs are pushed, they can be evaluated automatically (and/or manually) \nby the downstream consumer system.\nSame can be applied to Abnormal Behaviour reporting or Pattern awareness.\n\nData Interruption reporting: Reporting in standard formats for org, and having to consume into STIX.\n\nUse the same engine to automate CTI testing and python scripts.  Engine can be wrapped up into a single JAR, including DB.\nCan be used as a CLI tool as well.\n\nMeasure the impacts of CTI and the various STIX data being received.\n\nUse the STIX stream as auditing trail capability: being able to collect STIX events and cross those \nevents based on aggregation, counts over period of time, etc. Then generate a Request for review based on the conditions.\n\nVery easy to tie in ML for Event data: Such as Kibana xPack reviewing the various types of \ndata and detecting new patterns such as counts and increases in periods or locations.\n\nRemove the problem of \"Lack of Time to implement processes\" (reported as 43% of the time).  \nChampions can create common processes to be easily and quickly adopted by downstream groups.\n\n\n\nExample Use Cases:\n1. STIX Bureaucracy Management using Charon.\n1. Security Approvals and Revocations for STIX data exposed through TAXII.\n1. Managing TAXII \"Hubs\" / Central Databases and the review, adjustements, and approvals of submissions of data into the Charon / STIX DB.\n1. Life-cycling STIX data through BPMN.\n1. Managing TAXII / STIX data access requests, apply-and-removal of STIXX markings.\n1. Multi-Department STIX Data Isolation with STIX data submission to UpStream STIX datasource.\n1. Execute automated and manual workflows based on STIX data events (CRUD events in STIX data). \n1. Concept of \"Shareable Workflows\":\n    1. Ability to share common business and technical workflows across a single organization and across many organiztions.\n    1. Ability to create Executable Workflows based on data events within STIX data.\n    ","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstephenott%2Fstix-java","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstephenott%2Fstix-java","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstephenott%2Fstix-java/lists"}