Assurance measures: ACM
Hi!
Sorry for starting with the more boring part. Here is a short overview
of the assurance requirements of Common Criteria, and how they
are covered by Debian (in parenthesis).
This overview is made for the Adamantix developers, but might be
interesting for debian developers also.
This part covers ACM (configuration management). Debian is
really outstanding in this area. Watch out for further issues:)
ACM_AUT.2 Complete CM automation (appears at EAL6, which is a very high
assurance level. Haven't heard about a product above EAL4)
ACM_AUT.2.1D The developer shall use a CM system.
(This is the source repository and the build daemons.
To cover all requirements, a gnu arch or cvs repository
for the sources should be set up.)
ACM_AUT.2.2D The developer shall provide a CM plan.
(This is in the policy manual. Nicely fine grained.)
ACM_AUT.2.1C The CM system shall provide an automated means by which
only authorised changes are made to the TOE implementation
representation, and to all other configuration items.
(This is made by signing the changes file, and by the
ftpadmin approval).
ACM_AUT.2.2C The CM system shall provide an automated means to support
the generation of the TOE.
(Build daemons)
ACM_AUT.2.3C The CM plan shall describe the automated tools used in the
CM system.
(Developers reference)
ACM_AUT.2.4C The CM plan shall describe how the automated tools are
used in the CM system.
(Developers reference)
ACM_AUT.2.5C The CM system shall provide an automated means to
ascertain the changes between the TOE and its preceding version.
('tla what-changed' or 'cvs diff')
ACM_AUT.2.6C The CM system shall provide an automated means to identify
all other configuration items that are affected by the
modification of a given configuration item.
(looking up reverse dependencies)
ACM_CAP.5 Advanced support (appears at EAL6)
(If ACM_CAP.5 seems to be too strong, ACM_CAP.4 is the same but without
13C-21C, and appears at EAL4)
ACM_CAP.5.1D The developer shall provide a reference for the TOE.
(version numbers of packages)
ACM_CAP.5.2D The developer shall use a CM system.
(This is the source repository and the build daemons.
To cover all requirements, a gnu arch or cvs repository
for the sources should be set up.)
ACM_CAP.5.3D The developer shall provide CM documentation.
(policy manual, developers reference)
ACM_CAP.5.1C The reference for the TOE shall be unique to each version
of the TOE.
(Yes, each version have a different version number:)
ACM_CAP.5.2C The TOE shall be labelled with its reference.
(each package have its version number both in the file name
and in the control file)
ACM_CAP.5.3C The CM documentation shall include a configuration list, a
CM plan, an acceptance plan, and integration procedures.
The configuration list shall uniquely identify all
configuration items that comprise the TOE.
(The CM plan, acceptance plan and integration procedures
are described in the policy manual and the developers
reference. The configuration list (dpkg -l) indeed lists
all configuration items (packages) with version number.)
ACM_CAP.5.4C The configuration list shall describe the configuration
items that comprise the TOE.
(apt-cache show does just that)
ACM_CAP.5.5C The CM documentation shall describe the method used to
uniquely identify the configuration items.
(Maybe the apt and/or dpkg man page is also part of the CM
documentation)
ACM_CAP.5.6C The CM system shall uniquely identify all configuration
items.
(name, version)
ACM_CAP.5.7C The CM plan shall describe how the CM system is used.
(the docs are good)
ACM_CAP.5.8C The evidence shall demonstrate that the CM system is
operating in accordance with the CM plan.
(debian/changelog, build daemon logs, etc. There might be minor
issues with it, but not much.)
ACM_CAP.5.9C The CM documentation shall provide evidence that all
configuration items have been and are being effectively
maintained under the CM system.
(see above)
ACM_CAP.5.10C The CM system shall provide measures such that only
authorised changes are made to the configuration items.
(The debian keyring and the ftpmaster)
ACM_CAP.5.11C The CM system shall support the generation of the TOE.
(Build daemons)
ACM_CAP.5.12C The acceptance plan shall describe the procedures used to
accept modified or newly created configuration items as part of
the TOE.
(policy manual)
ACM_CAP.5.13C The integration procedures shall describe how the CM
system is applied in the TOE manufacturing process.
(policy manual. unstable, testing, stable, proposed-updates,
etc)
ACM_CAP.5.14C The CM system shall require that the person responsible
for accepting a configuration item into CM is not the person
who developed it.
(this means that the ftp master cannot be maintainer of
any packages, and the maintainers cannot be the upstream
maintainers)
ACM_CAP.5.15C The CM system shall clearly identify the configuration
items that comprise the TSF.
(this is TODO. have a CC-TSF: control field, which is shown
in apt-get show.)
ACM_CAP.5.16C The CM system shall support the audit of all modifications
to the TOE, including as a minimum the originator, date, and
time in the audit trail.
(The changelogs and the accepts of the ftpmaster should be in
the audit trail. It also seems to be a TODO)
ACM_CAP.5.17C The CM system shall be able to identify the master copy of
all material used to generate the TOE.
(the source uploads, and the download URL in the copyright file)
ACM_CAP.5.18C The CM documentation shall demonstrate that the use of the
CM system, together with the development security measures,
allow only authorised changes to be made to the TOE.
(aside the fact that some devel machines have just been cracked,
it is done)
ACM_CAP.5.19CThe CM documentation shall demonstrate that the use of the
integration procedures ensures that the generation of the TOE
is correctly performed in an authorised manner.
(Maybe two sentences about the controls of the process
in this view should be added.)
ACM_CAP.5.20CThe CM documentation shall demonstrate that the CM system
is sufficient to ensure that the person responsible for accepting a
configuration item into CM is not the person who developed it.
(Well, the ftpmaster's pgp key should be in diferent keyring
than the one of the developers, or something like that. For
the no-upstream rule should be done by scanning the orig
package for the maintainer...)
ACM_CAP.5.21CThe CM documentation shall justify that the acceptance
procedures provide for an adequate and appropriate review of
changes to all configuration items.
(maintainer accepts changes from upstream after review.
ftpadmin accepts changes from maintainer after review)
Reply to: