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
