cacert/cacert-policies
9
1
Fork 0
Code Issues Pull requests Projects Releases Packages 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
This commit is contained in:
Ian Grigg 2009-03-12 14:33:41 +00:00
parent 147a3a9e8c
commit 05c8252556
1 changed files with 27 additions and 160 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

187
SecurityPolicy.html
View file

@ -4,43 +4,11 @@
<head> <head>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title>Security Policy</title> <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> </head>
<body lang="en-GB">
<body style="direction: ltr; color: rgb(0, 0, 0);" lang="en-GB">
<h1>Security Policy for CAcert Systems</h1> <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> <br>
Creation date: 2009-02-16<br> Creation date: 2009-02-16<br>
Status: <i>work-in-progress</i> 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. It is under the control of Policy on Policy for version purposes.
</p> </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> <p>
This policy document says what is done, rather than how to do it. This policy document says what is done, rather than how to do it.
<b>Some sections are empty, which means "refer to the Manual."</b>
<span class="change">
<b>Some sections are empty, which means
"refer to the Manual."</b>
</span>
</p> </p>
<h4><a name="1.4.2">1.4.2.</a> The Security Manual (Practices) Document </h4> <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. Section Headings are the same in both documents.
Where Sections are empty in one document, Where Sections are empty in one document,
they are expected to be documented in the other. they are expected to be documented in the other.
<span class="change">
"Document further in Security Manual" can be implied from "Document further in Security Manual" can be implied from
any section heading in the Policy. any section heading in the Policy.
</span>
</p> </p>
<h4><a name="1.4.3">1.4.3.</a> The Security Procedures </h4> <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> <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> <h4><a name="2.2.1">2.2.1.</a> Computers </h4>
<p> <p>
Computers shall be inventoried before being put into service. Computers shall be inventoried before being put into service.
@ -244,9 +194,7 @@ List must be subject to change control.
</p> </p>
<p> <p>
<span class="change">
Each unit shall be distinctly and uniquely identified on all visible sides. 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). Machines shall be housed in secured facilities (cages and/or locked racks).
</p> </p>
@ -343,11 +291,9 @@ one systems administrator present.
</p> </p>
<p> <p>
<span class="change">
There is no inherent authorisation to access the data. There is no inherent authorisation to access the data.
Systems Administrators are authorised to access Systems Administrators are authorised to access
the raw data under the control of this policy. the raw data under the control of this policy.
</span>
All others must not access the raw data. All others must not access the raw data.
All are responsible for protecting the data All are responsible for protecting the data
from access by those not authorised. from access by those not authorised.
@ -363,13 +309,11 @@ All physical accesses are logged and reported to all.
<p> <p>
There must not be a procedure for emergency access. There must not be a procedure for emergency access.
<span class="change">
If, in the judgement of the systems administrator, If, in the judgement of the systems administrator,
emergency access is required and gained, emergency access is required and gained,
in order to avoid a greater harm, in order to avoid a greater harm,
independent authorisation before the independent authorisation before the
Arbitrator must be sought as soon as possible. Arbitrator must be sought as soon as possible.
</span>
See DRP. See DRP.
</p> </p>
@ -393,9 +337,7 @@ systems administration team leader.
These diagrams should include cabling information, These diagrams should include cabling information,
physical port configuration details, physical port configuration details,
expected/allowed data flow directions, expected/allowed data flow directions,
<span class="change">
and any further pertinent information, and any further pertinent information,
</span>
as applicable. as applicable.
Diagrams should be revision controlled, Diagrams should be revision controlled,
and must be updated when any change is made. 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 systems and servers which do not require access
to the Internet for their normal operation to the Internet for their normal operation
must not be granted that access. must not be granted that access.
<span class="change">
If such access becomes temporarily necessary for an If such access becomes temporarily necessary for an
authorized administrative task, authorized administrative task,
such access may be granted under the procedures of the SM such access may be granted under the procedures of the SM
and must be reported and logged. and must be reported and logged.
</span>
</p> </p>
<h5> 3.1.1.2. Internal connectivity </h5> <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> <h4><a name="3.2.3"> 3.2.3.</a> Patching </h4>
<p class="q">A.1.i, A.1.k:</p>
<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). 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> </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, Application of patches in this case may occur as soon as possible,
bypassing the normal configuration-change process. bypassing the normal configuration-change process.
The systems administration team leader must either approve the patch, The systems administration team leader must either approve the patch,
instruct remedial action, instruct remedial action, and refer the case to dispute resolution.
<span class="change">
and
</span>
refer the case to dispute resolution.
</p> </p>
<p> <p>
@ -500,10 +434,8 @@ Declaration of an emergency patching situation should not occur with any regular
</b> </b>
Emergency patch events must be documented Emergency patch events must be documented
within the regular summaries within the regular summaries
<span class="change">
by the team leader to Board by the team leader to Board
independent of filed disputes. independent of filed disputes.
</span>
</p> </p>
<h3><a name="3.3"> 3.3.</a> Application </h3> <h3><a name="3.3"> 3.3.</a> Application </h3>
@ -519,39 +451,32 @@ approve the installation of each release or patch.
<p> <p>
Any changes made to source code must be referred Any changes made to source code must be referred
back to software assessment team back to software assessment team
<span class="change">
and installation needs to be deferred and installation needs to be deferred
until approved by the Software Assessment Team. until approved by the Software Assessment Team.
</span>
</p> </p>
<h3><a name="3.4"> 3.4.</a> Access control </h3> <h3><a name="3.4"> 3.4.</a> Access control </h3>
<p> <p>
<span class="change">
All access to critical data and services shall be All access to critical data and services shall be
controlled and logged. controlled and logged.
</span> </p>
<h4><a name="3.4.1"> 3.4.1.</a> Application Access </h4> <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 General access for Members shall be provided via
a dedicated application. a dedicated application.
General features are made available according to General features are made available according to
Assurance Points and similar methods controlled in Assurance Points and similar methods controlled in
the software system. the software system.
</span> </p>
<p class="q"> what about web-api interfaces? Excluded? </p>
<h4><a name="3.4.2"> 3.4.2.</a> Special Authorisation </h4> <h4><a name="3.4.2"> 3.4.2.</a> Special Authorisation </h4>
<p> <p>
<span class="change">
Additional or special access is granted according to the Additional or special access is granted according to the
authorisations on the below access control lists authorisations on the below access control lists
</span>
(see &sect;1.1.1): (see &sect;1.1.1):
</p> </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> <h4><a name="3.4.3"> 3.4.3.</a> Authentication </h4>
<p> <p>
<span class="change">
Strong methods of authentication shall be used Strong methods of authentication shall be used
wherever possible. wherever possible.
All authentication schemes must be documented. All authentication schemes must be documented.
</span>
</p> </p>
<h4><a name="3.4.4"> 3.4.4.</a> Removing access </h4> <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> <h5> <a name="4.1.1.1">4.1.1.1.</a> Authorized users </h5>
<p> <p>
Only system administrators designated on the Only system administrators designated on the Access Lists
Access Lists in &sect;3.4.2 are authorized to access accounts,
in &sect;3.4.2
are authorized to access accounts,
<span class="change">
unless specifically directed by the Arbitrator. unless specifically directed by the Arbitrator.
</span>
</p> </p>
<h5> <a name="4.1.1.2">4.1.1.2.</a> Access to Systems</h5> <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> <h5> <a name="4.1.1.3">4.1.1.3.</a> Changing </h5>
<p> <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> </p>
<h4> <a name="4.1.2">4.1.2.</a> Required staff response time </h4> <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> <h4> <a name="4.1.3">4.1.3.</a> Change management procedures </h4>
<p> <p>
All changes made to system configuration must be recorded All changes made to system configuration must be recorded
<span class="change">
and reported in regular summaries to the board of CAcert. and reported in regular summaries to the board of CAcert.
</span>
</p> </p>
<h4> <a name="4.1.4">4.1.4.</a> Outsourcing </h4> <h4> <a name="4.1.4">4.1.4.</a> Outsourcing </h4>
@ -739,12 +656,10 @@ Disaster recovery backups may be distributed.
</p> </p>
<h4> <a name="4.3.4">4.3.4.</a> Retention period and Re-use </h4> <h4> <a name="4.3.4">4.3.4.</a> Retention period and Re-use </h4>
<p> <p>
<span class="change">
See &sect;2.2.3. See &sect;2.2.3.
</span>
</p> </p>
<h4> <a name="4.3.5">4.3.5.</a> Encryption </h4> <h4> <a name="4.3.5">4.3.5.</a> Encryption </h4>
<p> <p>
Backups must be encrypted and must only be transmitted via secured channels. 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> <h4> <a name="4.4.2">4.4.2.</a> System logs </h4>
<p> <p>
<span class="change">
See &sect;4.2.1. See &sect;4.2.1.
</span>
</p> </p>
<h4> <a name="4.4.3">4.4.3.</a> Incident reports </h4> <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> <h4> <a name="5.2.2">5.2.2.</a> Communications </h4>
<p> <p>
An initial report should be An initial report should be circulated.
<span class="change">
circulated.
<s>
sent to systems administrators
and wider interested parties.
</s>
</span>
</p> </p>
<p> <p>
@ -831,15 +737,13 @@ A communications forum should be established for direct
support of high priority or high severity incidents. support of high priority or high severity incidents.
</p> </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> <p>
A process of escalation should be established A process of escalation should be established
<span class="change">
for oversight and management purposes, for oversight and management purposes,
proportional to severity and priority. proportional to severity and priority.
Oversight starts with four eyes and ends with the Arbitrator. Oversight starts with four eyes and ends with the Arbitrator.
Management starts with the team leader and ends with the Board. Management starts with the team leader and ends with the Board.
</span>
</p> </p>
<h3> <a name="5.4">5.4.</a> Investigation </h3> <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> <h3> <a name="5.6">5.6.</a> Report </h3>
<p> <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. The Incident Report is written on closing the investigation.
A full copy should be appended to the A full copy should be appended to the
documentation of the investigation. documentation of the investigation.
@ -871,9 +775,7 @@ and progress information should be published as soon as
possible. possible.
The knowledge of the existence of the event must not be kept The knowledge of the existence of the event must not be kept
secret, nor the manner and methods be kept confidential. secret, nor the manner and methods be kept confidential.
<span class="change">
See &sect;9.7. See &sect;9.7.
</span>
</p> </p>
<h2><a name="6">6.</a> DISASTER RECOVERY</h2> <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 Board must maintain a key persons List with all the
contact information needed. contact information needed.
See &sect;10.1. See &sect;10.1.
<span class="change">
The list shall be accessible even if CAcert's The list shall be accessible even if CAcert's
infrastructure is not available. infrastructure is not available.
</span>
</p> </p>
<h2><a name="7">7.</a> SOFTWARE ASSESSMENT</h2> <h2><a name="7">7.</a> SOFTWARE ASSESSMENT</h2>
<p class="q">
Change name of this to Software Assessment.
</p>
<p> <p>
Software assessment team is responsible Software assessment team is responsible
for the security of the code. 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. Access to the special features is under tight control.
Additions to the team are approved by Board, Additions to the team are approved by Board,
and the software features are under CCS. and the software features are under CCS.
<span class="change">
See &sect;3.4.2. See &sect;3.4.2.
</span>
</p> </p>
<p> <p>
@ -1055,10 +949,9 @@ policies and practices.
<h3> <a name="8.2"> 8.2. </a> Responsibilities </h3> <h3> <a name="8.2"> 8.2. </a> Responsibilities </h3>
<span class="change">
<p> <p>
Support Engineers have these responsibilities: Support Engineers have these responsibilities:
<p> </p>
<ul><li> <ul><li>
Account Recovery, as documented in the Security Manual. Account Recovery, as documented in the Security Manual.
@ -1069,17 +962,14 @@ Support Engineers have these responsibilities:
</li><li> </li><li>
Tasks and responsibilities as specified in other policies, such as DRP. Tasks and responsibilities as specified in other policies, such as DRP.
</li></ul> </li></ul>
</span>
<h3> <a name="8.3"> 8.3. </a> Channels </h3> <h3> <a name="8.3"> 8.3. </a> Channels </h3>
<p> <p>
<span class="change">
Support may always be contacted by email at Support may always be contacted by email at
support at cacert dot org. support at cacert dot org.
Other channels may be made available and documented Other channels may be made available and documented
in Security Manual. in Security Manual.
</span>
</p> </p>
<h3> <a name="8.4"> 8.4. </a> Records and Logs </h3> <h3> <a name="8.4"> 8.4. </a> Records and Logs </h3>
@ -1091,7 +981,7 @@ in Security Manual.
</ul> </ul>
<h3> <a name="8.5"> 8.5. </a> Arbitration </h3> <h3> <a name="8.5"> 8.5. </a> Arbitration </h3>
<span class="change"> <p>
Support Engineers refer questions requiring authority Support Engineers refer questions requiring authority
to Arbitration, and may also be called upon to act as to Arbitration, and may also be called upon to act as
default Case Managers. default Case Managers.
@ -1100,7 +990,8 @@ See DRP and
Support Engineers should be familiar with Support Engineers should be familiar with
these topics, even if not listed as Arbitrators these topics, even if not listed as Arbitrators
or Case Managers. or Case Managers.
</span> </p>
<h3> <a name="8.6"> 8.6. </a> References </h3> <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. especially of new team members.
</p> </p>
<span class="change"> <h3> <a name="9.2"> 9.2. </a> Key generation/transfer</h3>
<h3> <a name="9.2"> 9.2. </a> <s> Key changeover </s></h3>
</span>
<h3> <a name="9.3"> 9.3. </a> Key generation/transfer</h3> <h4> <a name="9.2.1"> 9.2.1. </a> Root Key generation</h4>
<h4> <a name="9.3.1"> 9.3.1. </a> Root Key generation</h4>
<p> <p>
Root keys should be generated on a machine built securely Root keys should be generated on a machine built securely
for that purpose only and cleaned/wiped/destroyed immediately afterwards. for that purpose only and cleaned/wiped/destroyed immediately afterwards.
</p> </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> <p>
Root keys must be kept on reliable removable media used for that purpose only. 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. Subroots may be escrowed by either Board or Systems Administration Team.
</p> </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> <p>
Recovery must only be conducted Recovery must only be conducted under Arbitrator authority.
<span class="change">
under Arbitrator authority.
<s>
A recovery exercise should be conducted approximately every year.
</s>
</span>
</p> </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> <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> <h3><a name="9.6">9.6.</a> Outsourcing </h3>
<p class="change"> <p>
Components may be outsourced. Components may be outsourced.
Team leaders may outsource non-critical components Team leaders may outsource non-critical components
on notifying the board. on notifying the board.
@ -1374,7 +1241,7 @@ Any outsourcing arrangements must be documented.
All arrangements must be: All arrangements must be:
</p> </p>
<ul class="change"><li> <ul><li>
with Members of CAcert that are with Members of CAcert that are
<ul><li> <ul><li>
Assurers, as individuals, or 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> <h3> <a name="9.7">9.7</a> Confidentiality, Secrecy </h3>
<p class="change"> <p>
CAcert is an open organisation and adopts a principle CAcert is an open organisation and adopts a principle
of open disclosure wherever possible. of open disclosure wherever possible.
See <a href="https://svn.cacert.org/CAcert/principles.html"> 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. confidentiality or secrecy, then find another way.
</p> </p>
<p class="change"> <p>
In concrete terms, In concrete terms,
only under a defined exception under policy, only under a defined exception under policy,
or under the oversight of the Arbitrator, or under the oversight of the Arbitrator,