Opening Framing: What Does It Mean for Code to Run?
Last week, you crossed an important threshold: you stopped thinking of "the computer" as a black box. You saw that an operating system is a system of decisions — policies enforced through structure.
This week we focus on the first and most dangerous boundary in cybersecurity: execution.
When code runs, the system is not merely "doing something." It is granting a request: CPU time, memory, access to files, access to network, access to devices — sometimes with privileges the user does not fully understand.
So the real question is not "What does this program do?" The real question is:
Who is the system acting on behalf of when it runs this code?
1) A Process Is Not a Program
In everyday language, people treat "program" and "process" as the same thing. In security, that mistake is costly.
A program is a static artifact: a file on disk. It can be copied, renamed, scanned, archived, and forgotten.
A process is a living instance: an active execution context with memory, permissions, open files, and relationships to other processes.
Security incidents rarely happen because a program exists on disk. They happen because a program becomes a process — because the system agrees to run it.
Mental model: A program is a blueprint. A process is the building that is currently occupied. Security cares about the occupied building.
2) Execution Is Delegated Trust
When you execute software, you are delegating trust through the operating system. You might believe you are asking for one thing — "open this app" — but the OS is authorizing a chain of actions that includes:
- Loading code into memory
- Allocating CPU time and scheduling priority
- Assigning identity (user, group, privileges)
- Allowing access to files, devices, and networks (directly or indirectly)
- Allowing the process to spawn other processes
This matters because most "attacks" are not a single clever act. They are a sequence of granted permissions that were never reviewed as a sequence.
Professionals therefore learn to ask:
- What is the actual execution context?
- What privileges were inherited?
- What resources became reachable?
- What new actions became possible?
3) The OS Runs More Than You Think
A common early misconception is that "things run because I started them." In reality, most of what runs on a system is running because:
- the system started it at boot
- a service manager restarted it after failure
- another process spawned it
- a scheduled task triggered it
This is not an edge case. It is normal system behavior. And it creates a central security fact:
If you don't know what should be running, you can't know what is suspicious.
4) Process Relationships: Parents, Children, and Trust Chains
Processes do not exist in isolation. Every process (except the first) was created by another process — its parent. This creates a family tree of execution.
Security implications of parent-child relationships:
- Identity inheritance: child processes often inherit the user identity, environment variables, and permissions of their parent
- Trust propagation: if you trust a parent process, you implicitly trust what it spawns — which attackers exploit
- Visibility: defenders can trace suspicious processes back to their origin by following the parent chain
- Detection: unusual parent-child relationships (e.g., Word spawning PowerShell) are strong indicators of compromise
On Linux, you can observe this with ps -ef --forest or pstree.
On Windows, tools like Process Explorer show the process tree visually.
Key insight: processes form trust chains. Following those chains — forward and backward — is a core defensive skill.
Real-World Context: Execution as the Attack Surface
Understanding processes and execution is not academic. It's how real attacks work:
Process Injection Attacks: Attackers frequently inject malicious code into legitimate processes. The malware runs under the identity of a trusted process — your browser, a system service, or an update tool. Security tools looking for "bad programs" miss the attack because the program is legitimate; only the execution context is compromised. MITRE ATT&CK documents this as technique T1055.
Living Off the Land (LOLBins): Sophisticated attackers avoid dropping new executables entirely. Instead, they abuse built-in system tools — PowerShell, WMI, certutil, mshta — that already exist and are already trusted. The attack happens through execution of legitimate programs with malicious parameters. No new files, no obvious signatures, just processes doing unexpected things.
Parent-Child Process Abuse: Security tools often trust processes based on their parent. If Word spawns a child process, that might be normal. If Word spawns PowerShell which spawns cmd.exe which downloads a file — that's suspicious. Attackers exploit this by carefully constructing process trees that look legitimate.
Common thread: attacks target execution, not just files. Understanding what processes should be running, who should spawn them, and what they should do is defensive knowledge.
Guided Lab: Observing Execution (Concept → Evidence)
This lab is still observation-focused. We are not "hardening" yet. We are training your ability to see execution as the OS sees it: processes, owners, parent-child relationships, and resource usage.