> For the complete documentation index, see [llms.txt](https://docs.expel.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.expel.io/detection-strategy-guides/d-m/google/google-security-operations-secops-detection-strategy.md).
# Google Security Operations (SecOps) Detection Strategy
## Product Overview
Google SecOps is Google's Security Information and Event Management (SIEM) platform that provides threat detection, investigation, and response capabilities within the Google Cloud ecosystem.
## Detection Strategy for SIEM Integrations
### Detection
SIEM technology provides us with a helpful detection "backstop" for event telemetry. The detections are not authored by us, so how we ingest and action on the SIEM's alerts depends on the SIEM's category.
This SIEM integration is categorized as supporting both **out-of-the-box (OOTB) detection rules** and **custom detection rules**. This means we may leverage either OOTB or custom rules to map the SIEM alerts to our own ingestion criteria.
Your OOTB and custom rules are both subject to our evaluation and will be accepted based on:
1. **Fidelity** - the detection rule should have an alert volume that suggests high fidelity (for example, an average weekly alert volume less than 10 generally suggests the rule has high fidelity)
2. **Redundancy** - the detection rule name, description, and query should not duplicate (or suggest a duplication of) alerts that would surface through a direct API integration with a non-SIEM technology
3. **Evidence** - the detection rule must provide us with an adequate number of artifacts to action upon (two or fewer artifacts suggests insufficient information for our SOC analysts)
4. **Scope** - the detection rule name, description, and query must align with your service and should not be written for a different category of service
If we are unable to support your custom rule because it does not meet the criteria above, we will let you know so that you can make modifications and resubmit it to us.
For accepted custom rules, we will provide you with a report that details our projected level of support. Contact your Sales or Support rep for more details.
### Response
SIEM telemetry provides additional information that can be useful for us to disposition alerts. With the exception of investigative-only SIEMs, we will follow our normal event triage process and create an Expel Alert that is sent to our SOC analysts for analysis. We may also run queries against your SIEM logs to search for additional types of data, which we use to enrich our alerts with additional context.
## What We Support for Google SecOps
To see a comprehensive list of the most up-to-date SIEM rules and available DUETs (**d**id yo**u** **e**xpect **t**his) that we support for Google SecOps, ask your Sales or Support rep for the most recent download (not all SIEM rules are visible on the [Detections page](https://workbench.expel.io/tools/detections/all?filter=%7B%22supportedTech%22%3A%7B%22is%22%3A%5B%22chronicle%3A1.0.0%22%5D%7D%7D) in Workbench).
| **Supported event log sources** | |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Google SecOps detection rules support** | Yes. |
| **Detection rules written by Expel** | No. Expel does not write any detection rules for SIEM integrations. |
| **Custom rules support** | Yes. |
| **Investigative support through Workbench** | Yes. We are able to take the following investigative actions to gather data for triage and investigation of events.
- Query Logs
- Query IP
- Query Domain
- Query Host
- Query Hash
|
| **Hunting support** | No. Hunting is not currently available for this integration. |
## Additional Details and Common Questions
### Console Access
A SIEM alert does not typically include all of the contextual timeline activity surrounding the event of interest. Because this integration does not allow us to get all necessary data via the API, we will ask you for a certain level of console access during onboarding. Granting it is optional, but is strongly recommended.
The level of access that we require is meant to support essential triage and research activities, and to help us determine the vector and extent of attacker activity for an identified threat. At minimum, we will ask for visibility into alert data, timeline events recorded, and live response/real time response shell (if applicable).
### Historic Volume
We use historic volume to determine projected SIEM alert volume, which helps us decide whether or not a particular detection is appropriate to send to our SOC. We target 30 days as the ideal period of time to check on volume, and two weeks as the minimum. This gives us the confidence we need to properly evaluate incoming SIEM alerts in a way that does not flood the SOC with benign activity.
### DUET
A DUET (**d**id yo**u** **e**xpect **t**his) rule flags certain SIEM alerts as needing an immediate verification or notification, and bypasses the normal internal event triage process. The alerts subject to DUET rules contain behaviors that are not typically indicative of true security incidents, as they are related to policy violations or *potential* risk.
There are a number of workflows that a DUET may follow. When enabled, the activity will be flagged for investigation and will be routed to you (rather than to us) to take a specified first action. To see the specific DUET rules currently supported for this integration, visit the [Detections page](https://workbench.expel.io/tools/detections/all) in Workbench.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.expel.io/detection-strategy-guides/d-m/google/google-security-operations-secops-detection-strategy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.