CAcert Security Manual [DRAFT]

Contents

Motivation and Scope
Definitions
Roles and responsibilities
Version control

PHYSICAL SECURITY

Facility
Physical assets
Physical access

LOGICAL SECURITY

Network
Operating system
1. Operating configuration
2. Patching
  1. “emergency” patching
  2. scheduled maintenance
Application
1. Development
2. Maintenance
Access control

OPERATIONAL SECURITY

System administration
Logging
1. Automated logs
2. Operational (manual) logs
Backup
Data retention

INCIDENT RESPONSE

Detection
Determination of severity
Response
Recovery from breach
Reporting

DISASTER RECOVERY

Facility disaster
Unplanned network hardware failure
Unplanned machine hardware failure
Unplanned catastrophic software failure

ADMINISTRATIVE

Staffing
Key changeover
Key generation/transfer
1. Key generation
2. Backup and recovery
Root certificate changes

LEGAL

Response to external (legal) inquiry

0.1. Motivation and Scope

This Security Manual sets out required procedures for the secure operation of the CAcert computer systems. It is a "living" document, governed by the Configuration Control Specification. Important principles of this Security Manual are dual control (no single individual is the only one authorized to perform a task) and 4 eyes (at least two individuals must be present during a task, whenever possible).

0.2. Definitions

0.3. Roles and responsibilities

System administrator: responsible for maintaining core services and integrity. Tasks include system capacity planning, 3rd party software maintenance and patching, and log monitoring for intrusion detection purposes.

0.4. Version control

This Security Manual is part of the configuration-control specification for audit purposes (DRC). It is under the control of Policy on Policy for version purposes.

1. PHYSICAL SECURITY

Physical assets and security procedures are generally provided and maintained as set forth in the Memorandum of Understanding between CAcert and Stichting Oophaga Foundation of 10 July 2007.

1.1. Facility

1.1.1. Power

1.1.2. Network connectivity

1.1.3. Catastrophic event mitigation

1.2. Physical assets

1.2.1. Computers

Computers shall be inventoried (vendor, model and serial number, maintenance contact, rack location, intended use, hostname, IP address) before being put into service. Units shall have hostname clearly marked on front and rear of chassis. Machines shall be housed in secured facilities (cages and/or locked racks).

1.2.2. Cables

Cabling to all equipment shall be labeled at both ends.

1.2.3. Media

Storage media (disk drives, tapes, removable media) shall be inventoried upon acquisition (media type, brand, capacity, vendor). Drives (whether disk or removable) shall be securely wiped and reformatted before use.

1.2.3.1. Storage

Removable media shall be securely stored at all times when not in use. Disk drives not currently in service shall also be stored in a secured location.

1.2.3.2. Destruction

Storage media to be retired from service shall be securely erased (using the 35-pass Gutmann method or an even more thorough evolution) and, whenever possible, rendered inoperable via physical means. Media not rendered inoperable shall be disposed of via a licensed disposal facility. Records of secure erasure and method of final disposal shall be tracked in the asset inventory.

1.3. Physical access

In accordance with the principle of dual control, at least two persons authorized for access must be on-site at the same time for physical access to be granted.

1.3.1. Access authorization

Authorization for physical access is provided as described in Appendix C of the 10 July 2007 CAcert-Oophaga MOU. Authorized individuals are named on the Physical and Direct internet Access and Contact List maintained by Oophaga.

1.3.2. Access logging

All physical accesses are logged and reported.

1.3.3. Emergency access

1.3.4. Changing Physical Security codes

1.3.4.1. Frequency

1.3.4.2. Safe combinations

1.3.4.3. Cipher lock combinations

2. LOGICAL SECURITY

2.1. Network

2.1.1. Infrastructure

Current and complete diagrams of the physical and logical CAcert network infrastructure shall be maintained. These diagrams should include cabling information, physical port configuration details, and expected/allowed data flow directions, as applicable. Diagrams should be revision controlled, and must be updated when any change is made.

2.1.1.1. External connectivity

Only such services as are required for normal operation should be visible externally; systems and servers which do not require access to the Internet for their normal operation must not be granted that access.

2.1.1.2. Internal connectivity

System and server connections internal to the CAcert infrastructure should be kept to the minimum required for routine operations. Any new connectivity desired must be requested and approved and then must be reflected in the appropriate infrastructure diagram(s).

2.1.2. Operating configuration

2.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.

2.1.2.2. Egress

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

2.1.3. Intrusion detection

Anomalous traffic log events should be reported to appropriate personnel in near-real-time (e.g. text message, email) and investigated as soon as possible. Network traffic logs should, in any case, be examined daily (by manual or automatic means) for unusual patterns and/or traffic; anomalies should be investigated as they are discovered. Suspicious activity which may indicate an actual system intrusion or compromise should trigger the incident response protocol described in section 5.1.

2.2. Operating system

Any operating system used for server machines must support full-disk encryption, and this encryption option must be enabled when the operating system is first installed on the machine.

2.2.1. Operating configuration

Servers must enable only the operating system functions required to support the necessary services. Options and packages chosen at OS install shall be documented, and newly-installed systems must be inspected to ensure that only required services are active. Any required application software must follow similar techniques to ensure minimal exposure footprint.

Before a machine can be placed into service, a full (encrypted) backup must be made and stored in a secure offsite location. Paper documentation of the machine configuration (operating system and any required applications) must be stored with the backup, along with the associated backup key.

2.2.2. Patching

Software used on production servers must be kept current with respect to patches affecting software security. New patches should be applied as soon as possible after vendor release. Following any substantive patch application, a full (encrypted) backup of the patched machine shall be made and stored off-site in a secure location, together with paper documentation of any configuration changes and the associated backup key.

2.2.2.1. “emergency” patching

Application of a patch is deemed an emergency when a remote exploit for a weakness in the particular piece of software has become known (on servers allowing direct local user access, an emergent local exploit may also be deemed to be an emergency). Application of patches (preferably "vendor" released) in this case may occur as soon as possible, bypassing the normal configuration-change process (but still under the 4 eyes principle, if at all possible). Such emergency patching activity must be completely documented, both in the logs and in email to the appropriate oversight entity. If at all possible, 12 hour advance notice of any related downtime should be given the community; if this is not possible, the cacert.org website (or a standin) should explain the situation.

Declaration of an emergency patching situation should not occur with any regularity.

2.2.2.2. scheduled maintenance

Application of non-emergency patches shall be governed by the Configuration Control Specification. Any associated service downtime shall be announced to the community at least 72 hours in advance. The 4 eyes principle should be used if at all possible. Patch application must be fully documented in the logs and by email to the appropriate oversight entity.

2.3. Application

this section deals with applications written in-house

2.3.1. Development

from CPS 6.6

2.3.2. Maintenance

from CPS 6.6

2.4. Access control

General user access to CAcert services shall normally be conducted through a web-based application interface; direct command-line access to systems shall only be granted via a request to a member of the Remote and Virtual Access and Contact List (OS Access List) maintained by CAcert.

2.4.1. Authorization

2.4.2. Authentication

2.4.3. Removing access

Upon separation from CAcert, or determination by two members of the OS access list that access is no longer required, an entity's access to CAcert systems may be be removed.

3. OPERATIONAL SECURITY

3.1. System administration

A minimum of 2 individuals shall be tasked with primary system administration duties, including 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 local regulations.

3.1.1. Privileged account (e.g. root) passwords

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

3.1.1.1. Authorized users

Only designated system administrators shall be authorized to access privileged accounts.

3.1.1.2. Access to

All access attempts to privileged accounts shall be logged; unsuccessful attempts should be flagged for inspection.

3.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. Note should be made in the ChangeLog whenever a privileged account password has been changed. Access to the new password(s) must occur over encrypted channels.

3.1.1.4. Frequency of change

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

3.1.2. Required staff response time

Staff must be available to respond to system events requiring physical presence within X hours; response time to events resolvable by remote means must be within Y hours.

3.1.3. Change management procedures

3.2. Logging

Logs shall be maintained for anomalous network traffic, routine system activities, application (web, mail, and database) events, root access, and configuration changes. Where possible, logging will be automated, and access to logs should be restricted as much as possible.

3.2.1. Automated logs

Logs of anomalous network traffic, routine system events, web server access and errors, mail logs, database events, direct user login attempts, and root access attempts shall be kept via appropriate system provided automated tools. Automated logs shall be treated as "write only" (when possible, logging should be sent to a central log server). Logs should be reviewed periodically (preferably daily) for anomalous events; suspicious events should be flagged and investigated in a timely fashion.

3.2.2. Operational (manual) logs

Configuration changes, no matter how small, must be logged to the central site provided (http://wiki.cacert.org/wiki/ChangeLog). Access to this log shall be strictly controlled.

3.3. Backup

Backup, distinct from archive, is performed primarily for disaster recovery purposes.

3.3.1. Frequency

Backups shall be performed:

manually, of the entire system prior to being put into production (see section 3.2.1)
automatically, for systems in production or test modes

3.3.2. Storage

Backups shall be stored in a secured area; 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.

3.3.3. Retention period

There is no requirement for backup data to be retained after the backup is not longer current (except as required for support of incident reporting, as defined in section 5; only data supporting an incident investigation need be retained).

3.3.4. Encryption

Backups should be encrypted and must only be transmitted via secured channels.

3.4. Data retention

3.4.1. User data

User data will be retained for a minimum of one year after the user has become dormant or removed themselves from the organization.

3.4.2. System logs

Logs of routine system activity (web logs, mail logs, and shutdown/startup logs) will be archived for a minimum of six months. Log excepts required for incident investigation will be, in addition, stored with the corresponding incident investigation report.

3.4.3. Facility logs

Facility logs shall be stored for a minimum of 5 years.

3.4.4. 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.

4. INCIDENT RESPONSE

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 chief priority of any incident response must be to ensure the integrity of the core services; in no case must a detected incident be allowed to progress for the purposes of tracking the culprit.

4.1. 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.

4.2. Determination of severity

Anomalous events should be classified into one of 5 severity categories:

automated probe (broad attempt to detect some common weakness)
directed probe (specific attempt to exploit a particular service)
intrusion (successful probe)
compromise (successful intrusion)
denial of service [DoS] (successful directed attempt to interfere with network connectivity to one or more core services)

Compromised services must be isolated immediately upon detection of compromise. DoS events should usually be handled by the hosting entity.

4.3. 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 compromise will require mitigation by system administration staff.

4.3.1. Intrusion

The service successfully probed should be investigated as to its necessity and a means of defending against unauthorized contact should be devised.

4.3.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.

4.3.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 within 24 hours, and of the possibility that changes may have been rolled back.

4.3.4. Private key compromise

from CPS 5.7.3

4.4. Recovery from breach

4.5. Reporting

5. DISASTER RECOVERY

from CPS 5.7

5.1. Facility disaster

5.2. Unplanned network hardware failure

5.3. Unplanned machine hardware failure

5.4. Unplanned catastrophic software failure

6. ADMINISTRATIVE

6.1. Staffing

6.1.1. Staffing levels

A minimum of 2 system administrators should be employed at any time.

6.1.2. Background check procedures

Background checks are required for individuals with privileged access to software or physical systems. An investigation should include examination of:

realm-specific knowledge (programming skills for developers; relevant OS skills for system administrators, etc)
realm-specific understanding of good security practice
community reputation
provided references

6.1.3. Termination of staff

6.2. Key changeover

from CPS 5.6

6.3. Key generation/transfer

from CPS 6.2.6

6.3.1. Key generation

Root keys should be generated on the machine where they will be used.

Root keys must be transported OpenPGP encrypted + SSH/SCP transported. The OpenPGP Key must be generated on the system that will receive the key material, the fingerprint of the public key must be written down on paper, and transported on secondary channels (telephone, ...). All network connections to transport the root keys must be SSH/SCP encrypted/tunneled.

6.3.2. Backup and recovery

The following procedure should be for backup and recovery of the root key:

Boot a secure (totally disconnected from any network, directly cabled keyboard, etc) machine in secure mode (Knoppix or other trustworthy system).
Attach a secure media (USB Stick or Floppy Disk)
Generate fresh keypair for backups (backup@cacert.org), making sure that the secret key is either generated on the secure media, or in the ramdisk and copied onto the media afterwards:
* gpg --homedir /media/usbstick --gen-key (use secure parameters (RSA, 4096))
Write down the Fingerprint of the key on paper.
Export the public key (pubring.gpg) to the local harddisk or the Internet.
Securely store the secure media with the secret keys on it.
Reboot the machine
Send the public key to the machine that needs to back up its data.
Verify the fingerprints using some out-of-band method (telephone, etc)
Setup the backup system to encrypt the backups to that public key.

Make sure that even the encrypted key is never accessible by a computer that is connected to the internet. Always unplug and reboot the systems with a secure distribution when you use the key!

Wiki

Page

User