Case Study

Securing Healthcare Apps in GCP

See Valtix in Action

Tour the Product          Sign Up for Free Tier

Customer Overview

A healthcare company that has built the next-generation health platform to transform how pharmaceutical companies take their medical solutions, including IoT devices, to market. A key requirement is to quickly deploy a scalable environment for new customers while providing strong security controls that meet the regulatory requirements of the healthcare industry.

Summary

Industry: Healthcare

Challenges:

  • Advanced network security for HIPAA compliance for customer-facing applications
  • All aspects of their cloud deployment are automated with Terraform, except network security
  • Lower total cost of ownership to fit the needs of a small security team with limited resources

Solution:

  • Valtix cloud security service is deployed in a distributed architecture to protect the entire health platform, from Internet-facing frontend and multiple VPCs.

Outcome:

  • Valtix is integrated into the DevOps flow via Terraform; an auto-scaled network security stack is run-ready within 3 minutes. Security is managed-as-code with full audit traceability.
  • All sensitive data (healthcare, personal information) is always retained inside the customer’s cloud account boundaries, helping meet compliance requirements such as HIPAA.
  • Usage-based metering and billing model allows the customer to grow their security along with their business without unnecessary licenses that expire or even the need to manage licenses.

Architecture Details

The healthcare company had decided to build their entire application to be on-demand: as new pharma companies sign up, they would automatically deploy their entire stack via Terraform. Developers also could spin up new test environments for their internal work. This environment consists of a customer-facing, Internet-accessible, frontend VPC running on Google Kubernetes Engine (GKE). This is connected to a backend application VPC hosting the core application logic and data. And, finally, a common VPC to hold services such as logging, and management. All these flows and outbound traffic must be inspected to protect them against attacks and meet regulatory requirements.

“We were looking for a cloud-native network security solution that fits directly into our DevOps flow without requiring complex scripting for deployment and auto scaling. ” – Chief Technology Officer (CTO), Healthcare Platform Company

This use case presents an emerging issue: how to weave in enterprise-grade network security into the deployment flow of cloud-native, modern, apps? The DevOps team has deep expertise in automation but not advanced cloud network security; while the security team cannot easily integrate legacy firewalls into a continuous integration/continuous development (CI/CD) process.

Valtix solved this problem by providing a Terraform resource provider for its cloud security service. As apps are being built and deployed, whether in dev, test, or production, and each customer tenant, security can now be baked into the process – specifying an auto-scaling stack, and using cloud discovery-based security policies. Security teams can now easily integrate an advanced security service quickly, within 3 minutes of deployment, to meet regulations such as HIPAA that require all traffic to be inspected to achieve compliance.

Upon on-boarding into Valtix via Terraform, the Controller starts discovering the cloud infrastructure (instances, load balancers, VPCs, etc), deploys Valtix Gateways, and specify tag-based security policies:

  • TLS decryption (and re-encryption after inspection)
  • Incoming web traffic: Geo-IP enforcement with Cloud WAF – OWASP Top 10 with Advanced ruleset
  • All traffic flows, especially between internal VPCs, inspect for intrusion prevention (IPS) to protect against lateral movement of threats
  • Egress flows: Prevent the spread of malware and enforce URL filtering to a safelist of destinations:
    • “dev” systems can connect to anywhere on GitHub (*.github.com/*) to give developers flexibility in their work
    • “prod” systems are restricted to github.com/myOrgRepo to limit their exposure and prevent command-n-control (C2) hijacking when an attacker attempts a reverse shell
  • East-West: “prod” “web” instances can connect to “prod” “db”, but others cannot.
Back To Top