6.7.3 Integrity measures

What this heading covers

Integrity is about unauthorised change, not about the absence of bugs. The evidence can be a checksum, a signature, an audit comparison or a test that attempts an unauthorised write. The measure should cover data in transit and at rest, and the program logic itself, because a modified binary is an integrity failure. A product that detects a change but cannot say when it happened has a weaker integrity property than one that can.

Record position: family 22 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.3 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the modification attempts that were prevented or detected as the numerator over the attempts tested. For a coverage measure, divide the protected data sets by the data sets in scope. Record the detection time, because a change discovered a month later is a different result from one blocked at the write.

What to put in place before publication

1. Name what is protected and what is not.
2. Record the detection time for changes that were not blocked.

Evidence to keep

Two questions to ask

• Does the protection cover program logic as well as data?
• How long did detection take when a change was not blocked?

Where teams usually fall short

• A hash check on a download treated as integrity for the whole product.

What the number cannot tell you

It cannot tell you whether the data was correct before the change. Integrity protects against improper change, not against wrong entry.

What happens next

Non-repudiation and accountability are the two families that depend on records of who did what.