2.2 Beyond CIA: Authenticity, Non-repudiation, Accountability, Reliability

The CIA triad is the foundation, but it is not the whole picture. ISO/IEC 27000 defines a broader set of information security properties that the Foundation exam expects you to recognize: authenticity, non-repudiation, accountability, and reliability. These do not replace CIA — they refine it, and a single control (like a digital signature) often supports several properties at once.

Authenticity

Authenticity is the property that an entity is what it claims to be. The entity can be a user, a device, a server, a message, or a document.

Mechanisms

• Multi-factor authentication (MFA) for users.
• Server TLS certificates for websites.
• Digital signatures and MACs for messages and files.
• Code signing for software releases.
• Kerberos, OAuth, and SAML for federated identity.

Example

A supplier portal accepts invoices only when they carry a valid digital signature from an approved vendor certificate. The signature proves the invoice originated from the claimed vendor — that is authenticity.

Related Annex A controls

---

Non-repudiation

Non-repudiation is the property that an action or event cannot be denied by the party that performed it. Where authenticity proves "this came from X," non-repudiation proves "X cannot later claim it did not."

Mechanisms

• Digital signatures using the sender's private key (the recipient, or any third party, can verify with the public key).
• Trusted timestamps from a time-stamping authority, proving when the action occurred.
• Tamper-evident audit logs with centralized, append-only storage.
• Strong identity binding so the signing key is unambiguously tied to a verified individual.

Example

A trader submits an order via a signed, timestamped message. When the trade loses money, the trader cannot repudiate the order: the signature proves origin, the timestamp proves timing, and the audit trail proves submission. Each element alone is weaker; together they provide non-repudiation.

Important distinction

A shared symmetric key provides authenticity between two parties but not non-repudiation, because either party holds the same key and could have created the message. Asymmetric digital signatures are required for true non-repudiation.

---

Accountability

Accountability is the property that ensures the actions of an entity can be traced uniquely to that entity. Without accountability, blame and remediation are impossible.

Mechanisms

• Unique user IDs — never share accounts; shared accounts destroy accountability.
• Audit logging — A.8.15 Logging user activities, exceptions, faults, and events.
• Monitoring and review — A.8.16 Monitoring system use.
• Clock synchronization — A.8.17 Clock synchronization, so log timestamps are comparable across systems.
• Privileged access review — A.8.2 Privileged access rights.

Example

An auditor investigating a data leak pulls logs showing user j.doe downloaded 40,000 records at 02:13 UTC from the CRM database. Because every user has a unique ID and clocks are synchronized to a single NTP source, the action is traceable to one person — that is accountability.

What breaks accountability

• Shared or generic accounts (admin, root, testuser).
• Missing or incomplete logs.
• Unsynced clocks producing non-correlatable timestamps.
• Missing log integrity controls (an attacker can edit the log to frame someone else).

---

Reliability

Reliability is the property of consistent, intended behavior over time. It overlaps with availability but is broader — a system can be available yet unreliable (returning wrong results), or reliable yet briefly unavailable (during planned maintenance).

Mechanisms

• Redundancy — A.8.14 Redundancy of information processing facilities.
• Change management — A.8.32 Change management, to prevent untested changes from degrading behavior.
• Capacity management — A.8.6 Capacity management, to prevent overload-driven failures.
• Maintenance and supplier support — A.8.14, A.5.19 Supplier relationships.
• Secure coding and testing — A.8.28 Secure coding, A.8.29 Security testing in development.

Example

A payment gateway is expected to process 99.95% of transactions within 2 seconds. Capacity planning, redundant server clusters, change controls, and monitored failover ensure this behavior holds month after month. That consistency is reliability.

---

How the Properties Reinforce Each Other

graph TD
    AU["Authenticity"] --> NR["Non-repudiation"]
    AU --> AC["Accountability"]
    IN["Integrity"] --> NR
    AC --> RE["Reliability"]
    AV["Availability"] --> RE

    style AU fill:#1e3a5f,color:#fff
    style NR fill:#2d5a87,color:#fff
    style AC fill:#2d5a87,color:#fff
    style IN fill:#c9a227,color:#1e3a5f
    style AV fill:#c9a227,color:#1e3a5f
    style RE fill:#1e3a5f,color:#fff

Authenticity plus integrity enables non-repudiation. Authenticity enables accountability. Availability plus consistent behavior enables reliability. The exam often asks which property a control primarily supports — pick the most direct match, then acknowledge secondary effects in the explanation.

---

Common Exam Traps

1. Symmetric encryption provides non-repudiation. False — both parties share the key, so either could have produced the message.
2. Shared service accounts are fine if password-protected. No — they destroy accountability because actions cannot be traced to one person.
3. Reliability equals availability. No — a system can be available but produce wrong results (low reliability), or be briefly offline but consistent (low availability, high reliability).
4. A digital signature only proves authenticity. It also provides integrity (any modification breaks the signature) and contributes to non-repudiation.
5. Audit logs alone provide non-repudiation. Logs support accountability and can support non-repudiation, but only if they are tamper-evident, time-synchronized, and bound to authenticated identities.