cacert-policies/ConfigurationControlSpecification.html

255 lines
7.5 KiB
HTML
Raw Normal View History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title>Configuration-Control Specification - work-in-progress</title>
<style type="text/css">
<!--
body {
font-family : verdana, helvetica, arial, sans-serif;
}
th {
text-align : left;
}
.q {
color : green;
font-weight: bold;
text-align: center;
font-style:italic;
}
.error {
color : red;
font-weight: bold;
text-align: center;
font-style:italic;
}
.change {
color : blue;
font-weight: bold;
}
a:hover {
color : gray;
}
-->
</style>
</head>
<body lang="en-GB">
<h1> Configuration-Control Specification </h1>
<!-- Absolute URL because the policies are located absolutely. -->
<a href="http://www.cacert.org/policy/PolicyOnPolicy.php"><img align="right" src="Images/cacert-wip.png" alt="Configuration-Control Specification Status == work-in-progress" border="0"></a><p>
Creation date: 20091214<br>
Editor: Iang<br>
Status: 20100407 <i>WIP </i><br><br>
<h3> <a name="1">1</a> <a name="Introduction"> Introduction </a> </h3>
<!-- This section from A.1.a through A.1.c -->
<p>
The Configuration-Control Specification (CCS) controls and tracks those documents, processes and assets which are critical to the business, security and governance of the CAcert operations.
</p>
<p>
This document is the procedure for CCS.
This document itself is a component of the CCS,
see &sect;2.
<!-- A.1.c The configuration-control specification controls its own revision process. -->
All other documentation and process specified within
is derivative and is ruled by the CCS.
</p>
<p>
CCS is formated, inspired and designed to meet the needs of
DRC-A.1.
CCS may be seen as the index to systems audit under DRC.
</p>
<h3> <a name="2">2</a> <a name="Documents"> Documents </a> </h3>
<!-- A.1.c-h: The configuration-control specification controls the revision process for the CCS,CP,CPS,PP,SP,R/L/O -->
<h4> <a name="2.1">2.1</a> <a name="doc_list"> Controlled Document List </a> </h4>
<p>
This CCS creates a list of Primary or "root" documents known as Policies.
Primary documents may authorise other secondary documents
into the list, or "practices" outside the list.
</p>
<p>
The controlled documents list
contains numbers, locations and versions of all controlled documents.
The list is part of this CCS, and is located at
<a href="http://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">
http://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html</a>
Policy Officer is to manage the list.
Policy Officer is to log the changes at
<a href="http://wiki.cacert.org/PolicyDecisions">
http://wiki.cacert.org/PolicyDecisions</a>.
<!-- See A.1.k, logging of documents. -->
</p>
<h4> <a name="2.2">2.2</a> <a name="doc_change"> Change </a> </h4>
<p>
Change to the documents is as specified by
Policy on Policy (PoP).
</p>
<p class="q"> The following would possibly be better off in PoP (when a change cycle comes around), or a practices manual. </p>
<p>
Policies in effect (DRAFT and POLICY status) are to be under change control.
Fully approved documents (POLICY status)
are published on the CAcert website at
<a href="http://www.cacert.org/policy/">
http://www.cacert.org/policy/</a>
in plain HTML format,
under the same control as critical source code
under Security Policy (SP).
Pre-final work (DRAFT status) and working documents (work-in-progress status)
are made available on community-controlled version management systems
(rooted at Subversion:
<a href="http://svn.cacert.org/CAcert/Policies">
http://svn.cacert.org/CAcert/Policies</a>
wiki:
<a href="http://wiki.cacert.org/PolicyDrafts">
http://wiki.cacert.org/PolicyDrafts</a>).
Documents of lower status (work-in-progress or DRAFT)
must not be confusable with
documents of higher status (DRAFT or POLICY).
Copies should be eliminated where not being worked on.
</p>
<h4> <a name="2.3">2.3</a> <a name="doc_control"> Control </a> </h4>
<p>
CAcert policies are required to be owned / transferred to CAcert. See PoP 6.2.
</p>
<h3> <a name="3">3</a> <a name="Hardware"> Hardware </a> </h3>
<!-- This section from A.1.j -->
<h4> <a name="3.1">3.1</a> <a name="hard_list"> Controlled Hardware List </a> </h4>
<p>
Critical systems are defined by Security Policy.
</p>
<h4> <a name="3.2">3.2</a> <a name="hard_change"> Change </a> </h4>
<p> See Security Policy. </p>
<h4> <a name="3.3">3.3</a> <a name="hard_control"> Control </a> </h4>
<p>
Control of Hardware is the ultimate responsibility of the Board of CAcert Inc.
The responsibility for acts with hardware is delegated
to Access Engineers and Systems Administrators as per
Security Policy.
The ownership responsibility is delegated by agreement to Oophaga.
</p>
<h3> <a name="4">4</a> <a name="Software"> Software </a> </h3>
<!-- A.1.i: The configuration-control specification controls changes to software involved in: certs; data; comms to public -->
<h4> <a name="4.1">4.1</a> <a name="hard_list"> Controlled Software List </a> </h4>
<p>
Critical software is defined by Security Policy.
</p>
<ul class="q">
<li>One thing that is not so well covered by CAcert is the last bullet point of A.1.i
<li>"communicating with subscribers and with the general public."
<li>website is under SP; maillists,blogs,etc are not.
<li>as community has deliberately gone this direction, I suggest we argue it that way.
<li> What is far more problematic is the failure to do CCA & Challenge notification.
</ul>
<h4> <a name="4.2">4.2</a> <a name="soft_change"> Change </a> </h4>
<p> See Security Policy. </p>
<h4> <a name="4.3">4.3</a> <a name="soft_control"> Control </a> </h4>
<p>
CAcert owns its code, or requires control over open source code in use
by means of an approved free and open licence.
Such code must be identified and managed by Software Assessment.
</p>
<p>
Developers transfer full rights to CAcert
(in a similar fashion to documents),
or organise their contributions under a
proper free and open source code regime,
as approved by Board.
Where code is published
(beyond scope of this document)
care must be taken not to infringe licence conditions.
For example, mingling issues with GPL.
</p>
<p>
The Software Assessment Team Leader
maintains a registry of assignments
of title or full licence,
and a registry of software under approved open source licences.
</p>
<ul class="q">
<li> What about translingo and voting? </li>
<li> See <a href="https://lists.cacert.org/wws/arc/cacert-sysadm/2010-02/msg00008.html">thread</a> </li>
</ul>
<h3> <a name="5">5</a> <a name="Certs"> Certificates </a> </h3>
<!-- This section from A.1.b -->
<h4> <a name="5.1">5.1</a> <a name="certs_list"> Certificates List </a> </h4>
<p> Root Certificates are to be listed in the CPS. </p>
<h4> <a name="5.2">5.2</a> <a name="logs_change"> Changes </a> </h4>
<p> Creation and usage of Root Certificates is to be controlled by Security Policy. </p>
<h4> <a name="5.3">5.3</a> <a name="logs_archive"> Archive </a> </h4>
<p> See Security Policy. </p>
<h3> <a name="6">6</a> <a name="Logs"> Logs </a> </h3>
<!-- This section from A.1.k -->
<h4> <a name="6.1">6.1</a> <a name="logs_list"> Controlled Logs List </a> </h4>
<p> Logs are defined by Security Policy. </p>
<h4> <a name="6.2">6.2</a> <a name="logs_change"> Changes </a> </h4>
<p> Changes to Hardware, Software and Root Certificates are logged according to Security Policy. </p>
<h4> <a name="6.3">6.3</a> <a name="logs_archive"> Archive </a> </h4>
<p> See Security Policy. </p>
</body></html>