cacert
/
cacert-policies
8
1
Fork 0
Code Issues 3 Pull Requests 1 Packages Projects Releases Wiki Activity

from p2010051, this version going to DRAFT, preparing for the transfer to website

Browse Source 
git-svn-id: http://svn.cacert.org/CAcert/Policies@1918 14b1bab8-4ef6-0310-b690-991c95c89dfd
pull/1/head
Ian Grigg 14 years ago
parent efe3e93034
commit 834133192a
1 changed files with 37 additions and 244 deletions
Show Stats Download Patch File Download Diff File

281
SecurityPolicy.html
Unescape Escape View File

@ -4,7 +4,7 @@
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" />
<title>Security Policy - work-in-progress</title>
<title>Security Policy - DRAFT</title>
<style type="text/css"> <!-- only for WIP -->
<!--
@ -12,10 +12,6 @@ body {
font-family : verdana, helvetica, arial, sans-serif;
}
th {
text-align : left;
}
.q {
color : green;
font-weight: bold;
@ -23,63 +19,15 @@ th {
font-style:italic;
}
.error {
color : red;
font-weight: bold;
text-align: center;
font-style:italic;
}
.change {
color : blue;
font-weight: bold;
}
.strike {
color : blue;
font-weight: bold;
text-decoration:line-through;
}
.change2 {
color : #151B8D;
font-weight: bold;
}
.strike2 {
color : #151B8D;
font-weight: bold;
text-decoration:line-through;
}
a:hover {
color : gray;
}
-->
</style>
</head>
<body lang="en-GB">
<ul class="change">
<li class="change2"> 20100530: Package of changes to drop the Application Engineer and place those responsibilities back with the Sysadm team. Exception added to permit t/l to bring in a Software Assessor under controlled basis. Because this change is non-trivial, and a compromise in late voting stage, it is marked in a different blue.</li>
<li> 20100525: Two detail changes from Tom Trnka.</li>
<li> 20100513: With some consensus from policy group, changed the text in 2.2.1.1 to transfer the detailed handling of pre-purchase risks to SM.</li>
<li> 20100512: Some clarifying tweaks to semantics supplied by Philipp G, added Arb as a role in 9.1.1. but not as critical role. </li>
<li> 20100511: Introduced "Board" term, tightened "approval" semantics, s/wiped/erased/, slight semantic tweaks. </li>
<li> 20100502: Made 7.3 blank, "refer to SM" </li>
<li> 20100424: tidied up 9.4 </li>
<li> 20100422: added 9.3.2 notification requirement. </li>
<li> 20100421: reviewed and dropped the BLUE changes that introduced AE, etc. </li>
<li> 20100411: rewrote the critical roles to align with ABC requirement, dropped Board. </li>
<li> <big>20100404: status changes to WIP</big><br />
<span class="q"> Security Policy is no longer binding, as of 20100404</span> </li>
<li> 20901213: addition of WIP changes </li>
<li> 20090327: status change to DRAFT <a href="http://wiki.cacert.org/PolicyDecisions#p20090327">p20090327</a>. </li>
</ul>
<p>
WIP Changes are all marked in <span class="change">BLUE</span> or <span class="strike">struck-out</span>.
Explanatory comments in <span class="q">GREEN</span> are not part of text.<br />
<p class="q">
This version: going to DRAFT <a href="http://wiki.cacert.org/PolicyDecisions#p20100510">p20100510</a>
</p>
<p class="q"> Start of Policy</p>
<hr />
<h1>Security Policy for CAcert Systems</h1>
@ -87,9 +35,9 @@ Explanatory comments in <span class="q">GREEN</span> are not part of text.<br />
<table width="100%"><tr><td>
Creation date: 20090216<br />
Editor: iang<br />
Status: <b>WIP <a href="https://community.cacert.org/board/motions.php?motion=m20100327.2">m20100327.2</a></b> as of 20100404 00:00:02 UTC<br /><br />
Status: <b>DRAFT <a href="http://wiki.cacert.org/PolicyDecisions#p20100510">p20100510</a></b> <br /><br />
</td><td align="right">
<a href="http://www.cacert.org/policy/PolicyOnPolicy.php"><img src="Images/cacert-wip.png" alt="Security Policy Status == WIP" style="border-width:0" /></a>
<a href="http://www.cacert.org/policy/PolicyOnPolicy.php"><img src="Images/cacert-draft.png" alt="Security Policy Status == DRAFT" style="border-width:0" /></a>
</td></tr></table>
<h2 id="s1">1. INTRODUCTION</h2>
@ -110,8 +58,7 @@ These systems include:
Source code (changes and patches)
</li></ol>
<p>
<span class="strike">Board</span>
<span class="change">The Committee of CAcert, Inc. (hereafter, "Board")</span>
The Committee of CAcert, Inc. (hereafter, "Board")
may add additional components into the Security Manual.
</p>
@ -130,7 +77,6 @@ These roles are defined as:
Support Engineer
</li><li>
Software Assessor
<span class="strike2">(including Application Engineers)</span>
</li></ul>
<h4 id="s1.1.2">1.1.2. Out of Scope </h4>
@ -184,14 +130,6 @@ deriving from the above principles.
See &sect;1.1.
</dd>
<dt><i><span class="strike2">Application Engineer</i> </span></dt>
<dd>
<span class="strike2">A Member who manages the critical application,
including installing them on the critical system,
final testing, emergency patching, and ad hoc scripting.
See &sect;7.2.</span>
</dd>
<dt><i>Software Assessor</i> </dt>
<dd>
A Member who reviews patches for security and workability,
@ -239,12 +177,7 @@ The SM says how things are done.
As practices are things that vary from time to time,
including between each event of practice,
the SM is under the direct control of the
<span class="strike">
Systems Administration team
</span>
<span class="change">
applicable team leaders.
</span>
It is located and version-controlled on the CAcert wiki.
</p>
@ -295,19 +228,11 @@ Machines shall be housed in secured facilities (cages and/or locked racks).
</p>
<h4 id="s2.2.1.1">2.2.1.1 Acquisition </h4>
<p class="change">
<p>
Equipment for critical purposes should be acquired
in a way to minimise pre-acquisition security risks.
</p>
<p class="strike">
Acquisition of new equipment that is subject to a
pre-purchase security risk must be done from a
vendor that is regularly and commercially in business.
Precautions must be taken to prevent equipment being
prepared in advance.
</p>
<h4 id="s2.2.2">2.2.2. Service </h4>
<p>
@ -327,10 +252,7 @@ are inventoried upon acquisition and tracked in their use.
<p>
New storage media (whether disk or removable) shall be
securely
<span class="strike">wiped</span>
<span class="change">erased</span>
and reformatted before use.
securely erased and reformatted before use.
</p>
<h4 id="s2.2.3.2">2.2.3.2 Storage </h4>
@ -339,9 +261,7 @@ and reformatted before use.
Removable media shall be securely stored at all times,
including when not in use.
Drives that are kept for reuse are
<span class="strike">wiped</span>
<span class="change">erased</span>
securely before storage.
erased securely before storage.
Reuse can only be within critical systems.
</p>
@ -400,9 +320,6 @@ one Systems Administrator present.
<p>
There is no inherent authorisation to access the data.
Systems Administrators
<span class="strike2">
and Application Engineers
</span>
are authorised to access
the raw data under the control of this policy.
All others must not access the raw data.
@ -523,7 +440,6 @@ Documentation for installing and configuring servers with the appropriate softwa
<p>
Software used on production servers must be kept current with respect to patches affecting software security. Patch application
<span class="strike">is governed by CCS and</span> <!-- this is true, but CCS refers it to here, and the wording doesn't make sense without understanding CCS -->
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 &sect;4.2).
</p>
@ -538,10 +454,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
<span class="change">
or
</span>
instruct remedial action, and refer the case to dispute resolution.
or instruct remedial action, and refer the case to dispute resolution.
</p>
<p>
@ -556,13 +469,7 @@ independent of filed disputes.
<h3 id="s3.3"> 3.3. Application </h3>
<p class="strike2">
Systems administration is to provide a limited environment
to Applications Engineers in order to install and maintain
the application.
</p>
<p class="change2">
<p>
Requests for ad hoc queries over the application database for business
or similar purposes must be approved by the Arbitrator.
</p>
@ -603,38 +510,36 @@ authorisations on the below access control lists
<td>Access Engineers</td>
<td>control of access by personnel to hardware</td>
<td>exclusive of all other roles </td>
<td><span class="change">Access team leader</span> <span class="strike">Board of CAcert (or designee)</span></td>
<td>Access team leader</td>
</tr><tr>
<td>Physical Access List</td>
<td>Systems Administrators</td>
<td>hardware-level for installation and recovery</td>
<td>exclusive with Access Engineers and Software Assessors</td>
<td><span class="change">Systems Administration team leader</span> <span class="strike">Board of CAcert (or designee)</span></td>
<td>Systems Administration team leader </td>
</tr><tr>
<td>SSH Access List</td>
<td>Systems Administrators <span class="strike2">and Application Engineers </span></td>
<td>Systems Administrators </td>
<td>Unix / account / shell level</td>
<td> includes by default all on Physical Access List </td>
<td>Systems Administration team leader</td>
</tr><tr>
<td>Repository Access List</td>
<td><span class="change2">Software Assessors</span> <span class="strike2">Application Engineers</span></td>
<td>change the source code repository <span class="strike2">and install patches to application</span></td>
<td>Software Assessors</td>
<td>change the source code repository </td>
<td>exclusive with Access Engineers and Systems Administrators</td>
<td>software assessment team leader</td>
<td>Software Assessment team leader</td>
</tr><tr>
<td>Support Access List</td>
<td>Support Engineer</td>
<td>support features in the web application</td>
<td> <span class="change">exclusive with Access Engineers and Systems Administrators</span> <span class="strike2">includes by default all Application Engineers Systems Administrators </span> </td>
<td><span class="strike">Systems Administration</span> <span class="change">Support</span> team leader</td>
<td> exclusive with Access Engineers and Systems Administrators </td>
<td>Support team leader</td>
</tr></table>
<p>
All changes of personnel to the above lists are
<span class="change">subject to Board approval.</span>
<span class="strike">approved by the Board of CAcert.</span>
subject to Board approval.
</p>
<h4 id="s3.4.3"> 3.4.3. Authentication </h4>
@ -670,29 +575,23 @@ and hardware maintenance.
<h4 id="s4.1.1">4.1.1. Privileged accounts and passphrases </h4>
<p>
Access to <span class="change">privileged</span> accounts
Access to privileged accounts
(root and user via SSH or console)
must be strictly controlled.
Passphrases and SSH private keys used for entering into the systems
will be kept private
to CAcert sysadmins
<span class="strike2">and Application Engineers</span>
in all cases.
</p>
<h5 id="s4.1.1.1">4.1.1.1. Authorized users </h5>
<p>
Only System Administrators
<span class="strike2">and Application Engineers</span>
Only Systems Administrators
designated on the Access Lists
in &sect;3.4.2 are authorized to access accounts.
<span class="change2">
System Administration team leader may temporarily permit Software
Systems Administration team leader may temporarily permit Software
Assessors access to the application via SSH in order to do advanced
debugging, or as
</span>
<span class="strike2">Other</span>
specifically directed by the Arbitrator.
debugging, or as specifically directed by the Arbitrator.
</p>
<p>
@ -953,8 +852,7 @@ for the security and maintenance of the code.
<p>
The source code is under CCS.
Additions to the team are
<span class="change">subject to Board approval.</span>
<span class="strike">approved by the Board.</span>
subject to Board approval.
See &sect;3.4.2.
</p>
@ -977,57 +875,8 @@ Software assessment is not primarily tasked to write the code.
In principle, anyone can submit code changes for approval.
</p>
<p class="q"> Moved to SM 3.3 </p>
<p class="strike2">
The primary tasks for Application Engineers are:
</p>
<ol class="strike2"><li>
Installing signed-off patches,
</li><li>
Verifying correct running,
</li><li>
Correcting immediate errors and copying fixes back to
upstream repositories,
</li><li>
Running ad-hoc database scripts and other programs,
</li><li>
Repairing data errors,
</li><li>
Backing up at the database level,
</li><li>
Watching application-level logs.
</li></ol>
<h3 id="s7.3"> 7.3. Repository </h3>
<p class="q"> As we are still unsure how to do Repository, I recommend we make this section blank. Therefore, it is handled in Security Manual. <i>Iang, 20100502</i>.</p>
<p class="strike">
The application code and patches are maintained
in a central repository that is run by the
software assessment team.
</p>
<ul class="q">
<li> Alternative, also struck: </li>
</ul>
<p class="strike">
The development code and testing patches are maintained
in a central development repository that is run by the
software assessment team.
</p>
<p class="strike">
The production code is maintained in a secure production repository
within the critical systems that is run by the
Systems Administation team.
Access is made available to the Application Engineers.
</p>
<h3 id="s7.4"> 7.4. Review </h3>
<p>
@ -1057,35 +906,7 @@ Bug submission access should be provided to
any Member that requests it.
</p>
<h3 id="s7.6"> 7.6. <span class="strike">Handover</span> <span class="change">Production</span> </h3>
<p class="q"> Blank, now refer to SM 7.6 </p>
<p class="strike2">
The Application Engineer is a role within Software Assessment
team that is approved to install into production the
patches that are signed off.
<span class="strike">
Once signed off, the Application Engineer
commits the patch from the development repository
to the production repository,
and installs the patch from the production repository
into the running code.
The Application Engineer is responsible for basic
testing of functionality and emergency fixes,
which then must be back-installed into the repositories.
</span>
</p>
<p class="q"> this below moved to &sect;3.3 </p>
<p class="strike2">
Requests to Application Engineers for ad hoc queries over the database for business or similar purposes must be approved by the Arbitrator.
</p>
<p class="strike2">
See &sect;3.3.
</p>
<h3 id="s7.6"> 7.6. Production </h3>
<h2 id="s8">8. SUPPORT</h2>
@ -1094,9 +915,7 @@ See &sect;3.3.
<p>
The software interface gives features to Support Engineer.
Access to the special features is under tight control.
Additions to the team are
<span class="change">subject to Board approval,</span>
<span class="strike">approved by the Board,</span>
Additions to the team are subject to Board approval,
and the software features are under CCS.
See &sect;3.4.2.
</p>
@ -1125,7 +944,7 @@ Support Engineers have these responsibilities:
</p>
<ul><li>
<span class="change">Member</span> account recovery, as documented in the Security Manual.
Member account recovery, as documented in the Security Manual.
</li><li>
Respond to general requests for information or explanation by Members.
Support Engineers cannot make a binding statement.
@ -1177,12 +996,11 @@ or Case Managers.
<li> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
<li> System Administrator: responsible for maintaining core services and integrity. </li>
<li> Software Assessor: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
<li class="strike2"> Application Engineer: install application updates and confirm basic working.</li>
<li> Support Engineer: 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>
<li class="change"> Arbitrator: conducts ABCs. Authorises exceptions to policy. </li>
<li> Arbitrator: conducts ABCs. Authorises exceptions to policy. </li>
</ul>
<h4 id="s9.1.2"> 9.1.2. Staffing levels</h4>
@ -1241,7 +1059,7 @@ An investigation within ABC should include examination of:
<h4 id="s9.1.4.2"> 9.1.4.2. Coverage </h4>
<p>
ABC is to be done on every individual in a critical role.
<span class="change">See &sect;1.1.1.</span>
See &sect;1.1.1.
</p>
<h4 id="s9.1.4.3"> 9.1.4.3. Documentation </h4>
@ -1291,9 +1109,7 @@ with the relevant supporting information as above.
<p>
The Board should deliberate directly and in full.
Board members who are also active in the area should
<span class="strike">recuse</span>
<span class="change">abstain</span>
from the vote,
abstain from the vote,
but should support the deliberations.
Deliberations and decisions should be documented.
All conflicts of interest should be examined.
@ -1306,13 +1122,7 @@ 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
<span class="strike">it</span>
<span class="change">issues</span>
satisfactorily,
or to ensure that
<span class="strike">it is</span>
<span class="change">they are</span>
reported fully.
issues satisfactorily, or to ensure that they are reported fully.
</p>
<p>
@ -1350,17 +1160,14 @@ especially of new team members.
<h4 id="s9.2.1"> 9.2.1. Root Key generation</h4>
<p>
Root keys are generated only on instruction from <span class="strike">the</span> Board.
Root keys are generated only on instruction from Board.
They must be generated to a fully documented and reviewed procedure.
The procedure must include:
</p>
<ul>
<li> Use of hardware built securely for the purpose
only and cleaned/
<span class="strike">wiped</span>
<span class="change">erased</span>
/destroyed immediately afterwards. </li>
only and cleaned/erased/destroyed immediately afterwards. </li>
<li> Dual control over all phases, including by Board. </li>
<li> Strong collection of primary entropy, separated from use of entropy. </li>
<li> Test cycles of the process on the day. </li>
@ -1395,7 +1202,7 @@ Recovery must only be conducted under Arbitrator authority.
<h4 id="s9.3.1"> 9.3.1. Responsibility</h4>
<p>
<span class="strike">the</span> Board is responsible to the Community to manage
Board is responsible to the Community to manage
the CA at the executive level.
</p>
@ -1403,7 +1210,7 @@ the CA at the executive level.
<p>
All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.
<span class="change">Board and applicable team leaders must be notified</span>.
Board and applicable team leaders must be notified.
</p>
<p>
@ -1421,11 +1228,6 @@ and becomes your authority to act.
<p>
Components may be outsourced.
<span class="strike">
Team leaders may outsource non-critical components
on notifying <span class="strike">the</span> Board.
Critical components must be approved by <span class="strike">the</span> Board.
</span>
Any outsourcing arrangements must be documented.
All arrangements must be:
</p>
@ -1455,9 +1257,7 @@ All arrangements must be:
<p>
Contracts should be written with the above in mind.
<span class="change">
Outsourcing of critical components must be approved by <span class="strike">the</span> Board.
</span>
Outsourcing of critical components must be approved by the Board.
</p>
<h3 id="s9.5">9.5 Confidentiality, Secrecy </h3>
@ -1502,12 +1302,5 @@ All incorporated Documents must be documented.
Relevant and helpful Documents should be referenced for convenience.
</p>
<hr />
<p class="q">
<a href="http://validator.w3.org/check?uri=referer"><img src="Images/valid-html401-blue.png" id="graphics2" alt="Valid HTML 4.01" style="float: right; border-width: 0" height="33" width="90" /></a>
This is the end of the Security Policy.
</p>
</body></html>

Write Preview
Loading…
Cancel
Save