COMP 6660 · Enterprise Cybersecurity Cybersecurity Objectives and Principles

00 Introduction

Lesson 1.2 established what enterprise cybersecurity protects. This lesson establishes what "protecting" means — the specific properties that an asset must retain for the enterprise to consider it secure.

The word "secure" is used in everyday enterprise conversation as though it named a single quality. It does not. A system is secure only relative to a set of stated objectives: secure against unauthorised disclosure, secure against unauthorised modification, secure against unavailability, secure against forged messages, secure against denial. These are different properties, achieved by different controls, and the enterprise must decide which properties matter — and to what degree — for each asset it holds.

This lesson introduces the standard set of security objectives used across the discipline: the CIA triad (confidentiality, integrity, availability) and the extended set — authenticity, accountability, privacy, and non-repudiation. It explains each objective, the mechanisms that support it, the failure modes that defeat it, and the trade-offs that arise when objectives pull in different directions. It then shows how to apply the objectives to an enterprise asset, using the classification scheme from Lesson 1.2 as the bridge between asset identification and control selection.

The lesson is foundational. The objectives introduced here are used in every subsequent unit: to describe what a control does, to assess whether it is working, to frame risk, and to evaluate the impact of an incident. Students who internalise them early will find the rest of the course substantially easier.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 1 outcomes U1.1 (objectives and principles) and U1.5 (posture assessment), and to Module 1 outcomes M1.1 and M1.8. See the Unit 1 learning outcomes page for the full mapping.

02 Why security objectives matter

A security objective is a statement of what must remain true about an asset for the enterprise to consider it protected. Objectives serve four purposes.

The chain from asset to control

The objectives introduced in this lesson are not chosen freely. They follow from the asset's value and classification, which were the subject of Lesson 1.2. The chain runs like this:

1. Identify the asset What is it? Where is it? Who depends on it?
2. Classify the asset How sensitive is it? What regulatory obligations attach to it? What harm follows from its compromise?
3. State the objectives Which of confidentiality, integrity, availability, authenticity, accountability, privacy, and non-repudiation must be preserved, and to what degree?
4. Select the controls Which controls, applied in which places, will preserve the stated objectives at acceptable cost?
5. Verify the objectives How will the enterprise know the objectives are being met? What evidence is collected, and at what cadence?

This chain is the operational form of the argument made in Lesson 1.1 — that enterprise cybersecurity is a business issue. Each step requires judgement about value, harm, and acceptable cost, not just technical knowledge.

03 Confidentiality

What confidentiality requires

Confidentiality is not simply about keeping secrets. It has three dimensions, each with distinct requirements:

• Access control. Only authorised subjects can access the information. This requires identity, authentication, and authorisation mechanisms — the subject of Unit 2.
• Protection in transit and at rest. Even when access is correctly controlled, information can be intercepted in transit or extracted from storage. Encryption addresses both.
• Prevention of inference and aggregation. Confidentiality can be undermined without direct access to the information itself — through metadata, side channels, or the combination of individually harmless data points.

Mechanisms that support confidentiality

Common failure modes

• Misconfigured access. The most common cause of confidentiality breaches in cloud environments. An access policy that is more permissive than intended, or a storage bucket that is unintentionally public.
• Over-sharing. Legitimate users given broader access than their role requires, particularly in environments where roles are not reviewed and access accumulates over time.
• Weak or absent encryption. Encryption applied with weak ciphers, inadequate key management, or to data that is not actually sensitive while leaving genuinely sensitive data unencrypted.
• Insider misuse. Authorised users who use their access for unauthorised purposes. Technical controls rarely detect this without behavioural monitoring.
• Metadata and side channels. Even when content is protected, metadata — who accessed what, when, how often — can reveal sensitive information.
• Aggregation. Combining individually non-confidential sources into a confidential whole, without treating the aggregate as confidential.

Trade-offs and limits

Stronger confidentiality carries costs. Encryption can impede recovery if keys are lost; strict access control can slow legitimate work and drive activity into unsanctioned channels; data minimisation can reduce the enterprise's ability to detect patterns or anomalies. The right balance depends on the asset and its classification.

Confidentiality also has limits. Some confidentiality controls are defeated not by attackers but by misclassification: treating data as confidential when it is not wastes resource; treating it as non-confidential when it is not produces breach. Classification (Lesson 1.2) and confidentiality are therefore closely coupled.

04 Integrity

Two dimensions of integrity

Integrity has two distinct but related dimensions:

• Data integrity. The content of information is accurate and complete: records reflect reality, transactions have not been altered, documents have not been modified. Data integrity is about the information itself.
• System integrity. Systems operate as intended and are not subject to unauthorised modification — no hidden code, no unauthorised configuration changes, no unexpected behaviour. System integrity is about the systems that hold and process information.

Both dimensions matter. A system that runs correctly but is fed corrupt data is not trustworthy. A system with correct data but compromised behaviour may quietly alter that data or expose it. Enterprise integrity programmes address both.

Mechanisms that support integrity

Common failure modes

• Unauthorised modification. The classic integrity failure — an attacker or insider alters records, transactions, or code.
• Silent corruption. Data or files degrade without detection, often through storage failure, transmission error, or buggy software. Silent corruption is dangerous precisely because it produces no signal.
• Supply-chain insertion. A malicious component is inserted into the enterprise's software or hardware pipeline. The enterprise's own code may be correct; the integrity of the delivered system is not.
• Misconfiguration. Legitimate changes made without proper review introduce errors or weaken controls. This is often classified as an operational issue rather than an integrity failure, but the consequence is similar.
• Privileged insider action. Users with legitimate modification rights acting outside their authority — often without detection if logging is inadequate.

Integrity versus authenticity

Integrity and authenticity are related but distinct. Integrity is about whether the data has changed; authenticity is about whether the data comes from the claimed source. A file can be unaltered (integrity preserved) but from an unknown or untrusted source (authenticity not established). Conversely, a file can be from a known source (authenticity established) but altered in transit (integrity not preserved).

Cryptographic mechanisms — digital signatures in particular — provide both. A signed message cannot be altered without invalidating the signature (integrity), and the signature verifies the signer's identity (authenticity). This dual role is why signatures are central to enterprise trust infrastructure, examined in Lesson 2.4.

05 Availability

Availability in modern enterprises

Availability has moved from the periphery of cybersecurity to its centre. Two decades ago, most security programmes focused on confidentiality, with availability handled largely by operational and business-continuity teams. Today, availability is a primary target of enterprise attackers and a primary concern of executives.

Ransomware is the clearest illustration. Its objective is to make enterprise systems unavailable, and to monetise the resulting disruption. Denial-of-service attacks on customer-facing services have similar intent. Attacks on operational technology — hospitals, energy, transport — are fundamentally availability attacks with physical consequences.

Mechanisms that support availability

Common failure modes

• Ransomware and destructive attacks. Encryption or destruction of data and systems to force payment or cause disruption.
• Denial of service. Overwhelming a service with traffic, or exploiting a vulnerability that causes it to become unresponsive.
• Single points of failure. Components whose failure causes an outage because no redundancy exists. Frequently identified only after the event.
• Third-party dependency failure. Outages caused by cloud providers, SaaS platforms, or network operators on which the enterprise depends. The enterprise cannot fix these, only mitigate.
• Misconfiguration and operational error. Changes that inadvertently break services — often the most common cause of availability incidents in practice.
• Backup failure. Backups that cannot be restored, or that have been corrupted alongside the primary data, converting a recoverable incident into a crisis.

The availability trade-off

Availability is not simply "more is better". Every increment of availability costs resource, and the costs are not linear: moving from 99% to 99.9% availability is a modest engineering effort; moving from 99.99% to 99.999% is disproportionately expensive. Enterprises must decide, for each system, what level of availability is justified by the value of the service it delivers.

Availability also conflicts with other objectives. Strict change management (supporting integrity and availability) slows the deployment of new features. Encryption (supporting confidentiality) can complicate recovery if keys are lost. Aggressive security monitoring (supporting accountability) can consume resources that would otherwise serve availability. The trade-offs are real and must be managed deliberately.

06 Authenticity and accountability

The CIA triad covers the properties of information itself. The next two objectives — authenticity and accountability — concern trust in the parties who create, transmit, or act on that information.

Authenticity

Authenticity applies at several levels:

• Subject authenticity. A user, service, or device claiming an identity is genuinely that entity. Established by authentication mechanisms.
• Message authenticity. A message or data item originates from the claimed source. Established by digital signatures or message authentication codes.
• Document authenticity. A document, certificate, or record is genuine and has been issued by the claimed authority. Established by public key infrastructure, seals, and trusted attestation.
• Software authenticity. A software artifact is what it claims to be, from the claimed publisher, and has not been tampered with. Established by code signing and provenance verification.

Authenticity is closely coupled with integrity. A message that has been altered in transit is no longer authentic in the sense the sender intended; a system that has been modified no longer authenticates the same behaviour. But the two objectives are distinct: integrity is about whether something has changed; authenticity is about whether it is genuine.

Accountability

Accountability requires three things:

• Identity. Subjects must be uniquely identified, so that actions can be attributed to a specific party rather than a shared or anonymous account.
• Auditability. Actions must be recorded in a manner that can be reviewed after the fact, and that resists tampering or deletion.
• Consequence. The enterprise must be able to act on the record — to investigate, discipline, prosecute, or otherwise respond. A log that no one reads does not produce accountability.

Accountability is a governance property as much as a technical one. In many enterprises the technical mechanisms exist — logging is deployed, identities are assigned — but the accountability chain is broken because logs are not monitored, findings are not acted on, or shared accounts remain in use. The technology is necessary but not sufficient.

07 Privacy and non-repudiation

The final two objectives in the extended set — privacy and non-repudiation — are less frequently included in the CIA triad, but are increasingly central to enterprise security requirements. Privacy arises primarily from legal and ethical obligations; non-repudiation from the legal and commercial need to prevent denial of transactions.

Privacy

Privacy is often confused with confidentiality, but they are distinct. Confidentiality is about restricting access; privacy is about the rights and expectations of the individual whose data it is. Data can be confidential (accessible only to authorised parties) yet still violate privacy if it is collected without consent, used for purposes the individual did not agree to, or retained longer than appropriate.

Privacy imposes additional requirements on enterprise security:

• Lawful basis. Personal data must be collected and processed only on a lawful basis — consent, contract, legal obligation, legitimate interest — depending on the jurisdiction and context.
• Purpose limitation. Data collected for one purpose must not be used for another without a lawful basis.
• Data subject rights. Individuals typically have rights of access, correction, deletion, and objection, which the enterprise must be able to fulfil.
• Retention limits. Data must be retained only as long as necessary for its stated purpose, and then disposed of securely.
• Cross-border restrictions. Transfer of personal data across jurisdictions is restricted by many privacy regimes, with implications for cloud deployment and vendor selection.
• Breach notification. Unauthorised access to personal data must typically be reported to regulators and sometimes to affected individuals within defined time limits.

Privacy is examined further in Lesson 1.4 (in the context of the threat landscape) and in Module 3, Lesson 6.4 (compliance and regulatory requirements). At this stage, the essential point is that privacy is a security objective in its own right, and one whose requirements are set by law and ethics rather than by the enterprise's own preferences.

Non-repudiation

Non-repudiation differs from accountability in emphasis. Accountability is about the enterprise's ability to attribute actions to subjects; non-repudiation is about the subject's inability to deny having performed the action. Accountability is what the enterprise needs; non-repudiation is what makes the enterprise's record legally or commercially defensible.

Non-repudiation typically requires:

• Cryptographic evidence. Digital signatures provide mathematically verifiable proof that a specific key holder signed a specific message. This is stronger than password-based authentication, which can be repudiated on the basis that credentials were shared or stolen.
• Trusted time-stamping. The evidence must include when the action occurred, and the timestamp must itself be trustworthy.
• Secure key management. The subject's private key must be protected, or the non-repudiation guarantee is undermined — the subject can claim the key was compromised.
• Legal and contractual recognition. The enterprise's non-repudiation mechanisms must be recognised in the relevant jurisdictions and, where applicable, by the parties involved.

Non-repudiation appears most visibly in e-commerce, where customers must not be able to deny having placed an order; in financial services, where transactions must be defensible; in regulated industries, where records must be auditable; and in legal and government contexts, where electronic signatures carry the weight of handwritten ones. The mechanisms are examined in Lesson 2.4 (digital signatures and PKI).

08 Applying objectives to enterprise scenarios

The objectives are useful only when they are applied. This section shows how to select the appropriate objectives for a given asset, and how to manage the trade-offs that arise between them.

Not all objectives apply equally

A common mistake is to assume that every asset requires all objectives at maximum strength. In practice, the appropriate objectives vary widely:

The table is illustrative. Its purpose is to show that objectives are not a uniform checklist but a set of choices, made per asset, in light of the asset's value, regulatory context, and dependence.

The objectives trade off against each other

Objectives are not always compatible. Several trade-offs recur:

• Confidentiality vs. availability. Strong encryption protects data but can impede recovery if keys are lost. Strict access control reduces exposure but can prevent legitimate work during an incident.
• Integrity vs. availability. Rigorous change control and verification reduce the risk of corrupt or malicious change, but slow the pace of response and can delay restoration after an incident.
• Confidentiality vs. usability. Multi-factor authentication, device encryption, and strict access controls add friction for users. Excess friction drives circumvention.
• Accountability vs. privacy. Monitoring and logging for accountability can intrude on employee privacy, and can conflict with regulatory protections in some jurisdictions.
• Authenticity vs. availability. Strong authentication can become a bottleneck during outages if the identity system itself is unavailable.
• Any objective vs. cost. Every increment of objective attainment costs resource and introduces operational complexity. There is always a level beyond which the cost is not justified by the value of the asset.

How to resolve trade-offs

There is no universal formula, but a defensible process has four elements:

1. State the objectives explicitly For the asset in question, which objectives apply, and at what level? Write them down.
2. Identify the conflicts Where do the objectives pull against each other? Which controls serve more than one objective, and which serve one at the expense of another?
3. Assess the consequence of each option What harm would follow from a confidentiality failure? From an availability failure? From an integrity failure? Which harms are more severe, and for whom?
4. Decide and record Choose the balance, document the reasoning, and revisit it as circumstances change. Defensible decisions are documented decisions.

09 Objectives and classification

Lesson 1.2 introduced classification as the mechanism for translating asset identification into control requirements. This lesson has introduced objectives as the properties that controls exist to preserve. The two are closely connected.

How classification shapes objectives

Classification is not only about confidentiality. A complete classification scheme assigns a level to an asset based on the harm that would follow from its compromise across multiple objectives:

A defensible classification decision therefore considers harm across all applicable objectives, not only confidentiality. An asset that is not confidential but is highly integrity-critical (for example, a public reference-data table that drives financial calculations) may warrant a higher classification than its confidentiality alone would suggest.

From classification to control selection

Once classification and objectives are stated, control selection becomes a bounded problem: which controls, deployed where, will preserve the stated objectives at a level consistent with the classification, at acceptable cost?

The following table gives an illustrative mapping for a four-level scheme. It is not prescriptive — actual requirements depend on sector, jurisdiction, and enterprise context — but it shows the shape of the reasoning.

10 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Security objective

A statement of what must remain true about an asset for the enterprise to consider it protected. Objectives drive control selection and frame incident impact.

CIA triad

Confidentiality, integrity, and availability — the three foundational security objectives, from which most security controls derive their purpose.

Confidentiality

The property that information is accessible only to those authorised to access it, in the manner and for the purposes approved. Supported by access control, encryption, classification, minimisation, segmentation, and data loss prevention.

Integrity

The property that information and systems remain accurate, complete, and unaltered except by authorised parties. Has two dimensions — data integrity and system integrity — and is supported by hashing, signatures, change management, version control, and supply-chain controls.

Availability

The property that information and systems are accessible to authorised subjects when required, at the level of performance committed to. Supported by redundancy, backups, failover, DDoS mitigation, and incident response.

Authenticity

The property that a subject, message, or data item is genuine — that it originates from the party it claims to originate from, and has not been forged. Applies to subjects, messages, documents, and software.

Accountability

The property that actions can be attributed to specific subjects, and that those subjects can be held responsible. Requires identity, auditability, and consequence.

Privacy

The property that individuals have appropriate control over information about themselves. Distinct from confidentiality: a dataset can be confidential yet violate privacy if it is collected, used, or retained improperly.

Non-repudiation

The property that a party cannot credibly deny having performed an action. Typically relies on digital signatures, trusted time-stamping, and secure key management.

Control selection

The process of choosing which controls to deploy, where, and at what strength, in order to preserve stated objectives at a level consistent with an asset's classification and at acceptable cost.

Objective trade-off

A situation in which achieving one security objective requires accepting a reduction in another. Trade-offs are resolved through explicit reasoning about harm and cost, and recorded as decisions.

11 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

12 Self-check

Answer the questions below before moving to Lesson 1.4. If you cannot answer a question confidently, revisit the corresponding section.

13 Summary

This lesson has defined what "secure" means. The essential points are:

• "Secure" is not a single property. Security is defined relative to a set of objectives — the properties an asset must retain for the enterprise to consider it protected. Without stated objectives, "secure" is unmeasurable.
• The CIA triad is foundational. Confidentiality (access restricted to authorised parties), integrity (data and systems remain accurate and unaltered), and availability (authorised access when required). Each is supported by a distinct set of mechanisms and defeated by a distinct set of failure modes.
• The extended set — authenticity, accountability, privacy, non-repudiation — addresses obligations that CIA alone does not capture. Authenticity establishes genuineness; accountability attributes actions to subjects; privacy protects individual rights over personal data; non-repudiation prevents denial of actions.
• Not all objectives apply equally to every asset. Objective profiles vary by asset type, value, and regulatory context. Applying maximum controls uniformly is costly and ineffective.
• Objectives trade off against each other. Confidentiality versus availability; integrity versus availability; accountability versus privacy. Trade-offs are resolved through explicit reasoning about harm and cost, and recorded as decisions.
• Objectives connect to classification. The chain runs asset → classification → objectives → controls → verification. Every step is a decision, and every decision should be documented.

These ideas are used throughout the course. Lesson 1.4 examines the threat landscape in more detail — the adversaries whose actions threaten the objectives defined here. Lesson 1.5 introduces the frameworks that structure enterprise security programmes around these objectives. Unit 2 examines the cryptographic and access-control technologies that enforce them.