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
This commit is contained in:
parent
1f30d7fd39
commit
f6cf1a4a41
1 changed files with 262 additions and 0 deletions
|
@ -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…
Reference in a new issue