protection vs security

Imagine a large office building. Inside, every employee carries a key card that opens only the doors their job requires — the warehouse worker cannot wander into the finance vault. That internal system of locks and keys is one kind of safety. Quite separately, the building has guards at the entrance, cameras, and an alarm that watches for burglars trying to break in from outside. The first system controls honest people doing their jobs; the second defends against attackers. Operating systems draw exactly this line, and they call the two ideas protection and security.

Protection is about the internal mechanisms that decide what a running program may touch. It answers the precise, mechanical question: given that this process is running, what memory, files, and devices is it allowed to access, and how does the hardware and kernel enforce that? Protection assumes the players are not necessarily malicious — it is there even to stop an honest program with a bug from scribbling over another program's memory. Security is the broader concern of defending the system against deliberate misuse by adversaries: it includes the threats (viruses, attackers stealing passwords), the policies (who should be allowed to do what), and whether the protection mechanisms are actually strong enough to resist a clever opponent. A rough slogan: protection is the mechanism, security is the goal and the policy.

The reason the distinction matters is that you can have perfect protection mechanisms and still be insecure, and vice versa. If your locks work flawlessly but you hand the master key to everyone (a bad policy), you are protected by the mechanism yet wide open as a matter of security. Conversely, a great security policy is worthless if the underlying protection has a hole that lets a process bypass the locks entirely. Good systems need both: correct mechanisms (protection) serving a sensible, well-thought-out policy against real threats (security).