-
Notifications
You must be signed in to change notification settings - Fork 442
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
[google_secops] Initial release of the google secops #12767
base: main
Are you sure you want to change the base?
Conversation
🚀 Benchmarks reportTo see the full report comment with |
description: Script to set event.severity. | ||
tag: set_event_severity | ||
source: |- | ||
if (ctx.google_secops?.alert?.event?.securityResult instanceof List) { |
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 discovered an issue across all of our integrations, whereby event.severity is not mapped to the values expected by Elastic Security. This is a result of ambiguity in the ECS field description that we're also working to address (https://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-severity)
Could we map the event.severity values to the values expected by Elastic Security, to ensure the severity from 3rd party alerts will be assigned the correct severity within Elastic? It's a numeric scale:
Low - 21
Medium -47
High- 73
Critical - 99
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.
@jamiehynds We have mapped event.severity to the values given in the Google SecOps documentation.
Let me know if we have to update the values as the values expected by Elastic Security.
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.
@janvi-elastic , yes please update according to Elastic Security guidelines stated above.
The custom field will always be there if users wants the source severity.
You can add a note to the README to mentioning the same.
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
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.
Please check if we are able to ingest alert status updates from the API.
For example from ALERTING
-> NOT_ALERTING
.
If so, we will need a latest transform to store the last state.
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 you resolve an alert and check if you are getting the updated document?
ALERTING
-> NOT_ALERTING
packages/google_secops/data_stream/alert/_dev/test/system/test-default-config.yml
Outdated
Show resolved
Hide resolved
packages/google_secops/data_stream/alert/_dev/test/pipeline/test-alert.log-expected.json
Show resolved
Hide resolved
|
||
For more information, refer to [Agentless integrations](https://www.elastic.co/guide/en/serverless/current/security-agentless-integrations.html) and [Agentless integrations FAQ](https://www.elastic.co/guide/en/serverless/current/agentless-integration-troubleshooting.html) | ||
|
||
> Note: Currently Agentless support for Microsoft Sentinel integration is limited to API and not supported for Azure Event Hub input. |
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.
Microsoft Sentinel shouldn't be mentioned in the Google SecOps docs, presume a copy/paste error.
|
||
> Note: Currently Agentless support for Microsoft Sentinel integration is limited to API and not supported for Azure Event Hub input. | ||
|
||
### Agent-based deployment |
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.
@alaudazzi can you advise how we're handing these agentless going forward? With this issue in mind, I want to ensure we adhere for any new integrations developed. https://github.com/elastic/integration-docs/issues/653
packages/google_secops/manifest.yml
Outdated
enabled: true | ||
organization: security | ||
division: engineering | ||
team: security-service-integrations | ||
inputs: | ||
- type: cel | ||
title: Collect Google SecOps logs via API |
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 we change logs
to alerts, as the scope of the integration is limited to alerts from SecOps.
packages/google_secops/manifest.yml
Outdated
@@ -26,6 +26,14 @@ policy_templates: | |||
- name: google_secops | |||
title: Google SecOps logs |
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.
Change from logs to alerts.
packages/google_secops/manifest.yml
Outdated
@@ -26,6 +26,14 @@ policy_templates: | |||
- name: google_secops | |||
title: Google SecOps logs | |||
description: Collect Google SecOps logs. |
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.
Change from logs to alerts.
packages/google_secops/data_stream/alert/_dev/test/pipeline/test-alert.log
Outdated
Show resolved
Hide resolved
packages/google_secops/data_stream/alert/agent/stream/cel.yml.hbs
Outdated
Show resolved
Hide resolved
"ImpersonationLevel": "%33", | ||
"KeyLength": "0", | ||
"Keywords": "-9214364837600035000", | ||
"LmPackageName": "-", |
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.
Do we want to remove "-"
fields?
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 but please wait for @kcreddy.
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.
My primary concern is from #12767 (comment), we didn't test for events with alert's state change.
This might mean the alerts will keep growing in Kibana, and no way to find Current Active Alerts
.
In our instance, we don't have an option to update the state of alert. |
💚 Build Succeeded
History
|
|
@jamiehynds, If the API doesn't send updated states, we are okay. I will leave it to you to take the call on merging the PR without this test. |
@kcreddy , @jamiehynds -Unfortunately, we don't have access to the SOAR component. We can add transform as a precaution, but we are unable to determine which field leads to updated_detection. Alternatively, if we can confirm the relevant fields, we can test it using a Mockserver. Please find the list of supported response fields here. |
@piyush-elastic, thanks for the info. If we can't get access to SOAR, here's my suggestion: At this point, we are unsure if the updated alert state comes through the List Detections API. We may not want to add transform as precaution, because we don't have a proper way to delete the transform and its destination index automatically. We can go ahead with what we have right now and collect user feedback on any duplicate alerts (with different states) in their indices. We can add transform if duplicate alerts are ingested. @jamiehynds does that sound good? |
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.
Waiting on #12767 (comment) for merging.
Proposed commit message
Create new integration package google_secops.
Checklist
changelog.yml
file.How to test this PR locally
Screenshot