10. Protection, Security, Privacy, and Trusted Computing

Introduction and Context

An operating system is not merely a resource manager. It is also the principal enforcement point for deciding who may use a resource, what operations may be performed, under which conditions, and how violations are detected and investigated. Protection traditionally concerns the controlled use of system resources by processes and users. Security extends this concern to deliberate attacks, unauthorized disclosure, alteration, destruction, and disruption. Privacy addresses the legitimate control and responsible use of information about individuals. Trusted computing concerns the mechanisms by which a system can provide credible evidence that its software and execution environment have not been improperly altered.

These concerns are inseparable in contemporary systems. A database server may enforce file permissions correctly but still expose personal information through excessive logging. A secure application may be undermined by a compromised kernel. A device may authenticate a user successfully while booting an untrusted operating system image. Conversely, strong cryptographic controls may become ineffective when administrators grant broad privileges for convenience. Operating-system security therefore requires a layered and strategic view that combines technical mechanisms, organizational policies, human decisions, and governance.

The chapter examines access-control models, capabilities, authentication, least privilege, sandboxing, secure boot, trusted execution, kernel attack surfaces, malware defenses, auditing, privacy, patching, and confidential computing. The objective is not to treat these as isolated features, but to understand how they work together and where their assumptions and limitations lie.

Learning Objectives

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

1. Distinguish protection, security, privacy, trust, and assurance.

2. Explain access-control models based on permissions, roles, attributes, and capabilities.

3. Evaluate authentication mechanisms and the principle of least privilege.

4. Analyze sandboxing, isolation, trusted boot, trusted execution, and kernel attack surfaces.

5. Explain the role of malware defenses, auditing, patch management, and privacy engineering.

6. Assess confidential-computing designs and their practical limitations.

7. Select suitable controls for organizational and technical scenarios.

8. Identify ethical, governance, and professional responsibilities in operating-system security.

Protection as Controlled Resource Use

Protection is the operating system’s internal discipline for controlling access to objects such as files, memory regions, devices, processes, sockets, and interprocess communication channels. A subject, usually a process acting on behalf of a user or service, requests an operation on an object. The operating system must determine whether that operation is permitted.

A protection system can be described using three elements: subjects, objects, and rights. A right is an authorized operation, such as read, write, execute, append, delete, signal, or administer. The access matrix model represents subjects as rows, objects as columns, and rights as entries. Although a complete matrix is rarely stored directly, it provides a useful conceptual foundation. Access-control lists store the permissions associated with each object, whereas capability lists store the objects and rights available to each subject.

Traditional discretionary access control allows an owner or administrator to decide how an object is shared. It is flexible, but a user who controls a file may accidentally or deliberately grant access to another user. Mandatory access control associates subjects and objects with security labels and applies a system-wide policy. In a classified-information model, for example, a subject’s clearance and an object’s classification determine whether access is allowed. Discretionary and mandatory controls may coexist.

Role-based access control, or RBAC, grants permissions to roles rather than directly to individual users. A person may be assigned roles such as payroll officer, database auditor, or system operator. RBAC simplifies administration and supports separation of duties, but poorly designed roles can accumulate excessive permissions. Attribute-based access control, or ABAC, evaluates attributes of the subject, object, action, and environment. A policy may allow a physician to read a patient record only when the physician is assigned to the patient and the request originates from an approved device during working hours. ABAC provides expressive, contextual decisions but requires reliable attributes, policy management, and monitoring.

Identity, Authentication, and Authorization

Identity establishes an asserted identity; authentication provides evidence supporting that assertion; authorization determines what the authenticated identity may do. Confusing these stages leads to weak designs. A password identifies an account only when it is verified, and successful authentication does not imply unrestricted authorization.

Authentication factors are commonly grouped as something the user knows, has, or is. Passwords and personal identification numbers are knowledge factors. Hardware security keys, smart cards, and device-held credentials are possession factors. Biometrics are inherence factors. Multi-factor authentication combines independent factors, reducing the effect of a stolen password. However, two passwords do not constitute two independent factors, and a second factor can still be attacked through phishing, session theft, or social engineering.

Operating systems support authentication through mechanisms such as password databases, pluggable authentication frameworks, smart-card services, biometric interfaces, federated identity protocols, and hardware-backed credentials. Passwords should not be stored in plaintext. Salted, computationally expensive password hashing makes large-scale guessing more difficult, although it cannot compensate for weak passwords or compromised login endpoints.

Authorization is evaluated after authentication and should be checked at every security boundary. A service must not assume that a request is safe merely because it originated from an authenticated application. Reference monitors—small, tamper-resistant mechanisms that mediate all relevant access—provide the conceptual basis for reliable enforcement. The reference-monitor idea requires complete mediation, resistance to unauthorized modification, and verifiability.

Least Privilege and Capability-Oriented Design

The principle of least privilege states that a subject should receive only the permissions necessary for its current task, for no longer than necessary. Least privilege reduces the damage caused by software defects, credential theft, insider misuse, and malware. It also limits accidental changes and simplifies forensic analysis.

Privilege should be minimized in several dimensions. A service may need only read access rather than read-write access; it may need access to one directory rather than the entire file system; and it may require administrative authority only during a short initialization phase. Privilege separation divides a complex service into components, placing sensitive operations in a small privileged component and routine processing in less privileged components. Privilege dropping allows a process to begin with authority needed for setup and then relinquish it.

Capabilities provide an alternative way to represent authority. A capability is an unforgeable token that refers to an object and specifies permitted operations. Possession of the capability conveys authority, so it must be protected from copying, leakage, and confused-deputy misuse. Capability-based systems can make authority explicit and support fine-grained delegation. Modern operating systems also use capability-like mechanisms, including restricted handles, sandbox profiles, object references, and service-specific tokens, even when the entire operating system is not capability-based.

A confused-deputy problem occurs when a more privileged component is tricked into using its authority on behalf of a less privileged requester. Explicit capabilities and careful argument validation reduce this risk. Least privilege is not achieved by merely creating many user accounts; it requires mapping actual operations to narrowly scoped authority.

Isolation, Sandboxing, and Virtualization

Isolation limits the effects of a process or user on other processes and system resources. Traditional process isolation uses separate address spaces, privilege levels, protected system calls, and controlled interprocess communication. Stronger forms include containers, virtual machines, language-based sandboxes, application profiles, and microkernel-based service separation.

A sandbox restricts what code can do even if the code is untrusted or compromised. Restrictions may cover file paths, system calls, network destinations, devices, process creation, and resource consumption. Sandboxing is particularly useful for web browsers, document viewers, mobile applications, plugins, and build systems. It is not an absolute guarantee: vulnerabilities in the sandbox mechanism, kernel, hypervisor, or hardware may permit escape.

Containers generally share the host kernel while isolating processes, namespaces, users, and resource limits. They are efficient but inherit risks from the shared kernel. Virtual machines place an additional hypervisor boundary between guest and host, although hypervisors themselves have attack surfaces. A security decision should therefore consider not only the apparent boundary but also its implementation, configuration, update process, and failure behavior.

Secure Boot and the Chain of Trust

Secure boot seeks to prevent an unauthorized or modified operating-system component from executing during startup. A hardware-rooted key or measurement mechanism verifies an initial boot component, which then verifies the next component. This creates a chain of trust extending from firmware through the bootloader, kernel, and possibly system services.

In a verification-based design, a component is executed only if its signature is accepted under an authorized key. In a measurement-based design, hashes of components are recorded in protected hardware or firmware structures so that later software or a remote verifier can assess what was loaded. Verification prevents some unauthorized execution; measurement provides evidence about system state. They are related but not identical.

Secure boot does not prove that an authorized component is free from vulnerabilities, nor does it ensure that a running application behaves correctly. Key management is central: keys must be protected, revocation must be possible, recovery must be planned, and update procedures must not create an easy bypass. Organizations must also address the governance question of who controls the trust anchors and how legitimate alternative operating systems are supported.

Trusted execution environments, or TEEs, attempt to protect selected code and data from other software, including parts of the operating system. Hardware mechanisms isolate an enclave or secure world and may support attestation, through which a remote party receives evidence about the code running inside the protected environment. TEEs can help protect cryptographic keys and sensitive computation, but their security depends on processor implementation, enclave software, side-channel resistance, attestation infrastructure, and correct application design.

Kernel Attack Surfaces and Malware Defense

The kernel is highly privileged and therefore a valuable target. Its attack surface includes system calls, device drivers, file systems, networking stacks, memory management, module loading, debugging interfaces, and interactions with firmware and hardware. Drivers are especially significant because they often combine complex code with privileged execution. Reducing attack surface involves removing unnecessary components, restricting module loading, validating inputs, using memory-safe techniques where feasible, and separating services from the kernel.

Modern defenses include address-space layout randomization, non-executable memory, control-flow integrity, stack protection, privilege separation, hardware virtualization, secure configuration, and exploit mitigations. These mechanisms raise the cost of exploitation but do not eliminate software defects. Defense in depth is therefore essential.

Malware defense begins with prevention through secure defaults, application control, sandboxing, code signing, and least privilege. Detection may use signatures, behavioral analysis, anomaly detection, endpoint telemetry, and integrity monitoring. Response involves isolation, evidence preservation, eradication, recovery, and lessons learned. Artificial-intelligence and machine-learning techniques can assist in identifying unusual behavior, but they can produce false positives, be evaded by adversaries, and create privacy concerns when extensive user activity is collected.

A secure operating system must also defend against persistence. Malware may attempt to modify startup services, scheduled tasks, kernel modules, firmware, user profiles, or boot components. Integrity measurements, protected logs, secure update mechanisms, and periodic verification help detect such changes.

Auditing, Accountability, and Incident Response

Auditing records security-relevant events such as authentication attempts, privilege changes, policy decisions, process creation, sensitive-file access, configuration changes, and software installation. Accountability requires that actions can be associated with responsible subjects and that records are trustworthy enough for investigation.

Useful audit design balances completeness, interpretability, cost, and privacy. Logs should include accurate timestamps, event identity, relevant subject and object, result, and source context. Time synchronization is important when correlating events across systems. Logs should be protected against tampering, access should be restricted, retention should reflect legal and operational needs, and sensitive fields should not be collected unnecessarily.

Auditing is not equivalent to surveillance. Excessive collection can expose personal information and create a secondary target. Organizations should define purposes, retention periods, access rules, and review responsibilities. Security information and event-management systems can correlate operating-system events with network, identity, and application data, but automation must be accompanied by human validation.

An incident-response process typically includes preparation, detection and analysis, containment, eradication, recovery, and post-incident improvement. The operating system contributes forensic artifacts such as logs, process information, memory state, file metadata, and persistence mechanisms. Investigators must preserve integrity and chain of custody while respecting privacy and legal constraints.

Privacy as a System Property

Privacy is not simply secrecy. It includes appropriate collection, use, disclosure, retention, and deletion of information. Operating systems process identifiers, location data, telemetry, credentials, communications, health information, and behavioral traces. Even data that appears harmless may become sensitive when combined with other sources.

Privacy-by-design principles include data minimization, purpose limitation, transparency, user control, access and correction mechanisms, retention limits, and strong protection of data in storage, transit, and use. Operating-system facilities can support these principles through permission prompts, per-application data stores, isolated profiles, secure deletion policies, encryption, pseudonymous identifiers, and clear administrative controls.

Encryption protects confidentiality but does not automatically ensure privacy. Metadata, access patterns, timing, backups, logs, and inferred information may remain exposed. Differential privacy can reduce disclosure when aggregate statistics are published by adding carefully calibrated noise, although it introduces accuracy trade-offs. Federated processing can reduce the need to centralize raw data, but local devices and model updates still require protection.

Privacy decisions are also ethical decisions. A technically lawful monitoring system may still be disproportionate, opaque, or unfair. Professionals should assess necessity, proportionality, consent, vulnerable populations, discrimination risks, and the consequences of misuse. Regulatory requirements differ across jurisdictions, so organizations need legal review in addition to technical controls.

Patching, Configuration, and the Security Lifecycle

Security is a lifecycle rather than a product feature. Vulnerability management includes asset identification, risk assessment, prioritization, testing, deployment, verification, and retirement of unsupported components. Patching everything immediately is not always feasible, but delaying high-impact fixes without compensating controls creates significant risk.

A mature patching program maintains an accurate inventory, classifies systems by criticality and exposure, tests updates in representative environments, uses staged deployment, preserves rollback options, and verifies that patches were successfully applied. Emergency changes may be necessary for actively exploited vulnerabilities, but they should still be documented and reviewed. Configuration management is equally important: unused services, default credentials, excessive permissions, insecure debugging interfaces, and unverified software sources frequently create avoidable exposure.

Supply-chain security extends beyond local patching. Operating systems depend on firmware, drivers, libraries, package repositories, build systems, and update-signing infrastructure. Reproducible builds, provenance records, signed packages, dependency analysis, and independent verification can improve confidence, although none provides absolute assurance.

Confidential Computing

Confidential computing seeks to protect data while it is being processed, not only while stored or transmitted. Hardware-backed memory encryption and isolated execution environments can reduce exposure to a hostile cloud operator, compromised hypervisor, or unauthorized administrator. A workload may use remote attestation to verify that an approved software measurement is running before releasing secrets.

This model changes the trust boundary but does not remove the need for trust. Applications must handle secrets correctly, attestation policies must be meaningful, and side channels, denial of service, rollback, malicious inputs, and compromised dependencies remain concerns. Confidential computing is most valuable when the data owner does not fully control the infrastructure—for example, in outsourced analytics, collaborative machine learning, protected key management, and regulated workloads.

The strategic question is not whether confidential computing is universally superior. It is whether its additional complexity and performance costs are justified by the threat model. A well-designed system may combine ordinary encryption, access control, secure boot, TEEs, and organizational controls rather than relying on one mechanism.

An Illustrative Case: Securing a University Research Cloud

Background

A university operates a private cloud for medical-imaging research. Researchers use virtual machines and containers to process sensitive datasets. The platform includes a central identity service, shared storage, automated software deployment, and a security-monitoring system.

Situation and Problem

An internal review finds that researchers often receive administrator privileges inside virtual machines, container images are pulled from multiple public repositories, logs contain patient identifiers, and emergency patching is inconsistent. The cloud team assumes that virtualization alone protects datasets. A compromised research account could therefore access more data than necessary, introduce malware into images, or exploit an outdated host component.

Analysis

The principal weaknesses are excessive privilege, weak supply-chain assurance, insufficient data minimization, and an incomplete trust model. Virtual-machine isolation reduces risk but does not eliminate hypervisor, management-plane, storage, or credential threats. The organization also lacks clear separation between researcher, platform-operator, and auditor responsibilities.

Strategy and Solution

The university introduces phishing-resistant multi-factor authentication and separates administrative roles. Researchers receive project-specific identities and short-lived permissions. Storage uses per-project encryption keys, while access policies combine role, project membership, device state, and workload location. Containers are built through a controlled pipeline that scans dependencies, signs approved images, and rejects unsigned artifacts.

Host systems use secure boot, minimal services, restricted module loading, staged patching, and continuous configuration assessment. Sensitive analysis runs in isolated virtual machines with carefully selected confidential-computing features. Logs are redesigned to use project identifiers instead of patient names wherever possible, with restricted access and defined retention periods. A response plan specifies how to isolate a compromised workload, revoke credentials, preserve evidence, and notify the appropriate governance office.

Outcome

The resulting architecture does not claim perfect security. Instead, it reduces the probability and impact of compromise, makes authority more explicit, improves auditability, and limits unnecessary exposure of personal data. Researchers retain usable access to computing resources while platform administrators gain stronger evidence about system state and software provenance.

Learning Points

The case demonstrates that security is an interaction among identity, authorization, isolation, software supply chain, privacy, patching, monitoring, and governance. A single control—such as virtualization or encryption—cannot substitute for a coherent defense-in-depth strategy.

Challenges, Trade-offs, and Common Errors

Security controls impose costs. Fine-grained authorization can increase administrative complexity; strong authentication may reduce convenience; logging consumes storage and can threaten privacy; sandboxing may limit functionality; confidential execution may reduce performance; and rapid patching can interrupt research or business operations. Effective security management makes these trade-offs explicit rather than allowing convenience to determine policy implicitly.

Common errors include treating authentication as authorization, granting permanent administrative access, assuming that a signed program is harmless, trusting a container as if it were a complete virtual machine, collecting every possible log without a purpose, ignoring firmware and supply-chain risks, and failing to test recovery. Another error is confusing compliance evidence with actual risk reduction. Policies and audit reports are valuable only when controls operate effectively.

Governance, Ethics, and Professional Responsibility

Organizations should define ownership of systems, data, keys, logs, and trust anchors. Policies should address acceptable use, administrator access, vulnerability disclosure, incident reporting, retention, third-party services, and secure disposal. Separation of duties reduces the possibility that one individual can create, approve, and conceal a sensitive change.

Professionals must protect confidentiality, avoid unnecessary surveillance, disclose significant risks, preserve evidence, and respect authorization boundaries during testing. Security research should be conducted under explicit scope and responsible-disclosure practices. Decisions involving biometric data, employee monitoring, automated risk scores, or behavioral analytics require particular attention to fairness, proportionality, transparency, and the possibility of error.

Current Directions

Several developments are reshaping operating-system security. Memory-safe systems programming aims to reduce classes of memory-corruption vulnerabilities. Zero-trust architectures continuously evaluate identity, device posture, workload context, and policy rather than assuming that a network location is trustworthy. Hardware-backed credentials and passkeys reduce dependence on reusable passwords. Remote attestation and confidential computing are extending trust decisions into cloud environments. Automated vulnerability discovery, software bills of materials, and provenance frameworks improve visibility into dependencies.

These developments should be evaluated critically. Automation can scale defense but can also amplify incorrect policies. Hardware isolation can protect data but may introduce opaque implementation risks. AI-assisted detection may identify novel behavior but can generate biased or unexplained decisions. The enduring principles remain complete mediation, least privilege, isolation, verifiable trust, controlled change, privacy proportionality, and continuous reassessment.

Best-Practice Framework for Operating-System Security

A practical program can be organized around the following questions:

• What assets, subjects, trust boundaries, and failure consequences exist?
• How are identities authenticated, and how is authority granted, limited, and revoked?
• Which components require privilege, and can they be isolated or reduced?
• How are boot integrity, software provenance, configuration, and patch status verified?
• What events must be logged, who may review them, and how is privacy protected?
• How will the organization detect, contain, recover from, and learn from incidents?
• Which assumptions are delegated to hardware, cloud providers, vendors, or administrators?
• How are security decisions tested, measured, documented, and governed?

The answers should be evidence-based and revisited when systems, threats, regulations, or organizational purposes change.

Chapter Summary

Operating-system protection controls how subjects use system objects, while security addresses intentional compromise and privacy governs responsible handling of information. Access-control lists, roles, attributes, and capabilities provide different ways to express authority. Authentication establishes identity evidence; authorization determines permitted action; least privilege limits damage and supports separation of duties.

Isolation, sandboxing, virtualization, secure boot, trusted execution, and confidential computing create layered trust boundaries, but each has implementation weaknesses and operational costs. Kernel attack surfaces must be reduced through minimal design, privilege separation, exploit mitigation, secure configuration, and careful patching. Malware defense combines prevention, detection, response, and recovery. Auditing supports accountability when logs are trustworthy, purposeful, and privacy-aware.

A strategic security program integrates technical mechanisms with governance, ethical judgment, supply-chain assurance, incident response, and lifecycle management. No single control establishes complete trust. Security and privacy emerge from the coordinated design of identity, authority, isolation, integrity, monitoring, and organizational responsibility.

Key Terms

Protection: Controlled access by subjects to operating-system resources and objects.

Security: Protection of systems and information against unauthorized access, alteration, disclosure, or disruption.

Privacy: Appropriate control over the collection, use, disclosure, retention, and deletion of personal information.

Access matrix: Conceptual table mapping subjects and objects to authorized rights.

Access-control list: Permissions associated with a particular object.

Capability: An unforgeable authority token identifying an object and permitted operations.

Authentication: Verification of an asserted identity.

Authorization: Determination of actions permitted to an authenticated subject.

Least privilege: Granting only the authority necessary for a task and duration.

Role-based access control: Authorization based on assigned organizational roles.

Attribute-based access control: Authorization based on subject, object, action, and environmental attributes.

Sandbox: An execution environment that restricts code’s access to resources.

Reference monitor: A mediation mechanism that checks every relevant access request.

Secure boot: Startup verification or measurement of authorized software components.

Trusted execution environment: Hardware-supported isolation for selected code and data.

Attestation: Evidence supplied about the identity or state of an executing component.

Audit trail: Protected record of security-relevant events.

Confidential computing: Protection of data while it is being processed through isolated execution and hardware support.

Defense in depth: Use of multiple complementary controls so that one failure does not determine the outcome.

Supply-chain security: Protection of software, hardware, dependencies, build processes, and update channels.

Review Questions

Short Answer Questions

1. Distinguish protection from security in an operating system.

2. What is the difference between an access-control list and a capability list?

3. Why is multi-factor authentication stronger than password-only authentication?

4. Define the principle of least privilege.

5. Differentiate secure boot from measured boot.

Long Answer Questions

1. Explain discretionary, mandatory, role-based, and attribute-based access control, including their strengths and limitations.

2. Discuss how privilege separation, capabilities, and sandboxing reduce the impact of a compromised process.

3. Analyze the kernel attack surface and describe layered defenses against kernel compromise.

4. Explain how auditing, incident response, patching, and configuration management support the security lifecycle.

5. Discuss confidential computing, remote attestation, and the trust assumptions that remain despite hardware isolation.

Analytical / Application Questions

1. A payroll service needs to read employee records, produce reports, and send approved results to a finance system. Design an authorization and least-privilege strategy, including roles, capabilities, logging, and revocation.

2. A cloud provider claims that containers provide complete isolation for sensitive workloads. Evaluate this claim and recommend additional controls.

3. An organization wants to collect detailed operating-system telemetry from employee devices to detect malware. Propose a design that balances detection effectiveness with privacy, proportionality, retention, and governance.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication grants permissions, while authorization verifies passwords.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication encrypts data, while authorization records audit events.

D. Authentication applies only to administrators, while authorization applies only to users.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

A service needs to append records to one directory but not read, delete, or modify other files. Which design best applies least privilege?

A. Grant the service full administrator access during its entire execution.

B. Grant read-write-execute access to the entire file system.

C. Provide narrowly scoped append authority for the required directory.

D. Run the service under a shared account used by all applications.

Correct Answer: C. Provide narrowly scoped append authority for the required directory.

Question 3

What is the principal distinction between an access-control list and a capability?

A. An access-control list is associated with an object, whereas a capability conveys authority to a subject.

B. An access-control list always uses encryption, whereas a capability never does.

C. An access-control list authenticates users, whereas a capability patches software.

D. An access-control list applies only to networks, whereas a capability applies only to files.

Correct Answer: A. An access-control list is associated with an object, whereas a capability conveys authority to a subject.

Question 4

Which statement about secure boot and measured boot is most accurate?

A. Both guarantee that authorized software contains no vulnerabilities.

B. Secure boot verifies execution authorization, while measured boot records evidence about loaded components.

C. Measured boot prevents all unauthorized execution, while secure boot only creates logs.

D. Neither depends on key management or trust anchors.

Correct Answer: B. Secure boot verifies execution authorization, while measured boot records evidence about loaded components.

Question 5

A containerized application is compromised and attempts to access host kernel interfaces. Which observation is most accurate?

A. Containers always provide stronger isolation than virtual machines.

B. The shared kernel can create risk, so system-call restrictions and host hardening may be necessary.

C. Container compromise cannot affect other workloads under any configuration.

D. Secure boot makes container escape impossible.

Correct Answer: B. The shared kernel can create risk, so system-call restrictions and host hardening may be necessary.

Question 6

Which audit design is most consistent with security and privacy principles?

A. Record every possible data field indefinitely for future analysis.

B. Record relevant events, protect the logs, restrict access, and define retention periods.

C. Avoid logging authentication failures because they create privacy risks.

D. Allow administrators to edit logs to correct inconvenient events.

Correct Answer: B. Record relevant events, protect the logs, restrict access, and define retention periods.

Question 7

In the university research-cloud case, why were signed container images useful but insufficient?

A. Signatures prove that an image is authorized or authentic, but not that its code is vulnerability-free or appropriately privileged.

B. Signatures prevent all runtime attacks regardless of configuration.

C. Signatures eliminate the need for patch management.

D. Signatures are useful only for encrypting patient data.

Correct Answer: A. Signatures prove that an image is authorized or authentic, but not that its code is vulnerability-free or appropriately privileged.

Question 8

What problem is most directly addressed by privilege separation?

A. It ensures that all components run with identical permissions.

B. It confines sensitive operations to a smaller privileged component and reduces the authority of routine components.

C. It eliminates the need for authentication.

D. It guarantees that malware cannot exploit a vulnerability.

Correct Answer: B. It confines sensitive operations to a smaller privileged component and reduces the authority of routine components.

Question 9

What is a major purpose of remote attestation in confidential computing?

A. To prove that a remote system has sufficient storage capacity.

B. To provide evidence about the software and protected execution environment before secrets are released.

C. To replace all application-level access control.

D. To guarantee availability during denial-of-service attacks.

Correct Answer: B. To provide evidence about the software and protected execution environment before secrets are released.

Question 10

An organization collects detailed user activity logs for malware detection. Which control best addresses the associated privacy risk?

A. Collect more identifying information to improve future correlation.

B. Use purpose limitation, data minimization, restricted access, and defined retention.

C. Publish the logs internally so that all employees can inspect them.

D. Disable all security monitoring to avoid collecting personal information.

Correct Answer: B. Use purpose limitation, data minimization, restricted access, and defined retention.