diff --git a/SecurityPolicy.html b/SecurityPolicy.html index ba16ce7..cb478bf 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -130,6 +130,28 @@ deriving from the above principles.

1.3. Definition of Terms

+
Access Engineer
+
+ A Member who manages the critical hardware, + including maintenance, access control and physical security. + See §1.1. +
+ +
Software Developer
+
+ A Member who reviews patches for security and workability, + signs-off on them, and incorporates them into the repository. + See §7. +
+ +
Support ??? noun needed here
+
+ A Member who mans the support list, + and has access to restricted + data through the online interface. + See §8. +
+
Systems Administrator
A Member who manages a critial system, and has access @@ -179,16 +201,6 @@ Each procedure must be referenced explicitly in the Security Manual.

2. PHYSICAL SECURITY

- - -

-Physical assets and security procedures are generally provided and maintained as set forth in the Memorandum of Understanding between CAcert and Stichting Oophaga Foundation of 10 July 2007, and as amended from time to time. Approval of both boards of CAcert and Oophaga is required for changes to the MoU. -

- -

-The MoU places responsibility for the physical assets (hardware), hosting and for control of access to the hardware with Oophaga. -

-

2.1. Facility

@@ -200,15 +212,22 @@ access security.

2.2. Physical Assets

2.2.1. Computers

Computers shall be inventoried before being put into service. -Inventory list shall be available to all Systems Administrators. +Inventory list shall be available to all +Access Engineeers and all Systems Administrators. +List must be subject to change control. +

+ +

Units shall have nickname clearly marked on front and rear of chassis. Machines shall be housed in secured facilities (cages and/or locked racks).

@@ -222,12 +241,6 @@ Precautions must be taken to prevent equipment being prepared in advance.

-

-Acquisition may be done by CAcert systems administrators -but the ownership and control of the hardware transfers -to Oophaga the moment the equipment is in use. -

-

2.2.2. Cables

@@ -241,10 +254,8 @@ with identification of end points.

Storage media (disk drives, tapes, removable media) -are inventoried upon acquisition. -CAcert system administrators will report any changes -in the use or location of the media to the routine -logging list for update to the inventory. +are inventoried upon acquisition +and tracked in their use.

@@ -256,14 +267,16 @@ securely wiped and reformatted before use.

Removable media shall be securely stored at all times, -including when not in use. When there is a change to -status of media, a report is made to the log specifying -the new status -(sysadmins present, steps taken, location of storage, etc). +including when not in use. Drives that are kept for reuse are wiped securely before storage. Reuse can only be within critical systems.

+

+When there is a change to status of media, +a report is made to the log specifying the new status. +

+

2.2.3.3 Retirement

@@ -273,19 +286,9 @@ The following steps are to be taken:

  1. - The media is to be securely erased. + The media is to be securely erased, and
  2. - One of the following, in order of preference: -
    1. - rendered unreadable via physical means that - destroys the platters and electronics, or, -
    2. - disposed of via a licensed disposal facility, or -
    3. - sealed and stored securely until the data has expired. - The years of retirement and of expiry should be marked - by CAcert systems administrator. -
    + The media is securely destroyed.

@@ -317,7 +320,13 @@ At least one CAcert systems administrator will be present for logical access to CAcert critical servers. Only the most basic and safest of accesses should be done with one CAcert systems administrator present. -Others must not access the data. +

+ +

+Only Systems Administrators are authorised to access the data. +All others must not access the data. +All are responsible for protecting the data +from access by those not authorised.

2.3.3. Access Logging

@@ -343,7 +352,6 @@ codes and devices (keys) are to be authorised and documented.

-

3. LOGICAL SECURITY

3.1. Network

@@ -382,10 +390,6 @@ All ports to which outbound traffic is initiated shall be documented; traffic to

3.1.3. Intrusion detection

-

-(iang:) this one is covered in DRC-A.5.f. which says: "The security manual describes how computer systems are configured and updated to protect them against hostile intrusion, unauthorized electronic access, and "malware" and how individuals are authorized to perform those tasks." -

-

Logs should be examined regularly (by manual or automatic means) for unusual patterns and/or traffic; anomalies should be investigated as they are discovered and should be reported to appropriate personnel in near-real-time (e.g. text message, email) and investigated as soon as possible. Suspicious activity which may indicate an actual system intrusion or compromise should trigger the incident response protocol described in section 5.1.

@@ -445,11 +449,6 @@ Emergency patch events must be documented within the regular summaries to Board.

3.3. Application

-

-This section deals with applications written in-house.
-CPS 6.6 refers to this section for all info. -

-

Software development takes place on various test systems (not a critical system). See §7. Once offered by Software Development (team), system administration team leader has to approve the installation of each release or patch.

@@ -468,16 +467,6 @@ 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.

-

-Direct command-line access to critical systems shall only be granted to systems administrators designated on the Remote and Virtual Access and Contact List (SSH Access List). Systems administrators who appear on the CAcert _Access_ List in the MoU, Appendix B, are implied to be on the SSH Access List. -

- - -

3.4.1. Authorisation

@@ -485,14 +474,18 @@ The access control lists are:

-Changes to the above lists are approved by the board. +All changes to the above lists are approved by the board of CAcert.

3.4.2. Authentication

@@ -504,12 +497,11 @@ A strong method of authentication is used and documented.

3.4.3. Removing access

-Upon resignation from systems administration team, or determination by two members of the OS access list that access is no longer required, an entity's access to CAcert systems may be be temporarily removed. The removal is made permanent when the Board approves the change to the Access List. +Termination actions must be documented, +including resignation, arbitration, or determination +by team or board.

-

Maybe easier just to say, on direction of the Arbitrator.

- - @@ -693,6 +685,65 @@ Access to incident reports is restricted.

5. INCIDENT RESPONSE

+ +

5.1. Incidents

+ +

+Incidents and sources of important events and logging should be documented. +

+ +

5.2. Detection

+

+The standard of monitoring, alerting and reporting must be documented. +

+ +

5.3. Immediate Action

+

5.2.1. Severity and Priority

+

+On discovery of an incident, +an initial assessment of severity and priority must be made. +

+ +

5.2.2. Communications

+

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

+ +

+A communications forum should be established for direct +support of high priority or high severity incidents. +

+ +

5.2.3. Oversight

+

+A process of escalation of oversight should be eastablished. +

+ +

5.4. Investigation

+

+Incidents must be investigated. +The investigation must be documented. +Evidence must be secured if the severity is high. +

+ +

5.5. Response

+

Document.

+

5.6. Report

+

+A report should be appended to the documentation of the investigation, +and distributed in the act of closing the investigation. +

+ +

+Incidents are not normally kept secret or confidential. +Ony under a defined exception under policy, +or under the oversight of the Arbitrator, +may confidentiality be maintained. +The knowledge of the existence of the event must not be kept +secret, nor the manner in which it is kept confidential. +

+

6. DISASTER RECOVERY

7. SOFTWARE DEVELOPMENT

8. SUPPORT

@@ -930,6 +981,37 @@ All external inquiries of security import are filed as disputes and placed befor Only the Arbitrator has the authority to deal with external requests and/or create a procedure. Systems administrators, board members and other key roles do not have the authority to answer legal inquiry. The Arbitrator's ruling may instruct individuals, and becomes your authority to act.

+

9.6. Outsourcing

+ +

+CAcert may at its option outsource critical components to +other organisations, however this must not be a barrier +to security. Outsourced arrangements must be transparent. +

+ +

+Any outsourcing arrangements must be documented. +All arrangements must be: +

+ + + +

+Specifically, all involved personnel must be CAcert Assurers. +Contracts should be written with the above in mind. +

+