Google Cloud Platform and Security Monitoring
Google Cloud Platform (GCP) is attracting a lot of companies, large and small, with its stability and many built-in services. But aggregated security monitoring has to be done via an external service.
And while the GCP Security Command Center service is great, it is too narrowly focused on GCP-specific sources. This is why it’s recommended to aggregate all of that data (including that produced by the Security Command Center) into a SIEM. A SIEM would be able to cover the following scenarios:
- Hybrid cloud and multi-cloud setups – while it’s great to standardize on GCP, it’s never that simple. Different departments may have chosen different providers over the years with one running on AWS and the other on GCP. Most importantly, there’s always some “leftover” on-premise resource from the “before cloud” era that would require a great organizational effort to move to the cloud. That might be an organizations ActiveDirectory, SAP, or a legacy accounting software that just doesn’t run anywhere else. A SIEM would be able to collect and correlate events from all those systems, not just from GCP.
- SaaS – infrastructure is one thing, but each organization nowadays is using at least one major SaaS – e.g. Microsoft365/Office365, Slack, Jira, SalesForce, or a locally-specific HR SaaS. Events from all of these systems need to also be aggregated and correlated with the GCP logs, allowing the organization to have a 360-degree view of the IT landscape, not just the cloud infrastructure
- Network – even if everything is run on GCP, there’s always a local network that has to be monitored for anomalies. A SIEM can collect both the VPC Flow logs and the local netflow for complete visibility.
How Do SIEMs Support GCP?
Unfortunately, many legacy SIEMs don’t have support for GCP or any cloud for that matter. LogSentinel SIEM, on the other hand, treats the cloud, especially IaaS, as a first-class citizen with direct integration. Integration is done by simply providing a keyfile in the LogSentinel SIEM cloud integrations UI or by directing the GCP log router to LogSentinel SIEM’s endpoints. The two approaches are documented here and each has its strong sides for different scenarios.
- Pulling logs from GCP – Pulling logs is great for on-premise SIEM setups. If you want your SIEM installed locally (e.g. as a virtual appliance), then you may not want to expose it to the internet in order to receive pushed logs from GCP (it is possible to set up a VPC to eliminate the need to expose it publicly, but that’s an additional configuration that you may not want to do). Pulling logs regularly happens in the background.
- Pushing logs from GCP to LogSentinel SIEM – Pushing logs allows for greater flexibility as it relies on the native GCP log router configuration which can be fine-tuned (the pull option can also be tweaked based on resourceIds consumed, but the log router is much easier). The configuration is as easy as specifying a LogSentinel SIEM endpoint to receive the logs. A good fit for the LogSentinel SIEM SaaS offering, but also an option in an on-premise scenario.
This flexibility is a direct consequence of LogSentinel’s design decisions – we don’t believe in imposing a certain architecture or network configuration on customers, which makes our product applicable in many diverse scenarios.
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
