Assurance measures: AVA (There should be some white hats around also)

[Magosányi Árpád <mag@bunuel.tii.matav.hu>]

Hi!

Vulnerability assessment is continously happening. It is a common
estimation that the public sees its results with some two months
delay in average.
Actually the other assurance measures are invented to have as few
facts to be found by AVA, as possible.

AVA_CCA.1 Covert channel analysis (EAL5)
I do not cover this topic here, as one can get even EAL4 without
it. Hopefully firewall vendors will realise sooner or later,
that their products have no protection without doing their
homework in this area. (I count myself as one of them.)

AVA_MSU.2 Validation of analysis (EAL4, EAL5)

AVA_MSU.2.1D   The developer shall provide guidance documentation.
	(See AGD)
AVA_MSU.2.2D   The developer shall document an analysis of the guidance
	documentation.
	(This is the new one. I doubt that any OSS products have it)
AVA_MSU.2.1C   The guidance documentation shall identify all possible
	modes of operation of the TOE (including operation following
	failure or operational error), their consequences and
	implications for maintaining secure operation.
	(An often lacking element of docs.)
AVA_MSU.2.2C   The guidance documentation shall be complete, clear,
	consistent and reasonable.
	(It is everyone's long term goal:)
AVA_MSU.2.3C   The guidance documentation shall list all assumptions
	about the intended environment.
	(As stated in AGD, and shall be found in ST.)
AVA_MSU.2.4C   The guidance documentation shall list all requirements
	for external security measures (including external procedural,
	physical and personnel controls).
	(This is drawn from the list of objectives against te non-it
	environment from the ST.)
AVA_MSU.2.5C   The analysis documentation shall demonstrate that the
	guidance  documentation is complete.
	(hmm..)

AVA_SOF.1 Strength of TOE security function evaluation (EAL2-EAL7)

AVA_SOF.1.1D The developer shall perform a strength of TOE security
	function analysis for  each mechanism identified in the ST as
	having a strength of TOE security  function claim.
	(Fortunately it is a well-researched area. One can find research
	papers analysing the strength of the cryptographic functions
	widely used. The minimum pasword complexity/key lengths should
	only be set according to them, which can be made a requirement
	against the environment and documented in the guidance.)
AVA_SOF.1.1C For each mechanism with a strength of TOE security function
	claim the strength of TOE security function analysis shall show
	that it meets or exceeds the minimum strength level defined in
	the PP/ST.
	(see above)
AVA_SOF.1.2C   For each mechanism with a specific strength of TOE
	security function claim the strength of TOE security function
	analysis shall show that it meets or exceeds the specific
	strength of function metric defined in the PP/ST.
	(See above)

AVA_VLA.2 Independent vulnerability analysis (EAL4)

AVA_VLA.2.1D The developer shall perform a vulnerability analysis.
	(We all think about ways to overcome the defence of our
	program. Let's call it vulnerability analysis:)
AVA_VLA.2.2D The developer shall provide vulnerability analysis
	documentation.
	(Write down what did you thought about.)
AVA_VLA.2.1C The vulnerability analysis documentation shall describe the
	analysis of the TOE deliverables performed to search for ways in
	which a user can violate the TSP. The vulnerability analysis
	documentation shall describe the disposition of identified
	vulnerabilities.
	(look ad docs, fix if you find something, and document it.)
AVA_VLA.2.2C The vulnerability analysis documentation shall show, for
	all identified vulnerabilities, that the vulnerability cannot be
	exploited in the intended environment for the TOE.
	The vulnerability analysis documentation shall justify that the
	TOE, with the identified vulnerabilities, is resistant to
	obvious penetration attacks.
	(This is the type of security advisory that claims that "our
	system is not vulnerable", or "our system is not intended for
	that type of use", but in the docs this time.)

This time I list an evaluator action element, as this is the main point:

AVA_VLA.2.3E The evaluator shall perform an independent vulnerability
	analysis.
	(We have plenty of evaluators, they perform it, but often fail
	to tell it to others:) Nonetheless there are plenty of position
	papers telling that a strength of open source is opennes to
	independent vulnerability analysis. And they are true.)


-- 
GNU GPL: csak tiszta forrásból