Three building blocks for scalable zoning in the data center
In the previous blog on this topic I have described the main reasons why granular zoning in the data center is primarily a challenge of scalability. Too many firewall rules to manage, too many zones to provision, too many communication relationships to define. Especially when we aim for maximum protection with zero trusted communication, it becomes a fact which cannot be ignored anymore. So how to address this challenge:
Splitting functions and responsibilities is a possibility to scale used in many areas of an organization. Security in the data center can be split in policy definition, policy enforcement and policy validation.
This is comparable with the separation of power in democratic states. The parliament defines the laws, the government organizes the enforcement with the support of the police and the states attorney makes sure, not acting according to the law is not sustainable.
Why not apply the best practices we use in law making and enforcement to data center security, by separating duties as well and allow each of them to establish their own organisation, tools and processes?
The three building blocks to separate duties in data center security:
- Security policy definition
- Policy enforcement
- Compliance validation
This does not mean the same team or tool cannot be utilized for more than one discipline, but it’s always done in distinct, independent roles.
On a high level, what principles apply to each of these building blocks?
Let me start with some bullet points, I will elaborate on some of them going forward. The intension behind those principles is to define guidelines for the solution development.
- Policies describe the intended communication allowed between zones or application.
- Policies are defined for zones and/or applications.
- Policies are defined independent from the underlying Infrastructure. With no dependencies on IP-addresses, physical or virtual servers and networks or containers or cloud.
- Without a policy, no traffic is permitted, this is referred to as a white-list policy.
- Policies can be hierarchical. They can be applicable for the entire zone or very specific to an application.
- Defining policies is the responsibility of the application or service owner and done in collaboration with IT-Governance-, Risk-, Security- and Compliance- teams.
A management process might facilitate and document the policy definition process. This is often a service provided by the IT-Infrastructure team because they then also take care of the policy enforcement.
- Zones can contain multiple hosts and applications or every application is also a zone.
- Zones are dynamically implemented on demand.
- The same zones can potentially be implemented in physical, virtual or container networks as well as in public clouds.
- The Policy describing the intended communication allowed between zones, is translated into a standardised configuration and applied to the enforcement points like firewalls, networks or security enforcement in a cloud.
- In order to scale: communication between zones is enforced by the network.
- In order to scale: only communication which requires deeper inspection is enforced by the firewall.
Compliance validation: checks how the intended policy compares to the real-life situation.
- Verify the intent: Monitor whether the intended policy is implemented and enforced and no unspecified communication between zones takes place.
- Verify the business service: Verify in a proactive manner, whether the actual communication is taking place as expected by the application owners.
- Verify deviation from the baseline: Investigate what kind of communication attempts have been blocked. Was it initiated by malware or was it traffic that should actually be allowed but was not considered in any policy yet.
In summary, in order to implement more granular zoning in a way which allows you to handle the scalability challenge:
- Separate the definition of the communication policy from how it will actually be enforced. The two have different responsibilities and processes. Policy definition has to do with the application. Policy enforcement with the various infrastructures and the corresponding teams.
- Define the policy with the application in mind, understanding its communication requirements. Keep it independent from Servers, VM’s, IP-Addresses, ports, etc.
- Utilize the network as well as the firewall for enforcement.
- Make sure there is a scalable loop back from defining a policy, to enforcing it, to checking what actually takes place within the data center.
In a next blog, I am going to elaborate on some of the principles listed above. For example, why the firewall is not the only enforcement point anymore in a scalable data center and why a white list policy approach is not about the type of rules in the firewall.
- Access Point
- annual cybersecurity report
- Artificial Intelligence
- breach readiness and response
- Business Critical Services
- business email compromises
- Cisco CDA
- Cisco Switzerland
- Cloud Broker
- cloud workload protection
- Critical Infrastructure
- Data Center
- data privacy
- data protection
- encrypted traffic
- Hybrid Cloud
- hybrid-cloud application security
- IT Infrastructure
- midyear cybersecurity report
- network intuitive
- social engineering
- Threat Protection