Zones are defined by the sequences of protective measures employed at their perimeters. Zones that do not allow direct connections from outside the organization are considered further inside the organization than zones that allow connections from the outside. Zones that do not allow any traffic (inbound or outbound) to systems outside the organization are considered the furthest inside. In effect, the perimeter protections of a zone build on those of zones farther outside create a defense in depth.   Thus, as we move into the organization, the susceptibility of each zone to successful attack and exploitation from outside the organization is likely to be lower than that of each zone to successful attack and exploitation from outside the organization is likely to be lower than that of the next zone out on the ring of trust. Conversely, outer zones are subject to more attach and must provide appropriate security for resisting those attacks.

However, all else being equal the larger the zone, the more risk of unauthorized penetration. For many organizations, replacing the “flat-network” architecture (i.e., where a small number of centralized firewalls control access to thousands of end user devices, offices, etc.,) with a logically and physically sub-zoned network is the answer. The replacement strategy is to retract the network firewalls that really matter to the data center edge, equip endpoints to self protect, but don’t trust them too much.

Risks

1. Political considerations require strong sponsorship and clear (initial funding).
2. Multiple stakeholders and IT groups will need to be involved.
3. Technology risk associated with being an early adopter:
4. Standards are immature, and few organizations have deployed cloud network architecture.
5. Vendor product roadmaps are aggressive, and product cycles are accelerated.
6. Interdependencies lead to complexity; will require careful planning
   1. Multiple interdependent IT initiatives’ create potential for project slippage delays.
   2. Prioritize foundational projects to lay groundwork.
   3. Troubleshooting is more complex when so many changes are being made over a relatively short period.
7. Multiple solutions can lead to inconsistent controls:
   1. A combination of technical approaches may be needed to support all of the identified use cases.
   2. Each approach involves an administrative process for defining and managing controls, which could get out of synch.
8. Trade-off between secure communication and policy enforcement:
   1. Encrypted traffic may prevent inspection and enforcement of controls needed for compliance.
9. Risk of malware from unmanaged and lightly managed endpoints continues to increase:
   1. NAC-style scanning and enforcement may be needed.
10. Maturity and migration risks:
    1. Some of the technical mechanisms have seen limited use and may experience typical early product life cycle problems.
11. Support for the added complexity involved with mixed IPv4 and IPv6 will be required for a long time.