Security Principles, Models and Architecture

Introduction

Cybersecurity is not achieved by installing a single product. It is achieved by designing systems so that users, processes, devices, applications, networks and data are protected even when some controls fail. Security principles provide the reasoning rules for this design. Security models provide formal or semi-formal ways to express those rules. Security architectures organize controls into a coherent system.

This chapter examines least privilege, separation of duties, defense in depth, secure defaults, fail-safe design and trust boundaries. It then compares major access-control models and introduces reference architectures, zero trust and security-by-design. These ideas apply to cloud services, enterprise networks, mobile applications, databases and software development.

Learning Objectives

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

• explain core security design principles and apply them to practical systems;
• identify trust boundaries and analyze threats crossing them;
• compare discretionary, mandatory, role-based and attribute-based access control;
• describe defense-in-depth and reference security architectures;
• explain zero trust and distinguish it from perimeter-based security;
• apply security-by-design principles during system development;
• evaluate trade-offs involving usability, cost, availability, privacy and security.

1. Security as a Design Problem

A security control is effective only when it is correctly selected, implemented, configured, monitored and maintained. A technically strong control may fail because of excessive permissions, insecure defaults, poor integration or human workarounds. Security architecture therefore considers the whole system rather than isolated controls.

The classical security objectives are confidentiality, integrity and availability, commonly called the CIA triad. Confidentiality limits unauthorized disclosure; integrity protects information and systems from unauthorized alteration; availability ensures that authorized users can obtain services when needed. Authenticity, accountability, privacy and non-repudiation are often treated as additional objectives.

Security decisions involve trade-offs. Strong authentication can reduce account compromise but may increase user friction. Extensive logging improves accountability but can create privacy and storage obligations. A highly restrictive system may be secure in theory yet unsafe in practice if users bypass it. Good architecture makes risks visible and chooses controls proportionate to the value of assets and the consequences of failure.

2. Foundational Security Principles

2.1 Least Privilege

Least privilege means that a subject receives only the permissions required to perform an authorized task, for only as long as necessary. A subject may be a user, service, process, device or application.

Least privilege has three dimensions:

1. Scope: access only to required objects or resources.
2. Operation: permission to perform only required actions, such as read but not delete.
3. Duration: access expires when the task or business need ends.

For example, a reporting service may need read access to selected database views but not direct access to customer passwords, administrative tables or database configuration. A developer may need deployment access to a test environment but not production data.

Least privilege reduces the blast radius of compromised accounts and limits accidental damage. It must be supported by access reviews, just-in-time elevation, separation of administrative accounts and removal of dormant privileges. A common failure is “privilege accumulation,” in which employees retain permissions from previous roles.

2.2 Separation of Duties

Separation of duties divides a sensitive process among multiple people, roles or systems so that one actor cannot complete the entire high-risk action alone. For example, one employee may create a supplier, another may approve the supplier, and a third may authorize payment.

Separation may be:

• Static: incompatible roles cannot be assigned to the same identity.
• Dynamic: the system prevents conflicting actions within a transaction or time period.
• Technical: one system generates a request and another independently approves it.

This principle reduces fraud, insider abuse and single-person mistakes. It does not eliminate collusion, compromised approval accounts or poor monitoring. Therefore, separation of duties should be combined with logging, independent review and anomaly detection.

2.3 Defense in Depth

Defense in depth uses multiple, partially independent controls so that failure of one control does not expose the protected asset directly. Controls may include secure coding, identity protection, network segmentation, endpoint security, encryption, backups, monitoring and incident response.

Layers should not be merely repetitive. They should address different failure modes. For example, a web application firewall may block common attacks, input validation may reject malformed data, parameterized queries may prevent injection, database permissions may limit damage, and monitoring may detect suspicious behavior.

Defense in depth is not the same as buying many security products. Redundant controls that share the same dependency may fail together. If every control depends on one compromised identity provider, the architecture still has a concentration risk.

2.4 Secure Defaults

Secure defaults ensure that a system is protected before users apply additional configuration. Examples include denying network access unless explicitly allowed, requiring strong authentication for administration, disabling unused services and making data sharing private by default.

Secure defaults must be usable and documented. If the secure configuration prevents legitimate work without providing an approved alternative, users may disable it. Default passwords, publicly exposed storage and excessive default permissions are common examples of insecure defaults.

2.5 Fail-Safe Design

Fail-safe design means that when a system encounters an error, uncertainty or control failure, it fails into a state that limits harm. In access control, the usual secure failure is deny-by-default. If an authorization service is unavailable, a system should not automatically grant administrative access.

Fail-safe does not always mean “deny everything.” For safety-critical or life-preserving services, availability may be the dominant requirement. A hospital system may need an audited emergency-access procedure rather than complete denial. Such “break-glass” access should be narrowly scoped, time-limited, logged and reviewed.

Designers must distinguish fail-safe from fail-secure. Fail-secure emphasizes preventing unauthorized access; fail-safe is broader and seeks to minimize harm under failure. A door that unlocks during a fire may be life-safe but security-insecure. The correct behavior depends on the system’s hazards and priorities.

2.6 Complete Mediation

Complete mediation requires that every access to a protected resource be checked against the current authorization policy. Checking only at login is inadequate because permissions can change, sessions can be hijacked and resources may be accessed through multiple paths.

Effective mediation requires that all relevant interfaces enforce the same policy: user interfaces, APIs, background jobs, administrative tools and direct service-to-service calls. Caching authorization decisions can improve performance, but cache duration and revocation behavior must be carefully designed.

2.7 Economy of Mechanism and Open Design

Economy of mechanism favors simple, small and understandable security mechanisms. Complexity increases the chance of defects and makes review difficult. Open design means that security should not depend on secrecy of the design or algorithm. Cryptographic systems, for example, should rely on publicly evaluated algorithms and protected keys rather than secret algorithms.

3. Trust Boundaries and Security Domains

A trust boundary is a point where data, commands or identities move between components with different levels of trust. Examples include a browser-to-server connection, an Internet-facing API, a cloud account boundary, a container-to-host interface and a third-party payment service.

A trust boundary should be identified by asking:

• Who controls each component?
• What assumptions does one component make about another?
• Which data crosses the boundary?
• How are identity, integrity and authorization verified?
• What happens if the adjacent component is compromised?

Data crossing a boundary should be validated, authenticated where appropriate, authorized for the specific action, protected in transit and logged according to risk. Validation must be based on explicit rules rather than trust in client-side checks. A web browser may provide input validation for usability, but the server must enforce it because the client is outside the server’s trust boundary.

Figure: Trust boundaries in a simple application architecture.

4. Access-Control Models

Access control determines whether a subject may perform an operation on an object under specified conditions. Authentication establishes identity; authorization decides what that identity may do; auditing records relevant decisions and actions.

4.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 are common examples. DAC is flexible and convenient, but permissions can propagate through copying or sharing. A user who owns sensitive data may accidentally expose it.

4.2 Mandatory Access Control

Mandatory access control (MAC) applies centrally defined rules based on security labels or classifications. Users cannot simply override the policy because they own the object. A military-style example might classify data as Confidential, Secret or Top Secret and assign clearances to subjects.

MAC supports strong information-flow control but can be difficult to administer. Labels must be accurate, and legitimate collaboration across classifications requires controlled mechanisms.

4.3 Role-Based Access Control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. A nurse, auditor and database administrator can each receive different permissions. RBAC simplifies administration when organizational responsibilities are stable.

RBAC can suffer from role explosion when many exceptions, locations, projects and temporary conditions are added. Role design should follow business functions, use least privilege and include periodic review.

4.4 Attribute-Based Access Control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action and environment. A policy might allow a clinician to read a patient record when the clinician is assigned to that patient, the purpose is treatment, the device is managed and the request occurs through an approved channel.

ABAC supports fine-grained, context-aware decisions but requires reliable attributes, policy governance and explainable decisions. Incorrect or stale attributes can produce either unauthorized access or unnecessary denial.

4.5 Access-Control Matrix

An access-control matrix represents subjects, objects and permitted operations. For example, rows may represent roles and columns may represent resources. The matrix is a conceptual model; real systems implement it using access-control lists, capability lists, policy engines or combinations of these.

A policy decision should be evaluated for the requested action, not merely for the resource in general. “Read customer record” and “delete customer record” are different permissions. Policies should also specify obligations such as logging, masking or requiring a second approval.

5. Reference Architectures

A reference architecture is a reusable conceptual design that identifies components, responsibilities, trust relationships and control points. It is not a universal product blueprint. It must be adapted to business processes, technology and risk.

A layered enterprise architecture may include:

1. Identity layer: identity proofing, authentication, federation, privileged access and lifecycle management.
2. Endpoint layer: device configuration, patching, malware protection and device assurance.
3. Network layer: segmentation, secure protocols, firewalls and traffic monitoring.
4. Application layer: secure development, API authorization, input validation and session protection.
5. Data layer: classification, encryption, key management, backup, retention and deletion.
6. Operations layer: logging, detection, incident response, vulnerability management and recovery.

The layers are interdependent. Encryption does not correct excessive authorization; network segmentation does not replace application-level access control; monitoring does not prevent every attack. Architecture reviews should trace a critical transaction through all layers and ask where each security decision is made.

6. Zero Trust Architecture

Traditional perimeter security assumes that an internal network is more trustworthy than the Internet. This assumption is weak in cloud, mobile and distributed environments. Zero trust rejects implicit trust based on network location. It requires explicit, continuously evaluated authorization for access to resources.

Core ideas include:

• protect resources rather than merely network segments;
• authenticate and authorize users and devices before access;
• apply least privilege and limit session scope;
• assume breach and design for containment;
• collect telemetry and continuously improve policy;
• verify resource, device, identity, context and requested action.

Zero trust does not mean that trust is literally zero or that every request must be manually approved. It means that trust is not granted automatically and that authorization is based on evidence and policy.

A simplified decision flow is: a subject requests a resource; a policy engine evaluates identity, device posture, resource sensitivity, context and risk; a policy enforcement point permits, denies or constrains the request; telemetry records the decision. The decision may require step-up authentication, read-only access or a shorter session.

Zero trust has challenges. Legacy systems may not support modern identity protocols. Continuous evaluation can affect performance and privacy. Poorly designed policies can create excessive denial or encourage bypass. Adoption should therefore be incremental, beginning with critical resources and strong identity foundations.

7. Security by Design and by Default

Security by design integrates security throughout the system lifecycle rather than adding it after implementation. Activities include threat modeling, security requirements, architecture review, secure coding, testing, deployment controls and post-release monitoring.

A practical lifecycle is:

1. identify assets, users, abuse cases and trust boundaries;
2. define security and privacy requirements;
3. model threats and select controls;
4. implement using secure libraries and reviewed code;
5. test authentication, authorization, input handling, configuration and failure behavior;
6. deploy with secure defaults and controlled secrets;
7. monitor, patch, respond and learn from incidents;
8. retire data and components safely.

Threat modeling methods such as STRIDE can help teams consider spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The method is useful when it leads to concrete requirements and tests, not when it becomes a paperwork exercise.

Privacy by design is closely related. Systems should minimize collection, restrict secondary use, protect personal data, support appropriate transparency and provide retention and deletion controls. Security and privacy overlap but are not identical: a system may securely retain more personal data than it should.

8. Worked Application: University Examination Portal

Consider an illustrative university examination portal. Students upload answers, examiners grade submissions, administrators manage schedules and a payment provider handles examination fees.

Background and Problem

The portal initially uses shared administrator accounts, a single application server, broad database permissions and client-side validation. A compromised student account could potentially access other submissions through an insecure API. Administrators can both change grades and approve grade publication, creating a separation-of-duties weakness.

Analysis

Trust boundaries exist between student browsers and the application, the application and database, the portal and payment provider, and the portal and email service. Critical assets include answer scripts, grades, identity data and payment references. The main threats are unauthorized disclosure, grade tampering, account takeover, malicious uploads and service disruption during examinations.

Approach and Solution

The university applies the principles as follows:

• Students receive access only to their own submissions through server-side authorization.
• Examiners receive access only to assigned courses and submissions.
• Grade entry and publication approval are assigned to separate roles.
• The application uses a dedicated database service account with access to required views and procedures, not unrestricted administrative access.
• File uploads are type-checked, malware-scanned, stored outside executable paths and given generated names.
• Administrative actions require phishing-resistant multi-factor authentication and are logged.
• The payment provider receives only the minimum transaction data required.
• Network segmentation separates public services, application services and databases.
• Backups are encrypted, tested and protected from ordinary administrative accounts.
• The portal denies access when authorization services fail, while an audited emergency procedure supports essential operations.

Outcome

The design reduces the impact of a compromised student account, makes unauthorized grade changes more difficult and improves investigation through reliable logs. It does not guarantee security. Vulnerabilities in the application, identity provider or examiner devices remain possible, so patching, monitoring, testing and incident response continue.

Learning Points

The case demonstrates that principles work together. Least privilege limits permissions; separation of duties controls sensitive workflows; defense in depth adds independent barriers; trust-boundary analysis identifies validation and authorization points; secure defaults and fail-safe behavior reduce configuration and failure risks.

9. Governance, Ethics and Professional Practice

Security architecture involves authority and responsibility. Organizations should define who may access data, who approves exceptions, how long logs are retained and how incidents are disclosed. Access decisions should be auditable and consistent with applicable privacy, contractual and sectoral obligations.

Professionals must avoid unnecessary surveillance, discriminatory risk scoring and collection of data unrelated to security objectives. Automated security decisions should be explainable enough for review, especially when they affect employment, education, healthcare or access to essential services. Security testing must be authorized and carefully scoped.

Compliance frameworks can provide useful baselines, but compliance is not proof of security. A control may satisfy a checklist while failing against a realistic threat. Risk assessments should consider likelihood, impact, uncertainty and affected stakeholders.

10. Contemporary Developments and Limitations

Cloud computing, software-as-a-service, containers, APIs and artificial intelligence have expanded the number of identities and dependencies in modern systems. Machine identities may outnumber human identities, making credential lifecycle management and workload authorization increasingly important.

AI can assist with anomaly detection, code review, alert triage and policy analysis. It can also generate insecure code, expose confidential prompts or produce unreliable explanations. AI output requires human review, controlled data handling and testing against adversarial inputs.

No principle is absolute. Least privilege can hinder availability if emergency access is not planned. Defense in depth can increase cost and complexity. ABAC can become difficult to understand. Zero trust can be implemented as excessive surveillance or fragmented authentication. Security architecture must therefore be measurable, reviewable and aligned with real operational needs.

Best-Practice Checklist

• Inventory important assets, identities, dependencies and trust boundaries.
• Enforce authorization on the server and at every relevant interface.
• Use deny-by-default policies and secure initial configurations.
• Grant the smallest practical permissions and expire temporary access.
• Separate high-risk duties and independently review sensitive actions.
• Combine preventive, detective, corrective and recovery controls.
• Protect administrative accounts with strong authentication and monitoring.
• Test failure, revocation, backup restoration and incident procedures.
• Minimize personal data and define retention and deletion rules.
• Review architecture as systems, threats and business requirements change.

Chapter Summary

Security principles guide the design of systems that remain resilient when people, software, configurations or controls fail. Least privilege restricts permissions by scope, operation and duration. Separation of duties divides sensitive responsibilities. Defense in depth uses independent layers, while secure defaults and fail-safe behavior reduce exposure during normal use and failure. Complete mediation requires current authorization checks at every relevant access path.

Trust boundaries identify where assumptions change and where data or commands require validation, authentication, authorization and monitoring. DAC, MAC, RBAC and ABAC offer different ways to express access policy. Reference architectures organize identity, endpoint, network, application, data and operational controls. Zero trust removes implicit trust based on network location and emphasizes explicit, contextual and least-privilege authorization.

Security-by-design incorporates threat modeling, secure development, testing, privacy protection and lifecycle governance. Effective architecture balances confidentiality, integrity, availability, usability, privacy, cost and operational reality. No model eliminates risk; good practice makes risk constrained, visible and manageable.

Key Terms

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

Separation of duties: Dividing sensitive responsibilities so one actor cannot complete the entire process.

Defense in depth: Using multiple independent or partially independent security controls.

Secure default: An initial configuration that protects the system without requiring extra user action.

Fail-safe design: Designing failures to minimize harm under uncertainty or malfunction.

Complete mediation: Checking authorization for every relevant access to a protected resource.

Trust boundary: A transition between components with different trust assumptions.

Authentication: Establishing the identity of a subject.

Authorization: Determining whether an authenticated subject may perform an action.

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

Mandatory access control: Centralized access control based on labels and policy.

Role-based access control: Access control based on organizational roles.

Attribute-based access control: Access control based on subject, resource, action and contextual attributes.

Access-control matrix: A conceptual mapping of subjects, objects and permitted operations.

Reference architecture: A reusable conceptual arrangement of components and controls.

Zero trust: An approach that grants no implicit trust based on network location.

Policy enforcement point: A component that permits, denies or constrains a requested action.

Threat modeling: Structured analysis of assets, threats, trust boundaries and mitigations.

Security by design: Integrating security throughout the system lifecycle.

Break-glass access: Exceptional, controlled emergency access to restricted functions.

Review Questions

Short Answer Questions

1. Define least privilege and state its three principal dimensions.
2. What is a trust boundary? Give two examples.
3. Distinguish authentication from authorization.
4. State one strength and one limitation of RBAC.
5. What does zero trust reject about traditional perimeter security?

Long Answer Questions

1. Explain defense in depth and show how it can protect a web application.
2. Compare DAC, MAC, RBAC and ABAC in terms of policy basis, strengths and limitations.
3. Discuss secure defaults and fail-safe design, including a situation in which availability affects the failure decision.
4. Describe how security-by-design changes the software development lifecycle.
5. Explain the relationship among least privilege, separation of duties and complete mediation.

Analytical / Application Questions

1. Design access controls for a hospital record system using RBAC, ABAC and break-glass access. Explain the trust boundaries and audit requirements.
2. A company has a flat internal network and shared administrator accounts. Analyze the risks and propose a phased zero-trust and defense-in-depth architecture.
3. An online examination system allows a client application to decide whether a student may view a grade. Identify the design failures and propose secure controls using the principles in this chapter.

Multiple Choice Questions with Answers

Question 1

Which principle limits a user to only the permissions required for a task?

A. Least privilege

B. Open design

C. Non-repudiation

D. Availability

Correct Answer: A. Least privilege

Question 2

Which access-control model assigns permissions primarily through organizational roles?

A. DAC

B. MAC

C. RBAC

D. ABAC

Correct Answer: C. RBAC

Question 3

What is the main purpose of separation of duties?

A. To increase network bandwidth

B. To prevent one actor from completing a sensitive process alone

C. To eliminate all authentication requirements

D. To make every user an administrator

Correct Answer: B. To prevent one actor from completing a sensitive process alone

Question 4

Which statement best describes zero trust?

A. All internal network users are trusted automatically

B. Only external users require authentication

C. Trust is granted permanently after the first login

D. Access is explicitly evaluated rather than trusted because of network location

Correct Answer: D. Access is explicitly evaluated rather than trusted because of network location

Question 5

A server validates input only in the browser. What is the principal security problem?

A. The browser is outside the server’s trust boundary

B. The server is using too much encryption

C. The database has too many backups

D. The user has excessive screen resolution

Correct Answer: A. The browser is outside the server’s trust boundary

Question 6

Which is an example of a secure default?

A. Public access enabled for every new storage bucket

B. A default shared administrator password

C. Unused network services disabled initially

D. All users assigned administrative privileges

Correct Answer: C. Unused network services disabled initially

Question 7

Which model uses labels and centrally defined rules that resource owners cannot freely override?

A. DAC

B. MAC

C. RBAC

D. Capability-based sharing

Correct Answer: B. MAC

Question 8

Why is defense in depth valuable?

A. It guarantees that attacks are impossible

B. It makes all controls identical

C. It prevents one failed control from exposing the asset directly

D. It removes the need for monitoring

Correct Answer: C. It prevents one failed control from exposing the asset directly

Question 9

What should a fail-safe authorization system generally do when its policy service is unavailable?

A. Grant unrestricted administrator access

B. Deny access or invoke a controlled emergency procedure

C. Disable all logging

D. Copy credentials to a public location

Correct Answer: B. Deny access or invoke a controlled emergency procedure

Question 10

Which access-control approach evaluates attributes such as user, device, resource, action and context?

A. ABAC

B. MAC only

C. DAC only

D. Static password authentication

Correct Answer: A. ABAC