Defence in depth for one computer

Network defense is usually taught for organizations: a security operations center watching a whole company’s traffic. The underlying ideas apply just as well to a single Mac, scaled down to one person doing the watching. This lesson sets out the concepts the rest of the course builds on.

Defense-in-depth: no single layer is trusted alone

Defense-in-depth means arranging several independent protections so that one failing does not leave the machine open. On one Mac, the layers look like this: the operating system itself (updated, with unnecessary services turned off, covered in this site’s macOS hardening course), a firewall controlling which connections are allowed in and out, the accounts and privileges a piece of software would need to do real damage, and finally your own attention to what looks unusual. None of these is sufficient by itself. An outdated but well-firewalled Mac can still be compromised through a vulnerable app; a fully updated Mac with no firewall at all can still leak data to whatever an app decides to send.

MITRE’s D3FEND matrix, built jointly with the NSA’s Cybersecurity Directorate, organizes exactly this kind of layered thinking into named categories of defensive technique: hardening a system, detecting suspicious activity, isolating what is compromised, and eventually evicting an attacker and restoring normal operation. It is written for large organizations comparing tools and techniques, but the categories map cleanly onto a single Mac: the macOS hardening course in this site covers hardening, this course covers detecting and isolating, and none of it depends on owning a big security team to be useful at a smaller scale.

Minimizing exposure: the attack surface, from the network side

The companion idea to defense-in-depth is minimizing exposure: reducing what is reachable, and what can reach out, in the first place. The macOS hardening course covers this from inside the machine, closing services and ports; network defense covers the same idea from the traffic itself, deciding which connections should exist at all. A service that is never turned on cannot be attacked over the network; a connection that is never allowed cannot exfiltrate data, deliver a payload, or receive instructions from an attacker.

Least privilege, applied to network traffic

Least privilege is usually described in terms of accounts: give a user or process only the access it needs, nothing more. The same logic applies to network connections. A weather app has no legitimate reason to talk to a domain in a country its servers are not in; a text editor has no legitimate reason to make network connections at all. Traffic that does not match what an app should be doing is worth questioning, in the same way an account trying to do something outside its role would be.

Default-deny, and what it costs

A default-deny approach blocks everything except what has been explicitly allowed; default-allow blocks only what has been explicitly identified as bad. Default-deny is the stronger posture in principle, since it does not depend on already knowing about a threat, but it has a real, unavoidable cost: something you actually needed will occasionally be blocked too, and you have to notice and fix that yourself. A mail client that suddenly cannot check for new messages, or a printer driver that cannot find the printer, is usually default-deny doing exactly what it was configured to do, at a moment that is annoying rather than helpful.

This trade-off is why default-deny firewalls tend to ask, rather than silently decide, the first time an app tries to connect: the person using the machine is often the only one who can say whether a given connection is expected. The next lesson covers the specific tools on macOS that let you apply default-deny at different levels, from a single app to the whole network stack.