Segmentation and Access Control Flashcards

Dividing a network into smaller isolated zones each governed by its own access policies. Three motivations: Performance (isolate high-bandwidth apps to prevent interference with other users), Security (prevent direct user-to-database communication; each tier boundary requires an additional attacker compromise), Compliance (PCI-DSS mandates cardholder data isolation; segmentation defines audit scope and simplifies change control). Without segmentation, a single compromised endpoint can reach everything on a flat network. Segmentation is enforced at zone boundaries by firewalls, ACLs, and virtual network policies.

Physical: Separate hardware per segment — switches, cables, NICs. Strongest boundary (air gap possible). Most expensive and least flexible. Used for ICS/SCADA, classified networks, high-compliance CDE. Logical (VLAN): IEEE 802.1Q tags create isolated broadcast domains on shared physical switches. Cost-effective, flexible. Cross-VLAN traffic must be routed. Risk: VLAN hopping if misconfigured. Most common enterprise deployment. Virtual: Software-defined policies in cloud/hypervisor environments — AWS VPCs, Azure NSGs, security groups. Programmatic, scales as code. Micro-segmentation extends per-workload policies to east-west traffic.

The canonical security segmentation pattern for application environments: Tier 1 (Users/Presentation) → communicate only with application servers; Tier 2 (Application servers) → communicate with users on one interface, with database on another; Tier 3 (Database) → accept connections only from application tier. Users can never reach the database directly — a firewall or ACL between tiers 2 and 3 blocks all other sources. Exam rule: the only permitted services in the database zone are SQL (port 1433 / 3306) and SSH (port 22) for administration. Every additional tier an attacker must cross requires an additional compromise.

An ordered set of permit/deny rules evaluated sequentially against each connection or access request. First matching rule wins; if no rule matches, the implicit deny default applies. Match conditions: source IP, destination IP, port, protocol, time of day, application. Two deployment contexts: Network ACLs on routers/firewalls/layer 3 switches (control traffic between segments); System/OS ACLs on operating systems (control access to files, folders, and resources by trustee identity). Same permit/deny logic applies in both contexts. Critical risk: improper rule ordering can lock administrators out of the device they are configuring.

A configuration error where a new ACL rule blocks the administrator's own access to the device, preventing correction. Cause: a broad DENY rule placed before the existing PERMIT rule that covers the admin's connection. The DENY matches first, cutting the admin's session before the PERMIT is evaluated. Prevention: always place the admin access permit rule first; use commit-confirm / scheduled revert (auto-rollback if not confirmed within N minutes); make changes from a management VLAN, not from the network segment being restricted; have a colleague with console/out-of-band access on standby. Exam reminder: rule order is critical because ACLs use first-match evaluation.

Application control policy with a default-deny stance: nothing executes unless explicitly approved. All applications must be listed before they can run. Unknown, unsigned, or unapproved applications — including zero-day malware — are blocked automatically because they are not on the approved list. Strongest security posture for application execution. Highest operational overhead: every new application and every version update requires policy maintenance. Best for: payment terminals, kiosks, industrial controllers, SCADA systems — environments with a fixed, predictable application set. Key insight: a brand-new piece of malware with no signature is still blocked because it was never approved.

Application control policy with a default-permit stance: everything executes unless explicitly blocked. The list contains known-bad applications, hashes, or signatures. Anything not on the list runs freely. Antivirus is the canonical example — blocks known malware signatures, permits everything else. Lower operational overhead than allow lists. Critical weakness: zero-day or novel malware has no entry on the deny list and executes freely. The allow list's default-deny catches unknown malware; the deny list's default-permit allows it through. Appropriate for general-purpose environments where application variety is necessary and allow-list maintenance is impractical.

Identifies permitted executables by their SHA-256 cryptographic hash. Only binaries whose hash matches a stored approved value may execute. Cannot be bypassed by renaming — the hash of the binary content is unchanged by filename. Limitation: any legitimate software update produces a new binary with a new hash, breaking the approval — the policy must be updated for every patch. Best for: internally developed applications and critical system binaries with controlled update cycles. Exam differentiator: if the question asks "what control prevents a renamed malicious binary from executing," hash control is the answer because the hash identifies content, not filename.

Certificate: Permit executables signed by trusted publishers. All future versions from the same publisher auto-permitted — no hash update needed. Weakness: stolen/fraudulent code-signing cert bypasses this. Path: Only allow execution from approved directories (C:\Program Files\, C:\Windows\). Blocks the most common malware delivery pattern — dropping an executable in C:\Users\Downloads\ and running it. Standard malware delivery almost always uses a user-writable temp/download path. Network Zone: Restrict application execution to specific network zones (corporate only, not public Wi-Fi). Defense-in-depth for roaming endpoints — reduces attack surface outside the protected perimeter.

PCI-DSS (Payment Card Industry Data Security Standard) mandates that systems handling cardholder data be isolated from all other network traffic in a defined Cardholder Data Environment (CDE). Network segmentation creates this isolation boundary. The security benefit: breach containment — an attacker who compromises a system outside the CDE cannot reach payment systems directly. The compliance benefit: audit scope reduction — only systems within the CDE segment are subject to the full PCI audit burden. Systems outside the CDE are not in scope. Segmentation also simplifies change control by limiting the impact of configuration changes to the specific zone being modified.