-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
TheHive Connector for Cases #180931
TheHive Connector for Cases #180931
Conversation
Curious what the state of this is, as it's still asking for a review from ResponseOps. I don't think we've gotten any specific asks to review this, so not sure if this is kinda a POC, or if we really want to merge it. But it shows up on RO PR's to review, so if it's not currently active, would be nice to close it for now ... |
Pinging @elastic/response-ops-cases (Feature:Cases) |
@elasticmachine merge upstream |
Hey @brijesh-elastic I have started testing this but the code does not seem ready for review yet. I am seeing errors in the parameter form, and the connector does not appear in the Cases page, because it's not configured as such. To test it I created a temporary branch from this one and merged the main implementation branch https://github.com/brijesh-elastic/kibana/tree/thehive_case_connector. Did I miss anything? Or should I wait until the first PR is merged before starting with this one? |
You can test on the temporary branch. It's good to go. |
@elasticmachine merge upstream |
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.
Hi @brijesh-elastic, I see the connector supportedFeatureIds is missing CasesConnectorFeatureId
here
kibana/x-pack/plugins/stack_connectors/server/connector_types/thehive/index.ts
Lines 35 to 39 in a98d141
supportedFeatureIds: [ | |
AlertingConnectorFeatureId, | |
SecurityConnectorFeatureId, | |
UptimeConnectorFeatureId, | |
], |
Is it intentional? When I add the cases feature everything works well
const mapTLP = (tlp: number | string): string => { | ||
switch (tlp) { | ||
case "0": | ||
return 'CLEAR'; | ||
case "1": | ||
return 'GREEN'; | ||
case "2": | ||
return 'AMBER'; | ||
case "3": | ||
return 'AMBER+STRICT'; | ||
case "4": | ||
return 'RED'; | ||
default: | ||
return 'AMBER'; | ||
} | ||
} |
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.
Can this function be extracted outside of the component implementation? There's no need to be re-defined on each render. Also, there are 2 variables named tlp
in the same block, and the linter is complaining about it.
} = (theCase.connector.fields as ConnectorTheHiveTypeFields['fields']) ?? {}; | ||
return { | ||
tags: theCase.tags, | ||
tlp: typeof tlp === 'string' ? parseInt(tlp) : tlp, |
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.
It seems we have a rule for the radix parameter of the parseInt
call, the linter is complaining about it. To fix it:
tlp: typeof tlp === 'string' ? parseInt(tlp) : tlp, | |
tlp: typeof tlp === 'string' ? parseInt(tlp, 10) : tlp, |
@brijesh-elastic I've tested the connector, and everything is working fine. The only thing I miss is the case's Marked as Not marked as Is there any reason not to sync this field? |
No, Will add in next commit. |
Yes. In TheHive, the Initially, we faced an issue where the |
@elasticmachine merge upstream |
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.
Changes have been desk tested and everything is working as expected. All comments and doubts were solved. Approving on behalf of Security Solution.
LGTM
@elasticmachine merge upstream |
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.
Tested and LGTM! Great work! I left some minor comments. Also, I noticed that the TLP text for the dropdown selection (x-pack/plugins/cases/public/components/connectors/thehive/case_fields.tsx
) and the preview (x-pack/plugins/cases/public/components/connectors/thehive/case_fields_preview.tsx
) are the same. Is it possible to have a common data structure that it is shared between the components in case we want to update the text in the future? Wdyt?
*/ | ||
|
||
export const TheHiveFieldsRt = rt.strict({ | ||
tlp: rt.union([rt.number, rt.string, rt.null]), |
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.
The schema of the tlp
of the connector is number
and not a string. I think we should keep the same convention here for cases (number
or null
). This way we can avoid doing parseInt(tlp, 10)
on the backend. We may need to do it on the frontend as the select
dropdown accepts only strings as values (as you do here x-pack/plugins/stack_connectors/public/connector_types/thehive/params_case.tsx
).
'data-test-subj': 'tlp-field', | ||
options: tlpOptions, | ||
fullWidth: true, | ||
hasNoInitialSelection: true, |
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.
Given that the field is required should we have a default value on the dropdown?
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.
Yes, AMBER
.
it('it formats correctly when fields do not exist ', async () => { | ||
const invalidFields = { tags: ['tag1'], severity: 'low', connector: { fields: null } } as Case; | ||
const res = await format(invalidFields, []); | ||
expect(res).toEqual({ tlp: null, severity: 1, tags: ['tag1'] }); |
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.
Should we default the tlp
to something if it is a required field on TheHive?
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.
We've set the default TLP
to AMBER
in the frontend, so it will always be present in the format
function.
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.
Users can use the API and they can set the tlp
to null
. Does TheHive accept null
as a TLP?
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.
Yes, TheHive will accept it as null
and will default set it to AMBER
.
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.
Oh perfect then!
* 2.0. | ||
*/ | ||
|
||
export enum TheHiveTLP { |
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.
I think is better if we do
export enum TheHiveTLP {
CLEAR = 0,
GREEN = 1,
AMBER = 2,
"AMBER+STRICT" = 3, <--- I added the + symbol so the label can be used in the UI.
RED = 4,
}
The reason is that by doing
Object.entries(TheHiveTLP).map(
([_, value], index) => ({
text: value,
value: index,
})
);
we rely on the order of the enum (index
) which may change or be different in the future. If we explicitly map the key to an integer we avoid this problem. The key can be used as the value to be shown in the UI and there is no need to rely on the order of the enum. What do you think?
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.
Yes, That make more sense. Let me change it.
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! Thank you for your patience with my review. I tested and is working as expected.
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsasync chunk count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
## Summary This test (#180931) was introduced right before the version bump of user-events (#189949). This PR updates the one async call to be awaited, hopefully fixing the test. Solves: #192475 Unskipped tests are passing now: https://buildkite.com/elastic/kibana-pull-request/builds/233177 --------- Co-authored-by: Antonio <[email protected]>
Summary
This PR implements the case support for TheHive connector.
Depends on : #180138
Screenshots
List of connectors
Configure thehive connector from cases
Checklist
Delete any items that are not applicable to this PR.
For maintainers
Release notes
Support TheHive connector to cases