diff --git a/SecurityPolicy.html b/SecurityPolicy.html index ed0f437..db8116e 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -4,43 +4,11 @@
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."
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. -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. -
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. -
- All access to critical data and services shall be controlled and logged. - +
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?
+- 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.- Strong methods of authentication shall be used wherever possible. All authentication schemes must be documented. -
-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. -
-The procedure for changing passphrases and SSH keys shall be documented. +The procedure for changing passphrases and SSH keys shall be documented.
All changes made to system configuration must be recorded - and reported in regular summaries to the board of CAcert. -
- See §2.2.3. -
+Backups must be encrypted and must only be transmitted via secured channels. @@ -785,9 +700,7 @@ See CCA.
- See §4.2.1. -
-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.
-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. -
-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. -
-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.
Support Engineers have these responsibilities: -
+
- Support may always be contacted by email at support at cacert dot org. Other channels may be made available and documented in Security Manual. -
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. -
+ +Root keys should be generated on a machine built securely for that purpose only and cleaned/wiped/destroyed immediately afterwards.
-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.
-
-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.
Document.
- -Document.
- --Board has responsibility for formal advisory to the public. -
+
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:
-+
CAcert is an open organisation and adopts a principle of open disclosure wherever possible. See @@ -1415,7 +1282,7 @@ if a subject can only sustain under some confidentiality or secrecy, then find another way.
-+
In concrete terms, only under a defined exception under policy, or under the oversight of the Arbitrator,