This tutorial guides you through building a realistic zero-trust network simulation from scratch. You'll learn how to model a micro-segmented environment as a directed graph, enforce continuous verification for every request, and implement a dynamic policy engine that blends role-based permissions with device posture, MFA, path reachability, zone sensitivity, and live risk signals like anomaly and data-volume indicators. The simulation is operationalized through a Flask API, and mixed traffic—including insider lateral movement and exfiltration attempts—demonstrates how trust scoring, adaptive controls, and automated quarantines block malicious flows in real time.
What is the core concept of a zero-trust network and how does this simulation implement it?
Zero-trust networking operates on the principle of "never trust, always verify." Unlike traditional perimeter-based security, zero-trust assumes that no user, device, or network segment is inherently trustworthy—even if inside the corporate network. Every request must earn access through continuous verification of identity, device health, context, and behavior. In this simulation, zero-trust is implemented by modeling the network as a directed graph where nodes represent assets (e.g., servers, databases, gateways) and edges represent allowed communications. Each request is evaluated by an adaptive policy engine that checks multiple factors—role, device posture, MFA status, zone sensitivity, path reachability, anomaly scores, and data volume—and computes a trust score. Only if the score exceeds a threshold does the request proceed; otherwise, it is blocked or quarantined. This ensures that even legitimate-looking insider actions are scrutinized in real time.
How does graph-based micro-segmentation work in this model?
Micro-segmentation divides the network into small, isolated zones to limit lateral movement and contain breaches. In this simulation, we define five zones: public, DMZ, app, data, and admin, each with a sensitivity level (from 0.15 to 0.95). Assets within each zone (like CDN servers, API gateways, databases, and IAM systems) are represented as nodes in a directed graph. Edges represent allowed communication paths, but even if a path exists, it is not automatically trusted. The graph structure enforces the principle of least privilege: for example, a public asset can only communicate with specific DMZ assets, not directly with databases. During request evaluation, the policy engine checks path reachability within the graph—if no edge exists, the request is denied. This graph-based approach makes it easy to visualize and update access controls dynamically, and it serves as the foundation for the adaptive trust scoring.
What is the adaptive policy engine and what factors does it consider?
The adaptive policy engine is the brain of the zero-trust simulation. It blends ABAC (Attribute-Based Access Control) style permissions with live risk signals to compute a trust score for each request. Factors considered include the user's role (customer, employee, analyst, engineer, admin, secops), device type (managed laptop, BYOD phone, unknown IoT), device posture (a value between 0 and 1 representing how secure the device is), MFA status (whether multi-factor authentication was completed), source network context (corp LAN, VPN, public WiFi, Tor), geographic risk, behavioral anomaly score (detecting unusual access patterns), and data volume being transferred. The engine also checks zone sensitivity and path reachability from the graph. Each factor contributes to a weighted sum, which is passed through a sigmoid function to produce a normalized trust score between 0 and 1. A threshold (e.g., 0.5) determines whether access is granted, or if additional verification or quarantine is triggered.
How is insider threat detection integrated into the simulation?
Insider threats—whether malicious employees or compromised accounts—are a key focus of this simulation. The model simulates mixed traffic that includes normal requests as well as insider lateral movement and exfiltration attempts. Lateral movement is simulated by an insider trying to access assets in more sensitive zones (e.g., moving from the app zone to the admin zone) without proper authorization. Exfiltration attempts are modeled by requests that involve abnormally high data volumes (e.g., copying large tables from a database). The behavioral anomaly score is dynamically adjusted based on these patterns—if a user who normally reads order data suddenly tries to write to the admin database, the anomaly score spikes. The adaptive policy engine incorporates this score into the trust calculation, causing such requests to be blocked or flagged for quarantine. Automated alerts and quarantines are triggered in real time, demonstrating how continuous verification stops attacks even from privileged insiders.
What technologies and tools are used to build the simulation?
The simulation is built using Python with several key libraries. NetworkX is used to model the network as a directed graph, including nodes representing assets and edges for allowed paths. Flask provides a REST API that accepts incoming requests and returns trust scoring decisions. Utility functions for trust normalization, stable hashing, timestamping, and weighted sampling support deterministic simulations. The environment is defined with zones (public, DMZ, app, data, admin), each with a list of assets, and reusable components like request context (user, role, device, location, action) are structured using Python dataclasses. Helper functions format outputs as JSON for easy logging and analysis. The entire simulation runs in a notebook or script, making it accessible for learning and experimentation.
How does the Flask API operationalize the model?
The Flask API acts as the real-time interface between incoming requests and the zero-trust policy engine. When a request arrives (e.g., via an HTTP POST with JSON payload containing user, action, source, destination, etc.), the API parses the context and calls the core evaluation function. This function consults the graph for path reachability, computes the trust score using current device posture, behavior anomaly, data volume, and other factors, and then enforces a decision: allow, deny, or quarantine. If allowed, the request proceeds; if denied, a log entry is created; if quarantined, the user or device is flagged for investigation. The API returns a JSON response with the decision, trust score, and reasons. This makes it easy to simulate mixed traffic by sending scripted requests from different roles and devices, and to observe how adaptive controls respond to both normal and malicious actions in real time.
How does the simulation demonstrate blocking malicious flows in real time?
To demonstrate real-time blocking, the simulation runs a series of scripted traffic patterns. Normal traffic includes customers reading public content and employees performing routine tasks. Malicious flows include lateral movement—e.g., an engineer attempting to access the admin backup vault without reason—and data exfiltration—an analyst downloading gigabytes from the customer database. As each request hits the Flask API, the policy engine evaluates it live. For a lateral move attempt, the path reachability might exist, but the behavioral anomaly score spikes because the action is unusual for the role, causing the trust score to drop below the threshold. For exfiltration, the data volume factor heavily penalizes the trust score. The API responds with "deny" and logs a high-priority alert. Automated quarantines are triggered after multiple suspicious attempts, isolating the user or device. This showcases zero-trust's ability to stop attacks without human intervention.