Security

In short: Umbrella term for all measures that protect IT systems, data and networks from unauthorised access, manipulation or failure.

In more detail: Security isn’t a single tool, but an interplay of technical measures (firewalls, encryption, authentication), organisational processes (permission concepts, patch management) and physical security (access control to server rooms). A rough distinction is made between preventive measures (preventing attacks), detective measures (detecting attacks, e.g. with a sniffer) and reactive measures (responding to an incident).

In Depth

A central mental model in IT security is the “CIA triad” — not the intelligence agency, but the three basic goals of any protective measure:

Confidentiality  - only authorised people may view data
Integrity        - data must not be altered unnoticed
Availability     - systems must remain reachable for authorised people

These three goals are often in tension with each other: completely disconnecting a system from the network maximises confidentiality but destroys availability; additional security checks at every login increase security but worsen usability. Good security decisions therefore always weigh the actual protection needs against the effort/restriction involved, instead of blindly striving for the theoretical maximum of security.

Another basic principle is “defence in depth” (layered defence): instead of relying on a single protective measure (e.g. just a firewall), several independent layers are combined (firewall + encryption + authentication + monitoring), so that an attacker who gets past one layer fails at the next. In practice this means, for example: even if an attacker gains access to a server through a vulnerability, the passwords stored there should still be hashed (see hashing) — a second layer that cushions the first failure.

The principle of least privilege

Another foundational principle is “least privilege” (minimal rights allocation): every user, every service and every process should fundamentally only receive exactly the permissions it actually needs for its concrete task — no more. A practical example: a web server process that only needs to serve files shouldn’t run with administrator rights, because if it’s compromised, an attacker would otherwise automatically inherit the same far-reaching rights. Least privilege thereby limits the maximum possible damage of a single successful attack, even if a vulnerability couldn’t be prevented in time.

Zero trust as a modern approach

Classic security concepts long assumed a clear “inside” (trusted internal network) and “outside” (insecure internet), secured by a firewall at the boundary — once inside the internal network, you often automatically enjoyed elevated trust. The “zero trust” model deliberately discards this assumption: no device and no user is classified as trustworthy solely based on its location in the network — EVERY access to EVERY resource is checked and authenticated individually, regardless of whether the request comes from the internal network or from outside. The approach gained importance especially with the spread of remote work and cloud services, because the classic notion of a clearly bounded “internal network” is no longer realistic for many companies anyway.

Security as a continuous process, not a state

A common misconception is treating security as a “finished” state that can be achieved once — in reality it’s an ongoing process, because both the threat landscape (new attack techniques, newly discovered vulnerabilities) and the system itself (new features, new dependencies) constantly change. A system considered secure today can be vulnerable tomorrow through a newly discovered vulnerability in a library it uses — which is why regular security updates, automated dependency scans (e.g. npm audit) and periodic security audits are part of any serious security concept, not just the one-off hardening at a system’s original launch.

See also: Cybersecurity, Firewall