4.4Security architecture

For a system architect, security design is not something to "bolt on" in a later phase—it must be built into the architecture from the earliest stage. The idea that securing the perimeter (a firewall, etc.) alone is enough no longer holds, given internal-network intrusions and the spread of cloud usage and remote work. This section builds the judgment to decide which countermeasures to place at which layer, given business requirements and risk, grounded in the two defensive philosophies of defense in depth and zero trust, the division of roles between authentication and authorization, and the secure-by-design mindset.

4.4.1Defense in depth and zero trust

• Defense in depth is a design philosophy that places independent countermeasures at each of several layers—network perimeter, server, application, and data—so that if one layer is breached, the others contain the damage. Relying on perimeter defense alone (a firewall only) leaves the interior undefended the moment the perimeter is breached, so layering different kinds of countermeasures at each layer (a perimeter firewall, server patch management, an application WAF, data encryption, and so on) is the key to reducing risk.
• Zero trust is an architectural mindset that places no implicit trust in the idea that "it is safe because it is the internal network," and instead verifies every access, whether from inside or outside the company, each time it occurs. Whereas perimeter defense and defense in depth assume "outside is dangerous, inside is safe," zero trust assumes that the internal network may already be compromised (or that the perimeter itself has become blurred, e.g., through remote work), and performs authentication, authorization, and device-state verification on every access. The two are not mutually exclusive; in practice it is common to combine them, building zero-trust-style verification into one of the layers of defense in depth.

4.4.2Authentication and authorization

• Authentication is the process of confirming "who the user is" (ID/password, multi-factor authentication (MFA), certificates, etc.). Authorization is the process of determining, for a user already identified via authentication, "what they are allowed to do" (role-based access control (RBAC), etc.). Authentication is identity verification and authorization is permission determination—two distinct steps; succeeding at authentication does not mean every operation is permitted.
• A typical mistake in architecture design is treating authentication alone as sufficient and deferring authorization (designing the granularity of permissions). For example, implementing only a login feature (authentication) while granting every logged-in user admin-equivalent operations fails to prevent excessive privilege use (insider misuse or operational error) by a legitimately logged-in user. It is important to design authorization as a pair with authentication, based on the principle of least privilege (restricting permissions to only the operations actually needed).

4.4.3Secure by design and threat analysis

• Secure by design is the mindset of building security requirements in from the requirements-definition and design stage, standing in contrast to the costlier approach of discovering flaws via vulnerability scanning after implementation is complete and fixing them after the fact. It is grounded in the principle that addressing security upstream carries a smaller rework cost. Concrete practices include making default settings safe (secure by default) and restricting permissions to the minimum necessary (the principle of least privilege).
• Threat analysis (threat modeling) is the activity, performed at the design stage, of systematically enumerating "who might attack, for what purpose, and by what means," and deciding the priority of countermeasures. Rather than treating every conceivable threat equally, evaluating risk from both the likelihood of occurrence and the impact, and addressing the highest-priority threats first, leads to effective security investment within a limited budget.

Suppose a medical information system's architect receives a modification requirement to let remote-working staff access patient data from outside the corporate network. The existing design assumed a perimeter defense premised on "trust it if it is connected to the internal network," and the architect must first recognize that introducing remote work blurs the perimeter itself and undermines the premise of perimeter defense. The misjudgment to avoid here is thinking "as long as staff connect to the internal network via VPN, the existing perimeter-defense mechanism can be used as-is unchanged"—even once a VPN connection "joins" the internal network, the risk that the connecting device is personally owned or infected with malware remains unchanged, so the perimeter-defense premise (inside = safe) still does not hold. The appropriate design, based on the zero-trust mindset, is to verify, on every access to patient data regardless of whether the VPN connection succeeded, the user's authentication (MFA required), the device's state (OS patch status, antivirus running), and authorization against the data being accessed (least-privilege RBAC tied to department and role), every single time. Furthermore, rather than implementing this change as a one-off fix, practicing secure by design means performing threat analysis at the design stage, enumerating concrete threat scenarios such as "access from a personally owned device," "eavesdropping over public Wi-Fi," and "misuse of a departed employee's account," and deciding the priority of countermeasures according to each scenario's likelihood and impact (for example, given the high sensitivity of patient data, prioritizing device-state verification and authorization-granularity design first). It also bears noting that introducing authentication (MFA) alone and calling it done, while deferring authorization-granularity design (which role can access which patients' data), fails to prevent excessive access by a legitimately logged-in staff member (viewing patient data not needed for their actual duties).

4.4.4Section summary

• Defense in depth layers independent countermeasures at each layer; zero trust trusts nothing, even internally, and verifies every access—combining the two is common in practice
• Authentication (identity verification) and authorization (permission determination) are separate steps; design both as a pair, based on the principle of least privilege
• Secure by design builds security in from the upstream stages, and threat analysis prioritizes countermeasures by likelihood and impact