Meeting TIC 3.0 Requirements on Cloud.gov
Overview
OMB M‑19‑26 lets agencies satisfy Trusted Internet Connections (TIC) controls wherever it makes the most sense instead of hair‑pinning traffic through a single gateway.
TIC 3.0’s Cloud Use Case supports distributed PEPs—including ones inside a cloud service—as long as the 60 catalogued security capabilities are met.
On Cloud.gov, agencies can run an NGINX (or similar) reverse‑proxy app in the same space as their production apps. That proxy terminates inbound TLS, applies WAF rules, logs requests, and funnels outbound traffic through policy‑controlled Application Security Groups (ASGs).
The arrangement gives agencies a clear customer‑owned PEP (Policy Enforcement Point) inside the FedRAMP‑Moderate boundary while inheriting platform protections such as DDoS filtering, Gorouter load balancing, and continuous monitoring.
Architecture
Blue nodes reside on Cloud.gov but inside the Agency's ATO Boundary. RevProxy and ASG are agency‑owned PEPs; Router is Cloud.gov’s service‑level PEP.
FAQs
Q: Must we still back‑haul traffic through a legacy TIC 2.2 gateway? A: No. OMB M‑19‑26 allows enforcement at cloud PEPs; a reverse‑proxy app plus ASGs meets the Cloud Use Case when mapped in your SSP.
Q: Which TIC capabilities are fully inherited from Cloud.gov? A: DDoS mitigation, router WAF rules, platform TLS, and continuous monitoring logs are inherited; see the CIS for the definitive list.
Q: Can we use something other than NGINX? A: Yes—any HTTP reverse proxy (e.g., HAProxy, Envoy) packaged as a Cloud Foundry app works the same way.
Q: How do we update ASGs without restaging apps?
A: Run cf update-security-group and cf bind-security-group; changes apply instantly to running containers.