Cloud Computing Köln - Seite 1963 von 7146 - Neues zu Cloud Computing, Internet of Things und Technologien

Google has more than 20 years of experience protecting its core service from Distributed Denial of Service (DDoS) attacks and from the most advanced web application attacks. With Cloud Armor, we have enabled our customers to benefit from our extensive experience of protecting our globally distributed products such as Google Search, Gmail, and YouTube.In our research, we have noticed that new and more sophisticated techniques are increasingly able to bypass and override most of the commercial anti-DDoS systems and Web Application Firewalls (WAF). Credential stuffing is one of these techniques.Credential stuffing is one of the hardest to detect attacks because it’s more like the tortoise and less like the hare. In a slow but steady manner, the attacker exploits a list of usernames and passwords, often first available illicitly after a data breach, and uses automated techniques to force these compromised credentials to give them unauthorized access to a web service. While password reuse habits and the ever-growing number of stolen credential collections are making it easier for organizations uncover and report this type of “brute force” technique to law enforcement and technology providers, today’s credential stuffing attacks often leverage bots or compromised IoT devices to reach a level of scale and automation that earns the attackers far better results than the type of brute-force attacks deployed even a few years ago.Nevertheless, a defense-in-depth approach to cloud security can help stuff even advanced credential stuffing attacks. One technique is to secure user accounts with multi-factor authentication. In case of breach, the extra layer of protection that MFA creates can protect a password exposure from resulting in a successful malicious login. Unfortunately, we know that imposing such a requirement isn’t always appropriate or possible. In case of MFA failure or implementation challenges, additional controls to protect the websites that expose login forms against credential stuffing attacks can be deployed.We outline below how Google Cloud can help reduce the likelihood of a successful credential stuffing attack by building a layered security strategy that leverages native Google technologies such as Google Cloud Armor and reCAPTCHA Enterprise.Google Cloud Armor overviewGoogle Cloud Armor can help customers who use Google Cloud or on-premises deployments to mitigate and address multiple threats, including DDoS attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).Google Cloud Armor’s DDoS protection is always-on inline, scaling to the capacity of Google’s global network. It is able to instantly detect and mitigate network attacks in order to allow only well-formed requests through the load balancing proxies. This product provides not only anti-DDoS capabilities, but allows with a set of preconfigured rules to protect web applications and services from common attacks from the internet and help mitigate the OWASP Top 10 vulnerabilities. One of the most interesting features of Cloud Armor, especially for the credential stuffing attack protection, is the possibility to apply rate-based rules to help customers to protect the applications from a large volume of requests that flood instances and block access for legitimate users.Google Cloud Armor has two types of rate-based rules:Throttle: You can enforce a maximum request limit per client or across all clients by throttling individual clients to a user-configured threshold. This rule enforces the threshold to limit traffic from each client that satisfies the match conditions in the rule. The threshold is configured as a specified number of requests in a specified time interval.Rate-based ban: You can rate limit requests that match a rule on a per-client basis and then temporarily ban those clients for a specified time if they exceed a user-configured threshold.Google Cloud Armor security policies enable you to allow or deny access to your external HTTP(S) load balancer at the Google Cloud edge, as close as possible to the source of incoming traffic. This prevents unwelcome traffic from consuming resources or entering your Virtual Private Cloud (VPC) networks. The following diagram illustrates the location of the external HTTP(S) load balancers, the Google network, and Google data centers.Figure 1.A defense-in-depth approach to credential stuffing protectionIt is important to design security controls in a layered approach without relying only on a single defense mechanism. This strategy is known as defense-in-depth and if correctly applied, allows to achieve reasonable degrees of security. In the following sections we will discuss the layers that can be implemented using Google Cloud Armor to protect against credential stuffing attacks.Layer 1 – Geo-blocking and IP-blockingNon-sophisticated credential stuffing attacks are likely to use a limited number of IP addresses, often traceable to nation states. It is possible to start the defense-in-depth approach trying to identify the regions where the website that has to be protected should be available. For example, if the web is expected to be used only by U.S. users it is possible to set a deny rule using an expression like the following:code_block[StructValue([(u’code’, u”origin.region_code != ‘US'”), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e4f580ebf50>)])]Likewise, it is possible to apply a deny rule to block traffic that is originated by a list of regions, where the application shouldn’t be available. For example, if we want to block traffic from the United States and Italy, it is possible using the following expression:code_block[StructValue([(u’code’, u”origin.region_code == ‘US’ || origin.region_code == ‘IT'”), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e4f3ea9f510>)])]Additionally, it is possible to react to ongoing attacks creating a denylist for IP addresses or CIDRs, with a limit of 10 IP addresses, or ranges, per rule. An example would be:code_block[StructValue([(u’code’, u”inIPRange(origin.ip, ‘9.9.9.0/24′)”), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e4ef9c891d0>)])]While Geo-blocking and IP-blocking are good mechanisms to stop trivial attacks or to limit an attack, there is more that can be done to block attackers. Most of the sophisticated credential stuffing attack tools can be configured with proxies or to use compromised IoT devices to bypass IP-based controls.Layer 2 – HTTP headers Another way to improve defensive configurations is to add additional checks over the HTTP headers of the requests coming to the application. One of the main examples is the user-agent. The user-agent is a request header that helps the application to identify which operating system and which browser are being used usually to improve the user experience. The attackers do not frequently care about helping the application to better serve the user; in an attack scenario the HTTP headers are either completely missing or malformed. Below you can find an example rule to check the user-agent presence and correctness.code_block[StructValue([(u’code’, u”has(request.headers[‘user-agent’]) && request.headers[‘user-agent’].matches(‘Chrome’)”), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e4ef9c89810>)])]HTTP headers can be helpful to further reduce the attack surface, but they also have their limits. They are still controlled on the client side, which means an attacker can spoof them. To achieve maximum security results from configuring HTTP headers, it is necessary to more fully understand the HTTP headers that the application expects to encounter and to properly configure the Google Cloud Armor rule.Layer 3 – Rate Limiting As we’ve noted, the nature of credential stuffing attacks makes them difficult to identify. They are also often associated with password spraying techniques that target not only breached username and password pairs, but also widely-used, known weak passwords (such as “123456.”). Rate limiting protection mechanisms work well in these scenarios to add an additional defensive layer. When we deal with rate limiting, it’s important to identify the standard rate that a legitimate user would have, and to understand the threshold of requests that would be blocked if exceeded. Finding the right balance between security and user experience is often challenging. To help fine-tune rate limiting so that legitimate users are not blocked, Google Cloud Armor’s Preview mode allows security teams to test rate limiting without any real enforcement. In order to minimize user impact, we strongly recommended proceeding in this way followed by an analysis of the test results.Once the preliminary analyses have been completed, it is possible to use Google Cloud Armor to implement rate limiting rules. An example of a rule that applies a ban (which the user sees as a 404 error) of 5 minutes after 50 connections in less than 1 minute from the same IP address would be:code_block[StructValue([(u’code’, u’gcloud compute security-policies rules create 100 \rn –security-policy=sec-policy \rn –action=rate-based-ban \rn –rate-limit-threshold-count=50 \rn –rate-limit-threshold-interval-sec=60 \rn –ban-duration-sec=300 \rn –conform-action=allow \rn –exceed-action=deny-404 \rn –enforce-on-key=IP’), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e4f54690650>)])]When it comes to rate limiting the client identification is fundamental. The IP address could be the first option, but there are cases where it wouldn’t be enough. For example, many Internet service providers use natting techniques to reduce the public IP addresses space needed. Of course, the probability of an IP clash is low, but it is something that should be taken into account when designing the rate limiting thresholds and strategy. Cloud Armor can identify individual clients in many ways such as using IP addresses, HTTP headers, HTTP cookies and XFF-IPs. For example, it is common for mobile apps to be designed to use custom headers with unique values to better identify each client in a reliable way. In this case, it would be appropriate to enforce the client identification based on this custom header rather than the IP address. Below is an example rule based on the custom header ‘client-random-id’.code_block[StructValue([(u’code’, u”gcloud compute security-policies rules create 100 \rn –security-policy=sec-policy \rn –action=rate-based-ban \rn –rate-limit-threshold-count=50 \rn –rate-limit-threshold-interval-sec=60 \rn –ban-duration-sec=300 \rn –conform-action=allow \rn –exceed-action=deny-404 \rn–enforce-on-key=HTTP-HEADER \rn –enforce-on-key-name=’client-random-id'”), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e4f57fb7a50>)])]Layer 4 – reCAPTCHA Enterprise and Google Cloud Armor integrationAn additional level of protection, combined with the previously mentioned techniques, would be the native integration of Google Cloud Armor with reCAPTCHA Enterprise technology.The integration could be made using a rate limiting rule similar to the one described above. Instead of returning a 404 error, it can be configured to redirect the connection to a reCAPTCHA Enterprise challenge at the WAF layer. At this stage the following events take place:Cloud Armor verifies the rate limiting criteria and if exceeded would redirect the connection to reCAPTCHA Enterprise.reCAPTCHA Enterprise performs an assessment of the client interaction and if necessary challenges the user with a CAPTCHA.If the user fails the assessment an error message is returned. If the assessment is passed reCAPTCHA issues a temporary exemption cookie.Cloud Armor verifies the exemption cookie validity and grants access to the site.The following diagram shows the event sequence:Figure 2.ConclusionsCredential stuffing is a non-trivial attack and should be mitigated first with multi-factor authentication mechanisms and user education. Some technical measures can be implemented to apply a defense-in-depth model. Google Cloud Armor should be used to implement security mechanisms such as: Geo-Blocking HTTP Header verificationRate LimitingAnd, as an additional security layer:A combination of reCAPTCHA Enterprise and Google Cloud ArmorThese controls can achieve a reasonable degree of protection against not only credential stuffing attacks, but also brute-force attacks and general protection against bot-driven attacks.Related ArticleBetter protect your web apps and APIs against threats and fraud with Google CloudHow Google Cloud’s Web App and API Protection (WAAP) solution protects enterprises from rising security & fraud threatsRead Article
Quelle: Google Cloud Platform

30. Juli 2022

da Agency

Data Intensive Applications with GKE and MariaDB SkySQL

With Google Kubernetes Engine (GKE), customers get a fully managed environment to automatically deploy, manage, and scale containerized applications on Google Cloud. Kubernetes has become a preferred choice for running not only stateless workloads (e.g. Web Services) but also for stateful applications (e.g. databases). According to the Data on Kubernetes report, over 70% of Kubernetes users run stateful applications in production. Stateful application support within Kubernetes has improved rapidly, and GKE offers extensive support for high-performing and resilient persistent storage and built-in features like Backup for GKE. With stateful applications, customers can choose to adopt a “do it yourself” (DIY) model and deploy directly on GKE or simply use a fully managed database-as-a-service (DBaaS) offering such as Cloud SQL or MariaDB SkySQL. Whatever operating model customers choose, they expect a reliable, consistent experience from applications which means data must be continuously available. MariaDB SkySQL is a DBaaS for applications that demand scalability, availability and elasticity. It’s for customers looking for a cloud-native database that enables them to leverage the openness, resilience, extensibility, functionality and performance of MariaDB’s relational database on public cloud infrastructure. SkySQL delivers flexibility and scalability in a cloud database that keeps up with customers’ changing needs — all while reducing legacy database costs.Together customers get the best of both worlds for modern applications — fully managed compute with GKE for stateless applications and a highly reliable MariaDB SkySQL DBaaS for storing state. Virgin Media O2 serves more than 30 million users via Google Cloud and MariaDB SkySQL databases running all transactions for O2’s network, customer authentication, venue deployment and internal operations, including reporting and analytics.“We need to make informed business decisions because we can easily see and understand what is happening in our environment. We now have a 24×7 platform that’s more efficient, faster and cheaper. Cost was the last thing we looked at, but we’re happy to see the savings. Both OpEx and CapEx were massively reduced by moving everything we did from on-prem into SkySQL, and that savings will continue, on an ongoing basis. We can now always work within our budget and scale as we go.” – Paul Greaves, Head of Engineering, O2 Enterprise and Wifi, Virgin Media UK LimitedMariaDB SkySQL is built on GKE Under the hood, MariaDB SkySQL is built on GKE. DBaas are increasingly running on GKE to benefit from built-in features such as Backup for GKE, cost optimization features to measure unit economics and the portability and openness of Kubernetes. Additionally, to help with ongoing operations commonly referred to as ‘day 2 operations’, which has been a source of toil with stateful applications, customers get safe deployment strategies like Blue-green upgradesand observability. All this means running on GKE brings business agility that makes MariaDB SkySQL easy to deploy and easy to scale as the business grows. “Using GKE has really streamlined the process of operating SkySQL in the cloud,” says Kevin Farley, Global Director Cloud Partners MariaDB Corporation. “SkySQL databases deployed on GKE regional clusters using a Kubernetes operator, provide enterprise customers with maximum security and high availability.” Customers can choose to run databases of all types and sizes directly on GKE, or select managed DBaaS offerings like SkySQL. Increasingly, DBaaS are being built on GKE to deliver as-a-service products, so either way, customers get the power of GKE supporting mission critical applications. Try SkySQL on Google Cloud.
Quelle: Google Cloud Platform

30. Juli 2022

da Agency

Managing the Looker ecosystem at scale with SRE and DevOps practices

Many organizations struggle to create data-driven cultures where each employee is empowered to make decisions based on data. This is especially true for enterprises with a variety of systems and tools in use across different teams. If you are a leader, manager, or executive focused on how your team can leverage Google’s SRE practices or wider DevOps practices, definitely you are in the right place!What do today’s enterprises or mature start-ups look like?Today large organizations are often segmented into hundreds of small teams which are often working around data in the magnitude of several petabytes and in a wide variety of raw forms. ‘Working around data’ could mean any of the following: generating, facilitating, consuming, processing, visualizing or feeding back into the system. Due to a wide variety of responsibilities, the skill sets also vary to a large extent. Numerous people and teams work with data, with jobs that span the entire data ecosystem:Centralizing data from raw sources and systemsMaintaining and transforming data in a warehouseManaging access controls and permissions for the dataModeling dataDoing ad-hoc data analysis and explorationBuilding visualizations and reportsNevertheless, a common goal across all these teams is keeping services running and downstream customers happy. In other words, the organization might be divided internally, however, they all have the mission to leverage the data to make better business decisions. Hence, despite silos and different subgoals, destiny for all these teams is intertwined for the organization to thrive. To support such a diverse set of data sources and the teams supporting them, Looker supports over 60 dialects (input from a data source) and over 35 destinations (output to a new data source).Below is a simplified* picture of how the Looker ecosystem is central to a data-rich organization.Simplified* Looker ecosystem in a data-rich environment*The picture hides the complexity of team(s) accountable for each data source. It also hides how a data source may have dependencies on other sources. Looker Marketplace can also play an important role in your ecosystem.What role can DevOps and SRE practices play?In the most ideal state, all these teams will be in harmony as a single-threaded organization with all the internal processes so smooth that everyone is empowered to experiment (i.e. fail, learn, iterate and repeat all the time). With increasing organizational complexities, it is incredibly challenging to achieve such a state because there will be overhead and misaligned priorities. This is where we look up to the guiding principles of DevOps and SRE practices. In case you are not familiar with Google SRE practices, here is a starting point. The core of DevOps and SRE practices are mature communication and collaboration practices. Let’s focus on the best practices which could help us with our Looker ecosystem.Have joint goals. There should be some goals which are a shared responsibility across two or more teams. This helps establish a culture of psychological safety and transparency across teams.Visualize how the data flows across the organization. This enables an understanding how each team plays their role and how to work with them better.Agree on theGolden Signals (aka core metrics). These could mean data freshness, data accuracy, latency on centralized dashboards etc. These signals allow teams to set their error budgets and SLIs.Agree on communication and collaboration methods that work across teams. Regular bidirectional communication modes – have shared Google Chat spaces/slack channels. Focus on artifacts such as jointly owned documentations pages, shared roadmap items, reusable tooling, etc. For example, System Activity Dashboards could be made available to all the relevant stakeholders and supplemented with notes tailored to your organization.Set up regular forums where commonly discussed agenda items include major changes, expected downtime and postmortems around the core metrics. Among other agenda items, you could define/refine a common set of standards, for example centrally defined labels, group_labels, descriptions, etc. in the LookML to ensure there is a single terminology across the board.Promote informal sharing opportunities such as lessons learned, TGIFs, Brown bag sessions, and shadowing opportunities. Learning and teaching have an immense impact on how teams evolve. Teams often become closer with side projects that are slightly outside of their usual day-to-day duties.Have mutually agreed upon change management practices. Each team has dependencies so making changes may have an impact on other teams. Why not plan those changes systematically? For example, getting common standards across the Advance deploy mode.Promote continuous improvements. Keep looking for better, faster, cost-optimized versions of something important to the teams.Revisit your data flow. After every major reorganization, ensure that organizational change has not broken the established mechanisms.despite silos and different subgoals, destiny for all these teams is intertwined for the organization to thrive.Are you over-engineering?There is a possibility that in the process of maturing the ecosystem, we may end up in an overly engineered system – we may unintentionally add toil to the environment. These are examples of toil that often stem from communication gaps. Meetings with no outcomes/action plans – This one is among the most common forms of toil, where the original intention of a meeting is no longer valid but the forum has not taken efforts to revisit their decision.Unnecessary approvals – Being a single threaded team can often create unnecessary dependencies and your teams may lose the ability to make changes.Unaligned maintenance windows – Changes across multiple teams may not be mutually exclusive hence if there is misalignment then it may create unforeseen impacts on the end user.Fancy, but unnecessary tooling – Side projects, if not governed, may create unnecessary tooling which is not being used by the business. Collaborations are great when they solve real business problems, hence it is also required to refocus if the priorities are set right.Gray areas – When you have a shared responsibility model, you also may end up in gray areas which are often gaps with no owner. This can lead to increased complexity in the long run. For example, having the flexibility to schedule content delivery still requires collaboration to reduce jobs with failures because it can impact the performance of your Looker instance.Contradicting metrics – You may want to pay special attention to how teams are rewarded for internal metrics. For example, if a team focuses on accuracy of data and other one on freshness then at scale they may not align with one another.ConclusionTo summarize, we learned how data is handled in large organizations with Looker at its heart unifying a universal semantic model. To handle large amounts of diverse data, teams need to start with aligned goals and commit to strong collaboration. We also learned how DevOps and SRE practices can guide us navigate through these complexities. Lastly, we looked at some side effects of excessively structured systems. To go forward from here, it is highly recommended to start with an analysis of how data flows under your scope and how mature the collaboration is across multiple teams.Further reading and resourcesGetting to know Looker – common use casesEnterprise DevOps GuidebookKnow thy enemy: how to prioritize and communicate risks—CRE life lessonsHow to get started with site reliability engineering (SRE)Bring governance and trust to everyone with Looker’s universal semantic modelRelated articlesHow SREs analyze risks to evaluate SLOs | Google Cloud BlogBest Practice: Create a Positive Experience for Looker UsersBest Practice: LookML Dos and Don’ts
Quelle: Google Cloud Platform

30. Juli 2022

da Agency

Top 5 Takeaways from Google Cloud’s Data Engineer Spotlight

In the past decade, we have experienced an unprecedented growth in the volume of data that can be captured, recorded and stored. In addition, the data comes in all shapes and forms, speeds and sources. This makes data accessibility, data accuracy, data compatibility, and data quality more complex than ever more. Which is why this year at our Data Engineer Spotlight, we wanted to bring together the Data Engineer Community to share important learning sessions and the newest innovations in Google Cloud. Did you miss out on the live sessions? Not to worry – all the content is available on demand. Interested in running a proof of concept using your own data? Sign up here forhands-on workshop opportunities.Here are the five biggest areas to catch up on from Data Engineer Spotlight, with the first four takeaways written by a loyal member of our data community: Francisco Garcia, Founder of Direcly, a Google Cloud Partner. #1: The next generation of Dataflow was announced, including Dataflow Go (allowing engineers to write core Beam pipelines in Go, data scientists to contribute with Python transforms, and data engineers to import standard Java I/O connectors). The best part, it all works together in a single pipeline. Dataflow ML (deploy easy ML models with PyTorch, TensorFlow, or stickit-learn to an application in real time), and Dataflow Prime (removes the complexities of sizing and tuning so you don’t have to worry about machine types, enabling developers to be more productive). Read on the Google Cloud Blog: The next generation of Dataflow: Dataflow Prime, Dataflow Go, and Dataflow MLWatch on Google Cloud YouTube: Build unified batch and streaming pipelines on popular ML frameworks #2: Dataform Preview was announced (Q3 2022), which helps build and operationalize scalable SQL pipelines in BigQuery. My personal favorite part is that it follows software engineering best practices (version control, testing, and documentation) when managing SQL. Also, no other skills beyond SQL are required. Dataform is now in private preview. Join the waitlist Watch on Google Cloud YouTube: Manage complex SQL workflows in BigQuery using Dataform CLI #3: Data Catalog is now part of Dataplex, centralizing security and unifying data governance across distributed data for intelligent data management, which can help governance at scale. Another great feature is that it has built-in AI-driven intelligence with data classification, quality, lineage, and lifecycle management. Read on the Google Cloud Blog: Streamline data management and governance with the unification of Data Catalog and Dataplex Watch on Google Cloud YouTube: Manage and govern distributed data with Dataplex#4: A how-to on BigQuery Migration Services was covered, which offers end-to-end migrations to BigQuery, simplifying the process of moving data into the cloud and providing tools to help with key decisions. Organizations are now able to break down their data silos. One great feature is the ability to accelerate migrations with intelligent automated SQL translations. Read More on the Google Cloud Blog: How to migrate an on-premises data warehouse to BigQuery on Google Cloud Watch on Google Cloud YouTube: Data Warehouse migrations to BigQuery made easy with BigQuery Migration Service #5: The Google Cloud Hero Game was a gamified three hour Google Cloud training experience using hands-on labs to gain skills through interactive learning in a fun and educational environment. During the Data Engineer Spotlight, 50+ participants joined a live Google Meet call to play the Cloud Hero BigQuery Skills game, with the top 10 winners earning a copy of Visualizing Google Cloud by Priyanka Vergadia. If you missed the Cloud Hero game but still want to accelerate your Data Engineer career, get started toward becoming a Google Cloud certified Data Engineer with 30-days of free learning on Google Cloud Skills Boost. What was your biggest learning/takeaway from playing this Cloud Hero game?It was brilliantly organized by the Cloud Analytics team at Google. The game day started off with the introduction and then from there we were introduced to the skills game. It takes a lot more than hands on to understand the concepts of BigQuery/SQL engine and I understood a lot more by doing labs multiple times. Top 10 winners receiving the Visualizing Google Cloud book was a bonus. – Shirish KamathCopy and pasting snippets of codes wins you competition. Just kidding. My biggest takeaway is that I get to explore capabilities of BigQuery that I may have not thought about before. – Ivan YudhiWould you recommend this game to your friends? If so, who would you recommend it to and why would you recommend it? Definitely, there is so much need for learning and awareness of such events and games around the world, as the need for Data Analysis through the cloud is increasing. A lot of my friends want to upskill themselves and these kinds of games can bring a lot of new opportunities for them. – Karan KukrejaWhat was your favorite part about the Cloud Hero BigQuery Skills game? How did winning the Cloud Hero BigQuery Skills game make you feel?The favorite part was working on BigQuery Labs enthusiastically to reach the expected results and meet the goals. Each lab of the game has different tasks and learning, so each next lab was giving me confidence for the next challenge. To finish at the top of the leaderboard in this game makes me feel very fortunate. It was like one of the biggest milestones I have achieved in 2022. – Sneha Kukreja
Quelle: Google Cloud Platform

30. Juli 2022

da Agency

Get to know the top 3 teams of the Google Cloud Hackathon Singapore

Google Cloud hackathonOn 10th April 2022, Google Cloud launched the first Singapore Google Cloud Hackathon, where startup teams were tasked to build solutions for either the topics of Sustainability, Artificial Intelligence, Automation or the New Normal, to create innovative solutions and have the opportunity to win prizes. From April to 10th June, Google Cloud worked with hackathon entrants through the solutioning process from ideation to prototyping to the final pitch. The hackathon saw incredible response with 40 startup teams competing for a top 5 spot. The top 5 teams were invited to pitch live at the Google Asia Pacific Singapore Campus and presented to a panel of judges that consisted of experts in the startup ecosystem and technology leaders across APAC in Google. The top 3 teams also continued to receive mentorship opportunities with Google Cloud and startup experts. Top 3 teamsRead on to learn more about the top 3 startup teams:Team Empathly – 2nd Runner UpCofounders Timothy Liau, Jamie Yau and Rachel Tan personally experienced hate speech and witnessed discrimination in online communities. The available content filters and manual moderation solutions, which they found to be very expensive, only focused on damage control after the hateful comment has been sent. Out of a desire to prevent the toxic behavior at its source, Empathly was born.Any platform with user-generated content — social media, games, marketplaces, dating apps and more — is susceptible to hate speech. Described as “The Grammarly for content moderation”, Empathly applies its AI that identifies distinct types of hate speech with context – to promote safer and more inclusive speech in workplaces and online platforms. Empathy is built on Cloud Run and Cloud Firestore.Empathly’s behavioral science advisory team includes Yale-NUS professor and expert in behavioral insights Dr. Jean Liu whose research focuses on how technological solutions require an appreciation of human behavior and the social context. They will focus their next few months on working closely with their early customers and building toward product-market-fit.Team Ambient Systems – 1st Runner UpIvan Damnjanović founded Ambient to help companies meet their decarbonization targets through data science innovation. The team consists of Ivan and Frey Liu, a fellow computer science masters student from National University of Singapore (NUS). Through Ambient’s platform, companies can access real time Big Data analytics for actionable decarbonisation through energy efficiency and trade-off optimization.In 2020, Ambient Systems was founded when Ivan proposed a software-based solution for managing complex indoor air quality challenges, such as airborne transmission of COVID and vertical farming climate conditions. Ivan’s patent in the AgriTech field helped Ambient secure a $100k investment from NUS to further pursue commercialization of the technology and help Singapore achieve its 30 by 30 agenda – to build Singapore’s “agri-food industry’s capability and capacity to produce 30% of our nutritional needs locally and sustainably by 2030”.Through the use of Google’s Firebase platform, the team was able to quickly build a fully functional prototype that garnered interest from investors and customers.Team Pomona – ChampionsAs harsh weather conditions continue to plummet agricultural yield, there is an increasing need for countries to improve food security through efficient agriculture and sustainable living. However, high operational costs and cyclical risks inhibit the growth of vertical farming in the agricultural industry.Team Pomona consists of Pang Jun Rong, Yuen Kah May, Teo Keng Swee, Nicole Lim Jia Yi, Tan Jie En, who are student entrepreneurs from Singapore Management University (SMU) Computer Science. They took motivation from their school’s efforts in sustainability and technology to form Pomona — a solution set on making food security more personal through the ownership of vegetables in commercial agricultural lifecycles.Pomona features a gamified de-fi agricultural platform to promote collective ownership of vertical farming agriculture, which enables profit-sharing between producers and consumers to hedge against operational risks. This was done through a hybrid decentralized microservice cloud architecture with Google Cloud, using blockchain technologies for “dVeg” digital tokens and conventional full-stack components for gamification with IoT integration, providing real-time interactive growth tracking for lifecycle traceability.Final wordsCongratulations to all of the teams and especially Empathy, Ambient Systems, and Pomona. We look forward to more events with startups in the future!
Quelle: Google Cloud Platform