bug 1131: Updated Policies based on new versions send by Policy Officer
[cacert-devel.git] / www / policy / SecurityPolicy.html
1 <!DOCTYPE html>
2 <html>
3 <head>
4 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" lang="en">
5 <title>Security Policy</title>
6 <style type="text/css">
7 <!--
8 body {
9 font-family : verdana, helvetica, arial, sans-serif;
10 }
11 .comment {
12 color : steelblue;
13 }
14 -->
15 </style>
16 </head>
17 <body lang="en-GB">
18 <h1>Security Policy for CAcert Systems</h1>
19 <div class="comment">
20 <table width="100%">
21 <tbody>
22 <tr>
23 <td rowspan="2">
24 Name: SP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD8</a>
25 <br>
26 Creation date: 20090216
27 <br>
28 Editor: iang
29 <br>
30 Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
31 <br>
32 Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
33 </td>
34 <td align="right" valign="top">
35 <a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
36 <img src="images/cacert-policy.png" alt="CCA Status - POLICY" style="border-style: none;" height="31" width="88">
37 </a>
38 </td>
39 </tr>
40 </tbody>
41 </table>
42
43 <h2 id="g0.1">INTRODUCTION</h2>
44
45 <h3 id="g0.1.1">Motivation and Scope </h3>
46 <p>
47 This Security Policy sets out the policy
48 for the secure operation of the CAcert critical computer systems.
49 These systems include:
50 </p>
51 <ol>
52 <li>
53 Physical hardware mounting the logical services
54 </li>
55 <li>
56 Webserver + database (core server(s))
57 </li>
58 <li>
59 Signing service (signing server)
60 </li>
61 <li>
62 Source code (changes and patches)
63 </li>
64 </ol>
65 <p>
66 The Committee of CAcert, Inc. (hereafter, "Board")
67 may add additional components into the Security Manual.
68 </p>
69
70 <h4 id="g0.1.1.1">Covered Personnel </h4>
71
72 <p>
73 Critical roles are covered.
74 These roles are defined as:
75 </p>
76
77 <ul>
78 <li>
79 Access Engineer
80 </li>
81 <li>
82 Systems Administrator
83 </li>
84 <li>
85 Support Engineer
86 </li>
87 <li>
88 Software Assessor
89 </li>
90 </ul>
91
92 <h4 id="g0.1.1.2">Out of Scope </h4>
93
94 <p>
95 Non-critical systems are not covered by this manual,
96 but may be guided by it, and impacted where they are
97 found within the security context.
98 Architecture is out of scope, see CPS#6.2.
99 </p>
100
101 <h3 id="g0.1.2">Principles </h3>
102 <p>
103 Important principles of this Security Policy are:
104 </p>
105
106 <ul>
107 <li>
108 <i>dual control</i> -- at least two individuals must control a task
109 </li>
110 <li>
111 <i>four eyes</i> -- at least two individuals must participate in a task,
112 one to execute and one to observe.
113 </li>
114 <li>
115 <i>redundancy</i> -- no single individual is the only one authorized
116 to perform a task.
117 </li>
118 <li>
119 <i>escrow</i> -- where critical information (backups, passphrases)
120 is kept with other parties
121 </li>
122 <li>
123 <i>logging</i> -- where events are recorded in a file
124 </li>
125 <li>
126 <i>separation of concerns</i> -- when a core task is split between
127 two people from different areas
128 </li>
129 <li>
130 <i>Audit</i> -- where external reviewers do checks on practices and policies
131 </li>
132 <li>
133 <i>Authority</i> -- every action is authorised by either a policy or by the Arbitrator.
134 </li>
135 </ul>
136
137 <p>
138 Each task or asset is covered by a variety of protections
139 deriving from the above principles.
140 </p>
141
142 <h3 id="g0.1.3">Definition of Terms</h3>
143 <dl>
144
145 <dt><i>Access Engineer</i> </dt>
146 <dd>
147 A Member who manages the critical hardware,
148 including maintenance, access control and physical security.
149 See §1.1.
150 </dd>
151
152 <dt><i>Software Assessor</i> </dt>
153 <dd>
154 A Member who reviews patches for security and workability,
155 signs-off on them, and incorporates them into the repository.
156 See §7.2.
157 </dd>
158
159 <dt><i>Support Engineer</i> </dt>
160 <dd>
161 A Member who mans the support list,
162 and has access to restricted
163 data through the online interface.
164 See §8.
165 </dd>
166
167 <dt><i>Systems Administrator</i> </dt>
168 <dd>
169 A Member who manages a critical system, and has access
170 to security-sensitive functions or data.
171 </dd>
172
173 </dl>
174
175 <h3 id="g0.1.4">Documents and Version control</h3>
176
177 <h4 id="g0.1.4.1">The Security Policy Document </h4>
178 <p>
179 This Security Policy is part of the Configuration-Control Specification
180 for audit purposes (DRC-A.1).
181 It is under the control of Policy on Policy for version purposes.
182 </p>
183
184 <p>
185 This policy document says what is done, rather than how to do it.
186 <b>Some sections are empty, which means "refer to the Manual."</b>
187 </p>
188
189 <h4 id="g0.1.4.2">The Security Manual (Practices) Document </h4>
190
191 <p>
192 This Policy explicitly defers detailed security practices to the
193 <a href="http://wiki.cacert.org/SecurityManual">Security Manual</a>
194 ("SM").
195 The SM says how things are done.
196 As practices are things that vary from time to time,
197 including between each event of practice,
198 the SM is under the direct control of the
199 applicable team leaders.
200 It is located and version-controlled on the CAcert wiki.
201 </p>
202
203 <p>
204 Section Headings are the same in both documents.
205 Where Sections are empty in one document,
206 they are expected to be documented in the other.
207 "Document further in Security Manual" can be implied from
208 any section heading in the Policy.
209 </p>
210
211 <h4 id="g0.1.4.3">The Security Procedures </h4>
212
213 <p>
214 The team leaders may from time to time
215 explicitly defer single, cohesive components of the
216 security practices into separate procedures documents.
217 Each procedure should be managed in a wiki page under
218 their control, probably at
219 <a href="http://wiki.cacert.org/SystemAdministration/Procedures">
220 SystemAdministration/Procedures</a>.
221 Each procedure must be referenced explicitly in the Security Manual.
222 </p>
223
224 <h2 id="g0.2">PHYSICAL SECURITY</h2>
225
226 <h3 id="g0.2.1">Facility </h3>
227
228 <p>
229 CAcert shall host critical servers in a highly secure facility.
230 There shall be independent verification of the physical and
231 access security.
232 </p>
233
234 <h3 id="g0.2.2">Physical Assets </h3>
235
236 <h4 id="g0.2.2.1">Computers </h4>
237 <p>
238 Computers shall be inventoried before being put into service.
239 Inventory list shall be available to all
240 Access Engineers and all Systems Administrators.
241 List must be subject to change control.
242 </p>
243
244 <p>
245 Each unit shall be distinctly and uniquely identified on all visible sides.
246 Machines shall be housed in secured facilities (cages and/or locked racks).
247 </p>
248
249 <h4 id="g0.2.2.2">Acquisition </h4>
250 <p>
251 Equipment for critical purposes should be acquired
252 in a way to minimise pre-acquisition security risks.
253 </p>
254
255 <h4 id="g0.2.2.3">Service </h4>
256
257 <p>
258 Equipment that is subject to a service security risk
259 must be retired if service is required.
260 See also §2.2.3.3.
261 </p>
262
263 <h4 id="g0.2.2.4">Media </h4>
264
265 <h4 id="g0.2.2.5">Provisioning </h4>
266
267 <p>
268 Storage media (disk drives, tapes, removable media)
269 are inventoried upon acquisition and tracked in their use.
270 </p>
271
272 <p>
273 New storage media (whether disk or removable) shall be
274 securely erased and reformatted before use.
275 </p>
276
277 <h4 id="g0.2.2.6">Storage </h4>
278
279 <p>
280 Removable media shall be securely stored at all times,
281 including when not in use.
282 Drives that are kept for reuse are
283 erased securely before storage.
284 Reuse can only be within critical systems.
285 </p>
286
287 <p>
288 When there is a change to status of media,
289 a report is made to the log specifying the new status.
290 </p>
291
292 <h4 id="g0.2.2.7">Retirement </h4>
293
294 <p>
295 Storage media that is exposed to critical data and is
296 to be retired from service shall be destroyed or otherwise secured.
297 The following steps are to be taken:
298 </p>
299
300 <ol>
301 <li>
302 The media is securely destroyed, <b>or</b>
303 </li>
304 <li>
305 the media is securely erased,
306 and stored securely.
307 </li>
308 </ol>
309
310 <p>
311 Records of secure erasure and method of final disposal
312 shall be tracked in the asset inventory.
313 Where critical data is involved,
314 two Systems Administrators must sign-off on each step.
315 </p>
316
317 <h3 id="g0.2.3">Physical Access </h3>
318
319 <p>
320 In accordance with the principle of dual control,
321 at least two persons authorized for access must
322 be on-site at the same time for physical access to be granted.
323 </p>
324
325 <h4 id="g0.2.3.1">Access Authorisation </h4>
326
327 <p>
328 Access to physical equipment must be authorised.
329 </p>
330
331 <h4 id="g0.2.3.2">Access Profiles </h4>
332
333 <p>
334 The Security Manual must present the different access profiles.
335 At least one Access Engineer must control access in all cases.
336 At least one Systems Administrator will be present for
337 logical access.
338 Only the most basic and safest of accesses should be done with
339 one Systems Administrator present.
340 </p>
341
342 <p>
343 There is no inherent authorisation to access the data.
344 Systems Administrators
345 are authorised to access
346 the raw data under the control of this policy.
347 All others must not access the raw data.
348 All are responsible for protecting the data
349 from access by those not authorised.
350 </p>
351
352 <h4 id="g0.2.3.3">Access Logging </h4>
353
354 <p>
355 All physical accesses are logged and reported to all.
356 </p>
357
358 <h4 id="g0.2.3.4">Emergency Access </h4>
359
360 <p>
361 There must not be a procedure for emergency access.
362 If, in the judgement of the Systems Administrator,
363 emergency access is required and gained,
364 in order to avoid a greater harm,
365 independent authorisation before the
366 Arbitrator must be sought as soon as possible.
367 See DRP.
368 </p>
369
370 <h4 id="g0.2.3.5">Physical Security codes &amp; devices </h4>
371
372 <p>
373 All personel who are in possession of physical security
374 codes and devices (keys) are to be authorised and documented.
375 </p>
376
377
378 <h2 id="g0.3">LOGICAL SECURITY</h2>
379
380 <h3 id="g0.3.1">Network </h3>
381 <h4 id="g0.3.1.1">Infrastructure </h4>
382
383 <p>
384 Current and complete diagrams of the physical and logical
385 CAcert network infrastructure shall be maintained by
386 Systems Administration team leader.
387 These diagrams should include cabling information,
388 physical port configuration details,
389 expected/allowed data flow directions,
390 and any further pertinent information,
391 as applicable.
392 Diagrams should be revision controlled,
393 and must be updated when any change is made.
394 </p>
395
396 <h5 id="g0.3.1.1.1">External connectivity </h5>
397
398 <p>
399 Only such services as are required for normal operation
400 should be visible externally;
401 systems and servers which do not require access
402 to the Internet for their normal operation
403 must not be granted that access.
404 If such access becomes temporarily necessary for an
405 authorized administrative task,
406 such access may be granted under the procedures of the SM
407 and must be reported and logged.
408 </p>
409
410 <h5 id="g0.3.1.1.2">Internal connectivity </h5>
411
412 <p>
413 System and server connections internal to the CAcert infrastructure
414 should be kept to the minimum required for routine operations. Any new
415 connectivity desired must be requested and approved by System
416 administration team leader and then must be reflected in the appropriate
417 infrastructure diagram(s).
418 </p>
419
420
421 <h4 id="g0.3.1.2">Operating Configuration </h4>
422
423 <h5 id="g0.3.1.2.1">Ingress </h5>
424
425 <p>
426 All ports on which incoming traffic is expected shall be documented;
427 traffic to other ports must be blocked. Unexpected traffic must be
428 logged as an exception.
429 </p>
430
431 <h5 id="g0.3.1.2.2">Egress </h5>
432
433 <p>
434 All outbound traffic that is initiated shall be documented; traffic to
435 other destinations must be blocked. Unexpected traffic must be logged as
436 an exception.
437 </p>
438
439 <h4 id="g0.3.1.3">Intrusion detection </h4>
440
441 <p>
442 Logs should be examined regularly (by manual or automatic means) for
443 unusual patterns and/or traffic; anomalies should be investigated as
444 they are discovered and should be reported to appropriate personnel in
445 near-real-time (e.g. text message, email) and investigated as soon as
446 possible. Suspicious activity which may indicate an actual system
447 intrusion or compromise should trigger the incident response protocol
448 described in section 5.1.
449 </p>
450
451 <h3 id="g0.3.2">Operating System </h3>
452
453 <p>
454 Any operating system used for critical server machines must be available under an OSI-approved open source software license.
455 </p>
456
457 <h4 id="g0.3.2.1">Disk Encryption </h4>
458
459 <p>
460 Any operating system used for critical server machines must support
461 software full-disk or disk volume encryption, and this encryption option
462 must be enabled for all relevant disks/volumes when the operating
463 system is first installed on the machine.
464 </p>
465
466
467 <h4 id="g0.3.2.2">Operating configuration </h4>
468
469 <p>
470 Servers must enable only the operating system functions required to
471 support the necessary services. Options and packages chosen at OS
472 install shall be documented, and newly-installed systems must be
473 inspected to ensure that only required services are active, and their
474 functionality is limited through configuration options. Any required
475 application software must follow similar techniques to ensure minimal
476 exposure footprint.
477 </p>
478
479 <p>
480 Documentation for installing and configuring servers with the
481 appropriate software packages and configurations will be maintained by
482 the System Administrators.
483 </p>
484
485
486 <h4 id="g0.3.2.3">Patching </h4>
487
488 <p>
489 Software used on production servers must be kept current with respect to
490 patches affecting software security. Patch application
491 must be approved by the Systems Administration team leader, fully
492 documented in the logs and reported by email to the Systems
493 Administration list on completion (see §4.2).
494 </p>
495
496 <h5 id="g0.3.2.3.1">“emergency” patching </h5>
497
498 <p>
499 Application of a patch is deemed an <i>emergency</i>
500 when a remote exploit for a weakness in the particular piece
501 of software has become known
502 (on servers allowing direct local user access,
503 an emergent local exploit may also be deemed to be an emergency).
504 Application of patches in this case may occur as soon as possible,
505 bypassing the normal configuration-change process.
506 The Systems Administration team leader must either approve the patch
507 or instruct remedial action, and refer the case to dispute resolution.
508 </p>
509
510 <p>
511 <b> <!-- this comment left in bold deliberately -->
512 Declaration of an emergency patching situation should not occur with any regularity.
513 </b>
514 Emergency patch events must be documented
515 within the regular summaries
516 by the team leader to Board
517 independent of filed disputes.
518 </p>
519
520 <h3 id="g0.3.3">Application </h3>
521
522 <p>
523 Requests for ad hoc queries over the application database for business
524 or similar purposes must be approved by the Arbitrator.
525 </p>
526
527 <h3 id="g0.3.4">Access control </h3>
528
529 <p>
530 All access to critical data and services shall be
531 controlled and logged.
532 </p>
533
534 <h4 id="g0.3.4.1">Application Access </h4>
535
536 <p>
537 General access for Members shall be provided via
538 a dedicated application.
539 General features are made available according to
540 Assurance Points and similar methods controlled in
541 the software system.
542 </p>
543
544 <h4 id="g0.3.4.2">Special Authorisation </h4>
545
546 <p>
547 Additional or special access is granted according to the
548 authorisations on the below access control lists
549 (see §1.1.1):
550 </p>
551
552 <table style="text-align: center" border="1">
553 <tbody>
554 <tr>
555
556 <td>List Name</td>
557
558 <td>Who</td>
559
560 <td>Purpose of access</td>
561
562 <td>Relationship</td>
563
564 <td> Manager </td>
565 </tr>
566 <tr>
567
568 <td>Physical Control List</td>
569
570 <td>Access Engineers</td>
571
572 <td>control of access by personnel to hardware</td>
573
574 <td>exclusive of all other roles </td>
575
576 <td>Access team leader</td>
577 </tr>
578 <tr>
579
580 <td>Physical Access List</td>
581
582 <td>Systems Administrators</td>
583
584 <td>hardware-level for installation and recovery</td>
585
586 <td>exclusive with Access Engineers and Software Assessors</td>
587
588 <td>Systems Administration team leader </td>
589 </tr>
590 <tr>
591
592 <td>SSH Access List</td>
593
594 <td>Systems Administrators </td>
595
596 <td>Unix / account / shell level</td>
597
598 <td> includes by default all on Physical Access List </td>
599
600 <td>Systems Administration team leader</td>
601 </tr>
602 <tr>
603
604 <td>Repository Access List</td>
605
606 <td>Software Assessors</td>
607
608 <td>change the source code repository </td>
609
610 <td>exclusive with Access Engineers and Systems Administrators</td>
611
612 <td>Software Assessment team leader</td>
613 </tr>
614 <tr>
615
616 <td>Support Access List</td>
617
618 <td>Support Engineer</td>
619
620 <td>support features in the web application</td>
621
622 <td> exclusive with Access Engineers and Systems Administrators </td>
623
624 <td>Support team leader</td>
625 </tr>
626 </tbody>
627 </table>
628
629 <p>
630 All changes of personnel to the above lists are
631 subject to Board approval.
632 </p>
633
634 <h4 id="g0.3.4.3">Authentication </h4>
635
636 <p>
637 Strong methods of authentication shall be used
638 wherever possible.
639 All authentication schemes must be documented.
640 </p>
641
642 <h4 id="g0.3.4.4">Removing access </h4>
643
644 <p>
645 Follow-up actions to termination must be documented.
646 See §9.1.7.
647 </p>
648
649
650
651
652 <h2 id="g0.4">OPERATIONAL SECURITY </h2>
653
654 <h3 id="g0.4.1">System administration </h3>
655
656 <p>
657 Primary Systems Administration tasks
658 shall be conducted under four eyes principle.
659 These shall include backup performance verification,
660 software patch application,
661 account creation and deletion,
662 and hardware maintenance.
663 </p>
664
665 <h4 id="g0.4.1.1">Privileged accounts and passphrases </h4>
666 <p>
667 Access to privileged accounts
668 (root and user via SSH or console)
669 must be strictly controlled.
670 Passphrases and SSH private keys used for entering into the systems
671 will be kept private
672 to CAcert sysadmins
673 in all cases.
674 </p>
675
676 <h5 id="g0.4.1.1.1">Authorized users </h5>
677 <p>
678 Only Systems Administrators
679 designated on the Access Lists
680 in §3.4.2 are authorized to access accounts.
681 Systems Administration team leader may temporarily permit Software
682 Assessors access to the application via SSH in order to do advanced
683 debugging, or as specifically directed by the Arbitrator.
684 </p>
685
686 <p>
687 </p>
688
689 <h5 id="g0.4.1.1.2">Access to Systems</h5>
690 <p>
691 All access is secured, logged and monitored.
692 </p>
693
694 <h5 id="g0.4.1.1.3">Changing </h5>
695
696 <p>
697 The procedure for changing passphrases and SSH keys shall be documented.
698 </p>
699
700 <h4 id="g0.4.1.2">Required staff response time </h4>
701 <p>
702 Response times should be documented for Disaster Recovery planning. See §6.
703 </p>
704
705 <h4 id="g0.4.1.3">Change management procedures </h4>
706 <p>
707 All changes made to system configuration must be recorded
708 and reported in regular summaries to the Board of CAcert.
709 </p>
710
711 <h4 id="g0.4.1.4">Outsourcing </h4>
712
713 <h3 id="g0.4.2">Logging </h3>
714
715 <h4 id="g0.4.2.1">Coverage </h4>
716
717 <p>
718 All sensitive events should be logged reliably.
719 Logs should be deleted after an appropriate amount of time
720 as documented in the Security Manual.
721 </p>
722
723 <h4 id="g0.4.2.2">Access and Security </h4>
724
725 <p>
726 Access to logs must be restricted.
727 The security of the logs should be documented.
728 The records retention should be documented.
729 </p>
730
731 <h4 id="g0.4.2.3">Automated logs </h4>
732 <p>
733 Logging should be automated,
734 and use should be made of appropriate system-provided automated tools.
735 Automated logs should be reviewed periodically;
736 suspicious events should be flagged and investigated in a timely fashion.
737 </p>
738
739 <h4 id="g0.4.2.4">Operational (manual) logs </h4>
740 <p>
741 Configuration changes, no matter how small, must be logged.
742 </p>
743
744 <p>
745 All physical visits must be logged and a
746 report provided by the accessor and by
747 the Access Engineer.
748 </p>
749
750 <h3 id="g0.4.3">Backup </h3>
751
752 <p>
753 The procedure for all backups must be documented,
754 according to the following sub-headings.
755 </p>
756
757 <h4 id="g0.4.3.1">Type </h4>
758 <p>
759 Backups must be taken for operational
760 and for disaster recovery purposes.
761 Operational backups may be online and local.
762 Disaster recovery backups must be offline and remote.
763 </p>
764
765 <h4 id="g0.4.3.2">Frequency </h4>
766
767 <h4 id="g0.4.3.3">Storage </h4>
768 <p>
769 Backups must be protected to the same level as the critical systems themselves.
770 Disaster recovery backups may be distributed.
771 </p>
772
773 <h4 id="g0.4.3.4">Retention period and Re-use </h4>
774 <p>
775 See §2.2.3.
776 </p>
777
778 <h4 id="g0.4.3.5">Encryption </h4>
779 <p>
780 Backups must be encrypted and must only be transmitted via secured channels.
781 Off-site backups must be dual-encrypted using divergent methods.
782 </p>
783
784 <h4 id="g0.4.3.6">Verifying Backups </h4>
785 <p>
786 Two CAcert System Administrators must be
787 present for verification of a backup.
788 Four eyes principle must be maintained when the key and backup are together.
789 For any other purpose than verification of the success of the backup, see next.
790 </p>
791
792 <h4 id="g0.4.3.7">Key Management </h4>
793 <p>
794 The encryption keys must be stored securely by the
795 CAcert Systems Administrators.
796 Paper documentation must be stored with manual backups.
797 </p>
798
799 <h4 id="g0.4.3.8">Reading Backups </h4>
800 <p>
801 Conditions and procedures for examining the backups
802 must be documented,
803 and must be under Arbitrator control for purposes
804 other than verification and recovery.
805 </p>
806
807 <h3 id="g0.4.4">Data retention </h3>
808
809 <h4 id="g0.4.4.1">User data </h4>
810
811 <p>
812 Termination of user data is under direction of the Arbitrator.
813 See CCA.
814 </p>
815
816 <h4 id="g0.4.4.2">System logs </h4>
817 <p>
818 See §4.2.1.
819 </p>
820
821 <h4 id="g0.4.4.3">Incident reports </h4>
822 <p>
823 See §5.6.
824 </p>
825
826
827
828
829 <h2 id="g0.5">INCIDENT RESPONSE</h2>
830
831 <h3 id="g0.5.1">Incidents </h3>
832
833 <h3 id="g0.5.2">Detection </h3>
834 <p>
835 The standard of monitoring, alerting and reporting must be documented.
836 </p>
837
838 <h3 id="g0.5.3">Immediate Action </h3>
839 <h4 id="g0.5.3.1">Severity and Priority </h4>
840 <p>
841 On discovery of an incident,
842 an initial assessment of severity and priority must be made.
843 </p>
844
845 <h4 id="g0.5.3.2">Communications </h4>
846 <p>
847 An initial report should be circulated.
848 </p>
849
850 <p>
851 A communications forum should be established for direct
852 support of high priority or high severity incidents.
853 </p>
854
855 <h4 id="g0.5.3.3">Escalation </h4>
856 <p>
857 A process of escalation should be established
858 for oversight and management purposes,
859 proportional to severity and priority.
860 Oversight starts with four eyes and ends with the Arbitrator.
861 Management starts with the team leader and ends with the Board.
862 </p>
863
864 <h3 id="g0.5.4">Investigation </h3>
865 <p>
866 Incidents must be investigated.
867 The investigation must be documented.
868 If the severity is high,
869 evidence must be secured and escalated to Arbitration.
870 </p>
871
872 <h3 id="g0.5.5">Response </h3>
873
874 <h3 id="g0.5.6">Report </h3>
875
876 <p>
877 Incident reports shall be be published.
878 The Incident Report is written on closing the investigation.
879 A full copy should be appended to the
880 documentation of the investigation.
881 Sensitive information may be pushed out into
882 a restricted appendix of the report.
883 The Systems Administration team leader is responsible
884 for publication and maintenance.
885 </p>
886
887 <p>
888 Incidents are not normally kept secret nor confidential,
889 and progress information should be published as soon as
890 possible.
891 The knowledge of the existence of the event must not be kept
892 secret, nor the manner and methods be kept confidential.
893 See §9.5.
894 </p>
895
896 <h2 id="g0.6">DISASTER RECOVERY</h2>
897
898 <p>
899 Disaster Recovery is the responsibility of the Board of CAcert Inc.
900 </p>
901
902 <h3 id="g0.6.1">Business Processes </h3>
903 <p>
904 Board must develop and maintain documentation on Business Processes.
905 From this list, Core Processes for business continuity / disaster recovery
906 purposes must be identified.
907 </p>
908
909 <h3 id="g0.6.2">Recovery Times </h3>
910 <p>
911 Board should identify standard process times for all processes,
912 and must designate Maximum Acceptable Outages
913 and Recovery Time Objectives for the Core Processes.
914 </p>
915
916 <h3 id="g0.6.3">Plan </h3>
917 <p>
918 Board must have a basic plan to recover.
919 </p>
920
921 <h3 id="g0.6.4">Key Persons List </h3>
922 <p>
923 Board must maintain a Key Persons List with all the
924 contact information needed.
925 See §10.1.
926 The list shall be accessible even if CAcert's
927 infrastructure is not available.
928 </p>
929
930
931
932 <h2 id="g0.7">SOFTWARE ASSESSMENT</h2>
933
934 <p>
935 Software assessment team is responsible
936 for the security and maintenance of the code.
937 </p>
938
939 <h3 id="g0.7.1">Authority </h3>
940
941 <p>
942 The source code is under CCS.
943 Additions to the team are
944 subject to Board approval.
945 See §3.4.2.
946 </p>
947
948 <h3 id="g0.7.2">Tasks </h3>
949 <p>
950 The primary tasks for Software Assessors are:
951 </p>
952 <ol>
953 <li>
954 Keep the code secure in its operation,
955 </li>
956 <li>
957 Fix security bugs, including incidents,
958 </li>
959 <li>
960 Audit, Verify and sign-off proposed patches,
961 </li>
962 <li>
963 Provide guidance for architecture,
964 </li>
965 </ol>
966
967 <p>
968 Software assessment is not primarily tasked to write the code.
969 In principle, anyone can submit code changes for approval.
970 </p>
971
972 <h3 id="g0.7.3">Repository </h3>
973
974 <h3 id="g0.7.4">Review </h3>
975
976 <p>
977 At the minimum,
978 patches are signed off by the team leader
979 or his designated reviewer.
980 Each software change should be reviewed
981 by a person other than the author.
982 Author and signers-off must be logged.
983 The riskier the source is, the more reviews have to be done.
984 </p>
985
986 <h3 id="g0.7.5">Test and Bugs </h3>
987
988 <p>
989 Software assessment team maintains a test system.
990 Each patch should be built and tested.
991 Test status of each patch must be logged.
992 </p>
993
994 <p>
995 Software assessment team maintains a bug system.
996 Primary communications should go through this system.
997 Management access should be granted to all Software Assessors,
998 software developers, and Systems Administrators.
999 Bug submission access should be provided to
1000 any Member that requests it.
1001 </p>
1002
1003 <h3 id="g0.7.6">Production </h3>
1004
1005 <h2 id="g0.8">SUPPORT</h2>
1006
1007
1008 <h3 id="g0.8.1">Authority </h3>
1009 <p>
1010 The software interface gives features to Support Engineer.
1011 Access to the special features is under tight control.
1012 Additions to the team are subject to Board approval,
1013 and the software features are under CCS.
1014 See §3.4.2.
1015 </p>
1016
1017 <p>
1018 Support Engineers do not have any inherent authority
1019 to take any action,
1020 and they have to get authority on a case-by-case basis.
1021 The authority required in each case must be guided
1022 by this policy or the Security Manual or other clearly
1023 applicable document.
1024 If the Member's authority is not in doubt,
1025 the Member can give that authority.
1026 If not, the Arbitrator's authority must be sought.
1027 </p>
1028
1029 <p>
1030 Support Engineers are responsible to follow the
1031 policies and practices.
1032 </p>
1033
1034 <h3 id="g0.8.2">Responsibilities </h3>
1035
1036 <p>
1037 Support Engineers have these responsibilities:
1038 </p>
1039
1040 <ul>
1041 <li>
1042 Member account recovery, as documented in the Security Manual.
1043 </li>
1044 <li>
1045 Respond to general requests for information or explanation by Members.
1046 Support Engineers cannot make a binding statement.
1047 Responses must be based on policies and practices.
1048 </li>
1049 <li>
1050 Tasks and responsibilities as specified in other policies, such as DRP.
1051 </li>
1052 </ul>
1053
1054 <h3 id="g0.8.3">Channels </h3>
1055
1056 <p>
1057 Support may always be contacted by email at
1058 support at cacert dot org.
1059 Other channels may be made available and documented
1060 in Security Manual.
1061 </p>
1062
1063 <h3 id="g0.8.4">Records and Logs </h3>
1064
1065 <ul>
1066
1067 <li> use of restricted interfaces must be logged. </li>
1068
1069 <li> all support channels should be logged. </li>
1070
1071 <li> private requests for support should be referred to proper channels and logged there (e.g., by CCs) </li>
1072 </ul>
1073
1074 <h3 id="g0.8.5">Arbitration </h3>
1075 <p>
1076 Support Engineers refer questions requiring authority
1077 to Arbitration, and may also be called upon to act as
1078 default Case Managers.
1079 See DRP and
1080 <a href="https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html">Case Manager's Handbook.</a>
1081 Support Engineers should be familiar with
1082 these topics, even if not listed as Arbitrators
1083 or Case Managers.
1084 </p>
1085
1086 <h3 id="g0.8.6">References </h3>
1087
1088
1089
1090 <h2 id="g0.9">ADMINISTRATIVE</h2>
1091
1092 <h3 id="g0.9.1">Staffing</h3>
1093
1094 <h4 id="g0.9.1.1">Roles and responsibilities</h4>
1095
1096 <ul>
1097
1098 <li> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
1099
1100 <li> System Administrator: responsible for maintaining core services and integrity. </li>
1101
1102 <li> Software Assessor: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
1103
1104 <li> Support Engineer: human interface with users.</li>
1105
1106 <li> Team leaders: coordinate with teams, report to Board.</li>
1107
1108 <li> All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.</li>
1109
1110 <li> Board: authorise new individuals and accesses. Coordinate overall. </li>
1111
1112 <li> Arbitrator: conducts ABCs. Authorises exceptions to policy. </li>
1113 </ul>
1114
1115 <h4 id="g0.9.1.2">Staffing levels</h4>
1116
1117 <p>
1118 Each team should have a minimum of two members available at any time.
1119 Individuals should not be active
1120 in more than one team at any one time,
1121 but are expected to observe the other teams.
1122 See §3.4.2 for exclusivities.
1123 </p>
1124
1125 <p>
1126 One individual in each team is designated team leader
1127 and reports to Board.
1128 </p>
1129
1130 <h4 id="g0.9.1.3">Process of new Team Members</h4>
1131
1132 <p>
1133 New team members need:
1134 </p>
1135
1136 <ul>
1137
1138 <li> Recommendation by team leader </li>
1139
1140 <li> Arbitrated Background Check ("ABC") </li>
1141
1142 <li> Authorisation by Board </li>
1143 </ul>
1144
1145 <p>
1146 The team supports the process of adding new team members.
1147 </p>
1148
1149 <h4 id="g0.9.1.4">Arbitrated Background Check - Procedures</h4>
1150 <p>
1151 The Arbitrated Background Check ("ABC")
1152 must be conducted under the direction of the Arbitrator,
1153 with a separate Case Manager to provide four eyes.
1154 ABCs are carried out with full seriousness.
1155 </p>
1156
1157 <h4 id="g0.9.1.5">Scope </h4>
1158 <p>
1159 An investigation within ABC should include examination of:
1160 </p>
1161
1162 <ul>
1163
1164 <li> realm-specific knowledge </li>
1165
1166 <li> realm-specific understanding of good security practice </li>
1167
1168 <li> history of activity within Community </li>
1169
1170 <li> reputation and standing within Community </li>
1171
1172 <li> provided references </li>
1173
1174 <li> conflicts of interest </li>
1175 </ul>
1176
1177 <h4 id="g0.9.1.6">Coverage </h4>
1178 <p>
1179 ABC is to be done on every individual in a critical role.
1180 See §1.1.1.
1181 </p>
1182
1183 <h4 id="g0.9.1.7">Documentation </h4>
1184
1185 <p>
1186 The process of the ABC should be documented as a procedure.
1187 </p>
1188
1189 <p>
1190 Documentation of each individual check should be preserved
1191 and should be reviewable under any future Arbitration.
1192 It must include:
1193 </p>
1194
1195 <ul>
1196
1197 <li> Agreement with appropriate policies, etc. </li>
1198
1199 <li> Contact information. See §10.1. </li>
1200 </ul>
1201
1202 <h4 id="g0.9.1.8">Privacy for Critical Roles</h4>
1203
1204 <p>
1205 The following privacy considerations exist:
1206 </p>
1207
1208 <ul>
1209
1210 <li> procedure and ruling (recommendation) should be public </li>
1211
1212 <li> interview, documents should not be public, </li>
1213
1214 <li> summary of evidence should be in the ruling. </li>
1215
1216 <li> Arbitrator can rule on the escrow questions of evidence </li>
1217
1218 <li> contact information goes into the contact addressbook </li>
1219 </ul>
1220
1221 <p>
1222 CAcert trusted roles give up some privacy for the privacy of others.
1223 </p>
1224
1225 <h4 id="g0.9.1.9">Authorisation </h4>
1226
1227 <p>
1228 Individuals and access (both) must be authorised by the Board.
1229 Only the Board may approve new individuals or any access to the systems.
1230 Each individual should be proposed to the Board,
1231 with the relevant supporting information as above.
1232 </p>
1233
1234 <p>
1235 The Board should deliberate directly and in full.
1236 Board members who are also active in the area should
1237 abstain from the vote,
1238 but should support the deliberations.
1239 Deliberations and decisions should be documented.
1240 All conflicts of interest should be examined.
1241 </p>
1242
1243 <h4 id="g0.9.1.10">Security</h4>
1244
1245 <p>
1246 It is the responsibility of all individuals to
1247 observe and report on security issues.
1248 All of CAcert observes all where possible.
1249 It is the responsibility of each individual to resolve
1250 issues satisfactorily, or to ensure that they are reported fully.
1251 </p>
1252
1253 <p>
1254 See §9.5.
1255 </p>
1256
1257 <h4 id="g0.9.1.11">Termination of staff</h4>
1258
1259 <p>
1260 Termination of access may be for resignation, Arbitration ruling,
1261 or decision of Board or team leader.
1262 On termination (for any reason), access and information must be secured.
1263 See §3.4.4.
1264 </p>
1265
1266 <p>
1267 The provisions on Arbitration survive any termination
1268 by persons fulfilling a critical role.
1269 That is, even after a person has left a critical role,
1270 they are still bound by the DRP (COD7),
1271 and the Arbitrator may reinstate any provision
1272 of this agreement or bind the person to a ruling.
1273 </p>
1274
1275 <h4 id="g0.9.1.12">HR and Training</h4>
1276
1277 <p>
1278 It is the responsibility of the team leaders
1279 to coordinate technical testing and training,
1280 especially of new team members.
1281 </p>
1282
1283 <h3 id="g0.9.2">Root Key Management</h3>
1284
1285 <h4 id="g0.9.2.1">Root Key generation</h4>
1286
1287 <p>
1288 Root keys are generated only on instruction from Board.
1289 They must be generated to a fully documented and reviewed procedure.
1290 The procedure must include:
1291 </p>
1292
1293 <ul>
1294
1295 <li> Use of hardware built securely for the purpose
1296 only and cleaned/erased/destroyed immediately afterwards. </li>
1297
1298 <li> Dual control over all phases, including by Board. </li>
1299
1300 <li> Strong collection of primary entropy, separated from use of entropy. </li>
1301
1302 <li> Test cycles of the process on the day. </li>
1303
1304 <li> Documentation of each step as it happens against the procedure. </li>
1305
1306 <li> Confirmation by each participant over the process and the results. </li>
1307 </ul>
1308
1309 <h4 id="g0.9.2.2">Backup and escrow</h4>
1310
1311 <p>
1312 Root keys must be kept on reliable removable media used for that purpose only.
1313 Private Keys must be encrypted and should be dual-encrypted.
1314 Passphrase must be strong and must be separately escrowed from media.
1315 Dual control must be maintained.
1316 </p>
1317
1318 <p>
1319 The top-level root must be escrowed under Board control.
1320 Subroots may be escrowed by either Board or Systems Administration Team.
1321 </p>
1322
1323 <h4 id="g0.9.2.3">Recovery</h4>
1324
1325 <p>
1326 Recovery must only be conducted under Arbitrator authority.
1327 </p>
1328
1329 <h4 id="g0.9.2.4">Revocation </h4>
1330
1331 <h3 id="g0.9.3">Legal</h3>
1332
1333 <h4 id="g0.9.3.1">Responsibility</h4>
1334
1335 <p>
1336 Board is responsible to the Community to manage
1337 the CA at the executive level.
1338 </p>
1339
1340 <h4 id="g0.9.3.2">Response to external (legal) inquiry</h4>
1341
1342 <p>
1343 All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.
1344 Board and applicable team leaders must be notified.
1345 </p>
1346
1347 <p>
1348 Only the Arbitrator has the authority
1349 to deal with external requests and/or create a procedure.
1350 Access Engineers, Systems Administrators,
1351 support engineers,
1352 Board members and other key roles
1353 do not have the authority to answer legal inquiry.
1354 The Arbitrator's ruling may instruct individuals,
1355 and becomes your authority to act.
1356 </p>
1357
1358 <h3 id="g0.9.4">Outsourcing </h3>
1359
1360 <p>
1361 Components may be outsourced.
1362 Any outsourcing arrangements must be documented.
1363 All arrangements must be:
1364 </p>
1365
1366 <ul>
1367 <li>
1368 with Members of CAcert that are
1369
1370 <ul>
1371 <li>
1372 Assurers, as individuals, or
1373 </li>
1374 <li>
1375 Assured Organisations, in which
1376 all involved personnel are Assurers,
1377 </li>
1378 </ul>
1379 </li>
1380 <li>
1381 with Members that have the requisite knowledge
1382 and in good contact with the team leader(s),
1383 </li>
1384 <li>
1385 subject to audit,
1386 </li>
1387 <li>
1388 transparent and no barrier to security,
1389 </li>
1390 <li>
1391 under this Policy and the Security Manual,
1392 </li>
1393 <li>
1394 fully under Arbitration and DRP for the purposes of Security, and
1395 </li>
1396 <li>
1397 under the spirit of the Community and within the Principles of CAcert.
1398 </li>
1399 </ul>
1400
1401 <p>
1402 Contracts should be written with the above in mind.
1403 Outsourcing of critical components must be approved by the Board.
1404 </p>
1405
1406 <h3 id="g0.9.5">Confidentiality, Secrecy </h3>
1407
1408 <p>
1409 CAcert is an open organisation and adopts a principle
1410 of open disclosure wherever possible.
1411 See <a href="https://svn.cacert.org/CAcert/principles.html">
1412 Principles</a>.
1413 This is not a statement of politics but a statement of security;
1414 if a security issue can only be sustained
1415 under some confidentiality or secrecy, then find another way.
1416 </p>
1417
1418 <p>
1419 In concrete terms,
1420 confidentiality or secrecy may be maintained only
1421 under a defined method in policy,
1422 or under the oversight of the Arbitrator
1423 (which itself is under DRP).
1424 The exception itself must not be secret or confidential.
1425 All secrets and confidentials are reviewable under Arbitration,
1426 and may be reversed.
1427 All should strive to reduce or remove any such
1428 restriction.
1429 </p>
1430
1431 <h2 id="g0.10">REFERENCES</h2>
1432
1433 <h3 id="g0.10.1">Contacts </h3>
1434 <p>
1435 Contact information for all key people and teams must be documented.
1436 </p>
1437
1438 <h3 id="g0.10.2">Documents </h3>
1439 <p>
1440 All incorporated Documents must be documented.
1441 </p>
1442
1443 <h3 id="g0.10.3">Related Documents </h3>
1444 <p>
1445 Relevant and helpful Documents should be referenced for convenience.
1446 </p>
1447
1448 <hr>
1449
1450
1451 </div>
1452 </body>
1453 </html>