Segmentation and Access Control — Glossary

The practice of dividing a network into smaller, isolated zones each governed by its own access policies. Segmentation serves three purposes: performance (isolating high-bandwidth applications to prevent interference), security (preventing direct communication between system tiers, limiting lateral movement after a breach), and compliance (mandated isolation for sensitive data such as PCI-DSS cardholder data). Without segmentation, a compromised endpoint can reach every other system on the flat network. With segmentation, a breach is contained to its zone and further access requires crossing an enforced boundary.

Isolation of network zones using separate, dedicated hardware — distinct switches, routers, cabling, and NICs. Traffic between physically segmented networks must traverse a physical boundary device (firewall, router) with no shared medium. The strongest form of segmentation: an air-gapped network has no physical path for network attacks. Cost and inflexibility are the tradeoffs — reconfiguration requires physical changes. Deployed in industrial control systems, classified government networks, and high-compliance environments where the security requirement justifies the infrastructure cost.

Isolation of network zones using Virtual Local Area Networks (VLANs) on shared physical switching infrastructure. IEEE 802.1Q VLAN tags label each Ethernet frame with a VLAN ID; the switch forwards traffic only within the same VLAN. Cross-VLAN traffic must be routed by a layer 3 device where ACLs apply. A single physical switch supports multiple isolated broadcast domains simultaneously. More cost-effective and flexible than physical segmentation. Requires correct configuration of trunk ports and native VLANs to prevent VLAN-hopping attacks. Exam note: VLANs are the most common form of logical segmentation.

Segmentation implemented in virtualized and cloud environments through software-defined networking constructs — cloud VPCs, virtual switches, security groups, and network policies. No physical infrastructure is required. Micro-segmentation applies fine-grained policies at the individual workload (VM or container) level, subjecting east-west (workload-to-workload) traffic to the same inspection as north-south (perimeter) traffic. Programmatic and scalable — policies are defined in code and deployed automatically. Key cloud examples: AWS Security Groups, Azure NSGs, GCP VPC Firewall Rules.

The canonical security segmentation pattern separating presentation, application, and data tiers into distinct network zones with enforced access controls between each boundary. Tier 1 (Users): workstations communicate only with application servers. Tier 2 (Application servers): communicate with users on one interface and database servers on another. Tier 3 (Database servers): accept connections only from application servers — no direct user access, ever. Exam rule: the only services permitted in the database zone are SQL and SSH (for admin). Every additional tier boundary the attacker must cross requires an additional compromise step.

An ordered set of rules evaluated sequentially against each connection or access request to determine whether to permit or deny it. Match conditions include source IP, destination IP, port, protocol, time of day, and application type. The first matching rule determines the outcome; if no rule matches, the default action (typically deny) applies. ACLs exist at two levels: network ACLs on routers, firewalls, and layer 3 switches (control traffic between segments) and system ACLs on operating systems (control access to files, folders, and resources by user or group). Both use the same permit/deny logic.

The default action at the end of an ACL rule list when no explicit rule has matched the evaluated traffic: deny the connection. The implicit deny rule is not written as an explicit entry — it is the behavioral default of a security-hardened ACL. If no permit rule covers a particular traffic pattern, that traffic is blocked. This design principle ensures that the security posture is "deny unless explicitly allowed" rather than "allow unless explicitly denied." An improperly configured ACL that lacks a final explicit deny may permit unexpected traffic if the device's default is to allow unmatched traffic.

The identity — user account, group, or service — to which access permissions are assigned in an OS-level ACL. In Windows, a trustee is identified by its Security Identifier (SID). The DACL (Discretionary Access Control List) on a resource contains one or more Access Control Entries (ACEs), each pairing a trustee with a set of rights (read, write, execute, modify, full control). The OS evaluates a user's effective permissions by combining all ACEs where the user is named as trustee — either directly or through group membership.

An application control policy with a default-deny stance: nothing executes unless it is explicitly approved. Every permitted application must be individually listed. Unknown, unsigned, or unapproved applications are blocked regardless of whether they have been identified as malicious. The strongest application control posture — a brand-new piece of malware not on any deny list is still blocked because it is not on the allow list. Highest operational overhead: every new application and every version update requires policy maintenance. Appropriate for environments with fixed application sets: kiosks, payment terminals, industrial controllers.

An application control policy with a default-permit stance: everything executes unless it is explicitly blocked. The list contains known-bad applications, signatures, or hashes. Anything not on the list runs freely. Antivirus software is the canonical deny-list model — it blocks applications matching known malware signatures but permits all others. The critical weakness: unknown or zero-day malware has no signature and passes through freely. Lower operational overhead than allow lists — only newly identified malware requires a new entry. Appropriate for general-purpose environments where application flexibility is required.

Application control mechanism that identifies permitted executables by their cryptographic hash value (SHA-256 of the binary). Only executables whose hash matches a stored approved value are permitted to run. Extremely precise — a renamed or slightly modified binary produces a different hash and is blocked. Limitation: any legitimate software update changes the binary and therefore the hash, requiring policy updates on every patch. Used for internally developed applications, system-critical binaries, and environments where software change is tightly controlled. Cannot be bypassed by renaming files or changing extensions.

Application control mechanism that permits executables based on the digital signature and publisher certificate of the signed binary. Policies specify which certificate issuers or publishers are trusted. All applications signed by a trusted publisher are permitted — including future versions — without requiring policy updates for each new release. Scales well across large software inventories. Critical weakness: a malicious application signed with a stolen, compromised, or fraudulently obtained code-signing certificate bypasses this control. More operationally efficient than hash control but with a different trust model risk.

Application control mechanism that restricts execution to specific approved filesystem directories. Typical rule: allow execution from C:\Program Files\, C:\Windows\ — deny execution from C:\Users\, %TEMP%, %APPDATA%, and all other user-writable locations. Directly counters the most common malware delivery pattern: dropping an executable in a user-accessible directory and running it. Standard software installers write to Program Files (administrator-controlled); malware delivered via phishing or drive-by download writes to user-writable temp or download directories. Limitation: does not block malicious activity using a legitimate application already installed in an approved path.