Enterprise Network Security and Zero-Trust Architecture

C H A P T E R 0 5 Make routing authorization narrower than reachability Routing determines where packets travel, and a route announcement is not automatically proof that its origin is authorized. BGP policy reflects relationships between networks as well as technical reachability. A secure design constrains expected prefixes, origin information and export relationships, then monitors changes from outside its own routers. Route Origin Validation uses RPKI-derived information to classify a route's origin and prefix length. The principal states are Valid, Invalid and NotFound. [S10] NotFound means there is no applicable covering authorization; it is not the same as Invalid. A Valid origin result does not authenticate the complete AS path or prove that the route's propagation is appropriate. Understand maxLength before publishing a ROA A ROA can authorize more-specific prefixes up to a maximum length. Broad authorization may be operationally convenient, but it permits more announcements to satisfy origin validation. RFC 9319 recommends avoiding unnecessary maxLength exposure. [S11] Publish the announcements the organization actually needs, with a controlled process for changes and emergencies. FIGURE 04 / ROUTING EVIDENCE Origin, path and export policy are different checks Prefix authorization Expected origin and permitted prefix length Neighbor policy Accepted routes, limits and relationship ↓ No single signal covers every routing failure ↓ Path / leak checks Applicable roles, attributes and verification External monitoring Observed origins, paths and reachability RPKI Valid is an origin result, not a complete route-safety verdict. Keep validator availability and routing policy changes in the operational recovery plan. Enterprise Network & Zero Trust SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 12

C H A P T E R 1 1 Turn zero trust into explicit policy decisions Zero trust starts from resource access rather than treating location as sufficient evidence of trust. NIST distinguishes policy decision and enforcement responsibilities, including the policy engine, policy administrator and policy enforcement point. [S01] These are logical roles; a product may combine them, but the architecture still needs to explain their interactions. For a sensitive operation, define the subject, device or workload, requested action, resource, environmental evidence and decision lifetime. The policy engine evaluates that context. The administrator establishes or removes the permitted access path. The enforcement point applies the decision where the request can actually be stopped. FIGURE 08 / RESOURCE ACCESS Evidence becomes a bounded authorization decision Evidence User, workload, device posture and resource context Policy engine Evaluate a versioned rule and decision lifetime ↓ Protect the control channel and record decision versions ↓ Policy administration Establish, update or revoke access Enforcement point Allow the specific operation or deny it Trust signals inform a decision; they do not create permanent network trust. Re-evaluation frequency and session termination depend on the resource risk and the enforcement technology. Separate evidence freshness from credential validity A device certificate can remain valid while the device's posture changes. A user session can remain authenticated after a role is removed. Define how fresh each signal must be and what happens when it becomes unavailable. A last-known-good value may support a bounded low-risk operation, but it should not authorize an unlimited stream of privileged changes. In a synthetic design, a read-only analytics session can retain an authorization decision for five minutes, while a production configuration write requires a current approval and fresh workload evidence. These are illustrative policy choices, not universal intervals. Explain why the business impact supports different lifetimes and how the enforcement point recognizes expiration. Enterprise Network & Zero Trust SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 24

C H A P T E R 1 7 Isolate the different planes of an AI cluster An AI training cluster has several networks with different performance and trust requirements. The management plane controls hosts, schedulers and devices. The data plane moves training examples, checkpoints and artifacts. The accelerator fabric supports collective communication or other high- throughput operations. User access and telemetry add further paths. Treating all of them as one trusted internal network makes compromise difficult to contain. Begin with tenant and job isolation. Determine whether jobs share hosts, accelerators, network interfaces, storage identities or management components. A container boundary does not automatically establish the isolation needed for mutually untrusted workloads, especially when devices or privileged runtime features are exposed. FIGURE 13 / AI INFRASTRUCTURE Performance networks need explicit trust boundaries Management plane Scheduler, host administration and device control Storage / artifact plane Datasets, checkpoints and signed release bundles ↓ Authorize crossings instead of bridging every plane ↓ Accelerator fabric Job-scoped high-throughput communication User / egress plane Approved access and constrained external services A training job should not inherit the authority to administer its host, fabric or model registry. Physical separation, virtual isolation and identity controls must be selected from the actual hardware and tenancy model. Understand what RDMA changes RDMA permits supported data movement with reduced involvement of the remote CPU in the data path. The protection model depends on registered memory, queue and connection state, access keys, device configuration and the fabric. These mechanisms are not interchangeable with application- layer TLS authorization. Enterprise Network & Zero Trust SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 36