cacert/cacert-policies
9
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

first batch of PD changes

Browse source 
git-svn-id: http://svn.cacert.org/CAcert/Policies@1204 14b1bab8-4ef6-0310-b690-991c95c89dfd
This commit is contained in:
Ian Grigg 2009-03-11 15:58:55 +00:00
parent d88d1c2fe0
commit b36a49b6b9
1 changed files with 219 additions and 101 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

320
SecurityPolicy.html
View file

@ -77,7 +77,7 @@ These roles are directly covered:
</li><li>
Systems Administrators
</li><li>
Supporters
Support Engineer
</li><li>
Software Assessors
</li></ul>
@ -114,6 +114,8 @@ Important principles of this Security Policy are:
two people from different areas
</li><li>
<i>Audit</i> -- where external reviewers do checks on practices and policies
</li><li>
<i>Authority</i> -- every action is authorised by either a policy or by the Arbitrator.
</li></ul>
<p>
@ -131,14 +133,14 @@ deriving from the above principles.
See &sect;1.1.
</dd>
<dt><i>Software Assessor </i> </dt>
<dt><i>Software Assessor</i> </dt>
<dd>
A Member who reviews patches for security and workability,
signs-off on them, and incorporates them into the repository.
See &sect;7.
</dd>
<dt><i>Support ???</i> <span class="q"> noun needed here</span> </dt>
<dt><i>Support Engineer</i> </dt>
<dd>
A Member who mans the support list,
and has access to restricted
@ -148,7 +150,7 @@ deriving from the above principles.
<dt><i>Systems Administrator</i> </dt>
<dd>
A Member who manages a critial system, and has access
A Member who manages a critical system, and has access
to security-sensitive functions or data.
</dd>
@ -167,6 +169,11 @@ It is under the control of Policy on Policy for version purposes.
<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>
</p>
<h4><a name="1.4.2">1.4.2.</a> The Security Manual (Practices) Document </h4>
@ -186,6 +193,10 @@ 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>
@ -232,7 +243,9 @@ List must be subject to change control.
</p>
<p>
Units shall have nickname clearly marked on front and rear of chassis.
<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>
@ -247,8 +260,6 @@ prepared in advance.
<h4><a name="2.2.2">2.2.2.</a> Service </h4>
<p class="q">Wytze: new section replacing 'cables':</p>
<p>
Equipment that is subject to a service security risk
must be retired if service is required.
@ -331,8 +342,12 @@ one systems administrator present.
</p>
<p>
Only Systems Administrators are authorised to access the data.
All others must not access the data.
<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.
</p>
@ -347,9 +362,14 @@ All physical accesses are logged and reported to all.
<p>
There is no procedure for emergency access.
If emergency access is gained,
this must be reported and justified immediately.
See DPR.
<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 DPR.
</p>
<h4><a name="2.3.5">2.3.5.</a> Physical Security codes & devices </h4>
@ -366,13 +386,31 @@ codes and devices (keys) are to be authorised and documented.
<h4><a name="3.1.1">3.1.1.</a> Infrastructure </h4>
<p>
Current and complete diagrams of the physical and logical CAcert network infrastructure shall be maintained by systems administration team leader. These diagrams should include cabling information, physical port configuration details, and expected/allowed data flow directions, as applicable. Diagrams should be revision controlled, and must be updated when any change is made.
Current and complete diagrams of the physical and logical
CAcert network infrastructure shall be maintained by
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.
</p>
<h5> 3.1.1.1. External connectivity </h5>
<p>
Only such services as are required for normal operation 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.
Only such services as are required for normal operation
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">
Any exceptions must be documented in the Security Manual.
</span>
</p>
<h5> 3.1.1.2. Internal connectivity </h5>
@ -445,47 +483,73 @@ 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, or refer the case to dispute resolution.
instruct remedial action,
<span class="change">
and
</span>
refer the case to dispute resolution.
</p>
<p>
<b>
Declaration of an emergency patching situation should not occur with any regularity.
</b>
Emergency patch events must be documented within the regular summaries to Board.
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>
<p>
Software assessment takes place on various test systems (not a critical system). See &sect;7. Once offered by Software Assessment (team), system administration team leader has to approve the installation of each release or patch.
Software assessment takes place on various test systems
(not a critical system). See &sect;7.
Once offered by Software Assessment (team),
system administration team leader has to
approve the installation of each release or patch.
</p>
<p>
Any changes made to source code must be referred back to software assessment team.
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 class="q">
These two paras seem in wrong place.
Either add a "3.4.3. User Access" or?
</p>
<p>
General user access to CAcert services shall normally be conducted through a web-based application interface. Features are made available according to Assurance Points and direct permissions.
<span class="change">
All access to critical data and services shall be
controlled and logged.
</span>
<h4><a name="3.4.1"> 3.4.1.</a> Application Access </h4>
<span class="change">
General access for Members shall be provided via
a dedicated web application.
General features are made available according to
Assurance Points and similar methods controlled in
the software system.
</span>
</p>
<p>
Direct Permissions are managed by the Application to enable special online administrators from the Support Team access to certain functions.
</p>
<p class="q"> what about web-api interfaces? Excluded? </p>
<h4><a name="3.4.1"> 3.4.1.</a> Authorisation </h4>
<p class="q"> This bit is expanded! </p>
<h4><a name="3.4.2"> 3.4.2.</a> Special Authorisation </h4>
<p>
The access control lists (see &sect;1.1.1) are:
<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>
<table align="center" border="1"> <tr>
@ -499,13 +563,13 @@ The access control lists (see &sect;1.1.1) are:
<td>Access Engineers</td>
<td>control of access by personnel to hardware</td>
<td>exclusive of all other roles </td>
<td>Boards of CAcert and of Oophaga</td>
<td>Boards of CAcert (or designee)</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>Boards of CAcert and of Oophaga</td>
<td>Boards of CAcert (or designee)</td>
</tr><tr>
<td>SSH Access List</td>
<td>systems administrators</td>
@ -514,8 +578,8 @@ The access control lists (see &sect;1.1.1) are:
<td>systems administration team leader</td>
</tr><tr>
<td>Support Access List</td>
<td>supporters</td>
<td>support features in the online interface</td>
<td>Support Engineer</td>
<td>support features in the web application</td>
<td> includes by default all systems administrators </td>
<td>systems administration team leader</td>
</tr><tr>
@ -531,13 +595,16 @@ The access control lists (see &sect;1.1.1) are:
All changes to the above lists are approved by the board of CAcert.
</p>
<h4><a name="3.4.2"> 3.4.2.</a> Authentication </h4>
<h4><a name="3.4.3"> 3.4.3.</a> Authentication </h4>
<p>
A strong method of authentication is used and documented.
<span class="change">
Strong methods of authentication shall be used.
All authentication schemes must be documented.
</span>
</p>
<h4><a name="3.4.3"> 3.4.3.</a> Removing access </h4>
<h4><a name="3.4.4"> 3.4.4.</a> Removing access </h4>
<p>
Follow-up actions to termination must be documented.
@ -574,8 +641,11 @@ to CAcert sysadmins in all cases.
<p>
Only system administrators designated on the
Access Lists
in &sect;3.4.1
shall be authorized to access accounts.
in &sect;3.4.2
are authorized to access accounts,
<span class="change">
unless specifically directed by the Arbitrator.
</span>
</p>
<h5> <a name="4.1.1.2">4.1.1.2.</a> Access to Systems</h5>
@ -586,17 +656,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 should be documented.
</p>
<h5> <a name="4.1.1.4">4.1.1.4.</a> Outsourcing </h5>
<p>
Systems administration team leader may outsource non-critical
components such as DNS servers.
Outsourcing should be to Members who are Assurers,
who have the appropriate technical knowledge,
and are in good contact with team leader.
The procedure for changing passphrases and SSH keys <span class="change">shall</span> be documented.
</p>
<h4> <a name="4.1.2">4.1.2.</a> Required staff response time </h4>
@ -606,9 +666,14 @@ 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.
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>
<h3> <a name="4.2">4.2.</a> Logging </h3>
<h4> <a name="4.2.1">4.2.1.</a> Coverage </h4>
@ -670,6 +735,11 @@ Disaster recovery backups may be distributed.
<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.
@ -709,6 +779,11 @@ See CCA.
</p>
<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>
<p>
@ -741,8 +816,14 @@ 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 sent to systems administrators
An initial report should be
<span class="change">
circulated.
<s>
sent to systems administrators
and wider interested parties.
</s>
</span>
</p>
<p>
@ -750,9 +831,15 @@ 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> Oversight </h4>
<h4> <a name="5.2.3">5.2.3.</a> <span class="change"> Escalation </span> </h4>
<p>
A process of escalation of oversight should be eastablished.
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>
@ -767,7 +854,7 @@ Evidence must be secured if the severity is high.
<h3> <a name="5.6">5.6.</a> Report </h3>
<p>
Incident reports must be published.
Incident reports <span class="change">shall</span> be be published.
The Incident Report is written on closing the investigation.
A full copy should be appended to the
documentation of the investigation.
@ -778,22 +865,14 @@ for publication and maintenance.
</p>
<p>
Incidents are not normally kept secret nor confidential.
Incidents are not normally kept secret nor confidential,
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.
</p>
<p class="q">
The following is a general confidentiality and secrecy
clause. Suggest moving this to new section 9.7.
</p>
<p>
Only under a defined exception under policy,
or under the oversight of the Arbitrator,
may confidentiality be maintained.
<span class="change">
See &sect;9.7.
</span>
</p>
<h2><a name="6">6.</a> DISASTER RECOVERY</h2>
@ -826,6 +905,10 @@ 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>
@ -846,7 +929,7 @@ for the security of the code.
<p>
The source code is under CCS.
Additions to the team are approved by Board.
See &sect;3.4.1.
See &sect;3.4.2.
</p>
<h3> <a name="7.2"> 7.2. </a> Tasks </h3>
@ -943,19 +1026,21 @@ See &sect;3.3.
<h3> <a name="8.1"> 8.1. </a> Authority </h3>
<p>
The software interface gives features to Support personnel.
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>
Support personnel do not have any inherent authority
Support Engineers do not have any inherent authority
to take any action,
and they have have to get authority on a case-by-case
basis.
and they have have to get authority on a case-by-case basis.
The authority required in each case must be guided
by this policy or the Security Manual or other clear
by this policy or the Security Manual or other clearly
applicable document.
If the Member's authority is not in doubt,
the Member can give that authority.
@ -963,7 +1048,7 @@ If not, the Arbitrator's authority must be sought.
</p>
<p>
Support personnel are responsible to follow the
Support Engineers are responsible to follow the
policies and practices.
</p>
@ -971,23 +1056,26 @@ policies and practices.
<h3> <a name="8.3"> 8.3. </a> Channels </h3>
<h3> <a name="8.4"> 8.4. </a> Interface </h3>
<p>
Access to Member's private information is restricted.
Support staff may be authorised by the Board
to access any additional, restricted interfaces.
This access is managed by the systems administration
team leader, see &sect;3.4.1.
</p>
<h3> <a name="8.4"> 8.4. </a> Records and Logs </h3>
<h3> <a name="8.5"> 8.5. </a> Records and Logs </h3>
<ul>
<li> use of restricted interfaces must be logged. </li>
<li> all support channels should be logged. </li>
<li> private requests for support should be referred to proper channels and logged there (e.g., by CCs) </li>
</ul>
<h3> <a name="8.6"> 8.6. </a> Arbitration </h3>
<h3> <a name="8.5"> 8.5. </a> Arbitration </h3>
<span class="change">
Support Engineers refer questions requiring authority
to Arbitration, and may also be called upon to act as
default Case Managers.
See DRP and
<a href="https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html">Case Manager's Handbook.</a>
Support Engineers should be familiar with
these topics, even if not listed as Arbitrators
or Case Managers.
</span>
<h3> <a name="8.6"> 8.6. </a> References </h3>
@ -1001,7 +1089,7 @@ team leader, see &sect;3.4.1.
<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> Support: human interface with users.</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>
@ -1014,7 +1102,7 @@ Each team should have a minimum of two members available at any time.
Individuals should not be active
in more than one team at any one time,
but are expected to observe the other teams.
See &sect;3.4.1 for exclusivities.
See &sect;3.4.2 for exclusivities.
</p>
<p>
@ -1069,7 +1157,7 @@ The background check should be done on all of:
<li> systems administrator </li>
<li> access engineeers </li>
<li> software assessor </li>
<li> support </li>
<li> support engineer </li>
<li> Board </li>
</ul>
@ -1148,7 +1236,7 @@ and may be reversed.
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.
See &sect;3.4.3.
See &sect;3.4.4.
</p>
<p>
@ -1170,7 +1258,7 @@ especially of new team members.
<h3> <a name="9.2"> 9.2. </a> Key changeover</h3>
<p class="q">what goes in here? Non-root keys?</p>
<p class="q">what goes in here? Non-root keys? Strike this section? Or merge it as Root Keys with 9.3, 9.4....</p>
<h3> <a name="9.3"> 9.3. </a> Key generation/transfer</h3>
@ -1243,10 +1331,11 @@ and becomes your authority to act.
<h3><a name="9.6">9.6.</a> Outsourcing </h3>
<p>
CAcert may at its option outsource critical components to
other organisations, however this must not be a barrier
to security. Outsourced arrangements must be transparent.
<p class="change">
Components may be outsourced.
Team leaders may outsource non-critical components
on notifying the board.
Critical components must be approved by the board.
<p>
<p>
@ -1254,26 +1343,55 @@ Any outsourcing arrangements must be documented.
All arrangements must be:
</p>
<ul><li>
<ul class="change"><li>
with Members of CAcert that are
<ul><li>
Assurers, as individuals, or
</li><li>
Assured Organisations, in which
all involved personnel are Assurers,
</li></ul>
</li><li>
</li><li>
with Members that have the requisite knowledge
and in good contact with the team leader(s),
</li><li>
subject to audit,
</li><li>
transparent and no barrier to security,
</li><li>
under this Policy and the Security Manual,
</li><li>
under Arbitration and DRP,
fully under Arbitration and DRP for the purposes of Security, and
</li><li>
with organisations that are Members of CAcert
as organisational Members, and
</li><li>
under the spirit of the Principles of CAcert
under the spirit of the Community and within the Principles of CAcert.
</li></ul>
<p>
Specifically, all involved personnel must be CAcert Assurers.
Contracts should be written with the above in mind.
</p>
<h3> <a name="9.7">9.7</a> Confidentiality, Secrecy </h3>
<p class="change">
CAcert is an open organisation and adopts a principle
of open disclosure wherever possible.
See <a href="https://svn.cacert.org/CAcert/principles.html">
Principles</a>.
This is not a statement of politics but a statement of security;
if a subject can only sustain under some
confidentiality or secrecy, then find another way.
</p>
<p class="change">
In concrete terms,
only under a defined exception under policy,
or under the oversight of the Arbitrator,
may confidentiality or secrecy be maintained.
All should strive to reduce or remove any such
restriction.
</p>
<h2><a name="10">10.</a> REFERENCES</h2>