The Google Cloud Security Community is upgrading platforms! Read more and check out our FAQ.

[af27]

Hi,

We have a use case where we need to create cases via the following endpoint:

/api/external/v1/cases/CreateCase

On creation i get a 200 http code, but not caseid of the case that was just created... what is the best way to get the caseid?

[_K_O]

Hi @af27, 

Do you have an example of the code you're using?

I'm guessing you're using something like response = requests.post(url, headers, etc.) in which case you'll receive the HTTP code if you're simply printing response (print(response)). 

If that assumption is correct, you should print the full json response payload instead:

response = requests.post(url=soar_url + "API_ENDPOINT",headers=auth_header, json=payload)
print(response.json())

The json response will most likely contain the case id as this is how it works when using the CreateManualCase api endpoint. 

[af27]

Hello, 

Yes i am using the requests lib, sadly it just returns a bool as per the swagger api docs. So the repsonse i get is just "true" with a 200 http code.

#make the reequest
r = siemplify.session.post(url, json=body)
print(r.status_code)
#print(r.text)
print(r.json())

Which seems like an odd design choice... I will look at using a manual case, but would need to understand if there are any differences between a "normal" case and a manual case.

As we need to be able to create the case with alerts/events attached, and from the swagger the json body for manual case does not appear to have a section for events.

[_K_O]

@af27 I had a quick look at the code base, it looks like the case_info object that you use to create the ticket contains a ticket_id. You may be able to use the get_cases_by_ticket_id function to return the case_id.

• Case_info object: https://github.com/chronicle/soar-sdk/blob/main/SimulatedCasesCreator.py#L21 
• Ticket_id: https://github.com/chronicle/soar-sdk/blob/main/Siemplify.py#L708 

---

I have not tried this, it just seems like a possible solution. 

[SoarAndy]

This API endpoint will return a 200 to indicate the payload was received. 

Un-intuitively, this endpoint does not create the Alert, the Alert is added to a dedupe queue where the Alert might be dropped (and because it's a different service it wont affect the 200).

Reasons why an Alert is created even after a 200

• TicketID and/or displayID are UID, if another Alert exists with this we assume it's a duplicate and drop
• The system is being overloaded by this alert source/name and drops.  The numbers for this are HIGH, unless you are spamming the system in testing this is unlikely your problem
• There is functioanlity for inbound alerts to be filtered to different Environments based on keys, however I don't think this works on API, so again I don't think this is the problem.

Please show your payload so we can look at UUID 

[af27]

Hi Andy,

Thanks for your reply, that makes sense as to why the caseID doesn't instantly appear.

One of our suppliers will be sending the data via the API, we have made them aware that the TicketID/DisplayID needs to be unique. 

In my testing example i've just used a guid to make sure it is unique.

If we can assume the Id's are unique, what would be the best way for our supplier to get the case id as they will need this for future api calls

Thanks,

Alec

[af27 · Accepted solution]

We have manged to find a way around this.

Using the endpoint: /api/external/vi/search/CaseSearchEverything 

with the body: 

{
"externalAlertId": "{unique id set by supplier}",
"timeRangeFilter": 0
}

we can then retrieve the case id from the search result

[SoarAndy]

Ah sorry, I was away for a few days, but you found it, ignore previous comment 🙂

[SoarAndy]

After submitting a new Alert, you need to wait a few seconds for Dedupe, entity extraction, and Alert Grouping to finish before the Case ID is known. 

Then you can run a search to api/external/v1/search/CaseSearchEverything which takes an input externalAlertId

Note - the API is changing at some point, so keep an eye out for notifications and timelines.