Layered Controls

Defense-in-depth layers literacy names physical, network, host, application, and data layers — draft layer map rows on YOUR $ARCH_LAB fictional org LAB-ARCH-001 before control placement decisions.

Layered Controls• Audio Walkthrough

00:00/03:41

Visual · t41_layers_named

Layers named literacy. $ARCH_LAB only. Original Cyberlium.

You cannot place controls without naming layers — literacy teaches defense-in-depth vocabulary so fictional org scenarios on $ARCH_LAB get documented before architecture reviews.

Defense in depth stacks independent control layers — physical perimeter, network segmentation, host hardening, application security, data protection — so failure of one layer does not collapse the entire posture. On Cyberlium you practice on fictional systems in YOUR $ARCH_LAB org template — lab web tier, example.local API, training database — never paste real employer network maps or live infrastructure VLAN exports into layer notes. Cyberlium maps layer row on YOUR $ARCH_LAB — layer name, example control, fictional system on LAB-ARCH-001 for one stack level. Next: Perimeter vs Zero Trust.

1. Defense-in-depth layers (named)

Physical: facility access, locks, cameras on YOUR fictional org. Network: firewalls, segmentation, IDS. Host: patching, EDR, hardening baselines. Application: secure SDLC, input validation, authZ. Data: encryption, classification, DLP at rest and in transit.

On $ARCH_LAB, write layer row — layer name, one example control, fictional LAB-ARCH-001 system it protects.

Command guide

Try these commands — Defense-in-depth layers (named)

═══ LINUX / macOS (Terminal Practice) ═══

Check system state and user context

Command — copy this

id
whoami
uname -a

Inspect network sockets listening for connections

Command — copy this

ss -tuln 2>/dev/null || netstat -tuln

Audit active processes

Command — copy this

ps aux | grep -v "\[" | head -15

═══ WINDOWS (POWERSHELL) ═══ Query user identity and system information

Command — copy this

whoami /all
Get-ComputerInfo | Select-Object CsName, OsName, OsVersion

Primary tools to practice this lesson: curl, grep. Reference sites: NIST 800-160 (https://csrc.nist.gov/publications/detail/sp/800-160/vol-1/rev-1/final); OWASP ASVS (https://owasp.org/www-project-application-security-verification-standard/); Microsoft SDL (https://www.microsoft.com/en-us/securityengineering/sdl/). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.

2. Why layers precede single-control heroics

One firewall does not replace host hardening or application testing. Shared layer vocabulary aligns security, network, and development teams on the same design diagram. Version-controlled layer maps survive architecture review questions on lab templates.

Students draft lab layer maps on notes — production architecture follows enterprise standards and change control.

3. Lab boundary

Forbidden: copying real employer VLAN diagrams into lab layer maps as if fictional. Allowed: layers named card — one row per layer with $ARCH_LAB fictional system example.

Ship: layer map row for YOUR lab org system. Next: Perimeter vs Zero Trust.

4. What you ship: layer map row for $ARCH_LAB

Layer name, example control, fictional system. $ARCH_LAB named. chmod 600.

5. What you record before the next lesson

Date. Layer map row. $ARCH_LAB named. File t41-m02-l01-layers-named.txt chmod 600.

6. Wrong vs right: offensive playbooks vs YOUR threat models

Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.

Wrong: Paste employer network diagram into lab layer map. Skip data layer because 'network is enough.'
Right: Write layer map row for YOUR $ARCH_LAB fictional system. Next: Perimeter vs Zero Trust.

Hands-on Exercise