Foundations of Data Security

Introduction

Data security is the disciplined protection of data, information systems, and data-processing activities from unauthorized disclosure, improper alteration, destruction, misuse, and unjustified interruption. For data-science professionals, security is not a peripheral IT concern. Data scientists collect, transform, combine, model, publish, and operationalize data; each activity can create exposure. A dataset may contain personal information, commercially sensitive records, intellectual property, health information, or evidence used in consequential decisions. Security therefore influences the entire data lifecycle: acquisition, storage, preparation, analysis, sharing, deployment, retention, and disposal.

A sound security program begins with a conceptual vocabulary. Confidentiality, integrity, and availability describe primary protection objectives. Authenticity, accountability, non-repudiation, and privacy extend those objectives into questions of identity, responsibility, evidence, and individual rights. Other terms—threat, vulnerability, attack, risk, control, asset, exposure, and trust boundary—help professionals reason about how security failures occur and how they can be prevented or contained.

Security is also contextual. A control that is appropriate for a public dashboard may be inadequate for a clinical database. A highly restrictive system may protect confidentiality while making legitimate analysis impossible. Effective security balances protection, usability, operational resilience, legal obligations, and the social consequences of data use.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain confidentiality, integrity, availability, authenticity, accountability, non-repudiation, and privacy.
2. Distinguish assets, threats, vulnerabilities, attacks, risks, controls, residual risk, and trust boundaries.
3. Analyze how contemporary threat actors select targets and exploit attack surfaces.
4. Apply security principles to data-science platforms and organizational workflows.
5. Evaluate security controls in relation to technical, managerial, ethical, and regulatory requirements.
6. Explain why security and privacy are related but not identical objectives.

1. The Security Objectives

1.1 Confidentiality

Confidentiality means that information is accessible only to authorized entities and used only for authorized purposes. Authorization may depend on identity, role, purpose, location, time, or other conditions. Encryption, access control, data masking, network segmentation, and secure disposal are common confidentiality controls.

Confidentiality has at least three dimensions:

• Disclosure prevention: preventing unauthorized reading or inference.
• Use limitation: preventing authorized users from using data beyond their permitted purpose.
• Information-flow control: restricting movement between environments, classifications, or jurisdictions.

Confidentiality can fail without a conventional data breach. For example, a model may reveal membership in a sensitive training dataset, or an apparently anonymous dataset may be re-identified by joining it with public records.

1.2 Integrity

Integrity is the protection of data and systems against unauthorized or improper modification, deletion, fabrication, or reordering. Integrity also includes correctness and completeness when those properties are necessary for a process.

A transaction database requires accurate records; a machine-learning pipeline requires trustworthy training data, labels, features, code, and model artifacts. Hashes, digital signatures, input validation, immutable logs, version control, checksums, separation of duties, and reconciliation procedures support integrity.

Integrity is not identical to accuracy. A dataset may be inaccurate because it was collected poorly, even though no attacker modified it. Security integrity controls address unauthorized or uncontrolled change; data-quality programs address broader correctness problems. The two areas overlap in practice.

1.3 Availability

Availability means that authorized users and processes can access systems and data when required, with an acceptable level of performance. Backups, redundancy, failover, capacity planning, disaster recovery, patching, denial-of-service protection, and incident response contribute to availability.

Availability is not absolute. Organizations normally define recovery objectives:

• Recovery Point Objective (RPO): the maximum acceptable amount of data loss measured in time. An RPO of one hour means that, after a disruption, the organization aims to lose no more than approximately one hour of transactions.
• Recovery Time Objective (RTO): the target maximum time required to restore a service after disruption.

RPO and RTO are business requirements, not universal technical constants. A research archive may tolerate days of recovery, whereas a payment system may require near-continuous operation.

1.4 Authenticity

Authenticity is confidence that an entity, message, dataset, or system is genuine and what it claims to be. Authentication establishes identity or provenance; authorization determines what an authenticated entity may do.

Examples include:

• multi-factor authentication for a user;
• certificates for a service;
• signed software packages;
• provenance records for a dataset;
• verified source addresses in a communication protocol.

Authentication alone does not establish trustworthy behavior. A valid employee account may be compromised, and a genuine dataset may contain biased or erroneous measurements.

1.5 Accountability

Accountability is the ability to associate actions with responsible identities, processes, or organizations and to evaluate whether those actions were appropriate. It depends on reliable identity management, logging, monitoring, policy, and investigation.

A shared administrator account weakens accountability because actions cannot be attributed to a specific person. Strong accountability uses individual accounts, privileged-access management, tamper-evident logs, time synchronization, documented procedures, and regular review. Accountability also requires fair governance: monitoring should be proportionate, transparent, and limited to legitimate purposes.

1.6 Non-repudiation

Non-repudiation is evidence that supports a claim about the origin, receipt, approval, or integrity of an action, making unjustified denial more difficult. Digital signatures, trusted timestamps, signed transactions, and controlled audit trails can contribute to non-repudiation.

Non-repudiation is frequently overstated. A digital signature can demonstrate that a private key signed a message, but it does not by itself prove who controlled the key at the time, whether the signer understood the transaction, or whether the surrounding system was uncompromised. Legal non-repudiation depends on technical evidence, key management, identity assurance, policy, and applicable law.

1.7 Privacy

Privacy concerns appropriate collection, use, disclosure, retention, and deletion of information about identifiable or identifiable individuals. It includes autonomy, contextual integrity, purpose limitation, transparency, data minimization, and rights over personal information.

Privacy and confidentiality overlap but are not synonyms. Confidentiality asks whether unauthorized parties can access information. Privacy additionally asks whether the information should have been collected, whether its use is justified, whether the subject was informed, and whether the use is proportionate. An organization may keep a database confidential while still violating privacy by collecting excessive data or using it for an undisclosed purpose.

Privacy engineering translates these concerns into system practices such as minimization, pseudonymization, aggregation, differential privacy, configurable retention, consent or lawful-basis management, and privacy impact assessment. Pseudonymization reduces direct identifiability but does not necessarily make data anonymous; auxiliary information may permit re-identification.

2. A Unified Protection Model

The traditional CIA triad—confidentiality, integrity, and availability—remains a useful starting point, but modern data environments require additional properties. Authenticity supports trustworthy identity and provenance. Accountability supports investigation and governance. Non-repudiation supports evidentiary confidence. Privacy addresses legitimate and ethical treatment of individuals.

These properties may conflict. Strong encryption can improve confidentiality but complicate availability if keys are lost. Extensive logging can improve accountability but create a new repository of sensitive personal information. Data minimization can reduce privacy risk but limit analytical utility. Security architecture is therefore an exercise in managing trade-offs rather than maximizing one property in isolation.

A practical protection analysis asks:

1. What assets require protection?
2. Who may access them, for what purpose, and under what conditions?
3. What could go wrong, and what consequences would follow?
4. Which controls prevent, detect, respond to, or recover from those events?
5. What risk remains after controls are applied?
6. How will the organization know whether controls continue to work?

3. Essential Security Vocabulary

3.1 Assets and data value

An asset is anything valuable that requires protection. Assets include raw data, derived datasets, models, source code, credentials, cryptographic keys, computation capacity, staff expertise, reputation, and legal standing. Asset value is context-dependent. A public weather dataset may have low confidentiality requirements but high integrity and availability requirements if it supports emergency planning.

Data classification makes protection requirements explicit. Typical classifications include public, internal, confidential, and restricted, although organizations should define categories appropriate to their operations. Classification should consider sensitivity, regulatory obligations, business impact, data subject expectations, and consequences of compromise.

3.2 Threat

A threat is a potential cause of harm. Threats may be intentional or accidental, human or environmental, internal or external. Examples include credential theft, malicious insiders, software defects, power failure, fire, flood, supply-chain compromise, and accidental disclosure.

A threat actor is the person, group, organization, or automated system capable of initiating a harmful event. Capability, motivation, resources, access, and persistence distinguish different actors.

3.3 Vulnerability

A vulnerability is a weakness that can be exploited or can otherwise contribute to harm. Examples include an unpatched service, excessive permissions, weak authentication, exposed storage, insecure defaults, ambiguous ownership, inadequate backups, and poor staff training.

Vulnerabilities are not limited to software defects. Organizational weaknesses—such as unclear retention rules or an unreviewed vendor—can be equally significant.

3.4 Attack and attack vector

An attack is a deliberate attempt to compromise confidentiality, integrity, availability, authenticity, accountability, or privacy. An attack vector is the path or technique used, such as phishing, credential stuffing, exploitation of a vulnerable API, malicious code, physical access, or abuse of a cloud identity.

An attack may be successful even when no single vulnerability appears severe. Attackers often chain weaknesses: a phishing message obtains a low-privilege account, that account accesses a development environment, a leaked secret permits cloud access, and excessive permissions enable data exfiltration.

3.5 Risk

Risk is the possibility of adverse consequences arising from uncertainty. In security practice, risk analysis commonly relates a scenario’s likelihood to its impact. A simple qualitative model uses categories such as low, moderate, and high rather than pretending that uncertain judgments are precise numerical probabilities.

Where quantitative estimation is justified, expected loss can be represented as:

Here, EL is expected loss in monetary units, p is the probability of the specified loss event during a defined period, and I is the impact if it occurs. This model assumes that the event definition, time period, probability estimate, and impact estimate are comparable. It is useful for a clearly bounded scenario, but it can mislead when probability data are weak, impacts are non-monetary, or events are dependent. It should not be treated as a complete security-risk model.

Risk analysis should identify inherent risk before controls and residual risk after controls. Risk appetite expresses how much risk an organization is willing to accept; risk tolerance sets acceptable variation around objectives. These are governance decisions, not solely technical decisions.

3.6 Control

A control is a safeguard or countermeasure that modifies risk. Controls may be:

• Preventive: stop an unwanted event, such as least-privilege access.
• Detective: identify an event, such as anomaly monitoring.
• Corrective: restore an acceptable state, such as malware removal.
• Deterrent: discourage behavior, such as sanctions or visible monitoring.
• Compensating: provide an alternative safeguard when the preferred control is impractical.
• Recovery-oriented: restore operations, such as tested backups.

Controls can also be administrative, technical, or physical. A policy is not effective merely because it exists; its design, implementation, coverage, usability, and continuous verification determine its practical value.

3.7 Exposure, attack surface, and trust boundary

Exposure describes the extent to which an asset or capability is accessible to potential threats. The attack surface is the collection of points through which an attacker might enter, influence, observe, or disrupt a system. It includes internet-facing services, APIs, identities, endpoints, data stores, cloud configurations, software dependencies, machine-learning interfaces, personnel, and physical facilities.

A trust boundary is a boundary across which assumptions about identity, authority, security controls, or data correctness change. Examples include the boundary between a public network and an internal service, between a notebook environment and a production database, or between an organization and a cloud provider. Crossing a trust boundary should require explicit validation rather than implicit trust.

4. Threat Actors and Contemporary Attack Surfaces

4.1 Threat-actor categories

Cybercriminal groups generally seek financial gain through ransomware, fraud, extortion, credential theft, or sale of data. They may use commercial malware, affiliate models, and automated scanning.

Nation-state and state-sponsored groups may pursue espionage, strategic advantage, influence, intellectual property, or disruption. They often possess substantial resources and may exploit suppliers or maintain long-term access.

Insiders include employees, contractors, partners, and administrators. Insider risk may be malicious, negligent, coerced, or accidental. Privileged insiders are especially important because they can bypass ordinary controls.

Hacktivists are motivated by political or social objectives and may conduct defacement, data exposure, or denial-of-service attacks.

Competitors and industrial-espionage actors may seek proprietary models, research, customer information, or strategic plans.

Opportunistic attackers use automated tools to exploit common weaknesses without selecting a target personally. Internet exposure and weak credentials can therefore create risk even without a high-profile adversary.

Threat-actor labels are analytical aids, not fixed identities. A criminal group may use a technique associated with espionage, and a state actor may outsource activity to criminal intermediaries.

4.2 Attack surfaces in data-science environments

A modern data platform commonly includes collection devices, web applications, APIs, message queues, object storage, relational and NoSQL databases, notebooks, orchestration tools, code repositories, feature stores, model registries, containers, cloud identities, monitoring systems, and third-party services. Every connection and identity can enlarge the attack surface.

Important exposure areas include:

• Identity and access: stolen passwords, long-lived tokens, excessive privileges, unmanaged service accounts, and weak recovery processes.
• Data ingestion: poisoned records, malicious files, unsafe parsers, falsified provenance, and unvalidated external feeds.
• Cloud configuration: public storage, permissive security groups, exposed management interfaces, and incorrectly scoped roles.
• Software supply chains: vulnerable dependencies, compromised packages, malicious container images, and unreviewed code.
• Machine-learning systems: training-data poisoning, model theft, adversarial inputs, membership inference, prompt injection in AI-enabled applications, and leakage through outputs.
• Human interfaces: phishing, social engineering, insecure sharing, and accidental publication.
• Operational technology and edge devices: weakly protected sensors, outdated firmware, and physical tampering.

The attack surface should be mapped by data flow and privilege, not only by counting servers. A small service with write access to a sensitive dataset may be more important than a large public website.

4.3 Attack paths and threat modeling

Threat modeling is a structured method for identifying assets, trust boundaries, entry points, adversaries, abuse cases, and controls. Useful approaches include data-flow diagrams, attack trees, misuse cases, STRIDE-style categories, and adversary-behavior frameworks such as MITRE ATT&CK.

A data-flow analysis should identify:

1. sources and destinations of data;
2. transformations and validation steps;
3. identities and privileges at each stage;
4. storage locations and retention periods;
5. trust boundaries and external dependencies;
6. possible confidentiality, integrity, availability, and privacy failures.

Threat modeling is most valuable early in design, but it should be revisited when data sources, models, vendors, interfaces, or business purposes change.

5. Security Principles for Data Professionals

Least privilege

Each user, service, and process should receive only the access required for an authorized task, for the shortest practical duration. Least privilege limits blast radius when credentials are stolen or software is compromised. It requires role design, permission review, temporary elevation, and removal of obsolete accounts.

Separation of duties

Critical actions should not depend on one individual or one unchecked process. For example, the person who develops a model need not be the sole person approving its deployment to a regulated decision system. Separation reduces fraud and error, but excessive separation can create operational friction; responsibilities should be proportionate to risk.

Defense in depth

Protection should use multiple independent or partially independent layers. Authentication, authorization, encryption, network segmentation, monitoring, backups, and incident response may each fail, but their combination can reduce the probability and impact of compromise.

Secure by design and by default

Security requirements should be built into architecture, interfaces, data schemas, and workflows rather than added after deployment. Default settings should minimize exposure, use strong authentication, restrict sharing, and avoid collecting unnecessary data.

Zero-trust thinking

Zero trust does not mean that no trust is ever possible. It means that access decisions should not rely solely on network location or prior access. Each request should be evaluated using identity, device or workload context, resource sensitivity, policy, and current conditions. Continuous verification and segmentation are particularly useful in hybrid-cloud environments.

Fail safely and recoverably

When validation or authorization fails, the system should avoid granting unintended access. Recovery mechanisms should be tested, protected from the same failure as primary systems, and designed around defined RPO and RTO requirements.

Secure logging

Logs should support detection and accountability without becoming an uncontrolled source of sensitive data. Organizations should define event types, timestamps, identities, retention, access restrictions, integrity protection, and review responsibilities. Passwords, private keys, and unnecessary personal information should not be logged.

6. Applied Case: Protecting a University Health-Analytics Platform

The following is an illustrative case.

Background

A university research group develops a model to predict hospital readmission. Researchers combine pseudonymized clinical records with demographic, medication, and laboratory data. A cloud notebook environment is used for experimentation, while an approved analytics database stores curated data.

Problem

An audit discovers that several notebooks contain embedded database credentials. A storage bucket used for intermediate files is accessible to all members of the research project, including students whose projects do not require clinical data. The model-development process has no formal record of dataset versions or approvals. Researchers also plan to publish performance results by demographic group.

Analysis

The assets include clinical data, credentials, code, model artifacts, research outputs, and participant trust. Threats include accidental disclosure, credential theft, unauthorized browsing, data poisoning, and inappropriate inference. Vulnerabilities include hard-coded secrets, excessive access, weak provenance, and insufficient review. Trust boundaries exist between the university identity provider, cloud platform, notebooks, storage, and external publication channel.

The principal risks are not limited to external attackers. A compromised student account could access unnecessary records; a copied notebook could expose credentials; an untracked dataset could produce irreproducible or misleading results; and a published subgroup analysis could create privacy or discrimination concerns even if no record is directly identified.

Approach and solution

The group replaces embedded credentials with short-lived, centrally managed secrets and workload identities. Access is separated by role: data custodians approve access, researchers receive purpose-limited permissions, and students use de-identified extracts. Storage is divided into zones for restricted source data, curated research data, and publication-ready outputs. Network controls limit which workloads can reach the clinical database.

Dataset versions, transformations, approvals, and model artifacts are recorded in a provenance system. Code review and automated scanning identify exposed secrets and vulnerable dependencies. Logging records access to restricted data, and an independent reviewer examines unusual downloads. The group conducts a privacy impact assessment before publication, evaluates subgroup performance, suppresses unstable statistics, and documents limitations.

Backups are encrypted and tested. Incident procedures define how credentials are revoked, affected data are assessed, investigators are notified, and regulatory obligations are evaluated. The architecture does not eliminate risk; it reduces unnecessary access, improves evidence, and limits the consequences of a compromised account.

Outcome and learning points

The platform becomes more defensible because protection is aligned with purpose and data sensitivity. Researchers retain useful access, while broad project membership no longer implies access to all records. Provenance improves scientific reproducibility as well as integrity. The case demonstrates that confidentiality, privacy, integrity, accountability, and availability must be designed together. It also shows that a technically sophisticated model cannot compensate for weak identity, storage, or governance practices.

7. Governance, Ethics, and Regulation

Security governance assigns responsibility, establishes policy, measures performance, and supports informed risk decisions. Senior leadership sets risk appetite and resources; data owners define appropriate use; custodians implement safeguards; users follow procedures; auditors and regulators provide oversight. Responsibility should be explicit because “the system” cannot be accountable by itself.

Ethically, security controls should respect human dignity, proportionality, fairness, and legitimate expectations. Monitoring employees or research participants may improve detection but can become excessive surveillance. Automated risk scoring can reproduce discrimination or deny access without meaningful explanation. Security decisions should therefore consider affected individuals, not only the organization’s loss.

Legal requirements vary by jurisdiction and sector. Depending on context, organizations may need to address data-protection law, breach notification, health or financial rules, contractual duties, records management, intellectual-property law, and cross-border transfer restrictions. Compliance is a floor, not a guarantee of sound security. A lawful activity may still be unethical, and a compliant control may be ineffective if poorly implemented.

Privacy impact assessments, records of processing, retention schedules, data-subject rights processes, vendor due diligence, and incident-notification procedures help connect technical practice with governance. When personal data are used for machine learning, governance should also address purpose compatibility, explainability, fairness, model monitoring, and the possibility of inferring sensitive attributes.

8. Contemporary Developments and Limitations

Cloud computing has shifted security from protecting a fixed perimeter to governing identities, configurations, APIs, and shared-responsibility relationships. The provider may secure physical infrastructure while the customer remains responsible for identities, data, permissions, and workload configuration. The exact division must be documented rather than assumed.

Artificial intelligence introduces both new risks and new defensive capabilities. Generative systems may expose confidential prompts, follow malicious instructions embedded in retrieved content, or produce insecure code. Machine-learning pipelines may be attacked through poisoned training data, manipulated labels, model extraction, or inference of sensitive membership. At the same time, AI can assist anomaly detection, alert triage, code review, and vulnerability analysis. Human oversight remains necessary because automated security tools can generate false positives, miss novel attacks, or amplify biased assumptions.

Cryptographic agility is increasingly important. Organizations should inventory cryptographic dependencies, protect keys, rotate them appropriately, and prepare to replace algorithms when weaknesses emerge. “Encrypted” is not a complete security description: key management, endpoint protection, access policy, implementation quality, and metadata can determine actual protection.

No control is perfect. Multifactor authentication can be bypassed through session theft or social engineering; encryption does not prevent an authorized user from misusing data; backups may preserve corrupted or encrypted files; and extensive monitoring cannot guarantee detection. Security should therefore be treated as continuous risk management involving prevention, detection, response, recovery, and learning.

Best-Practice Checklist

A data-science organization should:

• inventory sensitive data, models, credentials, services, and dependencies;
• classify data and define authorized purposes;
• map data flows, attack surfaces, and trust boundaries;
• use strong authentication and least privilege;
• separate development, testing, and production environments;
• manage secrets centrally and avoid embedding them in code or notebooks;
• validate inputs and preserve dataset and model provenance;
• encrypt sensitive data in transit and at rest, with disciplined key management;
• monitor access and protect logs from tampering and unnecessary disclosure;
• maintain tested backups, incident procedures, and recovery objectives;
• review vendors, open-source dependencies, and cloud configurations;
• conduct privacy and security assessments when purposes or systems change;
• train users and test controls through exercises, audits, and authorized assessments.

Chapter Summary

Data security protects information and processing systems throughout the data lifecycle. Confidentiality limits unauthorized disclosure and use; integrity protects against improper change; availability supports timely authorized access; authenticity establishes confidence in identity and provenance; accountability links actions to responsible entities; non-repudiation provides evidence about transactions; and privacy governs the justified and respectful treatment of information about people.

Threats are potential causes of harm, vulnerabilities are weaknesses, attacks are deliberate attempts to exploit or abuse conditions, and risk concerns the possible consequences. Controls modify risk through prevention, detection, response, and recovery. Trust boundaries identify where assumptions about identity, authority, or data correctness change. Contemporary attack surfaces include identities, APIs, cloud configurations, software supply chains, notebooks, model pipelines, human users, and external providers.

Effective protection requires layered controls, least privilege, separation of duties, secure defaults, threat modeling, reliable logging, tested recovery, and governance. Security and privacy are connected but distinct: protecting access does not automatically make collection or use legitimate. For data-science professionals, security is simultaneously a technical discipline, a governance responsibility, and an ethical obligation.

Key Terms

Confidentiality: Protection against unauthorized disclosure or use of information.

Integrity: Protection against unauthorized or improper alteration, deletion, or fabrication.

Availability: Timely and reliable access for authorized users and processes.

Authenticity: Confidence that an entity, message, dataset, or system is genuine.

Accountability: Ability to associate actions with responsible identities or processes.

Non-repudiation: Evidence supporting claims about the origin, approval, receipt, or integrity of an action.

Privacy: Appropriate collection, use, disclosure, retention, and deletion of information about individuals.

Asset: Something valuable that requires protection.

Threat: A potential cause of harm.

Threat actor: An entity capable of initiating a harmful event.

Vulnerability: A weakness that can contribute to harm or be exploited.

Attack: A deliberate attempt to compromise a security objective.

Attack surface: The set of points through which a system may be entered, influenced, observed, or disrupted.

Risk: The possibility of adverse consequences arising from uncertainty.

Control: A safeguard or countermeasure that modifies risk.

Residual risk: Risk remaining after controls are applied.

Trust boundary: A boundary across which assumptions about identity, authority, or data correctness change.

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

Threat modeling: Structured analysis of assets, attackers, attack paths, boundaries, and controls.

Pseudonymization: Replacing direct identifiers while retaining a possibility of re-identification through additional information.

Review Questions

Short Answer Questions

1. Define confidentiality, integrity, and availability, and give one control supporting each.
2. Why is authenticity different from authorization?
3. Distinguish a vulnerability from an attack.
4. What is a trust boundary? Give one example in a cloud data platform.
5. Explain why privacy is broader than confidentiality.

Long Answer Questions

1. Discuss how accountability and non-repudiation support organizational governance. Identify their limitations.
2. Explain the relationship among assets, threats, vulnerabilities, attacks, controls, and residual risk.
3. Analyze the major attack surfaces in a contemporary machine-learning pipeline.
4. Compare preventive, detective, corrective, and recovery-oriented controls using a data-breach scenario.
5. Evaluate how least privilege, defense in depth, and zero-trust thinking can be combined in a university analytics platform.

Analytical / Application Questions

1. A research team stores sensitive records in a cloud bucket and grants access to every project member. Identify the assets, threats, vulnerabilities, trust boundaries, and priority controls.
2. A model’s accuracy is high, but its training data came from an unverified external source and its outputs reveal information about rare individuals. Analyze the integrity, authenticity, confidentiality, and privacy issues.
3. An organization must choose between a highly restrictive access design that delays research and a permissive design that increases exposure. Propose a risk-based decision framework, including governance, monitoring, and compensating controls.

Multiple Choice Questions with Answers

Question 1

Which security objective primarily concerns preventing unauthorized disclosure of information?

A. Availability

B. Confidentiality

C. Integrity

D. Authenticity

Correct Answer: B. Confidentiality

Question 2

Which statement best distinguishes authentication from authorization?

A. Authentication determines identity; authorization determines permitted actions

B. Authentication encrypts data; authorization backs up data

C. Authentication detects attacks; authorization restores systems

D. Authentication ensures availability; authorization ensures privacy

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

Question 3

A hard-coded database password in a notebook is best classified as a:

A. Threat actor

B. Vulnerability

C. Control

D. Trust boundary

Correct Answer: B. Vulnerability

Question 4

Which control most directly supports accountability?

A. Individual identities with protected audit logs

B. Publicly sharing administrator credentials

C. Removing timestamps from system events

D. Allowing unrestricted anonymous access

Correct Answer: A. Individual identities with protected audit logs

Question 5

What is the primary purpose of least privilege?

A. To maximize the number of system administrators

B. To grant each entity only the access needed for its authorized task

C. To eliminate the need for authentication

D. To make all data publicly available

Correct Answer: B. To grant each entity only the access needed for its authorized task

Question 6

Which example most clearly represents a trust boundary?

A. The boundary between a notebook environment and a production database

B. Two columns in the same spreadsheet with identical access rules

C. A duplicate copy of a public document

D. A local calculation performed without external input

Correct Answer: A. The boundary between a notebook environment and a production database

Question 7

A threat is best described as:

A. A weakness in a system

B. A potential cause of harm

C. A safeguard that reduces risk

D. A record of completed activity

Correct Answer: B. A potential cause of harm

Question 8

Why does pseudonymization not necessarily make data anonymous?

A. Pseudonymized data cannot be encrypted

B. Additional information may permit re-identification

C. Pseudonymization always increases direct identifiers

D. Pseudonymized data cannot be stored securely

Correct Answer: B. Additional information may permit re-identification

Question 9

Which control is primarily recovery-oriented?

A. Tested and protected backups

B. Input validation

C. Multi-factor authentication

D. Network intrusion detection

Correct Answer: A. Tested and protected backups

Question 10

A digital signature most directly provides evidence of:

A. Guaranteed accuracy of all information in a document

B. The relationship between a signing key and a signed message

C. Permanent availability of the signed service

D. The legal validity of every transaction in every jurisdiction

Correct Answer: B. The relationship between a signing key and a signed message