Category: Google Cloud

As the frequency and sophistication of cyberattacks on cloud platforms continue to rise, leading service providers are taking significant steps to bolster security and protect user data. Google, the global leader in search and cloud services, has announced a major security policy change for its Google Cloud platform. The company revealed that, by the end of this year, all users will be required to implement Multi-Factor Authentication (MFA) in order to maintain access to their services. Failure to comply will result in account termination.

This decision, which was made public in August 2023, comes on the heels of a critical report issued by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The report highlighted a troubling vulnerability in cloud accounts that rely solely on password-based security, making them susceptible to a range of cyber threats such as phishing, credential theft, and cryptomining attacks.

According to CISA’s findings, accounts secured with Multi-Factor Authentication are 99% less likely to be compromised, a statistic that underscores the effectiveness of MFA in safeguarding sensitive data. In response to these findings, Google’s move to make MFA mandatory for all Google Cloud users is being seen as a proactive measure to strengthen cloud security across its platform.

Phased Rollout of Mandatory MFA

In a recent blog post, Google outlined the three-phase implementation strategy for its new MFA requirement. The rollout will be gradual, ensuring that users have ample time to transition and adapt to the updated security protocols.
   

1. Phase One: Notification and Awareness (Starting November 2024)
      

Beginning in November 2024, all Google Cloud users will receive notifications informing them of the upcoming MFA mandate. These notifications will not only alert users to the new policy but will also provide step-by-step instructions on how to enable MFA on their accounts. The company is committed to raising awareness and guiding users through the process before the end of the year.
   

2. Phase Two: Full MFA Requirement for Google Cloud Users (By March 2025)
      

By March 2025, the use of Multi-Factor Authentication will be fully enforced for all Google Cloud users. Once this phase is active, users will be prompted to enable MFA whenever they log into their accounts using a password. To assist in this transition, detailed guidance on how to configure MFA will be available through the Google Cloud Console, Firebase Console, and other key platforms within the Google Cloud ecosystem.
   

3. Phase Three: Mandating MFA for Federal Users (By November 2025)
      

The final phase, which will take effect by November 2025, will extend the MFA requirement to federal users of Google Cloud services who access the platform via third-party applications, such as WhatsApp. This will mark the complete phasing out of single-password authentication across Google’s cloud services for all users, with MFA becoming the default security measure.

Industry-Wide Shift Toward MFA and the End of Password-Only Authentication

Google’s move to require MFA is not an isolated effort. Amazon Web Services (AWS) and Microsoft Azure are also preparing to roll out similar measures by March 2025. These tech giants are following a broader industry trend that is increasingly moving away from traditional password-based security in favor of more robust authentication methods, such as biometrics, hardware tokens, or one-time passcodes.

The drive to eliminate passwords is gaining momentum, with experts predicting that, within the next few years, most major technology companies will phase out passwords entirely. As cyber threats continue to evolve, the industry is recognizing that password-only security is no longer sufficient to protect sensitive data and systems.

The Future of Cloud Security: A Password-Free World?

The shift to Multi-Factor Authentication is a significant step forward in securing cloud services against emerging threats. By requiring multiple forms of verification, MFA drastically reduces the likelihood of unauthorized access, providing an additional layer of protection for users. As cloud platforms become an increasingly integral part of our digital infrastructure, it is clear that the future of online security will involve more than just a password.

As Google, Amazon, Microsoft, and others work toward a password-free future, the hope is that this move will lead to stronger, more resilient cybersecurity practices, making it much harder for cybercriminals to breach accounts and steal valuable data.

The post Google Cloud makes MFA mandatory for all global users by 2025 appeared first on Cybersecurity Insiders.

At the annual Google Cloud Security Summit, Google announced a major enhancement in its security offerings, emphasizing a streamlined approach through a convergence theme. This new strategy aims to significantly improve security programs and postures by automating core security functions such as detection, analysis, and response, while also integrating risk management. The goal is to protect critical applications and data, which have become crucial for business operations.

In today’s landscape, data theft malware and credential theft are prominent security threats in cloud environments. For organizations relying on outdated systems, maintaining compliance and managing these risks can be especially challenging.

To address these complex issues, Google Cloud is focusing on integrating new security and privacy products designed to counter newly identified threats. The company plans to leverage convergence technology to seamlessly integrate security tools into existing systems without disrupting current operations.

The summit also featured discussions about CrowdStrike, which had been implicated in a global IT disruption experienced by Microsoft in July 2024. In response, Daniel Bernard, the head of CrowdStrike, announced that his company would collaborate with Google to enhance cloud security through the deployment of Falcon Cloud Security.

Currently, CrowdStrike supports 9-10 products and services that integrate with Google SecOps. Starting in September, data will be routed through the Falcon Platform, enabling Google’s Incident Response team to work more efficiently with Mandiant to address security breaches.

Supporting these efforts will be Zscaler’s Zero Trust Security, which will aid enterprises in securing endpoints using telemetry signals from Chrome Enterprise Browsers. This will simplify device security verification, enhance cyber threat detection, and safeguard sensitive applications.

Additionally, Google Cloud will offer confidential Virtual Machines designed to protect data and applications through memory-based encryption, adding an extra layer of security through hardware.

The post Google Cloud to offer enhanced security with Simplicity and Convergence appeared first on Cybersecurity Insiders.

In early May, the internet was rocked by news of Google supposedly deleting a pension fund account worth $125 billion. Users of the Australia-based UniSuper pension fund’s systems suddenly had issues accessing their accounts for around a week. More than 600,000 pension fund members were affected.

Expectedly, many assumed it was a cyber attack. Several high-profile breaches such as the Maersk ransomware incident have involved major data losses that resulted in operational disruptions. It eventually became clear, though, that the problem was an undiscovered bug that could easily be exploited by threat actors. It is a vulnerability Google was unaware of and did not expect to be possible.

Google fixed the problem around mid-May and posted an explanation about what happened. However, there is an interesting take on the incident that merits some scrutiny: the possible role of IaC management tool Terraform. A New Zealand-based senior software developer shared interesting theories based on his experiences with Google Cloud’s professional services team, pointing to the possible unintended effects of Terraform commands.

Google’s Explanation

In a blog post on May 25, Google detailed how the incident actually happened. The company clarified that the incident only affected one customer in a single cloud region, referring to UniSuper. Specifically, the problem was limited to only one of the customer’s multiple Google Cloud VMware Engine (GCVE) private clouds. The event, Google said, did not impact other Google Cloud services, customer accounts, projects, and data backups.

After Google’s internal investigation, the cloud service provider concluded that the incident happened because of misconfiguration. The company traced this error to an initial deployment of a Google Cloud VMware Engine (GCVE) private cloud by a customer who used an internal tool. There was an issue in the parameter configuration, which resulted in the unintended and undesired consequence of capping the customer’s GCVE private cloud to a fixed term.

Google maintains that their operators, the people responsible for managing and deploying Google Cloud services, acted in line with the company’s internal control protocols. The UniSuper incident was the first problem of its kind they encountered, suggesting that they did not expect that an input parameter left blank could result in the deletion of a private cloud.

Google explained that the blank parameter prompted the system to assign a then-unknown default term. The investigation revealed that this term is for one year, which means that the GCVE private cloud was unwittingly set to terminate after a year. There were no notifications sent to the customer because the deletion was not brought about by a customer request. It was triggered as a consequence of a parameter left blank by Google operators.

The blog post by Google implicitly cleared UniSuper of any fault, saying that it was a Google Cloud issue through and through. A joint statement was released by UniSuper and Google, characterizing the incident as an isolated “one-of-a-kind occurrence” that was not supposed to have taken place.

Was ‘Terraform Destroy’ Truly the Culprit?

As researchers pointed out, it seems that the internal tool used by Google’s operators is Terraform. Commonly used for infrastructure-as-code (IaC) management, Terraform supports a command called ‘destroy,’ which is crucial for infrastructure management. DevOps managers can use Terraform destroy on a specific resource or multiple resources at once.

Using this command requires caution, as it can result in the irreversible removal of an infrastructure component. An accidental execution of the command over unintended resources can easily lead to an outage.

As mentioned in Google’s blog post, the unintended deletion happened because of a blank parameter inadvertently introduced. In this sense, the deletion was akin to the detonation of a long-running time bomb set a year prior (the one-year system-assigned expiration of the private cloud). With these details from Google, it seems highly unlikely that the high-profile mishap was caused by an imprudent use of the Terraform destroy command after all.

If a destroy command had been involved, the situation would have warranted a very different type of explanation. Instead of the fault entirely falling on Google’s operators, the problem would have originated from UniSuper’s own cloud provisioning managers. In this scenario, UniSuper would have applied a Terraform configuration file containing an instruction to remove a private cloud via the destroy command, with Google operators immediately approving it.

Cybersecurity Concerns

Despite the indications that it likely wasn’t careless use of the destroy command that caused the UniSuper outage, it is still worth discussing how important it is to be mindful of Terraform destroy. Threat actors can take advantage of it as they exploit bugs to delete resources and disrupt operations.

There are three possible scenarios where the destroy command can be indirectly triggered, and all of them involve bugs.

In the first scenario, failure to address bugs or issues in Terraform configuration files can wreak havoc during the Plan and Apply phases. These configuration file bugs may cause the unintended marking of resources for deletion. For example, poorly thought-out conditional statements or corrupted configuration files may inappropriately target certain resources for removal.

In the second scenario, organizations may be using external tools that interact with Terraform. These can include cloud provider APIs and provisioning scripts, which may have bugs that prompt them to inadvertently delete resources when they should not. There are cases where Terraform may call for these scripts, usually during configuration changes. If these are applied, the undesirable outcomes can be serious.

Lastly, if organizations use third-party providers to interact with cloud services and platforms, there is always the possibility that these tools can be misused to bring about misinterpretations during the apply phase and even during planning.

To prevent bugs and other cyber issues from using the destroy command to delete resources, it is important to regularly test configurations before applying them. IaC code reviews should also become a routine activity. Moreover, it is important to ensure the quality of the external controls being used and to always be updated with the latest bug fixes and security patches. Finally, the principle of least privilege should be enforced and regular data backups should always be readily available to expedite restoration efforts.

In Summary

To recap, the Terraform destroy command ultimately didn’t cause the UniSuper Google Cloud outage. The incident happened because of a blank parameter that was left unnoticed and unaddressed. Google’s team did not anticipate that the tool they were using would autonomously assign values that could lead them to trouble one year later.

There are still so many things to discover, learn, and understand about modern IT technologies, particularly when it comes to cloud configurations and management. For security teams, collaborating with DevOps armed with a thorough understanding of Terraform commands, is important for maximizing workflow efficiency, uptime and security.

The post Did ‘Terraform Destroy’ Cause the UniSuper Google Cloud Outage? appeared first on Cybersecurity Insiders.

New integration provides SOC teams with rich cloud context they need to detect and investigate threats in the cloud

 

SAN JOSE, Calif., 26 October 2022 – Lacework, the data-driven cloud security company, today announced a new integration with Google Cloud’s Chronicle Security Operations, bringing its cloud-native application protection platform (CNAPP) capabilities to Chronicle deployments. By tapping into rich multi cloud runtime alerts from the Lacework Polygraph Data Platform, organizations using Chronicle Security Operations gain better insight into cloud threats, helping them understand, respond to, and remediate incidents more effectively than ever before. Lacework fully integrates multicloud runtime telemetry with Chronicle Security Operations.

 

SOC teams that rely on legacy security solutions, which are based on static, manually-written rules, can’t keep up with the rate and scale of changes in cloud environments. They are then forced to spend an increasing amount of analyst time and energy sifting through an overwhelming volume of low-context alerts. SOC teams need a modern threat management solution that can keep up with the constantly changing nature of the cloud, and allows them — and their company overall — to operate and innovate effectively at scale. 

 

With this integration, organizations using Chronicle Security Operations can now access runtime alerts and anomalous activity from multi cloud environments, generated by the Lacework Polygraph Data Platform. The Lacework Polygraph Data Platform uses automation to provide teams with an improved signal-to-noise ratio compared to traditional solutions that are not built for the cloud, without the need for manual intervention. The addition of these high-context alerts allows SOC teams to quicken investigation and remediation, and closes the gap between SOC and security teams by embedding Lacework into security playbooks.

 

“Enterprises transforming their security strategies for the cloud require technologies that easily deliver comprehensive visibility across their multi cloud environments,” Sunil Potti, VP/GM of Security, Google Cloud. “Lacework’s integration with Chronicle Security Operations enables organizations to detect and address the right threats via contextual insights that matter the most across their diverse environments.”

 

Key capabilities of this integration include:

  • Anomaly detections from Lacework, including the cloud control plane, audit logs, cloud, and container instances for Google Cloud, AWS, and Microsoft Azure are all shared with Chronicle Security Operations.

  • Using Chronicle’s Universal Data Model parsers, customers can easily onboard this integration within their existing Chronicle instance.

  • Customers will be able to create automation, orchestration and response playbooks using Chronicle SOAR to quickly react to and address issues.

 

“Cloud threats are only becoming more sophisticated over time, so it’s critical for security teams to have the right context to make the right decisions to remediate issues quickly,” said Jay Parikh, co-CEO, Lacework. “Through our continued partnership with Google Cloud, we’re making it easier for joint customers to take advantage of the richness of Lacework data so they can get a better understanding of what’s happening across their multi cloud environments and continue to innovate with confidence.”

 

The Lacework integration with Chronicle Security Operations will be available to organizations via Google Cloud Marketplace. 

 

About Lacework

 

Lacework is the data-driven security company for the cloud. The Lacework Polygraph Data Platform automates cloud security at scale so our customers can innovate with speed and safety. Only Lacework can collect, analyze, and accurately correlate data across an organization’s cloud and Kubernetes environments, and narrow it down to the handful of security events that matter. Customers all over the globe depend on Lacework to drive revenue, bring products to market faster and safer, and consolidate point security solutions into a single platform. Founded in 2015 and headquartered in San Jose, Calif., Lacework is backed by leading investors like Sutter Hill Ventures, Altimeter Capital, D1 Capital Partners, Tiger Global Management, Counterpoint Global (Morgan Stanley), Franklin Templeton, Durable Capital, GV, General Catalyst, XN, Coatue, Dragoneer, Liberty Global Ventures, and Snowflake Ventures, among others. Get started at lacework.com.

The post Lacework Brings Its CNAPP Solution To Google Cloud’s Chronicle Security Operations appeared first on Cybersecurity Insiders.