PD-0088: Developer Vulnerability Analysis

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

What level of rigor is required of the developer in performing and documenting an AVA_VLA.3 vulnerability analysis?

Resolution

When vendors perform a vulnerability analysis, they should meet the letter (and intent) of the requirements.

While some may question the cost/benefit of having the vendor perform a thorough detailed vulnerability analysis, the AVA_VLA.3 requirements are clear that this must be done. In fact, it may be the case that the vendor is most knowledgeable about the product and is therefore most able to perform a systematic search for vulnerabilities.

Systematic, according to the CC (para 506), "requires that the developer identify those vulnerabilities in a structured and repeatable way". The vendor's vulnerability analysis must not be unstructured. It is suggested, but not required, that the vendor demonstrate their forethought by documenting their approach in a "Vulnerability Analysis Plan", which would include a description of the systematic methods to be applied and a description of the content of the results. It would be delivered for evaluation team review (and validation team guidance, as needed) to allow time for revision prior to the actual vulnerability analysis. Alternatively, the validation team could meet with the evaluation team early in the evaluation to discuss expectations of the vendor's vulnerability analysis (this fits in well with the proposed TOP process). Including the vendor in such a meeting should be left to the evaluation team to decide. However, having all parties present would serve to mitigate the risk of repeated iterations of the vulnerability analysis. Whether the vulnerability analysis guidance occurs with a written plan or via a meeting, either method should serve to improve the quality of the vendors' vulnerability analysis.

For AVA_VLA.3, the vendor's vulnerability analysis must include the TOE deliverables. The dependencies for these requirements indicate the TOE deliverables that must be included in the vulnerability analysis: informal functional specification, security enforcing high-level design, subset of the implementation of the TSF, descriptive low-level design, administrator guidance, and user guidance (ref. CC para 513). Evidence that all deliverables have been analyzed and the methods used for analysis must be provided in the vulnerability analysis documentation.

Additionally, the vendor's vulnerability analysis must consider obvious vulnerabilities including those in the public domain. This raises a related question of what constitutes "obvious vulnerabilities in the public domain". There are a number of CERT-like forums. How thoroughly must a vendor search the public domain? An unstructured web search is not adequate. A review of one CERT forum is not adequate. Again, "systematic" comes into play for this portion of the requirement. The vendor must document the method used to search the public domain. The documentation of the public domain search methods must indicate a structured, repeatable process.

Documentation of the vulnerability analysis should focus on both the TOE documentation and the public domain vulnerabilities. The vulnerability analysis documentation "shows that the search was systematic [and] should include identification of all TOE documentation upon which the search for flaws was based" (ref CC, para 506). The documentation of the public domain search must likewise be systematic and should include identification of all public domain sources upon which the search for flaws was based.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CC v2.1 Part 3 AVA_VLA.3.1D, AVA_VLA.3.3C

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0197