Section 1: Security Boundaries and Isolation

The Big Picture: Why Walls Matter

A modern PC runs hundreds of programs at once. Some are trusted (Windows itself). Some are not (a web page you just opened, a file someone emailed you). If every program could touch everything, one bad program would own the whole PC.

So Windows builds walls between things. Security people call a wall a security boundary: a line that code on one side is not allowed to cross without permission. Almost every security feature in this chapter is either a wall, a lock on a wall, or a guard watching a wall.

Think of an apartment building:

Important idea: defence in depth. No single wall is perfect. Windows stacks many walls, so an attacker who breaks one still faces the next.

          DEFENCE IN DEPTH (outside → inside)

 ┌─────────────────────────────────────────────────┐
 │ Firewall, SmartScreen (stop it arriving)        │
 │ ┌─────────────────────────────────────────────┐ │
 │ │ Defender, App Control (stop it running)     │ │
 │ │ ┌─────────────────────────────────────────┐ │ │
 │ │ │ Sandbox, integrity level (contain it)   │ │ │
 │ │ │ ┌─────────────────────────────────────┐ │ │ │
 │ │ │ │ Kernel mode + VBS (protect the core)│ │ │ │
 │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │
 │ │ │ │ │ Secure Boot, TPM, BitLocker     │ │ │ │ │
 │ │ │ │ │ (protect hardware and disk)     │ │ │ │ │
 │ │ │ │ └─────────────────────────────────┘ │ │ │ │
 │ │ │ └─────────────────────────────────────┘ │ │ │
 │ │ └─────────────────────────────────────────┘ │ │
 │ └─────────────────────────────────────────────┘ │
 └─────────────────────────────────────────────────┘

1.1 Process Isolation

What it is: A process is a running program. Process isolation means each process gets its own private world, and cannot see or change another process's memory or resources by default.

Virtual address spaces. From Chapter 3 you know that programs do not use real RAM addresses. The CPU and Windows give every process a virtual address space: a private set of addresses that Windows maps to real RAM behind the scenes. Process A's address 0x1000 and process B's address 0x1000 point to different real memory. A cannot even name B's memory, let alone read it.

 Process A (browser)            Process B (notepad)
 ┌───────────────────┐          ┌───────────────────┐
 │ virtual address   │          │ virtual address   │
 │ 0x1000            │          │ 0x1000            │
 └─────────┬─────────┘          └─────────┬─────────┘
           │                              │
           ▼                              ▼
 ┌───────────────────────────────────────────────────┐
 │ Real RAM: two DIFFERENT places                    │
 │      [ A's data ]            [ B's data ]         │
 └───────────────────────────────────────────────────┘

Other things that are kept separate:

Integrity levels. Windows adds a "rank" to every process and object, called an integrity level. A lower-ranked process cannot write to a higher-ranked object, even if the normal permissions would allow it.

This is why a hacked browser tab (Low) cannot silently edit your Documents (Medium) or Windows files.

When walls are crossed on purpose. Processes sometimes need to talk. Windows gives safe doors: pipes, network sockets, shared memory that both sides agree on, and messages. A program can also reach into another process with debugging functions, but Windows checks the token and integrity level first.

Windows tip: In Task Manager, open the Details tab, right-click a column header, choose Select columns and tick Elevated to see which processes run as admin. The free Sysinternals tool Process Explorer can also show the integrity level.

1.2 User Mode and Kernel Mode Isolation

What it is: The CPU itself has privilege levels (called rings on x86 chips). Windows uses just two:

The CPU enforces this in hardware. If a user-mode program tries a forbidden instruction, the CPU raises an exception and Windows stops the program.

How does a normal app get something done, like reading a file? It makes a system call. The app asks, the kernel checks "are you allowed?", and only then does the work.

 USER MODE (ring 3)     ┌─────────────────────────┐
                        │ App: "read this file"   │
                        └────────────┬────────────┘
                                     │ system call (a controlled door)
 ════════════════════════════════════╪═════════════════
 KERNEL MODE (ring 0)   ┌────────────▼────────────┐
                        │ Kernel checks the token │
                        │ and the file's ACL      │
                        └────────────┬────────────┘
                                     │ allowed? do the work
                        ┌────────────▼────────────┐
                        │ Drivers → disk          │
                        └─────────────────────────┘

Why kernel mode is the crown jewel. Code in the kernel has no walls left. A buggy or evil driver (drivers run in kernel mode) can crash Windows or hide malware from everything else. That is why:

• Windows requires kernel-mode drivers to be digitally signed (Section 9).
• Secure Boot (Section 3) makes sure nothing unsigned loads early.
• Newer Windows uses VBS (next topic) to protect the kernel itself.
• Windows can use a vulnerable driver blocklist that refuses known-bad signed drivers (depends on version and settings).

Kernel protections you may hear of:

1.3 Virtualization-Based Security (VBS)

What it is: VBS uses the CPU's virtualization features and the Hyper-V hypervisor to build an extra, protected area inside your running PC. Even if an attacker takes over the normal Windows kernel, they still cannot read what is inside this area.

Key words:

• A hypervisor is a very thin layer of software that runs below Windows and decides who can use memory and the CPU. It is the same technology that runs virtual machines.
• Hyper-V is Microsoft's hypervisor. With VBS on, Windows itself runs on top of it as the "normal world".
• A Virtual Trust Level (VTL) is a rank. Normal Windows is VTL0. The protected area is VTL1.

 ┌───────────────────────────────────────────────┐
 │ NORMAL WORLD (VTL0)                           │
 │ Apps - Windows kernel - drivers               │
 │ (if attacked, still cannot see VTL1)          │
 ├───────────────────────────────────────────────┤
 │ SECURE WORLD (VTL1)                           │
 │ Tiny secure kernel + isolated programs        │
 │ (hold secrets such as Credential Guard data)  │
 ├───────────────────────────────────────────────┤
 │ HYPERVISOR (Hyper-V) - enforces the split     │
 ├───────────────────────────────────────────────┤
 │ HARDWARE (CPU virtualization, IOMMU)          │
 └───────────────────────────────────────────────┘

The hypervisor controls the page tables that decide which memory each world can see. VTL0 simply has no mapping to VTL1 memory.

What VBS protects (examples):

Hardware needed (roughly): a 64-bit CPU with virtualization extensions and second-level address translation, UEFI firmware with Secure Boot, and (for the best result) a TPM 2.0. Windows 11 turns VBS on by default on many new PCs, but this depends on your hardware, edition and drivers. An incompatible old driver can stop Memory integrity from turning on.

Windows tip: Open msinfo32 and look at the System Summary line Virtualization-based security. It says Running or Not enabled. You can also see Windows Security → Device security → Core isolation.

The honest limit. VBS raises the bar a lot, but it is not magic. It depends on firmware and the hypervisor being correct. It is one layer in the defence in depth, not a replacement for the others.

Summary