Tech Blog – Network Zoning Still Required?

Introduction

Almost all of our clients have network zones in place and their infrastructure segmented on the network level. This is historical and in most cases related to the traditional on-prem network infrastructure. But time has changed and new technologies, SaaS services, and Cloud Service Providers (CSP) exist on the market. These all have an impact on the traditional on-prem but are also key to the cloud architecture.

What is a Zone?

If I ask a client the question: “What is a zone in your infrastructure?”, it is not common that the answer will be mostly: “An IP segment.” That is a starting point, of course, but when the second question “How do you protect your zone” is answered with: “A router or firewall”, I get my assumption confirmed that it is a firewall. But when I ask the final question: “Based on which criteria do you define a zone and the protection level of the zone?” the answer will be “Hmm …, not sure, could be …”. The outcome of the questionnaire is that most clients have a network segmentation with a firewall in place which protects the resources in the different network segments between each other.

Based on the answer of the final question, you can imagine the missing part: a zone definition based on some criteria which requires a so-called “zone concept”. A zone concept guarantees that resources which require the same protection level are placed in the same zone or are protected through the same protection mechanism.

Base Zone Concept

A zone concept can be multifarious and complex. To build a zone concept, it is important to distinguish between what can be controlled on the network level and which controls can be enabled on the protected resources. Furthermore, the zone concept should cover the security criteria to build a zone and the protection of a zone.

To build a reliable base zone concept, I recommend to still start with a network based zone concept (as the traditional on-prem IP segmentation) with a fixed definition of at least two, but not more than three security criteria. The security criteria must be independent from the infrastructure, the vendors, and the products. For example, the first security criteria can be defined to specify the allowed communication between the different network connected assets. The second security criteria provides the possibility to group several connected assets with the same characteristics with each other and treat them in the same security manner. Nothing really new, but with the defined criteria it is now clear how the zone is defined and which connected assets can be hosted in the same zone. In this example, a zone is the smallest entity which can be protected on the network level and is specified as a result of the combination of the criteria 1 (e.g., security domain) and criteria 2 (e.g., function).

An individual zone can be defined with the following security criteria and attributes:

Attributes:

• Zone ID (unique number)
• Zone name (associated name in addition to the ID)
• Segment(s) (the IP segments where the resources are connected and protected through the zone)

Security criteria:

• Criteria 1 (specifies the allowed communication between the connected assets)
• Criteria 2 (groups assets with the same characteristics and treat them in the same security manner)

Extended Zone Concept

With the strictly defined base zone concept in place, it is possible to also cover today’s new technologies and cloud and hybrid environments.

At first, the base zone concept is generic, which means it is independent of the underlay infrastructure and can be deployed on-prem, in the cloud, and also in a hybrid manner. It is always the same zone concept and simplifies the operation, security, and compliance & audit processes. Secondly, in the base zone concept, the zone contains an IP segment. In this extended zone concept, a zone can host individual resources instead of a whole IP segment. With this approach in place, the zone concept also covers micro-segmentation. Furthermore, since the base zone concept does not limit the number of zones, we can simply scale out with the amount of zones. Each zone has a unique zone ID, so it can be more than one zone with the same security criteria defined. This important feature allows us to cover today’s scalability in the cloud and in the SDN environments. After all, with an additional third security criteria (e.g., PCI), we can cover the zoning for a company which has to follow the PCI-DSS standard or other regulations as well.

Security Reference Architecture

With a now generic and scalable zone concept, the cloud infrastructure can be built upon the business’ security requirements, following guidelines like the AWS Security Reference Architecture (AWS SRA) and other known standards.

With the different zone deployment models based on the generic zone concept, it is now possible to integrate the additional AWS cloud security services into the zoned network architecture to achieve the required security maturity level. Only with such a solid foundation, the security and compliance objectives can be met.

Conclusion

Our field experience shows that a lot of clients do not yet have a base zone concept in place but would still like to go to the cloud. The cloud is not more than another infrastructure with a lot of advantages, but with the shared responsibility model. It still requires a good concept of how to protect and group the different resources in the cloud. The cloud providers themselves provide a lot of resources to implement security functions and provide valuable reference architectures but they do not provide the concept of the customer’s needs.

If you go forward with the cloud journey (and you should), do not forget to perform an analysis/discovery of your current zoning first and verify if it also fits the transition to the cloud. Of course, a good network zoning is also required in the cloud.

We at copebit can not only support you to build a secure cloud infrastructure, we also provide the services to improve and specify the required security landscape in the whole environment.

References

AWS Well-Architected
https://aws.amazon.com/architecture/well-architected/

Security Pillar – AWS Well-Architected Framework
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

AWS Security Reference Architecture (AWS SRA)
https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html

AWS Security Documentation
https://docs.aws.amazon.com/security/

AWS Shared Responsibility Model
https://aws.amazon.com/compliance/shared-responsibility-model/