Security Principles, Models and Architecture

Introduction

Cybersecurity is not achieved by a single product, control, or administrator. It is achieved through a deliberate architecture in which people, processes, technologies, and governance work together to reduce risk. Security principles provide the reasoning behind security decisions; security models provide formal ways to express rules; and security architecture turns those principles and models into a dependable system design.

This chapter examines six foundational principles: least privilege, defense in depth, separation of duties, secure-by-design, zero trust, and resilience. It also explains trust boundaries, security domains, and foundational access-control models. These ideas apply across operating systems, networks, cloud platforms, databases, software development, and organizational governance.

A useful distinction is between a security control and a security principle. A control is a specific safeguard, such as multifactor authentication or a firewall rule. A principle is a general design rule that helps determine which controls are appropriate and how they should be combined.

Learning Objectives

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

• Explain the purpose and limitations of least privilege, defense in depth, separation of duties, secure-by-design, zero trust, and resilience.
• Identify trust boundaries and security domains in an information system.
• Compare discretionary, mandatory, role-based, and attribute-based access control.
• Apply foundational access-control models to practical scenarios.
• Analyze how security architecture reduces attack opportunities and limits the effects of compromise.
• Evaluate security designs in relation to usability, governance, privacy, cost, and operational continuity.

1. Security Principles as Design Constraints

Security principles function as constraints on system design. They do not prescribe one universal implementation. For example, least privilege may be implemented through operating-system permissions, cloud identity policies, database views, or application-level authorization. The principle remains constant even though the mechanism changes.

A sound security design normally addresses three related questions:

1. Who or what is requesting access? This concerns identity and authentication.
2. What may the requester do? This concerns authorization and access control.
3. What happens if a control fails? This concerns detection, containment, recovery, and resilience.

Security architecture should also recognize that protection is not absolute. Risk can be viewed conceptually as a combination of the likelihood of an adverse event and its impact. In practice, risk analysis is often qualitative because reliable probabilities are unavailable. The objective is not to eliminate every possible risk, but to reduce risk to an acceptable level while preserving legitimate functionality.

2. Least Privilege

The principle of least privilege states that each subject should receive only the permissions necessary to perform its authorized tasks, for only as long as those permissions are needed. A subject may be a user, process, service account, device, or automated workload.

Least privilege has several dimensions:

• Minimum authority: grant only required operations, such as read but not write.
• Minimum scope: restrict access to the necessary files, records, systems, or environments.
• Minimum duration: use temporary or just-in-time privileges where possible.
• Minimum independence: prevent one identity from combining permissions that create excessive power.

For example, a payroll application may need to read employee identifiers and write approved salary transactions. It should not have unrestricted access to every database table or permission to create new administrator accounts.

Least privilege reduces the damage caused by stolen credentials, software vulnerabilities, insider misuse, and accidental errors. It also improves accountability because actions can be associated with narrowly defined responsibilities.

Practical implementation

Organizations implement least privilege through:

• Role-based access control and carefully designed job roles.
• Separate standard and administrative accounts.
• Privileged access management systems.
• Just-in-time elevation and approval workflows.
• Application allow-listing and restricted service permissions.
• Network segmentation and restricted service-to-service communication.
• Regular access reviews and removal of obsolete privileges.

Least privilege is not the same as denying all access. Excessive restriction can prevent work, encourage workarounds, and lead users to share accounts. Effective design therefore applies the smallest practical privilege while maintaining operational usability.

3. Defense in Depth

Defense in depth uses multiple, preferably independent, layers of protection. The layers may include prevention, detection, response, and recovery. A typical enterprise system may use physical security, network segmentation, endpoint protection, identity controls, application validation, encryption, logging, and backups.

The principle is based on the expectation that individual controls can fail. A phishing attack may defeat a password, but multifactor authentication may block the login. If an attacker succeeds, endpoint monitoring may detect suspicious activity. If malware encrypts files, immutable backups may support recovery.

Defense in depth is stronger when layers are not all dependent on the same failure. Ten security tools relying on one compromised administrator account do not provide ten independent layers. Similarly, multiple controls from the same flawed software component may share a common vulnerability.

Preventive, detective, and corrective layers

Defense in depth should not become uncontrolled complexity. Poorly integrated controls can create alert fatigue, conflicting rules, maintenance costs, and false confidence. Each layer should have a defined purpose, owner, and method of verification.

4. Separation of Duties

Separation of duties requires that a sensitive activity be divided among multiple people, roles, or technical components so that no single entity can complete the activity improperly without detection or collusion.

A common example is financial payment processing: one employee prepares a payment, another approves it, and a third reconciles the transaction. In information technology, a developer may create code, a separate reviewer may approve it, and an operations role may deploy it.

Separation of duties may be:

• Static: incompatible roles cannot be assigned to the same user.
• Dynamic: a user may hold several roles but cannot activate conflicting roles in the same transaction or session.
• Technical: a workflow requires independent cryptographic keys, approvals, or systems.

The principle reduces fraud, abuse, and errors. It is especially important for high-impact operations such as changing identity policies, releasing production software, modifying financial records, or deleting audit logs.

However, separation of duties can be difficult in small organizations. A compensating control may be needed, such as independent after-the-fact review, tamper-resistant logging, or automated approval thresholds. Separation must be substantive rather than merely organizational: assigning two nominal roles to one shared account does not create meaningful separation.

5. Secure-by-Design and Secure Defaults

Secure-by-design means that security requirements are considered throughout the system life cycle rather than added after implementation. Security begins with requirements and continues through architecture, development, testing, deployment, operation, and retirement.

Secure-by-design includes:

• Threat modeling before implementation.
• Clear security and privacy requirements.
• Safe interface and error-handling design.
• Strong identity and authorization boundaries.
• Secure coding and dependency management.
• Security testing in development pipelines.
• Secure configuration and update mechanisms.
• Monitoring, incident response, and recovery planning.

A related principle, secure by default, means that the initial configuration should provide a safe baseline. Examples include disabling unused services, requiring strong authentication, restricting public exposure, and avoiding default passwords. Users may need to enable additional functionality, but they should not be required to understand security engineering merely to avoid dangerous settings.

Security-by-design also incorporates privacy by design. Data collection should be limited to legitimate purposes, retained only as long as necessary, and protected throughout its life cycle.

6. Zero Trust

Zero trust is an architectural approach based on the assumption that no user, device, application, or network location should receive implicit trust. Access decisions should be continuously evaluated using identity, device condition, requested resource, context, and policy.

Zero trust does not mean that trust is impossible. It means that trust is explicit, limited, evidence-based, and revisable. A user connected to an internal network is not automatically authorized to access every internal service.

Core practices include:

• Verify identity and authorization before access.
• Apply least-privilege permissions.
• Use strong authentication, often including multifactor authentication.
• Segment resources and limit lateral movement.
• Continuously monitor sessions and devices.
• Make access decisions based on policy and context.
• Assume that compromise is possible and prepare to contain it.

Zero trust is sometimes misunderstood as a single product or a replacement for network security. It is neither. It is an architecture and operating philosophy that may use identity providers, endpoint management, microsegmentation, policy engines, encryption, and analytics.

A practical zero-trust decision can consider the subject, resource, action, device health, location, time, risk signals, and business purpose. A request from a managed device during normal work hours may still be denied if the user lacks authorization for the resource.

7. Resilience and Failure Containment

Resilience is the ability of a system or organization to continue delivering important services, withstand disruption, and recover while maintaining acceptable security. Resilience extends beyond backup. It includes preparation, resistance, adaptation, response, recovery, and learning.

Security and resilience are closely related but not identical. A highly secure system that cannot recover from a hardware failure is not operationally resilient. Conversely, a highly available system that restores malware or compromised configurations may be available but insecure.

Resilience practices include:

• Redundancy for critical components.
• Tested backups, including offline or immutable copies.
• Recovery procedures and alternate operating arrangements.
• Incident response plans and exercises.
• Segmentation to contain failures.
• Monitoring and dependency mapping.
• Defined recovery objectives.

Two common continuity measures are:

• Recovery time objective (RTO): the maximum acceptable time to restore a service after disruption.
• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time.

For example, an RTO of four hours means the service should be restored within four hours. An RPO of fifteen minutes means that recovery should lose no more than approximately fifteen minutes of recent data, subject to the organization’s measurement method and backup design.

Resilience requires testing. An untested backup is an assumption, not evidence of recoverability.

8. Trust Boundaries and Security Domains

A trust boundary is a logical or physical boundary across which data, commands, or authority pass from one level of trust to another. Examples include the boundary between the public internet and a web server, between a web application and a database, or between a user workstation and a privileged administration network.

Crossing a trust boundary should trigger explicit security controls, such as authentication, authorization, validation, encryption, logging, and rate limiting. A trust boundary is not necessarily a physical network boundary. A single host may contain several processes with different privileges and therefore multiple logical boundaries.

A security domain is a collection of subjects, objects, policies, and mechanisms governed by a common security authority or protection regime. A research network, production cloud account, or classified database environment may each constitute a security domain.

Domains help administrators define policy ownership and protection requirements. Communication between domains should be governed by an explicit interface rather than assumptions about shared trust.

Example architecture

Consider an online banking service:

1. Customers connect through a public-facing web tier.
2. The web tier communicates with an application tier through restricted service accounts.
3. The application tier accesses selected database procedures rather than unrestricted tables.
4. Administrative access occurs through a separate management network.
5. Security logs are forwarded to a protected monitoring domain.

Each transition is a trust boundary. The architecture limits direct access, reduces lateral movement, and creates locations where requests can be inspected and recorded.

9. Foundational Access-Control Concepts

Access control determines whether a subject may perform an operation on an object. The subject may be a human or process; the object may be a file, record, service, device, or API endpoint. Common operations include read, write, execute, create, delete, and administer.

A basic access-control decision can be represented conceptually as:

Here, Decision is an authorization result such as permit or deny; subject identifies the requester; action is the requested operation; resource is the target; and context includes relevant conditions such as time, device status, location, and risk. This is a conceptual policy function, not a universal computational formula. Its result depends on the organization’s rules and on the reliability of the identity and context information.

Authentication establishes identity or an identity claim. Authorization determines what that identity may do. Auditing records relevant activity so that decisions and actions can be reviewed.

9.1 Discretionary Access Control

In discretionary access control (DAC), the owner of an object can generally determine who may access it. Traditional file permissions and access-control lists often implement DAC.

DAC is flexible and convenient, but permissions may spread through copying, delegation, or poor configuration. A user who owns a file may accidentally make it available to unauthorized colleagues. DAC is therefore useful in collaborative environments but requires careful review.

9.2 Mandatory Access Control

In mandatory access control (MAC), access is governed by centrally defined policy, often using security labels and clearances. Users cannot freely override the rules.

MAC is appropriate where information classification and containment are critical, such as military, government, or highly regulated environments. It provides strong control but can be complex to administer and may reduce flexibility.

9.3 Role-Based Access Control

In role-based access control (RBAC), permissions are assigned to roles, and users receive roles according to job responsibilities. A nurse, auditor, database administrator, and customer-support agent may each have different role permissions.

RBAC simplifies administration and supports separation of duties. Its weakness is role explosion: organizations may create too many narrowly specialized roles. RBAC also handles context poorly unless supplemented with conditions such as location, device state, or time.

9.4 Attribute-Based Access Control

In attribute-based access control (ABAC), decisions use attributes of the subject, resource, action, and environment. A policy might permit a clinician to view a patient record when the clinician is assigned to that patient, is using an approved device, and is operating within an authorized care context.

ABAC is expressive and well suited to cloud and distributed systems. Its complexity creates governance challenges: attributes must be accurate, policies must be understandable, and conflicting rules must be resolved consistently.

10. Classic Security Models

Several formal models clarify different security objectives.

Bell–LaPadula model

The Bell–LaPadula model focuses on confidentiality. Its well-known rules are commonly summarized as “no read up” and “no write down.” A subject at a lower clearance should not read information at a higher classification, and information at a higher classification should not be written to a lower classification in ways that could cause disclosure.

The model addresses information flow, not every aspect of modern security. It does not by itself guarantee integrity, availability, usability, or correct classification.

Biba model

The Biba model focuses on integrity. Its common rules are “no read down” and “no write up.” A higher-integrity subject should avoid receiving potentially untrusted data from a lower-integrity source, and a lower-integrity subject should not modify higher-integrity objects.

Biba is conceptually useful for preventing contamination of trusted data, although practical systems often implement integrity through application validation, workflow controls, signatures, and database constraints.

Clark–Wilson model

The Clark–Wilson model emphasizes well-formed transactions, separation of duties, and integrity through certified transformation procedures. Users do not directly manipulate protected data arbitrarily; instead, approved programs perform valid transformations, and auditing supports accountability.

This model maps well to banking, accounting, and enterprise workflows in which data integrity depends on controlled transactions rather than merely on labels.

Brewer–Nash model

The Brewer–Nash, or Chinese Wall, model addresses conflicts of interest. Access may depend on a user’s previous access history. For example, a consultant who has accessed confidential information from one competing company may be restricted from accessing confidential information from another competitor.

The model demonstrates that authorization can depend on history and business context, not only on static identities and permissions.

11. Applying Principles Together

Security principles reinforce one another. Least privilege limits what an identity can do; separation of duties prevents one identity from controlling a sensitive process; defense in depth provides additional layers; zero trust prevents implicit access; secure-by-design embeds these controls early; and resilience limits the consequences of failure.

A design review should ask:

• Are identities unique, strongly authenticated, and regularly reviewed?
• Are permissions limited by task, scope, and duration?
• Are sensitive actions divided among independent roles?
• Are trust boundaries explicitly identified and defended?
• Can an attacker move laterally after compromising one component?
• Are security events detected and investigated?
• Can critical services recover within agreed objectives?
• Are privacy, accessibility, and legitimate business needs considered?

Applied Case: Illustrative University Research Cloud

Background

A university research group stores sensitive health-related research data in a cloud environment. Researchers need to analyze approved datasets, while administrators maintain the platform. The group initially uses shared accounts, broad storage permissions, and a publicly reachable management interface.

Problem

An attacker obtains a researcher’s password through phishing. Because the account has broad permissions and the management interface is exposed, the attacker downloads multiple datasets and attempts to create a new administrative account. Logs are incomplete, and backups are connected to the production environment.

Analysis

The design violates several principles. Shared or poorly controlled identities weaken accountability. Broad permissions violate least privilege. The exposed management interface creates a dangerous trust boundary. There is insufficient separation between research and administration. Connected backups increase the risk that a destructive attack will affect recovery data. The architecture assumes that an internal cloud account is trustworthy, contrary to zero-trust reasoning.

Approach and solution

The university redesigns the environment as follows:

• Each user receives a unique identity with multifactor authentication.
• Researcher permissions are limited to approved projects and datasets.
• Administrative privileges require separate accounts and just-in-time elevation.
• Management access is restricted to a protected administration network.
• Storage is divided into research, staging, and production security domains.
• Sensitive data is encrypted, and access is logged to a separate monitoring account.
• Dataset export requires an approval workflow involving two roles.
• Endpoint health and sign-in risk are evaluated during access decisions.
• Backups are isolated and include immutable copies.
• Incident-response and recovery exercises are performed periodically.

Outcome

The redesign does not make compromise impossible. It reduces the likelihood of unauthorized access, limits the amount of data available to a compromised researcher account, improves detection, and makes recovery more reliable. It also produces clearer evidence for research governance and privacy oversight.

Learning points

The case illustrates that security architecture is systemic. Multifactor authentication alone would not have solved excessive permissions, weak segmentation, or vulnerable backups. Strong results emerge from combining principles and verifying them through monitoring and testing.

12. Limitations, Governance, and Ethical Considerations

Security controls can create costs and unintended effects. Excessive monitoring may intrude on privacy. Strict access restrictions may reduce accessibility or prevent legitimate research. Automated risk scoring may discriminate against users if its data or assumptions are biased. Security teams must therefore distinguish necessary monitoring from unjustified surveillance and ensure that access decisions are explainable and reviewable.

Governance should define ownership, approval authority, retention periods, exception procedures, and accountability. Exceptions to least privilege may be necessary during emergencies, but they should be time-limited, logged, approved where possible, and reviewed afterward.

Regulatory obligations vary by jurisdiction and sector. Privacy, financial, health, education, and critical-infrastructure rules may impose requirements for access control, logging, breach response, retention, and data minimization. Compliance is not equivalent to security: a compliant system may still be poorly designed, and a technically strong control may require documentation and governance to satisfy legal obligations.

Artificial intelligence can assist with anomaly detection, policy analysis, and security operations, but it should not be treated as an unquestionable authorization authority. Models may generate false positives, miss novel attacks, expose sensitive data, or encode bias. Human oversight, protected training data, auditability, and safe failure modes remain essential.

Best-Practice Checklist

• Start with explicit security, privacy, and availability requirements.
• Map assets, identities, trust boundaries, and dependencies.
• Grant permissions by task, scope, and duration.
• Separate ordinary and privileged accounts.
• Use independent approval for high-impact actions.
• Combine preventive, detective, and recovery controls.
• Treat internal networks as potentially hostile rather than automatically trusted.
• Review roles, attributes, accounts, and exceptions regularly.
• Protect and test backups.
• Log security-relevant events in a protected, reviewable system.
• Test incident response, recovery, and failover procedures.
• Evaluate usability, privacy, accessibility, and organizational impact.

Chapter Summary

Security principles guide the design and operation of trustworthy systems. Least privilege limits authority to what is necessary, while separation of duties prevents one person or process from controlling sensitive activities alone. Defense in depth combines independent preventive, detective, and corrective layers. Secure-by-design integrates security throughout the life cycle and secure defaults reduce dangerous initial configurations.

Zero trust removes implicit trust based on network location and requires explicit, contextual authorization. Resilience enables organizations to withstand disruption, contain compromise, and recover within defined objectives. Trust boundaries identify locations where data or authority crosses between different levels of trust, while security domains organize systems under common policies and protection regimes.

DAC, MAC, RBAC, and ABAC provide different foundations for authorization. Bell–LaPadula emphasizes confidentiality, Biba emphasizes integrity, Clark–Wilson emphasizes controlled transactions and separation of duties, and Brewer–Nash addresses conflicts of interest. No model solves every security problem; effective architecture combines appropriate models with governance, monitoring, testing, and human judgment.

Key Terms

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

Defense in depth: Using multiple complementary layers of security protection.

Separation of duties: Dividing sensitive responsibilities among independent roles or entities.

Secure-by-design: Integrating security requirements and controls throughout the system life cycle.

Secure defaults: Initial settings that provide a safe baseline without requiring expert configuration.

Zero trust: An approach that grants no implicit trust and continuously evaluates access.

Resilience: The ability to withstand disruption, continue important services, and recover securely.

Trust boundary: A boundary across which data, commands, or authority pass between different trust levels.

Security domain: A group of subjects, objects, policies, and mechanisms governed by a common authority.

Authentication: Establishing or asserting the identity of a subject.

Authorization: Determining what an authenticated subject may do.

Discretionary access control: Access control in which object owners generally determine permissions.

Mandatory access control: Centrally governed access control based commonly on labels and clearances.

Role-based access control: Access control based on organizational roles and their permissions.

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

Bell–LaPadula model: A confidentiality-focused model using information-flow restrictions.

Biba model: An integrity-focused model using restrictions on information flow.

Clark–Wilson model: An integrity model based on well-formed transactions and separation of duties.

Recovery time objective: The maximum acceptable time for restoring a service after disruption.

Recovery point objective: The maximum acceptable period of data loss measured in time.

Review Questions

Short Answer Questions

1. What is the principle of least privilege, and why does it reduce security risk?
2. Distinguish authentication from authorization.
3. What is a trust boundary? Give one example.
4. State one major difference between RBAC and ABAC.
5. What do RTO and RPO measure?

Long Answer Questions

1. Explain how least privilege, separation of duties, and defense in depth work together in an enterprise system.
2. Compare DAC, MAC, RBAC, and ABAC, including an appropriate use case and limitation for each.
3. Explain zero trust and discuss why it is more than a network-security product.
4. Describe how secure-by-design changes the software development life cycle.
5. Compare the Bell–LaPadula, Biba, Clark–Wilson, and Brewer–Nash models.

Analytical / Application Questions

1. A hospital allows every authenticated employee to search all patient records. Identify the violated principles and propose a redesigned authorization architecture.
2. A small company cannot assign separate employees to prepare, approve, and reconcile payments. Design compensating controls that preserve accountability and reduce fraud risk.
3. A cloud service has multifactor authentication but unrestricted service accounts, public management interfaces, and untested backups. Analyze the weaknesses using the principles in this chapter and prioritize improvements.

Multiple Choice Questions with Answers

Question 1

Which statement best describes least privilege?

A. Every user receives administrator access for convenience

B. A subject receives only the permissions necessary for authorized tasks

C. Access is granted solely according to physical location

D. All permissions are permanently removed after authentication

Correct Answer: B. A subject receives only the permissions necessary for authorized tasks

Question 2

What is the primary purpose of defense in depth?

A. To ensure that one control can never fail

B. To replace the need for incident response

C. To provide multiple complementary layers when individual controls fail

D. To allow all users unrestricted access inside the network

Correct Answer: C. To provide multiple complementary layers when individual controls fail

Question 3

Which example best demonstrates separation of duties?

A. One administrator creates and approves a privileged account

B. A user changes a password using self-service recovery

C. One employee prepares a payment and another independently approves it

D. All employees use the same shared account

Correct Answer: C. One employee prepares a payment and another independently approves it

Question 4

Which statement is central to zero trust?

A. Internal network traffic is automatically trusted

B. Trust is granted permanently after the first login

C. No subject receives implicit trust based only on network location

D. Only passwords are needed for sensitive access

Correct Answer: C. No subject receives implicit trust based only on network location

Question 5

Which access-control model is primarily based on organizational job functions?

A. RBAC

B. MAC

C. DAC

D. Chinese Wall

Correct Answer: A. RBAC

Question 6

A policy permits a clinician to view a record only when the clinician is assigned to the patient, uses a managed device, and is on duty. Which model is most directly represented?

A. DAC

B. ABAC

C. Biba

D. Static MAC only

Correct Answer: B. ABAC

Question 7

Which model primarily addresses confidentiality through rules commonly summarized as no read up and no write down?

A. Biba

B. Clark–Wilson

C. Bell–LaPadula

D. Brewer–Nash

Correct Answer: C. Bell–LaPadula

Question 8

A trust boundary is best described as:

A. A location where data or authority crosses between different trust levels

B. A list of all software installed on a computer

C. A backup copy stored offline

D. A password complexity requirement

Correct Answer: A. A location where data or authority crosses between different trust levels

Question 9

What does an RPO of 15 minutes generally indicate?

A. The service must be restored within 15 minutes

B. No more than approximately 15 minutes of recent data should be lost

C. A user may remain logged in for 15 minutes

D. The system must detect an attack within 15 minutes

Correct Answer: B. No more than approximately 15 minutes of recent data should be lost

Question 10

Which practice most directly supports secure-by-default design?

A. Enabling all services and requiring users to disable unsafe features

B. Using default administrator passwords until deployment is complete

C. Disabling unnecessary services and restricting public exposure in the initial configuration

D. Delaying security requirements until after production release

Correct Answer: C. Disabling unnecessary services and restricting public exposure in the initial configuration