Security Architecture and Control Models

Introduction

Cybersecurity is not achieved by installing a single security product. It is achieved by designing an environment in which risks are reduced through mutually reinforcing policies, technologies, processes, and people. Security architecture provides the structure for this design. It identifies important assets, trust relationships, attack surfaces, control points, and recovery capabilities.

A security control is a safeguard intended to prevent, detect, respond to, or recover from an undesirable event. Examples include access-control lists, encryption, security awareness training, audit logs, firewalls, backups, incident-response procedures, and separation of duties. Controls are most effective when they are selected as part of an architecture rather than deployed in isolation.

This chapter develops six foundational ideas: defence in depth, least privilege, separation of duties, zero trust, secure defaults, and the classification of controls as preventive, detective, or corrective. These principles are applicable to networks, cloud systems, applications, databases, physical facilities, and organisational processes.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the purpose of security architecture and trust boundaries;
• apply defence in depth to a basic information system;
• distinguish least privilege from separation of duties;
• explain the assumptions and practical operation of zero trust;
• design secure defaults for users, systems, and applications;
• classify controls as preventive, detective, or corrective;
• select controls for common cybersecurity scenarios; and
• evaluate the limitations, governance implications, and trade-offs of security controls.

1. Security Architecture as a System of Protection

Security architecture is the organised design of security capabilities across an organisation. It connects business objectives and information risks to controls. A useful architecture answers four questions:

1. What must be protected?
2. From whom or what must it be protected?
3. Which controls reduce the relevant risks?
4. How will the organisation know whether the controls work?

The architecture should consider confidentiality, integrity, and availability, commonly called the CIA triad. Confidentiality limits information disclosure; integrity protects information and systems from unauthorised or improper modification; and availability supports timely and reliable access.

Assets, threats, vulnerabilities, and risk

An asset is something of value, such as customer records, credentials, source code, operational technology, or an essential service. A threat is a circumstance or actor capable of causing harm. A vulnerability is a weakness that may be exploited. Risk arises when a threat can exploit a vulnerability and produce an adverse impact.

A simple qualitative model is:

Likelihood expresses how probable the event is, while impact expresses the severity of its consequences. This is a planning model, not a precise universal law. Organisations may use numerical or qualitative scales, but the scales must be defined consistently. Controls reduce risk by lowering likelihood, limiting impact, or improving the speed of detection and recovery.

Trust boundaries

A trust boundary is a point at which assumptions about identity, authority, data handling, or system behaviour change. Examples include:

• the boundary between the public internet and an internal network;
• the boundary between a web server and a database;
• the boundary between an employee device and a cloud service; and
• the boundary between a development environment and production.

A common architectural error is treating an internal network as automatically trustworthy. Once an attacker compromises one device, unrestricted internal trust can permit lateral movement. Modern architecture therefore treats trust as a property to be established and continually evaluated, not a location-based privilege.

Figure: A layered security architecture in which preventive and detective capabilities operate across multiple system layers.

2. Defence in Depth

Defence in depth uses multiple, independent or partially independent safeguards so that failure of one safeguard does not expose the entire system. It is analogous to layered protection in physical security: a locked door, an alarm, a guard, and a response procedure provide stronger protection together than any one measure alone.

A basic online service might use the following layers:

The layers should not be merely numerous; they should be appropriate and coordinated. Ten controls that depend on the same administrator account or the same unpatched platform may represent less diversity than their number suggests. Architectural diversity is valuable because it reduces common-mode failure, in which one fault defeats several controls simultaneously.

Defence in depth does not mean preventing every incident. It aims to delay attacks, limit their scope, increase the chance of detection, and support recovery. It also creates trade-offs. Additional controls may increase cost, latency, administrative effort, and the risk of configuration errors. Controls should therefore be selected through risk assessment and tested for effectiveness.

3. Least Privilege

Least privilege means that a subject receives only the permissions necessary to perform an authorised task, for only as long as necessary. A subject may be a user, process, service account, application, or device. Least privilege applies to both what a subject can do and what resources it can access.

Important implementation practices include:

• use role-based access control where job responsibilities are stable;
• use attribute-based conditions where access depends on context such as device health, location, or data classification;
• separate ordinary and administrative accounts;
• grant time-limited or just-in-time administrative access;
• remove dormant accounts promptly;
• review permissions periodically; and
• ensure service accounts have narrowly defined permissions and securely managed credentials.

Least privilege is often confused with denying all access. That approach can make work impossible and encourage unsafe workarounds. The objective is necessary access, not minimal access in the abstract. Permissions should be traceable to a legitimate business or technical requirement.

Example

A help-desk employee may need to reset a user password but should not be able to export the employee database. A backup service may need to write to a backup repository but should not be able to alter production payroll records. A web application may need to read selected product data but should not connect to the database as an unrestricted administrator.

Least privilege reduces the consequences of stolen credentials and compromised applications. It does not eliminate risk: an attacker may compromise a privileged account, exploit a permitted function, or persuade an authorised user to misuse access. Consequently, least privilege must be combined with authentication, monitoring, approval, and response controls.

4. Separation of Duties

Separation of duties distributes a sensitive process among two or more people, roles, or technical components so that one individual cannot complete the entire high-risk action alone. It is primarily a fraud- and error-reduction principle, although it can also limit malicious activity.

For example, one employee may create a supplier record, another may approve a payment, and a third system may release the payment. In software development, a developer may submit code, an independent reviewer may approve it, and an automated pipeline may deploy it after required checks.

Separation of duties can be:

• static, where conflicting permissions are never assigned to the same role;
• dynamic, where a second approval is required at the time of an action; or
• technical, where system components enforce independent approval or dual control.

Least privilege and separation of duties are related but different. Least privilege asks, “What permissions does this subject need?” Separation of duties asks, “Should this sensitive process require more than one authorised party?” A person may have only the permissions needed for a role and still hold too many conflicting roles.

The principle must be designed carefully. Excessive approvals create delays and may encourage users to share accounts or bypass processes. Emergency access should be possible through a documented, time-limited, monitored procedure rather than through permanent exceptions.

5. Zero Trust

Zero trust is a security approach based on the principle that no user, device, application, or network location is automatically trusted. Access should be explicitly requested, authenticated, authorised, and continuously evaluated according to risk and policy.

Zero trust does not mean that trust is impossible. It means that trust is conditional and should be established for a specific interaction. A practical decision may consider:

• verified identity;
• device security posture;
• requested resource and operation;
• data sensitivity;
• time and location;
• behavioural or threat signals; and
• the strength of authentication.

A simplified access-decision model is:

Here, f represents an organisation's policy decision function. The expression is conceptual rather than a universal numerical equation. It indicates that access should depend on multiple attributes rather than network location alone.

Core zero-trust practices include strong identity management, MFA, device and endpoint assessment, micro-segmentation, application-level authorisation, encrypted communications, continuous logging, and rapid revocation. Zero trust is therefore an architectural programme, not a single product.

Zero trust scenario

An employee working from home requests access to a finance application. The organisation verifies the user's identity with MFA, checks that the managed laptop is encrypted and updated, evaluates the sensitivity of the requested function, grants only the required role, records the session, and re-evaluates access if the device becomes non-compliant. The fact that the request originates from the corporate VPN does not by itself establish trust.

Zero trust has limitations. Identity data may be incorrect, device checks may be incomplete, policy engines may be misconfigured, and continuous evaluation can affect usability. Organisations should adopt it incrementally, beginning with critical applications and high-value identities, while maintaining clear governance and fallback procedures.

6. Secure Defaults and Secure by Design

Secure defaults mean that a system initially operates in the safer configuration and requires a deliberate, authorised action to weaken protection. Examples include denying inbound network connections unless required, requiring MFA for privileged accounts, disabling unused services, making data sharing private by default, and recording security-relevant events.

Secure defaults are important because users and administrators often retain initial settings. They also reduce the burden on people who cannot reasonably understand every security implication. Related practices include:

• fail-safe behaviour, such as denying access when authorisation cannot be verified;
• minimal installation, in which unnecessary components are omitted;
• secure configuration baselines;
• safe error messages that do not disclose sensitive details;
• secure password and session policies; and
• privacy-protective defaults.

A secure default must still support availability and legitimate operations. For example, denying all network communication may be secure in a narrow sense but unusable for a business service. Defaults should be tested, documented, version-controlled, and reviewed when the system or threat environment changes.

Secure by design extends the idea across the development lifecycle. Security requirements are identified before implementation, threats are considered during design, code is reviewed and tested, dependencies are managed, and secure update mechanisms are provided. Security should not be treated solely as a final inspection activity.

7. Preventive, Detective, and Corrective Controls

Controls can be classified by their primary function. Some controls may perform more than one function, but classification helps analysts identify gaps.

Preventive controls act before or during an attempted violation. Detective controls provide visibility; without them, an organisation may not know that a preventive control failed. Corrective controls limit damage and restore an acceptable state. A mature architecture normally combines all three.

Controls may also be administrative, technical, or physical. A policy is administrative; an access-control system is technical; a locked server room is physical. These classifications are different dimensions. For example, a technical control may be preventive, detective, or corrective.

Control selection process

A practical selection process is:

1. identify the asset and business requirement;
2. identify credible threats and vulnerabilities;
3. determine likely consequences;
4. select preventive controls to reduce exposure;
5. select detective controls to expose failures or attacks;
6. select corrective controls for containment and recovery;
7. assign ownership and measurable requirements; and
8. test, monitor, and improve the controls.

Control effectiveness is not established merely because a control exists. Evidence may include access-review records, configuration reports, alert investigations, penetration-test results, recovery exercises, and audit findings.

8. Applying the Models to Common Scenarios

Scenario A: Ransomware risk in a college

A college stores student records on a central file service. Staff use laptops, some of which connect from home. A ransomware infection on one laptop could encrypt shared files and disrupt teaching administration.

A defence-in-depth response would include MFA, endpoint protection, timely patching, restricted file-share permissions, network segmentation, offline or immutable backups, central logging, and an incident-response plan. Least privilege would prevent ordinary staff from changing backup repositories. Separation of duties would require different personnel to approve and execute restoration of critical records. Zero trust would require identity and device evaluation rather than relying solely on a campus network address. Secure defaults would disable unnecessary services and prevent broad file sharing.

Preventive controls include patching, application control, and restricted write permissions. Detective controls include endpoint alerts, unusual file-change monitoring, and centralised logs. Corrective controls include isolating infected devices, disabling compromised accounts, rebuilding systems, and restoring tested backups.

Scenario B: Online payment application

An online retailer processes payments through a web application and stores order information in a database. The architecture should place the public-facing application behind filtering and rate-limiting controls, isolate the database from direct internet access, use an application account with only required database permissions, and protect sensitive data in transit and at rest. Code review, input validation, vulnerability testing, logging, and alerting provide additional layers.

Separation of duties can require independent approval for production deployment and restrict database administrators from approving their own access requests. Corrective procedures should address exposed credentials, vulnerable dependencies, fraudulent transactions, and restoration after a destructive incident.

9. Detailed Illustrative Case: Regional Health Clinic

Background

This illustrative case concerns a regional health clinic that uses a cloud-based patient-record system, internet-connected diagnostic devices, and a small internal IT team. Clinicians require rapid access, while privacy law and professional duties require protection of patient information.

Problem

The clinic discovers that several employees share a general account for a diagnostic device. A former contractor still has an active remote-access account, backups have not been tested for a year, and the patient-record application trusts any device connected through the clinic's network. These conditions create risks of unauthorised disclosure, ransomware, and poor accountability.

Analysis

The shared account prevents reliable attribution and violates least privilege. The former contractor account represents an identity lifecycle failure. The untested backups weaken corrective capability. Network-based trust conflicts with zero-trust principles. The risks are not solved by purchasing a new firewall because the weaknesses involve identity, process, configuration, monitoring, and recovery.

Approach and solution

The clinic adopts the following plan:

1. Every worker receives an individual identity with MFA, and contractor accounts have explicit expiry dates.
2. Clinicians receive role-based access; administrative staff cannot view clinical notes unless their duties require it.
3. Diagnostic-device permissions are separated from patient-record administration.
4. Privileged actions require approval and are recorded; emergency access is time-limited and reviewed.
5. Devices are inventoried, patched, encrypted, and assessed before access to the cloud application.
6. Network segmentation limits communication between clinical devices, user workstations, guest systems, and management services.
7. Backups are protected from ordinary production credentials and tested through scheduled restoration exercises.
8. Logs from identity, endpoint, cloud, and network systems are reviewed for high-risk events.
9. Staff receive training on phishing, privacy, reporting, and safe handling of patient information.

Outcome

The clinic can now attribute access to named individuals, reduce unnecessary permissions, detect suspicious sign-ins, and restore selected records from verified backups. The controls do not guarantee that no breach will occur. They reduce the probability and impact of compromise and improve the clinic's ability to respond lawfully and safely.

Learning points

The case demonstrates that security architecture is socio-technical. Identity controls require governance; technical controls require correct configuration; and recovery controls require testing. It also demonstrates that least privilege, separation of duties, zero trust, and defence in depth reinforce one another rather than operate as isolated checklists.

10. Governance, Ethics, and Professional Practice

Security controls affect people. Monitoring may protect systems but can also create privacy concerns if it collects excessive personal information or is used for unrelated employee surveillance. Organisations should define a legitimate purpose, limit collection, protect logs, restrict access to monitoring data, and retain it only as long as justified by policy and law.

Access decisions should be explainable enough for administrators and affected users to understand the governing policy. Automated risk scoring can produce false positives or unfairly restrict users. Human review and an appeal or support process are important for high-impact decisions.

Professional practice also requires accountability. Organisations should identify control owners, document exceptions, preserve evidence, test recovery, and report incidents according to applicable contractual and legal requirements. Compliance is not identical to security: a compliant control may be poorly implemented, while a useful security measure may require additional legal or privacy review.

11. Contemporary Developments and Limitations

Cloud services, mobile work, software supply chains, application programming interfaces, and operational technology have expanded the number of trust relationships. Identity-centric access, infrastructure as code, continuous integration security checks, software bills of materials, and managed detection services are increasingly used to address these conditions.

Artificial intelligence can assist with alert triage, anomaly detection, vulnerability prioritisation, and incident investigation. However, AI systems can generate false positives, inherit biased data, expose sensitive information, or be manipulated by adversarial inputs. AI should support—not replace—defined authority, human oversight, evidence preservation, and tested response procedures.

No model is complete. Defence in depth can become expensive complexity; least privilege can impede work if roles are poorly designed; separation of duties can create operational delays; zero trust can become a marketing label without measurable policy enforcement; and secure defaults can be weakened by undocumented exceptions. Continuous assessment is therefore essential.

Best-Practice Checklist

A diploma-level practitioner should be able to verify that:

• critical assets and trust boundaries are documented;
• access is based on verified identity, role, resource, and context;
• privileged access is separate, limited, monitored, and reviewed;
• sensitive processes have independent approval where appropriate;
• systems begin in a secure configuration;
• preventive, detective, and corrective controls are all present;
• logs are useful, protected, and reviewed;
• backups are isolated and restoration is tested;
• exceptions have owners, expiry dates, and compensating controls; and
• controls are evaluated against evidence rather than assumed effective.

Chapter Summary

Security architecture organises people, processes, technologies, and governance to protect assets and manage risk. Defence in depth uses multiple complementary layers so that a failed control does not expose the whole system. Least privilege limits each subject to the access required for an authorised task, while separation of duties divides sensitive responsibilities to reduce fraud, error, and abuse.

Zero trust rejects automatic trust based on network location and requires access decisions based on identity, device, resource, action, context, and policy. Secure defaults make the safer configuration the starting point and reduce dependence on user expertise. Preventive controls reduce the chance of an incident, detective controls reveal events, and corrective controls contain damage and restore operations.

Effective application requires risk assessment, clear ownership, testing, monitoring, privacy protection, and continuous improvement. No individual principle is sufficient; the strongest architectures combine them in a proportionate and evidence-based manner.

Key Terms

Asset: A resource of value that requires protection.

Control: A safeguard that reduces risk or supports detection, response, or recovery.

Corrective control: A control that contains, remediates, or restores after an event.

Defence in depth: Use of multiple complementary security layers.

Detective control: A control that identifies or reveals an event.

Least privilege: Granting only the access necessary for an authorised task.

Multi-factor authentication: Authentication using two or more independent factor types.

Preventive control: A control intended to stop or reduce the likelihood of an unwanted event.

Risk: The potential for harm arising from threats, vulnerabilities, likelihood, and impact.

Secure default: An initial configuration that favours protection and requires deliberate weakening.

Security architecture: The structured design of security capabilities across an environment.

Separation of duties: Distribution of sensitive responsibilities among independent parties or components.

Threat: An actor or circumstance capable of causing harm.

Trust boundary: A point where assumptions about authority, identity, or behaviour change.

Vulnerability: A weakness that may be exploited.

Zero trust: An approach that requires explicit, contextual, and continually evaluated access decisions.

Review Questions

5 Short Answer Questions

1. What is the purpose of a trust boundary?
2. Distinguish least privilege from separation of duties.
3. Give two examples of secure defaults.
4. What is the primary purpose of a detective control?
5. Why should backups be tested rather than merely created?

5 Long Answer Questions

1. Explain how defence in depth reduces the consequences of a compromised user account.
2. Describe the principal components of a zero-trust access decision.
3. Compare preventive, detective, and corrective controls using a ransomware example.
4. Explain how excessive permissions and shared accounts affect accountability and risk.
5. Discuss the governance and privacy issues associated with security monitoring.

3 Analytical / Application Questions

1. A small business allows all employees to access a shared drive containing payroll data. Propose a revised architecture using least privilege, separation of duties, MFA, monitoring, and recovery controls.
2. A developer can write code, approve the code, deploy it to production, and alter production logs. Identify the architectural weaknesses and design a control model that addresses them.
3. A remote employee's device passes authentication but has missing security updates and unusual sign-in behaviour. Using zero-trust principles, explain what access decision should be made and what evidence should be recorded.

Multiple Choice Questions with Answers

Question 1

Which principle requires a user or process to receive only the permissions necessary for its authorised task?

A. Defence in depth

B. Least privilege

C. Separation of duties

D. Secure default

Correct Answer: B. Least privilege

Question 2

Which control is primarily detective?

A. Multi-factor authentication

B. Network segmentation

C. Centralised audit-log alerting

D. Offline backup restoration

Correct Answer: C. Centralised audit-log alerting

Question 3

What is the main purpose of separation of duties?

A. To make every user a system administrator

B. To eliminate the need for authentication

C. To ensure one person can complete sensitive actions quickly

D. To prevent one person or role from controlling an entire sensitive process

Correct Answer: D. To prevent one person or role from controlling an entire sensitive process

Question 4

Which statement best represents zero trust?

A. Internal network users are automatically trusted

B. Access is explicitly and contextually evaluated rather than assumed

C. Only physical security controls are required

D. All access is permanently denied

Correct Answer: B. Access is explicitly and contextually evaluated rather than assumed

Question 5

Which is the best example of a secure default?

A. All file shares are public until users restrict them

B. Unused network services are enabled for convenience

C. Inbound connections are denied unless a documented need exists

D. Privileged accounts do not require MFA

Correct Answer: C. Inbound connections are denied unless a documented need exists

Question 6

A tested backup used to restore systems after ransomware is primarily what type of control?

A. Corrective

B. Preventive

C. Detective

D. Deterrent only

Correct Answer: A. Corrective

Question 7

Which design best demonstrates defence in depth for a web application?

A. One firewall with no logging or backups

B. A shared administrator account and a public database

C. MFA, network segmentation, secure coding, logging, and tested backups

D. A policy document without technical enforcement

Correct Answer: C. MFA, network segmentation, secure coding, logging, and tested backups

Question 8

A help-desk worker can reset passwords but cannot export the employee database. This most directly illustrates:

A. Least privilege

B. Zero trust only

C. Corrective control

D. Physical segregation

Correct Answer: A. Least privilege

Question 9

Which situation most clearly violates separation of duties?

A. A user has read-only access to a report

B. A developer submits code and an independent reviewer approves it

C. One employee creates, approves, and releases a large payment

D. A security analyst reviews authentication logs

Correct Answer: C. One employee creates, approves, and releases a large payment

Question 10

In a risk model expressed as Risk ≈ Likelihood × Impact, what does impact represent?

A. The number of passwords in the organisation

B. The severity of consequences if the event occurs

C. The time required to install a control

D. The identity of the attacker

Correct Answer: B. The severity of consequences if the event occurs