In a whitepaper titled Data Deletion on Google Cloud Platform, the company explains how the process is designed to ensure safe and effective deletion of data from active systems, backup volumes and physical storage media.

Generally, prior to deletion all customer data on Google cloud is encrypted at rest, replicated on active systems to ensure uninterrupted availability and copied to backup systems as protection against loss and to ensure data integrity.

Enterprises can ask for their entire account to be deleted, or just the data associated with a specific cloud project or resource. When any data is flagged for deletion, Google marks it as deleted and makes it unavailable for further use. However, the company implements a grace period before beginning to actually logically delete the data to ensure that organizations have a way to recover anything that may have been deleted by mistake, Google said in its whitepaper.

After the grace period has ended, Google uses one of two methods to delete data from active systems—cryptographic erasure and what it calls a mark-and-sweep garbage collection process where the deleted data is completely overwritten over time. Google uses a similar process of overwriting data or using cryptographic methods for deleting customer data from backup storage.

“Long after deletion has occurred, the final step in assuring deletion is to securely decommission our physical storage media,” said Eric Chiang, product manager with Google’s cloud security and privacy group.

Google’s media sanitization process is designed to ensure that deleted data on decommissioned storage media is completely irrecoverable through forensic or laboratory attacks. Hard drives that have been retired are overwritten with zeros and go through a multistep inspection process to ensure they contain no recoverable data.

All physical storage equipment with the company’s data centers is tracked—via asset tags and bar codes—from acquisition and installation through destruction. According to Google, it also employs a slew of methods, such as metal detection, biometric identification, laser-based intrusion detection systems and vehicle barriers, to prevent equipment from leaving its data centers in unauthorized fashion.

In instances where a storage media cannot be securely erased, Google physically destroys it by either crushing and deforming the drive or shredding it to bits before recycling.

Google’s latest whitepaper is part of an ongoing effort by the company to inform enterprises about the measures it takes to ensure that enterprise data is securely handled in the cloud. Although organizations have been moving more workloads to the cloud in recent years, concerns about unauthorized access and data leaks continue to persist and, in many cases, hamper cloud adoption.

Just earlier this week, Google released another whitepaper, this one describing the company’s process for responding to incidents involving the confidential, integrity and availability of customer data on Google Cloud Platform. Recently, the company also released a new tool that gives enterprises a way to monitor any access to their cloud workloads by Google administrators and support staff.

The post Google Releases Details on Its Cloud Data Deletion Process appeared first on eWEEK.

With it, organizations can better organize and manage data from all of the tools used to monitor workloads in the cloud, such as Stackdriver Kubernetes Monitoring, Stackdriver APM and OpenCensus. The goal is to enable visibility into workloads regardless of whether it is running on GCP, a hybrid environment or elsewhere.

“Workspaces can track your existing GCP projects, which form the basis for managing permissions and resources within GCP,” said Mary Koes, product manager, and Charles Baer, a solutions architect at Google, in a blog Sept 12. It can also be used to track any AWS accounts that an organization might want to monitor, the two Google managers said.

As one example, they pointed to a situation in which a business has an application with components split across different projects in GCP and AWS accounts. In such a situation, Stackdriver Workspaces will allow them to monitor all of the application’s resources across the two environments via a single pane of glass.

A Workspace contains dashboards, alerting policies, uptime checks and group definitions that members accessing it can use to monitor projects running on Google cloud and AWS. Enterprises can organize access to Stackdriver Workspaces in a variety of ways. The most common are by team function, by organization and by environment, Koes and Baer said.

When access is organized by team function, members of separate teams, like operations and testing, have their own Workspace to monitor environments relevant to their roles.

When access is provisioned by organization, administrators can use a single Workspace to monitor all projects within that organization. One use case for enabling access by organization is to support centralized logging and monitoring of cloud resources. “This approach provides a single Workspace to aggregate, filter and alert on all the monitoring metrics,” Koes and Baer wrote.

Organizing Workspaces by environment allows different functions such as development and production to have separate Workspaces relevant to their specific roles in a project.

A Stackdriver Groups functionality gives enterprises a way to group and to monitor a set of similar resources such as virtual machine instances, load balancers and databases. Administrators can also group resources based on their own custom criteria. For instance, they can group and monitor resources by name, applications, region, tags and other criteria. Stackdriver supports the creation of and monitoring of a subgroup such as a single microservice.

To help organizations better understand Stackdriver Workspaces and how to get started on it, Google is offering a free online tutorial that will be available through the end of September. Over the next several months, Google will also be adding new functionality and training features to help enterprises use Workspaces, Koes and Baer said.

The post Google Announces Stackdriver Workspaces for Monitoring Cloud Resources appeared first on eWEEK.

The paper shows that Google has implemented a four-phased approach for responding to data incidents, which it describes as a breach of Google security that results in the disclosure, alteration or destruction of customer data in its care.

The first stage involves incident identification. This is the stage when Google’s automated and manual processes detect potential vulnerabilities and incidents and report it back to Google’s incident response team.

The second phase involves response coordination. Members of a triage team evaluate the incident report, make an initial assessment of its severity and assign an incident commander to lead the response. The commander is responsible for assembling an incident response team from relevant groups, based on a more detailed assessment of the original incident report.

At this point the response process shifts to the incident resolution phase. Members of the response team are responsible for investigating the incident, gathering relevant facts and figuring out what additional resources might be necessary to contain the incident.

A designated operation lead is responsible for implementing measures to contain damage, fix the issue that caused the breach, and restore impact systems and services. A communication lead separately assesses the incident to determine if the breach triggered any notification requirements and develops a communication plan if that indeed happens to be the case.

The fourth phase is when members of the response team assess the incident and the response to it to see if there are any lessons to be learned and to be applied from them.

Google’s incident response team itself comprises members from across multiple specialized functions. It can include members that are specialists in cloud incident management, site reliability engineering, cloud security and privacy, signals detection, digital forensics, customer support and legal.

“Every data incident is unique, and the goal of the data incident response process is to protect customers’ data, restore normal service as quickly as possible, and meet both regulatory and contractual compliance requirements,” said Noela Nakos, lead technical program manager at Google, in a blog Sept. 12.

Effective response is key to managing and recovering from incidents and preventing future ones. The combination of subject matter experts and the processes that Google uses ensures that incidents are mitigated quickly, Nakos said.

Importantly, Google has also implemented a continuous improvement process as part of its incident response program. The goal is to use each incident to gain new insights for preventing such incidents and to improve the tools and processes that Google uses to ensure the security and privacy of customer data, Nakos noted.

Google’s efforts at greater transparency are part of a broader effort to assuage customer concerns about the security of data in the cloud. Just this week, for instance, the company announced general availability of a tool that gives companies a way to monitor and audit access to their data by Google’s administrators and support staff. Google also has for several years now been making available a so-called Transparency Report giving details on requests for customer data by government and law enforcement officials in the United States and elsewhere.

The post Google Outlines Incident Response Process for Cloud Customers appeared first on eWEEK.

Customers of six Google Cloud Platform (GCP) services including Compute Engine, App Engine and Cloud Storage can now use the company’s recently announced Access Transparency Logs to monitor any access to their workloads by Google engineers. 

“Google’s terms of service state we only ever access your data for reasons necessary to provide your service to you,” noted Joseph Valente, a Google product manager in a blog Sept. 11. Access Transparency Logs allows organizations to verify if Google is indeed adhering to this claim, he said. 

 “These logs provide visibility into access at every layer of the stack—not just when access happens through public [Application Programming Interfaces] or high-level endpoints.” 

Analysts consider such visibility important for companies that want to migrate workloads to the cloud, but are wary of doing it because of concerns over improper and unauthorized access to their data by the cloud services provider. 

A survey by HyTrust last year in fact showed that many organizations consider uncontrolled and unmonitored access to their data by cloud administrators as the top risk of migrating workloads to the cloud. 

Google announced Access Transparency Logs entered a beta evaluation phase in March. At the time the company described it as a technology for providing organizations with an audit trail of actions taken by Google’s support and engineering staff when interacting with their data and systems configurations. Such interactions typically occur when a customer calls Google for support and the company opens a ticket to investigate the issue. 

When such interactions do occur, Google customers can get access logs that are generated in near real-time and delivered to their Google Stackdriver Logging console. Administrators will be able to review and take action with the logs as they do with any other cloud audit logs, according to the company. The logs provide information on what resources were accessed and the operations that were performed on those resources along with justification for those actions, Google has noted. 

According to Valente, Google had to expend a considerable amount of effort into delivering the access transparency capability. For example, he noted that Google had to build a binary authorization technology to ensure that any code used to access customer data is properly authenticated. Similarly the company had to build enhanced data protection controls to automatically check the business justifications for accessing customer data. 

Access Transparency Logs are currently available only to organizations that have signed up for Google’s Platinum or Gold enterprise support packages. Such customers can enable the feature automatically with a click of a button in the Google Cloud console, Valente said. 

The post Google’s Cloud Access Transparency Logs Now Generally Available appeared first on eWEEK.

The Cisco Hybrid Cloud Platform for Google Cloud is designed to give enterprises a way to develop, deploy manage and secure applications across both on-premises environments and on Google’s Cloud Platform (GCP). 

Organizations can use the service to enable applications running in the cloud to access on-premises IT capabilities and applications running on-premises to take advantage of cloud infrastructure. Developers will be able to access cloud Application Programming Interfaces while cloud developers can access enterprise APIs and resources.

The flexibility enables enterprises to migrate workloads to the cloud at their pace, said Eyal Manor, vice president of engineering at Google Cloud in a blog Sept. 7.  “Whether they’re cloud-ready or modernizing their infrastructure on-premises, many businesses can benefit from a well-supported path that lets them move to the cloud on their own terms,” Manor said. 

According to Manor, the hybrid offering will allow developers to tap capabilities such as Kubernetes cloud container management technology, GCP service catalog and Cisco’s portfolio of network and security configurations to develop apps capable of running optimally in hybrid environments. The idea is give developers a way to write applications once and deploy them anywhere using their choice of operating system, hypervisor, software, and management tools. 

Specific areas where enterprise can benefit from the partnership include orchestration and lifecycle management of applications; managing network security policy and application monitoring and better service management across hybrid environments the two companies had noted in October. 

Customers will also be able to use Google’s Apigee API management technology to let workloads running on-premise to connect to the cloud and tools from Cisco’s Developer Center to write code for hybrid environments. 

Manor pointed to several examples of how such capabilities can help enterprises. One use case for the hybrid offering is on-premise application modernization. Organizations will be able to take advantage of technologies such as Kubernetes to build and manage cloud-ready apps that they can run on Cisco’s on-premise Hyperflex container-optimized infrastructure. 

Similarly, developers can use the hybrid offering to implement new portable services and manage them centrally using the Istio open-source microservices management technology. Istio is designed to let developers use policy-based controls to discover, connect, secure and manage services in a distributed microservices environment. By using it organizations can deploy microservices in hybrid environments with built-in load balancing, service authentication and monitoring, according to Google. 

The Google and Cisco partnership will also allow enterprises to more securely extend their Cisco security policies and monitoring to applications running in the cloud. 

The hybrid Google and Cisco offering includes hardware software and cloud services components that organizations can purchase separately or together and customize it for their needs, Google has previously noted.

The post Google-Cisco Hybrid Cloud Offering Now Generally Available appeared first on eWEEK.

This week the company announced that it would now start certifying Android devices as being ‘rugged’ under the same program if the devices meet an elevated set of standards for durability and longevity. 

The category is designed to make it easier for organizations to identify products that, in Google’s assessment, are built to handle demanding enterprise workloads over a longer device lifetime than typical devices designed for business use, according to the company. 

“In addition to minimum hardware, OS support and provisioning specifications, we’re adding requirements for drop-testing and ingress protection,” said Jack Weixel, head of global partnerships at Google’s Android group in a Sept 5 blog. For an Android device to be certified as rugged, it will also need to support regular security patching for at least five years, Weixel said. 

In February, Google launched Android Enterprise Recommended. At the time the company described it as an effort to establish certain best practices and minimum requirements for Android devices designed for use in enterprise settings. 

Under the program Google is testing and certifying Android devices as recommended for enterprise use if they meet minimum hardware specifications, are running at least  version Android 7.0 and are available unlocked directly from the manufacturer or reseller. 

For an Android deices to be classified as enterprise recommended the manufacture or reseller also needs to commit to installing security patches on the devices within 90 days of patch release. 

The company has already released an initial list of devices that meet these specifications. The lineup includes multiple Google Pixel models, the Blackberry KEYone, the LG V30 and Sony Xperia XZ1. 

With this week’s announcement device makers and resellers can get their Android devices certified as being rugged if the devices meet a few additional requirements such as the one for ingress-testing and drop testing. 

Rugged devices also need to support at least one additional major OS release and be capable of bulk deployment including through an Android ‘zero-touch’ enrollment feature for large-scale deployment in enterprise settings. 

Devices that have already been certified as rugged include the Zebra TC25, Honeywell Dolphin CT40, Sonim XP8 and Point Mobile PM45. Google is currently working with other manufacturers, such as Panasonic to get more devices validated under the rugged devices program, Weixel said. 

The Enterprise Recommended program is an effort by Google to foster more standardization and adherence to security controls in the Android ecosystem. The Android market, unlike Apple’s tightly controlled iPhone environment is highly fragmented with thousands of device makers delivering products. This has made it hard for enterprises to select products that are truly ready for business use, according to Google.  

By establishing a certification program and minimum requirements for validation, Google is hoping to give enterprises an easier way to identify Android devices that are ready for business use.

The post Google Expands ‘Android Enterprise Recommended’ Mobile Device Program appeared first on eWEEK.

In a report released Sept. 4, the CfA described how it had posed as the Internet Research Agency (IRA), a Russian   that allegedly purchased thousands of dollars worth of ads on Google in 2016 to influence the U.S. general elections. 

According to the CfA, it was able to use rubles and a Russian IP address to buy ads on Google that were very similar in content and tone to the politically divisive ads that the IRA purchased in 2016. 

The CfA said it was able to replicate the IRAs 2016 campaign using a Russian Google AdWords account established with a burner phone from Panama. The watchdog said it had used a Russian name for the account and paid for the ads via Russia’s Yandex payment service. CfA said it had also used a VPN to ensure that any IP number that Google logged would appear to be from St. Petersburg, the city where IRA is based. 

The ads ran on several major US media websites and YouTube channels while Google did nothing to stop them despite all its claims about implementing controls for preventing such misuse, the CfA said. 

“The ease with which CfA was able to replicate the 2016 Russian ad campaign shows Google has failed to keep its promise to prevent foreign actors from interfering in our elections,” CfA executive director Daniel Stevens said in the statement. “Google is more interested in pocketing rubles than protecting American Democracy.” 

Google did not respond immediately to an eWEEK request for comment on the CfA report. But in statements to other media outlets the company said it had implemented numerous controls, technical detection systems and a detailed mapping of accounts to prevent abuse of its channels by foreign trolls. The company claimed that such measures had limited the ability of foreign agents to spread disinformation on Google channels. 

Google also suggested the CfA campaign might have been motivated by business rival Oracle, a firm that is believed to have donated money to the watchdog group. In comments to Business Insider, the company said it had further bolstered ad systems against misuse following what Google claimed was Oracle’s impersonation of Russian trolls. 

“We’d encourage Oracle and its astroturf groups to work together with us to prevent real instances of foreign abuse—that’s how we work with other technology companies,” Google said in its comments to Business Insider. Wikipedia defines “astroturfing” as the practice of masking the real sponsors of a political action group to make look like a true grass roots initiative. 

Oracle for its part claimed that it had no idea what Google was talking about.  “This is the first we’ve heard of this,” the company said in an emailed statement to eWEEK that it attributed to senior vice president Ken Glueck. “Wish we had a ruble for every time Google blamed their problems on us.” 

CfA released its report on the eve of a U.S. Senate Select Committee on Intelligence hearing on foreign influence operators using social media platforms to spread disinformation. 

In prepared comments for the hearing, Google’s chief legal officer Kent Walker on Wednesday outlined several initiatives the company has taken over the past 18 months to curb the misuse of its platforms by foreign operators. 

The highlighted measures included an initiative to identify and remove groups who misidentify and mislead others such as the IRA and other Russian and Iranian-affiliated web misinformation operations. 

The post Watchdog Group Bypasses Google Controls to Buy Divisive Political Ads appeared first on eWEEK.

Google announced the ‘Store Sales Measurement’ tool last year describing it as a technology that would let advertisers’ link online ads with purchases that consumers make offline in brick-and-mortar stores. 

But the company’s relationship with MasterCard was not publicly known till last week when Bloomberg published an investigative report Aug. 30 disclosing how the two companies had reached a secret deal after four years of discussions. 

The arrangement gives Google access to certain data on purchases that consumers have made using MasterCard branded credit and debit cards in the U.S. 

According to Bloomberg, the data that Google purchases from MasterCard allows the company to know how many individuals that clicked on an online ad later ended up purchasing the item in a brick-and-mortar store so advertisers can better measure the effectiveness of their online ads. 

While the new feature has proved beneficial for Google and advertisers so far, there are some broad concerns over the privacy implications of linking a consumer’s online behavior with their offline purchases. Bloomberg quoted the counsel for consumer advocacy group Electronic Privacy Information Center (EPIC) as saying consumers don’t expect what they buy physically to be tracked and linked to their online activity. 

“Google is continually pushing the boundaries of collection, analysis and use of our information, including geo-location [data],” says Jeffrey Chester, executive director of the Center for Digital Democracy, a frequent and long-time critic of Google’s privacy practices. “The Google, MasterCard deal is a new nightmare for how little our privacy is now protected in the U.S.” 

In a statement Google this week reiterated many of the claims it made last year when it first announced the tool. 

“Before we launched this beta product last year, we built a new, double-blind encryption technology that prevents both Google and our partners from viewing our respective users’ personally identifiable information,” the company claimed. 

Google does not collect or have any access to personal information from credit and debit card data. Neither does it have any insight into the purchases that individuals make or the amount they might have spent in a physical store location. Google only learns of the aggregate value of purchases related to a specific product over multiple purchases. 

For example the company noted that an ad campaign with 10,000 clicks, Google might learn that 12 percent of the people who clicked on the ad made a purchase. The advertiser does not learn which individual users clicked on their ads—they only get the aggregate value of sales driven by their ad campaign. 

The company has also maintained that all of the data that it receives from MasterCard and other third parties is encrypted so it cannot identify individuals who make purchases. The company contends that it only uses data that users have agreed can be linked with their Internet activity and that users can withdraw their consent at any time. 

But some privacy groups including EPIC have challenged these claims. In a complaint filed with the U.S. Federal Trade Commission last July the EPIC said Google’s claims about preserving consumer privacy with regard to the in-store sales measurement program needs to be independently verified. 

Google’s reliance on a proprietary and secret algorithm for protecting consumer privacy, and its use of an opaque opt-out facility are unfair and deceptive to consumers, EPIC has claimed.

The post Google Claims MasterCard Data Deal Doesn’t Violate Privacy Rights appeared first on eWEEK.

Google’s AutoML Vision, AutoML Natural Language, and AutoML Translation are part of a broader Cloud AutoML suite of Google machine learning offerings aimed at helping developers train high-quality machine learning models, even if they have only limited prior experience with the technology.  

Google introduced the three tools at its Next ’18 partner conference in San Francisco in July. This week the company announced beta availability of the products along with more details on the technology. 

“This new suite of products aligns with our mission to democratize AI, and make it easy, fast and useful for all developers and enterprises,” said Levent Besik, Google Cloud product manager in a blog Aug. 13. The AutoML tools enable both ease of use and high quality machine learning models, he said. 

Besik described AutoML Vision as a more specialized version of Google’s existing Cloud Vision Application Programming Interface for injecting image analysis capabilities in applications. 

AutoML Vision is a more specialized version of the Cloud Vision API and is designed for developers looking for a way to integrate image classification and analysis capabilities for specific business needs, he said. AutoML Vision allows developers to upload their own image datasets and create custom machine learning models for image analysis. 

AutoML Natural Language is aimed at making it easier for developers to implement natural language processing capabilities in their products. Like AutoML Vision, AutoML Natural Language is a specialized version of Cloud Natural Language, an existing capability for helping embed powerful text analysis into applications. 

The tool helps developers build applications capable of extracting information about people, places and event mentioned in text documents, blog posts and other sources. Google has described the tool as helping developers enable capabilities for doing sentiment analysis in their applications. 

AutoML Translation allows developers to create apps that take advantage of Google’s translation capabilities to create language translation models for their specific domains. For example, an organization could use the technology to build capabilities for translating specific taxonomies for financial news, Besik said. 

Besides the specialized tools, Google is also continuing to develop its Cloud AI APIs. For example, Google has added a handwriting recognition enhancement in the Cloud Vision API that makes it possible for developers to add capabilities in their apps for identifying handwritten text. Enhancements to the Vision API include one feature that enables apps to identify items that are visually similar to a company’s own products. 

Google has also made improvements to its Cloud Text-to-Speech API, including the ability for an app to automatically identify the language being spoken, and the ability to identify and record individual participants in multiple participant conversations. 

The post Google Starts Beta Evaluation of New AI Developer Tools appeared first on eWEEK.

The company on Aug. 8 announced general availability of Spring Cloud GCP 1.0 on its cloud platform. 

The technology, developed in collaboration with Pivotal Research, will allow developers using GCP to more easily build Spring Boot applications, Mike Eltsufin, a Google software engineer and Ray Tsang, a Google developer advocate at the company, stated in an Aug. 8 blog. 

“Spring Cloud lets Java developers write more maintainable applications with less boilerplate code and simpler configuration and that are portable in a hybrid on-premises and cloud-based environment,” they noted. 

Spring is a framework for developing enterprise Java applications. It has been in existence several years and allows developers to use what are known in developer-speak as Plain Old Java Objects or POJO to develop Java applications for use in enterprise settings. 

One of the framework’s core advantages is that it gives developers a way to more easily organize the various objects and classes that make up their Java application so they all work together coherently and as intended. 

According to Pivotal Software, Spring can help speed up Java application development in microservices environments by making it easier for them to tie together disparate and distributed application components. 

Spring Boot from Pivotal is a set of tools for building independent, self-contained Spring applications more quickly. It eliminates many of the tasks that developers normally need to perform when implementing dependencies between loosely coupled objects in Java apps. 

Spring Cloud is built on Spring Boot and simplifies development and deployment of Java apps in distributed microservices environments. Spring Cloud provides a framework that makes it easier for developers to implement configuration management, service discovery, intelligent routing, distribution sessions and other capabilities in distributed apps. 

Google’s new Spring Cloud GCP 1.0 includes several Spring Boot starter integrations—also known simply as starters—for automatically discovering credentials and for configuring services from Google’s cloud environment and other platforms. 

Spring Boot starters are available for GCP services such as Cloud Pub/Sub messaging service, Cloud SQL, MySQL and other database services, Stackdriver Logging and Service Accounts for authentication. 

Developers can use these starters to more easily add new capabilities to their applications, Eltsufin and Tsang stated in blog. For example, by adding the Spring Cloud GCP Logging dependency to their app, developers can ensure that application logs are stored automatically in Stackdriver logging. 

Developers can enable also a distributed tracing capability for their applications by simply adding the Spring Cloud GCP Trace starter, the two Google managers wrote. 

Google is currently working on adding similar Spring Cloud GCP integrations so to make it easier for developers to build applications that take better advantage of Google’s of cloud hosted services, they said. 

Two examples of the new integrations are Spring Data Cloud Spanner for Google’s NoSQL database and Spring Cloud Config runtime configuration Application Programming Interface. 

The post Google Releases Spring Programming Model for Java on Cloud Platform appeared first on eWEEK.