Security Principles, Models and Architecture

Introduction and Context

Information security is not achieved by a single product, control, or policy. It is an engineered property of an information system and the organization that operates it. Security architecture provides the structure through which security objectives are translated into mechanisms, processes, responsibilities, and assurance activities.

Modern enterprises operate across cloud platforms, mobile devices, application programming interfaces, operational technology, third-party services, and remote work environments. These environments contain many trust relationships and frequently changing dependencies. Consequently, security must be designed as a system of mutually reinforcing controls rather than as a perimeter around a supposedly trusted internal network.

This chapter examines the principles, formal models, and architectural ideas used to design secure systems. It connects foundational principles—such as least privilege, defense in depth, separation of duties, and secure defaults—with trust boundaries, security domains, reference monitors, access-control models, and enterprise security architecture.

Learning Objectives

After completing this chapter, the reader should be able to:

1. Explain the principal design principles used in secure systems.

2. Identify trust boundaries and security domains in complex architectures.

3. Describe the function and assurance requirements of a reference monitor.

4. Compare discretionary, mandatory, role-based, and attribute-based access control.

5. Apply formal access-control models to confidentiality and integrity problems.

6. Design layered controls using defense in depth and secure defaults.

7. Analyze an enterprise security architecture and identify weaknesses.

8. Evaluate governance, usability, privacy, and operational implications of security design decisions.

1. Foundational Security Principles

1.1 Security objectives and protection goals

Security architecture begins with a clear statement of what must be protected and from which threats. The traditional confidentiality, integrity, and availability triad remains useful:

• Confidentiality limits information disclosure to authorized subjects.
• Integrity protects information and system behavior from unauthorized or improper modification.
• Availability ensures that authorized users can obtain services and information when required.

Contemporary architectures also emphasize authenticity, accountability, privacy, resilience, and safety. Authenticity concerns whether an entity or message is genuine. Accountability connects actions to responsible identities through logging and evidence. Privacy concerns appropriate control over personal information, including collection, use, retention, and disclosure. Resilience concerns the ability to withstand, recover from, and adapt to disruption.

These objectives can conflict. Extensive logging may improve accountability but create privacy risks. Strong availability requirements may reduce the time available for security inspection. A practical architecture therefore makes risk-based trade-offs rather than attempting to maximize one property independently.

1.2 Least privilege

Least privilege requires that a subject receive only the permissions necessary to perform an authorized task, for only as long as necessary. The subject may be a user, process, service account, device, or application component.

Least privilege has several dimensions:

• Functional scope: access only to required operations.
• Data scope: access only to required records or fields.
• Time scope: access only during the necessary period.
• Privilege level: ordinary users should not operate with administrative authority.
• Execution context: a process should not inherit unnecessary privileges from its parent.

Least privilege reduces the potential impact of credential theft, software compromise, insider misuse, and programming errors. It is not equivalent to simply creating many roles. Excessive role complexity can cause privilege accumulation and make authorization difficult to review.

Practical techniques include just-in-time administration, time-limited tokens, scoped cloud permissions, separate administrative accounts, service identities, database views, and periodic entitlement reviews. Least privilege must be balanced with operational recoverability: emergency personnel need a controlled break-glass procedure, but such access should be strongly authenticated, logged, approved where possible, and reviewed afterward.

1.3 Separation of duties

Separation of duties divides a sensitive activity among two or more people, roles, or systems so that no single party can complete the activity improperly without detection or collusion. For example, one employee may create a supplier, another approve payment, and an automated system execute the transfer.

Separation of duties is especially important for financial transactions, software deployment, security administration, cryptographic key management, and evidence handling. It can be:

• Static: incompatible roles cannot be assigned to the same subject.
• Dynamic: a subject may hold several roles but cannot activate conflicting roles in one session.
• Sequential: different stages of a workflow require different actors.

The principle is not absolute. Small organizations may lack sufficient personnel for complete separation. Compensating controls can include independent review, automated approvals, immutable audit records, dual control, and retrospective reconciliation.

1.4 Defense in depth

Defense in depth uses multiple, independent or partially independent safeguards so that failure of one control does not automatically result in compromise. Layers may include secure design, identity assurance, network segmentation, endpoint protection, application validation, encryption, monitoring, backup, and incident response.

Defense in depth is not merely the purchase of multiple security products. If all controls depend on the same identity provider, administrator, network, or configuration process, they may fail together. Architectural diversity and independence matter. For example, an application firewall and an application authorization defect may share the same assumptions and therefore provide less independence than expected.

A layered design should address different stages of an attack: prevention, detection, response, recovery, and learning. It should also consider physical, technical, administrative, and procedural controls.

1.5 Secure defaults and fail-safe behavior

Secure defaults mean that a system begins in the least permissive safe state. Examples include denying inbound network access unless explicitly allowed, disabling unused services, requiring authentication before access, and protecting logs from ordinary administrators.

A related idea is fail-safe failure: when a control fails, the system should fail in a state that does not unnecessarily expose protected assets. However, availability-critical systems may need carefully designed fail-operational behavior. A hospital device, for example, cannot always deny every function when authentication infrastructure is unavailable. The appropriate design may provide a restricted emergency mode with local safeguards and strong post-event review.

Secure defaults should be tested during installation, upgrade, recovery, and migration. A system that is secure when first deployed but becomes permissive during maintenance does not have a reliable secure-default property.

1.6 Complete mediation

Complete mediation requires that every access to a protected object be checked against the applicable authorization policy. Checking access only when a file is opened is insufficient if later operations can bypass the policy through cached handles, direct memory access, alternate APIs, or privileged services.

Complete mediation must be implemented efficiently enough to remain practical. Caching authorization decisions can improve performance, but cache invalidation, policy changes, revocation, and object identity must be handled carefully. A secure cache needs a defined lifetime and invalidation strategy.

1.7 Economy of mechanism and minimization

Economy of mechanism favors small, simple, and understandable security mechanisms. Complexity increases the number of possible states, hidden dependencies, configuration errors, and testing difficulties. Security-critical code should minimize unnecessary functionality and use well-understood interfaces.

Related principles include minimizing attack surface, reducing unnecessary data collection, avoiding shared accounts, and limiting the number of privileged components. Simplicity does not mean lack of capability; it means that capability is organized so that security properties can be reasoned about and tested.

1.8 Open design and psychological acceptability

The security of a mechanism should not depend on secrecy of its design. Open design permits independent review, interoperability, and improved assurance. This does not require public disclosure of every operational detail, but it rejects the assumption that an obscure algorithm is secure merely because attackers cannot initially inspect it.

Psychological acceptability means that security controls should fit users’ legitimate workflows. If controls are excessively difficult, users may bypass them, share credentials, store data insecurely, or develop unsafe workarounds. Usability is therefore a security concern, not a competing luxury.

2. Trust Boundaries and Security Domains

2.1 Trust and trust boundaries

Trust is a decision to rely on a subject, component, or environment to behave according to specified assumptions. Trust is not the same as identity. A service may be authenticated but still not trusted for every operation.

A trust boundary is a point at which data, control, privilege, or assumptions cross from one security context to another. Examples include:

• a public network to an internal service;
• a browser to a web application;
• an application to a database;
• a cloud tenant to a provider-managed service;
• a standard user process to an operating-system kernel;
• an enterprise to a supplier API.

At each boundary, the architecture should identify the crossing data, validate its format and meaning, authenticate the communicating parties, authorize the requested operation, protect confidentiality and integrity, and record significant events.

Trust boundaries are often missed when systems are drawn only by network location. A private subnet is not automatically trusted, and a cloud service may be external even when it appears in the same administrative console. Identity, privilege, data sensitivity, and operational control are more informative than topology alone.

2.2 Security domains

A security domain is a set of subjects, objects, and rules governed by a coherent security policy. Domains may be organized by business function, sensitivity, administrative authority, regulatory requirement, or technical platform.

Examples include a payment-card environment, a research-data domain, a corporate collaboration domain, and a public web domain. Domain boundaries can be enforced through network segmentation, separate identity stores, application authorization, encryption keys, administrative separation, and data-loss prevention controls.

A domain is not necessarily a physical network. A single cloud account may contain several logical domains, while a single business process may span multiple providers. Domain design should answer: who administers the domain, what policy applies, which identities are recognized, which assets are included, and how transfers across the boundary are approved and monitored?

2.3 Zero trust as an architectural interpretation

Zero trust architectures avoid granting broad implicit trust based on network location. They continuously evaluate identity, device state, requested resource, context, and policy. The expression “never trust, always verify” is a useful slogan, but a practical architecture still needs calibrated trust decisions; it cannot literally re-authenticate every operation without regard to risk and usability.

Zero trust commonly uses strong identity, device posture assessment, micro-segmentation, application-level authorization, encrypted communication, telemetry, and policy enforcement points. Its value is greatest where users, devices, workloads, and data are distributed. Its limitations include implementation complexity, dependence on accurate policy and telemetry, and the risk of creating excessive surveillance or authentication friction.

3. Reference Monitors and Trusted Computing Bases

3.1 The reference monitor concept

A reference monitor is an abstract mechanism that mediates all accesses by subjects to objects according to a defined authorization policy. It is traditionally characterized by three properties:

1. Complete mediation: every relevant access is checked.

2. Tamper resistance: the mechanism cannot be modified by unauthorized parties.

3. Verifiability: the mechanism is sufficiently small and structured that its correctness can be independently assessed.

In an operating system, the reference monitor may be realized through kernel access checks, memory protection, process isolation, and protected system calls. In an application, it may be implemented by an authorization service or policy enforcement point. In a distributed system, it is usually a collection of coordinated components rather than one physical object.

A reference monitor should not be confused with an audit log. Logging records actions; mediation decides whether an action is permitted. Nor is an identity provider alone a reference monitor: authentication establishes identity or an identity claim, while authorization decides what that identity may do.

3.2 Trusted computing base

The trusted computing base (TCB) consists of the hardware, firmware, software, configuration, and procedures that must function correctly for a security property to hold. A smaller TCB is generally easier to analyze and protect, although reducing it may increase integration complexity.

Examples include a hypervisor, a secure boot chain, kernel components, cryptographic libraries, identity services, policy engines, and privileged administrators. TCB analysis is valuable because a vulnerability in a noncritical application may be contained, whereas a vulnerability in a policy enforcement component can undermine many applications.

Assurance requires more than design claims. It may involve threat modeling, code review, penetration testing, formal verification of selected components, configuration assessment, supply-chain analysis, and operational monitoring.

4. Access-Control Models

Access control can be described using subjects, objects, operations, and authorization rules. A subject requests an operation on an object; a policy decision determines whether the request is allowed. The decision may depend on identity, role, attributes, context, object classification, and obligations such as logging or approval.

4.1 Discretionary access control

In discretionary access control (DAC), the owner of an object or another authorized subject can determine who receives access. Traditional file permissions and access-control lists are common examples.

DAC is flexible and convenient, but permissions can propagate through copying, delegation, and ownership changes. A user who is authorized to read a document may unintentionally share it. DAC is therefore often supplemented by data classification, information-flow controls, and administrative policies.

4.2 Mandatory access control

Mandatory access control (MAC) applies centrally enforced rules based on classifications, labels, or other system-wide policy. Subjects and objects may receive labels such as Public, Confidential, or Restricted, and a formal policy governs permitted information flows.

MAC reduces the ability of individual users to override policy and is useful for military, government, industrial, and high-assurance environments. It can be difficult to administer when information requires nuanced business sharing or when labels are inaccurate.

4.3 Role-based access control

Role-based access control (RBAC) assigns permissions to roles and roles to users or other subjects. Typical roles include claims processor, clinician, developer, and security auditor. RBAC supports administration through job functions and makes separation of duties expressible as role constraints.

RBAC can become difficult when roles are created for every exceptional circumstance. Role engineering should begin with stable business responsibilities, use approval and review workflows, and distinguish eligibility to activate a role from automatic activation.

4.4 Attribute-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, object, action, and environment. A policy might permit a physician to view records of assigned patients during an active treatment relationship, from a managed device, subject to emergency procedures.

ABAC supports fine-grained and contextual decisions but depends on trustworthy, current attributes. A stale employment status, incorrect device posture, or ambiguous data classification can produce incorrect decisions. Policies should be written clearly, tested with representative and adversarial cases, and accompanied by explainable decision records.

4.5 Capability-based access

A capability is an unforgeable or sufficiently protected token that conveys authority to perform specified operations on an object. Capabilities support delegation and can provide narrow, object-specific permissions. Their risks include token theft, excessive lifetime, unintended forwarding, and difficulty of revocation. Short-lived, audience-restricted capabilities and explicit delegation chains reduce these risks.

4.6 Policy enforcement and decision architecture

A common policy architecture separates:

• Policy Administration Point (PAP): creates or manages policies.
• Policy Decision Point (PDP): evaluates a request.
• Policy Enforcement Point (PEP): permits or blocks the operation.
• Policy Information Point (PIP): supplies attributes and context.

This separation can improve consistency, but it introduces availability and latency dependencies. Fail-open behavior may create security exposure; fail-closed behavior may interrupt critical services. Each application should define a risk-appropriate decision for policy service failure.

5. Formal Security Models

Formal models provide disciplined ways to reason about security properties. They do not automatically make a system secure because real systems contain imperfect labels, covert channels, configuration errors, and operational exceptions.

5.1 Bell–LaPadula model

The Bell–LaPadula model addresses confidentiality using ordered security levels. Its classic properties are:

• Simple security property (“no read up”): a subject at level L cannot read an object at a higher level.
• Star-property (“no write down”): a subject at level L cannot write information to a lower level.

These rules reduce unauthorized disclosure from higher classifications to lower classifications. They do not guarantee integrity, availability, correct labeling, or protection against covert channels. In practical systems, trusted subjects and controlled declassification may be required.

5.2 Biba model

The Biba model addresses integrity and reverses the direction of the principal information-flow restrictions:

• No read down: a high-integrity subject should not read from a lower-integrity source if doing so could contaminate its decisions.
• No write up: a lower-integrity subject should not modify a higher-integrity object.

Integrity models vary in their exact rules and interpretation. The key idea is to prevent untrusted information from corrupting trusted data or processes. Biba does not itself address confidentiality.

5.3 Clark–Wilson model

The Clark–Wilson model focuses on commercial integrity. It emphasizes well-formed transactions, certified transformation procedures, separation of duties, and auditability. Users do not directly manipulate constrained data; they invoke approved procedures that preserve integrity rules.

This model maps well to accounting systems, payment processing, and enterprise workflows. It recognizes that integrity is often a property of valid business processes rather than merely a property of information labels.

5.4 Brewer–Nash and conflict-of-interest controls

The Brewer–Nash model, commonly associated with the Chinese Wall concept, restricts access to prevent conflicts of interest. A consultant who has accessed confidential information belonging to one competing client may be prevented from accessing another competitor’s information.

The model illustrates that authorization may depend on a subject’s history, not only on current identity and object attributes. Such policies are relevant to professional services, legal practice, investment banking, and consulting.

6. Enterprise Security Architecture

6.1 Architecture as a system of governance and design

Enterprise security architecture aligns business objectives, risk appetite, information assets, technology, people, and controls. It should describe both the desired state and the transition path from current weaknesses.

A useful architecture process includes:

1. Identify business services, assets, data flows, dependencies, and regulatory obligations.

2. Establish threat assumptions, risk criteria, and security objectives.

3. Define trust boundaries, domains, identities, and ownership.

4. Select control patterns and reference architectures.

5. Assign controls to people, processes, and technology.

6. Validate through threat modeling, testing, and assurance activities.

7. Monitor performance, incidents, exceptions, and architectural drift.

Architecture frameworks can provide viewpoints, principles, and governance structures, but no framework replaces context-specific analysis.

6.2 Layered enterprise pattern

A contemporary enterprise pattern may include:

• governance, risk, compliance, and security policy;
• centralized identity, multifactor authentication, and privileged access management;
• endpoint and workload protection;
• segmented networks and encrypted service communication;
• secure software development and supply-chain controls;
• application and data authorization;
• centralized monitoring, detection, and response;
• resilient backup, recovery, and crisis management.

The design should avoid concentrating all authority in one account or service. Administrative planes, production planes, and user access planes should be separated. Critical actions should require stronger authentication and enhanced monitoring.

6.3 Data-centric architecture

Network location is an increasingly weak proxy for protection. Data-centric architecture classifies information, identifies custodians, applies access rules at the data and application layers, encrypts data in transit and at rest, and monitors use. Classification must be operationally meaningful; too many categories produce inconsistency, while vague categories provide little control.

Key management is part of the security architecture. Encryption with poorly protected or permanently accessible keys offers limited assurance. Key separation, rotation, access logging, recovery procedures, and independent administrative control should reflect data sensitivity.

6.4 Security metrics and assurance

Architecture requires evidence. Useful measures may include privileged-access review completion, mean time to revoke departed users, percentage of critical assets with tested recovery, vulnerability remediation age, policy exception volume, and detection coverage for priority threats.

Metrics should be interpreted carefully. A high number of blocked attacks may indicate effective prevention, increased attack activity, or merely noisy detection. Compliance measures demonstrate that a process occurred; they do not by themselves demonstrate that risk is controlled.

7. Worked Application: A University Research-Data Platform

This illustrative case concerns a university that operates a platform containing identifiable health-study data, public research outputs, student records, and analytical services.

Background and problem

Researchers require collaboration with external institutions. Students need limited access to teaching datasets. Data administrators maintain the platform, while institutional auditors require evidence of access. The previous design placed all users on a shared virtual network and granted broad database permissions. A compromised researcher account could potentially access unrelated studies.

Analysis

The architecture contains several trust boundaries: external collaborators to the university identity service, users to the research portal, portal services to databases, and the university to cloud analytics services. The data has different sensitivity levels, and the shared network does not represent a single security domain. The key risks are excessive privilege, cross-study disclosure, weak service-to-service authorization, and inadequate separation between administration and research access.

Approach

The university adopts the following controls:

1. Domain separation: public data, controlled research data, and identifiable health data are placed in distinct logical domains with separate policies and encryption keys.

2. Identity assurance: multifactor authentication is required for staff and collaborators; privileged administrators use separate accounts and just-in-time elevation.

3. ABAC and RBAC: study membership, role, data classification, device status, and purpose of use are evaluated. A researcher may access only approved studies and only permitted fields.

4. Reference-monitor functions: the portal is the enforcement point; a central policy service evaluates requests; database accounts do not grant researchers unrestricted direct access.

5. Separation of duties: data custodians approve access, researchers use data, and auditors review access evidence. No one person can approve and implement their own request without oversight.

6. Defense in depth: encryption, segmented services, endpoint controls, query monitoring, anomaly detection, tested backups, and incident response are combined.

7. Secure defaults: new studies are private, new accounts have no data access, external sharing is disabled, and emergency access expires automatically.

Outcome

The design reduces the consequences of a compromised account and creates auditable, purpose-specific access. It also introduces operational costs: policy administration, attribute maintenance, latency from centralized decisions, and the need to manage emergency access. These costs are addressed through standardized study templates, automated lifecycle workflows, clear data ownership, and periodic policy testing.

Learning points

The case demonstrates that defense in depth is strongest when layers address different failure modes. It also shows that network segmentation alone is insufficient, that reference-monitor behavior must exist at the application boundary, and that governance and data ownership are essential to technical enforcement.

8. Challenges, Ethics, and Contemporary Developments

8.1 Architectural limitations

No model captures every real-world concern. Formal confidentiality models may ignore availability and usability. RBAC can suffer from role explosion. ABAC can become opaque if policies are excessively complex. Centralized policy services can become critical dependencies. Micro-segmentation can increase visibility and control but may create operational fragility if service dependencies are poorly understood.

Security controls also create residual risk. A strong authentication system may be undermined by account recovery. Encryption may be defeated by endpoint compromise. Monitoring may detect misuse only after damage occurs. Architects should document assumptions, dependencies, exceptions, and residual risks rather than presenting controls as guarantees.

8.2 Ethics, privacy, and governance

Security architecture affects human rights, autonomy, and fairness. Continuous monitoring can become disproportionate surveillance. Automated authorization may encode inaccurate or discriminatory attributes. Security teams should apply purpose limitation, data minimization, transparency, retention limits, access review, and due process for denied access.

Governance should establish ownership, approval authority, exception handling, independent review, incident responsibilities, and evidence retention. Regulatory requirements should be treated as constraints and accountability obligations, not as substitutes for risk analysis. Privacy and security should be designed together because poorly protected personal data creates both security and privacy harms.

8.3 Cloud, software supply chains, and AI

Cloud environments distribute responsibility among providers, customers, and third parties. Security architecture must define the shared-responsibility boundary, verify tenant isolation assumptions, protect management interfaces, and control identities used by automation.

Software supply-chain security requires dependency inventories, signed artifacts where appropriate, provenance, build isolation, vulnerability response, and review of privileged pipeline actions. A secure application can still be compromised through a malicious or vulnerable dependency.

Artificial intelligence introduces additional architectural concerns: sensitive training data, model access, prompt injection, unauthorized tool use, data leakage, and overreliance on automated decisions. AI systems should operate with least privilege, separate untrusted input from instructions, constrain tool permissions, log important decisions, and retain human oversight for high-impact actions. AI does not replace a reference monitor; model output should not be treated as authorization without deterministic policy enforcement where authorization is critical.

Best-Practice Checklist

• Define assets, security objectives, owners, and threat assumptions.
• Map trust boundaries and data flows rather than relying only on network diagrams.
• Start users, services, and systems with no unnecessary privilege.
• Use separate administrative identities and just-in-time elevation.
• Enforce authorization at every relevant access path.
• Combine preventive, detective, responsive, and recovery controls.
• Keep security-critical mechanisms small, reviewable, and tamper-resistant.
• Apply the access-control model appropriate to the business problem.
• Test both normal and exceptional workflows, including emergency access.
• Design for policy-service failure, credential compromise, and configuration drift.
• Protect privacy and make monitoring proportionate and accountable.
• Measure actual control effectiveness, not only compliance activity.

Chapter Summary

Security principles provide the reasoning foundation for secure architecture. Least privilege limits authority; separation of duties prevents unilateral misuse; defense in depth combines controls across prevention, detection, response, and recovery; secure defaults reduce exposure caused by omission; complete mediation ensures that access decisions are applied consistently; and economy of mechanism supports assurance.

Trust boundaries identify where data, authority, and assumptions cross contexts. Security domains organize subjects, objects, and policies under coherent governance. A reference monitor mediates access and must provide complete mediation, tamper resistance, and verifiability. The trusted computing base includes all components on which a security property depends.

DAC, MAC, RBAC, ABAC, and capability-based approaches offer different balances of flexibility, central control, context sensitivity, and administrative complexity. Formal models such as Bell–LaPadula, Biba, Clark–Wilson, and Brewer–Nash clarify confidentiality, integrity, transaction, and conflict-of-interest requirements, but must be complemented by operational analysis.

Enterprise security architecture aligns business requirements, risk, identity, data, technology, governance, monitoring, and resilience. Effective architecture is risk-based, evidence-driven, privacy-aware, and adaptable to cloud services, supply-chain dependencies, and AI-enabled systems.

Key Terms

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

Separation of duties: Dividing sensitive responsibilities to prevent unilateral misuse.

Defense in depth: Using multiple complementary layers of protection.

Secure default: An initial configuration that provides the least permissive safe behavior.

Complete mediation: Checking every relevant access against authorization policy.

Trust boundary: A point where data, control, or assumptions cross security contexts.

Security domain: A set of subjects, objects, and rules governed by a coherent policy.

Reference monitor: A mechanism that mediates subject access to objects.

Trusted computing base: Components that must function correctly for a security property to hold.

Discretionary access control: Access control in which owners can delegate permissions.

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

Role-based access control: Access control using roles associated with permissions.

Attribute-based access control: Access control based on subject, object, action, and context attributes.

Capability: A protected token conveying authority over specified operations.

Bell–LaPadula model: A confidentiality model using restrictions such as no read up and no write down.

Biba model: An integrity model restricting contamination of higher-integrity information.

Clark–Wilson model: An integrity model based on valid transactions, separation of duties, and auditability.

Policy Enforcement Point: A component that permits or blocks a requested operation.

Zero trust: An architecture that avoids implicit trust based solely on network location.

Residual risk: Risk remaining after controls have been implemented.

Review Questions

Short Answer Questions

1. What are the three principal properties of a reference monitor?

2. Distinguish least privilege from separation of duties.

3. What is a trust boundary? Give two examples.

4. How does ABAC differ from RBAC?

5. Why is complete mediation important?

Long Answer Questions

1. Explain defense in depth and evaluate the importance of independence among security layers.

2. Compare DAC, MAC, RBAC, and ABAC, including suitable enterprise applications and limitations.

3. Explain the Bell–LaPadula, Biba, and Clark–Wilson models and the security properties each emphasizes.

4. Discuss the role of the trusted computing base in security assurance.

5. Develop an enterprise security architecture for a cloud-based organization using the principles in this chapter.

Analytical / Application Questions

1. A developer has permission to deploy code, approve production changes, and administer the deployment pipeline. Identify the architectural weaknesses and propose controls based on least privilege and separation of duties.

2. A hospital must maintain limited clinical operation when its central identity service is unavailable. Design a fail-safe emergency-access approach that balances availability, accountability, and least privilege.

3. Analyze a university research platform as a set of security domains and trust boundaries. Select an access-control model and justify how defense in depth would address a compromised researcher account.

Multiple Choice Questions with Answers

Question 1

Which principle requires that every access to a protected object be checked against authorization policy?

A. Complete mediation

B. Open design

C. Separation of duties

D. Psychological acceptability

Correct Answer: A. Complete mediation

Question 2

Which access-control model assigns permissions to roles and then assigns roles to users?

A. Mandatory access control

B. Role-based access control

C. Capability-based access control

D. Discretionary access control

Correct Answer: B. Role-based access control

Question 3

What is the primary purpose of separation of duties?

A. To make all users administrators

B. To prevent one party from completing a sensitive process improperly alone

C. To eliminate the need for audit logs

D. To ensure every system uses identical permissions

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

Question 4

Which Bell–LaPadula property is associated with preventing disclosure to lower classifications?

A. No read up

B. No write down

C. No read down

D. No write up

Correct Answer: B. No write down

Question 5

Which component makes the allow-or-deny decision in a policy decision architecture?

A. Policy Information Point

B. Policy Administration Point

C. Policy Decision Point

D. Policy Enforcement Point

Correct Answer: C. Policy Decision Point

Question 6

A system starts with all inbound network connections blocked and enables only explicitly approved services. This is an example of:

A. Secure defaults

B. Conflict-of-interest control

C. Discretionary ownership

D. Data contamination

Correct Answer: A. Secure defaults

Question 7

Which model is especially concerned with well-formed transactions and separation of duties in commercial systems?

A. Biba

B. Bell–LaPadula

C. Clark–Wilson

D. Brewer–Nash

Correct Answer: C. Clark–Wilson

Question 8

Which statement best describes a trust boundary?

A. A location where only physical security controls are used

B. A point where data, privilege, or assumptions cross between security contexts

C. A backup copy of a security policy

D. A list of all encrypted files

Correct Answer: B. A point where data, privilege, or assumptions cross between security contexts

Question 9

Why can excessive role creation create a security problem in RBAC?

A. It prevents authentication entirely

B. It can cause role explosion and make permissions difficult to review

C. It removes all business context from authorization

D. It guarantees that every user has administrator access

Correct Answer: B. It can cause role explosion and make permissions difficult to review

Question 10

Which statement about a reference monitor is correct?

A. It only records events after access occurs

B. It mediates access and should be tamper-resistant and verifiable

C. It is identical to an identity provider

D. It eliminates the need for security policies

Correct Answer: B. It mediates access and should be tamper-resistant and verifiable