Incoporated SM components into section 9, also headings for 5,6,7,8,10.

git-svn-id: http://svn.cacert.org/CAcert/Policies@1188 14b1bab8-4ef6-0310-b690-991c95c89dfd
pull/1/head
Ian Grigg 16 years ago
parent 1f30d7fd39
commit f6cf1a4a41

@ -691,6 +691,268 @@ Access to incident reports is restricted.
<h2><a name="5">5.</a> INCIDENT RESPONSE</h2>
<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>
<h2><a name=Documents"9">9.</a> ADMINISTRATIVE</h2></h3>
<h3> <a name="9.1"> 9.1. </a> Staffing</h3>
<h3> <a name="9.1.1"> 9.1.1. </a> Roles and responsibilities</h3>
<ul>
<li> System administrator: responsible for maintaining core services and integrity. </li>
<li> Software Developer: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
<li> Support: human interface with users.</li>
<li> Team leaders: coordinate with teams, report to board.</li>
<li> All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.</li>
<li> Board: authorise new individuals and accesses. Coordinate overall. </li>
</ul>
<h3> <a name="9.1.2"> 9.1.2. </a> Staffing levels</h3>
<p>
Each team should have a minimum of 2 members available at any time.
Individuals should be active in only one team at any one time,
but may be observers on any number of teams.
</p>
<p>
One individual in each team is designated leader and reports to Board.
</p>
<h3> <a name="9.1.3"> 9.1.3. </a> Process of new Team Members</h3>
<p>
New team members need:
</p>
<ul>
<li> Recommendation by team leader </li>
<li> Independent background check </li>
<li> Authorisation by Board </li>
</ul>
<p>
The team supports the process of adding new team members.
</p>
<h3> <a name="9.1.4"> 9.1.4. </a> Background Check Procedures</h3>
<p>
Background checks are carried out with full seriousness.
Background checks must be conducted under the direction of the Arbitrator,
with a separate Case Manager to provide four eyes.
</p>
<h4> <a name="9.1.4.1"> 9.1.4.1. </a> Scope </h4>
<p>
An investigation should include examination of:
</p>
<ul>
<li> realm-specific knowledge </li>
<li> realm-specific understanding of good security practice </li>
<li> history of activity within Community </li>
<li> reputation and standing within Community </li>
<li> provided references </li>
<li> conflicts of interest </li>
</ul>
<h4> <a name="9.1.4.2"> 9.1.4.2. </a> Coverage </h4>
<p>
A background check is to be done for all critical roles.
The background check should be done on all of:
</p>
<ul>
<li> systems administrator </li>
<li> access engineeers </li>
<li> software developer </li>
<li> support </li>
<li> Board </li>
</ul>
<h4> <a name="9.1.4.3"> 9.1.4.3. </a> Documentation </h4>
<p>
The process of the background check should be documented as a procedure.
</p>
<p>
Documentation of each individual check should be preserved
and should be reviewable under any future Arbitration.
It must include:
</p>
<ul>
<li> agreement with appropriate policies, etc </li>
<li> contact information </li>
</ul>
<h4> <a name="9.1.4.4"> 9.1.4.4. </a> Privacy for Hard Roles</h4>
<p>
The following privacy considerations exist:
</p>
<ul>
<li> procedure and ruling (recommendation) should be public </li>
<li> interview, documents should not be public, </li>
<li> summary of evidence should be in the ruling. </li>
<li> Arbitrator can rule on the escrow questions of evidence </li>
<li> contact information goes into the contact addressbook </li>
</ul>
<p>
CAcert trusted roles give up some privacy for the privacy of others.
</p>
<h3> <a name="9.1.5"> 9.1.5. </a> Authorisation </h3>
<p>
Individuals and access (both) must be authorised by the Board.
Only the Board may approve new individuals or any access to the systems.
Each Individual should be proposed to the Board,
with the relevant supporting information as above.
</p>
<p>
The Board should deliberate directly and in full.
Board members who are also active in the area should recuse from the vote,
but should support the deliberations.
Deliberations and decisions should be documented.
All conflicts of interest should be examined.
</p>
<h3> <a name="9.1.6"> 9.1.6. </a> Security</h3>
<p>
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 satisfactorily,
or to ensure that it is reported fully.
</p>
<p>
Only information subject to a specific and documented exception
may be kept secret or confidential.
The exception itself must not be secret or confidential.
All secrets and confidentials are reviewable under Arbitration,
and may be reversed.
</p>
<h3> <a name="9.1.7"> 9.1.7. </a> Termination of staff</h3>
<p>
Termination of access may be for resignation, Arbitration ruling,
or decision of Board or team leader.
On termination (for any reason), access and information must be secured.
</p>
<h3> <a name="9.1.8"> 9.1.8. </a> HR and Training</h3>
<p>
It is the responsibility of the team leaders
to coordinate technical testing and training,
especially of new team members.
</p>
<h3> <a name="9.2"> 9.2. </a> Key changeover</h3>
<p class="q">what goes in here? Non-root keys?</p>
<h3> <a name="9.3"> 9.3. </a> Key generation/transfer</h3>
<h3> <a name="9.3.1"> 9.3.1. </a> Root Key generation</h3>
<p>
Root keys should be generated on a machine built securely
for that purpose only and cleaned/wiped/destroyed immediately afterwards.
</p>
<h3> <a name="9.3.2"> 9.3.2. </a> Backup and escrow</h3>
<p>
Root keys must be kept on reliable removable media used for that purpose only.
Private Keys must be encrypted and should be dual-encrypted.
Passphrase must be strong and must be separately escrowed from media.
Dual control must be maintained.
</p>
<p>
The top-level root must be escrowed under Board control.
Subroots may be escrowed by either Board or Systems Administration Team.
</p>
<h3> <a name="9.3.3"> 9.3.3. </a> Recovery</h3>
<p>
Recovery must only be conducted under Board or Arbitrator direction.
A recovery exercise should be conducted approximately every year.
</p>
<h3> <a name="9.4"> 9.4. </a> Root certificate changes</h3>
<h3> <a name="9.4.1"> 9.4.1. </a> Creation</h3>
<p>Document.</p>
<h3> <a name="9.4.2"> 9.4.2. </a> Revocation</h3>
<p>Document.</p>
<h3> <a name="9.4.3"> 9.4.3. </a> Public notification</h3>
<p>
Board has responsibility for formal advisory to the public.
</p>
<h3> <a name="9.5"> 9.5. </a> Legal</h3>
<h3> <a name="9.5.1"> 9.5.1. </a> Responsibility</h3>
<p>
The board is responsible for the CA at the executive level.
</p>
<h3> <a name="9.5.2"> 9.5.2. </a> Response to external (legal) inquiry</h3>
<p>
All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.
</p>
<p>
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>
<h2><a name="10">10.</a> REFERENCES</h2>
<h3> <a name="10.1">10.1</a> Contacts </h3>
<p>
Contact information for all key people and teams must be documented.
</p>
<h3> <a name="10.2">10.2</a> Documents </h3>
<p>
All incorporated Documents must be documented.
</p>
<h3> <a name="10.3">10.3</a> Related Documents </h3>
<p>
Relevant and helpdul Documents should be referenced for convenience.
</p>
<hr>
<a href="http://validator.w3.org/check?uri=referer"><img src="Images/valid-html401-blue.png" id="graphics2" alt="Valid HTML 4.01" align="right" border="0" height="33" width="90"></a>
<p>This is the end of the Security Policy.</p>

Loading…
Cancel
Save