@ -105,13 +99,13 @@ Important principles of this Security Policy are:
<ul><li>
<i>dual control</i> -- at least two individuals must control a task
</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.
</li><li>
<i>redundancy</i> -- no single individual is the only one authorized
to perform a task.
</li><li>
<i>escrow</i> -- where critical information (backups, passwords)
<i>escrow</i> -- where critical information (backups, passphrases)
is kept with other parties
</li><li>
<i>logging</i> -- where events are recorded in a file
@ -137,7 +131,7 @@ deriving from the above principles.
See §1.1.
</dd>
<dt><i>Software Developer </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.
@ -169,6 +163,8 @@ for audit purposes (DRC).
It is under the control of Policy on Policy for version purposes.
</p>
<palign="center">These parts are not part of the policy: <spanclass="q">green comments</span>, <spanclass="error">red errors</span>.</p>
<p>
This policy document says what is done, rather than how to do it.
</p>
@ -188,7 +184,7 @@ It is located and version-controlled on the CAcert wiki.
<p>
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.
</p>
@ -218,11 +214,13 @@ access security.
<h3><aname="2.2">2.2.</a> Physical Assets </h3>
<ulclass="q"><li>
Big question here is whether Oophaga falls inside SP/SM or not.<br>
Answered: <b>IN</b>.
Big change is to place Oophaga INSIDE the SM/SP.
</li><li>
2nd Big Question is whether Oophaga is in SP or in SM.<br>
Answered: <b>in the SM.</b>
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><aname="2.2.1">2.2.1.</a> Computers </h4>
@ -247,14 +245,14 @@ Precautions must be taken to prevent equipment being
prepared in advance.
</p>
<h4><aname="2.2.2">2.2.2.</a> Cables </h4>
<pclass="error">
Drop 2.2.2.
</p>
<h4><aname="2.2.2">2.2.2.</a> Service </h4>
<pclass="q">
Cabling to all equipment shall be labeled at both ends
with identification of end points.
<pclass="q">Wytze: new section replacing 'cables':</p>
<p>
Equipment that is subject to a service security risk
must be retired if service is required.
See also §2.2.3.3.
</p>
<h4><aname="2.2.3">2.2.3.</a> Media </h4>
@ -263,8 +261,7 @@ with identification of end points.
<p>
Storage media (disk drives, tapes, removable media)
are inventoried upon acquisition
and tracked in their use.
are inventoried upon acquisition and tracked in their use.
</p>
<p>
@ -305,7 +302,7 @@ The following steps are to be taken:
Records of secure erasure and method of final disposal
shall be tracked in the asset inventory.
Where critical data is involved,
2 system administrators must sign-off on each step.
two systems administrators must sign-off on each step.
</p>
<h3><aname="2.3">2.3.</a> Physical Access </h3>
@ -326,10 +323,11 @@ Access to physical equipment must be authorised.
<p>
The Security Manual must present the different access profiles.
At least one CAcert systems administrator will be present for
logical access to CAcert critical servers.
At least one Access Engineer must control access in all cases.
At least one systems administrator will be present for
logical access.
Only the most basic and safest of accesses should be done with
one CAcert systems administrator present.
one systems administrator present.
</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>
<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>
@ -424,7 +422,7 @@ Servers must enable only the operating system functions required to support the
</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>
@ -460,15 +458,20 @@ Emergency patch events must be documented within the regular summaries to Board.
<h3> 3.3. Application </h3>
<p>
Software development takes place on various test systems (not a critical system). See §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 §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 development.
Any changes made to source code must be referred back to software assessment team.
</p>
<h3> 3.4. Access control </h3>
<pclass="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.
</p>
@ -479,20 +482,50 @@ Direct Permissions are managed by the Application to enable special online admin
<h4> 3.4.1. Authorisation </h4>
<p>
The access control lists are:
</p>
<pclass="q"> This bit is expanded! </p>
<p>
The access control lists (see §1.1.1) are:
</p>
<tablealign="center"border="1"><tr>
<td>List Name</td>
<td>Who</td>
<td>Purpose of access</td>
<td>Relationship</td>
<td> Manager </td>
</tr><tr>
<td>Physical Control List</td>
<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>
</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>
<ul><li>
Console Access List,
for physical access by System Administrators.
</li><li>
SSH Access List,
for access to Unix-level facilities of the online webserver.
</li><li>
Support Access List,
for access to the online support interface features.
</li></ul>
<p>
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>
<p>
Termination actions must be documented,
including resignation, arbitration, or determination
by team or board.
Follow-up actions to termination must be documented.
See §9.1.7.
</p>
@ -523,46 +555,38 @@ by team or board.
Primary systems administration tasks
shall be conducted under four eyes principle.
These shall include backup performance verification,
log inspection,
software patch identification and application,
software patch application,
account creation and deletion,
and hardware maintenance.
</p>
<p>
System administrators must pass a background check
and comply with all applicable policies in force.
</p>
<h4><aname="4.1.1">4.1.1.</a> Privileged accounts and passwords </h4>
<h4><aname="4.1.1">4.1.1.</a> Privileged accounts and passphrases </h4>
<p>
Access to Accounts
(root and user via SSH or console)
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
@ -594,20 +618,6 @@ All sensitive events should be logged.
Logs should be deleted after an appropriate amount of time.
</p>
<pclass="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><aname="4.2.2">4.2.2.</a> Access and Security </h4>
<p>
@ -627,11 +637,12 @@ suspicious events should be flagged and investigated in a timely fashion.
Each team should have a minimum of 2 members available at any time.
Individuals should be active in only one team at any one time,
but may be observers on any number of teams.
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 §3.4.1 for exclusivities.
</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>
<h3><aname="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>
<li> systems administrator </li>
<li> access engineeers </li>
<li> software developer </li>
<li> software assessor </li>
<li> support </li>
<li> Board </li>
</ul>
@ -1052,11 +1086,11 @@ It must include:
</p>
<ul>
<li>agreement with appropriate policies, etc</li>
<li>contact information</li>
<li>Agreement with appropriate policies, etc.</li>
<li>Contact information. See §10.1.</li>
</ul>
<h4><aname="9.1.4.4"> 9.1.4.4. </a> Privacy for Hard Roles</h4>
<h4><aname="9.1.4.4"> 9.1.4.4. </a> Privacy for Critical Roles</h4>
<p>
The following privacy considerations exist:
@ -1114,6 +1148,16 @@ 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 §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>
<h3><aname="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>
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>
<h3><aname="9.6">9.6.</a> Outsourcing </h3>
@ -1212,7 +1262,7 @@ All arrangements must be:
under Arbitration and DRP,
</li><li>
with organisations that are Members of CAcert
as organisational Members,
as organisational Members, and
</li><li>
under the spirit of the Principles of CAcert
</li></ul>
@ -1239,7 +1289,7 @@ All incorporated Documents must be documented.
<h3><aname="10.3">10.3</a> Related Documents </h3>
<p>
Relevant and helpdul Documents should be referenced for convenience.
Relevant and helpful Documents should be referenced for convenience.
Ian Grigg
16 years ago