Cybersecurity, Privacy, and Resilience

Introduction and Context

Cybersecurity, privacy, and resilience are closely related but distinct dimensions of dependable computing. Cybersecurity concerns the protection of systems, networks, applications, data, and users against unauthorized actions or harmful events. Privacy concerns the appropriate collection, use, disclosure, retention, and deletion of information about identifiable people. Resilience concerns the capacity of an organization or system to anticipate, withstand, recover from, and adapt to disruption.

Modern organizations depend on cloud platforms, mobile devices, application programming interfaces, software supply chains, artificial intelligence, and interconnected operational technologies. This interdependence creates value but also expands the attack surface and increases the consequences of failure. A vulnerability in a software library, a compromised credential, a misconfigured storage service, or an unethical use of personal data can affect millions of people.

Security is therefore not merely a technical property. It is a socio-technical discipline involving engineering, human behavior, organizational governance, economics, law, and ethics. Effective practice combines preventive controls with detection, response, recovery, and institutional learning.

Learning Objectives

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

1. Distinguish cybersecurity, information security, privacy, safety, and resilience.
2. Explain the confidentiality, integrity, and availability model and its limitations.
3. Analyze threats, vulnerabilities, risks, controls, and attack surfaces.
4. Compare authentication, authorization, cryptographic, network, and application controls.
5. Apply risk, incident-response, privacy, and resilience frameworks to practical situations.
6. Evaluate security decisions in ethical, legal, organizational, and societal contexts.
7. Design a layered security and recovery strategy for a realistic information system.

Foundational Concepts

Assets, threats, vulnerabilities, and risk

An asset is something of value, such as data, software, infrastructure, a service, intellectual property, reputation, or human safety. A threat is a potential cause of harm. Threat actors may include criminals, insiders, competitors, activists, intelligence services, or accidental users. A vulnerability is a weakness that can be exploited or triggered. An exploit is a method for taking advantage of a vulnerability.

Risk expresses the possibility that a threat will exploit a vulnerability and produce harm. A simple qualitative model is:

Likelihood represents the estimated chance or frequency of an adverse event; impact represents its consequences. This relationship is a decision aid rather than a universal law. In formal quantitative analysis, likelihood may be represented as an annual probability and impact as monetary loss, service downtime, safety consequences, or another defined measure. The units of the resulting risk estimate depend on the chosen model. Risk assessments must state assumptions because estimates are uncertain and may be correlated.

Risk treatment generally involves avoiding, reducing, transferring, or accepting risk. Insurance may transfer part of a financial consequence, but it does not remove technical, legal, or social harm. Risk acceptance should be explicit, authorized, time-bounded, and reviewed.

The CIA triad

The classical CIA triad identifies three security objectives:

The triad is useful but incomplete. Authenticity establishes that an entity or message is genuine. Accountability and non-repudiation support attribution and auditability. Safety addresses prevention of physical injury or dangerous operation. Resilience adds the ability to continue and recover under adverse conditions. A highly confidential system that is unavailable to legitimate users may still fail its mission.

Attack surface and defense in depth

The attack surface is the collection of exposed interfaces, services, identities, devices, dependencies, and processes through which harm may occur. Internet-facing endpoints, administrative interfaces, third-party libraries, employees, contractors, removable media, and cloud permissions can all enlarge the attack surface.

Defense in depth uses multiple, partially independent layers. Typical layers include governance, physical protection, identity management, endpoint security, network segmentation, secure application design, data protection, monitoring, and recovery. Layering is valuable because no individual control is perfect. However, layers that share the same credentials, configuration source, or failure dependency may provide less independence than expected.

Threats and Attack Patterns

Common attack patterns include phishing, credential stuffing, malware, ransomware, denial of service, exploitation of unpatched software, injection attacks, insecure direct object references, insider misuse, supply-chain compromise, and social engineering. Threats may be opportunistic or targeted. Attackers frequently combine techniques: a phishing message may steal credentials, which are then used to access a virtual private network, escalate privileges, exfiltrate data, and encrypt systems.

A useful analytical sequence is:

1. Identify assets and business processes.
2. Map trust boundaries and data flows.
3. Enumerate plausible threat actors and events.
4. Identify vulnerabilities and existing controls.
5. Estimate likelihood and impact.
6. Select treatments and define residual risk.
7. Monitor, test, and revise assumptions.

Threat modeling methods such as STRIDE categorize threats using concepts including spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The method is not a substitute for expert judgment; it is a structured way to expose omissions during design.

Identity, Authentication, and Authorization

Identity management establishes who or what an entity is. Authentication verifies a claimed identity, while authorization determines what that identity may do. Auditing records relevant activity for later investigation and accountability.

Authentication factors are commonly classified as:

• Something known, such as a password or personal identification number.
• Something possessed, such as a hardware security key or authenticator device.
• Something inherent, such as a biometric characteristic.

Multi-factor authentication combines factors from different categories. Two passwords are not two independent factors. Strong systems use phishing-resistant methods where feasible, such as hardware-backed cryptographic credentials.

Authorization models include discretionary access control, role-based access control, attribute-based access control, and policy-based approaches. The principle of least privilege grants only the permissions necessary for a task, for only as long as necessary. Separation of duties prevents one individual or account from completing a sensitive process without independent review.

Passwords should be stored using a password-hashing function with a unique salt and an appropriately costly configuration. Encryption is not a substitute for password hashing: encryption is designed for reversible confidentiality, whereas password hashing is designed to resist recovery of the original password.

Cryptographic Foundations

Cryptography supports confidentiality, integrity, authentication, and key management.

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient for large data volumes, but the key must be securely shared. Asymmetric cryptography uses a public key and a private key. It supports public-key encryption, digital signatures, and key establishment, but is generally more computationally expensive.

A cryptographic hash maps an input to a fixed-length digest. Secure hash functions should make it computationally infeasible to find a preimage, a second input with the same digest, or a practical collision. A hash alone does not prove who created a message. A message authentication code uses a shared secret to provide integrity and source authentication. A digital signature uses a private key to sign and a public key to verify.

Encryption in transit protects communication across networks; encryption at rest protects stored information. Neither automatically protects data while it is being processed, exposed through an application, or accessed by an authorized but malicious user. Key management—generation, distribution, rotation, storage, revocation, and destruction—is often more difficult than selecting an algorithm.

Secure Software and Systems Engineering

Security must be integrated into the software development life cycle. Secure requirements identify assets, trust boundaries, misuse cases, regulatory obligations, and recovery needs before implementation. Secure design applies least privilege, fail-safe defaults, input validation, secure error handling, strong session management, and explicit authorization checks.

Developers should avoid constructing database queries by concatenating untrusted input. Parameterized queries reduce injection risk. Output encoding helps prevent cross-site scripting, but the correct encoding depends on the output context. Secrets should not be embedded in source code or container images. Dependencies should be inventoried, updated, scanned, and obtained from trustworthy sources.

Testing may include static analysis, dynamic testing, dependency analysis, fuzzing, penetration testing, code review, configuration assessment, and red-team exercises. Automated tools produce false positives and false negatives; findings require skilled interpretation. Security testing cannot prove the absence of vulnerabilities.

A secure default configuration, timely patching, asset inventory, vulnerability prioritization, and controlled change management are foundational operational practices. Emergency patching should be balanced with testing and rollback planning, especially in safety-critical or highly available environments.

Privacy as a Design and Governance Problem

Privacy is not identical to secrecy. A person may reasonably expect appropriate control, purpose limitation, contextual integrity, and fair treatment even when information is not secret. Privacy engineering addresses data collection, processing, sharing, retention, deletion, and inference throughout the system life cycle.

Important principles include:

• Purpose limitation: collect and use data for specified legitimate purposes.
• Data minimization: collect only what is necessary.
• Accuracy: provide mechanisms for correcting significant errors.
• Storage limitation: retain information no longer than justified.
• Transparency: explain processing in understandable language.
• Accountability: assign responsibility and demonstrate compliance.
• Security: protect data against unauthorized or harmful processing.

Pseudonymization replaces direct identifiers but does not necessarily make data anonymous. Re-identification may be possible by linking datasets. Anonymization is context-dependent and difficult to guarantee, particularly when datasets are rich or repeatedly released. Differential privacy provides a formal approach to limiting the influence of one person's data on an output, but it introduces a privacy–utility trade-off and requires careful management of the privacy budget.

Privacy impact assessments should examine data flows, purposes, affected groups, risks, controls, retention, third-party access, and mechanisms for rights exercise. Laws differ across jurisdictions, but responsible practice should not be reduced to legal compliance. Ethical duties may arise even where regulation is unclear.

Resilience and Continuity

Resilience is broader than backup. It includes anticipation, prevention, absorption, adaptation, recovery, and learning. Business continuity identifies critical services and acceptable disruption. Disaster recovery restores technology and data. Crisis management coordinates decisions, communications, authority, and stakeholder relationships.

A business impact analysis identifies critical processes, dependencies, maximum tolerable downtime, and recovery priorities. Two common measures are:

• Recovery time objective (RTO): the maximum targeted time within which a service should be restored after disruption.
• Recovery point objective (RPO): the maximum targeted age of data that may be lost, measured in time.

For example, an RPO of 15 minutes means that, under the recovery design, the organization aims to lose no more than approximately 15 minutes of recent data. It does not guarantee that exactly 15 minutes will be lost.

Resilience controls include redundancy, geographic distribution, graceful degradation, rate limiting, offline or immutable backups, alternate communications, manual workarounds, tested restoration, and supplier contingency plans. Redundancy can increase complexity and correlated failure; therefore, systems must be tested under realistic failure scenarios.

Incident response commonly includes preparation; detection and analysis; containment; eradication; recovery; and post-incident activity. These stages are iterative rather than strictly linear. Evidence preservation, legal obligations, communications, and protection of affected people must be considered alongside technical containment.

Measuring Security and Resilience

Metrics should support decisions rather than reward superficial activity. Useful measures may include mean time to detect, mean time to contain, percentage of critical assets with tested backups, time to remediate high-risk vulnerabilities, phishing-resistant authentication coverage, and recovery exercise success.

Averages can conceal severe outliers. Metrics should therefore include scope, sampling method, time period, confidence or uncertainty where relevant, and definitions. A low incident count may indicate effective prevention—or inadequate detection and reporting. Similarly, a high patching percentage may hide unpatched systems that are especially exposed.

Security economics requires comparing control costs with expected loss reduction, while recognizing that catastrophic and systemic events may not be well represented by historical averages. Qualitative judgment remains important where data are sparse.

Illustrative Case: Ransomware in a University Research Hospital

Background

This illustrative case concerns a hospital whose clinical scheduling, laboratory, imaging, and billing systems share identity services and several network segments. Researchers also use cloud storage and external collaborators.

Problem

An employee receives a convincing message and enters credentials into a fraudulent portal. Attackers use the credentials to access remote services, obtain elevated privileges through a poorly governed administrator account, and deploy ransomware. Some file servers are encrypted. Backups are connected to the production domain and are also affected. Clinical staff revert to paper procedures, while public communication is delayed because leadership lacks an agreed crisis protocol.

Analysis

The event is not explained by phishing alone. Contributing conditions include insufficient phishing-resistant authentication, excessive privilege, weak network segmentation, incomplete asset inventory, inadequate monitoring of privileged actions, and untested backup isolation. The incident affects availability and integrity directly, while confidentiality is also at risk because attackers may exfiltrate information before encryption. Patient safety becomes a central concern because clinical decisions depend on timely and accurate records.

Approach and solution

The hospital establishes an incident command structure and prioritizes patient safety. It isolates affected segments, preserves evidence, disables compromised accounts, and communicates through verified channels. Recovery begins with clean, offline or immutable backups and documented restoration priorities. Longer-term measures include phishing-resistant multi-factor authentication, privileged access management, segmentation of clinical technology, centralized logging, endpoint detection, tested restoration, supplier reviews, tabletop exercises, and privacy notifications where required.

Outcome and learning points

Recovery is slower than originally expected because dependencies were undocumented and restoration procedures had not been rehearsed. The hospital subsequently defines service priorities, RTOs, and RPOs with clinical leaders rather than treating them as purely technical values. The central lesson is that resilience depends on governance, people, architecture, and repeated practice. A control that exists on paper but is not tested cannot be assumed to work during crisis.

Ethical, Legal, and Governance Considerations

Security professionals have responsibilities to users, employers, affected communities, and the public. Responsible disclosure balances the need to notify affected parties with the need to prevent exploitation. Monitoring must be proportionate, transparent, and governed; excessive surveillance can violate privacy and damage trust. Automated security systems may produce discriminatory impacts if training data or decision rules are biased.

Governance should define ownership, risk appetite, policy exceptions, escalation routes, independent review, and consequences for noncompliance. Boards and senior managers must receive comprehensible information about material risks rather than purely technical dashboards. Third-party and supply-chain risk requires contractual controls, assurance evidence, incident notification arrangements, and an understanding of concentration risk.

Regulatory obligations vary by jurisdiction and sector. They may concern breach notification, critical infrastructure, records retention, consumer protection, health data, financial data, or cross-border transfers. Legal advice is necessary for specific obligations. Technical teams should nevertheless design systems that support evidence, access requests, correction, deletion where applicable, and accountable decision-making.

Contemporary Developments

Cloud-native systems, containers, infrastructure as code, zero-trust architectures, software bills of materials, confidential computing, and automated detection are changing security practice. Zero trust does not mean trusting nothing in an absolute sense; it means making access decisions using explicit, continuously evaluated evidence rather than relying solely on network location.

Artificial intelligence can assist with anomaly detection, code analysis, alert triage, and incident summarization. It can also generate vulnerable code, amplify phishing, expose sensitive prompts, create misleading explanations, and increase the scale of attacks. AI systems require protection against data poisoning, prompt injection, model theft, unauthorized inference, and insecure tool use. Human oversight, evaluation against representative cases, provenance, access control, and rollback are essential.

Quantum computing may affect some widely used public-key schemes in the long term. Organizations with long-lived confidential data should monitor post-quantum cryptography standards and assess cryptographic inventory and migration difficulty. This is a planning issue, not a reason to abandon currently appropriate controls without a validated replacement.

Best-Practice Design Pattern

A mature program usually combines the following activities:

1. Maintain an accurate inventory of assets, data, identities, dependencies, and owners.
2. Classify information and define security and privacy requirements.
3. Apply secure-by-design principles and threat modeling.
4. Use strong identity, least privilege, segmentation, encryption, and secure configuration.
5. Monitor continuously, with logs protected from unauthorized alteration.
6. Patch and remediate according to risk, exposure, exploitability, and business criticality.
7. Prepare incident, continuity, and disaster-recovery plans.
8. Test controls through exercises, restoration drills, audits, and adversarial assessment.
9. Measure meaningful outcomes and review residual risk.
10. Learn from incidents without concealing failures or blaming individuals for systemic weaknesses.

No framework eliminates risk. Frameworks such as the NIST Cybersecurity Framework, ISO/IEC 27001, CIS Controls, and sector-specific standards provide useful structures, but implementation must reflect organizational context and legal requirements.

Chapter Summary

Cybersecurity protects systems and information from harmful or unauthorized actions; privacy governs appropriate processing of information about people; resilience enables organizations to continue, recover, and learn during disruption. The CIA triad provides a foundation, but authenticity, accountability, safety, and recoverability are also important. Risk analysis connects assets, threats, vulnerabilities, likelihood, and impact, while defense in depth reduces dependence on any one control.

Identity and authorization must enforce least privilege and separation of duties. Cryptography requires correct algorithms, sound protocols, and disciplined key management. Secure software development integrates threat modeling, validation, dependency management, testing, and operational monitoring. Privacy requires minimization, purpose limitation, transparency, retention control, and accountability. Resilience depends on business impact analysis, defined RTOs and RPOs, isolated backups, continuity planning, and tested recovery.

Finally, cybersecurity is a socio-technical and governance problem. Ethical judgment, regulation, supply-chain management, human factors, AI, and organizational learning strongly influence outcomes. Effective programs measure meaningful results and continually adapt to changing threats.

Key Terms

Asset: A resource, process, capability, or information of value.

Attack surface: The exposed interfaces and conditions through which a system may be attacked.

Authentication: Verification of a claimed identity.

Authorization: Determination of what an authenticated entity may do.

Availability: Accessibility of systems or data to authorized users when needed.

Confidentiality: Protection against unauthorized disclosure.

Defense in depth: Use of multiple protective layers.

Differential privacy: A formal method for limiting the effect of one person's data on an output.

Integrity: Preservation of correctness, completeness, and authenticity.

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

Privacy impact assessment: Structured analysis of privacy risks and controls.

Recovery point objective: Target maximum age of data that may be lost after disruption.

Recovery time objective: Target maximum time for restoring a service.

Resilience: Capacity to withstand, recover from, adapt to, and learn from disruption.

Risk: Possibility of harm arising from uncertain events.

Threat: Potential cause of harm.

Vulnerability: Weakness that can be exploited or triggered.

Zero trust: An architecture based on explicit, continuously evaluated access decisions rather than implicit network trust.

Review Questions

Short Answer Questions

1. Distinguish a threat, vulnerability, exploit, and risk.
2. What are the three elements of the CIA triad?
3. Why is multi-factor authentication stronger when factors come from different categories?
4. Define RTO and RPO.
5. Why is pseudonymization not necessarily anonymization?

Long Answer Questions

1. Explain defense in depth and evaluate its advantages and limitations.
2. Describe how cryptography supports confidentiality, integrity, and authentication, including the role of key management.
3. Explain how privacy-by-design principles influence data collection, storage, sharing, and deletion.
4. Describe the stages of incident response and explain why they are iterative.
5. Discuss why cybersecurity should be treated as a socio-technical governance problem rather than only a technical problem.

Analytical / Application Questions

1. A cloud application stores medical records, uses contractors, and exposes an administrative interface to the internet. Identify its principal assets, trust boundaries, threats, vulnerabilities, and recommended controls.
2. An organization has daily backups but an RPO of 15 minutes and an RTO of 2 hours. Analyze whether daily backups satisfy the stated objectives and propose a better recovery design.
3. A university wants to deploy an AI system that predicts student risk using behavioral data. Analyze the security, privacy, fairness, transparency, retention, and governance issues before deployment.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication verifies identity; authorization determines permitted actions.

B. Authentication encrypts data; authorization compresses data.

C. Authentication defines backups; authorization defines recovery time.

D. Authentication detects malware; authorization removes malware.

Correct Answer: A. Authentication verifies identity; authorization determines permitted actions.

Question 2

A system has strong confidentiality but is unavailable to authorized users during required operating hours. Which CIA property is primarily failing?

A. Confidentiality

B. Integrity

C. Availability

D. Non-repudiation

Correct Answer: C. Availability

Question 3

Which control most directly supports the principle of least privilege?

A. Giving every employee administrator rights

B. Granting only task-required permissions and reviewing them periodically

C. Using the same account for all administrators

D. Disabling audit logs

Correct Answer: B. Granting only task-required permissions and reviewing them periodically

Question 4

What does an RPO of 15 minutes specify?

A. The maximum planned time to restore service

B. The maximum target age of data that may be lost

C. The maximum password lifetime

D. The maximum time allowed for vulnerability scanning

Correct Answer: B. The maximum target age of data that may be lost

Question 5

Why is a password-hashing function preferred to reversible encryption for password storage?

A. Hashing is designed to make recovery of the original password difficult

B. Hashing allows administrators to read every password

C. Encryption cannot protect data at rest

D. Hashing eliminates the need for unique salts

Correct Answer: A. Hashing is designed to make recovery of the original password difficult

Question 6

Which practice most directly reduces SQL injection risk?

A. Disabling backups

B. Concatenating user input into queries

C. Using parameterized queries

D. Increasing screen brightness

Correct Answer: C. Using parameterized queries

Question 7

Which statement about pseudonymization is correct?

A. It always guarantees that re-identification is impossible

B. It replaces identifiers but linkage may still permit re-identification

C. It is identical to deleting all personal data

D. It prevents unauthorized access without any other control

Correct Answer: B. It replaces identifiers but linkage may still permit re-identification

Question 8

Which activity is most characteristic of resilience engineering?

A. Relying exclusively on prevention

B. Testing restoration from isolated backups and rehearsing failure procedures

C. Removing all monitoring to reduce costs

D. Granting broad access during normal operations

Correct Answer: B. Testing restoration from isolated backups and rehearsing failure procedures

Question 9

In a risk model expressed as Risk ≈ Likelihood × Impact, what does impact represent?

A. The estimated consequence of the adverse event

B. The number of passwords in the system

C. The encryption key length only

D. The number of software developers

Correct Answer: A. The estimated consequence of the adverse event

Question 10

What is a central idea of zero-trust architecture?

A. All internal network traffic is automatically trusted

B. Access decisions rely on explicit and continuously evaluated evidence

C. Authentication is unnecessary inside the organization

D. Perimeter firewalls eliminate the need for endpoint controls

Correct Answer: B. Access decisions rely on explicit and continuously evaluated evidence