Security Architecture: Answer These Three Core Questions Before Picking Tools

1. What to protect

Core assets of an internet‑hospital include:

Patient accounts
Doctor identities
Medical records and prescriptions
Insurance and payment data
Service APIs
Keys, logs and backups
Ability to keep the clinical service running

These assets face three fundamental security problems that map directly to the CIA goals:

Confidentiality – unauthorized parties must not see the data.

Integrity – data must not be altered without authorization and any change must be traceable.

Availability – authorized users must be able to obtain the service when needed.

Typical controls:

Confidentiality: authentication, access control, least‑privilege, encryption, data masking.

Integrity: checksums, digital signatures, permission checks, database constraints, tamper‑evident logs.

Availability: rate limiting, clustering, failover, backup‑restore, disaster‑recovery drills.

2. Who can do what (AAA)

Access to a medical‑record room requires three steps – authentication, authorization, and accounting (AAA).

Authentication proves identity. Examples:

Patient: phone number + SMS code
Doctor: username + password + hardware token
Operator: password + token on a managed device

Authorization decides what the authenticated subject may do. Examples:

Patient can view only their own records
Doctor can view records needed for treatment
Pharmacist can review prescriptions but cannot modify diagnosis
Operator can restart services but cannot read plaintext records

Accounting records who accessed what, when, from where, and whether the operation succeeded, enabling later investigation.

3. Beyond AAA – Least privilege and Separation of duties

Least privilege means granting only the permissions required for the current task. Example – a SMS service needs to read phone numbers, read templates, and call the provider; it must not be able to modify orders, read full medical records, delete audit logs, or access DB‑admin accounts.

Separation of duties splits high‑risk processes among different roles. Example – a refund workflow:

Customer‑service initiates the refund
Supervisor approves the refund
Finance executes the payment
System records an audit log

If a single person could perform all steps, a compromised account could bypass all controls.

4. When a defense fails – security zones, DMZ, WAF, MFA

Security zones (or domains) divide the system by trust level, business responsibility, and data sensitivity, and enforce access rules between zones.

DMZ – a buffer zone between the Internet and internal networks.

WAF – a Web Application Firewall that inspects HTTP/HTTPS requests for attacks such as SQL injection, XSS, malicious scanning, abnormal request rates, or dangerous paths.

MFA – Multi‑Factor Authentication that combines at least two different factor types (something you know, something you have, something you are).

Typical request flow:

External user → WAF (malicious request check) → DMZ (buffer) → Application services → Data zone

Operations staff use MFA plus a bastion host to reach the operations zone.

5. Defense in depth

Deploying a single firewall is insufficient because attacks can arise from compromised accounts, infected internal devices, vulnerable applications, misconfigurations, or insider abuse.

Depth‑in‑defense adds complementary controls at multiple layers so that if one line fails, others still block, limit, or detect the attack. Example for a stolen doctor password:

1. MFA blocks password‑only login
2. Risk engine flags abnormal device/location
3. Authorization limits record scope
4. Rate‑limiting throttles bulk queries
5. Sensitive fields are masked
6. Audit system flags abnormal access
7. Response workflow freezes account and revokes tokens

6. Zero‑trust for the internal network

Traditional models treat the external network as untrusted and the internal network as trusted, but compromised internal accounts or services can spread laterally.

Zero‑trust requires verifying identity and permissions for every request, regardless of network location, and granting only the minimal permissions needed.

For users, verify:

User identity
Device health
Login location
Target resource
Current risk score

For internal services, verify both ends of communication, authorize per service and API, limit token scope and lifetime, and log all calls.

7. Post‑attack lifecycle (WPDRRC)

The six‑step lifecycle covers pre‑alert, protection, detection, response, recovery, and retaliation.

Pre‑alert – monitor vulnerability notices, weak passwords, risky configurations, abnormal trends.

Protection – authentication, authorization, firewalls/WAF, patching, encryption, network segmentation.

Detection – watch for anomalous logins, massive record queries, DB anomalies, host/application alerts.

Response – freeze accounts, revoke tokens, isolate devices, block malicious sources, trigger emergency procedures.

Recovery – restore from trusted backups, redeploy clean environments, verify data integrity, gradually bring services back.

Retaliation – perform attack forensics, preserve evidence, cooperate with regulators or law‑enforcement, improve defenses based on the attack path.

8. Encryption is not sufficient alone

Data passes through creation, transmission, storage, use, sharing, backup, and destruction – each stage has distinct risks.

Protection measures:

Transmission – TLS/mTLS to prevent eavesdropping and tampering.

Storage – encrypt databases, sensitive fields, and backups; restrict access.

Use/Display – data masking, need‑to‑know display, export approval, watermarks, least‑privilege access.

Key Management – generate, store, and rotate keys separately from ciphertext; control who can use them; audit key usage.

Four related technologies must not be confused:

Encryption – prevents others from reading the content.

Hash (digest) – detects whether content has been altered.

Digital signature – verifies source, integrity and provides non‑repudiation.

Digital certificate – trusted authority proves which public key belongs to whom.

9. Putting the internet‑hospital case together – practical steps

Six practical steps:

Identify assets: accounts, records, prescriptions, payment data, APIs, keys, logs, backups.

Divide zones: Internet zone, DMZ, application zone, data zone, operations‑management zone.

Control access: establish identities for patients, doctors, pharmacists, admins; enforce MFA for high‑risk actions; authorize per role, data ownership, and clinical relationship; apply least‑privilege and separation of duties; audit all sensitive actions.

Protect data: TLS/mTLS for transport; encrypt sensitive data and backups; mask data when displayed; keep keys separate from business data; use hashes or signatures for critical prescriptions.

Build layered defenses: perimeter traffic cleaning and access control; host patching and hardening; application parameter validation, authorization, rate limiting; strict data‑zone isolation; operations via MFA and bastion host.

Detect, respond, recover: centralize logs and detect anomalies; on attack freeze accounts, revoke tokens, isolate hosts; restore from trusted backups; regularly run privilege‑escalation tests, penetration tests, and recovery drills.