BindPlane On-Prem Architecture for Google SecOps

In this post I want to discuss BindPlane architecture, specifically, the on-prem architecture for routing logs to your Google SecOps SIEM. BindPlane, at a high level, is a telemetry pipeline (built on top of the OpenTelemetry framework) that is designed to collect, refine and export logs, metrics and traces from any source to any destination. It is an incredibly powerful tool and one that I have only began scratching the surface of.

I wanted to write this blog post as I found the information, specifically on the architecture, a little lacking online and quite confusing as Google and Bindplane (owned by ObserveIQ) are separate organizations. In the context of Google SecOps, BindPlane can be thought of as the log shipper, it is designed to act as the pipeline to route your logs from your on-premise machines to Google SecOps.

To note, I wont get into the weeds of Bindplane, as there are a lot of elements to it and to keep this strictly around architecture, I will look to write up separate blogs around the other elements so as not to overload you with information. However, there are a few key concepts I want to quickly explain as it will help with understanding the deployment of the architecture.

Key Concepts

Bindplane OP – BindPlane OP (Observability Pipeline) is a management console that can be deployed directly to a Linux server or using a docker container image. The management console is where you can deploy BindPlane Collector Agents to your environment so it can then be configured and managed. It is where you design the pipeline and the processes you want to build in your pipeline.
BindPlane Agent – The BindPlane agent is the collector that gets deployed to the machines you want to collect logs from and ship to your destination. The BindPlane agent uses a configuration file to understand what logs to receive and where to send.
BindPlane Configuration – This is the configuration that is built inside the management console that tells the collector information such as what ports to listen on, where to send the logs as well as any processing you may want to to inside the pipeline.
BindPlane Gateway – The Bindplane gateway is used for receiving data from other BindPlane collectors on the network.
Google SecOps Forwarder – This is Google’s native log collector and forwarder to its SIEM platform.

Google SecOps On-Prem Collection Methods

Google SecOps has two methods of collecting logs from your on-premises machines; via the Google SecOps Forwarder or through the BindPlane Collector. From my understanding, both of these methods send the logs to the same destination – the Google Ingestion API (for US its malachiteingestion-pa.googleapis.com). So, how do you know when to use one or the other, or both? The best way to explain this, will be to go through various architectures, that way we can visualize the deployment and when each architecture would be suitable depending on your environment and your requirements.

Architecture Methods

Method 1 – Google SecOps Forwarder

The first method I want to discuss, albeit not in much detail, is ingesting logs via the Google SecOps Forwarder. You can simply deploy Google SecOps Forwarder via the docker container available and set it up to receive logs from your on prem machines. The forwarder will then collect and ship the logs to Google SecOps via the ingestion API. In my opinion, this method is redundant due to the introduction of BindPlane, which offers far greater features. However, this method maybe useful if you have a small environment and simply need to send logs to your SIEM without any other processing.

Method 2 – BindPlane Direct to Google SecOps

This method of architecture sends logs from your on-prem machine directly to your Google SecOps instance. This architecture method has a the Bindplane OP Server running inside a docker container on a Linux Server. You can access the management console using a browser like Chrome. From the console, you can deploy agents to all your endpoint machines in your environment and assign the configuration those servers. Once the collector is installed on those machines, it will ship the logs your have configured directly to the Google SecOps Ingestion API via TCP on Port 443.

This method requires your endpoint machines to have outbound enabled for that port and connection type. So this maybe an issue if you do not allow this type of traffic from your endpoints. This method is ok for small environments but for medium to large enterprise’s, will quickly prove to be a management headache as you have to deploy and agent on every machine.

Method 3 – Central Bindplane Collectors Direct to SecOps

In this method, we are deploying BindPlane to servers to act as a central log collector for other machines deployed on your network. This method is more suitable for medium to large enterprises as you do not need deploy Bindplane Agents on all your endpoints. Instead, you can deploy BindPlane on a Linux server and build a configuration file that essentially turns this Linux server into a central forwarder. You can then configure your on prem log sources, like your Firewalls, VPNs, Linux servers etc to send to this Linux server with the Bindplane Agent on it, which will then forward those logs straight to Google SecOps. Each Log source can also be configured to send to a specific port, which will make it easier to define a log type in the BindPlane pipeline, allowing for seamless Google SecOps Standardization.

If you have a large Windows deployment, you can also look at deploying a Bindplane Agent on your WEC Server. Any servers already configured to send its event logs to the WEC server, can then be forwarded from the WEC server to Google SecOps via the BindPlane Agent.

Like Method 2, this deployment still relies on an outbound connection via 443 to the Google Ingestion API, so may not be suitable for some environments.

Method 4 – BindPlane Gateway to Google SecOps

In this deployment we add a BindPlane Gateway to the architecture. The Gateway allows for a few extra use cases, it allows additional processing which you may want to do after all your logs have been collected but before its been sent to Google SecOps, i.e. add some metadata to all your logs. The best use case for deploying a BindPlane Gateway is the ability to have it deployed on another part of your network i.e. your DMZ, this means all the logs can be shipped from internal collectors, to the gatway that resides on your DMZ and from your DMZ you create a single outbound allow rule to the Ingestion API whilst denying any inbound traffic to the gateway and any inbound traffic from the gateway to the internal collectors. This allows for better network security.

One downside to this deployment method compared to sending your logs directly from the collectors is the fact you have an additional potential point of failure and another server to manage.

Method 5 – Google SecOps Forwarder to Google SecOps

This is simply a copy of Method 4, but instead of using the BindPlane Gateway in the DMZ, you could use the Google SecOps Forwarder. However, I do not see any point in doing this as BindPlane offers additional pipeline processing features as well as making it easier to manage, having a single product across your internal environment.

Method 6 – Additional Destinations

I wanted to show this last method, simply to show the power and flexibility of BindPlane. In this deployement we are sending logs to not just Google SecOps but also to a GCP Bucket and an AWS S3 Bucket. This use case would be really good if you have logs that you may need to store for compliance purposes but have no security value and so you could send these logs to cheaper solutions such as these. The BindPlane processer makes it east to split these logs out to various destionations. The free Google Bindplane license does allow you to send to a GCP bucket, but if you want to ship your logs elsewhere, you will need a BindPlane enterprise license.

Summary

To summarise, we went through 6 potential architecture options all of which have there pros and cons. I think deploying products like BindPlane allows you to take more control

References