cacert/cacert-policies
9
1
Fork 0
Code Issues Pull requests Projects Releases Packages 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
This commit is contained in:
Ian Grigg 2010-06-05 10:35:41 +00:00
parent efe3e93034
commit 834133192a
1 changed files with 37 additions and 244 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

281
SecurityPolicy.html
View file

@ -4,7 +4,7 @@
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<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 - work-in-progress</title> <title>Security Policy - DRAFT</title>
<style type="text/css"> <!-- only for WIP --> <style type="text/css"> <!-- only for WIP -->
<!-- <!--
@ -12,10 +12,6 @@ body {
font-family : verdana, helvetica, arial, sans-serif; font-family : verdana, helvetica, arial, sans-serif;
} }
th {
text-align : left;
}
.q { .q {
color : green; color : green;
font-weight: bold; font-weight: bold;
@ -23,63 +19,15 @@ th {
font-style:italic; 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> </style>
</head> </head>
<body lang="en-GB"> <body lang="en-GB">
<ul class="change"> <p class="q">
<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> This version: going to DRAFT <a href="http://wiki.cacert.org/PolicyDecisions#p20100510">p20100510</a>
<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> </p>
<p class="q"> Start of Policy</p>
<hr /> <hr />
<h1>Security Policy for CAcert Systems</h1> <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> <table width="100%"><tr><td>
Creation date: 20090216<br /> Creation date: 20090216<br />
Editor: iang<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"> </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> </td></tr></table>
<h2 id="s1">1. INTRODUCTION</h2> <h2 id="s1">1. INTRODUCTION</h2>
@ -110,8 +58,7 @@ These systems include:
Source code (changes and patches) Source code (changes and patches)
</li></ol> </li></ol>
<p> <p>
<span class="strike">Board</span> The Committee of CAcert, Inc. (hereafter, "Board")
<span class="change">The Committee of CAcert, Inc. (hereafter, "Board")</span>
may add additional components into the Security Manual. may add additional components into the Security Manual.
</p> </p>
@ -130,7 +77,6 @@ These roles are defined as:
Support Engineer Support Engineer
</li><li> </li><li>
Software Assessor Software Assessor
<span class="strike2">(including Application Engineers)</span>
</li></ul> </li></ul>
<h4 id="s1.1.2">1.1.2. Out of Scope </h4> <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. See &sect;1.1.
</dd> </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> <dt><i>Software Assessor</i> </dt>
<dd> <dd>
A Member who reviews patches for security and workability, 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, As practices are things that vary from time to time,
including between each event of practice, including between each event of practice,
the SM is under the direct control of the the SM is under the direct control of the
<span class="strike">
Systems Administration team
</span>
<span class="change">
applicable team leaders. applicable team leaders.
</span>
It is located and version-controlled on the CAcert wiki. It is located and version-controlled on the CAcert wiki.
</p> </p>
@ -295,19 +228,11 @@ Machines shall be housed in secured facilities (cages and/or locked racks).
</p> </p>
<h4 id="s2.2.1.1">2.2.1.1 Acquisition </h4> <h4 id="s2.2.1.1">2.2.1.1 Acquisition </h4>
<p class="change"> <p>
Equipment for critical purposes should be acquired Equipment for critical purposes should be acquired
in a way to minimise pre-acquisition security risks. in a way to minimise pre-acquisition security risks.
</p> </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> <h4 id="s2.2.2">2.2.2. Service </h4>
<p> <p>
@ -327,10 +252,7 @@ are inventoried upon acquisition and tracked in their use.
<p> <p>
New storage media (whether disk or removable) shall be New storage media (whether disk or removable) shall be
securely securely erased and reformatted before use.
<span class="strike">wiped</span>
<span class="change">erased</span>
and reformatted before use.
</p> </p>
<h4 id="s2.2.3.2">2.2.3.2 Storage </h4> <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, Removable media shall be securely stored at all times,
including when not in use. including when not in use.
Drives that are kept for reuse are Drives that are kept for reuse are
<span class="strike">wiped</span> erased securely before storage.
<span class="change">erased</span>
securely before storage.
Reuse can only be within critical systems. Reuse can only be within critical systems.
</p> </p>
@ -400,9 +320,6 @@ one Systems Administrator present.
<p> <p>
There is no inherent authorisation to access the data. There is no inherent authorisation to access the data.
Systems Administrators Systems Administrators
<span class="strike2">
and Application Engineers
</span>
are authorised to access are authorised to access
the raw data under the control of this policy. the raw data under the control of this policy.
All others must not access the raw data. All others must not access the raw data.
@ -523,7 +440,6 @@ Documentation for installing and configuring servers with the appropriate softwa
<p> <p>
Software used on production servers must be kept current with respect to patches affecting software security. Patch application 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). 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>
@ -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, 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
<span class="change"> or instruct remedial action, and refer the case to dispute resolution.
or
</span>
instruct remedial action, and refer the case to dispute resolution.
</p> </p>
<p> <p>
@ -556,13 +469,7 @@ independent of filed disputes.
<h3 id="s3.3"> 3.3. Application </h3> <h3 id="s3.3"> 3.3. Application </h3>
<p class="strike2"> <p>
Systems administration is to provide a limited environment
to Applications Engineers in order to install and maintain
the application.
</p>
<p class="change2">
Requests for ad hoc queries over the application database for business Requests for ad hoc queries over the application database for business
or similar purposes must be approved by the Arbitrator. or similar purposes must be approved by the Arbitrator.
</p> </p>
@ -603,38 +510,36 @@ authorisations on the below access control lists
<td>Access Engineers</td> <td>Access Engineers</td>
<td>control of access by personnel to hardware</td> <td>control of access by personnel to hardware</td>
<td>exclusive of all other roles </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> </tr><tr>
<td>Physical Access List</td> <td>Physical Access List</td>
<td>Systems Administrators</td> <td>Systems Administrators</td>
<td>hardware-level for installation and recovery</td> <td>hardware-level for installation and recovery</td>
<td>exclusive with Access Engineers and Software Assessors</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> </tr><tr>
<td>SSH Access List</td> <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>Unix / account / shell level</td>
<td> includes by default all on Physical Access List </td> <td> includes by default all on Physical Access List </td>
<td>Systems Administration team leader</td> <td>Systems Administration team leader</td>
</tr><tr> </tr><tr>
<td>Repository Access List</td> <td>Repository Access List</td>
<td><span class="change2">Software Assessors</span> <span class="strike2">Application Engineers</span></td> <td>Software Assessors</td>
<td>change the source code repository <span class="strike2">and install patches to application</span></td> <td>change the source code repository </td>
<td>exclusive with Access Engineers and Systems Administrators</td> <td>exclusive with Access Engineers and Systems Administrators</td>
<td>software assessment team leader</td> <td>Software Assessment team leader</td>
</tr><tr> </tr><tr>
<td>Support Access List</td> <td>Support Access List</td>
<td>Support Engineer</td> <td>Support Engineer</td>
<td>support features in the web application</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> exclusive with Access Engineers and Systems Administrators </td>
<td><span class="strike">Systems Administration</span> <span class="change">Support</span> team leader</td> <td>Support team leader</td>
</tr></table> </tr></table>
<p> <p>
All changes of personnel to the above lists are All changes of personnel to the above lists are
<span class="change">subject to Board approval.</span> subject to Board approval.
<span class="strike">approved by the Board of CAcert.</span>
</p> </p>
<h4 id="s3.4.3"> 3.4.3. Authentication </h4> <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> <h4 id="s4.1.1">4.1.1. Privileged accounts and passphrases </h4>
<p> <p>
Access to <span class="change">privileged</span> accounts Access to privileged accounts
(root and user via SSH or console) (root and user via SSH or console)
must be strictly controlled. must be strictly controlled.
Passphrases and SSH private keys used for entering into the systems Passphrases and SSH private keys used for entering into the systems
will be kept private will be kept private
to CAcert sysadmins to CAcert sysadmins
<span class="strike2">and Application Engineers</span>
in all cases. in all cases.
</p> </p>
<h5 id="s4.1.1.1">4.1.1.1. Authorized users </h5> <h5 id="s4.1.1.1">4.1.1.1. Authorized users </h5>
<p> <p>
Only System Administrators Only Systems Administrators
<span class="strike2">and Application Engineers</span>
designated on the Access Lists designated on the Access Lists
in &sect;3.4.2 are authorized to access accounts. in &sect;3.4.2 are authorized to access accounts.
<span class="change2"> Systems Administration team leader may temporarily permit Software
System Administration team leader may temporarily permit Software
Assessors access to the application via SSH in order to do advanced Assessors access to the application via SSH in order to do advanced
debugging, or as debugging, or as specifically directed by the Arbitrator.
</span>
<span class="strike2">Other</span>
specifically directed by the Arbitrator.
</p> </p>
<p> <p>
@ -953,8 +852,7 @@ for the security and maintenance of the code.
<p> <p>
The source code is under CCS. The source code is under CCS.
Additions to the team are Additions to the team are
<span class="change">subject to Board approval.</span> subject to Board approval.
<span class="strike">approved by the Board.</span>
See &sect;3.4.2. See &sect;3.4.2.
</p> </p>
@ -977,57 +875,8 @@ Software assessment is not primarily tasked to write the code.
In principle, anyone can submit code changes for approval. In principle, anyone can submit code changes for approval.
</p> </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> <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> <h3 id="s7.4"> 7.4. Review </h3>
<p> <p>
@ -1057,35 +906,7 @@ Bug submission access should be provided to
any Member that requests it. any Member that requests it.
</p> </p>
<h3 id="s7.6"> 7.6. <span class="strike">Handover</span> <span class="change">Production</span> </h3> <h3 id="s7.6"> 7.6. Production </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>
<h2 id="s8">8. SUPPORT</h2> <h2 id="s8">8. SUPPORT</h2>
@ -1094,9 +915,7 @@ See &sect;3.3.
<p> <p>
The software interface gives features to Support Engineer. 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 Additions to the team are subject to Board approval,
<span class="change">subject to Board approval,</span>
<span class="strike">approved by the Board,</span>
and the software features are under CCS. and the software features are under CCS.
See &sect;3.4.2. See &sect;3.4.2.
</p> </p>
@ -1125,7 +944,7 @@ Support Engineers have these responsibilities:
</p> </p>
<ul><li> <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> </li><li>
Respond to general requests for information or explanation by Members. Respond to general requests for information or explanation by Members.
Support Engineers cannot make a binding statement. 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> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
<li> System Administrator: responsible for maintaining core services and integrity. </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> 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> Support Engineer: human interface with users.</li>
<li> Team leaders: coordinate with teams, report to Board.</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> 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> 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> </ul>
<h4 id="s9.1.2"> 9.1.2. Staffing levels</h4> <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> <h4 id="s9.1.4.2"> 9.1.4.2. Coverage </h4>
<p> <p>
ABC is to be done on every individual in a critical role. 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> </p>
<h4 id="s9.1.4.3"> 9.1.4.3. Documentation </h4> <h4 id="s9.1.4.3"> 9.1.4.3. Documentation </h4>
@ -1291,9 +1109,7 @@ with the relevant supporting information as above.
<p> <p>
The Board should deliberate directly and in full. The Board should deliberate directly and in full.
Board members who are also active in the area should Board members who are also active in the area should
<span class="strike">recuse</span> abstain from the vote,
<span class="change">abstain</span>
from the vote,
but should support the deliberations. but should support the deliberations.
Deliberations and decisions should be documented. Deliberations and decisions should be documented.
All conflicts of interest should be examined. 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. observe and report on security issues.
All of CAcert observes all where possible. All of CAcert observes all where possible.
It is the responsibility of each individual to resolve It is the responsibility of each individual to resolve
<span class="strike">it</span> issues satisfactorily, or to ensure that they are reported fully.
<span class="change">issues</span>
satisfactorily,
or to ensure that
<span class="strike">it is</span>
<span class="change">they are</span>
reported fully.
</p> </p>
<p> <p>
@ -1350,17 +1160,14 @@ especially of new team members.
<h4 id="s9.2.1"> 9.2.1. Root Key generation</h4> <h4 id="s9.2.1"> 9.2.1. Root Key generation</h4>
<p> <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. They must be generated to a fully documented and reviewed procedure.
The procedure must include: The procedure must include:
</p> </p>
<ul> <ul>
<li> Use of hardware built securely for the purpose <li> Use of hardware built securely for the purpose
only and cleaned/ only and cleaned/erased/destroyed immediately afterwards. </li>
<span class="strike">wiped</span>
<span class="change">erased</span>
/destroyed immediately afterwards. </li>
<li> Dual control over all phases, including by Board. </li> <li> Dual control over all phases, including by Board. </li>
<li> Strong collection of primary entropy, separated from use of entropy. </li> <li> Strong collection of primary entropy, separated from use of entropy. </li>
<li> Test cycles of the process on the day. </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> <h4 id="s9.3.1"> 9.3.1. Responsibility</h4>
<p> <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. the CA at the executive level.
</p> </p>
@ -1403,7 +1210,7 @@ the CA at the executive level.
<p> <p>
All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP. 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>
<p> <p>
@ -1421,11 +1228,6 @@ and becomes your authority to act.
<p> <p>
Components may be outsourced. 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. Any outsourcing arrangements must be documented.
All arrangements must be: All arrangements must be:
</p> </p>
@ -1455,9 +1257,7 @@ All arrangements must be:
<p> <p>
Contracts should be written with the above in mind. Contracts should be written with the above in mind.
<span class="change"> Outsourcing of critical components must be approved by the Board.
Outsourcing of critical components must be approved by <span class="strike">the</span> Board.
</span>
</p> </p>
<h3 id="s9.5">9.5 Confidentiality, Secrecy </h3> <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. Relevant and helpful Documents should be referenced for convenience.
</p> </p>
<hr /> <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> </body></html>