Cybersecurity and Privacy

Introduction and Context

A cyber-physical system (CPS) combines computation, communication, sensing, actuation, and physical processes. Examples include robotic cells, autonomous vehicles, smart grids, medical devices, process plants, and building-management systems. In such systems, a cyberattack can produce consequences beyond data loss: unsafe motion, environmental release, equipment damage, production interruption, or harm to people.

Operational technology (OT) refers to systems that monitor or control physical processes. OT includes programmable logic controllers (PLCs), distributed control systems (DCSs), supervisory control and data acquisition (SCADA) systems, safety-instrumented systems, industrial robots, sensors, actuators, and engineering workstations. Information technology (IT) generally prioritizes confidentiality and data processing, whereas OT traditionally prioritizes safety, availability, deterministic timing, and process integrity. Modern CPS environments increasingly connect IT and OT, making cybersecurity a systems-engineering responsibility rather than an isolated information-technology function.

Security must therefore be designed together with safety, reliability, maintainability, privacy, and operational performance. A technically strong security control may be unsuitable if it creates unacceptable latency, prevents emergency intervention, or cannot be maintained during a long equipment life cycle.

Learning Objectives

After completing this chapter, a student should be able to:

1. Explain cybersecurity and privacy risks in CPS and OT environments.
2. Identify assets, trust boundaries, threats, vulnerabilities, and consequences.
3. Apply threat-modeling and risk-assessment methods to an industrial system.
4. Design a layered secure architecture for IT/OT environments.
5. Select appropriate authentication, encryption, access-control, and monitoring mechanisms.
6. Plan secure software and firmware updates without compromising safety or availability.
7. Describe an OT incident-response process and distinguish it from a conventional IT response.
8. Evaluate ethical, privacy, governance, and life-cycle implications of CPS security.

1. Security, Safety, and Privacy in CPS

The three classical security objectives are confidentiality, integrity, and availability (CIA):

• Confidentiality prevents unauthorized disclosure of information.
• Integrity preserves correctness, authenticity, and trustworthiness of data and commands.
• Availability ensures that authorized users and systems can perform required functions when needed.

For CPS, these objectives must be extended. Safety concerns preventing unacceptable physical harm. Authenticity concerns confidence that a message, device, or user is genuine. Accountability links actions to responsible identities and processes. Resilience is the ability to continue essential functions and recover after disruption.

The priorities differ by application. A temporary loss of a noncritical dashboard may be tolerable, while a false pressure reading or delayed shutdown command may be dangerous. In a safety-critical system, the secure design must not make the safety function dependent on an insecure or unavailable general-purpose network.

Privacy concerns the collection, processing, storage, and sharing of information about identifiable people. CPS privacy issues arise in worker-location systems, biometric access, wearable devices, vehicle telemetry, smart homes, video surveillance, and predictive-maintenance data that may reveal employee behavior. Privacy is not simply a matter of encrypting data; it also involves purpose limitation, transparency, retention, proportionality, access rights, and governance.

Important terminology

An asset is something valuable that requires protection, such as a PLC, process recipe, safety configuration, credential, network service, or human life. A threat is a potential cause of harm. A vulnerability is a weakness that can be exploited. An attack is an intentional attempt to exploit a weakness. A risk is the possibility that a threat will exploit a vulnerability and produce a consequence. A control is a safeguard that reduces likelihood, consequence, or exposure.

A zero-day vulnerability is a vulnerability unknown, or not yet effectively addressed, by the responsible defender. A zero-trust architecture does not automatically trust a device or user merely because it is inside a network; access is continuously evaluated using identity, context, policy, and least privilege. Defense in depth uses multiple independent layers so that failure of one control does not expose the entire system.

2. Threat Modeling for Cyber-Physical Systems

Threat modeling is a structured process for identifying what can go wrong, why it could happen, and how the system should be designed to reduce the danger. It should begin during concept and architecture development, not after deployment.

2.1 Establish scope and assumptions

The analyst first defines the system boundary, mission, operating modes, safety constraints, maintenance arrangements, external connections, and acceptable consequences. Important questions include:

• What physical process is controlled?
• Which functions are safety-critical or time-critical?
• Which components are externally reachable?
• Which users, vendors, and autonomous services require access?
• What must remain operational during a network outage?
• What are the recovery-time and recovery-point requirements?
• Which legal, contractual, safety, and privacy obligations apply?

The analyst should document assumptions. For example, “the safety PLC is physically isolated” is not a fact unless verified; it is an assumption that may fail when a maintenance laptop or shared switch is introduced.

2.2 Build an asset and data-flow model

An asset inventory identifies hardware, firmware, software, accounts, protocols, data, dependencies, and physical locations. A data-flow diagram then shows communication paths and trust boundaries. Typical zones include enterprise IT, a demilitarized zone (DMZ), supervisory systems, control networks, safety systems, and field devices.

A trust boundary is a transition at which security assumptions change. Examples are a firewall between an enterprise network and an OT DMZ, a remote-access gateway, a wireless link, or the interface between a vendor service and a plant network. Each crossing deserves explicit authentication, authorization, validation, logging, and failure analysis.

2.3 Identify threats

The STRIDE framework classifies common threats:

STRIDE is useful for identifying threat types, but it does not by itself determine physical consequence or probability. Safety analysis methods such as hazard and operability studies (HAZOP), failure-mode and effects analysis (FMEA), fault-tree analysis, and bow-tie analysis should be coordinated with cybersecurity analysis. A cyber event can be treated as an initiating cause in a safety argument.

Attack trees provide another useful method. The root node states an undesirable goal, such as “cause an unsafe robot motion.” Branches represent alternative attack paths, such as compromising an engineering laptop, abusing a remote-access account, or modifying a controller program locally. The tree encourages analysts to consider combinations of controls and attack paths rather than isolated vulnerabilities.

2.4 Assess risk

A simple qualitative model represents risk as a combination of likelihood and impact:

Here, R is a risk score, L is a likelihood rating, and I is an impact rating. In a basic ordinal matrix, both ratings may use values from 1 to 5. The multiplication is a prioritization convention, not a probability law. It is meaningful only when the rating scales and organizational interpretation are defined consistently. A score of 12 is not necessarily twice as dangerous as a score of 6.

A more formal expected-loss model can be written as:

Here, E[L] is expected loss over a defined period, pᵢ is the probability of scenario i during that period, and Cᵢ is its consequence expressed in a chosen unit, such as monetary loss or downtime. The scenarios should be sufficiently defined, probabilities should not be invented without evidence, and consequences may include safety, environmental, legal, reputational, and operational dimensions. In practice, rare catastrophic events may require special treatment rather than being dismissed because their estimated probability is small.

A risk register should record the asset, threat, vulnerability, initiating event, consequence, existing controls, likelihood, impact, risk owner, treatment decision, and review date. Risk treatment may involve reducing, transferring, avoiding, or accepting risk. Acceptance must be explicit and authorized by an accountable owner.

Worked example: a remote maintenance connection

Consider a packaging line whose PLC can be reached through a vendor virtual-private-network connection. Suppose a team rates the likelihood of unauthorized access as 3 on a five-level scale and the impact of an unauthorized logic change as 5. The qualitative score is:

If the organization classifies scores of 10–25 as high, the risk requires treatment. Possible measures include individual accounts, phishing-resistant multifactor authentication, time-limited approval, jump-server access, command and session logging, a read-only default role, offline backups of known-good logic, and an operational procedure requiring local authorization. After controls are implemented, the residual likelihood might be reassessed as 1, while impact remains 5 because a successful logic change would still be severe. The residual score becomes 5. The reduction is due to reduced likelihood, not reduced consequence. This distinction is important when selecting additional safeguards.

3. Secure CPS Architecture

3.1 Zones, conduits, and segmentation

A secure architecture separates systems according to function, consequence, trust, and required communication. A common design places enterprise systems outside the OT environment, uses an OT DMZ for controlled data exchange, and separates supervisory, control, and safety networks. Firewalls should enforce explicit allow-lists rather than relying on broad “internal network” trust.

Segmentation is not merely creating subnets. Effective segmentation includes routing restrictions, protocol filtering, authenticated administration, secure remote access, monitoring, and tested rules. Industrial protocols may be insecure by design, so placing them behind appropriate gateways and restricting their sources and destinations is often necessary.

A practical architecture commonly includes:

1. Field layer: sensors, actuators, drives, and instruments.
2. Control layer: PLCs, remote terminal units, and safety controllers.
3. Supervisory layer: HMIs, historians, alarm servers, and engineering stations.
4. OT DMZ: jump servers, patch repositories, data brokers, and remote-access gateways.
5. Enterprise layer: business systems, analytics, identity services, and email.

Safety systems require special consideration. Independence, fail-safe behavior, manual fallback, and validated safety functions should not be undermined by a shared administrative path. A safety controller may exchange carefully limited status information with a control system while preventing ordinary business credentials from changing the safety logic.

3.2 Secure-by-design principles

The following principles apply throughout the CPS life cycle:

• Least privilege: grant only the permissions required for a defined task.
• Separation of duties: separate programming, approval, deployment, and review where feasible.
• Secure defaults: deny unnecessary services and require explicit enablement.
• Fail-safe and fail-secure behavior: define what happens when communication or authentication fails; safety may require continued local control rather than simply shutting down.
• Minimize attack surface: remove unused accounts, ports, services, and interfaces.
• Complete mediation: check authorization at every sensitive operation, not only at login.
• Defense in depth: combine physical, technical, procedural, and organizational controls.
• Secure maintainability: design for patching, backup, logging, replacement, and recovery.
• Resilience: preserve essential functions during degraded or disconnected operation.

3.3 Authentication and identity

Authentication establishes who or what is requesting access. It should be distinguished from authorization, which determines what the authenticated subject may do. Strong authentication combines factors such as knowledge, possession, and inherence. Passwords alone are weak against phishing, reuse, and credential theft. Multifactor authentication is particularly important for remote access and privileged actions, but it must be engineered so that emergency operation and recovery remain possible.

Machine identities matter as much as human identities. Devices should use unique credentials or certificates rather than shared secrets. Certificate life-cycle management includes issuance, protection of private keys, rotation, revocation, expiration handling, and recovery when a device is replaced.

Accounts should be individual, time-bounded where possible, and reviewed regularly. Shared accounts reduce accountability and should be avoided except where technically unavoidable and governed by compensating controls. Privileged access management can provide approval workflows, credential vaulting, session recording, and automatic expiry.

3.4 Cryptography and protected communication

Encryption provides confidentiality, while message authentication and digital signatures provide integrity and authenticity. A secure channel normally requires:

• authenticated endpoints;
• modern, reviewed cryptographic algorithms and protocols;
• protected private keys;
• certificate validation and revocation or status handling;
• protection against replay, downgrade, and man-in-the-middle attacks; and
• a plan for key rotation and algorithm transition.

Encryption does not make an authorized malicious command safe. If an attacker obtains valid credentials or compromises an endpoint, encrypted traffic may still carry harmful instructions. Encryption also does not replace network segmentation, authorization, or monitoring.

Data should be classified according to sensitivity and consequence. Data in transit and data at rest may require different controls. Logs can contain personal information, credentials, process details, or security-sensitive topology; therefore, logs also require access control, integrity protection, retention rules, and secure time synchronization.

4. Access Control in Operational Technology

Role-based access control (RBAC) assigns permissions to roles such as operator, maintenance technician, engineer, safety specialist, and auditor. Attribute-based access control (ABAC) additionally evaluates attributes such as location, device health, time, work order, process state, and approval status. RBAC is easier to administer; ABAC can express more context but is more complex to validate.

A sound OT policy distinguishes observation from control. An operator may view a trend but not modify logic; a maintenance technician may adjust a drive only under an approved work order; an engineer may edit a program but require a second person to approve deployment. Emergency access should be predefined, strongly authenticated, logged, limited in duration, and reviewed afterward.

Access decisions should account for physical security. A person with access to a cabinet, programming port, removable media, or reset switch may bypass network controls. Physical access is therefore part of the threat model, not an unrelated facilities issue.

5. Secure Software, Firmware, and Configuration Updates

Long-lived OT equipment often contains old operating systems, proprietary firmware, or components that cannot be patched without production interruption. “Patch everything immediately” is not a safe universal rule. Conversely, “never change a running system” leaves known vulnerabilities exposed. A disciplined update process balances security, safety, compatibility, and availability.

A secure update process includes:

1. Maintain an accurate asset and software bill of materials where feasible.
2. Obtain updates from authenticated sources.
3. Verify digital signatures, hashes, version numbers, and device compatibility.
4. Test in a representative staging environment or digital twin where practical.
5. Review safety, timing, configuration, and rollback effects.
6. Back up configurations and preserve a known-good recovery image.
7. Schedule approved maintenance with clear responsibilities.
8. Monitor the update and validate operation afterward.
9. Record evidence, failures, and lessons learned.

A cryptographic hash can detect accidental or deliberate modification when compared with a trusted reference. A digital signature additionally binds the software to a signing identity, provided the signing key and verification process are protected. Secure boot can prevent unauthorized firmware from executing, but it must include a recovery and key-management strategy; otherwise, a lost signing key or corrupted image can create an availability crisis.

Removable media should be controlled through authorization, malware scanning, technical restrictions, and chain-of-custody procedures. Vendor access should be temporary, monitored, and terminated when the work is complete.

6. Monitoring, Detection, and Incident Response

Prevention is insufficient because compromise may occur through unknown vulnerabilities, insiders, supply chains, or stolen credentials. OT monitoring should establish a baseline of normal assets, protocols, command rates, engineering changes, and communication paths. Detection mechanisms should be as passive and low-impact as possible when active scanning could disrupt fragile equipment.

Useful events include repeated authentication failures, new devices, changes to PLC logic, unexpected firmware versions, unusual remote sessions, unauthorized set-point changes, disabled alarms, and communication between zones that normally do not interact. Time synchronization is important for reconstructing events, but loss of an external time source should not make essential control functions unsafe.

An incident-response life cycle commonly includes preparation; detection and analysis; containment; eradication; recovery; and post-incident improvement. OT response differs from ordinary IT response:

• Disconnecting a compromised device may interrupt a critical process.
• Reimaging equipment may destroy forensic evidence or validated configurations.
• A controller cannot necessarily be rebooted during production.
• The safest containment action may be to block a path, switch to local control, or limit commands rather than shut down the whole network.
• Safety, operations, engineering, legal, communications, and management must coordinate.

Incident playbooks should define authority, contact paths, safe-state decisions, evidence handling, alternative communication channels, recovery priorities, and criteria for returning to service. Backups must be offline or otherwise protected from ransomware and should be tested through restoration exercises. Recovery is not complete until configurations, safety functions, monitoring, credentials, and operational procedures have been validated.

7. Privacy and Governance

Privacy engineering begins by asking whether personal data is necessary. Data minimization reduces both privacy exposure and the consequences of a breach. Where data is needed, the organization should define purpose, lawful basis or applicable authority, retention, access, disclosure, correction, and deletion requirements. Workers should receive clear notice about monitoring, and high-risk surveillance should be subject to proportionality and impact assessment.

Governance should assign owners for assets, risks, identities, configurations, suppliers, incident response, and privacy. Policies must be supported by training, technical enforcement, audits, and measurable review. Relevant standards and regulations vary by jurisdiction and sector. Industrial organizations commonly align their programs with recognized cybersecurity frameworks, industrial automation security standards, functional-safety standards, privacy laws, and sector-specific obligations. Compliance is evidence of required practice, not proof that a system is secure.

Supply-chain governance is essential. Procurement should address vulnerability disclosure, security update support, component provenance, secure development, incident notification, remote access, end-of-life planning, and responsibilities after acquisition. A system may be vulnerable because of a third-party library, engineering laptop, cloud service, or maintenance provider even when the plant’s own network is well designed.

Ethically, engineers have duties to protect human safety, communicate residual risk honestly, avoid unnecessary surveillance, preserve professional accountability, and report serious hazards. Security decisions should not shift unreasonable risk to workers merely to preserve production or reduce cost.

8. Applied Case: Illustrative Smart Manufacturing Cell

Background

Consider an illustrative automated machining cell containing a robot, a PLC, a safety controller, networked drives, an HMI, a production historian, and a vendor remote-support connection. The cell operates continuously in three shifts. The HMI and engineering workstation share a flat network with several office-connected computers.

Problem

A maintenance account is shared by several technicians. Remote support uses a permanently enabled VPN account. PLC programs are copied to USB drives without signature verification, and there is no tested offline backup. The safety controller is physically separate but shares a network switch with the control PLC. Operators report occasional unexplained set-point changes.

Analysis

The principal assets are worker safety, robot motion control, product quality, availability, controller logic, credentials, and production data. Threats include credential theft, malicious or accidental program modification, ransomware spreading from an office computer, unauthorized vendor action, and tampering through removable media. The flat network creates a large blast radius, while shared accounts prevent reliable attribution.

A risk register identifies unauthorized logic change as high risk because the consequence could include unsafe motion and long downtime. Ransomware affecting the HMI is also significant, although the PLC may continue local control. The unexplained set-point changes indicate that the issue is not merely theoretical; monitoring and investigation are required.

Approach and solution

The organization first places the cell in an OT zone and establishes an OT DMZ. Vendor access is routed through a hardened jump server, requires individual multifactor authentication, explicit approval, time limits, and session logging. The shared maintenance account is removed and role-based accounts are created.

The engineering workstation receives application allow-listing, restricted removable-media use, protected backups, and a controlled change process. PLC logic is exported to a version-controlled repository, digitally verified where supported, and backed up offline. The safety controller is reviewed for independence and communication is restricted to necessary status exchange. Network rules are changed from broad internal access to explicit source-destination-service allow-lists.

The team creates playbooks for loss of HMI, suspected unauthorized logic change, ransomware, and unsafe robot behavior. A restoration exercise demonstrates that the cell can be returned to a validated configuration. Operators are trained to report unexpected changes and to use local safe-stop procedures.

Outcome

The architecture reduces unauthorized access paths, improves attribution, limits lateral movement, and improves recovery confidence. It does not eliminate risk: a trusted engineer could still make a harmful change, a vulnerability could remain undiscovered, and operational procedures could fail. Continuous review, testing, and safety coordination remain necessary.

Learning points

1. A risk assessment must include physical consequences, not only data confidentiality.
2. Shared credentials undermine both security and investigation.
3. Segmentation is effective only when supported by restrictive rules and monitoring.
4. Backups are a security control only when restoration has been tested.
5. OT incident response must preserve safe operation while containing compromise.
6. Security, safety, privacy, and availability require joint engineering decisions.

9. Contemporary Developments and Limitations

Cloud analytics, industrial Internet of Things devices, 5G connectivity, digital twins, and artificial intelligence can improve maintenance and operational insight, but each introduces dependencies and new attack surfaces. AI-based anomaly detection can identify unusual traffic or process behavior, yet it may generate false positives, miss novel attacks, or be manipulated by poisoned data. It should support—not replace—engineering judgment and deterministic safety controls.

Digital twins can support testing of updates and attack scenarios, but a twin may differ from the real plant and must not be treated as complete evidence. Software bills of materials improve visibility into components, but they do not automatically show exploitability or operational consequence. Cloud services can centralize monitoring but require strong identity, availability planning, data governance, and fallback operation if connectivity is lost.

No control is perfect. Encryption can increase computational load or complicate troubleshooting. Multifactor authentication can hinder emergency access if poorly designed. Segmentation can create operational complexity. Intrusion detection can be difficult where protocols are proprietary or highly time-sensitive. Risk assessments become obsolete as equipment, suppliers, threats, and processes change.

10. Best-Practice Design Checklist

A CPS security program should, at minimum:

• maintain an accurate asset, dependency, and data inventory;
• identify safety, operational, privacy, and security consequences;
• model threats at system, component, human, and supply-chain levels;
• segment IT, OT, safety, and vendor access according to risk;
• use unique identities, least privilege, multifactor authentication, and controlled privilege elevation;
• protect communications and manage cryptographic keys throughout their life cycle;
• control configuration changes, removable media, firmware, and software updates;
• preserve offline, tested backups and recovery procedures;
• monitor relevant events without destabilizing the process;
• rehearse OT-specific incident response with safety and operations personnel;
• govern privacy, retention, supplier responsibilities, and workforce transparency; and
• reassess risks after significant changes, incidents, or newly discovered vulnerabilities.

Chapter Summary

Cybersecurity in cyber-physical and operational-technology systems protects not only information but also physical processes, safety, availability, integrity, and human well-being. Effective practice begins with clearly defined assets, trust boundaries, assumptions, threats, vulnerabilities, and consequences. STRIDE, attack trees, safety analysis, qualitative risk matrices, and expected-loss reasoning provide complementary perspectives.

Secure CPS architectures use segmentation, zones and conduits, least privilege, defense in depth, secure defaults, strong identity, protected communications, and carefully governed remote access. Authentication must cover both people and machines, while authorization should distinguish observation, control, engineering, and emergency functions. Secure update processes require trusted sources, signature verification, testing, backups, rollback, and post-update validation.

Monitoring and incident response must account for physical processes, deterministic operation, safety, evidence preservation, and recovery. Privacy requires minimization, transparency, purpose limitation, retention control, and responsible governance. Finally, cybersecurity is a life-cycle discipline involving engineering, operators, suppliers, management, safety professionals, and affected people. No single technology eliminates risk; resilience comes from layered controls, tested procedures, informed decisions, and continuous improvement.

Key Terms

Asset: A resource or function requiring protection.

Attack surface: The set of interfaces, services, people, and paths through which a system may be attacked.

Availability: The property of being accessible and usable when required.

Confidentiality: Protection against unauthorized disclosure.

Control: A safeguard that reduces likelihood, consequence, or exposure.

Defense in depth: Use of multiple complementary security layers.

Digital signature: A cryptographic mechanism that supports authenticity and integrity of signed data.

Integrity: Protection against unauthorized or accidental alteration.

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

Multifactor authentication: Authentication using two or more independent factor types.

Operational technology: Hardware and software that monitors or controls physical processes.

Privacy: Responsible control of the collection and use of information about identifiable people.

Risk: The possibility that a threat exploits a vulnerability and causes harm.

Risk register: A documented record of risks, controls, owners, and treatment decisions.

Safety: Prevention of unacceptable physical harm or hazardous conditions.

Segmentation: Dividing a network or system into controlled security zones.

Threat model: A structured representation of assets, threats, vulnerabilities, and consequences.

Vulnerability: A weakness that can be exploited or produce unsafe exposure.

Zero trust: An architecture that continuously evaluates access instead of granting implicit trust based on network location.

Review Questions

Short Answer Questions

1. Why do CPS security priorities differ from those of a conventional office information system?
2. Distinguish authentication from authorization.
3. What is the purpose of an OT DMZ?
4. Why are tested backups important for incident recovery?
5. Name two privacy concerns associated with industrial monitoring.

Long Answer Questions

1. Explain how STRIDE can be applied to a robotic manufacturing cell, and identify its limitations.
2. Describe a defense-in-depth architecture for an IT/OT environment, including zones, conduits, identity, and monitoring.
3. Explain how a secure firmware-update process should be designed for a long-lived industrial controller.
4. Compare RBAC and ABAC for OT access control, including benefits and limitations.
5. Describe the stages of OT incident response and explain why they differ from conventional IT incident response.

Analytical / Application Questions

1. A remote maintenance connection has a likelihood rating of 4 and an impact rating of 5 on a five-level qualitative matrix. Calculate the risk score using R = L × I, explain what the score does and does not mean, and propose three controls.
2. An engineering workstation, HMI, PLC, safety controller, vendor gateway, and office laptop currently share one network. Design a revised architecture and justify the placement of each component.
3. A factory wants to deploy AI-based anomaly detection that collects worker identifiers, machine data, and network traffic. Analyze the cybersecurity, safety, privacy, and governance issues that should be resolved before deployment.

Multiple Choice Questions with Answers

Question 1

Which security objective is most directly concerned with preventing unauthorized modification of PLC logic?

A. Confidentiality

B. Integrity

C. Availability

D. Non-repudiation

Correct Answer: B. Integrity

Question 2

In the STRIDE framework, a forged engineering-workstation credential is an example of:

A. Spoofing

B. Tampering

C. Denial of service

D. Information disclosure

Correct Answer: A. Spoofing

Question 3

What is the principal purpose of an OT DMZ?

A. To eliminate the need for authentication

B. To provide a controlled intermediary between enterprise and OT networks

C. To place safety controllers on the public Internet

D. To replace all network monitoring

Correct Answer: B. To provide a controlled intermediary between enterprise and OT networks

Question 4

A risk matrix uses the convention R = L × I. If likelihood is 4 and impact is 5, what is the risk score?

A. 9

B. 16

C. 20

D. 25

Correct Answer: C. 20

Question 5

Which practice best supports accountability for engineering changes?

A. Using one shared administrator account

B. Disabling all logs to improve performance

C. Using individual identities and recording approved changes

D. Allowing permanent vendor access

Correct Answer: C. Using individual identities and recording approved changes

Question 6

Which statement about encryption is correct?

A. Encryption alone guarantees that authorized commands are safe

B. Encryption can support confidentiality, while authentication and integrity controls address other properties

C. Encryption eliminates the need for network segmentation

D. Encryption prevents all insider threats

Correct Answer: B. Encryption can support confidentiality, while authentication and integrity controls address other properties

Question 7

Which update practice is most appropriate for a safety-relevant industrial controller?

A. Install any update immediately without testing

B. Avoid all updates permanently

C. Authenticate the source, test the update, back up the configuration, and validate recovery

D. Copy firmware from an unknown USB drive

Correct Answer: C. Authenticate the source, test the update, back up the configuration, and validate recovery

Question 8

Why can disconnecting a compromised OT device be dangerous?

A. It always increases confidentiality

B. It may interrupt or destabilize a physical process

C. It automatically restores the device

D. It removes the need for incident analysis

Correct Answer: B. It may interrupt or destabilize a physical process

Question 9

Which principle grants a user only the permissions needed for a defined task?

A. Least privilege

B. Open trust

C. Maximum availability

D. Data duplication

Correct Answer: A. Least privilege

Question 10

Which privacy practice reduces exposure by limiting collection to what is necessary for a defined purpose?

A. Data minimization

B. Credential sharing

C. Permanent retention

D. Unrestricted disclosure

Correct Answer: A. Data minimization