|
|
|
|
@ -48,6 +48,7 @@ a:hover {
|
|
|
|
|
<body lang="en-GB">
|
|
|
|
|
|
|
|
|
|
<ul class="change">
|
|
|
|
|
<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>
|
|
|
|
|
@ -643,7 +644,7 @@ and hardware maintenance.
|
|
|
|
|
|
|
|
|
|
<h4 id="s4.1.1">4.1.1. Privileged accounts and passphrases </h4>
|
|
|
|
|
<p>
|
|
|
|
|
Access to Accounts
|
|
|
|
|
Access to <span class="change">privileged</span> accounts
|
|
|
|
|
(root and user via SSH or console)
|
|
|
|
|
must be strictly controlled.
|
|
|
|
|
Passphrases and SSH private keys used for entering into the systems
|
|
|
|
|
@ -1064,7 +1065,7 @@ See §3.4.2.
|
|
|
|
|
<p>
|
|
|
|
|
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 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 clearly
|
|
|
|
|
applicable document.
|
|
|
|
|
@ -1085,7 +1086,7 @@ Support Engineers have these responsibilities:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul><li>
|
|
|
|
|
Account Recovery, as documented in the Security Manual.
|
|
|
|
|
<span class="change">Member</span> account recovery, as documented in the Security Manual.
|
|
|
|
|
</li><li>
|
|
|
|
|
Respond to general requests for information or explanation by Members.
|
|
|
|
|
Support Engineers cannot make a binding statement.
|
|
|
|
|
@ -1142,6 +1143,7 @@ or Case Managers.
|
|
|
|
|
<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>
|
|
|
|
|
<li class="change"> Arbitrator: conducts ABCs. Authorises exceptions to policy. </li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h4 id="s9.1.2"> 9.1.2. Staffing levels</h4>
|
|
|
|
|
@ -1200,6 +1202,7 @@ An investigation within ABC should include examination of:
|
|
|
|
|
<h4 id="s9.1.4.2"> 9.1.4.2. Coverage </h4>
|
|
|
|
|
<p>
|
|
|
|
|
ABC is to be done on every individual in a critical role.
|
|
|
|
|
<span class="change">See §1.1.1.</span>
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h4 id="s9.1.4.3"> 9.1.4.3. Documentation </h4>
|
|
|
|
|
@ -1248,7 +1251,10 @@ with the relevant supporting information as above.
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The Board should deliberate directly and in full.
|
|
|
|
|
Board members who are also active in the area should recuse from the vote,
|
|
|
|
|
Board members who are also active in the area should
|
|
|
|
|
<span class="strike">recuse</span>
|
|
|
|
|
<span class="change">abstain</span>
|
|
|
|
|
from the vote,
|
|
|
|
|
but should support the deliberations.
|
|
|
|
|
Deliberations and decisions should be documented.
|
|
|
|
|
All conflicts of interest should be examined.
|
|
|
|
|
|
Ian Grigg
14 years ago