Skip to content
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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

janvi-elastic
Copy link
Contributor

@janvi-elastic janvi-elastic commented Feb 13, 2025

Proposed commit message

Create new integration package google_secops.

  • Added data stream.
  • Added data collection logic for alert data stream.
  • Added the ingest pipeline for alert data stream.
  • Mapped fields according to the ECS schema and added Fields metadata in the appropriate yml files.
  • Added dashboards and visualizations.
  • Added test for pipeline for alert data stream.
  • Added system test cases for alert data stream.
  • Add agentless deployment

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

How to test this PR locally

  • Clone integrations repo.
  • Install elastic package locally.
  • Start elastic stack using elastic-package.
  • Move to integrations/packages/google_secops directory.
  • Run the following command to run tests.

elastic-package test

--- Test results for package: google_secops - START ---
╭───────────────┬─────────────┬───────────┬────────────────────────────────────────────────────────────────────────┬────────┬──────────────╮
│ PACKAGE       │ DATA STREAM │ TEST TYPE │ TEST NAME                                                              │ RESULT │ TIME ELAPSED │
├───────────────┼─────────────┼───────────┼────────────────────────────────────────────────────────────────────────┼────────┼──────────────┤
│ google_secops │             │ asset     │ dashboard google_secops-517f96c9-1d44-420a-9ff4-96cf28de00d7 is loaded │ PASS   │      1.619µs │
│ google_secops │             │ asset     │ search google_secops-5407845c-e294-4f99-a342-9dc7e05dc8e0 is loaded    │ PASS   │        273ns │
│ google_secops │             │ asset     │ search google_secops-6a9de76e-e146-484e-ad87-fdb29c937fa2 is loaded    │ PASS   │        205ns │
│ google_secops │ alert       │ asset     │ index_template logs-google_secops.alert is loaded                      │ PASS   │        244ns │
│ google_secops │ alert       │ asset     │ ingest_pipeline logs-google_secops.alert-0.1.0 is loaded               │ PASS   │        253ns │
╰───────────────┴─────────────┴───────────┴────────────────────────────────────────────────────────────────────────┴────────┴──────────────╯
--- Test results for package: google_secops - END   ---
Done
--- Test results for package: google_secops - START ---
╭───────────────┬─────────────┬───────────┬───────────────────────────────────────────┬────────┬──────────────╮
│ PACKAGE       │ DATA STREAM │ TEST TYPE │ TEST NAME                                 │ RESULT │ TIME ELAPSED │
├───────────────┼─────────────┼───────────┼───────────────────────────────────────────┼────────┼──────────────┤
│ google_secops │ alert       │ pipeline  │ (ingest pipeline warnings test-alert.log) │ PASS   │ 288.418232ms │
│ google_secops │ alert       │ pipeline  │ test-alert.log                            │ PASS   │ 342.148692ms │
╰───────────────┴─────────────┴───────────┴───────────────────────────────────────────┴────────┴──────────────╯
--- Test results for package: google_secops - END   ---
Done
--- Test results for package: google_secops - START ---
╭───────────────┬─────────────┬───────────┬──────────────────────────┬────────┬──────────────╮
│ PACKAGE       │ DATA STREAM │ TEST TYPE │ TEST NAME                │ RESULT │ TIME ELAPSED │
├───────────────┼─────────────┼───────────┼──────────────────────────┼────────┼──────────────┤
│ google_secops │ alert       │ static    │ Verify sample_event.json │ PASS   │ 239.740171ms │
╰───────────────┴─────────────┴───────────┴──────────────────────────┴────────┴──────────────╯
--- Test results for package: google_secops - END   ---
Done
--- Test results for package: google_secops - START ---
╭───────────────┬─────────────┬───────────┬───────────┬────────┬────────────────╮
│ PACKAGE       │ DATA STREAM │ TEST TYPE │ TEST NAME │ RESULT │   TIME ELAPSED │
├───────────────┼─────────────┼───────────┼───────────┼────────┼────────────────┤
│ google_secops │ alert       │ system    │ default   │ PASS   │ 2m8.093218093s │
╰───────────────┴─────────────┴───────────┴───────────┴────────┴────────────────╯
--- Test results for package: google_secops - END   ---
Done

Screenshot

Screenshot 2025-02-13 112206
Screenshot 2025-02-13 112251
agentless-server-1
agentless-server-2
agentless-server-3
agentless-server-cloud-discover
agentless-server-discover

@elastic-vault-github-plugin-prod

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

description: Script to set event.severity.
tag: set_event_severity
source: |-
if (ctx.google_secops?.alert?.event?.securityResult instanceof List) {

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

cc @raqueltabuyo @cpascale43

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@kcreddy kcreddy added New Integration Issue or pull request for creating a new integration package. Crest Team:Security-Service Integrations Security Service Integrations Team [elastic/security-service-integrations] labels Feb 13, 2025
@elasticmachine
Copy link

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

@kcreddy kcreddy added the dashboard Relates to a Kibana dashboard bug, enhancement, or modification. label Feb 13, 2025
Copy link
Contributor

@kcreddy kcreddy left a 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.

Copy link
Contributor

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


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.

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

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

enabled: true
organization: security
division: engineering
team: security-service-integrations
inputs:
- type: cel
title: Collect Google SecOps logs via API

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.

@@ -26,6 +26,14 @@ policy_templates:
- name: google_secops
title: Google SecOps logs

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.

@@ -26,6 +26,14 @@ policy_templates:
- name: google_secops
title: Google SecOps logs
description: Collect Google SecOps logs.

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.

"ImpersonationLevel": "%33",
"KeyLength": "0",
"Keywords": "-9214364837600035000",
"LmPackageName": "-",
Copy link
Contributor

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?

Copy link
Contributor

@efd6 efd6 left a 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.

Copy link
Contributor

@kcreddy kcreddy left a 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.

@janvi-elastic
Copy link
Contributor Author

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.

@elasticmachine
Copy link

💚 Build Succeeded

History

@kcreddy
Copy link
Contributor

kcreddy commented Feb 25, 2025

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.

@jamiehynds,
As per @janvi-elastic, changing alert state is possible in SOAR, but they have only SIEM access. Due to this we are unable to test by closing an alert and whether we ingest the updated state.

If the API doesn't send updated states, we are okay.
If the API does send updated states, then we ingest the alert again in its new state (because we don't have fingerprint processor), thus leading to duplicates of same alert inside the dashboard. i.e., an alert can be in both Active and Close states. The only way to fix this is through latest transform.

I will leave it to you to take the call on merging the PR without this test.

@piyush-elastic
Copy link
Contributor

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.

@jamiehynds, As per @janvi-elastic, changing alert state is possible in SOAR, but they have only SIEM access. Due to this we are unable to test by closing an alert and whether we ingest the updated state.

If the API doesn't send updated states, we are okay. If the API does send updated states, then we ingest the alert again in its new state (because we don't have fingerprint processor), thus leading to duplicates of same alert inside the dashboard. i.e., an alert can be in both Active and Close states. The only way to fix this is through latest transform.

I will leave it to you to take the call on merging the PR without this test.

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.

@jamiehynds, As per @janvi-elastic, changing alert state is possible in SOAR, but they have only SIEM access. Due to this we are unable to test by closing an alert and whether we ingest the updated state.

If the API doesn't send updated states, we are okay. If the API does send updated states, then we ingest the alert again in its new state (because we don't have fingerprint processor), thus leading to duplicates of same alert inside the dashboard. i.e., an alert can be in both Active and Close states. The only way to fix this is through latest transform.

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.

@kcreddy
Copy link
Contributor

kcreddy commented Feb 27, 2025

@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:
The field responsible is lastUpdatedTime, but it is not available through the ListDetections API, i.e., not available in the rule-based detections (type: RULE_DETECTION).
It is available in API response of curated detections, i.e., threat intel detections (type: GCTI_FINDING).

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.
In case later we find the updated alerts are not available through the API and there is no need for transform, then users will have to delete their existing transform and also the index manually, which doesn't seem ideal experience.

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?

Copy link
Contributor

@kcreddy kcreddy left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Crest dashboard Relates to a Kibana dashboard bug, enhancement, or modification. New Integration Issue or pull request for creating a new integration package. Team:Security-Service Integrations Security Service Integrations Team [elastic/security-service-integrations]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants