From d88d1c2fe01440e71ec9ca4f8aa0d7742dbb88bc Mon Sep 17 00:00:00 2001 From: Ian Grigg Date: Sun, 8 Mar 2009 09:19:14 +0000 Subject: [PATCH] more html errors, more name tags git-svn-id: http://svn.cacert.org/CAcert/Policies@1198 14b1bab8-4ef6-0310-b690-991c95c89dfd --- SecurityPolicy.html | 52 ++++++++++++++++++++++----------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/SecurityPolicy.html b/SecurityPolicy.html index 102e095..75534ca 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -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.

-

3.2.1. Disk Encryption

+

3.2.1. Disk Encryption

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.

-

3.2.2. Operating configuration

+

3.2.2. Operating configuration

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

-

3.2.3. Patching

+

3.2.3. Patching

A.1.i, A.1.k:

@@ -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).

-
3.2.3.1. “emergency” patching
+
3.2.3.1. “emergency” patching

Application of a patch is deemed an emergency @@ -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.

-

3.3. Application

+

3.3. Application

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.

-

3.4. Access control

+

3.4. Access control

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.

-

3.4.1. Authorisation

+

3.4.1. Authorisation

This bit is expanded!

@@ -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.

-

3.4.2. Authentication

+

3.4.2. Authentication

A strong method of authentication is used and documented.

-

3.4.3. Removing access

+

3.4.3. Removing access

Follow-up actions to termination must be documented. @@ -991,11 +991,11 @@ team leader, see §3.4.1. -

9. ADMINISTRATIVE

+

9. ADMINISTRATIVE

9.1. Staffing

-

9.1.1. Roles and responsibilities

+

9.1.1. Roles and responsibilities

-

9.1.2. Staffing levels

+

9.1.2. Staffing levels

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.

-

9.1.3. Process of new Team Members

+

9.1.3. Process of new Team Members

New team members need: @@ -1038,7 +1038,7 @@ New team members need: The team supports the process of adding new team members.

-

9.1.4. Background Check Procedures

+

9.1.4. Background Check Procedures

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.

-

9.1.5. Authorisation

+

9.1.5. Authorisation

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.

-

9.1.6. Security

+

9.1.6. Security

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.

-

9.1.7. Termination of staff

+

9.1.7. Termination of staff

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.

-

9.1.8. HR and Training

+

9.1.8. HR and Training

It is the responsibility of the team leaders @@ -1174,14 +1174,14 @@ especially of new team members.

9.3. Key generation/transfer

-

9.3.1. Root Key generation

+

9.3.1. Root Key generation

Root keys should be generated on a machine built securely for that purpose only and cleaned/wiped/destroyed immediately afterwards.

-

9.3.2. Backup and escrow

+

9.3.2. Backup and escrow

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.

-

9.3.3. Recovery

+

9.3.3. Recovery

Recovery must only be conducted under Board or Arbitrator direction. @@ -1204,14 +1204,14 @@ A recovery exercise should be conducted approximately every year.

9.4. Root certificate changes

-

9.4.1. Creation

+

9.4.1. Creation

Document.

-

9.4.2. Revocation

+

9.4.2. Revocation

Document.

-

9.4.3. Public notification

+

9.4.3. Public notification

Board has responsibility for formal advisory to the public. @@ -1219,13 +1219,13 @@ Board has responsibility for formal advisory to the public.

9.5. Legal

-

9.5.1. Responsibility

+

9.5.1. Responsibility

The board is responsible for the CA at the executive level.

-

9.5.2. Response to external (legal) inquiry

+

9.5.2. Response to external (legal) inquiry

All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.