diff --git a/SecurityPolicy.html b/SecurityPolicy.html index 2da60fa..957a1e8 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -4,7 +4,7 @@ - Security Policy - work-in-progress + Security Policy - DRAFT - - -

-WIP Changes are all marked in BLUE or struck-out. -Explanatory comments in GREEN are not part of text.
+

+This version: going to DRAFT p20100510

- -

Start of Policy

Security Policy for CAcert Systems

@@ -87,9 +35,9 @@ Explanatory comments in GREEN are not part of text.
Creation date: 20090216
Editor: iang
- Status: WIP m20100327.2 as of 20100404 00:00:02 UTC

+ Status: DRAFT p20100510

- Security Policy Status == WIP + Security Policy Status == DRAFT

1. INTRODUCTION

@@ -110,8 +58,7 @@ These systems include: Source code (changes and patches)

-Board -The Committee of CAcert, Inc. (hereafter, "Board") +The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual.

@@ -130,7 +77,6 @@ These roles are defined as: Support Engineer
  • Software Assessor -(including Application Engineers)

    • 1.1.2. Out of Scope

    @@ -184,14 +130,6 @@ deriving from the above principles. See §1.1. -
    Application Engineer
    -
    - A Member who manages the critical application, - including installing them on the critical system, - final testing, emergency patching, and ad hoc scripting. - See §7.2. -
    -
    Software Assessor
    A Member who reviews patches for security and workability, @@ -239,12 +177,7 @@ The SM says how things are done. As practices are things that vary from time to time, including between each event of practice, the SM is under the direct control of the - -Systems Administration team - - applicable team leaders. - It is located and version-controlled on the CAcert wiki.

    @@ -295,19 +228,11 @@ Machines shall be housed in secured facilities (cages and/or locked racks).

    2.2.1.1 Acquisition

    -

    +

    Equipment for critical purposes should be acquired in a way to minimise pre-acquisition security risks.

    -

    -Acquisition of new equipment that is subject to a -pre-purchase security risk must be done from a -vendor that is regularly and commercially in business. -Precautions must be taken to prevent equipment being -prepared in advance. -

    -

    2.2.2. Service

    @@ -327,10 +252,7 @@ are inventoried upon acquisition and tracked in their use.

    New storage media (whether disk or removable) shall be -securely -wiped -erased -and reformatted before use. +securely erased and reformatted before use.

    2.2.3.2 Storage

    @@ -339,9 +261,7 @@ and reformatted before use. Removable media shall be securely stored at all times, including when not in use. Drives that are kept for reuse are -wiped -erased - securely before storage. +erased securely before storage. Reuse can only be within critical systems.

    @@ -400,9 +320,6 @@ one Systems Administrator present.

    There is no inherent authorisation to access the data. Systems Administrators - -and Application Engineers - are authorised to access the raw data under the control of this policy. All others must not access the raw data. @@ -523,7 +440,6 @@ 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).

    @@ -538,10 +454,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 - -or - -instruct remedial action, and refer the case to dispute resolution. +or instruct remedial action, and refer the case to dispute resolution.

    @@ -556,13 +469,7 @@ independent of filed disputes.

    3.3. Application

    -

    -Systems administration is to provide a limited environment -to Applications Engineers in order to install and maintain -the application. -

    - -

    +

    Requests for ad hoc queries over the application database for business or similar purposes must be approved by the Arbitrator.

    @@ -603,38 +510,36 @@ authorisations on the below access control lists Access Engineers control of access by personnel to hardware exclusive of all other roles - Access team leader Board of CAcert (or designee) + Access team leader Physical Access List Systems Administrators hardware-level for installation and recovery exclusive with Access Engineers and Software Assessors - Systems Administration team leader Board of CAcert (or designee) + Systems Administration team leader SSH Access List - Systems Administrators and Application Engineers + Systems Administrators Unix / account / shell level includes by default all on Physical Access List Systems Administration team leader Repository Access List - Software Assessors Application Engineers - change the source code repository and install patches to application + Software Assessors + change the source code repository exclusive with Access Engineers and Systems Administrators - software assessment team leader + Software Assessment team leader Support Access List Support Engineer support features in the web application - exclusive with Access Engineers and Systems Administrators includes by default all Application Engineers Systems Administrators - Systems Administration Support team leader + exclusive with Access Engineers and Systems Administrators + Support team leader -

    All changes of personnel to the above lists are -subject to Board approval. -approved by the Board of CAcert. +subject to Board approval.

    3.4.3. Authentication

    @@ -670,29 +575,23 @@ and hardware maintenance.

    4.1.1. Privileged accounts and passphrases

    -Access to privileged accounts +Access to privileged accounts (root and user via SSH or console) must be strictly controlled. Passphrases and SSH private keys used for entering into the systems will be kept private to CAcert sysadmins -and Application Engineers in all cases.

    4.1.1.1. Authorized users

    -Only System Administrators -and Application Engineers +Only Systems Administrators designated on the Access Lists in §3.4.2 are authorized to access accounts. - -System Administration team leader may temporarily permit Software +Systems Administration team leader may temporarily permit Software Assessors access to the application via SSH in order to do advanced -debugging, or as - -Other -specifically directed by the Arbitrator. +debugging, or as specifically directed by the Arbitrator.

    @@ -953,8 +852,7 @@ for the security and maintenance of the code.

    The source code is under CCS. Additions to the team are -subject to Board approval. -approved by the Board. +subject to Board approval. See §3.4.2.

    @@ -977,57 +875,8 @@ Software assessment is not primarily tasked to write the code. In principle, anyone can submit code changes for approval.

    -

    Moved to SM 3.3

    -

    -The primary tasks for Application Engineers are: -

    -
    1. - Installing signed-off patches, -
    2. - Verifying correct running, -
    3. - Correcting immediate errors and copying fixes back to - upstream repositories, -
    4. - Running ad-hoc database scripts and other programs, -
    5. - Repairing data errors, -
    6. - Backing up at the database level, -
    7. - Watching application-level logs. -
    - - -

    7.3. Repository

    -

    As we are still unsure how to do Repository, I recommend we make this section blank. Therefore, it is handled in Security Manual. Iang, 20100502.

    - -

    -The application code and patches are maintained -in a central repository that is run by the -software assessment team. -

    - - - - -

    -The development code and testing patches are maintained -in a central development repository that is run by the -software assessment team. -

    - -

    -The production code is maintained in a secure production repository -within the critical systems that is run by the -Systems Administation team. -Access is made available to the Application Engineers. -

    -

    7.4. Review

    @@ -1057,35 +906,7 @@ Bug submission access should be provided to any Member that requests it.

    -

    7.6. Handover Production

    - -

    Blank, now refer to SM 7.6

    -

    -The Application Engineer is a role within Software Assessment -team that is approved to install into production the -patches that are signed off. - -Once signed off, the Application Engineer -commits the patch from the development repository -to the production repository, -and installs the patch from the production repository -into the running code. -The Application Engineer is responsible for basic -testing of functionality and emergency fixes, -which then must be back-installed into the repositories. - -

    - -

    this below moved to §3.3

    - -

    -Requests to Application Engineers for ad hoc queries over the database for business or similar purposes must be approved by the Arbitrator. -

    - -

    -See §3.3. -

    - +

    7.6. Production

    8. SUPPORT

    @@ -1094,9 +915,7 @@ See §3.3.

    The software interface gives features to Support Engineer. Access to the special features is under tight control. -Additions to the team are -subject to Board approval, -approved by the Board, +Additions to the team are subject to Board approval, and the software features are under CCS. See §3.4.2.

    @@ -1125,7 +944,7 @@ Support Engineers have these responsibilities:

    9.1.2. Staffing levels

    @@ -1241,7 +1059,7 @@ An investigation within ABC should include examination of:

    9.1.4.2. Coverage

    ABC is to be done on every individual in a critical role. -See §1.1.1. +See §1.1.1.

    9.1.4.3. Documentation

    @@ -1291,9 +1109,7 @@ with the relevant supporting information as above.

    The Board should deliberate directly and in full. Board members who are also active in the area should -recuse -abstain -from the vote, +abstain from the vote, but should support the deliberations. Deliberations and decisions should be documented. All conflicts of interest should be examined. @@ -1306,13 +1122,7 @@ It is the responsibility of all individuals to observe and report on security issues. All of CAcert observes all where possible. It is the responsibility of each individual to resolve -it -issues -satisfactorily, -or to ensure that -it is -they are -reported fully. +issues satisfactorily, or to ensure that they are reported fully.

    @@ -1350,17 +1160,14 @@ especially of new team members.

    9.2.1. Root Key generation

    -Root keys are generated only on instruction from the Board. +Root keys are generated only on instruction from Board. They must be generated to a fully documented and reviewed procedure. The procedure must include: