Understanding DMZ Architecture in Servicenow Discovery

[Charu Maurya]

I have a basic understanding of discovery; however, I want to better understand how DMZ works in real enterprise environments.

I have some questions and would appreciate guidance from experienced professionals:

1. What exactly is a DMZ in networking terms?
2. Why do organizations place servers in a DMZ instead of the internal network?
3. In ServiceNow Discovery, why is a MID Server sometimes installed inside the DMZ?
4. How does communication happen between:
   • ServiceNow instance
   • MID Server
   • DMZ servers/devices
5. What firewall ports are usually opened for Discovery in a DMZ setup?
6. Is inbound connectivity from ServiceNow to the MID Server required?
7. When should we use the following:
   • one MID Server
   • multiple MID Servers
   • separate MID Servers for the internal network and the DMZ
8. Can someone share a simple real-world architecture example or best practice for Discovery in a DMZ environment?
9. What are common mistakes or security concerns while configuring Discovery for DMZ systems?

I would also appreciate any documentation, diagrams, or learning resources

[Vishnu-K · Accepted solution]

Hi @Charu Maurya ,

In real enterprise environments, the DMZ sits between the internet and your internal corporate network think of it as a buffer zone. Anything that needs to be reachable from the outside world (web servers, APIs, load balancers, proxies) lives there. The logic is simple: if something in the DMZ gets compromised, the attacker still hits a wall before reaching your internal systems.

Now, where does ServiceNow's MID Server fit into this? In most organizations I've seen, MID Servers are dropped right into the DMZ because they act as the bridge between the ServiceNow cloud instance and whatever you're trying to discover. The beauty of this setup is that the MID Server reaches out to ServiceNow so you're not punching inbound holes in your firewall from the internet. Security teams love that.

A typical setup looks roughly like this:

ServiceNow (Cloud) → Firewall → MID Server (DMZ) → Internal Firewall → Internal Network

In practice, most enterprises run at least two MID Servers — one handling internal discovery, another dedicated to the DMZ. Some larger environments add more for load balancing or failover.

The communication flow itself is pretty straightforward:

• MID Server opens an outbound HTTPS connection to ServiceNow on port 443
• It then probes target systems using SSH, WMI, SNMP, PowerShell, etc.
• Results flow back through the ECC Queue — no inbound connection needed from ServiceNow's side

Common ports you'll typically see opened for DMZ discovery:
443 (MID ↔ ServiceNow),
22 (Linux SSH),
135/445 (Windows WMI),
161 (SNMP), and 5985/5986 (WinRM).

A few things I'd flag as best practices :

• Keep MID Servers separate per zone - don't share one between internal and DMZ
• Credential segregation matters don't reuse the same accounts across zones
• Keep firewall rules tight and specific - "open everything to make it work" always comes back to bite you

The most common mistake I've run into is teams trying to use a single MID Server for both internal and DMZ discovery. On paper it seems simpler, but it creates firewall headaches and security teams will flag it eventually. The other one is over-broad firewall rules opened during initial setup that nobody ever revisits.

If you're learning this stuff, it also really helps to get comfortable with general network segmentation and dual-firewall architecture ServiceNow Discovery design decisions are heavily tied to how the underlying enterprise network is structured.

Hope this helps if it does please do mark it as helpful and accept the solution

Thanks,
Vishnu