From 05c8252556e6aedab08c98415c291089d302f7f9 Mon Sep 17 00:00:00 2001 From: Ian Grigg Date: Thu, 12 Mar 2009 14:33:41 +0000 Subject: [PATCH] 3rd batch: dropped blue, green, sections 9.2, 9.4. PD take to board. git-svn-id: http://svn.cacert.org/CAcert/Policies@1209 14b1bab8-4ef6-0310-b690-991c95c89dfd --- SecurityPolicy.html | 187 +++++++------------------------------------- 1 file changed, 27 insertions(+), 160 deletions(-) diff --git a/SecurityPolicy.html b/SecurityPolicy.html index ed0f437..db8116e 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -4,43 +4,11 @@ Security Policy - - + -

Security Policy for CAcert Systems

-

CAcert Security Policy Status == wip +

CAcert Security Policy Status == wip
Creation date: 2009-02-16
Status: work-in-progress @@ -166,15 +134,9 @@ for audit purposes (DRC). It is under the control of Policy on Policy for version purposes.

-

These parts are not part of the policy: green comments, red errors.

-

This policy document says what is done, rather than how to do it. - - -Some sections are empty, which means -"refer to the Manual." - +Some sections are empty, which means "refer to the Manual."

1.4.2. The Security Manual (Practices) Document

@@ -194,10 +156,8 @@ It is located and version-controlled on the CAcert wiki. Section Headings are the same in both documents. Where Sections are empty in one document, they are expected to be documented in the other. - "Document further in Security Manual" can be implied from any section heading in the Policy. -

1.4.3. The Security Procedures

@@ -225,16 +185,6 @@ access security.

2.2. Physical Assets

- -

2.2.1. Computers

Computers shall be inventoried before being put into service. @@ -244,9 +194,7 @@ List must be subject to change control.

- Each unit shall be distinctly and uniquely identified on all visible sides. - Machines shall be housed in secured facilities (cages and/or locked racks).

@@ -343,11 +291,9 @@ one systems administrator present.

- There is no inherent authorisation to access the data. Systems Administrators are authorised to access the raw data under the control of this policy. - All others must not access the raw data. All are responsible for protecting the data from access by those not authorised. @@ -363,13 +309,11 @@ All physical accesses are logged and reported to all.

There must not be a procedure for emergency access. - If, in the judgement of the systems administrator, emergency access is required and gained, in order to avoid a greater harm, independent authorisation before the Arbitrator must be sought as soon as possible. - See DRP.

@@ -393,9 +337,7 @@ systems administration team leader. These diagrams should include cabling information, physical port configuration details, expected/allowed data flow directions, - and any further pertinent information, - as applicable. Diagrams should be revision controlled, and must be updated when any change is made. @@ -409,12 +351,10 @@ should be visible externally; systems and servers which do not require access to the Internet for their normal operation must not be granted that access. - If such access becomes temporarily necessary for an authorized administrative task, such access may be granted under the procedures of the SM and must be reported and logged. -

3.1.1.2. Internal connectivity
@@ -470,8 +410,6 @@ Documentation for installing and configuring servers with the appropriate softwa

3.2.3. Patching

-

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

-

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

@@ -487,11 +425,7 @@ an emergent local exploit may also be deemed to be an emergency). Application of patches in this case may occur as soon as possible, bypassing the normal configuration-change process. The systems administration team leader must either approve the patch, -instruct remedial action, - -and - -refer the case to dispute resolution. +instruct remedial action, and refer the case to dispute resolution.

@@ -500,10 +434,8 @@ Declaration of an emergency patching situation should not occur with any regular Emergency patch events must be documented within the regular summaries - by the team leader to Board independent of filed disputes. -

3.3. Application

@@ -519,39 +451,32 @@ approve the installation of each release or patch.

Any changes made to source code must be referred back to software assessment team - and installation needs to be deferred until approved by the Software Assessment Team. -

3.4. Access control

- All access to critical data and services shall be controlled and logged. - +

3.4.1. Application Access

- +

General access for Members shall be provided via a dedicated application. General features are made available according to Assurance Points and similar methods controlled in the software system. - - -

what about web-api interfaces? Excluded?

+

3.4.2. Special Authorisation

- Additional or special access is granted according to the authorisations on the below access control lists - (see §1.1.1):

@@ -601,11 +526,9 @@ All changes to the above lists are approved by the board of CAcert.

3.4.3. Authentication

- Strong methods of authentication shall be used wherever possible. All authentication schemes must be documented. -

3.4.4. Removing access

@@ -643,13 +566,9 @@ to CAcert sysadmins in all cases.
4.1.1.1. Authorized users

-Only system administrators designated on the -Access Lists -in §3.4.2 -are authorized to access accounts, - +Only system administrators designated on the Access Lists +in §3.4.2 are authorized to access accounts, unless specifically directed by the Arbitrator. -

4.1.1.2. Access to Systems
@@ -660,7 +579,7 @@ All access is secured, logged and monitored.
4.1.1.3. Changing

-The procedure for changing passphrases and SSH keys shall be documented. +The procedure for changing passphrases and SSH keys shall be documented.

4.1.2. Required staff response time

@@ -671,9 +590,7 @@ Response times should be documented for Disaster Recovery planning. See §6

4.1.3. Change management procedures

All changes made to system configuration must be recorded - and reported in regular summaries to the board of CAcert. -

4.1.4. Outsourcing

@@ -739,12 +656,10 @@ Disaster recovery backups may be distributed.

4.3.4. Retention period and Re-use

-

- See §2.2.3. -

+

4.3.5. Encryption

Backups must be encrypted and must only be transmitted via secured channels. @@ -785,9 +700,7 @@ See CCA.

4.4.2. System logs

- See §4.2.1. -

4.4.3. Incident reports

@@ -816,14 +729,7 @@ an initial assessment of severity and priority must be made.

5.2.2. Communications

-An initial report should be - -circulated. - -sent to systems administrators -and wider interested parties. - - +An initial report should be circulated.

@@ -831,15 +737,13 @@ A communications forum should be established for direct support of high priority or high severity incidents.

-

5.2.3. Escalation

+

5.2.3. Escalation

A process of escalation should be established - for oversight and management purposes, proportional to severity and priority. Oversight starts with four eyes and ends with the Arbitrator. Management starts with the team leader and ends with the Board. -

5.4. Investigation

@@ -855,7 +759,7 @@ evidence must be secured and escalated to Arbitration.

5.6. Report

-Incident reports shall be be published. +Incident reports shall be be published. The Incident Report is written on closing the investigation. A full copy should be appended to the documentation of the investigation. @@ -871,9 +775,7 @@ and progress information should be published as soon as possible. The knowledge of the existence of the event must not be kept secret, nor the manner and methods be kept confidential. - See §9.7. -

6. DISASTER RECOVERY

@@ -906,20 +808,14 @@ Board must have a basic plan to recover. Board must maintain a key persons List with all the contact information needed. See §10.1. - The list shall be accessible even if CAcert's infrastructure is not available. -

7. SOFTWARE ASSESSMENT

-

-Change name of this to Software Assessment. -

-

Software assessment team is responsible for the security of the code. @@ -1031,9 +927,7 @@ The software interface gives features to Support Engineer. Access to the special features is under tight control. Additions to the team are approved by Board, and the software features are under CCS. - See §3.4.2. -

@@ -1055,10 +949,9 @@ policies and practices.

8.2. Responsibilities

-

Support Engineers have these responsibilities: -

+

  • Account Recovery, as documented in the Security Manual. @@ -1069,17 +962,14 @@ Support Engineers have these responsibilities:
  • Tasks and responsibilities as specified in other policies, such as DRP.
-

8.3. Channels

- Support may always be contacted by email at support at cacert dot org. Other channels may be made available and documented in Security Manual. -

8.4. Records and Logs

@@ -1091,7 +981,7 @@ in Security Manual.

8.5. Arbitration

- +

Support Engineers refer questions requiring authority to Arbitration, and may also be called upon to act as default Case Managers. @@ -1100,7 +990,8 @@ See DRP and Support Engineers should be familiar with these topics, even if not listed as Arbitrators or Case Managers. - +

+

8.6. References

@@ -1282,20 +1173,16 @@ to coordinate technical testing and training, especially of new team members.

- -

9.2. Key changeover

- +

9.2. Key generation/transfer

-

9.3. Key generation/transfer

- -

9.3.1. Root Key generation

+

9.2.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.2.2. Backup and escrow

Root keys must be kept on reliable removable media used for that purpose only. @@ -1309,32 +1196,12 @@ 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.2.3. Recovery

-Recovery must only be conducted - -under Arbitrator authority. - -A recovery exercise should be conducted approximately every year. - - +Recovery must only be conducted under Arbitrator authority.

-

9.4. Root certificate changes

- -

9.4.1. Creation

- -

Document.

- -

9.4.2. Revocation

-

Document.

- -

9.4.3. Public notification

- -

-Board has responsibility for formal advisory to the public. -

9.5. Legal

@@ -1362,7 +1229,7 @@ and becomes your authority to act.

9.6. Outsourcing

-

+

Components may be outsourced. Team leaders may outsource non-critical components on notifying the board. @@ -1374,7 +1241,7 @@ Any outsourcing arrangements must be documented. All arrangements must be:

-