Assurance measures: ALC (The hidden treasure of Debian)
Hi!
We will see here the assurance measures related to life cycle support.
This is an area where Debian shines out even from the other open
source projects.
ALC_DVS.2 Sufficiency of security measures (EAL6, EAL7)
ALC_DVS.2.1D The developer shall produce development security
documentation.
(Policy manual, developer's reference, and the various
policies related to project resources.)
ALC_DVS.2.1C The development security documentation shall describe
all the physical, procedural, personnel, and other security
measures that are necessary to protect the confidentiality and
integrity of the TOE design and implementation in its
development environment.
(Well, the word "confidentality" is not applicable in our
case. Otherwise there are numerous measures.)
ALC_DVS.2.2C The development security documentation shall provide
evidence that these security measures are followed during the
development and maintenance of the TOE.
(As most of the measures are enforced by technical means,
and the rest is mediated by the BTS or e-mail (mostly
mailing lists), the evidence is plenty.)
ALC_DVS.2.3C The evidence shall justify that the security measures
provide the necessary level of protection to maintain the
confidentiality and integrity of the TOE.
(After the recent breakin, one could conclude that they
aren't. But the code base isn't touched, and the necessary
lessons are being drawn.)
ALC_FLR.3 Systematic flaw remediation ("above EAL7": no flaw remediation
is mandated by any EALs)
ALC_FLR.3.1D The developer shall document the flaw remediation
procedures provide flaw remediation procedures addressed to TOE
developers.
(http://www.debian.org/security/)
ALC_FLR.3.2D The developer shall establish a procedure for accepting
and acting upon all reports of security flaws and requests for
corrections to those flaws.
(see above)
ILC_FLR.3.3D The developer shall provide flaw remediation guidance
addressed to TOE users.
(see above)
ALC_FLR.3.1C The flaw remediation procedures documentation shall
describe the procedures used to track all reported security
flaws in each release of the TOE.
(http://www.debian.org/security/faq#policy
http://www.debian.org/security/faq#testing
http://www.debian.org/security/faq#contrib)
ALC_FLR.3.2C The flaw remediation procedures shall require that a
description of the nature and effect of each security flaw be
provided, as well as the status of finding a correction to that
flaw.
(The advisories do that)
ALC_FLR.3.3C The flaw remediation procedures shall require that
corrective actions be identified for each of the security
flaws.
(The advisories do that)
ALC_FLR.3.4C The flaw remediation procedures documentation shall
describe the methods used to provide flaw information,
corrections and guidance on corrective actions to TOE users.
(Links to advisories, security announce mailing list,
and rdf newsfeeds on www.debian.org/security do that.)
ALC_FLR.3.5C The flaw remediation procedures documentation shall
describe a means by which the developer receives from TOE users
reports and enquiries of suspected security flaws in the TOE.
( http://www.debian.org/security/faq#contact)
ALC_FLR.3.6C The procedures for processing reported security flaws
shall ensure that any reported flaws are corrected and the
correction issued to TOE users.
(http://www.debian.org/security/faq#lifespan
It is done for all released Debian version. I judge
that this counts as fulfilling the requirement.)
ALC_FLR.3.7C The procedures for processing reported security flaws
shall provide safeguards that any corrections to these security
flaws do not introduce any new flaws.
(http://www.debian.org/security/faq#oldversion)
ALC_FLR.3.8C The flaw remediation guidance shall describe a means by
which TOE users report to the developer any suspected security
flaws in the TOE.
( http://www.debian.org/security/faq#contact)
ALC_FLR.3.9C The flaw remediation procedures shall include a procedure
requiring timely responses for the automatic distribution of
security flaw reports and the associated corrections to
registered users who might be affected by the security flaw.
( the advisory mailing list registration counts as a
registration, and both the web page and the advisories
contain the distribution point for the corrections)
ALC_FLR.3.10C The flaw remediation guidance shall describe a means by
which TOE users may register with the developer, to be eligible
to receive security reports and corrections.
(Advisory mailing list)
ALC_FLR.3.11C The flaw remediation guidance shall identify the specific
points of contact for all reports and enquiries about security
issues involving the TOE.
( http://www.debian.org/security/faq#contact )
ALC_LCD.3 Measurable life-cycle model (EAL7)
ALC_LCD.3.1D The developer shall establish a life-cycle model to be used
in the development and maintenance of the TOE.
(http://www.debian.org/doc/FAQ/ch-ftparchives.en.html
There should be a more definitive document describing
how much RC bug a release may contain, etc, but I cannot find
it.)
ALC_LCD.3.2D The developer shall provide life-cycle definition
documentation.
(same)
ALC_LCD.3.3D The developer shall use a standardised and measurable
life-cycle model to develop and maintain the TOE.
(Well, the Debian life cycle is the standard open source
life cycle. The PL may should ask opensource.org, to
issue a standard on it:) The life-cycle model is
measured by the number of release-critical bugs.)
ALC_LCD.3.4D The developer shall measure the TOE development using the
standardised and measurable life-cycle model.
(This is the RC bug report we all scan through hoping
that our packages had not mentioned.)
ALC_LCD.3.1C The life-cycle definition documentation shall describe the
model used to develop and maintain the TOE, including the
details of its arithmetic parameters and/or metrics used to
measure the TOE development against the model.
(See 1D)
ALC_LCD.3.2C The life-cycle model shall provide for the necessary
control over the developmentand maintenance of the TOE.
(It does. Sometimes it does a bit more than necessary:)
ALC_LCD.3.3C The life-cycle definition documentation shall explain why
the model was chosen.
(Uh-Oh, a 700-mail thread on -policy should be added as an
appendix;)
ALC_LCD.3.4C The life-cycle definition documentation shall explain how
the model is used to develop and maintain the TOE.
(I did read it. Swear. But where?)
ALC_LCD.3.5C The life-cycle definition documentation shall demonstrate
compliance with the standardised and measurable life-cycle
model.
(What to say on that? Once it will be standardized, it will be
easy to demonstrate compliance.)
ALC_LCD.3.6C The life-cycle documentation shall provide the results of
the measurements of the TOE development using the standardised
and measurable life-cycle model.
(The weekly RC bug reports should be part of it? Okay then.)
ALC_TAT.3 Compliance with implementation standards - all parts (EAL6,
EAL7)
ALC_TAT.3.1D The developer shall identify the development tools
being used for the TOE.
(Build-essential, and some items from build-depends.
ALC_TAT.3.2D The developer shall document the selected
implementation-dependent options of the development tools.
(It is in their debian/rules)
ALC_TAT.3.3D The developer shall describe the implementation standards
for all parts of the TOE.
(Policy manual)
ALC_TAT.3.1C All development tools used for implementation shall be
well-defined.
(debian/rules)
ALC_TAT.3.2C The documentation of the development tools shall
unambiguously define the meaning of all statements used in
the implementation.
(We hope they do, and have the source to make everything
unambigous:)
ALC_TAT.3.3C The documentation of the development tools shall
unambiguously define the meaning of all implementation-dependent
options.
(We hope they do, and have the source to make everything
unambigous:)
--
GNU GPL: csak tiszta forrásból
Reply to: