An Approachable Intro to Security Architecture

Let's make security architecture easier to understand by exploring it through the perspective of a made-up company that we will call Northwind Health. Northwind Health is a medium-sized healthcare provider with a mix of cloud and on-prem systems, remote workers, sensitive data, APIs, and the usual human behaviors.

In this article, we're going to walk through each architectural component layer by layer to see how a company like Northwind Health actually secures itself.

Identity & Access Management (IAM)

Northwind Health uses a hybrid model, which includes Azure AD for cloud identity, on-premises Active Directory for legacy systems, and Google Cloud Platform (GCP) for analytics tools. All employees use Single Sign-On (SSO) to log in to internal systems, the patient portal, and all SaaS applications.

How IAM is structured

The Northwind security team applies the principle of least privilege by default, meaning employees only have access to what they need. As a result, the nurses can view patient charts but cannot view Billing resources or make billing changes. While the Billing staff can make changes to certain resources, they do not have access clinical data because as this is beyond the scope their role. Admin privileges are separated into tightly controlled groups that require just-in-time (JIT) elevation so they can only gain higher access for a short window, and only when they need it.

Where IAM gets interesting is where service accounts are concerned. Northwind uses several service accounts in GCP to run jobs, sync clinical records, and send data to their analytics dashboards. This is potentially one of the biggest risk areas in their architecture if not correctly handled.

Here's an example scenario where an overly permissive service account can lead to a breach. One of their service accounts is responsible for collecting anonymous patient data from the clinical systems. This service account was created in a hurry during a vendor migration and was granted the role of GCP Owner.

That means this service account can create new VMs, change firewall rules, modify IAM policies, access or delete storage buckets, spin up compute resources, deploy new containers, and disable logging. All these permissions just because the admin didn't have time to figure out the exact ones needed.

This account's service key could leak in a multitude of ways. Potentially, through a GitHub repo, a misconfigured server, a phishing attack on the admin, or a VM compromise. If this happens, an attacker can easily become a cloud administrator in Northwind without ever touching a user account.

What proper IAM looks like

If the admin had done this correctly, that service account would only have Storage Object Viewer, BigQuery Data Editor, and Pub/Sub Publisher permissions. Identity permissions should be assigned in such a way that if an account does get compromised, the impact radius stays small.

Network Security

Now let's discuss what network security would look like for Northwind Health's environment. Let's imagine the environment revolves around network segmentation, with a headquarters location, three clinics, and a cloud environment.

The network was designed so devices don't all pool into one big network. Instead, there's a clinical network for the Electronic Health Records system. The guest Wi-Fi stays completely isolated from internal systems. Administrative work like HR, billing, and executive systems sit on their own network. As is standard, the development environment is kept separate from production. Legacy systems that run on-premises servers have their own network segment. Remote employees connect through VPN into a dedicated and restricted segment.

In this setup, if an attacker compromises a receptionist’s workstation, the layout of Northwind's architecture would prevent them from pivoting into the clinical network which consists of patient data.

Now, imagine a scenario in which a remote employee clicks a malicious PDF link, allowing an attacker to gain initial access to their work computer. If there were no network segmentation, the attacker could scan laterally until they discovered something of value. However, at Northwind, network segmentation would hinder that agenda because it limits what a user inside the network can access. Similarly, employees connecting via VPN would be subject to conditional access rules that add remote staff to a network segment with no visibility into clinical servers. So even if the attack progresses, the architectural design will ultimately protect the crown jewels.

This is network security architecture at its best. It’s not just about firewalls, but every boundary must be set with the intention of disrupting attack progression and protecting the company's assets.

Endpoint & Device Security (EDR)

Every workstation and server at Northwind runs an Endpoint Detection & Response (EDR) agent. That agent monitors for patterns of suspicious behavior, malware signatures, and any activity that resembles an attack.

Let's imagine another scenario in which suspicious usage patterns are detected on a workstation monitored by an EDR agent. The EDR would look for events that appear suspicious.

• A script creating new user accounts silently
• PowerShell executing from an Excel document
• A process injecting into LSASS to access credentials
• An end user’s laptop that randomly starts to scan the subnet

If there's a compromised workstation that tries to dump LSASS memory to steal hashed credentials, Northwind's correctly configured EDR would detect the LSASS access attempt, kill the process, isolate the machine from the network, and alert the SOC automatically.

On the flip side, if the EDR was incorrectly configured, it wouldn't monitor those protected processes, tamper protection would probably be disabled, events in memory would not get captured, and there would be little to no useful logs generated. In fact, the attack could go on without anyone knowing until significant damage was done.

Good EDR architecture goes past installing the agent. It requires tuning behavioral rules, setting up isolation workflows, and ensuring logs reach the SIEM in a timely manner to prompt action.

Application & API Security

Northwind’s patient portal uses APIs to pull data from the EHR and billing system and to run patient insurance eligibility checks with insurers. Every API call is a potential attack vector if not properly secured.

Let's say one of their older APIs doesn't enforce strict authentication for a metadata endpoint. It wasn’t sensitive at first; it was intended only as supporting information, as metadata is expected to be. But there's one issue: that endpoint reveals internal IDs, version information, and fields that an attacker can use to craft malicious payloads.

When the architecture comes up, the team realizes that this endpoint needs to beef up security because an attacker could scrape the metadata endpoint, learn the structure of the patient query API, build a malformed request, and exploit an API logic flaw to reveal sensitive patient information.

This is the potential flow of an attack that could occur on the metadata endpoint:
Attacker scrapes the metadata endpoint → learns the structure of the patient query API → builds a malformed request → API logic flaw reveals sensitive patient information.

To secure the API, Northwind should enforce authentication, validate input, and restrict exposure. Oftentimes, it seems like the main objective in application security is to secure the code, but it's also in understanding how applications talk to each other and tightening the trust boundaries between them.

Data Security

Northwind Health handles some of the most sensitive and highly regulated data, patient records. Protecting this data means thinking about how it lives in the system, how it moves, and how people actually use it day to day. The environment handles different types of information; structured EHR and billing data, unstructured files like PDFs and patient notes, operational logs and audit trails, and anonymized patient data used for research and analysis.

Now imagine a nurse downloads a report and sends it to her personal email so she can finish up work from home. This report contains PHI. In an insecure environment, this incident would slip through unnoticed. However, in Northwind’s setup, several guardrails stop that from happening.

• DLP rules flag or block anything that looks like outbound PHI
• Downloads are encrypted before they leave the system
• RBAC limits large data downloads to only specific employees
• Download activity is logged, and unusual patterns generate alerts in the SIEM

Good data architecture sets clear boundaries for how sensitive information should be moved, shared, and stored, without making regular tasks impossible for users. It gives employees the room to do their work while still keeping patient data exactly where it belongs.

Monitoring, Logging, and Detection

Northwind’s SIEM pulls logs from the IAM system, VPN, EDR, firewalls, APIs, and databases. This is one of the most critical architectural layers because logs reconstruct what happened during an attack.

If an attacker were to gain access to any part of the environment and there are no logs to guide the security team and tell the story, they are essentially going in blind, attempting to recreate events about which they lack information. You can’t see the entry point, the path taken, the data accessed, or the systems affected.

Let's say an attacker compromises one of Northwind's keys for the GCP service account. Here's how proper logging helps catch this before it becomes a full breach. The IAM logs would show the service account logging in from an unusual location while the network logs record attempts to create new firewall rules. The API logs would reflect repeated failed admin calls from that service account and the EDR logs would tie in workstation anomalies that correlate with those other events.

The role of the SOC here would be to piece it all together to understand the full attack scale before any damage occurs. Security architecture done right ensures every security component in place contributes relevant logging evidence to an incident to create a clear timeline of events for the security team.

Let's Put it All Together

An employee in Northwind Health's Billing department receives a phishing email from an attacker posing insurance agent/representative following up on an overdue claim. The employee, out of concern, hastily opens this attachment without second thought, and just like that, the malware runs.

The upside in this scenario is that the attacker cannot access patient data because IAM restricts this employee's account to billing systems only and there is no privilege escalation path to explore.

In addition, the employee's now-compromised machine is trapped in its isolated network segment and is unable to communicate with clinical servers which is likely the attacker's objective.

The malware is now on the unsuspecting employee's computer and attempts to scan the subnet and access LSASS. The EDR agent isolates the device and sends high-severity alerts to the SOC so they can step in before the threat spreads.

Even with stolen browser cookies, API requests to the patient portal require fresh authentication tokens; therefore, the attacker can’t reuse browser session data.

The DLP policy will either prevent or set off alerts for large outbound file transfers to prevent the attacker from exporting bulk PHI.

Once the suspicious activity has been correctly detected, the alerts will go to the SOC with a clear timeline of events about:

• The email received
• The malicious PDF attachment
• How and when the exploit was executed
• Actions taken by the EDR including isolation
• A series of IAM denial events
• Blocked data transfers

Because Northwind's visibility is strong, the SOC contains the incident quickly and reports it with confidence.

Security architecture is the strategic design of how every system in an environment interacts, protects, and responds. When you walk through a real company’s environment layer by layer, the architecture becomes tangible, and you realize that while each component plays a role, it’s their connection and interaction that make the organization resilient.