Chapter 2
Security Principles, Models and Architecture
Diploma in Cyber Security
Cyber Security Fundamentals
•
Diploma
Security Principles, Models and Architecture
Introduction and Context
Cyber security is not achieved by installing a single product or applying one technical control. It is achieved by designing systems so that failure, misuse and attack are limited, detected and recoverable. Security principles provide the reasoning behind such designs; security models provide structured ways to express requirements; and security architecture turns those principles into an arrangement of people, processes, technologies, data flows and controls.
This chapter develops foundational principles used when designing and evaluating basic systems. It focuses on defense in depth, least privilege, separation of duties, zero trust, secure-by-design, resilience and trust boundaries. These concepts are interdependent. For example, least privilege reduces the damage caused by a compromised account, while segmentation limits the account’s movement across trust boundaries. Resilience ensures that the organization can continue or recover when preventive controls fail.
Security architecture should support organizational objectives rather than obstruct them unnecessarily. A university, bank, hospital or small business will have different assets, legal duties, risk tolerances and operating models. Nevertheless, the principles in this chapter are broadly applicable.
Learning Objectives
By the end of this chapter, you should be able to:
Explain major security principles and their relationship to risk reduction.
Apply defense in depth, least privilege and separation of duties to basic architectures.
Describe zero trust and distinguish it from traditional perimeter security.
Identify trust boundaries and analyze how data and privileges cross them.
Apply secure-by-design and resilience concepts throughout a system life cycle.
Evaluate a simple architecture and recommend practical controls.
Recognize ethical, governance and compliance implications of security design.
Security Principles as Design Reasoning
A security principle is a general rule that guides decisions. Principles are more durable than particular technologies. A firewall may be replaced by a cloud control, but the principle of restricting unnecessary communication remains relevant.
Security controls are commonly understood as:
Preventive controls, which reduce the likelihood of an unwanted event, such as access control or secure configuration.
Detective controls, which identify events, such as logging, monitoring and intrusion detection.
Corrective controls, which restore an acceptable state, such as patching, account reset and malware removal.
Deterrent controls, which discourage misconduct, such as visible monitoring and disciplinary policies.
Compensating controls, which provide an alternative reduction in risk when the preferred control cannot be implemented.
A mature architecture combines these types. Prevention is valuable, but prevention alone is fragile because credentials can be stolen, software can contain defects, and authorized users can make mistakes.
The Security Objectives
The classic objectives are confidentiality, integrity and availability, often called the CIA triad.
Confidentiality prevents unauthorized disclosure.
Integrity protects accuracy, completeness and unauthorized alteration.
Availability ensures that authorized users can access systems and information when required.
Additional objectives are often necessary. Authenticity concerns whether an entity or message is genuine. Accountability connects actions to responsible identities through records and controls. Non-repudiation provides evidence that a party performed an action, although its legal strength depends on policy, technology and jurisdiction.
Controls can improve one objective while affecting another. Strong encryption may improve confidentiality but complicate availability if keys are lost. Extensive monitoring may improve accountability but create privacy concerns. Architecture therefore involves balancing protection, usability, cost, performance and legal obligations.
Defense in Depth
Defense in depth places multiple, partially independent controls between an asset and a threat. The idea comes from military defense but is widely applied to information systems. If one control fails, another may still prevent, detect or limit the attack.
A layered architecture may include:
Governance policies and security awareness.
Physical protection of facilities and devices.
Identity proofing, authentication and authorization.
Network segmentation and filtering.
Secure operating-system and application configuration.
Data encryption and loss-prevention controls.
Logging, monitoring and alerting.
Backups, incident response and recovery testing.
Defense in depth is not simply the purchase of several products. If all controls depend on the same administrator account, identity provider or network path, they may fail together. Independence, diversity and visibility matter. For instance, endpoint detection, centralized logging and offline backups provide different forms of protection and recovery.
A practical design question is: “What happens if this control fails?” The answer should identify the next layer, the evidence generated, and the recovery action. Layers should also be proportionate to risk. Excessive controls can create complexity, misconfiguration and alert fatigue.
Least Privilege and Need to Know
Least privilege means granting an entity only the permissions required for an authorized task, for only as long as necessary. The entity may be a user, process, service account, application or device. Need to know is a related information principle: access to information is granted only when a legitimate task requires it.
Least privilege has several dimensions:
Scope: which resources can be accessed.
Operation: what can be done, such as read, create, modify or delete.
Time: how long access remains active.
Context: from which device, location or network access is permitted.
Privilege level: whether administrative actions are allowed.
Role-based access control (RBAC) assigns permissions to roles rather than directly to individuals. Attribute-based access control (ABAC) evaluates attributes such as user department, data classification, device health, time and location. Privileged access management can require approval, multifactor authentication, session recording and just-in-time elevation.
Least privilege must be usable. If permissions are too restrictive, employees may create unsafe workarounds, share accounts or store data elsewhere. Effective implementation therefore includes access reviews, clear ownership, temporary elevation and a process for requesting legitimate access.
Separation of Duties
Separation of duties divides a sensitive process among two or more people, roles or systems so that one actor cannot complete the entire high-risk activity alone. It reduces fraud, abuse and undetected error.
For example, a payment process may require one employee to create a supplier record, another to approve the payment and an automated system to release funds. In software delivery, a developer may write code, an automated pipeline may test it, and a separate reviewer may approve production deployment.
Separation of duties can be:
Static, where incompatible roles cannot be assigned to the same person.
Dynamic, where a conflict is checked during a particular transaction.
Preventive, where the system blocks conflicting actions.
Detective, where actions are reviewed after they occur.
Small organizations may not have enough employees for complete separation. Compensating controls include independent review, detailed logs, management approval, rotation of duties and reconciliations. Separation must also be designed carefully: dividing responsibility without ensuring communication can delay incident response or create accountability gaps.
Trust Boundaries and Reference Monitors
A trust boundary is a logical or physical division across which information, commands or privileges move between environments with different levels of trust. Examples include:
Internet and internal network.
User workstation and server.
Application and database.
Organization and cloud provider.
Production and development environments.
Ordinary user account and administrator account.
Trust is not binary. A network inside an organization is not automatically safe, and an external network is not automatically malicious. Trust should be treated as a set of explicit assumptions that are verified and constrained.
At a boundary, architecture should specify:
What crosses the boundary.
Which identities are authenticated.
Which actions are authorized.
How data is validated and protected.
What is logged and monitored.
What happens when a request is denied or a component fails.
A useful conceptual mechanism is a reference monitor: a small, complete and tamper-resistant mechanism that mediates every access to a protected object. In practical systems, access-control enforcement is distributed among operating systems, applications, gateways and data stores. The closer enforcement is to the protected resource, the less likely it is that an overlooked path will bypass it.
Trust-Boundary Illustration
Layered architecture showing trust boundaries between users, application services and protected data
Figure: Layered architecture showing trust boundaries between users, application services and protected data
Figure: Trust boundaries require explicit mediation of requests between system zones.
Zero Trust
Zero trust is an architectural approach in which no request is trusted merely because it originates inside a network or because the requester was previously authenticated. Each request is evaluated using available evidence, such as identity, device status, requested resource, data sensitivity, behavioral signals and environmental conditions.
A zero-trust design commonly follows these practices:
Verify explicitly using strong authentication and authorization.
Apply least privilege and limit access to a specific resource and action.
Assume breach and design to contain compromise.
Monitor continuously and re-evaluate access when conditions change.
Segment systems and reduce unnecessary east-west communication.
Protect data in transit and at rest.
Zero trust is not a single product, nor does it mean that users must authenticate repeatedly without reason. It is also not identical to denying all access. Its purpose is to replace implicit trust with explicit, risk-informed decisions. Good implementation requires accurate asset inventories, identity governance, reliable telemetry and usable policies.
Secure-by-Design and Secure-by-Default
Secure-by-design means that security is treated as a core system requirement from conception through retirement, rather than as a late-stage add-on. Threat modeling, security requirements, architecture review, secure coding and abuse-case testing should occur before deployment.
Secure-by-default means that the initial configuration provides a reasonably safe state. Examples include disabled unused services, multifactor authentication enabled where feasible, minimal exposed interfaces, encryption enabled by default and privacy-protective data collection settings.
A secure life cycle includes:
Identify assets, stakeholders, threats and legal requirements.
Define security and privacy requirements.
Model trust boundaries and attack paths.
Select controls and document assumptions.
Implement using secure development and configuration practices.
Test functionality, misuse cases, resilience and access enforcement.
Deploy with monitoring, rollback and change control.
Patch, review, measure and retire safely.
Security cannot be delegated entirely to end users. Interfaces should make safe actions easy, provide understandable warnings and avoid collecting unnecessary data. This reflects the principles of usability, privacy by design and fail-safe operation.
Resilience and Recovery
Resilience is the capability of a system or organization to prepare for, withstand, adapt to and recover from adverse conditions while maintaining important functions. It extends beyond availability during normal operation.
Resilience planning begins by identifying critical services and their dependencies. Two important recovery objectives 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, subject to the organization’s stated assumptions. An RPO of one hour means that restoration should lose no more than approximately one hour of transactions. These are business requirements, not guarantees produced automatically by a backup tool.
Resilience controls include redundancy, tested backups, spare capacity, alternate communications, graceful degradation, incident response plans and manual workarounds. Backups should be protected from ransomware through access restrictions, immutability or offline copies, encryption and restoration testing. A backup that has never been restored successfully is an assumption, not demonstrated resilience.
Resilience also has a human dimension. Plans should identify decision authority, communications, suppliers, legal reporting duties and staff welfare. Overdependence on a single cloud provider, administrator or software component creates concentration risk.
Security Models and Frameworks
A security model is an abstract representation of security rules and permitted interactions. A framework is a structured set of practices or functions used to organize implementation and governance. Models help explain what should be allowed; frameworks help organizations manage how security is implemented.
Access-Control Models
Discretionary access control (DAC): resource owners may grant access. It is flexible but can lead to uncontrolled propagation of permissions.
Mandatory access control (MAC): a central policy based on labels or classifications controls access. Users cannot normally override the policy.
Role-based access control (RBAC): permissions are associated with job or system roles.
Attribute-based access control (ABAC): decisions use attributes and policy conditions, supporting context-sensitive decisions.
Information-Flow Models
The Bell–LaPadula model focuses on confidentiality, traditionally expressed through “no read up” and “no write down” rules under specified assumptions. It does not by itself guarantee integrity or availability. The Biba model focuses on integrity, commonly restricting reading from lower-integrity sources and writing to higher-integrity objects. These models are useful abstractions, but real systems must address identity lifecycle, covert channels, usability, administration and operational exceptions.
Governance and Risk Frameworks
Organizations often use recognized frameworks to structure cybersecurity activities. The NIST Cybersecurity Framework groups activities around Govern, Identify, Protect, Detect, Respond and Recover. The ISO/IEC 27001 family supports an information security management system based on organizational context, risk treatment, control selection and continual improvement. Such frameworks do not replace judgment: an organization must select controls appropriate to its assets, threats and obligations.
Applying Principles to a Basic Architecture
Consider a small online student-record system. A defensible architecture might include:
A public web interface separated from internal services.
An application service that validates input and enforces authorization.
A database inaccessible directly from the public network.
Staff authentication using multifactor authentication.
Separate student, registrar and system-administrator roles.
A database account for the application with only required permissions.
Centralized logs for authentication, record access and administrative changes.
Alerts for unusual access and repeated failures.
Encrypted connections and protected backups.
A tested incident and recovery procedure.
The architecture applies defense in depth through multiple layers, least privilege through restricted roles and service accounts, separation of duties through distinct administrative responsibilities, zero trust through explicit verification, and resilience through backups and recovery testing. Trust boundaries exist at the public interface, application service and database. Each boundary should validate input, authenticate requests where appropriate and record significant actions.
Worked Application: Illustrative Case Study
Background
A fictional college operates a cloud-based examination system. Lecturers upload assessments, students submit work, and administrators manage accounts. Initially, all staff share a broad “staff” role, the database is reachable from several networks, and backups are performed but not regularly restored.
Problem
An attacker obtains one lecturer’s password through phishing. The account can view student records, modify grades and access administrative reports. Because logs are incomplete, the college cannot easily determine which records were changed. A later ransomware incident affects both production data and the connected backup repository.
Analysis
The architecture contains excessive privilege, weak separation of duties, insufficient monitoring and a common failure path between production and backups. The organization has treated internal users as trusted and has not clearly defined trust boundaries. The risk is not limited to the initial account compromise; the account’s privileges enable unauthorized integrity and confidentiality impacts.
Approach and Solution
The college redesigns the system as follows:
Identity: staff use multifactor authentication, individual accounts and strong account-recovery procedures.
Least privilege: lecturers can manage only assigned courses; grade approval requires a separate role.
Separation of duties: a lecturer submits grades, while an authorized reviewer approves publication.
Zero trust: every application request is authenticated and authorized; device health and session risk influence access.
Segmentation: the database accepts connections only from the application service; administration uses a separate controlled path.
Defense in depth: web filtering, application validation, endpoint protection, centralized logging and anomaly alerts are added.
Resilience: encrypted, immutable and logically separated backups are introduced, with scheduled restoration tests.
Governance: access reviews occur each term, retention rules are documented, and incident reporting responsibilities are assigned.
Outcome
The redesigned system reduces the likely impact of a stolen lecturer credential, makes grade changes attributable, limits movement toward the database and provides a tested recovery route. No control eliminates risk, but the attack path is narrower and evidence is stronger.
Learning Points
The case demonstrates that security is an architectural property rather than a single authentication feature. Controls must address confidentiality, integrity and availability together. It also shows why recovery testing and governance are as important as preventive controls.
Challenges, Limitations and Trade-offs
Security principles can conflict or be difficult to implement.
Least privilege versus productivity: narrow permissions may delay legitimate work. Use role design, temporary elevation and timely review.
Monitoring versus privacy: logs may contain personal or sensitive information. Define purpose, retention, access and lawful processing.
Segmentation versus operational complexity: poorly planned segmentation can interrupt essential services. Map dependencies and test changes.
Zero trust versus usability: excessive prompts can encourage unsafe behavior. Use risk-based, adaptive controls.
Resilience versus cost: redundancy and testing require investment. Prioritize systems according to impact and recovery requirements.
Separation of duties versus staffing: small teams need compensating reviews and independent oversight.
Automation versus accountability: automated decisions should be explainable, auditable and subject to human escalation.
A principle is not a substitute for threat analysis. For example, encryption does not correct an overly permissive authorization policy, and multifactor authentication does not prevent an authorized insider from misusing access. Controls should be evaluated against realistic attack paths and failure modes.
Ethical, Legal and Governance Considerations
Security professionals have duties to protect people, respect privacy and avoid unnecessary harm. Access should be justified, proportionate and limited to an authorized purpose. Monitoring should not become indiscriminate surveillance. Personal data should be minimized, protected and retained only as required by policy and law.
Organizations should define accountability for system owners, data owners, administrators, suppliers and incident managers. Security decisions should be documented, reviewed and auditable. Regulatory requirements vary by jurisdiction and sector, but common obligations include protecting personal information, reporting certain incidents, maintaining records and managing third-party risk.
Vendors and cloud providers should be assessed for identity management, logging, encryption, data location, subcontractors, incident notification, service continuity and secure deletion. Shared-responsibility models must be understood clearly: outsourcing infrastructure does not outsource the organization’s legal and ethical accountability for its data.
Contemporary Developments and Best Practices
Modern environments combine cloud services, mobile devices, application programming interfaces, software supply chains, operational technology and artificial intelligence. These increase the importance of identity-centric controls, asset inventories, API authorization, software provenance and continuous monitoring.
AI systems introduce additional concerns, including sensitive training data, prompt injection, insecure tool use, model manipulation and unclear accountability. The same principles remain applicable: least privilege for tools and service accounts, explicit authorization, separation between development and production data, logging of significant actions and tested recovery. AI should not be granted broad autonomous access merely because it can produce useful outputs.
Good practice includes:
Maintain an accurate inventory of assets, identities, data and dependencies.
Classify information and assign accountable owners.
Make secure configurations the default.
Use individual identities and multifactor authentication for important access.
Review privileges regularly and remove stale accounts.
Segment high-value systems and protect trust boundaries.
Centralize relevant logs and protect them from alteration.
Test incident response, backups and recovery—not just documentation.
Manage vulnerabilities according to exploitability and business impact.
Include security requirements in procurement and software development.
Measure outcomes, investigate exceptions and improve continuously.
Chapter Summary
Security architecture translates principles into enforceable system arrangements. Defense in depth combines preventive, detective, corrective and recovery controls so that one failure does not expose the entire system. Least privilege and need to know restrict access by resource, operation, time and context. Separation of duties divides sensitive activities and uses compensating controls where staffing is limited.
Trust boundaries identify where data, commands and privileges cross environments with different assumptions. Zero trust requires explicit, continuous and context-aware verification rather than implicit trust based on network location. Secure-by-design and secure-by-default make security a life-cycle requirement, while resilience prepares systems to withstand disruption and recover within business-defined objectives.
Access-control models such as DAC, MAC, RBAC and ABAC provide different ways to express authorization. Governance frameworks organize risk management but do not replace analysis. Effective architecture combines technical controls with policy, trained people, privacy protection, accountability, monitoring and tested recovery. The central professional lesson is to assume that some controls will fail and design the system so that failures are limited, visible and recoverable.
Key Terms
Accountability: The ability to associate actions with responsible identities or processes.
ABAC: Access control based on attributes and policy conditions.
Availability: The property that authorized users can access systems and data when needed.
Defense in depth: Use of multiple, partially independent security layers.
Least privilege: Granting only the permissions required for an authorized task.
Need to know: Restricting information access to a legitimate requirement.
RBAC: Access control based on organizational or system roles.
Resilience: The ability to withstand, adapt to and recover from disruption.
RPO: Maximum acceptable data loss expressed as a period of time.
RTO: Maximum acceptable time to restore a service.
Secure-by-default: Initial configuration that starts in a reasonably protected state.
Secure-by-design: Integrating security requirements throughout the system life cycle.
Separation of duties: Dividing sensitive responsibilities among independent roles or actors.
Trust boundary: A division across which data, commands or privileges move between different trust assumptions.
Zero trust: An approach that verifies requests explicitly and does not grant implicit trust based on network location.
Confidentiality: Protection against unauthorized disclosure.
Integrity: Protection against unauthorized or inaccurate alteration.
Reference monitor: A mechanism intended to mediate access to protected resources.
Review Questions
Short Answer Questions
What is meant by defense in depth?
Define least privilege and give one example.
What is a trust boundary?
State the difference between RTO and RPO.
Why is zero trust different from traditional perimeter security?
Long Answer Questions
Explain how defense in depth, least privilege and separation of duties work together in a student-record system.
Compare RBAC and ABAC, including one advantage and one limitation of each.
Discuss how secure-by-design changes the stages of a system’s life cycle.
Explain the role of resilience planning in responding to ransomware.
Analyze the ethical and governance issues associated with centralized security monitoring.
Analytical / Application Questions
A small business allows every employee to access a shared file server using one account. Identify the trust-boundary, accountability and least-privilege weaknesses, and recommend a staged improvement plan.
Design a basic architecture for an online payment service using at least five principles from this chapter. Explain where controls should be placed and what each control achieves.
A cloud application has strong authentication but permits its application service account to read and delete every database table. Analyze the risks and propose controls addressing least privilege, separation of duties, monitoring and resilience.
Multiple Choice Questions with Answers
Question 1
Which principle requires multiple independent or partially independent controls so that one control failure does not expose the entire system?
A. Defense in depth
B. Need to know
C. Non-repudiation
D. Data minimization
Correct Answer: A. Defense in depth
Question 2
A service account can read customer orders but cannot modify accounts or delete records. Which principle is primarily illustrated?
A. Separation of duties
B. Least privilege
C. Deterrence
D. Availability
Correct Answer: B. Least privilege
Question 3
What is the main idea of zero trust?
A. All internal network traffic is trusted
B. Users never receive access to protected resources
C. Requests are explicitly verified rather than trusted because of location
D. Only perimeter firewalls are required
Correct Answer: C. Requests are explicitly verified rather than trusted because of location
Question 4
Which arrangement best demonstrates separation of duties?
A. One administrator creates and approves a payment
B. All employees use one shared account
C. A lecturer submits grades and an independent reviewer approves publication
D. A firewall blocks unsolicited Internet traffic
Correct Answer: C. A lecturer submits grades and an independent reviewer approves publication
Question 5
What does an RPO describe?
A. The maximum acceptable restoration time
B. The maximum acceptable amount of data loss measured in time
C. The number of administrators needed for recovery
D. The expected lifetime of a password
Correct Answer: B. The maximum acceptable amount of data loss measured in time
Question 6
Which control is most directly associated with secure-by-default design?
A. Enabling unnecessary services for convenience
B. Starting a system with unused interfaces disabled
C. Allowing all users administrative access initially
D. Removing all audit logs
Correct Answer: B. Starting a system with unused interfaces disabled
Question 7
Which access-control model assigns permissions primarily to job or system roles?
A. RBAC
B. MAC
C. DAC
D. ABAC
Correct Answer: A. RBAC
Question 8
Why should a database in a layered web architecture normally be inaccessible directly from the public network?
A. To eliminate the need for authentication
B. To create a trust boundary and reduce direct attack paths
C. To make backups unnecessary
D. To guarantee data availability during every outage
Correct Answer: B. To create a trust boundary and reduce direct attack paths
Question 9
Which statement about backups best reflects resilience practice?
A. A backup is reliable once it has been created
B. Backups should be tested through restoration and protected from the same compromise as production
C. Backups should use the same unrestricted credentials as production
D. Backups replace incident response planning
Correct Answer: B. Backups should be tested through restoration and protected from the same compromise as production
Question 10
Which objective is primarily concerned with preventing unauthorized alteration of information?