Add Security Zone to IP prefix data model

[empusas]

Every bigger company has some sort of security policy that defines how network zones in the company and external can interact with each other.
You could have a simple web, app, db or dev, test, production. Or an approach based on departments like HR, finance, R&D etc.

There are also many application how you could use such a attribute. Maybe for zone based firewalls, or if you want to check current flows against your companies security policy.

I did implement this so far as a custom field and I prefer to have it an optional field with choices. That limited the problem with misspelled value and typos.

But I could imagine that this might be feature that more people see use for and that we could implement as an out of the box feature for netbox.

[jeremystretch]

It wouldn't make sense to associate a prefix with a security zone, as zones are relative to devices. The "inside" zone might be the "outside" zone for two different devices with interfaces in a common prefix.

[empusas]

I would not agree with that 100%. On devices you usually map interfaces to security zones. But in a corporate network the IP is usually a part of a zone. Otherwise you would not be able to review end to end flows across many devices.

[jeremystretch]

But in a corporate network the IP is usually a part of a zone.

But still relevant to the device. Consider this topology:

( 192.168.0.0/24 ) ---[ Firewall A ]--- ( 192.168.1.0/24 ) ---[ Firewall B ]--- ( 192.168.2.0/24)
                 Inside           Outside                Inside           Outside

To which zone would the IP address 192.168.1.10 belong?

[candlerb]

Presumably to the "DMZ-between-A-and-B" zone?

[DanSheps]

I guess you need to look at the fact there are two "zones". The logical zone between two interfaces (DMZ, Corp, etc) and the "security zone" that is normally assigned to a device interface. Which one do we want to model is the question, if we want to model them at all.

[jeremystretch]

That only works if both devices refer to the zone by the same name, which we can't assume or require.

[empusas]

Tufin has a good support article that describes how to create a zone matrix file for their Secure Track product.
I think that gives a very good impression how security zones are usually implemented in bigger companies and what I was looking for.

https://forum.tufin.com/support/kc/latest/Content/Suite/7091.htm?tocpath=Technical%20Notes%7CCisco%20ACI%7CChecking%20Compliance%20of%20Cisco%20ACI%20Applications%20in%20SecureApp%7C_____1

[cbontrager]

This is a need we are working through in our environment as well.

From an overall organization security design, network subnets may be assigned to a particular security zone. The matrix of various zones is used for analyzing and checking compliance against permitted flows between different segments. The security zone is not necessarily related to a device ingress/egress zone. A device (firewall) zone would be more associated with an interface or interface IP address associated to a device. In an ideal world, perhaps the network security zone would have a 1:1 relationship with all device firewall zones, but in the real world this is typically not the case.

[mjunek]

But in a corporate network the IP is usually a part of a zone.

But still relevant to the device. Consider this topology:

( 192.168.0.0/24 ) ---[ Firewall A ]--- ( 192.168.1.0/24 ) ---[ Firewall B ]--- ( 192.168.2.0/24)
                 Inside           Outside                Inside           Outside

To which zone would the IP address 192.168.1.10 belong?

Inside and Outside in this diagram are only one "use case" of zones - specifically they are default logical security zones in a firewall when shipped from the manufacturer.

A more accurate depiction of that network from a security zoning perspective might be:

( 192.168.0.0/24 ) ---[ Firewall A ]--- ( 192.168.1.0/24 ) ---[ Firewall B ]--- ( 192.168.2.0/24)
    CORPORATE                                   DMZ                                  INTERNET

You would also name firewall zones appropriately on the devices, rather than using default 'inside' and 'outside' so that it depicts the real-world functions as well.

In the use case we have, each prefix lives in one of a number of zones:

• Internet/Uncontrolled
• End User
• DMZ
• On-Prem Enterprise Services
• Public Cloud Enterprise Services
• Central Management

There is a specific matrix which defines which zones are allowed communication by default, and what can be made by explicit firewall rules, and which require exemptions of policy. For example, End User is under no circumstances allowed to talk to Central Management.

Technically, these are implemented with a vast number of firewalls - each with their own 'inside/outside/misc' concepts in regards to traffic flow, however, those do not affect the names of the actual zones where the interfaces live.

For now, in our use case, we have gotten around this by using VLAN/Prefix roles to represent the security zones, because we do not have a need for specific prefix roles. However, that use case may end up coming up down the track.

I certainly see the benefit on having this particular feature in a longer term road map.