indicator_get_v1 API Doesn't Return Tags

[mtobias-getty]

Hello!

Looking at the IOC apis, specifically the get API, I noticed that the tags element of the IOC is not returned by the API, both in practice and per documentation. This presents a bit of an issue as I'm working on a process that utilizes CI/CD to manage IOCs in our environment.

The lack of tags presents an issue as I, the developer, need to be aware of if the IOCs I'm submitting to the API are new or exist and need to be updated, both the create and update APIs require the code to handle duplication and present error messages if you try to create and IOC that already exists. So, to handle this I have a process that creates a hash of the relevant information between my repo and what Crowdstrike is aware of, if there is a change in the description, severity, platforms the hash value will differ from what Crowdstrike knows and what my repo has and I can call the update endpoint instead of the create endpoint (or do nothing if the hash matches).

Since the Crowdstrike API doesn't return the tags of the IOC, I can't use those as part of the comparison, this puts me in a situation where I cannot have just the tags on an IOC change, because the code doesn't detect that it is a changed IOC, as far as what the Crowstrike API returns, it isn't a changed IOC. Is there a possibility for the indicator_get_v1 API to return a tags element, which is already accepted by the indicator_create_v1API

[jshcodes]

Hi @mtobias-getty -

I've confirmed that tags are not coming back in a indicator_get_v1 or indicator_combined_v1 operation call. I am also seeing the modify date change when I modify the tags, even though the base IOC is unchanged. (Which makes sense as the record itself IS changed in this scenario.) So you would not know it's a tag that was updated, but you would be able to see that the record has received an update and that your hash comparison is still a match.

I'll follow up shortly (I'm working on confirming if there isn't a method for us to retrieve these another way.)

[jshcodes]

Actually I'm wrong, I didn't have any set, so I didn't get the branch back. If you use indicator_combined_v1 you should get the tags back in your return. Will post an example here in a moment.

[jshcodes]

Hi @mtobias-getty!

You will only get a response back containing the tags branch if there are tags set on the indicator. This should hold true for both the indicator_get_v1 and indicator_combined_v1 operations.

Example

import json
from falconpy import IOC

ioc = IOC(client_id="CLIENT_ID_HERE", client_secret="CLIENT_SECRET_HERE")
result = ioc.indicator_combined_v1(filter="value:'1.2.3.4'")["body"]["resources"]
print(json.dumps(result, indent=4))

Which should return you something along the lines of ...

[
    {
        "id": "a9e43608f2dd50138b6REDACTED",
        "type": "ipv4",
        "value": "1.2.3.4",
        "action": "no_action",
        "severity": "",
        "metadata": {},
        "platforms": [
            "linux"
        ],
        "tags": [
            "JoshTest"
        ],
        "expired": false,
        "deleted": false,
        "applied_globally": true,
        "from_parent": false,
        "created_on": "2021-10-22T11:20:04.584121517Z",
        "created_by": "REDACTED_CLIENT_ID",
        "modified_on": "2022-05-11T16:04:44.847319541Z",
        "modified_by": "falconpy@CrowdStrike"
    }
]

[mtobias-getty]

Hey @jshcodes,

Good news! I was actually incorrect. Upon further testing, and the indicator_combined_v1 response actually showed me this, the indicator_get_v1 (paired with indicator_serach to make sure I know what IDs to pull back) DOES actually return tags if they exist. The API just doesn't return the tag element at all if there aren't tags. It seems like quite an optional field. In my testing the indicator_combined_v1 behaves the same way, only IOCs with tags returns a tags element, otherwise it isn't included in the response. I've simply fixed my issue with testing to see if the tags value comes back, if it does I include it in my hash calculation, if it doesn't, I set a blank string and include it in my hash calculation. This correctly determines tag changes.

If anything I might suggest a note be included in the documentation indicating that tags is an optional response from the API depending on if the IOC has tags already or not. Otherwise, thank you very much for your quick response, I think I'm all set!

[jshcodes]

Fantastic!

We'll get the documentation updated to mention this issue. I've also edited my answer above to provide more detail regarding the output.

Thank you for the additional detail! 😄