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

3rd batch: dropped blue, green, sections 9.2, 9.4. PD take to board.

Browse Source 
git-svn-id: http://svn.cacert.org/CAcert/Policies@1209 14b1bab8-4ef6-0310-b690-991c95c89dfd
pull/1/head
Ian Grigg 16 years ago
parent 147a3a9e8c
commit 05c8252556
1 changed files with 27 additions and 160 deletions
Show Stats Download Patch File Download Diff File

187
SecurityPolicy.html
Unescape Escape View File

@ -4,43 +4,11 @@
<head>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title>Security Policy</title>
<style type="text/css">
<!--
P { color: #000000 }
TD P { color: #000000 }
H1 { color: #000000 }
H2 { color: #000000 }
DT { color: #000000 }
DD { color: #000000 }
H3 { color: #000000 }
TH P { color: #000000 }
.q {
color : green;
font-weight: bold;
text-align: center;
font-style:italic;
}
.error {
color : red;
font-weight: bold;
text-align: center;
font-style:italic;
}
.change {
color : blue;
font-weight: bold;
}
-->
</style>
</head>
<body lang="en-GB">
<body style="direction: ltr; color: rgb(0, 0, 0);" lang="en-GB">
<h1>Security Policy for CAcert Systems</h1>
<p><a href="PolicyOnPolicy.html"><img src="Images/cacert-wip.png" id="graphics1" alt="CAcert Security Policy Status == wip" align="bottom" border="0" height="33" width="90"></a>
<p><a href="PolicyOnPolicy.html"><img src="Images/cacert-wip.png" alt="CAcert Security Policy Status == wip" border="0"></a>
<br>
Creation date: 2009-02-16<br>
Status: <i>work-in-progress</i>
@ -166,15 +134,9 @@ for audit purposes (DRC).
It is under the control of Policy on Policy for version purposes.
</p>
<p align="center">These parts are not part of the policy: <span class="q">green comments</span>, <span class="error">red errors</span>.</p>
<p>
This policy document says what is done, rather than how to do it.
<span class="change">
<b>Some sections are empty, which means
"refer to the Manual."</b>
</span>
<b>Some sections are empty, which means "refer to the Manual."</b>
</p>
<h4><a name="1.4.2">1.4.2.</a> The Security Manual (Practices) Document </h4>
@ -194,10 +156,8 @@ It is located and version-controlled on the CAcert wiki.
Section Headings are the same in both documents.
Where Sections are empty in one document,
they are expected to be documented in the other.
<span class="change">
"Document further in Security Manual" can be implied from
any section heading in the Policy.
</span>
</p>
<h4><a name="1.4.3">1.4.3.</a> The Security Procedures </h4>
@ -225,16 +185,6 @@ access security.
<h3><a name="2.2">2.2.</a> Physical Assets </h3>
<ul class="q"><li>
Big change is to place Oophaga INSIDE the SM/SP.
</li><li>
2nd Change is to place Oophaga in SP and in SM:
<ul>
<li> role of Access Engineer is in SP.</li>
<li> detail in the SM.</li>
</ul>
</li></ul>
<h4><a name="2.2.1">2.2.1.</a> Computers </h4>
<p>
Computers shall be inventoried before being put into service.
@ -244,9 +194,7 @@ List must be subject to change control.
</p>
<p>
<span class="change">
Each unit shall be distinctly and uniquely identified on all visible sides.
</span>
Machines shall be housed in secured facilities (cages and/or locked racks).
</p>
@ -343,11 +291,9 @@ one systems administrator present.
</p>
<p>
<span class="change">
There is no inherent authorisation to access the data.
Systems Administrators are authorised to access
the raw data under the control of this policy.
</span>
All others must not access the raw data.
All are responsible for protecting the data
from access by those not authorised.
@ -363,13 +309,11 @@ All physical accesses are logged and reported to all.
<p>
There must not be a procedure for emergency access.
<span class="change">
If, in the judgement of the systems administrator,
emergency access is required and gained,
in order to avoid a greater harm,
independent authorisation before the
Arbitrator must be sought as soon as possible.
</span>
See DRP.
</p>
@ -393,9 +337,7 @@ systems administration team leader.
These diagrams should include cabling information,
physical port configuration details,
expected/allowed data flow directions,
<span class="change">
and any further pertinent information,
</span>
as applicable.
Diagrams should be revision controlled,
and must be updated when any change is made.
@ -409,12 +351,10 @@ should be visible externally;
systems and servers which do not require access
to the Internet for their normal operation
must not be granted that access.
<span class="change">
If such access becomes temporarily necessary for an
authorized administrative task,
such access may be granted under the procedures of the SM
and must be reported and logged.
</span>
</p>
<h5> 3.1.1.2. Internal connectivity </h5>
@ -470,8 +410,6 @@ Documentation for installing and configuring servers with the appropriate softwa
<h4><a name="3.2.3"> 3.2.3.</a> Patching </h4>
<p class="q">A.1.i, A.1.k:</p>
<p>
Software used on production servers must be kept current with respect to patches affecting software security. Patch application is governed by CCS and 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>
@ -487,11 +425,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,
instruct remedial action,
<span class="change">
and
</span>
refer the case to dispute resolution.
instruct remedial action, and refer the case to dispute resolution.
</p>
<p>
@ -500,10 +434,8 @@ Declaration of an emergency patching situation should not occur with any regular
</b>
Emergency patch events must be documented
within the regular summaries
<span class="change">
by the team leader to Board
independent of filed disputes.
</span>
</p>
<h3><a name="3.3"> 3.3.</a> Application </h3>
@ -519,39 +451,32 @@ approve the installation of each release or patch.
<p>
Any changes made to source code must be referred
back to software assessment team
<span class="change">
and installation needs to be deferred
until approved by the Software Assessment Team.
</span>
</p>
<h3><a name="3.4"> 3.4.</a> Access control </h3>
<p>
<span class="change">
All access to critical data and services shall be
controlled and logged.
</span>
</p>
<h4><a name="3.4.1"> 3.4.1.</a> Application Access </h4>
<span class="change">
<p>
General access for Members shall be provided via
a dedicated application.
General features are made available according to
Assurance Points and similar methods controlled in
the software system.
</span>
<p class="q"> what about web-api interfaces? Excluded? </p>
</p>
<h4><a name="3.4.2"> 3.4.2.</a> Special Authorisation </h4>
<p>
<span class="change">
Additional or special access is granted according to the
authorisations on the below access control lists
</span>
(see &sect;1.1.1):
</p>
@ -601,11 +526,9 @@ All changes to the above lists are approved by the board of CAcert.
<h4><a name="3.4.3"> 3.4.3.</a> Authentication </h4>
<p>
<span class="change">
Strong methods of authentication shall be used
wherever possible.
All authentication schemes must be documented.
</span>
</p>
<h4><a name="3.4.4"> 3.4.4.</a> Removing access </h4>
@ -643,13 +566,9 @@ to CAcert sysadmins in all cases.
<h5> <a name="4.1.1.1">4.1.1.1.</a> Authorized users </h5>
<p>
Only system administrators designated on the
Access Lists
in &sect;3.4.2
are authorized to access accounts,
<span class="change">
Only system administrators designated on the Access Lists
in &sect;3.4.2 are authorized to access accounts,
unless specifically directed by the Arbitrator.
</span>
</p>
<h5> <a name="4.1.1.2">4.1.1.2.</a> Access to Systems</h5>
@ -660,7 +579,7 @@ All access is secured, logged and monitored.
<h5> <a name="4.1.1.3">4.1.1.3.</a> Changing </h5>
<p>
The procedure for changing passphrases and SSH keys <span class="change">shall</span> be documented.
The procedure for changing passphrases and SSH keys shall be documented.
</p>
<h4> <a name="4.1.2">4.1.2.</a> Required staff response time </h4>
@ -671,9 +590,7 @@ Response times should be documented for Disaster Recovery planning. See &sect;6
<h4> <a name="4.1.3">4.1.3.</a> Change management procedures </h4>
<p>
All changes made to system configuration must be recorded
<span class="change">
and reported in regular summaries to the board of CAcert.
</span>
</p>
<h4> <a name="4.1.4">4.1.4.</a> Outsourcing </h4>
@ -739,12 +656,10 @@ Disaster recovery backups may be distributed.
</p>
<h4> <a name="4.3.4">4.3.4.</a> Retention period and Re-use </h4>
<p>
<span class="change">
See &sect;2.2.3.
</span>
</p>
<h4> <a name="4.3.5">4.3.5.</a> Encryption </h4>
<p>
Backups must be encrypted and must only be transmitted via secured channels.
@ -785,9 +700,7 @@ See CCA.
<h4> <a name="4.4.2">4.4.2.</a> System logs </h4>
<p>
<span class="change">
See &sect;4.2.1.
</span>
</p>
<h4> <a name="4.4.3">4.4.3.</a> Incident reports </h4>
@ -816,14 +729,7 @@ an initial assessment of severity and priority must be made.
<h4> <a name="5.2.2">5.2.2.</a> Communications </h4>
<p>
An initial report should be
<span class="change">
circulated.
<s>
sent to systems administrators
and wider interested parties.
</s>
</span>
An initial report should be circulated.
</p>
<p>
@ -831,15 +737,13 @@ 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> <span class="change"> Escalation </span> </h4>
<h4> <a name="5.2.3">5.2.3.</a> Escalation </h4>
<p>
A process of escalation should be established
<span class="change">
for oversight and management purposes,
proportional to severity and priority.
Oversight starts with four eyes and ends with the Arbitrator.
Management starts with the team leader and ends with the Board.
</span>
</p>
<h3> <a name="5.4">5.4.</a> Investigation </h3>
@ -855,7 +759,7 @@ evidence must be secured and escalated to Arbitration.
<h3> <a name="5.6">5.6.</a> Report </h3>
<p>
Incident reports <span class="change">shall</span> be be published.
Incident reports shall be be published.
The Incident Report is written on closing the investigation.
A full copy should be appended to the
documentation of the investigation.
@ -871,9 +775,7 @@ and progress information should be published as soon as
possible.
The knowledge of the existence of the event must not be kept
secret, nor the manner and methods be kept confidential.
<span class="change">
See &sect;9.7.
</span>
</p>
<h2><a name="6">6.</a> DISASTER RECOVERY</h2>
@ -906,20 +808,14 @@ Board must have a basic plan to recover.
Board must maintain a key persons List with all the
contact information needed.
See &sect;10.1.
<span class="change">
The list shall be accessible even if CAcert's
infrastructure is not available.
</span>
</p>
<h2><a name="7">7.</a> SOFTWARE ASSESSMENT</h2>
<p class="q">
Change name of this to Software Assessment.
</p>
<p>
Software assessment team is responsible
for the security of the code.
@ -1031,9 +927,7 @@ The software interface gives features to Support Engineer.
Access to the special features is under tight control.
Additions to the team are approved by Board,
and the software features are under CCS.
<span class="change">
See &sect;3.4.2.
</span>
</p>
<p>
@ -1055,10 +949,9 @@ policies and practices.
<h3> <a name="8.2"> 8.2. </a> Responsibilities </h3>
<span class="change">
<p>
Support Engineers have these responsibilities:
<p>
</p>
<ul><li>
Account Recovery, as documented in the Security Manual.
@ -1069,17 +962,14 @@ Support Engineers have these responsibilities:
</li><li>
Tasks and responsibilities as specified in other policies, such as DRP.
</li></ul>
</span>
<h3> <a name="8.3"> 8.3. </a> Channels </h3>
<p>
<span class="change">
Support may always be contacted by email at
support at cacert dot org.
Other channels may be made available and documented
in Security Manual.
</span>
</p>
<h3> <a name="8.4"> 8.4. </a> Records and Logs </h3>
@ -1091,7 +981,7 @@ in Security Manual.
</ul>
<h3> <a name="8.5"> 8.5. </a> Arbitration </h3>
<span class="change">
<p>
Support Engineers refer questions requiring authority
to Arbitration, and may also be called upon to act as
default Case Managers.
@ -1100,7 +990,8 @@ See DRP and
Support Engineers should be familiar with
these topics, even if not listed as Arbitrators
or Case Managers.
</span>
</p>
<h3> <a name="8.6"> 8.6. </a> References </h3>
@ -1282,20 +1173,16 @@ to coordinate technical testing and training,
especially of new team members.
</p>
<span class="change">
<h3> <a name="9.2"> 9.2. </a> <s> Key changeover </s></h3>
</span>
<h3> <a name="9.2"> 9.2. </a> Key generation/transfer</h3>
<h3> <a name="9.3"> 9.3. </a> Key generation/transfer</h3>
<h4> <a name="9.3.1"> 9.3.1. </a> Root Key generation</h4>
<h4> <a name="9.2.1"> 9.2.1. </a> Root Key generation</h4>
<p>
Root keys should be generated on a machine built securely
for that purpose only and cleaned/wiped/destroyed immediately afterwards.
</p>
<h4> <a name="9.3.2"> 9.3.2. </a> Backup and escrow</h4>
<h4> <a name="9.2.2"> 9.2.2. </a> Backup and escrow</h4>
<p>
Root keys must be kept on reliable removable media used for that purpose only.
@ -1309,32 +1196,12 @@ The top-level root must be escrowed under Board control.
Subroots may be escrowed by either Board or Systems Administration Team.
</p>
<h4> <a name="9.3.3"> 9.3.3. </a> Recovery</h4>
<h4> <a name="9.2.3"> 9.2.3. </a> Recovery</h4>
<p>
Recovery must only be conducted
<span class="change">
under Arbitrator authority.
<s>
A recovery exercise should be conducted approximately every year.
</s>
</span>
Recovery must only be conducted under Arbitrator authority.
</p>
<h3> <a name="9.4"> 9.4. </a> <span class="change"> <s> Root certificate changes </s> </span> </h3>
<h4> <a name="9.4.1"> 9.4.1. </a> Creation</h4>
<p>Document.</p>
<h4> <a name="9.4.2"> 9.4.2. </a> Revocation</h4>
<p>Document.</p>
<h4> <a name="9.4.3"> 9.4.3. </a> Public notification</h4>
<p>
Board has responsibility for formal advisory to the public.
</p>
<h3> <a name="9.5"> 9.5. </a> Legal</h3>
@ -1362,7 +1229,7 @@ and becomes your authority to act.
<h3><a name="9.6">9.6.</a> Outsourcing </h3>
<p class="change">
<p>
Components may be outsourced.
Team leaders may outsource non-critical components
on notifying the board.
@ -1374,7 +1241,7 @@ Any outsourcing arrangements must be documented.
All arrangements must be:
</p>
<ul class="change"><li>
<ul><li>
with Members of CAcert that are
<ul><li>
Assurers, as individuals, or
@ -1405,7 +1272,7 @@ Contracts should be written with the above in mind.
<h3> <a name="9.7">9.7</a> Confidentiality, Secrecy </h3>
<p class="change">
<p>
CAcert is an open organisation and adopts a principle
of open disclosure wherever possible.
See <a href="https://svn.cacert.org/CAcert/principles.html">
@ -1415,7 +1282,7 @@ if a subject can only sustain under some
confidentiality or secrecy, then find another way.
</p>
<p class="change">
<p>
In concrete terms,
only under a defined exception under policy,
or under the oversight of the Arbitrator,

Write Preview
Loading…
Cancel
Save