more html errors, more name tags
git-svn-id: http://svn.cacert.org/CAcert/Policies@1198 14b1bab8-4ef6-0310-b690-991c95c89dfd
This commit is contained in:
Ian Grigg
parent
ce12774cd6
commit
d88d1c2fe0
1 changed files with 26 additions and 26 deletions
|
|
@ -408,14 +408,14 @@ Logs should be examined regularly (by manual or automatic means) for unusual pat
|
|||
Any operating system used for critical server machines must be available under an OSI-approved open source software license.
|
||||
</p>
|
||||
|
||||
<h4> 3.2.1. Disk Encryption </h4>
|
||||
<h4><a name="3.2.1"> 3.2.1.</a> Disk Encryption </h4>
|
||||
|
||||
<p>
|
||||
Any operating system used for critical server machines must support software full-disk or disk volume encryption, and this encryption option must be enabled for all relevant disks/volumes when the operating system is first installed on the machine.
|
||||
</p>
|
||||
|
||||
|
||||
<h4> 3.2.2. Operating configuration </h4>
|
||||
<h4><a name="3.2.2"> 3.2.2.</a> Operating configuration </h4>
|
||||
|
||||
<p>
|
||||
Servers must enable only the operating system functions required to support the necessary services. Options and packages chosen at OS install shall be documented, and newly-installed systems must be inspected to ensure that only required services are active, and their functionality is limited through configuration options. Any required application software must follow similar techniques to ensure minimal exposure footprint.
|
||||
|
|
@ -426,7 +426,7 @@ Documentation for installing and configuring servers with the appropriate softwa
|
|||
</p>
|
||||
|
||||
|
||||
<h4> 3.2.3. Patching </h4>
|
||||
<h4><a name="3.2.3"> 3.2.3.</a> Patching </h4>
|
||||
|
||||
<p class="q">A.1.i, A.1.k:</p>
|
||||
|
||||
|
|
@ -434,7 +434,7 @@ Documentation for installing and configuring servers with the appropriate softwa
|
|||
Software used on production servers must be kept current with respect to patches affecting software security. Patch application is governed by CCS and must be approved by the systems administration team leader, fully documented in the logs and reported by email to the systems administration list on completion (see §4.2).
|
||||
</p>
|
||||
|
||||
<h5> 3.2.3.1. “emergency” patching </h5>
|
||||
<h5><a name="3.2.3.1"> 3.2.3.1.</a> “emergency” patching </h5>
|
||||
|
||||
<p>
|
||||
Application of a patch is deemed an <i>emergency</i>
|
||||
|
|
@ -455,7 +455,7 @@ Declaration of an emergency patching situation should not occur with any regular
|
|||
Emergency patch events must be documented within the regular summaries to Board.
|
||||
</p>
|
||||
|
||||
<h3> 3.3. Application </h3>
|
||||
<h3><a name="3.3"> 3.3.</a> Application </h3>
|
||||
|
||||
<p>
|
||||
Software assessment takes place on various test systems (not a critical system). See §7. Once offered by Software Assessment (team), system administration team leader has to approve the installation of each release or patch.
|
||||
|
|
@ -465,7 +465,7 @@ Software assessment takes place on various test systems (not a critical system).
|
|||
Any changes made to source code must be referred back to software assessment team.
|
||||
</p>
|
||||
|
||||
<h3> 3.4. Access control </h3>
|
||||
<h3><a name="3.4"> 3.4.</a> Access control </h3>
|
||||
|
||||
<p class="q">
|
||||
These two paras seem in wrong place.
|
||||
|
|
@ -480,7 +480,7 @@ General user access to CAcert services shall normally be conducted through a web
|
|||
Direct Permissions are managed by the Application to enable special online administrators from the Support Team access to certain functions.
|
||||
</p>
|
||||
|
||||
<h4> 3.4.1. Authorisation </h4>
|
||||
<h4><a name="3.4.1"> 3.4.1.</a> Authorisation </h4>
|
||||
|
||||
<p class="q"> This bit is expanded! </p>
|
||||
|
||||
|
|
@ -531,13 +531,13 @@ The access control lists (see §1.1.1) are:
|
|||
All changes to the above lists are approved by the board of CAcert.
|
||||
</p>
|
||||
|
||||
<h4> 3.4.2. Authentication </h4>
|
||||
<h4><a name="3.4.2"> 3.4.2.</a> Authentication </h4>
|
||||
|
||||
<p>
|
||||
A strong method of authentication is used and documented.
|
||||
</p>
|
||||
|
||||
<h4> 3.4.3. Removing access </h4>
|
||||
<h4><a name="3.4.3"> 3.4.3.</a> Removing access </h4>
|
||||
|
||||
<p>
|
||||
Follow-up actions to termination must be documented.
|
||||
|
|
@ -991,11 +991,11 @@ team leader, see §3.4.1.
|
|||
|
||||
|
||||
|
||||
<h2><a name=Documents"9">9.</a> ADMINISTRATIVE</h2></h3>
|
||||
<h2><a name="9">9.</a> ADMINISTRATIVE</h2>
|
||||
|
||||
<h3> <a name="9.1"> 9.1. </a> Staffing</h3>
|
||||
|
||||
<h3> <a name="9.1.1"> 9.1.1. </a> Roles and responsibilities</h3>
|
||||
<h4> <a name="9.1.1"> 9.1.1. </a> Roles and responsibilities</h4>
|
||||
|
||||
<ul>
|
||||
<li> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
|
||||
|
|
@ -1007,7 +1007,7 @@ team leader, see §3.4.1.
|
|||
<li> Board: authorise new individuals and accesses. Coordinate overall. </li>
|
||||
</ul>
|
||||
|
||||
<h3> <a name="9.1.2"> 9.1.2. </a> Staffing levels</h3>
|
||||
<h4> <a name="9.1.2"> 9.1.2. </a> Staffing levels</h4>
|
||||
|
||||
<p>
|
||||
Each team should have a minimum of two members available at any time.
|
||||
|
|
@ -1022,7 +1022,7 @@ One individual in each team is designated team leader
|
|||
and reports to Board.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.1.3"> 9.1.3. </a> Process of new Team Members</h3>
|
||||
<h4> <a name="9.1.3"> 9.1.3. </a> Process of new Team Members</h4>
|
||||
|
||||
<p>
|
||||
New team members need:
|
||||
|
|
@ -1038,7 +1038,7 @@ New team members need:
|
|||
The team supports the process of adding new team members.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.1.4"> 9.1.4. </a> Background Check Procedures</h3>
|
||||
<h4> <a name="9.1.4"> 9.1.4. </a> Background Check Procedures</h4>
|
||||
<p>
|
||||
Background checks are carried out with full seriousness.
|
||||
Background checks must be conducted under the direction of the Arbitrator,
|
||||
|
|
@ -1108,7 +1108,7 @@ The following privacy considerations exist:
|
|||
CAcert trusted roles give up some privacy for the privacy of others.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.1.5"> 9.1.5. </a> Authorisation </h3>
|
||||
<h4> <a name="9.1.5"> 9.1.5. </a> Authorisation </h4>
|
||||
|
||||
<p>
|
||||
Individuals and access (both) must be authorised by the Board.
|
||||
|
|
@ -1125,7 +1125,7 @@ Deliberations and decisions should be documented.
|
|||
All conflicts of interest should be examined.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.1.6"> 9.1.6. </a> Security</h3>
|
||||
<h4> <a name="9.1.6"> 9.1.6. </a> Security</h4>
|
||||
|
||||
<p>
|
||||
It is the responsibility of all individuals to observe and report on security issues.
|
||||
|
|
@ -1142,7 +1142,7 @@ All secrets and confidentials are reviewable under Arbitration,
|
|||
and may be reversed.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.1.7"> 9.1.7. </a> Termination of staff</h3>
|
||||
<h4> <a name="9.1.7"> 9.1.7. </a> Termination of staff</h4>
|
||||
|
||||
<p>
|
||||
Termination of access may be for resignation, Arbitration ruling,
|
||||
|
|
@ -1160,7 +1160,7 @@ and the Arbitrator may reinstate any provision
|
|||
of this agreement or bind the person to a ruling.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.1.8"> 9.1.8. </a> HR and Training</h3>
|
||||
<h4> <a name="9.1.8"> 9.1.8. </a> HR and Training</h4>
|
||||
|
||||
<p>
|
||||
It is the responsibility of the team leaders
|
||||
|
|
@ -1174,14 +1174,14 @@ especially of new team members.
|
|||
|
||||
<h3> <a name="9.3"> 9.3. </a> Key generation/transfer</h3>
|
||||
|
||||
<h3> <a name="9.3.1"> 9.3.1. </a> Root Key generation</h3>
|
||||
<h4> <a name="9.3.1"> 9.3.1. </a> Root Key generation</h4>
|
||||
|
||||
<p>
|
||||
Root keys should be generated on a machine built securely
|
||||
for that purpose only and cleaned/wiped/destroyed immediately afterwards.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.3.2"> 9.3.2. </a> Backup and escrow</h3>
|
||||
<h4> <a name="9.3.2"> 9.3.2. </a> Backup and escrow</h4>
|
||||
|
||||
<p>
|
||||
Root keys must be kept on reliable removable media used for that purpose only.
|
||||
|
|
@ -1195,7 +1195,7 @@ The top-level root must be escrowed under Board control.
|
|||
Subroots may be escrowed by either Board or Systems Administration Team.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.3.3"> 9.3.3. </a> Recovery</h3>
|
||||
<h4> <a name="9.3.3"> 9.3.3. </a> Recovery</h4>
|
||||
|
||||
<p>
|
||||
Recovery must only be conducted under Board or Arbitrator direction.
|
||||
|
|
@ -1204,14 +1204,14 @@ A recovery exercise should be conducted approximately every year.
|
|||
|
||||
<h3> <a name="9.4"> 9.4. </a> Root certificate changes</h3>
|
||||
|
||||
<h3> <a name="9.4.1"> 9.4.1. </a> Creation</h3>
|
||||
<h4> <a name="9.4.1"> 9.4.1. </a> Creation</h4>
|
||||
|
||||
<p>Document.</p>
|
||||
|
||||
<h3> <a name="9.4.2"> 9.4.2. </a> Revocation</h3>
|
||||
<h4> <a name="9.4.2"> 9.4.2. </a> Revocation</h4>
|
||||
<p>Document.</p>
|
||||
|
||||
<h3> <a name="9.4.3"> 9.4.3. </a> Public notification</h3>
|
||||
<h4> <a name="9.4.3"> 9.4.3. </a> Public notification</h4>
|
||||
|
||||
<p>
|
||||
Board has responsibility for formal advisory to the public.
|
||||
|
|
@ -1219,13 +1219,13 @@ Board has responsibility for formal advisory to the public.
|
|||
|
||||
<h3> <a name="9.5"> 9.5. </a> Legal</h3>
|
||||
|
||||
<h3> <a name="9.5.1"> 9.5.1. </a> Responsibility</h3>
|
||||
<h4> <a name="9.5.1"> 9.5.1. </a> Responsibility</h4>
|
||||
|
||||
<p>
|
||||
The board is responsible for the CA at the executive level.
|
||||
</p>
|
||||
|
||||
<h3> <a name="9.5.2"> 9.5.2. </a> Response to external (legal) inquiry</h3>
|
||||
<h4> <a name="9.5.2"> 9.5.2. </a> Response to external (legal) inquiry</h4>
|
||||
|
||||
<p>
|
||||
All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.
|
||||
|
|
|
|||
Loading…
Reference in a new issue