How Security and Network Teams Can Work Together to Achieve Zero Trust

For years, security professionals have repeated some version of the statement, “trust but verify.” Discussions of zero trust architectures (ZTA) began long before digital transformation. However, as organizations moved to the cloud and remote work became the norm, ZTA evolved into a security-critical approach by eliminating implicit trust, continuously verifying access, and limiting user and device access to only the resources they need to perform their job functions. 

Problematically, security and network teams must collaborate, yet they approach segmentation from different perspectives. Security teams need to reduce attack paths, isolate risky devices, and prevent attacker lateral movement. Network teams focus on keeping critical systems online. A segmentation policy that reduces security risk while disrupting operations trades one business problem for another. 

For a zero trust network architecture (ZTNA) that mitigates security and operational risk, security and networking teams must collaborate effectively using a shared understanding of device, risk, communication patterns, and dependencies so they can implement secure network segmentation policies that maintain uptime. 

Why Zero Trust Creates Tension Between Security and Network Teams

While security and networking teams may approach the same problem from different directions, they both strive to minimize the organization’s risk. Since their scope of responsibility differs, they may come into conflict. 

Security Teams Focus on Reducing Trust and Limiting Access

Security teams implement zero trust network segmentation strategies so that attackers have fewer opportunities to access more of a network they have infiltrated. In a flat network, malicious actors can gain initial access through a single compromised device, then travel across the network discovering critical assets, accessing sensitive systems, or moving toward a final target. 

Segmentation limits communications between assets, applications, and other resources. If segmentation works as intended, a compromised device only communicates with the systems necessary for its legitimate function, limiting how attackers can use it to move across the overall environment. 

In the security context, unnecessary connectivity is an unnecessary risk. 

Network Teams Need to Maintain Connectivity and Availability

Network teams need to ensure that legitimate traffic reaches its intended destination. Devices and applications often have dependencies that may not be immediately obvious, and blocking the wrong connection can disrupt workflows or take critical systems offline. 

Network teams may need to maintain a communication that the security team identifies as risky and seeks to restrict. Ultimately, the teams must discuss the impact that their roles have on each other’s intended outcomes. 

Why Network Segmentation Is Critical to Zero Trust

When organizations implement ZTNA, they explicitly determine which resources an entity or user needs to access and then limit the connectivity accordingly. Network segmentation creates the boundaries that control how any two assets can communicate. 

Segmentation Limits Implicit Trust

Segmentation places assets on separate internal networks and controls traffic between them. By preventing them from communicating broadly, the network security policies limit communication based on operational requirements. 

For connected devices, limiting communications is particularly important. An Internet of Things (IoT) device, operational technology (OT), or Internet of Medical Things (IoMT) device may need to communicate with a specific server, application, or cloud service. However, it may not need access to every other system across the organization’s environment.

Segmentation Helps Limit Lateral Movement

With too much network access, a compromised account or asset can turn into a larger security incident. Once an attacker gains initial unauthorized access, they can look for other reachable systems, credentials, or services that allow them to move deeper into the network.

Segmentation limits their ability by restricting communication to only the systems that the device or account needs. By reducing the number of potential routes an attacker can use to reach sensitive or critical assets, segmentation limits an incident’s potential blast radius. 

Zero Trust Requires More Than Creating Network Segments

Creating VLANs, firewall rules, or access control lists is only one part of a ZTA. Organizations still need to determine the communication allowed within those boundaries. 

Organizations need to understand:

• The devices that communicate across the network 
• What the devices communicate with
• The allowed ports and services needed
• The connections necessary for legitimate operations

Without this context, segmentation policies can become too permissive to reduce risk or so restrictive that they interrupt business operations. 

Why Zero Trust Segmentation Strategies Can Break the Network

ZTNA is about creating the right boundaries. However, without sufficient context, the security and networking teams have no way to collaborate to implement appropriate controls. 

Security Teams Lack Visibility into Network Dependencies

While security teams may deem a specific asset risky due to its connections and potential vulnerabilities, they have no way to know every system, application, or service that it needs without a business-focused, context-rich inventory of assets. Blocking a connection that appears to be unnecessary without understanding dependencies can disrupt legitimate workflows. 

Network Teams Lack Security Context Behind Policy Changes

Network teams understand traffic, but traffic alone fails to identify security risks. May history not forget 2014’s Heartbleed, and its ability to sneak 64k out at a time? It’s fingerprintable now, but before that, without information about vulnerabilities, exploits, and potential attack paths, teams may struggle to prioritize segmentation changes. 

Static Policies Struggle with Dynamic Environments

Even well-designed segmentation policies offer a point-in-time view of the environment. Organizations continuously add new assets. Many physical assets move (intentionally). Security researchers and vendors publish new vulnerabilities. Without ongoing visibility and coordination, policies become outdated, leaving unnecessary access in place or blocking operationally necessary communication.

Best Practices for Implementing Zero Trust Segmentation Without Disrupting the Network

When security and network teams collaborate, they can reduce operational and security risks by building a shared strategy based on visibility, risk context, and ongoing validation. 

Establish Shared Visibility Across Security and Network Teams

With shared visibility, both teams work from a common understanding of connected assets, their behaviors, and their network communications. Using this context, the teams can make segmentation decisions based on how devices operate rather than relying on assumptions about how they should operate. 

When evaluating solutions that can support this visibility, organizations should look for capabilities such as:

• Comprehensive discovery and inventory of connected devices
• Visibility into device communication patterns and dependencies
• Device identification and classification that provides operational context

Combine Asset Risk with Network Context

Risk-based segmentation considers an asset’s security risk and how the asset interacts with the environment. It is not just based on a CVSS score of a vulnerability reported on an asset. With contextual understanding of risk, not just theoretical severity, security teams can prioritize controls to meaningfully reduce exposure rather than treating all vulnerabilities and devices equally. 

When evaluating solutions that can support this visibility, organizations should look for capabilities such as:

• Detailed understanding of device characteristics and function well beyond network identifiers
• Contextualized device risk and vulnerability prioritization
• Identification of risky or unnecessary communication paths
• Analysis of device criticality, exploitability, and potential impact

Identify Necessary Communication Before Creating Policies

Before restricting network access, network and security teams should collaborate to determine the systems and services a device legitimately needs to communicate with. By understanding these dependencies early in the process, security teams reduce unnecessary connectivity while networking teams have confidence that segmentation will maintain uptime for required workflows. 

When evaluating solutions that can support this visibility, organizations should look for capabilities such as:

• Analysis of observed device communication and behavior
• Analysis of vendor-provided Software Bill of Materials (SBOM) or MDS2 (Manufacturer Disclosure Statements for Medical Device Security) (where applicable)
• Identification of required device, application, and service dependencies
• Segmentation policy recommendations based on legitimate communication requirements

Validate Segmentation Policies Before Enforcement

Evaluating segmentation policies before enforcing them across the network helps identify potential connectivity disruptions. By simulating the segmentation rule before implementation, security and network teams can reduce the risk that a security control accidentally blocks a legitimate dependency that would lead to downtime or other operational disruption. 

When evaluating solutions that can support this visibility, organizations should look for capabilities such as:

• Simulation of proposed segmentation policies before enforcement
• Validation against observed network traffic and device communication patterns
• Integration with existing NAC, firewall, and other network enforcement infrastructure

Continuously Reassess and Adjust Segmentation

Network policies should evolve as devices, vulnerabilities, communication patterns, and business requirements change. Continuous Segmentation reassessment enables organizations to maintain least-privilege connectivity without relying on policies that no longer reflect the actual environment. 

When evaluating solutions that can support this visibility, organizations should look for capabilities such as:

• Continuous monitoring for changes in device behavior, risk, and communication
• Detection of changes that may require segmentation policies to be reassessed
• Integration with existing network enforcement technologies to operationalize and update policies

Asimily: Security and Network Team Collaboration Through Network Segmentation Orchestration

Asimily enables security and network teams to collaborate by providing the shared device, risk, and communication context they need to make informed segmentation decisions. The platform continuously identifies and classifies connected IT, IoT, OT, and IoMT assets, maps their communication patterns, and uses risk and behavioral data to generate least-privilege segmentation policies aligned with how devices actually operate.

With Continuous Segmentation including Policy Simulation, teams can create and validate segmentation policies before deployment, helping security teams reduce attack paths while giving network teams confidence that changes will not disrupt legitimate operations. Asimily then orchestrates approved policies through existing network security infrastructure, enabling organizations to operationalize Zero Trust while maximizing their existing NAC and firewall investments.

Learn how Asimily can help your security and network teams turn Zero Trust segmentation into an operational reality. Request a demo today.