diff --git a/SecurityPolicy.html b/SecurityPolicy.html index 2da60fa..957a1e8 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -4,7 +4,7 @@
-
-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
Creation date: 20090216 Editor: iang - Status: WIP m20100327.2 as of 20100404 00:00:02 UTC + Status: DRAFT p20100510 |
- ![]() ![]() |
-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+
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. -
-@@ -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.
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.
-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 listsAll changes of personnel to the above lists are -subject to Board approval. -approved by the Board of CAcert. +subject to Board approval.
-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.
-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: -
-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. -
-@@ -1057,35 +906,7 @@ Bug submission access should be provided to any Member that requests it.
-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. -
- +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:ABC is to be done on every individual in a critical role. -See §1.1.1. +See §1.1.1.
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.
-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:
-the Board is responsible to the Community to manage +Board is responsible to the Community to manage the CA at the executive level.
@@ -1403,7 +1210,7 @@ the CA at the executive level.All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP. -Board and applicable team leaders must be notified. +Board and applicable team leaders must be notified.
@@ -1421,11 +1228,6 @@ and becomes your authority to act.
Components may be outsourced. - -Team leaders may outsource non-critical components -on notifying the Board. -Critical components must be approved by the Board. - Any outsourcing arrangements must be documented. All arrangements must be:
@@ -1455,9 +1257,7 @@ All arrangements must be:Contracts should be written with the above in mind. - -Outsourcing of critical components must be approved by the Board. - +Outsourcing of critical components must be approved by the Board.