Also see the [OSDU R3 Security Requirements](https://community.opengroup.org/osdu/program/-/wikis/Release_Planning/R3/Information_Security/OSDU-R3-Security-Requirements)
## Table of Contents
- What should be observed within OSDU
- Google Cloud Platform logging and monitoring
- Top logging and monitoring requirements for a production suitable solution
## What should be observed within OSDU
* Cloud Service starts/stops/error conditions
* OSDU Service starts/stops/error conditions
* All security-relevant events need to be logged. These include for every invocation of an OSDU API:
* Who
* Allowed/denied
* What resources were involved
* Any API header containing sensitive information such as authorization token should not be logged
## Google Cloud Platform logging and monitoring
Google Cloud Platform logs [include](https://cloud.google.com/logging/docs/view/available-logs):
* User logs
* Security logs
* Admin Activity
* Data Access
* System Event
* Access Transparency: actions taken by Google staff when accessing your Google Cloud content
[Chronicle’s](https://chronicle.security/applications/) threat investigation capabilities build on continuous, automated and retroactive correlation of all your security telemetry with a variety of threat intelligence sources. This includes
* Context from VirusTotal
* Embedded threat intelligence sources including Proofpoint, DHS, Avast, and AVG
* Customer provided threat intelligence feeds.
With Chronicle, investigations and hunts that might have taken days to complete can be performed in seconds, making your analysts far more productive.
### Security Command Center
[Security Command Center](https://cloud.google.com/security-command-center) is a security management and data risk platform that helps with security vulnerabilities and threats.
* Gain centralized visibility and control with built-in cyber risk management
* Improve your vulnerability management
* Report on and maintain compliance
* Detect threats targeting your Google Cloud assets
### Monitoring
[Cloud Monitoring](https://cloud.google.com/monitoring) provides visibility into the performance, uptime, and overall health of cloud-powered applications.
It collects metrics, events, and metadata from:
* Google Cloud
* Amazon Web Services
* Hosted uptime probes
* Application instrumentation
* A variety of common application components including Elasticsearch, Nginx, Apache Web Server, and many others.
### Service monitoring
[Service monitoring](https://cloud.google.com/monitoring/service-monitoring) and the Service Monitoring API help you manage your services like Google manages its own services. The core notions of service monitoring include the following:
* Selecting metrics that act as service-level indicators (SLIs).
* Using the SLIs to set service-level objectives (SLOs) for the SLI values.
* Using the error budget implied by the SLO to mitigate risk in your service.
## Top logging and monitoring requirements for a production suitable solution
### Common logging and monitoring standards
[Fluentd](https://www.fluentd.org/) is an open source data collector for a unified logging layer which is supported by AWS, MS, and GCP. The [Java Logback appender](https://logback.qos.ch/) is a generic SPI with facades for multiple logging backends including GCP Stackdriver. Cloud Logging library for Go exposes a higher-level layer for working with GCP Cloud Logging, and Python Standard Logging also supports GCP Stackdriver ([more info](https://cloud.google.com/logging/docs/setup))
[OpenCensus](https://cloud.google.com/monitoring/custom-metrics/open-census) is an open-source project which provides an idiomatic API, along with an exporter that sends your metric data to Cloud Monitoring through the Monitoring API for you. OpenCensus also has good support for application tracing.
You can use a single distribution of libraries to collect both metric and trace data from your services.
### System availability and security event alerting
You can monitor the availability of a resource by creating a GCP alerting policy that creates an incident if the [uptime check fails](https://cloud.google.com/monitoring/uptime-checks).
Google Cloud Security Command Center provides [Container Threat, Event Threat, and Anomaly detection](https://cloud.google.com/security-command-center/docs/concepts-security-sources#anomaly_detection) including potential leaked credentials, unusual activity, and coin mining.
### Action Automation
Cloud Logging can export all logging for an organization, or for a specific Google Cloud project. Using logging filters, you can include or exclude specific cloud resources. For example, you could export all Compute Engine logs, but exclude high-volume logs from Cloud Load Balancing. This approach gives you the flexibility to export all logs or specific logs.
GCP logging [supports automated notifications](https://cloud.google.com/monitoring/support/notification-options) to email, mobile applications, PagerDuty, SMS, Slack, Webhooks, and Google Cloud Pub/Sub. An alerting policy defines conditions, and these conditions are built on metrics. An [alerting policy condition can monitor](https://cloud.google.com/monitoring/alerts/types-of-conditions), for example, if a metric reaches a value, or if a metric starts to change quickly.
### Monitoring Cloud Provider access to your applications
Access Transparency gives you near real-time logs when Google Cloud administrators access your content. Cloud Audit Logs already provide visibility into the actions of your own administrators. However, this audit trail typically stops once your cloud provider’s support or engineering team is engaged; Access Transparency closes that gap, capturing near real-time* logs of manual, targeted accesses by either support or engineering.
### Protection of Logs
* Logs need to be immutable.
* Logs need to be encrypted at rest.
Google Cloud Platform logs are [stored in Google Cloud Storage buckets](https://cloud.google.com/logging/docs/storage) which are immutable and support both managed service and BYOK encryption mechanisms.
