“Ninety percent of all data today was created in the last two years—that’s 2.5 quintillion bytes of data per day,” according to business data analytics company Domo. That would be a mind-bending statistic, except that it’s already five years old.

As data usage has undergone drastic expansion and changes in the past five years, so have your business needs for data. Technology such as cloud computing and AI have changed how we use data, derive value from data, and glean insights from data. Your organization is no longer just crunching and re-crunching the same data sets. Data moves, shifts, and replicates, as you mingle data sets and gain new value in the process, as we say in our Data Cloud story. All the while, your data resides in—and is being created in—new places.

Data lives in a myriad of locations now and requires access from different locations and mediums, yet many of today’s security models are not geared towards this. In short, your data has fallen out of love with your security model, but attackers have not. So, how do we realign data and security so they are once again in a healthy relationship?

Google Cloud, as a leader in cloud data management and cloud security, is positioned uniquely to define and lead this effort. We’ve identified some challenges around the classic approach to data security and the changes triggered by the near-ubiquity of the cloud. The case is compelling for adopting a modern approach to data security. We contend that the optimal way forward is with autonomic data security.

A relatively new concept, autonomic data security is security that’s been integrated with data throughout its lifecycle. It can make things easier on users by freeing them from defining and redefining myriad rules about who can do what, when, where. It’s an approach that keeps pace with constantly evolving cyberthreats and business changes.

Autonomic data security can help you keep your IT assets more secure and can make your business and IT processes speedier. For example, data sharing with partners and data access decisions simultaneously becomes faster and more secure. This may sound like magic, but in fact relies on a constant willingness to change and adapt to both business changes and threat evolution.

Taking the precepts, concepts, and forward-looking solutions presented in this paper into consideration, we strongly believe that now is the right time to assess where you and your business are when it comes to data security. Cloud also brings an incredible scale of computing. Where gigabytes once roamed, petabytes are now common. This means that many data security approaches, especially the manual ones, are no longer practical.

To prepare for the future of data security, we recommend you challenge your current model and assumptions and ask critical questions, evaluate where you are, and then start to put a plan in place of how you could start incorporating the autonomic data security pillars into your data security model.

There are two sets of questions organizations need to discover the answers to as they start this journey. The first set of questions will help you identify the nature and status of your data, and inform the answers to the second set.

• What data do I have?
• Who owns it?
• Is it sensitive?
• How is it used?
• What is the value in storing the data?

The second set focuses on higher-level problems:

• What is my current approach to data security?
• Where does it fail to support the business and counter the threats?
• Does it support my business?
• Should I consider making a change? And if yes, in what direction?

The path to improved data security starts by asking the right questions. You can read the full Autonomic Data Security paper for a more in-depth exploration here and learn more about the idea in this podcast episode.

Mindful Containers is a fictitious company that is creating containerized microservice applications. They need a fully managed compute environment for deploying and scaling serverless containerized microservices. So, they are considering Cloud Run. 

They are excited about Cloud Run because it abstracts away the cluster configuration, monitoring, and management so they can focus on building the features for their apps. Cloud Run is a fully-managed compute environment for deploying and scaling serverless containerized microservices.

What is Cloud Run?

Cloud Run is a fully-managed compute environment for deploying and scaling serverless HTTP containers without worrying about provisioning machines, configuring clusters, or autoscaling.

• No vendor lock-in – Because Cloud Run takes standard OCI containers and implements the standard Knative Serving API, you can easily port over your applications to on-premises or any other cloud environment. 
• Fast autoscaling – Microservices deployed in Cloud Run scale automatically based on the number of incoming requests, without you having to configure or manage a full-fledged Kubernetes cluster. Cloud Run scales to zero— that is, uses no resources—if there are no requests.
• Split traffic – Cloud Run enables you to split traffic between multiple revisions, so you can perform gradual rollouts such as canary deployments or blue/green deployments.
• Custom domains – You can set up custom domain mapping in Cloud Run and it will provision a TLS certificate for your domain. 
• Automatic redundancy – Cloud Run offers automatic redundancy so you don’t have to worry about creating multiple instances for high availability

How to use Cloud Run

With Cloud Run, you write your code in your favorite language and/or use a binary library of your choice. Then push it to Cloud Build to create a container build. With a single command—“gcloud run deploy”—you go from a container image to a fully managed web application that runs on a domain with a TLS certificate and auto-scales with requests.

How does Cloud Run work?

Cloud Run service can be invoked in the following ways:

HTTPS: You can send HTTPS requests to trigger a Cloud Run-hosted service. Note that all Cloud Run services have a stable HTTPS URL. Some use cases include: 

• Custom RESTful web API
• Private microservice
• HTTP middleware or reverse proxy for your web applications
• Prepackaged web application

gRPC: You can use gRPC to connect Cloud Run services with other services—for example, to provide simple, high-performance communication between internal microservices. gRPC is a good option when you: 

• Want to communicate between internal microservices
• Support high data loads (gRPC uses protocol buffers, which are up to seven times faster than REST calls)
• Need only a simple service definition you don’t want to write a full client library
• Use streaming gRPCs in your gRPC server to build more responsive applications and APIs

WebSockets: WebSockets applications are supported on Cloud Run with no additional configuration required. Potential use cases include any application that requires a streaming service, such as a chat application.

Trigger from Pub/Sub: You can use Pub/Sub to push messages to the endpoint of your Cloud Run service, where the messages are subsequently delivered to containers as HTTP requests. Possible use cases include:

• Transforming data after receiving an event upon a file upload to a Cloud Storage bucket
• Processing your Google Cloud operations suite logs with Cloud Run by exporting them to Pub/Sub
• Publishing and processing your own custom events from your Cloud Run services

Running services on a schedule: You can use Cloud Scheduler to securely trigger a Cloud Run service on a schedule. This is similar to using cron jobs. Possible use cases include:

• Performing backups on a regular basis
• Performing recurrent administration tasks, such as regenerating a sitemap or deleting old data, content, configurations, synchronizations, or revisions
• Generating bills or other documents

Executing asynchronous tasks: You can use Cloud Tasks to securely enqueue a task to be asynchronously processed by a Cloud Run service. Typical use cases include:

• Handling requests through unexpected production incidents
• Smoothing traffic spikes by delaying work that is not user-facing
• Reducing user response time by delegating slow background operations, such as database updates or batch processing, to be handled by another service, 
• Limiting the call rate to backend services like databases and third-party APIs

Events from Eventrac: You can trigger Cloud Run with events from more than 60 Google Cloud sources. For example:

• Use a Cloud Storage event (via Cloud Audit Logs) to trigger a data processing pipeline 
• Use a BigQuery event (via Cloud Audit Logs) to initiate downstream processing in Cloud Run each time a job is completed

How is Cloud Run different from Cloud Functions?

Cloud Run and Cloud Functions are both fully managed services that run on Google Cloud’s serverless infrastructure, auto-scale, and handle HTTP requests or events. They do, however, have some important differences:

• Cloud Functions lets you deploy snippets of code (functions) written in a limited set of programming languages, while Cloud Run lets you deploy container images using the programming language of your choice. 
• Cloud Run also supports the use of any tool or system library from your application; Cloud Functions does not let you use custom executables. 
• Cloud Run offers a longer request timeout duration of up to 60 minutes, while with Cloud Functions the requests timeout can be set as high as 9 mins. 
• Cloud Functions only sends one request at a time to each function instance, while by default Cloud Run is configured to send multiple concurrent requests on each container instance. This is helpful to improve latency and reduce costs if you’re expecting large volumes. 

Pricing

Cloud Run comes with a generous free tier and is pay per use, which means you only pay while a request is being handled on your container instance. If it is idle with no traffic, then you don’t pay anything.

Conclusion

After learning about the ease of set up, scalability, and management capabilities of Cloud Run the Mindful Containers team is using it to deploy stateless microservices. If you are interested in learning more, check out the documentation.https://www.youtube.com/embed/oR4btKLRdn4?enablejsapi=1&

For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev

Why do we keep talking about security all the time? Why hasn’t anyone just gone and fixed it?

You’ve probably heard these questions, whether from your leadership, or a board member or just from friends. Then you labor at explaining why security in the cloud is so complex and challenging, the constant arms race, and eventually, their eyes glaze over. But you’re right: It is complex, and it can be hard. 

As a security leader today, you likely spend a lot of your time focused on getting information: what’s going on, what new vulnerability just surfaced, what threats are present in your environment, and how to remediate them. And you probably already have a few dozen tools in place to measure, analyze, collect, and search through your data. 

Right now, with your set of existing tools, you hopefully have a good sense of your on-prem systems and your overall attack surface. But across all those datasets, you’re juggling incongruous access patterns, stale data, and cluttered information coming from disparate tools—it’s not organized by topic, risk, or project. So unifying and rectifying the data sources, to really give you a full picture, just doesn’t happen.

Then you add cloud systems to the mix, and it’s a whole ‘nother ball of wax. We wanted to detail a few security features we’ve developed—most recently Event Threat Detection, available today in beta—and highlight some information that can help you reduce the complexity of your organization’s security, and improve your security posture.

Gain visibility and control, and prevent threats
With Cloud Security Command Center (Cloud SCC), Google brings a flexible platform to give you wide visibility and rapid response capabilities. Beyond just risk and vulnerability management, Cloud SCC focuses on active defense, showing you threats that have been detected and the path to greater holistic security in your cloud resources.

It integrates with existing partner security solutions you already use and Google Cloud security tools. And its API is accessible to you and your vendors, so any additional data is easy to integrate.

The model above is a centralized dashboard for threat prevention, detection, and response, with views of your current state that you can change based on your needs. For example, you can focus on assets to get a comprehensive list of every firewall, network, disk, bucket, and so on in your organization. 

You can also orient your view based on findings (results) of what’s wrong in your Google Cloud Platform (GCP) environment. We recently launched the Vulnerabilities dashboard to show findings from Security Health Analytics. It’s an integrated security product that helps you identify misconfigurations and compliance violations in your GCP resources and take action.

Reduce threat exposure with Event Threat Detection
Reducing your exposure to threats goes hand-in-hand with being able to respond quickly to those threats that are present in your environment. Today, we’re excited to announce the beta of Event Threat Detection, a security product that integrates into Cloud SCC, and was inspired by how Google protects itself. We wanted to extend our scale and threat intelligence to help you protect your environment and improve your security posture. 

Event Threat Detection helps you detect threats in your logs and send high-risk threats to your SIEM (Security Information and Event Management system) for further investigation. It also can help you save time and money by focusing your attention on the most worrisome cloud-based threats. 

Due to the growth in cloud computing, we’ve seen an increase in the number of customers running VPC Flow logs, Cloud DNS logs, Cloud Audit logs, and syslog delivered via the fluentd agent on GCP. Event Threat Detection uses Google’s threat intelligence to surface threats present in these logs, including anomalous IAM grants, malware, cryptomining, outgoing DDoS, and brute-force SSH. 

When Event Threat Detection finds a threat in your logs, it shows up as a finding on the Cloud SCC dashboard. If you need to further analyze any of these threats, you can send them to your SIEM, saving time and money because Event Threat Detection has already determined the high-risk logs you need to investigate further. 

Event Threat Detection integrates with Cloud Functions to make it easier for you to export findings to your SIEM of choice. You can also use Cloud Functions to automate responses and changes to Event Threat Detection findings. See the video below for more information.

Respond to threats
Once threats have been detected, the final step is, obviously, responding to them. To help speed up your response game, you can set up automated actions for when threats are detected. When Cloud SCC detects an anomaly, or an active threat, you can have it change a VM configuration, perhaps cutting the VM off from other parts of your network.

You can also change firewall rules automatically. Using these events to trigger Cloud Functions, you can set up any response you like, fully automated. At the same time, you can send incident metrics and data to Stackdriver or your own SIEM to make sure your incident response team has everything they need.

Together, these features give you the power to structure and organize the data you gather, which is key to making cloud security work for large, mature organizations. Cloud SCC lets you create tags for items to assist with incident response or project-based inquiry, and to aid in custom dashboard creation. The constant goal: give you the information you need quickly, so you can take the necessary action.

Cloud SCC details
Now that you have a high-level view of how Cloud SCC and Event Threat Detection can help your organization become more secure, here are some other resources highlighting Google security features that integrate into Cloud Security Command Center, how they work, and how they can help you improve your security posture:

• Find and fix misconfigurations in your Google Cloud resources with Security Health Analytics
• Stop data exfiltration with Cloud Data Loss Prevention
• Detect and remediate security anomalies with Cloud Anomaly Detection
• Catch web app vulnerabilities before they hit production with Cloud Web Security Scanner

These blogs feature step-by-step instructions with screenshots, and each has a companion video. Check them out, and let us know if there are any other issues and solutions you’d like us to detail.  

With unemployment application submissions reaching record numbers over the past year, state and local agencies in the United States have faced the challenge of processing unprecedented numbers of claims per week. The digital infrastructure most agencies have in place is unable to handle this volume, resulting in constituents waiting longer, and bad actors taking advantage of vulnerable systems. The Department of Labor Inspector General estimates that $63 billion in claims distributed is either an improper payment or fraud. 

Validating claims also requires secure data sharing with other agencies for document and identity verification. Government leaders need a way to allow case adjudicators to quickly and confidently release backlogged claims, integrate with existing systems, and segment legitimate claims from potentially fraudulent ones — all within limited government budgets — securely and at scale.

Implementing a fraud detection solution on Google Cloud

States were under pressure to release payments, while also filtering out potentially fraudulent claims. SpringML and Google Cloud developed a framework to give adjudicators a reliable verification process that quickly filters potentially fraudulent claims, while processing the remaining claims so benefits reach citizens in a timely manner. SpringML and Google Cloud, applied AI-powered machine learning models to detect anomalous patterns in large datasets. Using Google Cloud tools, SpringML implemented a solution to streamline workflows, improve efficiencies, automate processes and identify potentially fraudulent claims.

SpringML used a variety of Google Cloud products to deliver a fraud detection solution, including:

• Google Cloud Storage to store and manage data
• BigQuery to store tabular data and BigQuery Machine Learning (BQML) to conduct machine learning on that data
• AutoML solutions to build predictive models and risk scoring
• Visualization tools such as Looker and Data Studio to present data and help government leaders make informed decisions.

Implementing machine learning to detect improper payments allows agencies to classify claims as “fraud” or “not fraud” based on the number of flags, as well as prioritize the most urgent claims. Deploying intelligent virtual agents to handle frequently asked questions meant that live agents could focus their time on more challenging cases. 

Even once the pandemic is behind us, there will be bad actors trying to take advantage of overwhelmed or legacy systems. We’ve identified a few best practices for agencies managing enormous case loads and looking to improve improper payment analytics: 

• Move your systems to the cloud. Many on-premises legacy systems can’t update their applications and scale to meet the volume of claims. Moving to a cloud environment enables rapid solution deployment and ingestion of large amounts of data without fear of overloading the system. The cloud scales with you–cost-effectively and securely. 
• Understand patterns in the data. The answer is always in the data — we used deep analysis to help uncover suspicious patterns in large data sets. We implemented unsupervised machine learning to learn behaviors and create configurable rules that adjust to new information that comes into the system. We can uncover patterns that are likely associated with fraud – ones that a human might have missed. 
• Use AI/ML tools to automate your existing systems and teams. These tools enable humans to work smarter and more efficiently. We automate anomaly detection and create dashboards for adjudicators to rapidly process claims. We are enabling the Wisconsin Department of Workforce Development by implementing automatic calculations and processing of recharge amounts, resulting in faster processing times and fewer human errors. Proactive fraud detection and timely calculation of recharge payment allowed DWD to ensure the benefits reached the right individuals.
• Build flexibility into your systems. We discovered that fraud patterns change over time. For instance,flags for fraud during March-May 2020 were vastly different from those we found in June-July 2020. Google Cloud tools make it easy to continually update algorithms to detect patterns and integrate external data sources.

Using Google Cloud tools, we can update digital infrastructure and incorporate machine learning best practices to help organizations efficiently process large volumes of claims and identify high probability fraudulent ones. SpringML provides consulting and implementation services and industry-specific analytics solutions that deliver high-impact business value to accelerate data-driven digital transformation. Learn more about fraud detection and how to improve improper payments analytics by watching our webinar. 

Together we can solve for the future of cloud security. Join us to learn how you can stay ahead of the next generation of threats with Google Cloud – whether you need to keep your organization secure in the cloud, on-premises, or in a hybrid environment. Get fresh insights from industry leaders and engage in interactive sessions that can help you solve your most critical security challenges. 

Our digital event has ended, but you can still explore our sessions on demand.
The Security Summit is part of our digital Google Cloud Summit series. Check out the other events in the series to explore Google Cloud technology applications in various industries and dive into our latest digital innovations.Original air date:20 July 2021 21:30 Register to watch on demand.