Security Principles, Models and Architecture

Introduction

Cybersecurity is not achieved by a single firewall, password policy or security product. It is an architectural property of an organisation’s people, processes, technologies and information flows. Security architecture provides the structure through which risks are reduced: users receive only the access they require, sensitive operations are separated, systems are divided into controlled zones, and trust is continuously evaluated rather than assumed.

This chapter examines the principles and models used to design secure systems. It explains least privilege, need-to-know, separation of duties, secure defaults, defence in depth, segmentation and zero trust. It also introduces trust boundaries, reference monitors and access-control models. Finally, it applies these ideas to on-premises, hybrid and digitally transformed environments.

A useful distinction is between a security principle and a security control. A principle is a design rule, such as least privilege. A control is a specific mechanism that implements the rule, such as role-based access control, network access control or privileged-access management. Good architecture connects principles to controls and then verifies whether the controls achieve their intended outcomes.

Learning objectives

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

• explain major security design principles and their relationships;
• identify trust boundaries and reference monitors in an architecture;
• compare discretionary, mandatory, role-based and attribute-based access control;
• apply defence in depth and segmentation to enterprise environments;
• explain the assumptions and operating practices of zero-trust architecture;
• analyse security architectures for on-premises, hybrid and digital-transformation environments;
• evaluate practical, governance and ethical limitations of security models.

1. Foundational security principles

1.1 Least privilege

Least privilege means that a subject—such as a user, process, service account or device—receives only the permissions needed to perform its authorised task, and no more. Privileges should also be limited in time, scope and resource type.

For example, an application that reads customer records should not automatically be able to delete them. A database administrator may need to manage database structures but not view the contents of sensitive medical records. A help-desk employee may reset a password but should not be able to issue unrestricted administrator credentials.

Least privilege has four dimensions:

1. Minimal functionality: provide only the functions required.
2. Minimal data access: expose only the necessary records or fields.
3. Minimal duration: make elevated access temporary where possible.
4. Minimal authority: restrict actions such as read, write, execute, approve or delete.

Least privilege limits the impact of both accidental mistakes and compromised accounts. It can, however, become difficult to administer if permissions are excessively fragmented. Effective implementation therefore requires role design, access reviews, logging and removal of obsolete permissions.

1.2 Need-to-know

Need-to-know limits access to information based on a demonstrated operational requirement. It is related to least privilege but is not identical. Least privilege concerns what actions a subject may perform; need-to-know concerns which information the subject may receive.

A security analyst may have permission to investigate alerts but need access only to log metadata, not the full content of every employee communication. In a legal department, two teams may have the same job title but be prevented from viewing each other’s confidential matters.

Need-to-know supports confidentiality and data minimisation. It should be implemented through data classification, compartmentalisation, field-level controls and carefully designed workflows.

1.3 Separation of duties

Separation of duties requires a sensitive activity to be divided among two or more people, roles or technical components. The purpose is to prevent one actor from being able to complete an abuse without detection.

For example, one employee may create a supplier record, another may approve a payment, and a third system may release the transaction. In software delivery, developers may write code, an independent reviewer may approve it, and an automated pipeline may deploy only approved changes.

Separation of duties can be:

• Static: conflicting permissions cannot be assigned to the same role or user.
• Dynamic: conflicting duties are permitted at different times but not within the same transaction.
• Technical: independent systems or cryptographic keys are required.

The principle introduces operational cost and can create delays. It should therefore focus on high-impact activities rather than every routine action.

1.4 Secure defaults and fail-safe behaviour

Secure defaults mean that a system begins in the safest reasonable configuration. Examples include denying network access until a rule allows it, disabling unused services, requiring encryption by default and making new cloud storage private unless explicitly shared.

A related idea is fail-safe failure: when a control fails, the system should fail in a manner that protects security. A failed authorisation service should normally deny access rather than grant it. This must be balanced against availability and safety requirements. In a hospital, for example, emergency access may be necessary when an identity service is unavailable. Such access should be narrowly defined, logged and reviewed afterward.

1.5 Defence in depth

Defence in depth uses multiple, partially independent protective layers. A typical sequence may include identity verification, endpoint protection, network segmentation, application authorisation, database controls, encryption, backups and monitoring.

The layers should not all depend on the same assumption. Five controls that rely on one compromised administrator account do not provide five independent barriers. Defence in depth is strongest when controls differ in technology, location and failure mode.

Defence in depth supports both prevention and resilience. If prevention fails, detection, containment, recovery and lessons learned should limit the consequences.

1.6 Segmentation and compartmentalisation

Segmentation divides a system or network into zones with controlled communication paths. Compartmentalisation applies the same idea to data, applications, teams or processes.

Examples include separating user workstations from servers, placing payment systems in a restricted zone, isolating development from production, and separating management interfaces from ordinary user traffic. Segmentation reduces attack propagation and makes monitoring more meaningful.

Segmentation is not achieved merely by creating subnets. Effective segmentation requires explicit policy, authenticated connections where appropriate, restrictions on east-west traffic, and testing of allowed and denied paths.

2. Trust boundaries and reference monitors

2.1 Trust boundaries

A trust boundary is a point where the assumptions about identity, authority, data quality or system control change. Common boundaries occur between a public internet and an internal service, between a user device and a corporate application, between a cloud provider and a customer, and between an application and a database.

A boundary should prompt several questions:

• Who is making the request?
• What evidence supports the claimed identity?
• Which authority decides whether the request is permitted?
• Can the input be trusted, or must it be validated?
• What is logged, and who can alter the log?
• What happens if the boundary control is unavailable?

Data crossing a boundary should be authenticated, authorised, validated and, where appropriate, encrypted. A common design error is to validate a user at the outer boundary and then trust all internal requests. Modern environments contain many internal threats and compromised devices; therefore, internal location alone is weak evidence of trust.

2.2 The reference monitor concept

A reference monitor is an abstract security-enforcement mechanism that mediates every access by a subject to an object. It evaluates the request against policy and either permits or denies it.

A practical reference monitor should have three properties:

• Complete mediation: every relevant access is checked.
• Tamper resistance: the enforcement mechanism cannot be modified by unauthorised users.
• Small, verifiable design: the mechanism is sufficiently simple to analyse and test.

Operating-system kernels, database authorisation layers, API gateways and hardware security modules can implement aspects of a reference monitor. No single component necessarily mediates every access in a modern distributed system, so architects must identify where mediation occurs and whether paths exist around it.

For example, an API gateway may authenticate requests, but an application must still enforce object-level authorisation. Otherwise, a valid user might alter an identifier in a request and retrieve another customer’s record. Authentication at the perimeter is not a substitute for authorisation at the resource.

3. Access-control models

Access control answers three questions: who or what is requesting access, which resource is being requested, and what operation is proposed. A policy decision may be represented conceptually as:

Here, Subject is the requesting entity, Object is the protected resource, Action is the proposed operation, Context includes factors such as time, device and location, and Policy contains the rules. The expression is a conceptual model rather than a numerical formula; it does not prescribe one implementation.

3.1 Discretionary access control

In discretionary access control (DAC), the owner of a resource can decide who may access it. Traditional file permissions and access-control lists often use this model.

DAC is flexible and suitable for collaborative environments, but it can permit uncontrolled redistribution. A user who owns a document may share it with another user, even if the organisation intended stronger information control. DAC also tends to accumulate permissions over time.

3.2 Mandatory access control

Mandatory access control (MAC) applies centrally defined rules based on classifications and clearances. A subject with a particular clearance may access an object only when the policy permits the relationship between the subject’s clearance and the object’s classification.

MAC is useful for military, government and highly regulated environments. It provides stronger central control than DAC but can be complex and less flexible. Classification labels must be accurate, and administrators must manage exceptions carefully.

3.3 Role-based access control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. Typical roles include payroll officer, database operator and security analyst.

RBAC simplifies administration when job responsibilities are stable. It also supports separation of duties by preventing conflicting roles from being assigned together. Its weakness is role explosion: many combinations of department, project, location and task can produce an unmanageable number of roles.

A simplified RBAC relationship is:

The arrows represent assignment relationships, not mathematical operations. A permission may include an operation and resource, such as “read invoices.”

3.4 Attribute-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, object, action and environment. A policy might allow a clinician to view a patient record when the clinician is assigned to the patient, is using an approved device, and is operating during an authorised clinical session.

ABAC provides fine-grained and context-aware decisions. It is well suited to cloud and API environments, but policy complexity, attribute quality and explainability become important operational issues. Incorrect or stale attributes can produce incorrect decisions.

3.5 Rule-based and risk-adaptive control

Rule-based control uses explicit conditions such as “deny access from blocked countries” or “require stronger authentication for administrative actions.” Risk-adaptive systems combine policy with signals such as unusual behaviour, device posture or impossible travel. Such signals should support—not silently replace—clear authorisation policy.

Automated risk decisions must be monitored for error, bias and disproportionate effects. A legitimate traveller or remote worker may be incorrectly classified as risky. High-impact decisions should provide an appeal or human review path.

4. Zero trust architecture

Zero trust is an architectural approach based on the principle that no user, device, application or network location is automatically trusted. Access is granted for a specific resource, action and session based on verified evidence and policy.

Zero trust does not mean that trust is impossible. It means that trust is conditional, limited and continuously evaluated. Important practices include:

• strong identity proofing and authentication;
• device and workload identity;
• least-privilege, resource-level authorisation;
• explicit policy decisions using relevant context;
• encryption in transit and at rest;
• continuous logging, monitoring and response;
• segmentation and reduction of implicit internal trust.

A zero-trust request commonly passes through a policy decision point and a policy enforcement point. The decision point evaluates identity, resource sensitivity, device status, requested action and organisational policy. The enforcement point permits, limits or denies the connection.

Zero trust is not simply “put everything behind a login.” A password-only design may authenticate a user but still fail to assess device compromise, excessive permissions, application-level authorisation or data exposure. Nor does zero trust require replacing every existing system immediately. It is usually implemented incrementally, beginning with high-value assets and critical access paths.

5. Secure architecture across deployment environments

5.1 On-premises environments

An on-premises architecture is operated primarily within facilities controlled by the organisation. Security responsibilities include physical access, networks, servers, operating systems, applications, identities and backups.

A sound design typically separates:

• public-facing services;
• user endpoints;
• application servers;
• databases and sensitive data stores;
• administrative and management networks;
• backup and recovery infrastructure.

Administrative access should use separate privileged accounts, phishing-resistant multifactor authentication where feasible, jump hosts or privileged-access workstations, command logging and time-limited elevation. Legacy systems should be isolated rather than allowed unrestricted access merely because they cannot support modern controls.

5.2 Hybrid environments

Hybrid environments combine on-premises systems with cloud services. Their principal challenge is the interaction of different identity systems, networks, policies, logging capabilities and responsibility boundaries.

Architectural controls include federated identity with strong assurance, carefully scoped synchronisation, private connectivity where appropriate, cloud security groups and network policies, centralised logging, key-management decisions and consistent data classification. A synchronised identity directory can improve usability but also enlarges the blast radius of a compromised account.

The shared-responsibility model must be understood precisely. A cloud provider may secure physical facilities and core infrastructure, while the customer remains responsible for identities, configurations, data, applications and some operating-system controls. Responsibility differs by service model and contract; it should be documented rather than assumed.

5.3 Digital-transformation environments

Digital transformation often introduces mobile access, software-as-a-service, application programming interfaces, containers, microservices, automation and operational technology integration. These environments increase agility but also create more identities, dependencies and trust boundaries.

Secure architecture should include software supply-chain controls, signed builds, dependency management, secrets protection, workload identity, API authorisation, secure-by-design development and continuous configuration assessment. In microservice systems, service-to-service authentication and authorisation are required; network reachability alone should not imply permission.

Automation must be governed. Infrastructure-as-code can consistently deploy secure configurations, but an insecure template can reproduce weakness at scale. Change review, testing, version control and protected deployment pipelines are therefore security controls.

6. Applying the principles: an illustrative case

Background

The following is an illustrative case. A regional healthcare organisation operates hospitals on premises, uses a cloud-based appointment platform and allows clinicians to work from managed laptops and mobile devices. Patient records are stored in a central clinical system, while laboratories and imaging systems are connected through internal networks.

Problem

An internal review finds excessive access permissions, shared administrator accounts, flat network connectivity and inconsistent logging. A stolen clinician password could potentially be used from an unmanaged device to access many patient records. Developers also have direct access to production databases for troubleshooting.

Analysis

The organisation has weak separation between identity, device and resource trust. Internal network location is treated as proof of legitimacy. The shared accounts reduce accountability, and direct developer access violates least privilege and separation of duties. The flat network increases the consequences of a compromised workstation.

Approach and solution

The organisation adopts the following architecture:

1. Individual accounts replace shared administrative accounts; privileged actions require multifactor authentication and time-limited elevation.
2. RBAC provides baseline permissions, while ABAC adds patient assignment, device status and session context.
3. Developers receive masked test data and controlled, logged production support access rather than standing database privileges.
4. Clinical, laboratory, imaging, user and management systems are segmented. Inter-zone communication is explicitly allowed by service and direction.
5. The appointment platform uses federated identity and narrowly scoped API tokens. Tokens identify the calling service and permitted operations rather than granting broad database access.
6. A central monitoring service collects authentication, authorisation, administrative and data-access events. High-risk access triggers investigation.
7. Emergency access is available for clinical necessity, but it is time-limited, recorded and reviewed by the privacy and clinical governance teams.
8. Backups are protected from ordinary administrative accounts and tested through recovery exercises.

Outcome

The new design reduces standing privilege, improves attribution and limits lateral movement. It does not eliminate risk: a compromised authorised account may still cause harm, attributes may be incorrect, and clinical availability must be protected. The organisation therefore supplements preventive controls with monitoring, incident response, recovery and periodic access recertification.

Learning points

The case demonstrates that secure architecture is a system of mutually supporting decisions. Zero trust, segmentation and least privilege are not isolated products. They require accurate identities, reliable device information, resource-level authorisation, usable emergency processes and governance that reviews whether controls work in practice.

7. Limitations, governance and professional practice

Security principles can conflict. Strict least privilege may impede emergency response. Extensive logging can support accountability but expose personal information. Segmentation can reduce attack spread but increase complexity and operational cost. Strong authentication can improve security while creating accessibility challenges for users with disabilities or limited connectivity.

Governance should define ownership, acceptable use, exception processes, retention periods and review frequency. Access reviews should examine whether permissions are still necessary, not merely whether a manager clicked an approval button. Security architecture should also align with privacy and data-protection obligations, contractual requirements and sector regulation.

Architects should avoid security theatre: controls that generate reassuring evidence without reducing meaningful risk. A compliance checklist cannot replace threat modelling, testing and incident learning. Security decisions should be proportionate to asset value, threat likelihood, potential harm and operational requirements.

Artificial intelligence may assist with anomaly detection, policy analysis and configuration review, but automated recommendations can be inaccurate or biased. AI systems themselves require access control, data protection, model governance, supply-chain assurance and human oversight. An AI-generated access decision should be explainable enough for administrators to investigate and for affected individuals to challenge where appropriate.

8. Best-practice design process

A practical design process is:

1. Identify important assets, business processes and safety requirements.
2. Map data flows, identities, dependencies and trust boundaries.
3. Classify information and define permitted uses.
4. Select access-control models appropriate to the operating context.
5. Apply least privilege, need-to-know and separation of duties.
6. Design segmentation and defence-in-depth layers.
7. Define secure defaults, failure behaviour and emergency access.
8. Implement logging, monitoring, alerting and recovery capabilities.
9. Test controls through configuration review, access recertification, vulnerability assessment and realistic exercises.
10. Review the architecture after incidents, major changes and emerging threats.

A secure architecture is therefore an evolving practice rather than a one-time diagram. Its quality depends on whether policy is enforced at the correct resource, whether exceptions are visible, and whether the organisation can detect and recover when assumptions fail.

Chapter Summary

Security architecture translates principles into enforceable and reviewable arrangements. Least privilege limits authority; need-to-know limits information exposure; separation of duties reduces unilateral abuse; secure defaults and fail-safe behaviour reduce avoidable failure; defence in depth combines independent layers; and segmentation limits attack propagation.

Trust boundaries identify changes in assumptions and require authentication, authorisation, validation and monitoring. A reference monitor mediates access and should provide complete mediation, tamper resistance and a design that can be verified. DAC, MAC, RBAC and ABAC offer different balances of flexibility, central control and contextual precision.

Zero trust rejects implicit trust based on network location. It uses explicit, resource-specific and continuously evaluated decisions. On-premises, hybrid and digitally transformed environments require different implementations, but all benefit from strong identity, least privilege, segmentation, logging, secure automation and tested recovery. Effective security also requires governance, privacy protection, accessibility, human oversight and continual evaluation.

Key Terms

Least privilege: Granting only the minimum authority required for an authorised task.

Need-to-know: Restricting information access to what a person or process must know to perform a legitimate function.

Separation of duties: Dividing a sensitive activity among independent roles or components.

Secure default: A starting configuration that protects security unless access is explicitly enabled.

Fail-safe failure: A failure mode that preserves security, usually by denying access, subject to safety and availability needs.

Defence in depth: The use of multiple complementary security layers.

Segmentation: Dividing systems or networks into controlled zones.

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

Reference monitor: A mechanism that mediates access between subjects and objects.

Complete mediation: Checking every relevant access request.

Discretionary access control: Access control in which resource owners can grant permissions.

Mandatory access control: Centralised access control based on classifications and clearances.

Role-based access control: Assigning permissions through organisational roles.

Attribute-based access control: Making decisions using subject, object, action and environmental attributes.

Zero trust: An architecture that grants no implicit trust and continually evaluates access.

Policy decision point: A component that evaluates policy and determines whether access is allowed.

Policy enforcement point: A component that applies the decision by permitting, restricting or denying access.

Shared responsibility: The division of security obligations between a service provider and its customer.

Privilege escalation: Gaining greater authority than originally authorised.

Lateral movement: An attacker’s movement between systems after obtaining an initial foothold.

Review Questions

Short Answer Questions

1. What is the difference between least privilege and need-to-know?
2. State the three essential properties of a reference monitor.
3. Why does network location alone provide weak evidence of trust?
4. What is role explosion in RBAC?
5. Give two examples of security controls used in a hybrid environment.

Long Answer Questions

1. Explain how least privilege, separation of duties and defence in depth work together in an enterprise architecture.
2. Compare DAC, MAC, RBAC and ABAC, including a suitable use case and limitation for each.
3. Explain the meaning of zero trust and distinguish it from simply requiring users to log in.
4. Discuss the major trust boundaries in a hybrid cloud architecture and the controls appropriate to them.
5. Evaluate the benefits and limitations of segmentation in a digitally transformed organisation.

Analytical / Application Questions

1. A university gives all database administrators unrestricted access to student records and allows developers to troubleshoot production systems using shared accounts. Analyse the risks and propose a redesigned access-control and accountability model.
2. Design a segmented architecture for an organisation containing public web services, employee devices, application servers, sensitive databases and administrative systems. Explain the permitted communication paths and the defence-in-depth controls.
3. A legitimate employee is repeatedly blocked by an automated risk engine because of international travel. Analyse the security, privacy and fairness issues, and propose a zero-trust approach that preserves both protection and a meaningful review process.

Multiple Choice Questions with Answers

Question 1

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

A. Least privilege

B. Defence in depth

C. Mandatory access control

D. Segmentation

Correct Answer: A. Least privilege

Question 2

Which property of a reference monitor means that every relevant access must be checked?

A. Tamper resistance

B. Complete mediation

C. Role assignment

D. Data minimisation

Correct Answer: B. Complete mediation

Question 3

Which access-control model assigns permissions through organisational roles?

A. DAC

B. MAC

C. RBAC

D. ABAC

Correct Answer: C. RBAC

Question 4

What is a principal characteristic of zero-trust architecture?

A. Internal network traffic is automatically trusted

B. All access is permanently denied

C. Trust is granted based only on IP address

D. Access is explicitly evaluated for a resource and context

Correct Answer: D. Access is explicitly evaluated for a resource and context

Question 5

Which practice best demonstrates separation of duties?

A. One administrator creates and approves a payment

B. A developer writes code and independently reviewed changes are deployed

C. All employees share one privileged account

D. A user receives access to every department’s files

Correct Answer: B. A developer writes code and independently reviewed changes are deployed

Question 6

What is a primary security benefit of network segmentation?

A. It eliminates the need for authentication

B. It prevents every possible intrusion

C. It limits attack propagation between zones

D. It guarantees that data is correctly classified

Correct Answer: C. It limits attack propagation between zones

Question 7

In ABAC, which factor may contribute to an access decision?

A. Only the user’s job title

B. Only the object owner’s preference

C. Subject, object, action and environmental attributes

D. Only the network cable type

Correct Answer: C. Subject, object, action and environmental attributes

Question 8

Which is the most secure default for a newly created cloud storage resource?

A. Public access enabled

B. Access denied until explicitly authorised

C. Access granted to all authenticated users

D. Access granted to the creator’s entire department

Correct Answer: B. Access denied until explicitly authorised

Question 9

Why are shared administrator accounts a security weakness?

A. They always use encryption

B. They prevent privilege escalation

C. They reduce individual accountability

D. They automatically enforce need-to-know

Correct Answer: C. They reduce individual accountability

Question 10

In a hybrid environment, which statement best describes shared responsibility?

A. The cloud provider is responsible for every customer configuration

B. The customer is responsible for the provider’s physical facilities

C. Security duties are divided according to the service model and agreement

D. Neither party has responsibility for identity management

Correct Answer: C. Security duties are divided according to the service model and agreement