Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems creating Attack Patterns via send_stix2_bundle #1141

Closed
jbfeldman opened this issue Mar 8, 2021 · 1 comment
Closed

Problems creating Attack Patterns via send_stix2_bundle #1141

jbfeldman opened this issue Mar 8, 2021 · 1 comment
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@jbfeldman
Copy link

Description

I'm using a home-built enrichment connector that calls an external commercial API, converts the output to STIX2, and sends it back to OpenCTI. The Connector successfully imports Indicators and Notes into OpenCTI. However, I am unable to successfully create Attack Patterns using the send_stix2_bundle call in my custom connector. An indicator should be connected to multiple different attack patterns imported from the connector. However, the Indicators are only connected to a single attack pattern. Clicking into that attack pattern, it looks like for some reason all of the newly created attack patterns are now aliases of this single attack pattern.

This connector had worked with previous versions of OpenCTI (pre 4.2.x I think)

Environment

  1. OS: Ubuntu 18.04 LTS, but OpenCTi is running in Docker
  2. OpenCTI version: 4.2.4
  3. OpenCTI client: error is in pycti, observed in the UI
  4. Other environment details:

Reproducible Steps

Install and run the connector.
Enrich an indicator

Expected Output

Multiple attack patterns. Something like this (from an older version of OpenCTI where this worked as expected)

indic_with_ttps

Actual Output

Only a single linked Attack Pattern

indic_one_ttp

And that Attack Pattern has aliases of all of the other attack patterns (and a ton of STIX IDs)

attack-pattern-many-aliases

Additional information

This is the snippet of python code that generates the attack patterns.

` objects = [indicator, score_note, rf_identity, rel]
for rule in response['risk']['evidenceDetails']:
note = Note(
abstract=f"{rule['rule']}",
content=f"{rule['evidenceString']}",
created_by_ref=rf_identity.id,
object_refs=[indicator.id]
)
ttp = AttackPattern(
name=rule['rule'],
description = rule['rule'],
created_by_ref=rf_identity.id,
custom_properties={
'x_rf_criticality': rule['criticality'],
'x_rf_critcality_label': rule['criticalityLabel']
}
)
rel = Relationship(
relationship_type='indicates',
source_ref=indicator.id,
target_ref=ttp.id,
start_time=datetime.now(),
created_by_ref=rf_identity.id
)
objects.append(note)
objects.append(ttp)
objects.append(rel)

    return Bundle(objects=objects).serialize()

`

@SamuelHassine
Copy link
Member

SamuelHassine commented Mar 9, 2021

Hello @jbfeldman,

We are sorry but we have turned the x_mitre_id to a "mandatory" field. This field is used to generate the standard STIX ID. Thus, all attack patterns with the same x_mitre_id will be merged together. In the Python library, I've noticed this:

# Extract external ID
x_mitre_id = "Unknown"
if "x_mitre_id" in stix_object:
         x_mitre_id = stix_object["x_mitre_id"]

In you screenshots, I don't see the field "External ID", but can you confirm it's "Unknown"?

You can put whatever you want in this field, but just ensure this will be unique. Some attack patterns can have the same name but be different, this field is the only criteria to define if an attack pattern is the same as another one.

By the way, we will remove the code which define a default "Unknown" x_mitre_id": OpenCTI-Platform/client-python@f7e3273. This will lead to an exception as x_mitre_id is a mandatory field.

Kind regards,
Samuel

@SamuelHassine SamuelHassine added bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR) labels Mar 9, 2021
@SamuelHassine SamuelHassine reopened this Mar 9, 2021
@SamuelHassine SamuelHassine added this to the Release 4.3.0 milestone Mar 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Projects
None yet
Development

No branches or pull requests

2 participants