Security Principles, Models and Architecture

Introduction

Cybersecurity is not achieved by installing a single product or responding to individual incidents. It is achieved by designing systems, processes, and decisions so that information and services remain trustworthy under normal use, human error, equipment failure, and deliberate attack. Security principles provide the reasoning tools for making those design decisions. Security models translate principles into rules that can be implemented and tested, while security architecture organizes controls across people, processes, technologies, and physical environments.

This chapter introduces foundational principles used in cybersecurity practice: least privilege, need-to-know, separation of duties, defense in depth, secure-by-design, fail-safe defaults, resilience, and Zero Trust. It also distinguishes preventive, detective, corrective, deterrent, and compensating controls. These concepts are related but not interchangeable. For example, least privilege limits what an account can do; authentication establishes who is using the account; logging detects activity; and a backup helps recovery after an incident.

Learning Objectives

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

• explain major security principles and apply them to practical situations;
• distinguish least privilege from need-to-know and separation of duties;
• describe defense in depth, secure-by-design, fail-safe defaults, resilience, and Zero Trust;
• classify controls as preventive, detective, corrective, deterrent, or compensating;
• use basic security models to reason about confidentiality, integrity, and access;
• identify architectural weaknesses and recommend proportionate improvements;
• evaluate governance, ethical, and operational implications of security decisions.

1. The Security Objective: Trustworthy Systems

The traditional foundation of cybersecurity is the CIA triad:

• Confidentiality means that information is not disclosed to unauthorized people, processes, or systems.
• Integrity means that information and systems remain accurate, complete, and protected from unauthorized alteration.
• Availability means that authorized users can access information and services when required.

These objectives often conflict. Strong confidentiality controls may slow access. Aggressive availability measures may increase exposure. Integrity checks may consume processing capacity. Security architecture therefore involves risk-based decisions rather than maximizing one objective in isolation.

Other properties are also important. Authenticity concerns whether an identity, message, or system is genuine. Accountability links actions to responsible subjects through records and governance. Non-repudiation provides evidence that a party performed an action, although technical evidence alone cannot resolve every legal or organizational dispute.

A security decision should begin by identifying assets, likely threats, vulnerabilities, business requirements, legal obligations, and acceptable risk. Controls should then be selected according to their effectiveness, cost, usability, and effect on operations.

2. Foundational Principles

2.1 Least privilege

Least privilege gives a subject only the permissions required to perform an authorized task, for only as long as those permissions are needed. A subject may be a user, service account, process, device, or application.

Practical applications include:

• assigning ordinary users standard accounts rather than permanent administrator rights;
• granting a database service permission to read only the tables it requires;
• using time-limited elevation for maintenance;
• separating production and development credentials;
• removing unused accounts and permissions through periodic review.

Least privilege reduces the damage caused by mistakes, compromised accounts, and malicious insiders. It does not eliminate risk: a narrowly privileged account can still be abused, and excessive complexity can cause administrators to create unsafe workarounds. Effective implementation therefore requires access inventories, role design, approval processes, logging, and regular recertification.

2.2 Need-to-know

Need-to-know limits access to information according to a legitimate business requirement. It is related to least privilege but focuses particularly on information exposure. A person may have a broad technical role yet not need access to every dataset within that role.

For example, a payroll administrator may need access to salary records but not medical information. A help-desk analyst may be allowed to reset a password without viewing the contents of a user's files.

Least privilege asks, “What operations may this subject perform?” Need-to-know asks, “Which information must this subject see?” Both should be applied together. Role-based access control can support these principles, but roles must be carefully defined and reviewed.

2.3 Separation of duties

Separation of duties divides a sensitive process among two or more people or roles so that no single person can complete the entire process improperly without detection. A common example is requiring one employee to create a supplier and another to approve payment.

Separation of duties may be:

• static, where conflicting privileges cannot coexist;
• dynamic, where a conflict is prevented during a particular transaction;
• sequential, where different people perform different stages;
• dual control, where two authorized people must act together.

The principle helps control fraud, error, and abuse. It must be adapted to organizational size. In a small organization, complete separation may be impractical; compensating controls such as independent review, automated logging, and management approval may be necessary.

2.4 Defense in depth

Defense in depth uses multiple, preferably independent, protective layers. Layers may include policy, physical security, identity controls, network segmentation, endpoint protection, application validation, encryption, monitoring, backups, and incident response.

The aim is not simply to place many controls in one location. Controls should address different failure modes. A firewall and a second firewall configured identically may provide less diversity than a firewall combined with strong identity controls, application authorization, and detection. Layered security also assumes that some controls will fail, be bypassed, or be misconfigured.

A useful architectural sequence is:

Figure: Defense in depth distributes security functions across governance, identity, technical protection, detection, and recovery layers.

2.5 Secure-by-design and secure-by-default

Secure-by-design means that security is considered throughout the system life cycle rather than added after deployment. Requirements, architecture, coding, testing, procurement, configuration, maintenance, and retirement all include security considerations.

Secure-by-design practices include threat modeling, abuse-case analysis, dependency management, code review, security testing, privacy review, and defined security ownership. They also include designing for safe failure, updateability, logging, and recovery.

Secure-by-default means that the initial configuration provides a safe baseline. Examples include disabling unnecessary services, requiring strong authentication, restricting network exposure, using protective privacy settings, and denying optional access until it is explicitly enabled. Defaults matter because many systems remain near their original configuration.

2.6 Fail-safe defaults

Fail-safe defaults deny access or functionality unless it has been explicitly authorized. In access control, this is commonly called “default deny.” A newly created account should not automatically receive broad access; an unrecognized network request should not be accepted merely because no rule matched it.

Fail-safe design must consider availability and safety. A system controlling medical equipment or industrial processes cannot simply stop without considering human consequences. In such environments, the safe state may be a controlled degraded mode rather than total shutdown. Designers must define failure states, emergency procedures, and authorized override mechanisms.

2.7 Resilience

Resilience is the ability to prepare for, withstand, respond to, and recover from adverse events while maintaining important functions. It extends beyond prevention. Resilient organizations assume that outages, attacks, mistakes, and supplier failures will occur.

Resilience includes redundancy, tested backups, alternate communications, incident response, business continuity, disaster recovery, crisis leadership, and lessons learned. It also depends on recovery objectives:

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

RTO and RPO are business requirements, not guarantees. They should be defined through impact analysis and validated through exercises and restoration tests.

2.8 Zero Trust

Zero Trust is an architectural and operational approach based on the principle “never trust, always verify.” It does not mean that trust is impossible; it means that implicit trust based on network location, device ownership, or previous access is insufficient.

A Zero Trust decision evaluates signals such as authenticated identity, device condition, requested resource, session context, location, behavior, and risk. Access is granted to a specific resource for a specific purpose and may be continuously re-evaluated.

Core practices include:

• strong identity proofing and multifactor authentication;
• device and application inventory;
• micro-segmentation and resource-level authorization;
• least privilege and just-in-time access;
• centralized, high-quality telemetry;
• automated policy enforcement and rapid revocation.

Zero Trust is not a single product and does not remove the need for network controls, endpoint protection, or recovery. Poor identity data, incomplete asset inventories, and excessive monitoring can undermine implementation. A phased approach should begin with critical resources and measurable access policies.

3. Security Models

A security model is a formal or semi-formal description of how access, information flow, or system behavior should be controlled. Models help translate policy into rules that can be implemented and audited.

3.1 Access-control models

Discretionary access control (DAC) allows resource owners to decide who may access resources. It is flexible but can permit uncontrolled permission propagation.

Mandatory access control (MAC) applies centrally enforced labels or classifications. Users cannot normally override the rules. It is useful where information classification and strict containment are required.

Role-based access control (RBAC) assigns permissions to roles, and users receive roles according to responsibilities. RBAC simplifies administration but can suffer from role explosion and stale assignments.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might allow a clinician to view a patient record only when assigned to that patient, using an approved device, during an active treatment relationship. ABAC can express context-rich policies but requires reliable attributes and policy governance.

These models can be combined. An organization may use RBAC for ordinary administration and ABAC for sensitive, context-dependent decisions.

3.2 Confidentiality and integrity models

The Bell–LaPadula model focuses on confidentiality. Its well-known rules are “no read up” and “no write down,” intended to prevent information from flowing from a higher classification to a lower one through ordinary operations.

The Biba model focuses on integrity. Its classic rules are “no read down” and “no write up,” intended to prevent reliance on less trustworthy data and unauthorized contamination of higher-integrity objects.

These models are conceptual tools, not complete security programs. Real systems must also address availability, identity lifecycle, covert channels, usability, administration, and operational exceptions.

3.3 Control objectives and assurance

Security models should be connected to measurable control objectives. Examples include: all privileged access is multifactor authenticated; critical logs are protected from alteration; backups are restored at defined intervals; and access reviews are completed by accountable owners.

Assurance asks whether controls are correctly designed, correctly implemented, and operating effectively. A policy that requires quarterly review is not sufficient evidence that reviews occurred. Evidence may include approval records, system configurations, test results, and sampled logs.

4. Control Categories

Controls may be classified by their purpose. Categories can overlap; a single control may have more than one effect.

A control's classification depends on its intended function. A camera may deter, detect, and provide evidence. A backup is mainly corrective or recovery-oriented; it does not prevent an attacker from stealing current data. A compensating control should be documented, risk assessed, approved by an accountable authority, and reviewed for continued suitability. It is not automatically equivalent to the original control.

5. Applying Principles to Architecture

Security architecture translates principles into boundaries, trust relationships, data flows, and control placement. A basic process is:

1. Identify important assets and business services.
2. Map users, devices, applications, data stores, and external dependencies.
3. Mark trust boundaries and information flows.
4. Identify threats and misuse cases.
5. Apply least privilege, need-to-know, and separation of duties.
6. Add preventive, detective, corrective, deterrent, and compensating controls.
7. Define secure defaults, failure behavior, recovery objectives, and ownership.
8. Test the design through review, simulation, and operational evidence.

For example, an online student portal should not connect directly to a database using a highly privileged account. A more defensible design uses authenticated users, an application layer, parameterized queries, a restricted service identity, database segmentation, protected logs, alerting, and tested backups. Administrative functions should require stronger authentication and separate approval where appropriate.

Architecture decisions should also consider data minimization, privacy, accessibility, maintainability, and total cost of ownership. A control that users cannot understand or operate may produce unsafe workarounds. Security is therefore socio-technical: people and processes are part of the architecture.

6. Illustrative Case: Protecting a Small Health Clinic

Background

This fictional case concerns a small clinic using a cloud-based patient-record system, internet-connected diagnostic devices, email, and a part-time technology provider. The clinic has ten employees and limited security expertise.

Problem

All employees share a generic administrative account for one system. Diagnostic devices are placed on the same network as office laptops. Backups are configured but have never been restored in a test. A phishing message compromises an employee mailbox, and the attacker attempts to access patient records.

Analysis

The clinic has violated least privilege and accountability through shared accounts. Need-to-know is absent because broad administrative access is given to staff who do not require it. Network placement creates excessive implicit trust. Untested backups weaken resilience. Email compromise creates a path to sensitive information and may enable fraudulent requests.

Approach and solution

The clinic first identifies critical services and classifies patient information as highly sensitive. It introduces named accounts, multifactor authentication, role-based access, and quarterly access reviews. Reception staff receive only scheduling and demographic permissions; clinicians receive records required for patient care; billing staff receive billing information; and the technology provider receives time-limited administrative access.

Diagnostic devices are placed in a segmented network. The provider configures default-deny firewall rules, restricts outbound traffic, patches supported devices, and isolates unsupported devices as a compensating measure. Email filtering, phishing-resistant authentication where available, and staff reporting procedures are added. Central logs record authentication, privilege changes, and unusual downloads. Alerts are reviewed by the provider under a defined service agreement.

The clinic establishes an offline or otherwise protected backup copy, documents RTO and RPO requirements, and performs restoration exercises. A two-person approval is required for changes to payment details or bulk exports of records. Warning banners, contractual sanctions, and privacy training provide deterrence, but the clinic does not rely on deterrence alone.

Outcome

The redesigned environment reduces the consequences of a compromised account, improves investigation, and gives the clinic a tested recovery path. Some work takes longer because staff must authenticate and request elevated access. This is managed through clear procedures and time-limited workflows rather than by restoring permanent privileges.

Learning points

The case demonstrates that principles reinforce one another. Least privilege limits access; need-to-know limits information exposure; separation of duties reduces fraud; segmentation supports defense in depth and Zero Trust; logs enable detection; and tested backups support resilience. It also shows that a small organization can apply these principles incrementally without building a complex enterprise platform.

7. Challenges, Ethics, and Governance

Security controls create ethical responsibilities. Monitoring should be proportionate, transparent, legally justified, and limited to legitimate purposes. Organizations should protect employee and customer data collected for security, restrict access to monitoring records, and define retention periods. Excessive surveillance can damage trust and may conflict with privacy law or employment obligations.

Access decisions must avoid unjustified discrimination. Automated risk scoring and AI-assisted detection can generate false positives, encode biased assumptions, or expose sensitive attributes. Human review, documented decision criteria, appeal processes, testing, and auditability are important safeguards. AI tools should not be granted unrestricted access to confidential data merely because they are convenient.

Governance assigns ownership. Senior leadership sets risk appetite and resources; system owners define business requirements; security professionals advise and monitor; privacy and legal specialists interpret obligations; and users follow procedures and report problems. Regulations and standards may require access control, auditability, incident response, retention, or resilience, but compliance is not identical to security. A compliant control can still be poorly configured or ineffective.

8. Contemporary Practice and Best Practices

Modern environments use cloud services, mobile devices, software supply chains, application programming interfaces, and automated deployment. Principles must therefore apply beyond a traditional corporate network. Recommended practices include:

• maintain an accurate inventory of identities, devices, software, data, and suppliers;
• use unique identities and multifactor authentication for sensitive access;
• remove unnecessary privileges and make privileged access time-limited;
• protect secrets and service identities through managed vaults and rotation;
• segment critical systems and restrict east-west movement;
• build security testing and dependency management into software delivery;
• collect useful, protected logs and define response responsibilities;
• test backups, failover, incident response, and supplier contingencies;
• document compensating controls and review them periodically;
• measure outcomes, such as remediation time, restoration success, and access-review completion, rather than merely counting products;
• design for accessibility and usable security so that safe behavior is practical.

The central lesson is that architecture is a continuing process. Systems, threats, suppliers, regulations, and business purposes change. Reviews, exercises, and evidence must therefore be continuous enough to detect when an initially sound design has become unsafe.

Chapter Summary

Security principles provide a disciplined basis for protecting systems and information. Least privilege restricts permissions to what is necessary; need-to-know restricts information exposure; and separation of duties divides sensitive responsibilities. Defense in depth uses diverse layers so that one failure does not determine the outcome. Secure-by-design and secure-by-default integrate protection into the life cycle and initial configuration. Fail-safe defaults deny unauthorized action while accounting for safety-critical failure states. Resilience prepares an organization to withstand disruption and recover, while Zero Trust removes implicit trust and evaluates access in context.

Security models such as DAC, MAC, RBAC, ABAC, Bell–LaPadula, and Biba help express access and information-flow requirements. Controls may be preventive, detective, corrective, deterrent, or compensating, and one control can serve several functions. Effective architecture combines these ideas with governance, privacy, usability, monitoring, tested recovery, and accountable ownership.

Key Terms

Least privilege: Granting only the permissions required for an authorized task.

Need-to-know: Restricting information access to a legitimate business requirement.

Separation of duties: Dividing sensitive responsibilities among people or roles.

Defense in depth: Using multiple, diverse security layers.

Secure-by-design: Incorporating security throughout the system life cycle.

Secure-by-default: Providing a protective initial configuration.

Fail-safe default: Denying access or functionality unless explicitly authorized.

Resilience: The ability to prepare for, withstand, respond to, and recover from disruption.

Zero Trust: An approach that verifies access explicitly and rejects implicit trust.

Discretionary access control: Access controlled by resource owners.

Mandatory access control: Centrally enforced access based on classifications or labels.

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

Attribute-based access control: Making decisions using subject, resource, action, and context attributes.

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

Detective control: A control intended to identify an event or condition.

Corrective control: A control intended to restore or repair after an event.

Deterrent control: A control intended to discourage harmful behavior.

Compensating control: An alternative control used when the preferred control is impractical.

Recovery time objective: The targeted maximum time to restore a service.

Recovery point objective: The targeted maximum data-loss interval after disruption.

Review Questions

Short Answer Questions

1. What is the difference between least privilege and need-to-know?
2. Why is separation of duties useful in financial or administrative processes?
3. What does “default deny” mean?
4. Why are backups not purely preventive controls?
5. State two characteristics of Zero Trust.

Long Answer Questions

1. Explain how least privilege, need-to-know, and separation of duties can be applied together in a hospital.
2. Discuss the benefits and limitations of defense in depth.
3. Compare RBAC and ABAC, including a situation in which each may be appropriate.
4. Explain how secure-by-design differs from adding security after deployment.
5. Discuss why resilience requires more than technical redundancy.

Analytical / Application Questions

1. A small company cannot implement multifactor authentication on a legacy application. Propose and justify a documented set of compensating controls.
2. An administrator can create a supplier, approve invoices, and change bank details. Analyze the risks and redesign the process using separation of duties and monitoring.
3. A cloud application trusts every request originating from the corporate network. Evaluate this design using Zero Trust principles and propose a transition plan.

Multiple Choice Questions with Answers

Question 1

Which principle gives a user only the permissions required for a specific task?

A. Least privilege

B. Defense in depth

C. Separation of duties

D. Non-repudiation

Correct Answer: A. Least privilege

Question 2

Which control is primarily intended to identify suspicious activity after it occurs?

A. Network segmentation

B. Audit logging and alerting

C. Input validation

D. Multifactor authentication

Correct Answer: B. Audit logging and alerting

Question 3

A payroll employee can access salary records but not medical records. Which principle is most directly illustrated?

A. Need-to-know

B. Fail-safe default

C. Deterrence

D. Availability

Correct Answer: A. Need-to-know

Question 4

What is the main purpose of separation of duties?

A. To ensure every employee has administrator access

B. To divide sensitive activities so one person cannot complete them improperly alone

C. To eliminate the need for audit logs

D. To make all access decisions discretionary

Correct Answer: B. To divide sensitive activities so one person cannot complete them improperly alone

Question 5

Which statement best describes Zero Trust?

A. All internal network traffic is trusted

B. Users are verified once and never re-evaluated

C. Access is explicitly verified and limited to the requested resource and context

D. External users are denied while internal users are automatically allowed

Correct Answer: C. Access is explicitly verified and limited to the requested resource and context

Question 6

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

A. Corrective

B. Deterrent

C. Preventive

D. Discretionary

Correct Answer: A. Corrective

Question 7

Which access-control model assigns permissions through job functions such as clinician or billing clerk?

A. RBAC

B. MAC

C. DAC

D. Biba

Correct Answer: A. RBAC

Question 8

What does secure-by-default mean?

A. The system begins with the broadest possible access

B. The initial configuration provides a protective baseline

C. Security is considered only after an incident

D. Users cannot ever change configuration

Correct Answer: B. The initial configuration provides a protective baseline

Question 9

A warning banner and published disciplinary policy are examples primarily of which control category?

A. Corrective

B. Deterrent

C. Compensating

D. Recovery

Correct Answer: B. Deterrent

Question 10

Which statement about a compensating control is correct?

A. It is automatically equal to the preferred control

B. It is used as an alternative when the preferred control is impractical and should be documented and reviewed

C. It prevents the need for risk assessment

D. It can be implemented without an owner

Correct Answer: B. It is used as an alternative when the preferred control is impractical and should be documented and reviewed