Using Google SecOps with Bindplane

This guide showcases how to configure Bindplane to standardize exporting SIEM logs to Google SecOps.

By following the best practices outlined in this guide you will get:

• Standardized namespace and ingestion labels for Google SecOps
• Out-of-the box sources that work with default Google SecOps parsers
• Seamless fleet management for collectors
• Persistent queues

And, access to processors for:

• Filtering and routing log events
• Enriching log streams

Bindplane Cloud

We recommend Bindplane Cloud for deployments wherever possible. With no additional cost, the Cloud environment is always up-to-date, and eliminates the infrastructure overhead of maintaining your own instance. There is nearly the same functionality between both.

Licensing

The license types are the same between Bindplane Cloud and Bindplane On Prem. You can use Bindplane Cloud for no additional cost. Bindplane Google Edition includes Bindplane Cloud as a deployment option.

Network Diagram

Network Requirements

Bindplane Cloud exposes a domain and IP Address for using OpAMP to communicate between the collector and server, Admin UI, CLI, and API.

• Domain: app.bindplane.com TCP :443
• IP Address: 34.120.255.184

Authentication support is done via Auth0, and requires connectivity when using the Admin UI. View this list of IPs to allowlist for Auth0.

• Auth0: auth0.bindplane.com TCP :443

Bindplane Collector Network Requirements

The Bindplane Distro for OpenTelemetry (BDOT) Collector uses OpAMP to connect to Bindplane Cloud. This connection is established on the collector-side. You will only need to open an outbound port for the collector to communicate with Bindplane Cloud.

• Domain: app.bindplane.com TCP :443

Using GitHub for BDOT Collector Installation and Updates

An installation script pulls the configuration from the BDOT Collector Github repository.

How to Sign Up for a Bindplane Cloud Organization?

Sign up at https://app.bindplane.com/signup.

Sign-ups are open to customers and will start with a “Free” license level. You can change a Bindplane Free license to a Bindplane Google Edition license by emailing a request to support@observiq.com.

Include the name of the Organization that you want to change to Bindplane Google Edition. Organization names can be found in the upper right menu “observIQ Field Team” in the example below.

Bindplane On Prem

Self-hosting Bindplane is necessary in a few notable situations such as:

• Strict network security considerations
• Air-gapped environments where external collector communication isn’t possible
• Needing to install Bindplane On Prem and BDOT Collector without a network connection
• External authentication via LDAP, AD, or OIDC

Bindplane On Prem supports offline installations, hosting collector packages for upgrades, and external authentication. View the detailed docs, here.

Network Diagram

High Availability Deployment

A single node works for POCs or small deployments. We recommend a HA deployment as a best practice for production.

• HA Deployment Production Checklist
• Google HA GKE Production Checklist

Deployments without External Connectivity (Air Gapped)

If you need to install and upgrade a BDOT Collector offline, you can use Bindplane to host BDOT Collector installation packages and update binaries. View the detailed docs, here.

Network Requirements

Bindplane On Prem exposes port :3001 by default for using OpAMP to communicate between the collector and server, Admin UI, CLI, and API.

• Port: TCP :3001

Bindplane Collector Network Requirements

The Bindplane Distro for OpenTelemetry (BDOT) Collector uses OpAMP to connect to Bindplane On Prem. This connection is established on the collector-side. You will use port :3001 for the BDOT Collector to communicate with Bindplane On Prem.

• Port: TCP :3001

Using GitHub for BDOT Collector Installation and Updates

An installation script pulls the configuration from the BDOT Collector Github repository.

Self Hosted Multi-Cloud Architecture

It is common for organizations to operate in multiple data centers or cloud providers. In these scenarios, we recommend one of the following best practices:

• Use Bindplane Cloud: Ideal for customers who prefer a fully hosted solution.
• Deploy a single, shared Bindplane cluster: Allows for centralized management, shared configurations, and streamlined operations across all environments.

If you want to leverage Bindplane in multiple locations without deploying separate instances, you can configure a Bindplane HA Cluster that spans different data centers or clouds. This setup provides fault tolerance and high availability across regions.

For instructions on creating a high availability cluster, refer to the High Availability Guide.

In certain environments, it may not be possible for OpAMP (OpenTelemetry Protocol AMP) traffic to travel between different data centers due to network constraints or security policies. In these cases, each data center or cloud region can maintain its own Bindplane instance.

However, be aware of the following trade-offs:

• No Shared Configurations: Configurations can't be shared across separate Bindplane servers. Each instance is managed independently.
• Limited Telemetry Visibility: Observability data is confined to the collectors connected to a specific Bindplane instance.
• No Multi Data Center High Availability: High availability is restricted to the local data center. Separate instances do not automatically fail over between locations.
• Separate License Keys: Requires requesting multiple unique keys for each Bindplane instance, increasing management overhead if multiple instances are deployed.

Agent Configuration and Deployment Considerations

Use Gateway Agents

• Limit connections between customers’ network segment and Google SecOps APIs
• Limit JSON service keys to Google SecOps
• Queuing the for entire enterprise
• HA Gateways for additional resilience and scalability

For more guidance, refer to this blog post about Aggregators.

Agent Deployment using Configuration Management tools

Some customers prefer to manage BDOT Collector installation packages themselves using configuration management and system automation tools such as Ansible, Puppet, Chef, MS SCCM, or GPOs.

In these cases, once the Collectors are deployed, Bindplane takes over configuration and management. For Ansible users, use the Ansible Role specifically for Bindplane Collector deployments.

Google Secops Destination Configuration

The SecOps destination is used in your configurations to export logs with the BDOT Collector to Google SecOps.

JSON Authentication

The JSON authentication is recommended for most deployments.

For more detailed guidance, view Google SecOps Destination. For 'gRPC' connections, you can download the necessary JSON service key in the Google SecOps UI under Collection Agents, labeled INGESTION AUTHENTICATION FILE.

API Protocol Options

Production options are gRCP and HTTPS. We recommend to use the gRPC API unless you have communication restrictions around the gRPC protocol, such as a proxy that does not support gRPC. Compression, GZIP, is enabled by default on the exporter.

How to Scale Bindplane

Bindplane is designed for high scalability. It does not sit in the data telemetry path—meaning the number of collectors has no impact on the server’s performance.

In self-hosted deployments, a single Bindplane instance can manage up to one million agents. When you exceed 25,000 agents, we recommend running Bindplane in a High Availability configuration (see BindPlane Prerequisites).

For additional guidance on BDOT Collector and Gateway scaling, visit the BDOT Collector and Gateway Scaling page.

Google SecOps Log Collection Best Practices

Google SecOps expects raw, unstructured logs, so we recommend using sources supported by the default SecOps parsers for the smoothest integration. View details about the Google SecOps Destination.

If your use case requires custom parsing, refer to the Google Chronicle Default Parsers for options and configurations.

• Windows Events (With Advanced → “Raw Logs” enabled)
• Microsoft SQL Server
• CSV
• File
• HTTP
• TCP
• UDP
• Azure Event Hub (Using Log Format: Raw Option)
• Kafka (Using Raw Option)

We suggest using a Batch processor with the following configuration:

• Sends batches of size 500
• Uses a max batch size of 600

Raw Data is Required for Parsing within Google SecOps

• Best practice is to use the Google SecOps Standardization Processor for most configurations.
• chronicle_log_type log attribute used to define a SecOps parser as a Processor in situations where you cannot use the SecOps Standardization Processor.
• Some log types have the parser type assigned automatically

Window Event Collection

There are three ways to collect logs from Windows

• Windows Local Agent Collection (Recommended)
• Windows Event Forwarding to Local Agent
• Windows Remote collection using MSRPC

Syslog

• Use either the unparsed File Source, TCP RAW or UDP RAW Log Source
• Allows for parsing in SecOps
• Use the SecOps Standardization processor or the chronicle_log_type attribute to define the parser

Data Ingestion and Health Dashboard in SecOps

The Data Ingestion and Health in SecOps can be useful to verify log types and volume of data being received by SecOps.