6.7.7 Resistance measures

What this heading covers

Resistance needs a threat model. Without one, a test is a tour and the result is a count of findings with no denominator. The model should name the attacker, the capability and the assets, and the tests should be traceable to it. A penetration test is one method; abuse-case testing, fuzzing and control tests are others. The measure should be dated and tied to a version, because resistance changes with every release and every new dependency.

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

How a measure for this family is built

Count the attack cases in the model that the product resisted as the numerator over the cases tested. Report unresolved findings by severity, and the date and version tested. A single scanner score is not this measure, because it covers known patterns rather than the model.

What to put in place before publication

1. Write the threat model before testing, and trace each test to a case.
2. Date the result and name the version, because resistance is not stable.

Evidence to keep

Two questions to ask

• What threat model was used, and who wrote it?
• Which version was tested, and what is still open by severity?

Where teams usually fall short

• A scanner report presented as resistance, with no threat model behind it.

What the number cannot tell you

It cannot tell you about an attack nobody modelled. Resistance is bounded by the threat model, and the measure should be read that way.

What happens next

Maintainability is next: the security families depend on the product being changeable when a weakness is found.