sucked in section 4

git-svn-id: 14b1bab8-4ef6-0310-b690-991c95c89dfd
Ian Grigg 15 years ago
parent e5aea95353
commit cac52d9c3b

@ -46,7 +46,7 @@ Creation date: 2009-02-16<br>
Status: <i>work-in-progress</i>
<h2><a name="1">1.</a> Introduction</h2>
<h2><a name="1">1.</a> INTRODUCTION</h2>
<h3><a name="1.1">1.1.</a> Motivation and Scope </h3>
@ -105,7 +105,7 @@ Important principles of this Security Policy are:
<i>dual control</i> -- at least two individuals must control a task
<i>4 eyes</i> -- at least two individuals must be present during a task,
<i>four eyes</i> -- at least two individuals must be present during a task,
one to execute and one to observe.
<i>redundancy</i> -- no single individual is the only one authorized
@ -177,7 +177,7 @@ SystemAdministration/Procedures</a>.
Each procedure must be referenced explicitly in the Security Manual.
<h2><a target="2">2.</a> Physical Security</h2>
<h2><a name="2">2.</a> PHYSICAL SECURITY</h2>
@ -344,7 +344,7 @@ codes and devices (keys) are to be authorised and documented.
<h2><a name="3">3.</a> Logical Security</h2>
<h2><a name="3">3.</a> LOGICAL SECURITY</h2>
<h3><a name="3.1">3.1.</a> Network </h3>
<h4><a name="3.1.1">3.1.1.</a> Infrastructure </h4>
@ -513,6 +513,184 @@ Upon resignation from systems administration team, or determination by two membe
<h2> <a name="4">4. OPERATIONAL SECURITY </h2>
<h3> <a name="4.1">4.1. System administration </h3>
Primary systems administration tasks shall be conducted under four eyes principle.
These shall include
backup performance verification,
log inspection,
software patch identification and application,
account creation and deletion,
and hardware maintenance.
System administrators must pass a background check and comply with all applicable policies in force.
<h4> <a name="4.1.1">4.1.1. Privileged accounts and passwords </h4>
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
to CAcert sysadmins in all cases.
<h5> <a name=""> Authorized users </h5>
Only system administrators designated on the Access List
shall be authorized to access accounts.
<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=""> Access to </h5>
All remote communications for systems administration purposes is encrypted,
logged and monitored.
<h5> <a name=""> Changing </h5>
Passwords must be kept secure.
The procedure for changing passwords should be documented.
<h4> <a name="4.1.2">4.1.2. Required staff response time </h4>
Response times should be documented.
<h4> <a name="4.1.3">4.1.3. Change management procedures </h4>
All changes made to system configuration must be recorded.
<h3> <a name="4.2">4.2. Logging </h3>
<h4> <a name="4.2.1">4.2.1. Coverage </h4>
Logs shall be maintained for:
<li> anomalous network traffic, </li>
<li> system activities and events, </li>
<li> application (certificate, web, mail, and database) events, </li>
<li> "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>
<h4> <a name="4.2.2">4.2.2. Access and Security </h4>
Access to logs must be restricted.
The security of the logs should be documented.
The records retention should be documented.
<h4> <a name="4.2.3">4.2.3. Automated logs </h4>
Logging should be automated,
and use should be made of appropriate system-provided automated tools.
Automated logs should be reviewed periodically;
suspicious events should be flagged and investigated in a timely fashion.
<h4> <a name="4.2.4">4.2.4. Operational (manual) logs </h4>
Configuration changes, no matter how small, must be logged.
Access to this log shall be restricted.
All physical visits will be logged and a report provided by the accessor.
<h3> <a name="4.3">4.3. Backup </h3>
The procedure for all backups must be documented,
according to the following sub-headings.
<h4> <a name="4.3.1">4.3.1. Type </h4>
Backups must be taken for operational
and for disaster recovery purposes ("offline").
Disaster recovery backups must be offline and remote.
Operational backups may be online and local.
<h4> <a name="4.3.2">4.3.2. Frequency </h4>
<h4> <a name="4.3.3">4.3.3. Storage </h4>
Backups must be protected to the same level as the critical systems themselves.
Offline backups should be distributed.
<h4> <a name="4.3.4">4.3.4. Retention period and Re-use </h4>
<h4> <a name="4.3.5">4.3.5. Encryption </h4>
Backups must be encrypted and must only be transmitted via secured channels.
Off-site backups must be dual-encrypted using divergent methods.
<h4> <a name="4.3.6">4.3.6. Verifying Backups </h4>
Two CAcert system administrators must be
present for verification of a backup.
Four eyes principle must be maintained when the key and backup are together.
For any other purpose than verification of the success of the backup, see next.
<h4> <a name="4.3.7">4.3.7. Key Management </h4>
The encryption keys must be stored securely by the
CAcert systems administrators.
Paper documentation must be stored with manual backups.
<h4> <a name="4.3.8">4.3.8. Reading Backups </h4>
Conditions and procedures for examining the backups for purposes
other than for verification must be documented
and must be under Arbitrator control.
<h3> <a name="4.4">4.4. Data retention </h3>
<h4> <a name="4.4.1">4.4.1. User data </h4>
Termination of user data is under direction of the Arbitrator.
See CCA.
<h4> <a name="4.4.2">4.4.2. System logs </h4>
<h4> <a name="4.4.3">4.4.3. Incident reports </h4>
The systems administration team leader is to maintain incident reports securely.
Access to incident reports is restricted.
<h3> <a name="4.5">4.5. Cycling </h3>
<a href=""><img src="Images/valid-html401-blue.png" id="graphics2" alt="Valid HTML 4.01" align="right" border="0" height="33" width="90"></a>
<p>This is the end of the Security Policy.</p>