Check Point CCCS cheat sheet

Shared responsibility split: the provider secures the cloud (physical facilities, hypervisor, managed service internals); the customer secures what is in the cloud (identity, data, configuration, guest OS, network controls).

IaaS leaves the guest OS, patching, and network ACLs to the customer; PaaS removes OS patching but keeps application code, identity, and data classification with the customer; SaaS leaves mainly identity, data, and usage configuration to the customer.

The customer's responsibility never transfers to the provider for access management: over-permissive IAM roles, unrotated keys, and missing MFA remain customer findings under every service model.

Cloud account boundaries are the primary security perimeter; the provider's hypervisor boundary is not a control the customer can audit, so customer controls must be evidenced inside the account.

Ephemeral, API-driven infrastructure means configuration drift is continuous; security controls must be enforced declaratively (policy-as-code, IaC scanning) rather than by periodic manual review.

Data residency and sovereignty obligations attach to where data is stored and processed; the provider's region list defines the technical boundary, but legal accountability stays with the data owner.

Encryption responsibility is layered: provider-managed keys shift operational burden but reduce customer control; customer-managed keys (BYOK/HYOK) return key custody and rotation accountability to the customer.

Logging responsibility is customer-side: provider audit trails (control-plane logs) must be enabled, centralized, and retained by the customer; they are not on by default in every service.

CloudGuard Network Security gateways are delivered as marketplace images (or Terraform/CloudFormation templates) that boot a Gaia-based gateway into a VNet/VPC; the Security Management Server can be on-premises or in the cloud.

In AWS, the gateway requires an Elastic IP or NAT for management reachability, an ENI in each inspected subnet path, and source/destination check disabled on forwarding interfaces.

In Azure, the gateway needs an accelerated-networking-capable VM size for throughput, a subnet delegated to the gateway, and IP forwarding enabled on the NIC for routed inspection.

High availability uses cluster patterns native to the cloud: AWS uses route table failover with cluster VIP movement; Azure uses load balancer or route-based failover; both rely on the gateway cluster protocol over the management/data interfaces.

Autoscaling (AWS Auto Scaling groups, Azure VMSS) uses a gateway image with bootstrap configuration so new instances fetch policy from the management server without manual steps.

Licensing is BYOL or PAYG; PAYG instances are tied to the marketplace terms and cannot be moved across clouds, while BYOL uses centralized license management from the Security Management Server.

Deployment sizing is driven by inspected throughput and connection count, not instance count; a single gateway's throughput ceiling determines how many gateways or autoscaling units are needed.

Terraform modules from Check Point's public repository are the standard deployment path; they parameterize VPC/VNet, subnets, gateway count, and management connectivity.

East-west inspection requires routing traffic through the gateway: in AWS, edit route tables so the destination subnet's route points to the gateway ENI; in Azure, use user-defined routes (UDRs) with next hop set to the gateway private IP.

North-south inspection places the gateway between the internet gateway and workload subnets; the public route table sends 0.0.0.0/0 to the gateway, and the gateway's external interface routes to the IGW.

Asymmetric routing breaks stateful inspection; ensure return traffic traverses the same gateway instance, typically by symmetric route tables per availability zone.

Security groups and NSGs are stateless-or-stateful host-level filters that complement, not replace, the gateway; the gateway provides L7 inspection, IPS, anti-bot, and application control.

Inspection of intra-VPC traffic requires the workload subnet route table to point at the gateway for the peer CIDR; without a route change, traffic never reaches the gateway.

Transit hub-and-spoke designs centralize gateways in a shared services VPC/VNet; spokes peer to the hub and route inter-spoke traffic through the inspection VPC.

Gateway Load Balancer (AWS GWLB) and Azure Gateway Load Balancer insert third-party inspection transparently using GENEVE encapsulation on port 6081, avoiding manual route churn per workload.

Private connectivity (AWS PrivateLink, Azure Private Endpoint) bypasses internet inspection paths; verify that private endpoint traffic is still routed through the inspection point or explicitly accepted.

CloudGuard Posture Management (CSPM) continuously assesses cloud accounts against built-in and custom rules, producing findings with severity and remediation guidance.

Compliance frameworks map rules to controls: CIS Benchmarks, PCI DSS, HIPAA, SOC 2, NIST, and GDPR are available as compliance bundles that report per-control pass/fail.

Onboarding uses read-only cross-account roles (AWS IAM role, Azure service principal, GCP service account) so assessment does not require write credentials.

Findings are categorized by severity and by entity (account, resource, identity); remediation can be manual, via auto-remediation workflows, or via ticketing integration.

Exclusions and exceptions suppress known-acceptable findings; each exception should carry an owner and expiry to avoid permanent blind spots.

Auto-remediation uses serverless functions (Lambda, Azure Functions) triggered by the platform to fix misconfigurations such as public storage buckets or open security groups.

Intelligence feeds (threat intelligence, anomaly detection) enrich posture findings so that a misconfiguration is prioritized by whether it is exposed or exploited.

Continuous assessment cadence is near-real-time via cloud API polling and event-driven triggers; point-in-time scans are insufficient because drift is constant.

CloudGuard Workload Protection (CWPP) agents or agentless scanning protect serverless functions, containers, and VM workloads against malware, drift, and runtime attacks.

Serverless protection uses a lightweight function extension or layer that inspects invocations; it must be attached at deploy time and cannot be retrofitted without redeployment.

Container image scanning runs in CI (registry scan on push) and at runtime; blocking policy should fail the pipeline on critical vulnerabilities rather than warn.

Infrastructure-as-code scanning (Terraform, CloudFormation) catches misconfigurations before deployment, shifting posture enforcement left of the cloud API.

Automation is delivered through the management API and CLI (e.g., cpgateway/management API, web API) so provisioning, policy install, and object creation are scriptable.

Event-driven response uses cloud-native triggers (EventBridge, Azure Event Grid, Cloud Functions) to call remediation playbooks when a finding or alert fires.

Runtime protection detects behavioral anomalies (unexpected process, file encryption, outbound C2) and can block or quarantine the workload automatically.

Tagging and asset inventory are prerequisites for automation: policies and remediation scoped by tag or account ensure the right workloads are targeted.