12. Dependability, Security, and Trusted Computer Design

Introduction and Context

Computer design is often evaluated through performance, cost, energy efficiency, and functionality. These criteria are necessary but insufficient for systems whose failure can injure people, interrupt essential services, expose confidential information, or undermine institutional trust. A server supporting financial transactions, an automotive controller, a medical device, and a cloud platform must not merely compute correctly under normal conditions. Each must continue to provide an acceptable service when components fail, software behaves unexpectedly, attacks occur, or operating conditions depart from assumptions.

This broader quality is studied through dependability and security. Dependability concerns the ability of a system to deliver a service that can reasonably be trusted. Security concerns protection against unauthorized disclosure, modification, misuse, and denial of service. The two fields overlap but are not identical. A system can be highly available yet insecure, or confidential yet unreliable. Trusted computer design combines hardware architecture, operating-system mechanisms, verification, operational procedures, and governance to address both dimensions.

At postgraduate level, dependability cannot be reduced to memorizing reliability formulas, and security cannot be reduced to listing defensive technologies. Designers must identify assets, failure assumptions, adversaries, trust boundaries, measurable requirements, and trade-offs. This chapter develops those ideas and connects classical fault-tolerant design with contemporary mechanisms such as secure boot, hardware roots of trust, trusted execution environments, memory protection, and defenses against speculative-execution attacks.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish fault, error, failure, reliability, availability, and maintainability.

2. Apply reliability, availability, repair, redundancy, and error-detection models.

3. Compare fault-avoidance, fault-tolerance, fault-removal, and fault-forecasting approaches.

4. Evaluate the security role of privilege separation, memory protection, secure boot, enclaves, and hardware roots of trust.

5. Explain why side channels and speculative execution challenge conventional security boundaries.

6. Select appropriate dependability and security mechanisms for realistic system requirements.

7. Analyze organizational, ethical, regulatory, and operational implications of trusted computer design.

Dependability as a System Property

Dependability is an umbrella concept encompassing several attributes. Reliability is the probability that a system performs its required function without failure for a specified period under stated conditions. Availability is the probability that a system is operational and accessible when required. Maintainability is the probability that a failed system can be restored within a specified time. Safety concerns the absence of catastrophic consequences to people or the environment. Integrity denotes protection against improper alteration. Confidentiality concerns unauthorized disclosure. Security usually emphasizes confidentiality, integrity, and availability, while dependability also includes reliability, maintainability, and safety.

A useful vocabulary separates the stages of a malfunction. A fault is a physical or design defect that may produce an incorrect internal state. An error is an erroneous system state caused by a fault. A failure occurs when delivered service deviates from the specification. For example, a defective memory cell is a fault; a corrupted instruction loaded from that cell is an error; executing an incorrect medical dosage calculation is a failure. A fault may remain dormant, and an error may be detected and corrected before it becomes a failure.

This distinction leads to the fault-error-failure chain:

fault → error → failure

Dependable design attempts to prevent faults, detect errors, contain their effects, recover from failures, and learn from incidents. Security engineering uses a similar logic but treats an intelligent adversary as an active source of faults. An attacker may deliberately create an error, exploit an existing vulnerability, or manipulate the environment so that a failure benefits the attacker.

Reliability and Failure Distributions

Let R(t) denote reliability at time t and F(t) the probability of failure by time t. For a continuous lifetime variable:

R(t) = 1 − F(t)

The instantaneous failure rate, often called the hazard rate, is represented by λ(t). If λ is constant, reliability follows the exponential model:

R(t) = e^(−λt)

The mean time to failure for this model is 1/λ. The constant-rate assumption is convenient for electronic components during their useful life but does not describe every system. Mechanical wear, manufacturing defects, software faults, environmental stress, and common-cause failures can create changing failure rates. A bathtub curve is often used conceptually: early failures decline after manufacturing defects are removed, useful-life failures occur at a roughly stable rate, and wear-out failures increase with age.

Software requires special care. Software does not physically wear out, but latent design defects are exposed by new inputs, configurations, updates, or environmental conditions. Consequently, software reliability is often driven by operational profiles and defect-removal practices rather than component aging.

Availability and Maintainability

Availability incorporates both failure and repair. A simple steady-state approximation is:

A = MTBF / (MTBF + MTTR)

where MTBF is mean time between failures and MTTR is mean time to repair or restore. A system with a high MTBF can still have poor availability if repairs are slow. Conversely, rapid automated recovery can produce high availability even when individual components fail relatively often.

Availability may be measured as inherent, achieved, or operational. Inherent availability considers corrective maintenance under ideal support conditions. Achieved availability includes preventive maintenance. Operational availability additionally includes logistics, staffing, procedures, and delays in obtaining replacement components. This distinction matters in cloud services, industrial plants, and remote infrastructure, where the repair process may dominate hardware behavior.

Availability targets should be interpreted carefully. “Three nines” means 99.9 percent availability, while “five nines” means 99.999 percent. The difference is not merely 0.099 percentage points; it represents a substantial reduction in allowable downtime. However, a numerical target is meaningful only when the measurement interval, maintenance exclusions, service boundary, and failure definition are specified.

Designing for Fault Tolerance

Fault tolerance is the ability of a system to continue delivering an acceptable service in the presence of faults. It does not imply that faults disappear. Instead, the design limits their consequences through redundancy, detection, isolation, masking, recovery, or reconfiguration.

Redundancy and Its Forms

Redundancy provides more resources or information than the minimum required. Hardware redundancy may use duplicated processors, power supplies, memory modules, or network paths. Information redundancy adds bits that permit error detection or correction, as in parity, checksums, cyclic redundancy checks, and error-correcting codes. Time redundancy repeats an operation or uses retry after a transient fault. Software redundancy uses diverse implementations, recovery blocks, or independently developed components.

A parallel system whose components fail independently is available if at least one component operates. If each of n identical components has reliability R(t), the reliability of a parallel arrangement is:

Rparallel(t) = 1 − [1 − R(t)]^n

This improvement depends on independence. If all redundant components share a power supply, clock, cooling system, design defect, or software image, a common-cause failure can defeat the entire arrangement. Redundancy therefore requires architectural separation, not merely duplication.

A series system fails when any essential component fails. Under independence, its reliability is the product of individual reliabilities. Adding components in series to provide additional functionality can reduce overall reliability, whereas parallelizing critical components can improve it. Designers must therefore examine the complete dependency graph rather than count components in isolation.

Detection, Correction, and Recovery

Error-detecting codes identify corruption but may not reveal its location or correct it. A parity bit detects many single-bit errors but cannot correct them. Error-correcting codes add sufficient redundancy to locate and repair certain error patterns. In memory systems, single-error correction and double-error detection are common design goals, although the precise capability depends on the code and implementation.

Detection mechanisms must be placed close to the point where errors arise. End-to-end checks are also valuable because intermediate components may corrupt data after a lower-level check has passed. A storage controller can detect a media error, but an end-to-end integrity check may be needed to detect corruption introduced in transit or by faulty software.

Recovery may be forward or backward. Forward recovery masks or compensates for an error and continues execution, as in correcting a memory bit. Backward recovery returns the system to a known consistent state, as in checkpoint and rollback. Transaction systems commonly combine logging, atomicity, and recovery procedures to ensure that partial updates do not produce inconsistent state.

Fault containment limits propagation. Process isolation, memory protection, privilege boundaries, watchdog timers, and microservice separation all act as containment mechanisms. A system that cannot prevent every fault can still be dependable if a fault in one component is prevented from corrupting critical services.

Graceful Degradation and Fail-Safe Behavior

A fault-tolerant system need not always provide full functionality. Graceful degradation maintains essential functions while reducing noncritical services. An aircraft control system, for example, may lose redundancy but continue with restricted capability. Fail-safe behavior moves the system to a state that minimizes harm, whereas fail-secure behavior preserves security when failure occurs, such as denying access when authorization cannot be verified. These goals may conflict: a door-control system may need to remain fail-safe for evacuation but fail-secure against unauthorized entry. Requirements must resolve such conflicts explicitly.

Fault Models and Dependability Analysis

No design can defend against every possible fault. Engineers therefore state a fault model: the assumed fault types, locations, rates, timing, and independence relationships. Common categories include transient faults, intermittent faults, permanent faults, systematic design faults, accidental faults, and malicious faults.

A transient fault disappears without repair, perhaps because of electrical noise or radiation. An intermittent fault appears irregularly and is often difficult to diagnose. A permanent fault persists until a component is replaced or reconfigured. Systematic faults result from design, specification, implementation, or process errors and may affect every replicated instance. This last category is especially important: duplicating identical flawed software does not create genuine diversity.

Failure Mode and Effects Analysis (FMEA) examines component failure modes, their effects, detection mechanisms, and corrective actions. Fault-tree analysis begins with an undesired top event and derives combinations of failures that can cause it. Markov models represent transitions among operational, degraded, failed, and repair states. Reliability block diagrams represent logical relationships among components. These tools are complementary: a block diagram is intuitive for structural redundancy, while a Markov model is better suited to repairable systems with state-dependent transitions.

Quantitative analysis must not create false precision. Input failure rates may be uncertain, independence assumptions may be unrealistic, and human or software failures may be difficult to estimate. Qualitative engineering judgment, testing, incident evidence, and sensitivity analysis should accompany numerical results.

Security Boundaries in Computer Architecture

Security begins with assets, threats, trust assumptions, and policy. Assets include data, computation, keys, identities, availability, and physical control. A threat model identifies adversaries, their capabilities, goals, access paths, and persistence. A trust boundary separates components whose behavior is trusted from components that must be treated as potentially malicious or compromised.

Privilege and Memory Protection

Modern processors support multiple privilege levels so that operating-system code can control hardware while applications operate with fewer permissions. Memory-management units translate virtual addresses, enforce page permissions, and isolate processes. Permissions such as read, write, and execute reduce the consequences of a compromised program. Non-executable data regions, address-space layout randomization, guard pages, and control-flow integrity further complicate exploitation.

These mechanisms are not complete security solutions. A privileged operating system remains a large trusted computing base, and implementation defects can allow privilege escalation. Direct memory access devices must be controlled through mechanisms such as an input-output memory management unit. Otherwise, a peripheral may bypass processor-level memory isolation.

Secure Boot and the Chain of Trust

Secure boot establishes a measured or verified sequence from an immutable hardware root to firmware, bootloader, operating system, and sometimes application components. A component is verified using a digital signature or cryptographic hash before it is executed. The key question is not simply whether verification occurs, but where the initial trust anchor resides and how keys are provisioned, rotated, revoked, and recovered.

A hardware root of trust is a small, protected foundation used to perform security-critical operations. It may include immutable boot code, a secure element, a trusted platform module, fused public keys, protected registers, or hardware-supported cryptographic operations. A root of trust does not make the entire system trusted automatically. It provides a basis for verifying later components and protecting secrets, but the surrounding software and operational processes must preserve the chain.

Measured boot records cryptographic measurements of components, allowing a remote party to assess platform state. Verified boot prevents execution of unauthorized components. These approaches can be combined: verification enforces a policy, while measurement supports attestation and audit.

Trusted Execution Environments and Enclaves

A trusted execution environment (TEE) isolates selected code and data from the normal operating system. Enclaves attempt to ensure that even a compromised operating system cannot directly read or modify protected memory. Remote attestation allows a remote party to verify that approved code is running in an expected environment before releasing a secret.

Enclaves introduce difficult questions. What code is trusted inside the enclave? How are inputs and outputs validated? Can side channels reveal secrets? How are updates and rollback handled? Enclave protection is therefore a defense-in-depth mechanism rather than a substitute for secure software design. The smaller trusted computing base is valuable, but its interface, hardware implementation, and attestation infrastructure remain part of the security argument.

Side Channels and Speculative Execution

A conventional security model often assumes that an attacker can observe only explicit outputs. Side-channel attacks invalidate this assumption by extracting information from indirect effects such as execution time, cache state, branch-predictor state, power consumption, electromagnetic emissions, or memory-access patterns.

A timing channel may reveal whether a secret-dependent operation took a fast or slow path. A cache attack can infer which memory locations a victim accessed. Constant-time algorithms reduce timing variation by avoiding secret-dependent branches and memory accesses, but compiler transformations, processor behavior, and system noise must also be considered. Isolation should therefore address shared microarchitectural resources, not just virtual address spaces.

Speculative execution improves performance by executing instructions before earlier branches or dependencies are fully resolved. If speculation follows an incorrect path, architectural results are discarded. However, microarchitectural effects such as cache fills may remain. An attacker can use a carefully constructed sequence to cause speculative execution to access data that should not be architecturally accessible, then infer the data through a side channel. This class of attacks demonstrates that “not committed” does not necessarily mean “not observable.”

Mitigations include stronger bounds checks, speculation barriers, branch-predictor controls, cache partitioning or flushing, microcode updates, compiler changes, process isolation, and redesign of sensitive code. Each mitigation carries performance, compatibility, and residual-risk costs. Security evaluation must therefore consider threat model, processor generation, software stack, and whether an attacker can execute code locally or share hardware.

A Design Method for Trusted Computer Systems

A disciplined design process integrates dependability and security rather than treating them as final testing activities.

First, define service requirements. Specify acceptable failure behavior, recovery time, data integrity, safety constraints, confidentiality needs, and availability targets. Second, identify assets, trust boundaries, dependencies, and adversary capabilities. Third, select a fault and threat model, including assumptions about independence, physical access, insiders, supply-chain compromise, and software updates.

Fourth, choose mechanisms proportionate to the risk: error-correcting memory, watchdogs, replication, isolation, secure boot, attestation, cryptographic protection, logging, or physical controls. Fifth, analyze residual risk using FMEA, fault trees, attack trees, penetration testing, formal methods, and reliability experiments. Sixth, validate operational behavior through fault injection, recovery testing, red-team exercises, and independent review. Finally, monitor the deployed system. Dependability and security are lifecycle properties; configuration drift, newly discovered vulnerabilities, component aging, and changing workloads alter the original assumptions.

The best architecture usually combines prevention, detection, response, and recovery. Prevention alone creates brittle systems; detection without response merely generates alerts; recovery without root-cause analysis allows recurring incidents.

Illustrative Case Study: A Secure and Dependable Edge-Control Platform

Background

Consider an illustrative company developing an industrial edge controller for a water-treatment facility. The controller collects sensor readings, operates pumps and valves, and communicates with a supervisory system. It must continue safe operation during network loss, tolerate selected hardware faults, and prevent unauthorized firmware from controlling equipment.

Situation and Problem

The initial prototype used a general-purpose processor, a single boot flash device, uncorrected memory, and a network-facing management service running with excessive privilege. A power disturbance could corrupt a configuration update. A compromised maintenance laptop could install modified firmware. A software defect in the management service could potentially alter control processes. The engineering team proposed simply adding a second controller, but both units would have shared the same firmware and power supply.

Analysis

The safety requirement was not identical to the availability requirement. If sensor data became unreliable, continuing to operate pumps at the last command could be unsafe. The system therefore needed validity checks, a bounded degraded mode, and a safe state for particular actuator combinations. The threat model included remote network attackers, compromised maintenance equipment, and malicious firmware, but not unlimited physical destruction of the facility.

The team identified common-cause risks: identical software, shared power, shared sensor wiring, and a common update mechanism. It also recognized that a secure boot signature alone would not protect runtime memory, management interfaces, or secrets stored in unprotected flash.

Approach and Solution

The revised architecture used error-correcting memory, protected configuration with versioned transactional updates, a watchdog, and independent health monitoring. Two control paths were separated sufficiently to detect disagreement, while a safety monitor selected a predefined safe response when sensor values or controller outputs violated plausibility limits. The design did not claim that dual controllers provided perfect fault tolerance; instead, it documented the faults against which they were effective.

An immutable boot component verified the bootloader and operating-system image. Device-unique keys were held in a protected hardware module, and remote maintenance required authenticated authorization, signed packages, anti-rollback counters, and an auditable process. The management service was isolated with least privilege and could not directly write actuator registers. Network communication used authenticated encryption, while diagnostic logs were protected against unauthorized modification.

Testing included power interruption during updates, memory-error injection, network flooding, invalid sensor sequences, rollback attempts, and compromise of the management process. Security testing also examined timing and cache exposure in cryptographic operations. Recovery objectives were measured rather than assumed.

Outcome

The resulting platform had greater hardware and software complexity and a modest performance cost. Nevertheless, it achieved a clearer safety case, reduced the trusted computing base, and made recovery behavior explicit. The organization also gained operational procedures for key rotation, incident response, spare hardware, and secure decommissioning.

Learning Points

The case illustrates that redundancy without independence is weak, secure boot without runtime isolation is incomplete, and availability without safe degraded behavior can be dangerous. It also shows why dependability and security decisions must be made together: an update mechanism is both a reliability function and a security boundary.

Challenges, Limitations, and Professional Responsibilities

The principal challenge is complexity. Every additional monitor, replica, key, recovery path, and security layer introduces interfaces that may contain defects. Redundancy can increase the number of failure modes, while aggressive isolation can complicate maintenance and reduce observability.

Common mistakes include treating availability as reliability, assuming duplicated software is independent, ignoring common-cause failures, measuring only average downtime, trusting a cryptographic algorithm without securing keys, using encryption without authentication, and declaring a system secure because it passed a penetration test. Another mistake is neglecting recovery: backups may be encrypted by ransomware, restoration may be untested, or a recovered system may reintroduce the original vulnerability.

Security and dependability also involve ethical and governance obligations. Engineers should not conceal residual risks behind impressive availability numbers or security labels. System owners need clear documentation of assumptions, limitations, maintenance requirements, and failure behavior. Privacy laws, sector-specific safety rules, software-update obligations, audit requirements, and supply-chain controls may apply. Responsible disclosure and timely patching must be balanced against the risk that an update itself disrupts a critical service.

Artificial intelligence can assist anomaly detection, predictive maintenance, log correlation, and fault diagnosis. However, machine-learning detectors can produce false positives, be evaded by adversaries, or fail under distribution shift. An AI recommendation should not silently override a safety policy. Human oversight, explainable escalation, secure data pipelines, and conservative fallback behavior remain necessary.

Current Developments and Best Practices

Trusted computing is moving toward confidential computing, hardware-backed attestation, memory-encryption technologies, capability-oriented architectures, formally verified components, and stronger supply-chain provenance. Chiplet integration and open instruction-set ecosystems create new opportunities but also expand verification and trust challenges. Post-quantum cryptography is influencing long-lived designs whose protected data must remain confidential for many years.

Practical best practices include:

• Define measurable reliability, recovery, safety, and security requirements before selecting mechanisms.
• State fault and threat assumptions explicitly, including common-cause and insider risks.
• Minimize and document the trusted computing base.
• Use least privilege, memory protection, authenticated communication, and secure update processes.
• Combine prevention with detection, containment, recovery, and learning.
• Test degraded modes, restoration, key rotation, and incident response—not only normal operation.
• Use independent implementations or organizational separation where common-mode faults are serious concerns.
• Treat hardware roots of trust and enclaves as foundations requiring lifecycle governance, not as magical guarantees.
• Assess side channels and speculative behavior when secrets share processors or other microarchitectural resources.
• Reassess assumptions after changes in hardware, software, workloads, threats, and regulations.

Chapter Summary

Dependability is the ability of a system to provide a service that can reasonably be trusted. Reliability, availability, maintainability, safety, integrity, and security describe related but distinct properties. Faults may produce errors, and errors may become failures; dependable design seeks to prevent, detect, contain, mask, and recover from these events.

Reliability models, availability equations, reliability block diagrams, Markov models, FMEA, and fault-tree analysis provide structured ways to reason about failure. Redundancy, error-correcting codes, isolation, watchdogs, graceful degradation, and recovery mechanisms improve resilience, but common-cause failures and unrealistic independence assumptions limit their value.

Security architecture relies on privilege separation, memory protection, secure boot, hardware roots of trust, measured boot, attestation, and trusted execution environments. Side channels and speculative execution show that architectural access rules may not control every observable effect. Trusted design is therefore a lifecycle activity involving threat modeling, testing, maintenance, governance, and responsible management of residual risk.

Key Terms

Fault: A defect or abnormal condition that can produce an erroneous state.

Error: An incorrect internal state caused by a fault.

Failure: A deviation of delivered service from its specification.

Reliability: Probability of performing required function without failure for a stated period.

Availability: Probability that a system is operational and accessible when required.

Maintainability: Probability that a failed system is restored within a specified time.

Dependability: The broader ability of a system to provide a justifiably trusted service.

Fault tolerance: Ability to continue acceptable service despite specified faults.

Redundancy: Provision of additional resources or information beyond the minimum required.

Common-cause failure: A single cause that defeats multiple supposedly independent elements.

MTBF: Mean time between failures during operation.

MTTR: Mean time to repair or restore service.

Fault containment: Limitation of a fault’s effects to a restricted system area.

Secure boot: Verified execution of an authorized boot sequence from a trusted foundation.

Hardware root of trust: Protected hardware foundation for verification, identity, or key protection.

Trusted execution environment: An isolated execution area intended to protect code and data.

Attestation: Evidence that a platform is running specified hardware or software state.

Side channel: An unintended information channel based on observable implementation effects.

Speculative execution: Execution performed before instruction dependencies or control flow are fully resolved.

Trusted computing base: Hardware and software components whose correctness is essential to security.

Review Questions

Short Answer Questions

1. Distinguish a fault, an error, and a failure using a computer-system example.

2. Why can a system with high reliability still have poor availability?

3. What is the purpose of a hardware root of trust?

4. Explain the difference between verified boot and measured boot.

5. Why does redundancy fail to provide full protection against common-cause failures?

Long Answer Questions

1. Explain reliability, availability, and maintainability models and discuss the assumptions behind the availability equation.

2. Compare fault avoidance, fault detection, fault masking, fault containment, and recovery with suitable architectural examples.

3. Discuss secure boot, trusted execution environments, remote attestation, and the trusted computing base as parts of a security architecture.

4. Explain how side channels and speculative execution challenge conventional memory and privilege isolation.

5. Develop a dependability and security design strategy for a safety-critical embedded computer.

Analytical / Application Questions

1. A service has an MTBF of 2,000 hours and an MTTR of 4 hours. Calculate its approximate steady-state availability and explain what operational factors could make the real value lower.

2. Two replicated controllers use identical firmware, a shared power supply, and identical sensors. Analyze which failure assumptions are invalid and recommend improvements.

3. Design a test and assurance plan for a device that uses secure boot and an enclave to protect cryptographic keys. Include failure recovery, update security, side-channel considerations, and governance requirements.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes reliability from availability?

A. Reliability concerns repair time, whereas availability concerns only component cost.

B. Reliability concerns failure-free operation over an interval, whereas availability includes operational status and restoration.

C. Reliability applies only to software, whereas availability applies only to hardware.

D. Reliability measures confidentiality, whereas availability measures integrity.

Correct Answer: B. Reliability concerns failure-free operation over an interval, whereas availability includes operational status and restoration.

Question 2

A duplicated system shares one power supply and one identical software image. Which issue most seriously limits the value of duplication?

A. Excessive information redundancy

B. Common-cause failure

C. Excessive maintainability

D. Reduced address-space randomization

Correct Answer: B. Common-cause failure

Question 3

What does an error-correcting memory mechanism provide that a simple parity bit generally does not?

A. The ability to authenticate firmware

B. The ability to correct certain detected errors

C. Protection against all software vulnerabilities

D. Guaranteed independence between processors

Correct Answer: B. The ability to correct certain detected errors

Question 4

Which mechanism primarily establishes a verified sequence from an initial trusted component to later boot components?

A. Secure boot

B. Load balancing

C. Cache partitioning only

D. Checkpoint rollback only

Correct Answer: A. Secure boot

Question 5

What is the main purpose of remote attestation?

A. To increase processor clock frequency

B. To prove that a platform is running an expected measured state

C. To replace all access-control policies

D. To eliminate the need for software updates

Correct Answer: B. To prove that a platform is running an expected measured state

Question 6

Why can speculative execution create a security problem even when incorrect instructions are not architecturally committed?

A. They permanently change the instruction set.

B. They can leave observable microarchitectural effects such as cache state.

C. They always disable memory protection.

D. They automatically modify firmware keys.

Correct Answer: B. They can leave observable microarchitectural effects such as cache state.

Question 7

A system enters a restricted operating mode after losing one redundant sensor. This is an example of:

A. Graceful degradation

B. A series-system failure

C. Software wear-out

D. Key revocation

Correct Answer: A. Graceful degradation

Question 8

Which statement about a trusted execution environment is most accurate?

A. It guarantees that enclosed code contains no defects.

B. It protects selected code and data but still requires careful interfaces and side-channel analysis.

C. It makes secure boot unnecessary in every architecture.

D. It prevents all denial-of-service attacks.

Correct Answer: B. It protects selected code and data but still requires careful interfaces and side-channel analysis.

Question 9

A system has MTBF = 2,000 hours and MTTR = 4 hours. Using A = MTBF/(MTBF + MTTR), its approximate availability is:

A. 80.0%

B. 95.0%

C. 99.8%

D. 99.998%

Correct Answer: C. 99.8%

Question 10

Which design decision best addresses a compromised management service?

A. Granting it unrestricted actuator access for faster operation

B. Running it with least privilege and isolating it from critical control functions

C. Duplicating the same vulnerable service on another processor

D. Disabling all event logging

Correct Answer: B. Running it with least privilege and isolating it from critical control functions