added some terms;

aligned a few things in sections 2,3 for SM
added 5.
added headings for 6,7,8
added Outsroucing to address the Oophaga confusion


git-svn-id: http://svn.cacert.org/CAcert/Policies@1189 14b1bab8-4ef6-0310-b690-991c95c89dfd

SecurityPolicy.html

@@ -130,6 +130,28 @@ deriving from the above principles.
 <h3><a name="1.3">1.3.</a> Definition of Terms</h3>
 <dl>
 
+<dt><i>Access Engineer</i> </dt>
+<dd>
+    A Member who manages the critical hardware,
+    including maintenance, access control and physical security.
+    See &sect;1.1.
+</dd>
+
+<dt><i>Software Developer </i> </dt>
+<dd>
+    A Member who reviews patches for security and workability,
+    signs-off on them, and incorporates them into the repository.
+    See &sect;7.
+</dd>
+
+<dt><i>Support ???</i> <span class="q"> noun needed here</span> </dt>
+<dd>
+    A Member who mans the support list,
+    and has access to restricted
+    data through the online interface.
+    See &sect;8.
+</dd>
+
 <dt><i>Systems Administrator</i> </dt>
 <dd>
     A Member who manages a critial system, and has access
@@ -179,16 +201,6 @@ Each procedure must be referenced explicitly in the Security Manual.
 
 <h2><a name="2">2.</a> PHYSICAL SECURITY</h2>
 
-
-
-<p>
-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.
-</p>
-
-<p>
-The MoU places responsibility for the physical assets (hardware), hosting and for control of access to the hardware with Oophaga.
-</p>
-
 <h3><a name="2.1">2.1.</a> Facility </h3>
 
 <p>
@@ -200,15 +212,22 @@ access security.
 <h3><a name="2.2">2.2.</a> Physical Assets </h3>
 
 <ul class="q"><li>
-    Big question here is whether Oophaga falls inside SP/SM or not.
+    Big question here is whether Oophaga falls inside SP/SM or not.<br>
+    Answered:  <b>IN</b>.
   </li><li>
-    2nd Big Question is whether Oophaga is in SP or in SM.
+    2nd Big Question is whether Oophaga is in SP or in SM.<br>
+    Answered:  <b>in the SM.</b>
 </li></ul>
 
 <h4><a name="2.2.1">2.2.1.</a> Computers </h4>
 <p>
 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.
+</p>
+
+<p>
 Units shall have nickname clearly marked on front and rear of chassis.
 Machines shall be housed in secured facilities (cages and/or locked racks).
 </p>
@@ -222,12 +241,6 @@ Precautions must be taken to prevent equipment being
 prepared in advance.
 </p>
 
-<p>
-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.
-</p>
-
 <h4><a name="2.2.2">2.2.2.</a> Cables </h4>
 
 <p>
@@ -241,10 +254,8 @@ with identification of end points.
 
 <p>
 Storage media (disk drives, tapes, removable media)
-are inventoried upon acquisition.
+are inventoried upon acquisition
-CAcert system administrators will report any changes
+and tracked in their use.
-in the use or location of the media to the routine
-logging list for update to the inventory.
 </p>
 
 <p>
@@ -256,14 +267,16 @@ securely wiped and reformatted before use.
 
 <p>
 Removable media shall be securely stored at all times,
-including when not in use. When there is a change to
+including when not in use.
-status of media, a report is made to the log specifying
-the new status
-(sysadmins present, steps taken, location of storage, etc).
 Drives that are kept for reuse are wiped securely before storage.
 Reuse can only be within critical systems.
 </p>
 
+<p>
+When there is a change to status of media,
+a report is made to the log specifying the new status.
+</p>
+
 <h4><a name="2.2.3.3">2.2.3.3</a> Retirement </h4>
 
 <p>
@@ -273,19 +286,9 @@ The following steps are to be taken:
 </p>
 
 <ol><li>
-    The media is to be securely erased.
+    The media is to be securely erased, <b>and</b>
   </li><li>
-    One of the following, in order of preference:
+    The media is securely destroyed.
-      <ol type="a"><li>
-         rendered unreadable via physical means that
-         destroys the platters and electronics, or,
-        </li><li>
-         disposed of via a licensed disposal facility, or
-        </li><li>
-         sealed and stored securely until the data has expired.
-         The years of retirement and of expiry should be marked
-         by CAcert systems administrator. 
-      </li></ol>
 </li></ol>
 
 <p>
@@ -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.
+</p>
+
+</p>
+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.
 </p>
 
 <h4><a name="2.3.3">2.3.3.</a> Access Logging </h4>
@@ -343,7 +352,6 @@ codes and devices (keys) are to be authorised and documented.
 </p>
 
 
-
 <h2><a name="3">3.</a> LOGICAL SECURITY</h2>
 
 <h3><a name="3.1">3.1.</a> Network </h3>
@@ -382,10 +390,6 @@ All ports to which outbound traffic is initiated shall be documented; traffic to
 
 <h4><a name="3.1.3">3.1.3.</a> Intrusion detection </h4>
 
-<p class="q">
-(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."
-</p>
-
 <p>
 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. 
 </p>
@@ -445,11 +449,6 @@ Emergency patch events must be documented within the regular summaries to Board.
 
 <h3> 3.3. Application </h3>
 
-<p class="q">
-This section deals with applications written in-house.<br>
-CPS 6.6 refers to this section for all info.
-</p>
-
 <p>
 Software development takes place on various test systems (not a critical system). See &sect;7. Once offered by Software Development (team), system administration team leader has to approve the installation of each release or patch.
 </p>
@@ -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.
 </p>
 
-<p>
-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.
-</p>
-
-<ul class="q">
-   <li> this means that Oophaga have a veto on the administrators who can remote access the data. </li>
-   <li> yet Oophaga have no view over the data, nor authority. </li>
-   <li> Probably the list has to be split into two, one in the MoU framework, and another purely managed by CAcert. </li>
-</ul>
-
 <h4> 3.4.1. Authorisation </h4>
 
 <p>
@@ -485,14 +474,18 @@ The access control lists are:
 </p>
 
 <ul><li>
-    Online support team members,
+    Console Access List,
-    managed by the Systems Administration team leader.
+    for physical access by System Administrators.
   </li><li>
-    SSH Access List, maintained by the Systems Administration team leader.
+    SSH Access List,
+    for access to Unix-level facilities of the online webserver.
+  </li><li>
+    Support Access List,
+    for access to the online support interface features.
 </li></ul>
 
 <p>
-Changes to the above lists are approved by the board.
+All changes to the above lists are approved by the board of CAcert.
 </p>
 
 <h4> 3.4.2. Authentication </h4>
@@ -504,12 +497,11 @@ A strong method of authentication is used and documented.
 <h4> 3.4.3. Removing access </h4>
 
 <p>
-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.
 </p>
 
-<p class="q">Maybe easier just to say, on direction of the Arbitrator.</p>
-
-
 
 
 
@@ -693,6 +685,65 @@ Access to incident reports is restricted.
 
 
 <h2><a name="5">5.</a> INCIDENT RESPONSE</h2>
+
+<h3> <a name="5.1">5.1.</a> Incidents </h3>
+
+<p>
+Incidents and sources of important events and logging should be documented.
+</p>
+
+<h3> <a name="5.2">5.2.</a> Detection </h3>
+<p>
+The standard of monitoring, alerting and reporting must be documented.
+</p>
+
+<h3> <a name="5.3">5.3.</a> Immediate Action </h3>
+<h4> <a name="5.2.1">5.2.1.</a> Severity and Priority </h4>
+<p>
+On discovery of an incident,
+an initial assessment of severity and priority must be made.
+</p>
+
+<h4> <a name="5.2.2">5.2.2.</a> Communications </h4>
+<p>
+An initial report should be sent to systems administrators
+and wider interested parties.
+</p>
+
+<p>
+A communications forum should be established for direct
+support of high priority or high severity incidents.
+</p>
+
+<h4> <a name="5.2.3">5.2.3.</a> Oversight </h4>
+<p>
+A process of escalation of oversight should be eastablished.
+</p>
+
+<h3> <a name="5.4">5.4.</a> Investigation </h3>
+<p>
+Incidents must be investigated.
+The investigation must be documented.
+Evidence must be secured if the severity is high.
+</p>
+
+<h3> <a name="5.5">5.5.</a> Response </h3>
+<p>Document.</p>
+<h3> <a name="5.6">5.6.</a> Report </h3>
+<p>
+A report should be appended to the documentation of the investigation,
+and distributed in the act of closing the investigation.
+</p>
+
+<p>
+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.
+</p>
+
 <h2><a name="6">6.</a> DISASTER RECOVERY</h2>
 <h2><a name="7">7.</a> SOFTWARE DEVELOPMENT</h2>
 <h2><a name="8">8.</a> SUPPORT</h2>
@@ -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. 
 </p>
 
+<h3><a name="9.6">9.6.</a> Outsourcing </h3>
+
+<p>
+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.
+<p>
+
+<p>
+Any outsourcing arrangements must be documented.
+All arrangements must be:
+</p>
+
+<ul><li>
+    subject to audit,
+  </li><li>
+    under this Policy and the Security Manual,
+  </li><li>
+    under Arbitration and DRP,
+  </li><li>
+    with organisations that are Members of CAcert
+    as organisational Members,
+  </li><li>
+    under the spirit of the Principles of CAcert
+</li></ul>
+
+<p>
+Specifically, all involved personnel must be CAcert Assurers.
+Contracts should be written with the above in mind.
+</p>
+