Interviewer: You and the team just wrapped Phase One. For readers who aren’t steeped in the process, what exactly does Phase One cover?

Earl: Phase One was all about proving the concept end-to-end in a real DoD environment.

We are authorized to flow actual mission traffic from customer NIPR enclaves, through the SCCA boundary protection stack we built, into OCI Government regions, and down to the customer tenancy — and back out again.

Until we get the full IL5 ATO, everything runs under controlled test conditions with real workloads, but the architecture and controls are already production-grade.

Interviewer: Can you briefly walk us through what was involved in the process?

Earl:  Within a short period of time, we wrote, hardened, documented, and defended every layer of the stack — down to keeping legacy Oracle ports alive; real customer traffic flowed across the boundary without a hiccu.

• Wrote and hardened all the Terraform Infrastructure-as-Code
• Stood up the full networking and security stack (BCAP, VDSS, inspection points, etc.)
• Produced every required diagram, data-flow document, and control response
• Opened and supported legacy ports like Oracle 1521/1522 that customers actually need today
• Coordinated multiple rounds of reviews with DISA and the Cloud Assessment Office

Getting real customer traffic across the boundary upon completion of Phase 1 was the ultimate validation.

Interviewer: Can you walk us through how OCI’s SCCA landing zone maps to the four SCCA pillars (BCAP, VDSS, VDMS, TCCM)?

Earl: Sure. The pillars are functional requirements, not product names, which is why OCI can meet them just as well as AWS or Azure — sometimes with less headache.

Interviewer: A lot of our readers have to turn around and brief their AO or prime next week — what’s the one-liner you use for each pillar that instantly makes sense to them?

Earl: Here’s how I explain it in every meeting:

• BCAP → DISA can physically pull the plug if we get compromised.

• VDSS → Every packet of CUI gets the same inspection rigor you’d get from an on-prem DISA firewall.

• VDMS → Stops the #1 cloud breach vector: stolen admin credentials.

• TCCM → Gives the Authorizing Official continuous, automated evidence instead of a 400-page Word doc every three years.

Interviewer: Which OCI services made it possible to stay 100 % cloud-native and still get DISA comfortable?

Earl: Three stood above the rest:

1. OCI Network Firewall – our VDSS boundary firewall; full stateful inspection, logging, and now SNAT
2. Security Lists + Network Security Groups – granular permit/deny inside the VCN
3. OCI IAM with Dynamic Groups & Vault – handles the entire TCCM pillar

These replace rack-and-stack appliances while giving validators exactly the controls they expect.

Interviewer: What almost derailed the project? 

Earl: Two categories:

Technical

• OCI Network Firewall was missing SNAT in the Gov regions when we started. We temporarily bridged the gap with a router instance, then swapped to native SNAT the day the feature dropped.

Administrative

• A key lesson learned: the IP approval authority sits higher/with a different organization than most published org charts show—discovering that halfway through can be painful
• Multiple restarts on paperwork until we mapped every required signature.

Both were steep learning curves, but now we know the exact playbook.

Interviewer: Bottom line — what’s actually working right now?

Earl: Our government customers are actively testing mission traffic through the SCCA boundary I described.

• End-to-end connectivity validated (on-prem – OCI)
• Oracle 1521/1522 flowing
• Up to 10 Gbps inspected throughput available
• Bi-weekly syncs with the government team — all feedback positive so far

The next milestone is full IL5 ATO, and we are on that path right now.  That means the reference architecture, the Terraform, the policies, the runbooks – everything is battle-tested and ready for deployment in weeks.