-
Notifications
You must be signed in to change notification settings - Fork 86
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
Update to v2 based process and event searches #241
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great stuff, thanks for the help here @crahan. I'm not the one who should be approving this PR as I'm not the most familiar with this project but I left some comments in here for some context on the underlying APIs. I'm sure @avanbrunt-cb would like to look at this at some point, too.
src/cbapi/psc/threathunter/query.py
Outdated
@@ -285,28 +303,31 @@ def _validate(self, args): | |||
def _search(self, start=0, rows=0): | |||
# iterate over total result set, 100 at a time | |||
args = self._get_query_parameters() | |||
self._validate(args) | |||
#self._validate(args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use the v1 validation endpoint for this, I believe the _validate
function just needs to pull the query from query
instead of q
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct, I've updated the _validate()
function in the PR by grabbing the query
parameter from args
and submitting it as the value for q
to the v1 validation API endpoint. Validation now passes as expected. I've updated the PR description to reflect this.
@avanbrunt-cb
Which will translate into: "sort": [
{
"field": "device_timestamp",
"order": "DESC"
},
{
"field": "backend_timestamp",
"order": "ASC"
}
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Pull request checklist
Please check if your PR fulfills the following requirements:
Pull request type
Please check the type of change your PR introduces:
What is the ticket or issue number?
No ticket number available.
Pull Request Description
This pull request updates Cb ThreatHunter process and event searches to use the new v2 style API. Tests (see below) indicate that process search results now contain aggregated lists of TTP and enriched_event_type data. We are also able to retrieve more or even all events for a particular Process object (versus only a handful of events with the v1 event search API). Retrieval of event data now correctly uses batches of 100 events per iteration and it will loop until the value of
num_available
has been reached (fixing the issues reported in #239).Does this introduce a breaking change?
As the change from Process Search v1 to v2 splits out enriched Process search results from the regular process search results (and moves these solely to the enriched_event search) this PR will result in procecss search results not including enriched events. An additional update will be required to support explicitly searching for enriched process events. Retrieving events from a process GUID are not affected by this and function the same as before.
Validation for event and process searches had to be disabled as the v2 search API does not supply a validation endpoint and the query parameter json format changed between v1 and v2. As a result the v1 validation API endpoints can not be used anymore. Any lines in(see 'Update 2' below)query.py
where_validate()
is called have been commented out and the_validate()
has been left in place.Update 1: It also still uses the v1 process search status API endpoint (
/api/investigate/v1/orgs/{org_key}/processes/search_jobs/{query_id}
) as v2 does not provide that functionality yet (it only has/api/investigate/v2/orgs/{org_key}/processes/search_jobs/{job_id}/results
). However, using a v2 job-id with the v1 status endpoint returns the contacted vs completed information as expected. If this is not desired, then the v2 process search results endpoint (/api/investigate/v2/orgs/{org_key}/processes/search_jobs/{job_id}/results
) can be used instead. It will simply return the first set of results for each status check instead of just search completion status (i.e. only the counts of the search nodes that were contacted and have returned results).Update 2: the
validate()
function calls have been enabled again and thevalidate()
function was updated to send the query as aq
parameter instead of the now defaultquery
argument used in the v2 search API.How Has This Been Tested?
The following script was used to test the changes:
The below alternative code works as well (using the
events()
function on a Process object):Either of these test scripts results in the below output: