6.7.6 Authenticity measures

What this heading covers

Authenticity is a property of a claim and its proof. It covers users, services and messages, and the strength of the proof matters. A password and a hardware key both authenticate, and they do not give the same assurance. The measure should say which mechanisms are in scope and what proportion of the population uses them, and it should include the negative case: a forged claim that must be rejected.

Record position: family 25 of 40 in clause 6, under 6.7 Security, which carries 6 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.7.6 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the entities or messages authenticated by an approved mechanism as the numerator over the entities or messages in scope. For strength, report the distribution of mechanisms rather than a single percentage. Test a forged credential and a replayed message, and count the rejections.

What to put in place before publication

1. State which mechanisms count as approved.
2. Test forgery and replay, not only a successful login.

Evidence to keep

Two questions to ask

• Which authentication mechanisms count as approved?
• Was a forged or replayed claim rejected in testing?

Where teams usually fall short

• A login success rate presented as authenticity, with no forgery test.

What the number cannot tell you

It cannot tell you whether the mechanism is strong enough for the asset. That is a risk decision, not a percentage.

What happens next

Resistance is the sixth security family and the one that faces an adversary.