“The security auditor handed us a spreadsheet of 1,400 legacy firewall rules and said, ‘Every new segment must comply with this from the second it is created.’ Our options were: hire five more ticket handlers, or automate ourselves out of a job.”

In late 2021 at NTT Data, we were building a private cloud platform for an enterprise client. The goal was self-service: application teams click a button in vRealize Automation (vRA), and they get a fully isolated tenant environment with compute, storage, and networking in under ten minutes.

It was a beautiful blueprint, until it hit the security compliance gate.

---

The Manual Gatekeeper

Under the legacy workflow, spinning up a subnet was fast, but securing it took days.

Every segment required a manual ticket to the security operations team to copy-paste the “Default Security Baseline” ruleset into the physical firewall. That ruleset was standard: block inbound SSH from the desktop range, allow NTP and log telemetry, and restrict cross-tenant routing.

But because it was done by humans, it was prone to typos, configuration drift, and delays.

If the security operations team was backlogged, the developer’s new VMs sat idle for 72 hours waiting for basic port access. We were trying to build a modern cloud platform, but we were still running on ticket-ops.

---

The Mess: The Race Condition That Failed the Audit

Our first attempt to automate this was a post-provisioning Ansible cron job.

Every ten minutes, Ansible Tower would query the NSX-T Manager for new logical segments, compare them against a database of known segments, and apply the default security ruleset.

On paper, this worked. In reality, it created a dangerous security gap.

For up to ten minutes after a segment was created, the logical network existed in the hypervisor without any security rules applied. The VMs were live and exposed.

# How we discovered the gap: scanning the new segment before the cron job ran
nmap -Pn -p 22,80,443 10.200.45.12
# Output: Port 22 [OPEN] - SSH exposed to untrusted subnets for a 600-second window

During a simulated audit, the compliance officer spun up a test segment, launched an exploit script, and compromised a test database before the Ansible cron job even paged in.

The audit report was brutal: Critical vulnerability — Non-compliant segments live for up to 600 seconds.

We had to stop trying to secure the segment after the fact. We needed the segment to be born secure.

---

The Solution: Synchronous Day-0 Injection

We tore down the Ansible cron job and integrated the security injection directly into the vRA blueprint workflow.

By utilizing the NSX-T Policy API, we designed a synchronous step in the deployment pipeline. The segment creation and the firewall rule insertion were bound to a single transaction block.

If the security rules failed to apply, the segment creation failed, and the provisioning rolled back. No insecure network was ever allowed to exist.

We configured the NSX-T Distributed Firewall (DFW) using Policy API Groups mapped to dynamic segment tags.

// # NSX-T Policy API Day-0 Rule Payload
{
  "display_name": "Day-0-Default-Sec-Baseline",
  "sequence_number": 10,
  "rules": [
    {
      "display_name": "Block-Inbound-SSH-Untrusted",
      "action": "DROP",
      "sources": ["/infra/domains/default/groups/untrusted-ranges"],
      "destinations": ["/infra/domains/default/groups/tenant-app-nodes"],
      "services": ["/infra/services/SSH"]
    },
    {
      "display_name": "Allow-Internal-Monitoring",
      "action": "ALLOW",
      "destinations": ["/infra/domains/default/groups/monitoring-endpoints"],
      "services": ["/infra/services/ICMP", "/infra/services/SNMP"]
    }
  ]
}

We also implemented an egress guardrail ensuring that VMs could only talk to the corporate NTP server for time sync, preventing NTP amplification attack vectors.

The template was injected via a Python worker script running inside the vRA orchestration engine, validating the payload schema before execution.

# Synchronous payload validation helper
def validate_security_payload(payload):
    required_keys = ["display_name", "rules"]
    for key in required_keys:
        if key not in payload:
            raise ValueError(f"Missing mandatory baseline key: {key}")
    print("Payload verified. Proceeding with Policy API injection.")

---

The Impact

• Zero Exposure Window: Since segment creation and rule insertion are atomic, the security exposure window dropped from 10 minutes to exactly zero seconds.
• Ticket Elimination: 100% of standard tenant security requests were automated, removing roughly 150 tickets per month from the security queue.
• Continuous Compliance: The next audit cycle passed with zero flags; compliance was verified at the API level.

Key Takeaway

Never Separate Network Creation from Security Definition.

If your platform team is creating subnets without simultaneously applying default security baselines, you are running a race condition against attackers. Bind the policy definition to the segment instantiation, and treat security rules as non-negotiable infrastructure code.

---

Architecture and decisions: mine. Debugging sessions at odd hours: mine. AI assistance: structure, syntax, first draft. — Sachin