Hi!
This is the last part of the saga (for a time at least), as we are
done with all assurance requrements (modulo those concentrating on
ST and PP assurance.)
I hope that at least some of you were listening.
(First I thought there would be some feedback, at least
like "stop it, this is boring!", or "why do you write to a
mailing list which does not even exists?".)
The assurance maintenance class is not an integral
part of the assurance requirement set. It not included in the
EALs, and it seems that no one really cares about it. It might
be okay with commercial software development styles (it isn't:
one can only find outdated versions of software evaluated against
CC), but having only a point release evaluated would just not
fit with open source development methodology.
Unfortunately this class heavily depends on other assurance
classes, some of which open source isn't good at.
AMA_AMP.1 Assurance maintenance plan
AMA_AMP.1.1D The developer shall provide an AM Plan.
(Let's assume that we don't have any.)
AMA_AMP.1.1C The AM Plan shall contain or reference a brief description
of the TOE, including the security functionality it provides.
(Security Target, TOE description (what we also don't have))
AMA_AMP.1.2C The AM Plan shall identify the certified version of the
TOE, and shall reference the evaluation results.
(None is available)
AMA_AMP.1.3C The AM Plan shall reference the TOE component
categorisation report for the certified version of the TOE.
(We will se this later.)
AMA_AMP.1.4C The AM Plan shall define the scope of changes to the TOE
that are covered by the plan.
(The upper bound of possible changes until the next stable
release. Some OSS projects would benefit from such an upper
bound anyway: it would made their release cycle more
controllable.)
AMA_AMP.1.5C The AM Plan shall describe the TOE life-cycle, and shall
identify the current plans for any new releases of the TOE,
together with a brief description of any planned changes that
are likely to have a significant security impact.
(The actually planned changes. Some projects have such goals,
and some don't. They are not meet them, but it isn't expected
anyway.)
AMA_AMP.1.6C The AM Plan shall describe the assurance maintenance cycle,
stating and justifying the planned schedule of AM audits and the
target date of the next re-evaluation of the TOE.
(The AM schedule should match to the devel cycle. Maybe having
a defined QA effort concerning itself with the release cycle
(and this could even be aligned by AM goals), would create
a pressure to the cycle which could make a balance with the
developers' pressure (put in this and that also, the release
goal is just a date without meaning). In debian there is the
QA group, which does concerned with some issues related,
but not assume responsibility for 1.6C and more importantly
for enforcing 1.5C)
AMA_AMP.1.7C The AM Plan shall identify the individual(s) who will
assume the role of developer security analyst for the TOE.
(My daylight job includes this. You will sooner or later
will really hate all developers. And they will hate you
as well. And both of you will have very good reasons to
do so:) At least this is the case with commercial developments:
most of the developers I meet does not even know the
tools and languages they use, and very upset when I tell
them that they work is b*llsh*t.)
AMA_AMP.1.8C The AM Plan shall describe how the developer security
analyst role will ensure that the procedures documented or
referenced in the AM Plan are followed.
(I am very interested what is the equivalent of "management
decision" in OSS:) You know this kind from Dilbert cartoons)
AMA_AMP.1.9C The AM Plan shall describe how the developer security
analyst role will ensure that all developer actions involved
in the analysis of the security impact of changes affecting
the TOE are performed correctly.
(I looked it up in the CEM trying to figure out what it
means. I have found the following information: none)
AMA_AMP.1.10C The AM Plan shall justify why the identified developer
security analyst(s) have sufficient familiarity with the
security target, functional specification and (where
appropriate) high-level design of the TOE, and with the
evaluation results and all applicable assurance requirements for
the certified version of the TOE.
(I cannot think of feasible procedural controls (save that the
security analyst is the same who have written the ST of the
TOE, which is not always works))
AMA_AMP.1.11C The AM Plan shall describe or reference the procedures to
be applied to maintain the assurance in the TOE, which
shall include the procedures for configuration
management, maintenance of assurance evidence, performance of
the analysis of the security impact of changes affecting the
TOE, and flaw remediation.
(Good news: "only" maintenance of assurance evidence and
security impact analysis is what to be done.)
AMA_CAT.1 TOE component categorisation report
AMA_CAT.1.1C The TOE component categorisation report shall categorise
each component of the TOE, identifiable in each TSF
representation from the most abstract to the least abstract,
according to its relevance to security; TOE component
categorisation must indicate whether the component is
TSP-enforcing or non-TSP- enforcing.
(Each security function, module, and procedure (e.g.C function
should be categorized in EAL4)
AMA_CAT.1.2C The TOE component categorisation report shall describe
the categorisation scheme used, so that it can be determined how
to categorise new components introduced into the TOE, and also
when to re-categorise existing TOE components following changes
to the TOE or its security target.
(If a procedure
-modifies TSF data
-makes decision based on TSF data
-does other security relevant activity based on TSF data
-depends on a TSP-enforcing procedure
The module contains a TSP-enforcing function.)
AMA_CAT.1.3C The TOE component categorisation report shall identify
any tools used in the development environment that, if modified,
will have an impact on the assurance that the TOE satisfies its
security target.
(Which tool is not?)
AMA_EVD.1 Evidence of maintenance process
AMA_EVD.1.1D The developer security analyst shall provide AM
documentation for the current version of the TOE.
AMA_EVD.1.1C The AM documentation shall include a configuration list
and a list of identified vulnerabilities in the TOE.
(Packages.gz, DSA list)
AMA_EVD.1.2C The configuration list shall describe the configuration
items that comprise the current version of the TOE.
(See ACM)
AMA_EVD.1.3C The AM documentation shall provide evidence that the
procedures documented or referenced in the AM Plan are being
followed.
(BTS could be used)
AMA_EVD.1.4C The list of identified vulnerabilities in the current
version of the TOE shall show, for each vulnerability, that the
vulnerability cannot be exploited in the intended environment
for the TOE.
(As there is either a fix or a workaround)
AMA_SIA.2 Examination of security impact analysis
AMA_SIA.2.1D The developer security analyst shall, for the current
version of the TOE, provide a security impact analysis that
covers all changes affecting the TOE as compared with the
certified version.
(The developer hopefully does it, but rarely document.
Should have been.)
AMA_SIA.2.1C The security impact analysis shall identify the certified
TOE from which the current version of the TOE was derived.
(Aversion number.)
AMA_SIA.2.2C The security impact analysis shall identify all new and
modified TOE components that are categorised as TSP-enforcing.
(diff -u :)
AMA_SIA.2.3C The security impact analysis shall, for each change
affecting the security target or TSF representations, briefly
describe the change and any effects it has on lower
representation levels.
(One does not change the ST without good reason. I would
actually 1. come out with an idea, 2. implement it,
3. draw the ST changes from the idea and changes
of implementation representation (source code))
AMA_SIA.2.4C The security impact analysis shall, for each change
affecting the security target or TSF representations, identify
all IT security functions and all TOE components categorised as
TSP-enforcing that are affected by the change.
(It also can easily be drawn from source.)
AMA_SIA.2.5C The security impact analysis shall, for each change which
results in a modification of the implementation representation
of the TSF or the IT environment, identify the test evidence
that shows, to the required level of assurance, that the TSF
continues to be correctly implemented following the change.
(Regresion test is a good thing, and it should always be
done. Just we have to have tests to start with:)
AMA_SIA.2.6C The security impact analysis shall, for each applicable
assurance requirement in the configuration management (ACM),
life cycle support (ALC), delivery and operation (ADO) and
guidance documents (AGD) assurance classes, identify any
evaluation deliverables that have changed, and provide a brief
description of each change and its impact on assurance.
(Diff -u helps a lot:)
AMA_SIA.2.7C The security impact analysis shall, for each applicable
assurance requirement in the vulnerability assessment (AVA)
assurance class, identify which evaluation deliverables have
changed and which have not, and give reasons for the decision
taken as to whether or not to update the deliverable.
(One cannot easily avoid thinking if uses CC:)
--
GNU GPL: csak tiszta forrásból
