augment vulnerability analysis

[jeffblank]

Below is draft text, to augment expectations for vulnerability analysis. It will need to be reworked to ensure that the activity is bounded in terms of time and cost, but it is a good starting point:

The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks involving [selection: integer arithmetic vulnerabilities, buffer overflows, known malware, assignment [list of other vulnerabilities, no other vulnerabilities]] to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential.

Application note: The evaluator shall make all selections associated with possible attacks on the TOE, excluding only those that are inherently infeasible (e.g., the application is written in a programming language not vulnerable to buffer overflows, the application does not perform any integer arithmetic). Identification of known malware can be performed using signature-based methods. Basic attack potential refers to vulnerabilities that can be identified using commercially available mobile application assessment tools.

[kgal]

Copied words. Did not add any additional ones.

[jeffblank]

CC fail. You can't do this. The requirement text for AVA_VAN.1.3E cannot be arbitrarily changed. Please see Common Criteria part 3. We can, however, alter/create application notes and assurance activities. That said, we still will want to rewrite this to make it very, very clear that this activity must be bounded. We must be very careful with the language since we should not take ourselves seriously if we write "have no buffer overflows". We need to encourage vulnerability analysis without demanding any absolute result, since that is impossible.

[kgal]

Oops. Where did you want this? The wording for the requirement was pretty much exactly the same. Total trap.