Contents

  1. Introduction
    1. Motivation and Scope
      1. Covered Personnel
      2. Out of scope
    2. Principles
    3. Definitions
    4. Documents and Version control
      1. The Security Policy Document
      2. The Security Manual Document
      3. The Security Procedures
  2. PHYSICAL SECURITY
    1. Facility
      1. Location and Construction
      2. Power
      3. Network connectivity
      4. Catastrophic event mitigation
      5. Rating
    2. Physical assets
      1. Computers
        1. Acquisition
      2. Service
      3. Media
        1. Provisioning
        2. Storage
        3. Retirement
    3. Physical access
      1. Access authorization
      2. Access Profiles
      3. Access logging
      4. Emergency access
      5. Physical Security codes & devices
  3. LOGICAL SECURITY
    1. Network
      1. Infrastructure
        1. External connectivity
        2. Internal connectivity
      2. Operating configuration
        1. Ingress
        2. Egress
      3. Intrusion detection
    2. Operating system
      1. Disk Encryption
      2. Operating configuration
      3. Patching
        1. “emergency” patching
    3. Application
    4. Access control
      1. Application Access
      2. Special Authorisation
      3. Authentication
      4. Removing access
  4. OPERATIONAL SECURITY
    1. System administration
      1. Privileged accounts and passphrases
        1. Authorized users
        2. Access to Systems
        3. Changing
      2. Required staff response time
      3. Change management procedures
      4. Outsourcing
    2. Logging
      1. Coverage
      2. Access and Security
      3. Automated logs
      4. Operational (manual) logs
    3. Backup
      1. Type
      2. Frequency
      3. Storage
      4. Retention period and Re-use
      5. Encryption
      6. Verifying Backups
      7. Key Management
      8. Reading Backups
    4. Data retention
      1. User data
      2. System logs
      3. Incident reports
  5. INCIDENT RESPONSE
    1. Incidents
    2. Detection
    3. Immediate Action
      1. Severity and Priority
      2. Communications
      3. Escalation
    4. Investigation
    5. Response
      1. Intrusion
      2. Operating system compromise
      3. Potential user data compromise
      4. Root key compromise
      5. Application compromise
      6. Recovery from compromise or breach
    6. Reporting
  6. DISASTER RECOVERY
      1. Notes
    2. Business Processes
      1. Core Processes
    3. Recovery Times
    4. Plan
    5. Key Persons List
  7. SOFTWARE DEVELOPMENT
    1. Authority
    2. Tasks
    3. Repository
    4. Review
    5. Test and Bugs
    6. Production
  8. SUPPORT
    1. Authority
    2. Responsibilities
      1. Support Engineers
      2. Enabling Roles
      3. Triage
      4. Support Team Leader
    3. Channels
    4. Records and Logs
    5. Arbitration
    6. References
  9. ADMINISTRATIVE
    1. Staffing
      1. Roles and responsibilities
      2. Staffing levels
      3. Process of new Team Members
      4. Background Check Procedures
        1. Scope
        2. Coverage
        3. Documentation
        4. Privacy for Critical Roles
      5. Authorisation
      6. Security
      7. Termination of staff
      8. HR and Training
    2. Root Key Management
      1. Root Key generation
      2. Backup and Escrow
      3. Recovery
      4. Revocation
    3. Legal
      1. Responsibility
      2. Response to external (legal) inquiry
    4. Outsourcing
    5. Confidentiality, Secrecy
  10. RESOURCES
    1. Contacts
      1. Key Persons Contact List
    2. Documents
      1. To Provide / find
    3. Related Documents

1. Introduction

1.1. Motivation and Scope

This Security Manual sets out required practices and procedures for the secure operation of the CAcert critical computer systems by personnel, as identified by the Security Policy (SP).

1.1.1. Covered Personnel

As in SP.

1.1.2. Out of scope

As in SP.

1.2. Principles

As in SP.

1.3. Definitions

As in SP.

1.4. Documents and Version control

1.4.1. The Security Policy Document

This Security Manual is under the control of Security Policy ("SP" or "the Policy") for compliance. The Policy says what must be done. When reading the Security Manual, it should be read side-by-side with the Policy, as every section here relies on the Policy.

I think what we could do is write a PHP script to read both the documents, and display them left and right by section numbers ...

The Security Policy is under CCS for audit purposes. SP is POLICY which is binding to the key personnel.

1.4.2. The Security Manual Document

This Security Manual ("SM" or "this Manual") is a practices document. It says how things are done. It is managed by the team leaders using this wiki for version control.

It will be reviewed for compliance with the SP, and practices and procedures documented within will be reviewed for compliance with both SP and SM.

1.4.3. The Security Procedures

SP authorises the team leaders to create procedures. These are single, cohesive components of the security practices, formed into separate documents where keeping them in the SM makes it too unwieldy. These documents have the same standing as this SM, and can be considered to be incorporated logically into the SM.

See Section 10.2 for a list of current procedures.

Where additional practices are identifed to become procedures, mark them with PROCEDURE while they are being developed here.

2. PHYSICAL SECURITY

This section is managed by the Access Team Leader. Discuss

Notes for reviewing this section Following comments are not part of SM: 

4.5.1.  Physical Security Controls

   In this subcomponent, the physical controls on the facility housing
   the entity systems are described.  Topics addressed may include:

   *  Site location and construction, such as the construction
      requirements for high-security zones and the use of locked rooms,
      cages, safes, and cabinets;

   *  Physical access, i.e., mechanisms to control access from one area
      of the facility to another or access into high-security zones,
      such as locating CA operations in a secure computer room monitored
      by guards or security alarms and requiring movement from zone to
      zone to be accomplished using a token, biometric readers, and/or
      access control lists;

   *  Power and air conditioning;

   *  Water exposures;

   *  Fire prevention and protection;

   *  Media storage, for example, requiring the storage of backup media
      in a separate location that is physically secure and protected
      from fire and water damage;

   *  Waste disposal; and

   *  Off-site backup.

2.1. Facility

Hosting is provided by BIT under contract with secure-u. See §9.4.

2.1.1. Location and Construction

The facility is a modern, purpose-built secured hosting center in Ede, Netherlands.

CPS5.1.1 refers here.

2.1.2. Power

The facility has an (expandable) 1.2 MW power connection, twin air-conditioning for 0.75 MW (expandable) and twin power backup via UPSs and diesel generators.

CPS5.1.3 refers here.

2.1.3. Network connectivity

The facility is connected to a fiber ring which provides two geographically separated connections between Ede and Amsterdam. Both in Ede and Amsterdam there are two geographically distinct endpoints, also interconnected by fiber again. Internet traffic can be exchanged at each location, through the Amsterdam Internet Exchange AMSIX (http://www.ams-ix.net).

2.1.4. Catastrophic event mitigation

The facility is 9 meter above sea level (NAP). It has these event mitigation features:

Is that it?

CPS5.1.4 refers here.

2.1.5. Rating

The datacenter is structurally and electronically secured at the BORG Class 4 level. The BORG classification is controlled by the Dutch Centre for Criminality Prevention and Security, and is defined in Nationale Beoordelingsrichtlijn BORG 2005 (only available in Dutch).

2.2. Physical assets

2.2.1. Computers

Inventory list is to state vendor, model and serial number, maintenance contact, rack location, intended use, nickname.

Working list of physical inventory:

Legal assets Inventory list is located at the Secretary of secure-u's office. To get a copy of the list, request to secure-u Board, (vorstand@secure-u.de) .

2.2.1.1. Acquisition

Acquisition of hardware opens particular security risks for well-funded attackers.

Acquisition may be done by CAcert systems administrators but the moment it enters service, the legal ownership of the hardware transfers to secure-u, and the physical control transfers to Access Engineers.

2.2.2. Service

2.2.3. Media

2.2.3.1. Provisioning

Access Engineers maintain an inventory of storage media. The inventory shall include media type and capacity.

2.2.3.2. Storage

Change of status report should include: sysadmins present, steps taken, location of storage, etc.

2.2.3.3. Retirement

Secure destruction shall include one of the following, in order of preference:

  1. rendered unreadable via physical means that destroys the platters and electronics, or,
  2. disposed of via a licensed disposal facility, or
  3. sealed and stored securely by secure-u until the data has expired. The year of expiry should be marked by CAcert systems administrator.

The detailed process is documented at SystemAdministration/Procedures/DriveRetirement.

2.3. Physical access

CPS5.1.2 refers here.

2.3.1. Access authorization

Authorization for physical access is provided as described in Appendix B of the CAcert-secure-u MoU, as updated by the respective boards.

2.3.2. Access Profiles

Physical access is only possible through secure-u's Access Engineers. At least one secure-u Access Engineer must be present. At least one CAcert Systems Administrator will be present for logical access to CAcert critical servers.

Access Engineers do not access the data.

2.3.3. Access logging

Physical accesses are logged and reported to CAcert systems administration mailing list (see §10.1). The "contact lists" documented in the MoU is understood to be subscribed to this mailing list.

Facility logs shall be kept by BIT.

2.3.4. Emergency access

According to policy, there is no procedure for emergency access. If emergency access is gained or observed, file a dispute and place the circumstances before an independent Arbitrator. This can be used to secure after-the-fact authorisation for emergencies.

2.3.5. Physical Security codes & devices

BIT controls the card access system, eye-scanner, and rack locks. Rack lock keys are registered (not permitted to be copied).

secure-u representatives on the access list have a key to the rack. BIT has a key of some form. how is the BIT key controlled?

3. LOGICAL SECURITY

This section is managed by the Critical System Administration Team Leader.

3.1. Network

3.1.1. Infrastructure

The diagrams are located where???

3.1.1.1. External connectivity

Services visible externally are:

3.1.1.2. Internal connectivity

Services internally visible are:

Non-critical systems connect with critical systems only using externally visible services as follows:

3.1.2. Operating configuration

3.1.2.1. Ingress

All ports on which incoming traffic is expected shall be documented; traffic to other ports must be blocked. Unexpected traffic must be logged as an exception.

Protocol

Port

Usage

HTTP

TCP/80

main web server

HTTPS

TCP/443

main web server in secure mode

SSH

TCP/22

only from two hosts on internal admin network; remote system maintenance

3.1.2.2. Egress

All ports to which outbound traffic is initiated shall be documented; traffic to other ports must be blocked. Unexpected traffic must be logged as an exception.

Protocol

Port

Usage

DNS

UDP/53 + TCP/53

DNS lookups by main CAcert application

SMTP

TCP/25

outgoing mail sent by main CAcert application

WHOIS

TCP/43

domain name lookup by main CAcert application

HTTP

TCP/80

web lookups, mainly for system updates

NTP

UDP/123

time synchronization with internet time servers

boxbackup

TCP/2201

only to backup.intern.cacert.org; for on-line backups

3.1.3. Intrusion detection

(iang:) this one is covered in DRC-A.5.f. which says: "The security manual describes how computer systems are configured and updated to protect them against hostile intrusion, unauthorized electronic access, and "malware" and how individuals are authorized to perform those tasks."

an actual test of this could involve injection into private ethernet by secure-u personnel.

For traffic through the Tunix-managed external firewall traffic analysis is conducted by Tunix under contract by secure-u. This service provides 24/7 monitoring. see webpage of Tunix.

For traffic directly into and out of CAcert critical servers, traffic analysis is conducted by CAcert systems administrators.

3.2. Operating system

The preferred OS for the webdb server is Debian GNU/Linux, Stable release. At some point in time the Debian project will label a newer release as its Stable release. The previously Stable release will acquire the status Oldstable release, but will continue to be maintained for one year with security patches; if a new Stable release occurs within one year of the previous one, the period of one year maintenance will be shortened. The CAcert system administrators need to upgrade the webdb server from Debian oldstable to Debian stable before the oldstable release becomes unmaintained by the Debian project. See also SystemAdministration/Systems/Webdb.

The signing server is also running the Debian GNU/Linux OS, its Debian Lenny release, which is the stable release since February 2009. Contrary to the webdb server, this server has no external connections and no external exposure; therefore it will not be upgraded to a newer release, unless it needs to be completely rebuilt at some future point in time. See also SystemAdministration/Systems/Signer.

3.2.1. Disk Encryption

See SystemAdministration/Procedures/DiskEncryption.

3.2.2. Operating configuration

When placing into service, a full (encrypted) backup must be made, as per SM§4.3. This is preferably done immediately after entering service.

3.2.3. Patching

New security patches should be applied as soon as possible after vendor release. Patches should be vendor-released and applied manually. Following any substantive patch application, a full (encrypted) backup of the patched machine shall be made, as above. Details about the operating system patch/update procedure are described in SystemAdministration/Procedures/OperatingSystemPatches

3.2.3.1. “emergency” patching

3.3. Application

The primary tasks for managing the Application are:

3.4. Access control

3.4.1. Application Access

Where possible, systems administrators should use the facilities in the general application, and should suggest changes where frequent actions could be better done via the application.

3.4.2. Special Authorisation

The access control lists are:

3.4.3. Authentication

SSH access. Access is via SSH to the hop machine located inside the network, and from there to the critical server(s). SSH Authentication keys are set on both machines, with IP# blocking enabled. Passwords are not used for systems administrator access to personal named accounts, one per sysadmin. Direct remote logins to root are not permitted. The public SSH key of each sysadmin with such access is stored in ~sysadmin/.ssh/authorized_keys on the critical server, the private SSH key needs to kept securely (i.e. protected by a passphrase on a private system) by each sysadmin with such access. Logs of SSH access are kept on the critical server(s).

Online access. By logging in to the normal account of the support team member.

3.4.4. Removing access

Upon any of these events:

a person's access to CAcert systems may be be temporarily removed. The removal is made permanent when the Board approves the change to the Access List.

4. OPERATIONAL SECURITY

This section is managed by the Critical System Administration Team Leader.

4.1. System administration

Four eyes principle is satisfied by a different systems administrator conducting regular log inspection over tasks.

4.1.1. Privileged accounts and passphrases

Direct root account access from remote connections (i.e. remote root login) is prohibited. In no circumstance must a password travel over an unencrypted channel. Other privileged accounts (database, http server, etc) should be configured as to not permit login.

Using the sudo utility is the preferred method for granting root access to designated users, either for a limited set of commands, or in general. Configuration of sudo privileges is done through /etc/sudoers, and should be done in such a way that an individual password is needed from each sysadmin login when invoking sudo.

Despite the preferred use of sudo there is still a need for root passwords, in order to allow emergency access to the system from the (physical) console. Such access should not depend on individual sysadmin logins, but the knowledge of the root passwords is restricted to members of the Console Access List (see 3.4.2.).

4.1.1.1. Authorized users

4.1.1.2. Access to Systems

Only SSH is used for access to accounts. All access attempts to accounts shall be logged; unsuccessful attempts should be flagged for inspection.

4.1.1.3. Changing

It is the duty of the system administrators to generate privileged account passwords. Changed passwords should conform to best practice regarding length and complexity. Changes should be logged to the Event Log whenever a privileged account password has been changed.

Passwords for privileged accounts must be changed on authorized user turnover or suspected compromise of the associated machine.

Details on passwords and related secrets management and changes are listed in Password Management Procedures.

4.1.2. Required staff response time

Availability to respond to system events is at best efforts.

4.1.3. Change management procedures

All changes made to system configuration must be recorded through RCS.

4.1.4. Outsourcing

DNS and OCSP may be outsourced. See Section 9.4.

This is a wip area.

4.2. Logging

CPS4.2 refers here.

4.2.1. Coverage

Logs are kept and retained as following:

type of log

minimum retention period

maximum retention period

anomalous network traffic

6 months

12 months

system activities and events

6 months

12 months

login and root access

6 months

12 months

application (certificate, web, mail, and database) events

6 months

12 months

requests for certificate signing, on both of the cryptographic module (signing server) and on the main online server

24 months

36 months

configuration changes

system life

+12 months

(daniel:) I'd mandate a central log server - a compromised server that has logs doesn't have that much integrity. Recommend that system admins only have a read-only view of the central log server. An accessible read-only view by board and system administration staff would enhance transparency.

(wytze:) I like to see this too, but not mandate it right now.

Both the cryptographic module (signing server) and the main online server must keep logs of the requests sent.

4.2.2. Access and Security

Each record should be timestamped. Logs should be treated as "write only".

Logs on the inaccessible signing server should be extracted on a timely basis for analysis. Logs of on-line critical servers should be backed up on a daily basis.

Access to logs is restricted to Systems Administrators.

Future development: logging should be sent to a central log server.

4.2.3. Automated logs

Automated logs should be reviewed preferably daily.

4.2.4. Operational (manual) logs

Configuration changes must be logged using RCS. Only systems administrators have access to the RCS log.

All visits will be logged (reported) to the Event Log including a short description of activities performed.

4.3. Backup

tie this in with section 3.2.1 CPS5.1.6 refers here.

4.3.1. Type

There are three types of backup:

4.3.2. Frequency

Backups shall be performed:

4.3.3. Storage

Disaster recovery backups shall be stored in a secured area by secure-u; access to the media must be controlled. Backup media may be reused, but must be properly disposed of (see section 2.2.3.2) at end of life.

Currently, disaster recovery backups are not distributed due to lack of resources.

4.3.4. Retention period and Re-use

PROCEDURE: A backup procedure needs to be written, including:

Under the exceptional conditions of (a) incident investigation (section 5) or (b) Arbitrator instruction, relevant backups may be examined and relevant information within may be extracted and retained for those purposes. The data must be cleaned at the end of the exception.

4.3.5. Encryption

Disaster recovery backups are dual-encrypted using encrypted file system and GPG public key.

4.3.6. Verifying Backups

After a disaster recover backup is made, it is verified before sending it to the secure storage. Verifications must be notified to the Event Log.

For operational backups, a selection of files is chosen and checked for recoverability.

Where is the restore procedure... Mendel!

4.3.7. Key Management

At least two must conduct the backup.

Paper documentation must be stored with the backup:

When systems administrators cease their authorised activity, they must hand over their keys, destroy their copies, or as directed by Arbitrator.

A copy of all root passwords, backup keys and associated passphrases is kept in one or more sealed envelopes and stored in a safe of one of CAcert's board members. When one or more stored secrets are changed, a new sealed envelope will be provided at the earliest practical moment by the System Administrator team to the board member in charge of storing these safe copies.

Added for the record: Roots/EscrowAndRecovery said: 

The passwords to encrypted disks as well root passwords for systems access are escrowed in sealed envelope with a board member, the Public Officer of CAcert Inc. This type of keys is expected to be changed periodically.

    * One white envelope (type Barional A6), sealed with transparent tape, dated 26-11-2008, signature Wytze van der Raay (crit. system admin), carries the identification marks 'backup keys' and backup@cacert.org. 

Recovery of root passwords and ssh keys from sealed envelope is by decision of the Board. Validity of keys need to be checked periodically (date of change).

And 

On 28th of November Rootkeys have been put in sealed envelopes. Sealing has been done with 3Com security tape. Envelopes have been (temporary) stored until dutch Notary arrangement is completed with CAcert Inc. president Teus Hagen in private safe.

From these two above comments:

4.3.8. Reading Backups

If an incident is detected that requires access to backups, a dispute is filed to seek authorisation. Any emergency actions are to be notified in a timely fashion to the Arbitrator.

4.4. Data retention

4.4.1. User data

On termination of an account, user data will be retained according to the direction of the Arbitrator.

4.4.2. System logs

See Section 4.2.1 for retention of System logs.

Log excerpts required for incident investigation and Arbitration will be, in addition, stored with the corresponding incident investigation report or Arbitration case file. It is the responsibility of the investigator or Arbitrator to announce the start of investigation, and to identify which logs are sensitive and therefore under his control.

In order to satisfy an investigation, logs may need to be copied and secured on a separate drive only for the investigation.

4.4.3. Incident reports

Completed incident reports shall be retained indefinitely in a secure location. If sensitive data is present in a retained report, any retained electronic version of the report (or any electronic data appended to the report) shall be encrypted.

5. INCIDENT RESPONSE

This section is managed by ??? Discuss. CPS 5.7 refers to here.

5.1. Incidents

There are several levels:

  1. Tunix firewall 24/7 port control & monitoring and unencrypted traffic analysis.

  2. Webserver firewall port control & monitoring.

  3. Application controls.
  4. Signing server.

All of these levels generate logs.

5.2. Detection

Logs must be examined for anomalies at least weekly; where possible, automated anomalous detections monitors should alert appropriate individuals in near-realtime when unusual events are detected. One individual shall be designated as the primary log monitor, responsible for a level of familiarity with the logs sufficient to detect new suspected anomalies and update the automated detectors.

5.3. Immediate Action

5.3.1. Severity and Priority

Severity. Anomalous events should be classified into one of these severity categories:

  1. undirected failure (corruption by software)
  2. probe
    1. automated probe (broad attempt to detect some common weakness)
    2. directed probe (specific attempt to exploit a particular service)
  3. intrusion (successful perversion of controls)
    1. exploit, no loss
    2. compromise, possibility of losses of sensitive data or certificate issuance
    3. breach, positive evidence of data loss
  4. denial of service [DoS] (successful directed attempt to interfere with network connectivity or other availability to one or more core services)

Priority. The priority of any incident response is to ensure the integrity of the core services and safety of data assets above all else. Compromised services must be isolated immediately upon detection of compromise. Incidents must be terminated immediately on detection, and must not be be allowed to continue under any circumstances (including for the purposes of tracking a culprit).

5.3.2. Communications

Warning. As soon as an event is detected, an initial report of breach or compromise should be sent to:

The precise CC list is determined by the judgment of the Member on the spot, and each Member notified may forward the report more widely. Followups can occur as more information evolves.

War room. Establish a chat room (e.g., IRC or skype) for immediate supporters (e.g., other sysadms, secure-u, Board, Arbitrator). Turn on logging. Several rooms may be helpful when focus is required. DoS events should usually be handled by the hosting and firewall entities, via secure-u MoU, so establish contact with them. Contact with secure-u and its contracted agencies is defined in the MoU, including email addresses. Check websites for emergency phone numbers of contracted agencies.

5.3.3. Escalation

In the event of intrusion or worse, separated oversight and authority for emergency actions must be established.

Oversight. If team authorities do not meet the need, file dispute and place the oversight before the Arbitrator. Oversight is there to approve and authorise the actions, and in an extreme situation, direct alternatives. If data is compromised, Arbitration is required.

Management. The team leader should be brought into the communications loop. If not available, or as decided by the team leader, include the Board (its designated Board member. Management is focussed on blow-by-blow decisions on how to deal with the situation.

Management and Arbitration are not contradictory, but instead work together.

5.4. Investigation

Any anomalous event (lack of response from a service or services, unanticipated overuse of resources, etc) shall be fully investigated as soon as possible. Should the investigation indicate that a security breach may have occurred, evidence must be preserved in as close to pristine condition as is possible and any related log data archived.

The following should be checked:

5.5. Response

Corrective action taken in response to an anomalous event shall be appropriate to the event's severity classification. In general, only events classified as intrusion or worse will require mitigation by system administration staff.

5.5.1. Intrusion

The service successfully probed should be investigated:

5.5.2. Operating system compromise

In the event of a compromise due to an operating system vulnerability, the compromised system must be isolated from external network contact and forensically examined, with all relevant logs archived. In the case where logs have been destroyed by malicious activity, log backups should be consulted to determine the timing and method of the compromise.

Once the investigation has revealed the intrusion vector, the operating system should be completely wiped and reinstalled from a known-good reference backup, any known vulnerabilities (especially the exploited one(s)) patched, and all local passwords and key-pairs changed, and a new known-good reference backup made before the system can be returned to service.

5.5.3. Potential user data compromise

User data should not exist other than in the databases; should the integrity of a database become suspect, it must be removed from service until the precipitating incident has been investigated, appropriate counter-measures taken, and the database rolled back to a known-good state. All affected users must be notified of the breach, and of the possibility that changes may have been rolled back.

5.5.4. Root key compromise

If a root key is compromised:

  1. It is taken off line, including any subroots.
  2. It is revoked
    • via CRL (subroots) or,
    • via notification to vendors (root only). See Section 9.2.4.
  3. New root key procedure is invoked. See Section 9.2.1.
  4. New root key is installed.
  5. Certificates are revoked and Members notified to issue new certificates.

(in above, subroot applies if applicable.)

5.5.5. Application compromise

When an application is compromised:

  1. developer is contacted.
  2. relevant logs, code, files are escrowed, as advised by developer.
  3. emergency patches are made, as advised.

(in above, vendor applies as developer if applicable.)

5.5.6. Recovery from compromise or breach

Once the damage is assessed and compromise or breach is indicated, confer with the Arbitrator for recovery procedures.

5.6. Reporting

Report. A final report should be created on the wiki and notified to all effected parties (sysadms, Board, software development, secure-u, user victims). It should include:

Reports should be referenced from SecurityManual/IncidentReports/

Secrecy. Events should not be kept secret unless there is a clear and present danger to users of additional immediate loss. Any confidentiality will severely limit the ability of other members to help resolve the issues, and in general will do more harm than good. Any secret event must be placed under the Arbitrator. The event itself should not be kept secret, but the details of the hack may be embargoed. It should be immediately filed as a dispute so as to establish oversight and confirmation of the decision to keep details under wraps.

Disclosure of breaches and bugs should be done as soon as possible. Embarrassment is not an issue, nor is scaring people away. If necessary, designate a non-essential Member to listen on the forums just for preparing disclosure information.

6. DISASTER RECOVERY

This section is managed by who ?? Discuss.

TBD.

work-in-progress.

The process described below follows the CISA view.

6.0.1. Notes

6.1. Business Processes

The board maintains BusinessProcesses.

6.1.1. Core Processes

DisasterRecovery sets the core processes as:

  1. critical systems
  2. OCSP/CRL servers

6.2. Recovery Times

DisasterRecovery sets the recovery time for revocation services at 27 hours.

6.3. Plan

  1. Notification goes to the key persons list.
  2. Board makes initial assessment of team needed and notifies team.
  3. Disaster Recovery team converges.
  4. Planning and response.

6.4. Key Persons List

The board designates a trusted team of core participants, including:

A document is held by all members of this team with all the relevant contact information for each member of the team. The detailed layout, management, distribution and updating of this document is documented in Key Persons List Procedure.

7. SOFTWARE DEVELOPMENT

This section is managed by the Software Assessment Team Leader.

Refs to other documents:

7.1. Authority

Software development team leader is responsible for the security of the code.

7.2. Tasks

The primary task is to audit and verify the code, not to write the code. In principle, anyone can submit code changes for approval.

Additional tasks, where time is available, include:

7.3. Repository

The integrity of the central version control system is crucial for the integrity of the applications running on the critical systems, so the system hosting the version control system needs to be carefully managed (but data encryption is not applicable to this type of system).

Seems odd. Is that a statement that this is a critical system or not?

7.4. Review

The Software Asessment Team is responsible to advance patches that have been submitted by the developers of the CAcert community. The Software Assessment Team will take care that all patches forwarded to the Quality Assurance Team follows the CAcert coding guidelines and contains sufficient instructions to be applied to a test system. The Software Assessment Team forwards the patches submitted by the developers to the Quality Assurance Team which will test if the changes do as desired.

7.5. Test and Bugs

Current test system is maintained at SystemAdministration/Systems/Test. Bug communications system is maintained at https://bugs.cacert.org/.

Accounts are available on both systems on request to Members (Assurer level) after a small degree of checking.

Small degree... what does that mean?

7.6. Production

Production is a work-in-progress:

After a positive feedback from the Quality Assurance Team the Software Assessors will forward the patches into a new revision and prepare a build for the sysadmins so they can apply those changes to the production system.

Delivering a patch or upgrade to the systems administration team is a major undertaking and will require the availability of both teams for a period of time.

8. SUPPORT

This section is managed by the Support Team Leader.

8.1. Authority

The board appoints the Support team leader to lead the support team. m20100222.1

Software for storing Member information (aka the website) is generally under the control of CCS, see DRC-A.1.i. Also, software for "communicating with subscribers and with the general public" is specified as being under control.

Iang: to date, CAcert has operated two forms of software for communicating with subscribers and the general public.:

  1. Firstly, the website, which includes its website display, and a member email database for formal communications. The latter email database is only used under control of the software, and under Arbitration control, both of which are under CCS.

  2. Secondly, the "infrastructure" group of servers: wiki, mail, blog, lists. These are not under the control of audit, DRC, CCS and Security Policy. This latter group includes the support tools of mailbox (old) and OTRS at issue.cacert.org (new).

Authority for each action by a Support Engineer is provided by:

8.2. Responsibilities

8.2.1. Support Engineers

Support Engineers ("SEs") do the following:

8.2.2. Enabling Roles

The SE is responsible for enabling roles when given authority.

There are these roles:

  1. location role

    • allows the user to change the location database
    • provided by an extra menu entry

  2. admin role:

    • this is the role routinely given to SEs.
    • basic access to accounts, can see more of the user's potentially private information,
    • gives extra menus
    • view of the accounts
    • change the DoB, Name, password
    • remove an assurance (cannot change points)
    • set flags:
      • O-Admin flag on the account
        • enables create new Org accounts
        • which gives extra menus to manage OA
      • set the code-signing flag
        • enables the user to request code-signing certificates

        • controlled by CPS4.2.6, which states that "Code-signing certificates are made available to Assurers only."

        • should file a bug to get a change in the software to make this automatic?
        • or, for now, practice should be for Support only to set the code-signing flag on Assurers.
      • lock the account from doing assurances
      • lock the account from logging in
      • enable Tverify assurance process for the user
      • set Admin role (any administrator with Admin role set can do this)
      • Org Administrator
      • set the TTP flag

  3. Tverify role

    • allows the user to add more points???? not tested
  4. "delete account" just flags the account as unaccessable
    • to really delete, must scramble the data

  5. advertising role

  6. TTP role

    • ask Robert how the TTP role works

    • need 200 "old points"

  7. Organisation Assurer ("OA") role

    • OA creates Org Account
      • Org-Assurer flag???? check name
    • Process:
      • OA adds the domains
      • OA adds the O-Admins of the organisation to the Org Account
      • support sends a mail to the O-Admins to ask if they have the new menus to create org certs.

  8. Organisation Administrator ("O-Admin") role

    • Any O-Admin can issue certificates, acting for the organisation
    • O-Admin with 50 Assurance Points can be flagged as a MASTER
    • As MASTER they can also add new sub-Admins

    • bug, all O-Admins need to be Assurers according to AP or OAP.

8.2.3. Triage

Support Team Leader appoints and manages a team of first responders, known as Triage. The role is strictly limited to analysing incoming support requests and forwarding them to appropriate places. No access to special features is given.

Members of Triage must be Assurers, and must agree to be covered by Security Policy and this manual, however no ABC is currently required. The information seen and actions taken are approximately similar to those of Assurers. Triage is considered to be a training step towards Support Engineer and other roles within CAcert.

8.2.4. Support Team Leader

Support Team leader is responsible for:

8.3. Channels

Incoming communication occurs over these methods:

Triage may forward communications coming into support@ to these channels:

SEs currently maintain a semi-private room on IRC at #se for all support members, and a private mailing list cacert-support-engineer@.

The systems mentioned (mailbox, OTRS, IRC, open help forum maillist) above are "infrastructure" systems maintained on VMs by the infrastructure team. They are not currently designated by Board as "critical systems" and are therefore not strictly under Security Policy.

Support Engineers have access via the website support features as authorised under section 3.4.2. Triage have no such access.

8.4. Records and Logs

Each instruction from the Arbitrator should come with a TOKEN.

All support channels should be logged.

8.5. Arbitration

Arbitration is a major responsibility of the support team:

Team leader is responsible for reviewing decisions to file, and decisions not to file.

8.6. References

9. ADMINISTRATIVE

This section is managed by the Board.

9.1. Staffing

9.1.1. Roles and responsibilities

Additional tasks include:

9.1.2. Staffing levels

Each team should be at least 3 people, and preferably more. The team leader should participate directly in the recruiting effort. As the team gets larger, the team leader does less active "hands-on" work and more coordination and team building.

9.1.3. Process of new Team Members

The general process is:

  1. team proposes someone to join
  2. team does preparation and interview
  3. background check is initiated by filing dispute to Arbitration
  4. Arbitration Ruling plus recommendation presented to board for appointment
  5. Board approves.
  6. Team cycles new person in.

9.1.4. Background Check Procedures

The Background Check is initiated by filing dispute, naming the person concerned as respondent. This uses Arbitration as an administrative step and does not imply there is a "dispute" alleged against the person. An Arbitrator who is independent of the persons, but experienced in the field, should be chosen. A Case Manager should support, and fills a four eyes role.

The Background Check is conducted under the direction of the Arbitrator. Therefore the Background Check Procedure is primarily under the control of the Arbitrator, and changes initiated by others should be done in consultation.

The Background Check Procedure is managed by the Arbitrator.

9.1.4.1. Scope

An investigation should include examination of:

9.1.4.2. Coverage

The interview should signal which policies are agreed to, and ask about any reservations the candidate may have.

9.1.4.3. Documentation

The Arbitrator collects and maintains the documentation after the ruling.

The Arbitrator must collect a legally binding agreement from the candidate to the policies and procedures in force, for purposes of normal security (including non-disclosure, confidentiality, privacy and/or a task-specific contracts). The method of collecting the binding agreement is (at the present time) left up to the Arbitrator.

Background checks are supported by the teams, or by anyone as directed by the Board.

9.1.4.4. Privacy for Critical Roles

9.1.5. Authorisation

9.1.6. Security

Security issues should be reported to team leader and filed as a security bug. If unsatisfactorily resolved, report the filed bug to Board or file as a dispute. Team leaders must not stand in the way of escalation, and should encourage active observation by members, and escalations on uncertain issue so that practice is gained. Without the confidence to escalate, members may be too hesitant when they need to be more vocal.

9.1.7. Termination of staff

The following steps must be taken:

  1. SSH public keys of that person are blocked.
  2. major secrets are changed (e.g., root passwords, server SSH keys)
  3. minor passwords are analysed for sensitivity (e.g., database passwords)
  4. accounts, record of activities, etc, are escrowed.
  5. copies of escrowed root keys or backups are secured.

Team leaders should also ensure 1,2 above where individuals are transferring activity from one team to another.

9.1.8. HR and Training

The existing team tests for technical knowledge. Quasi-formal qualifications on security are considered but are not required. Some roles are more extensively grilled on security practices.

Note: there should be training and (CATS) tests for some parts of this process.

9.2. Root Key Management

9.2.1. Root Key generation

The Procedure for Key Generation is located at Roots/CreationCeremony.

9.2.2. Backup and Escrow

Media. Dual USB sticks should be used for escrow of root keys (two USB sticks for reliability, taped together). Dual encryption should be used, being file system and OpenPGP. Passwords must be generated automatically and transferred to paper manually.

For Subroots, Systems Administration Team Leader escrows copy. Passwords are held by Team Members. For disaster recovery purposes, both Subroots and accompanying passwords are also escrowed by the board in the same way as the top-level root.

Board to advise on how top-level root is escrowed.

Note: there is still the outstanding issue of the CRLs needing to be produced in a reasonable time using the top-level root to sign CRL over subroots.

9.2.3. Recovery

Procedure for Recovery of roots from Backup and Escrow (above) should be located at Roots/EscrowAndRecovery.

but not as yet written.

9.2.4. Revocation

Revocation is authorised by the Board or by the Arbitrator, see Section 5, 6.

Method. Contact each vendor and file a bug to request the root to be marked "untrusted" in the vendor's root list. Be prepared to confirm a request for acknowledgement via a secure channel.

Notes:

9.3.1. Responsibility

The board is the ultimate responsible party for legal affairs.

9.3.2. Response to external (legal) inquiry

You do not have the authority to answer inquiries of security or legal import. The Arbitrator's ruling may instruct you, and becomes your authority to act. This provision is very strong, and exists for your own protection as well as the protection of the entire community of Members.

Social engineering may be used against you to breach this rule. Notify your team leader and/or security officer of any requests that go outside formal channels, even trivial ones.

We probably need a social engineering procedures/manual here.

9.4. Outsourcing

Physical assets and hosting are generally provided and maintained as set forth in the Memorandum of Understanding between CAcert and secure-u of 24 June 2013, and as amended from time to time. Approval of both boards of CAcert and secure-u is required for changes to the MoU. Please note that prior to the MoU between CAcert and secure-u, a very similar MoU was in force between CAcert and Stichting Oophaga, originally agreed upon on 10 July 2007, and last amended on 9 June 2009. All these documents can be found here: svn CAcert_Inc/hosting.

The MoU places responsibility for the physical assets (hardware), hosting and for control of access to the hardware with secure-u.

secure-u places the hosting contract with BIT, Ede.

9.5. Confidentiality, Secrecy

CAcert critical roles give up some privacy so as to preserve the privacy of others.

10. RESOURCES

10.1. Contacts

Note: All mailing lists are currently run on "infrastructure" machines which are non-critical. Watch this.

10.1.1. Key Persons Contact List

The procedure for maintaining and distributing the key persons private contact list is documented in SystemAdministration/Procedures/KeyPeopleContacts.

10.2. Documents

  1. The Security Policy is under CCS for audit purposes.

  2. MoU with secure-u is located in svn CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf

List of Procedures:

  1. CategoryProcedures
  2. Community/HomePagesMembers/EvaStöwe/KPL_process
  3. Roots/CreationCeremony
  4. SecurityManual
  5. SecurityManual/CZ
  6. Software/Assessment/Documentation/EmergencyPatches
  7. SystemAdministration
  8. SystemAdministration/Procedures/CertificateIssuing
  9. SystemAdministration/Procedures/DNSChanges
  10. SystemAdministration/Procedures/DiskEncryption
  11. SystemAdministration/Procedures/DiskMirroring
  12. SystemAdministration/Procedures/DriveRetirement
  13. SystemAdministration/Procedures/FirewallChanges
  14. SystemAdministration/Procedures/FullBackupRestore
  15. SystemAdministration/Procedures/InfrastructureTeam
  16. SystemAdministration/Procedures/KeyPeopleContacts
  17. SystemAdministration/Procedures/KeysEscrow
  18. SystemAdministration/Procedures/OcspResponder
  19. SystemAdministration/Procedures/OperatingSystemPatches
  20. SystemAdministration/Procedures/PasswordManagement
  21. SystemAdministration/Procedures/SoftwarePatches

10.2.1. To Provide / find

SecurityManual (last edited 2016-11-06 12:14:22 by AlesKastner)