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

batch of changes from NL meetings (Wytze) 20090306-07

Browse source 
git-svn-id: http://svn.cacert.org/CAcert/Policies@1196 14b1bab8-4ef6-0310-b690-991c95c89dfd
This commit is contained in:
Ian Grigg 2009-03-08 09:09:11 +00:00
parent da157c5a81
commit 27fc4a3096
1 changed files with 178 additions and 128 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

306
SecurityPolicy.html
View file

@ -52,7 +52,7 @@ Status: <i>work-in-progress</i>
<p> <p>
This Security Policy sets out the policy This Security Policy sets out the policy
for the secure operation of the CAcert critical computer systems. for the secure operation of the CAcert critical computer systems.
These computer systems include: These systems include:
</p> </p>
<ol><li> <ol><li>
Physical hardware mounting the logical services Physical hardware mounting the logical services
@ -69,23 +69,17 @@ These computer systems include:
<h4><a name="1.1.1">1.1.1.</a> Effected Personnel </h4> <h4><a name="1.1.1">1.1.1.</a> Effected Personnel </h4>
<p> <p>
These roles and teams are effected: These roles are directly covered:
</p> </p>
<ul><li> <ul><li>
Hardware Controllers (Oophaga) Access Engineers
</li><li> </li><li>
Direct Hardware Access Systems Administrators Systems Administrators
(as listed in Oophaga Appendix B Access List)
</li><li> </li><li>
Application Administrators Supporters
(online access to critical systems at Unix level)
</li><li> </li><li>
Support Team Software Assessors
(online access via administration interfaces)
</li><li>
Software Development Team
(approval of application code)
</li></ul> </li></ul>
<h4><a name="1.1.1">1.1.2.</a> Out of Scope </h4> <h4><a name="1.1.1">1.1.2.</a> Out of Scope </h4>
@ -105,13 +99,13 @@ Important principles of this Security Policy are:
<ul><li> <ul><li>
<i>dual control</i> -- at least two individuals must control a task <i>dual control</i> -- at least two individuals must control a task
</li><li> </li><li>
<i>four eyes</i> -- at least two individuals must be present during a task, <i>four eyes</i> -- at least two individuals must participate in a task,
one to execute and one to observe. one to execute and one to observe.
</li><li> </li><li>
<i>redundancy</i> -- no single individual is the only one authorized <i>redundancy</i> -- no single individual is the only one authorized
to perform a task. to perform a task.
</li><li> </li><li>
<i>escrow</i> -- where critical information (backups, passwords) <i>escrow</i> -- where critical information (backups, passphrases)
is kept with other parties is kept with other parties
</li><li> </li><li>
<i>logging</i> -- where events are recorded in a file <i>logging</i> -- where events are recorded in a file
@ -137,7 +131,7 @@ deriving from the above principles.
See &sect;1.1. See &sect;1.1.
</dd> </dd>
<dt><i>Software Developer </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,
signs-off on them, and incorporates them into the repository. signs-off on them, and incorporates them into the repository.
@ -169,6 +163,8 @@ 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.
</p> </p>
@ -188,7 +184,7 @@ It is located and version-controlled on the CAcert wiki.
<p> <p>
Section Headings are the same in both documents. Section Headings are the same in both documents.
Where Section Headings 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.
</p> </p>
@ -218,11 +214,13 @@ 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> <ul class="q"><li>
Big question here is whether Oophaga falls inside SP/SM or not.<br> Big change is to place Oophaga INSIDE the SM/SP.
Answered: <b>IN</b>.
</li><li> </li><li>
2nd Big Question is whether Oophaga is in SP or in SM.<br> 2nd Change is to place Oophaga in SP and in SM:
Answered: <b>in the SM.</b> <ul>
<li> role of Access Engineer is in SP.</li>
<li> detail in the SM.</li>
</ul>
</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>
@ -247,14 +245,14 @@ Precautions must be taken to prevent equipment being
prepared in advance. prepared in advance.
</p> </p>
<h4><a name="2.2.2">2.2.2.</a> Cables </h4> <h4><a name="2.2.2">2.2.2.</a> Service </h4>
<p class="error">
Drop 2.2.2.
</p>
<p class="q"> <p class="q">Wytze: new section replacing 'cables':</p>
Cabling to all equipment shall be labeled at both ends
with identification of end points. <p>
Equipment that is subject to a service security risk
must be retired if service is required.
See also &sect;2.2.3.3.
</p> </p>
<h4><a name="2.2.3">2.2.3.</a> Media </h4> <h4><a name="2.2.3">2.2.3.</a> Media </h4>
@ -263,8 +261,7 @@ with identification of end points.
<p> <p>
Storage media (disk drives, tapes, removable media) Storage media (disk drives, tapes, removable media)
are inventoried upon acquisition are inventoried upon acquisition and tracked in their use.
and tracked in their use.
</p> </p>
<p> <p>
@ -305,7 +302,7 @@ The following steps are to be taken:
Records of secure erasure and method of final disposal Records of secure erasure and method of final disposal
shall be tracked in the asset inventory. shall be tracked in the asset inventory.
Where critical data is involved, Where critical data is involved,
2 system administrators must sign-off on each step. two systems administrators must sign-off on each step.
</p> </p>
<h3><a name="2.3">2.3.</a> Physical Access </h3> <h3><a name="2.3">2.3.</a> Physical Access </h3>
@ -326,10 +323,11 @@ Access to physical equipment must be authorised.
<p> <p>
The Security Manual must present the different access profiles. The Security Manual must present the different access profiles.
At least one CAcert systems administrator will be present for At least one Access Engineer must control access in all cases.
logical access to CAcert critical servers. At least one systems administrator will be present for
logical access.
Only the most basic and safest of accesses should be done with Only the most basic and safest of accesses should be done with
one CAcert systems administrator present. one systems administrator present.
</p> </p>
</p> </p>
@ -380,7 +378,7 @@ Only such services as are required for normal operation should be visible extern
<h5> 3.1.1.2. Internal connectivity </h5> <h5> 3.1.1.2. Internal connectivity </h5>
<p> <p>
System and server connections internal to the CAcert infrastructure should be kept to the minimum required for routine operations. Any new connectivity desired must be requested and approved by CAcert system administration team leader and then must be reflected in the appropriate infrastructure diagram(s). System and server connections internal to the CAcert infrastructure should be kept to the minimum required for routine operations. Any new connectivity desired must be requested and approved by system administration team leader and then must be reflected in the appropriate infrastructure diagram(s).
</p> </p>
@ -424,7 +422,7 @@ Servers must enable only the operating system functions required to support the
</p> </p>
<p> <p>
Documentation for installing and configuring servers with the appropriate software packages and configurations will be maintained by the system administrators in the wiki. Documentation for installing and configuring servers with the appropriate software packages and configurations will be maintained by the system administrators.
</p> </p>
@ -460,15 +458,20 @@ Emergency patch events must be documented within the regular summaries to Board.
<h3> 3.3. Application </h3> <h3> 3.3. Application </h3>
<p> <p>
Software development takes place on various test systems (not a critical system). See &sect;7. Once offered by Software Development (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>
<p> <p>
Any changes made to source code must be referred back to software development. Any changes made to source code must be referred back to software assessment team.
</p> </p>
<h3> 3.4. Access control </h3> <h3> 3.4. Access control </h3>
<p class="q">
These two paras seem in wrong place.
Either add a "3.4.3. User Access" or?
</p>
<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. 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.
</p> </p>
@ -479,20 +482,50 @@ Direct Permissions are managed by the Application to enable special online admin
<h4> 3.4.1. Authorisation </h4> <h4> 3.4.1. Authorisation </h4>
<p class="q"> This bit is expanded! </p>
<p> <p>
The access control lists are: The access control lists (see &sect;1.1.1) are:
</p> </p>
<ul><li> <table align="center" border="1"> <tr>
Console Access List, <td>List Name</td>
for physical access by System Administrators. <td>Who</td>
</li><li> <td>Purpose of access</td>
SSH Access List, <td>Relationship</td>
for access to Unix-level facilities of the online webserver. <td> Manager </td>
</li><li> </tr><tr>
Support Access List, <td>Physical Control List</td>
for access to the online support interface features. <td>Access Engineers</td>
</li></ul> <td>control of access by personnel to hardware</td>
<td>exclusive of all other roles </td>
<td>Boards of CAcert and of Oophaga</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>
</tr><tr>
<td>SSH Access List</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>Support Access List</td>
<td>supporters</td>
<td>support features in the online interface</td>
<td> includes by default all systems administrators </td>
<td>systems administration team leader</td>
</tr><tr>
<td>Repository Access List</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>
</tr><table>
<p> <p>
All changes to the above lists are approved by the board of CAcert. All changes to the above lists are approved by the board of CAcert.
@ -507,9 +540,8 @@ A strong method of authentication is used and documented.
<h4> 3.4.3. Removing access </h4> <h4> 3.4.3. Removing access </h4>
<p> <p>
Termination actions must be documented, Follow-up actions to termination must be documented.
including resignation, arbitration, or determination See &sect;9.1.7.
by team or board.
</p> </p>
@ -523,46 +555,38 @@ by team or board.
Primary systems administration tasks Primary systems administration tasks
shall be conducted under four eyes principle. shall be conducted under four eyes principle.
These shall include backup performance verification, These shall include backup performance verification,
log inspection, software patch application,
software patch identification and application,
account creation and deletion, account creation and deletion,
and hardware maintenance. and hardware maintenance.
</p> </p>
<p> <h4> <a name="4.1.1">4.1.1.</a> Privileged accounts and passphrases </h4>
System administrators must pass a background check
and comply with all applicable policies in force.
</p>
<h4> <a name="4.1.1">4.1.1.</a> Privileged accounts and passwords </h4>
<p> <p>
Access to Accounts Access to Accounts
(root and user via SSH or console) (root and user via SSH or console)
must be strictly controlled. must be strictly controlled.
Passwords and passphrases entered into the systems will be kept private Passphrases and SSH private keys used for entering into the systems
will be kept private
to CAcert sysadmins in all cases. to CAcert sysadmins in all cases.
</p> </p>
<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 Access List Only system administrators designated on the
Access Lists
in &sect;3.4.1
shall be authorized to access accounts. shall be authorized to access accounts.
</p> </p>
<p class="q">Assumes above that there is no reason to have access
to a Unix-level account on the critical machines unless on the Access List.</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>
<p> <p>
All remote communications for systems administration purposes is encrypted, All access is secured, logged and monitored.
logged and monitored.
</p> </p>
<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>
Passwords must be kept secure. The procedure for changing passphrases and SSH keys should be documented.
The procedure for changing passwords should be documented.
</p> </p>
<h5> <a name="4.1.1.4">4.1.1.4.</a> Outsourcing </h5> <h5> <a name="4.1.1.4">4.1.1.4.</a> Outsourcing </h5>
@ -577,7 +601,7 @@ and are in good contact with team leader.
<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>
<p> <p>
Response times should be documented. Response times should be documented for Disaster Recovery planning. See &sect;6.
</p> </p>
<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>
@ -594,20 +618,6 @@ All sensitive events should be logged.
Logs should be deleted after an appropriate amount of time. Logs should be deleted after an appropriate amount of time.
</p> </p>
<p class="q">
'''Move to SM:'''
Logs shall be maintained for:
</p>
<ul>
<li> anomalous network traffic, </li>
<li> system activities and events, </li>
<li> application (certificate, web, mail, and database) events, </li>
<li> '''make generic''': "Comms Module" requests for certificate signing on both the cryptographic module (signing server) and the main online server, </li>
<li> login and root access, </li>
<li> configuration changes. </li>
</ul>
<h4> <a name="4.2.2">4.2.2.</a> Access and Security </h4> <h4> <a name="4.2.2">4.2.2.</a> Access and Security </h4>
<p> <p>
@ -627,11 +637,12 @@ suspicious events should be flagged and investigated in a timely fashion.
<h4> <a name="4.2.4">4.2.4.</a> Operational (manual) logs </h4> <h4> <a name="4.2.4">4.2.4.</a> Operational (manual) logs </h4>
<p> <p>
Configuration changes, no matter how small, must be logged. Configuration changes, no matter how small, must be logged.
Access to this log shall be restricted.
</p> </p>
<p> <p>
All physical visits will be logged and a report provided by the accessor. All physical visits must be logged and a
report provided by the accessor and by
the Access Engineer.
</p> </p>
<h3> <a name="4.3">4.3.</a> Backup </h3> <h3> <a name="4.3">4.3.</a> Backup </h3>
@ -644,9 +655,9 @@ according to the following sub-headings.
<h4> <a name="4.3.1">4.3.1.</a> Type </h4> <h4> <a name="4.3.1">4.3.1.</a> Type </h4>
<p> <p>
Backups must be taken for operational Backups must be taken for operational
and for disaster recovery purposes ("offline"). and for disaster recovery purposes.
Disaster recovery backups must be offline and remote.
Operational backups may be online and local. Operational backups may be online and local.
Disaster recovery backups must be offline and remote.
</p> </p>
<h4> <a name="4.3.2">4.3.2.</a> Frequency </h4> <h4> <a name="4.3.2">4.3.2.</a> Frequency </h4>
@ -654,7 +665,7 @@ Operational backups may be online and local.
<h4> <a name="4.3.3">4.3.3.</a> Storage </h4> <h4> <a name="4.3.3">4.3.3.</a> Storage </h4>
<p> <p>
Backups must be protected to the same level as the critical systems themselves. Backups must be protected to the same level as the critical systems themselves.
Offline backups should be distributed. 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>
@ -682,9 +693,10 @@ Paper documentation must be stored with manual backups.
<h4> <a name="4.3.8">4.3.8.</a> Reading Backups </h4> <h4> <a name="4.3.8">4.3.8.</a> Reading Backups </h4>
<p> <p>
Conditions and procedures for examining the backups for purposes Conditions and procedures for examining the backups
other than for verification must be documented must be documented,
and must be under Arbitrator control. and must be under Arbitrator control for purposes
other than verification and recovery.
</p> </p>
<h3> <a name="4.4">4.4.</a> Data retention </h3> <h3> <a name="4.4">4.4.</a> Data retention </h3>
@ -700,12 +712,10 @@ See CCA.
<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>
<p> <p>
The systems administration team leader is to maintain incident reports securely. Document.
Access to incident reports is restricted. See &sect;5.6.
</p> </p>
<h3> <a name="4.5">4.5.</a> Cycling </h3>
@ -755,18 +765,35 @@ Evidence must be secured if the severity is high.
<h3> <a name="5.5">5.5.</a> Response </h3> <h3> <a name="5.5">5.5.</a> Response </h3>
<h3> <a name="5.6">5.6.</a> Report </h3> <h3> <a name="5.6">5.6.</a> Report </h3>
<p> <p>
A report should be appended to the documentation of the investigation, Incident reports must be published.
and distributed in the act of closing the investigation. The Incident Report is written on closing the investigation.
A full copy should be appended to the
documentation of the investigation.
Sensitive information may be pushed out into
a restricted appendix of the report.
The systems administration team leader is responsible
for publication and maintenance.
</p> </p>
<p> <p>
Incidents are not normally kept secret or confidential. Incidents are not normally kept secret nor confidential.
Ony under a defined exception under policy, 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, or under the oversight of the Arbitrator,
may confidentiality be maintained. may confidentiality be maintained.
The knowledge of the existence of the event must not be kept
secret, nor the manner in which it is kept confidential.
</p> </p>
<h2><a name="6">6.</a> DISASTER RECOVERY</h2> <h2><a name="6">6.</a> DISASTER RECOVERY</h2>
@ -798,18 +825,19 @@ Board must have a basic plan to recover.
<p> <p>
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.
</p> </p>
<h2><a name="7">7.</a> SOFTWARE DEVELOPMENT</h2> <h2><a name="7">7.</a> SOFTWARE ASSESSMENT</h2>
<p class="q"> <p class="q">
Change name of this to Software Assessment. Change name of this to Software Assessment.
</p> </p>
<p> <p>
Software development team is responsible Software assessment team is responsible
for the security of the code. for the security of the code.
</p> </p>
@ -817,7 +845,8 @@ for the security of the code.
<p> <p>
The source code is under CCS. The source code is under CCS.
Additions to the team are approved by Board Additions to the team are approved by Board.
See &sect;3.4.1.
</p> </p>
<h3> <a name="7.2"> 7.2. </a> Tasks </h3> <h3> <a name="7.2"> 7.2. </a> Tasks </h3>
@ -837,7 +866,7 @@ The primary tasks are:
</li></ol> </li></ol>
<p> <p>
Software Development is not primarily tasked to write the code. 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>
@ -847,7 +876,7 @@ In principle, anyone can submit code changes for approval.
<p> <p>
The application code and patches are maintained The application code and patches are maintained
in a central repository that is run by the in a central repository that is run by the
software development team. software assessment team.
</p> </p>
<h3> <a name="7.4"> 7.4. </a> Review </h3> <h3> <a name="7.4"> 7.4. </a> Review </h3>
@ -865,16 +894,16 @@ The riskier the source is, the more reviews have to be done.
<h3> <a name="7.5"> 7.5. </a> Test and Bugs </h3> <h3> <a name="7.5"> 7.5. </a> Test and Bugs </h3>
<p> <p>
Software Development team maintains a test system. Software assessment team maintains a test system.
Each patch should be built and tested. Each patch should be built and tested.
Test status of each patch must be logged. Test status of each patch must be logged.
</p> </p>
<p> <p>
Software Development team maintains a bug system. Software assessment team maintains a bug system.
Primary communications should go through this system. Primary communications should go through this system.
Management access should be granted to all software developers, Management access should be granted to all software assessors,
and systems administrators. software developers, and systems administrators.
Bug submission access should be provided to Bug submission access should be provided to
any Member that requests it. any Member that requests it.
</p> </p>
@ -882,12 +911,12 @@ any Member that requests it.
<h3> <a name="7.6"> 7.6. </a> Handover </h3> <h3> <a name="7.6"> 7.6. </a> Handover </h3>
<p> <p>
Once signed off, software development (team leader) Once signed off, software assessment (team leader)
coordinates with systems administration (team leader) coordinates with systems administration (team leader)
to offer the upgrade. to offer the upgrade.
Upgrade format is to be negotiated, Upgrade format is to be negotiated,
but systems administration naturally has the last word. but systems administration naturally has the last word.
Software development people are not to have access Software assessors are not to have access
to the critical systems, providing a dual control to the critical systems, providing a dual control
at the teams level. at the teams level.
</p> </p>
@ -903,7 +932,8 @@ system administrators.
<p> <p>
Systems administrators copy the patches securely Systems administrators copy the patches securely
from the software development onto the critical machine. from the software assessment repository
onto the critical machine.
See &sect;3.3. See &sect;3.3.
</p> </p>
@ -929,8 +959,7 @@ by this policy or the Security Manual or other clear
applicable document. applicable document.
If the Member's authority is not in doubt, If the Member's authority is not in doubt,
the Member can give that authority. the Member can give that authority.
If not, the Arbitrator's authority must be sought.
The Arbitrator's authority must be sought.
</p> </p>
<p> <p>
@ -947,7 +976,8 @@ policies and practices.
Access to Member's private information is restricted. Access to Member's private information is restricted.
Support staff may be authorised by the Board Support staff may be authorised by the Board
to access any additional, restricted interfaces. to access any additional, restricted interfaces.
Each such special access is managed by the team leader. This access is managed by the systems administration
team leader, see &sect;3.4.1.
</p> </p>
<h3> <a name="8.5"> 8.5. </a> Records and Logs </h3> <h3> <a name="8.5"> 8.5. </a> Records and Logs </h3>
@ -968,8 +998,9 @@ Each such special access is managed by the team leader.
<h3> <a name="9.1.1"> 9.1.1. </a> Roles and responsibilities</h3> <h3> <a name="9.1.1"> 9.1.1. </a> Roles and responsibilities</h3>
<ul> <ul>
<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 Developer: 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> Support: human interface with users.</li> <li> Support: 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>
@ -979,13 +1010,16 @@ Each such special access is managed by the team leader.
<h3> <a name="9.1.2"> 9.1.2. </a> Staffing levels</h3> <h3> <a name="9.1.2"> 9.1.2. </a> Staffing levels</h3>
<p> <p>
Each team should have a minimum of 2 members available at any time. Each team should have a minimum of two members available at any time.
Individuals should be active in only one team at any one time, Individuals should not be active
but may be observers on any number of teams. in more than one team at any one time,
but are expected to observe the other teams.
See &sect;3.4.1 for exclusivities.
</p> </p>
<p> <p>
One individual in each team is designated leader and reports to Board. One individual in each team is designated team leader
and reports to Board.
</p> </p>
<h3> <a name="9.1.3"> 9.1.3. </a> Process of new Team Members</h3> <h3> <a name="9.1.3"> 9.1.3. </a> Process of new Team Members</h3>
@ -1034,7 +1068,7 @@ The background check should be done on all of:
<ul> <ul>
<li> systems administrator </li> <li> systems administrator </li>
<li> access engineeers </li> <li> access engineeers </li>
<li> software developer </li> <li> software assessor </li>
<li> support </li> <li> support </li>
<li> Board </li> <li> Board </li>
</ul> </ul>
@ -1052,11 +1086,11 @@ It must include:
</p> </p>
<ul> <ul>
<li> agreement with appropriate policies, etc </li> <li> Agreement with appropriate policies, etc. </li>
<li> contact information </li> <li> Contact information. See &sect;10.1. </li>
</ul> </ul>
<h4> <a name="9.1.4.4"> 9.1.4.4. </a> Privacy for Hard Roles</h4> <h4> <a name="9.1.4.4"> 9.1.4.4. </a> Privacy for Critical Roles</h4>
<p> <p>
The following privacy considerations exist: The following privacy considerations exist:
@ -1114,6 +1148,16 @@ and may be reversed.
Termination of access may be for resignation, Arbitration ruling, Termination of access may be for resignation, Arbitration ruling,
or decision of Board or team leader. or decision of Board or team leader.
On termination (for any reason), access and information must be secured. On termination (for any reason), access and information must be secured.
See &sect;3.4.3.
</p>
<p>
The provisions on Arbitration survive any termination
by persons fulfilling a critical role.
That is, even after a person has left a critical role,
they are still bound by the DRP (COD7),
and the Arbitrator may reinstate any provision
of this agreement or bind the person to a ruling.
</p> </p>
<h3> <a name="9.1.8"> 9.1.8. </a> HR and Training</h3> <h3> <a name="9.1.8"> 9.1.8. </a> HR and Training</h3>
@ -1188,7 +1232,13 @@ All external inquiries of security import are filed as disputes and placed befor
</p> </p>
<p> <p>
Only the Arbitrator has the authority to deal with external requests and/or create a procedure. Systems administrators, board members and other key roles do not have the authority to answer legal inquiry. The Arbitrator's ruling may instruct individuals, and becomes your authority to act. Only the Arbitrator has the authority
to deal with external requests and/or create a procedure.
Access Engineers, systems administrators,
board members and other key roles
do not have the authority to answer legal inquiry.
The Arbitrator's ruling may instruct individuals,
and becomes your authority to act.
</p> </p>
<h3><a name="9.6">9.6.</a> Outsourcing </h3> <h3><a name="9.6">9.6.</a> Outsourcing </h3>
@ -1212,7 +1262,7 @@ All arrangements must be:
under Arbitration and DRP, under Arbitration and DRP,
</li><li> </li><li>
with organisations that are Members of CAcert with organisations that are Members of CAcert
as organisational Members, as organisational Members, and
</li><li> </li><li>
under the spirit of the Principles of CAcert under the spirit of the Principles of CAcert
</li></ul> </li></ul>
@ -1239,7 +1289,7 @@ All incorporated Documents must be documented.
<h3> <a name="10.3">10.3</a> Related Documents </h3> <h3> <a name="10.3">10.3</a> Related Documents </h3>
<p> <p>
Relevant and helpdul Documents should be referenced for convenience. Relevant and helpful Documents should be referenced for convenience.
</p> </p>