Multiple times now I’ve come across fucked up policies that where so messed you needed weeks to understand them. At one employer we had a naming convention that I since then use almost everywhere I can, since it is (at least for me) super easy to read, if done correctly.
Object Naming
An object name consists of fields with attributes (see Figure-1), separated by underscores.
(grp_)type_(ext_)company_country_location_(zone/scope)_segment_[Purpose1_][Purpose2N_](hostname)
| Attribute | Value | Length | Description |
| grp | grp | 3 | Group prefix (fixed) |
| type | hst net rng pfl | 3 | Object type Host object Network object Range object Prefix List |
| ext | ext | 3 | External (public) prefix |
| company | tkom decix vzon fdd | unlim. | Company Identidier (slug) Telekom DE-CIX Verizon FirstData (FISERV) |
| country | de us fr dk | 2 | Country germany USA France Denmark |
| location | fra fra1 fra3 ber cgn | 3-5 | Location Name (city,dc,district,area) Frankfurt a.M. (area) eg. NTT FRA1 eg. NTT FRA3 Berlin Cologne |
| zone/scope | pci dc campus branch | unlim. | Zone or Scope names eg. PCI-DSS Scope networks eg. Datacenter network eg. Campus networks eg. Branch location networks |
| segment | dmz db dns | unlim. | Segment name DMZ Database segment DNS segment |
| Purpose | resolver soa proxy | unim. | Purpose (eg. Application, function) DNS Resolver DNS SOA Proxy server Mail system |
| Hostname | Hostname according to convention | unlim. | Hostname (ALL CAPS) |
Hierarchical Object Tree
Conclusion
Using a hierarchical object structure makes life a lot easier imho. Anyway, this also requires one to “use it right”, for example build a firewall policy based on groups, not on host or network objects.
