The two goals the triad leaves out

Three objectives are not enough to describe a real incident

The triad is primary, but it is not complete. Two further goals are needed often enough that the field names them, and the paper opens on telling them apart.

• Authenticity — the property of being genuine and able to be verified and trusted. Confidence in the validity of a transmission, a message, or the identity of an originator. Authenticity is a question asked at the moment of the transaction: is this really from who it claims to be from?
• Accountability — the requirement that whatever a system did can be attributed back to exactly one acting entity, with no ambiguity about which. Accountability is a question asked afterwards: who did this, and can we show it to someone who doubts us?

Accountability is the goal that generates the traceability requirement, and traceability is what makes non-repudiation, deterrence, fault isolation, intrusion detection, after-action recovery and legal action possible. Those six are consequences of accountability, not separate goals. This distinction is worth money on the paper: when a stem describes an outcome such as "the customer cannot later deny issuing the instruction", the goal being asked for is accountability, and the tempting wrong answer is non-repudiation, which is what accountability buys you.

Be careful how you read that, because it is easy to over-correct into a second error. Saying non-repudiation is not one of the five goals is not saying it is not a real thing: non-repudiation is a named security service, and you will meet it as one in the X.800 catalogue later in this module. Goals and services sit at different layers of the vocabulary. The goals are the properties a system is required to have; the services are the guarantees a protocol offers in order to obtain them. Non-repudiation is a service built on the goals — chiefly on accountability (the action is attributable) and on integrity (the record of it has not changed since). So: five goals, and non-repudiation is a service standing on two of them.

Where each goal sits, in one pass

Notice that the last two are not reducible to the first three, but they lean on them: authenticity is usually delivered by an integrity mechanism (a signature over the message), and accountability by a confidentiality-and-integrity-protected log. Do not confuse a goal with the mechanism that delivers it.

One honest wrinkle you should know, because it looks like a contradiction if you meet it cold: FIPS 199 recognises only the three triad objectives, and folds authenticity in under integrity. That is a deliberate convention in a US federal categorisation standard, not a claim that authenticity does not exist. The taxonomy is a convention, chosen for a purpose; five goals is the fuller picture and three is the categorisation scale.

Worked example — one incident, asked five times

At Northreach, a payment instruction arrives at the finance system: transfer £14,200 to supplier account 60-14-92. It is submitted through the credentials of M. Oyelaran, a procurement officer who left the university six weeks ago and whose account was never disabled. Finance pays it. Two weeks later the real supplier chases an unpaid invoice.

Ask the five goals of this incident in turn. This is the drill, and it is how the exam question is answered.

Confidentiality — was anything disclosed to someone unauthorized? Yes, incidentally: whoever used the account could read the supplier list and the payment history. That is a genuine loss, but it is not what cost the £14,200.

Integrity — was anything altered? Data integrity is arguably intact: no existing record was modified; a new, well-formed instruction was added. This is the trap. "Nothing was altered" does not mean integrity held — a fabricated but well-formed record is a data integrity failure the moment you ask whether the data was changed only in a specified and authorized manner, and it was not.

Availability — was service denied? No. The system was up and answered every request. Availability was perfect throughout, which is a useful reminder that a system can be one hundred percent available while being robbed.

Authenticity — was the instruction genuinely from who it claimed to be from? No. It claimed to be from Oyelaran and was not. This is the goal that failed at the moment of the transaction, and the requirement it generates is that the finance system must verify the originator before acting — an active account is not a verified originator, which is exactly what a step-up authentication or a signed instruction would have caught.

Accountability — can the action be traced uniquely to the entity that performed it? No, and this is the deepest failure. The log says "Oyelaran". Oyelaran was two hundred miles away and can prove it. Because the credential was shared, dormant and unmonitored, the log cannot tie the action to any entity — so the university cannot do forensics (which host?), cannot isolate the fault (which control failed?), cannot deter a repeat, and cannot pursue anyone legally. Only accountability generates the traceability requirement, and only traceability delivers all six of those consequences.

So the incident is one event and five separate findings, and the remediation list falls straight out of them: disable accounts at leaving (accountability and authenticity), verify originators on payment instructions (authenticity), log per-session origin and bind it to a real identity (accountability), review supplier-list access (confidentiality).

Now do it yourself. Classify these three requirements by the goal that generates each: (a) the marker who entered a grade change must be identifiable from the audit trail six months later; (b) a grade-change request must be shown to have come from a marker assigned to that course; (c) a grade, once entered, must not change except through the change process. Then write the accountability/authenticity discrimination cold, in one sentence each, in the register the paper uses.