#pragma section-numbers 1 ## 20161106 AK ---- [[SecurityManual/CZ|česky]] | '''english''' ---- || ''' CAcert Security Manual ''' || || [[https://www.cacert.org/policy/SecurityPolicy.html|Security Policy]] is {{https://www.cacert.org/policy/images/cacert-policy.png}} [[PolicyDecisions#p20140731|p20140731]] || || which means SP and this Security Manual is binding over entire community || <> ---- == Introduction == <> === 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 [[https://www.cacert.org/policy/SecurityPolicy.html|Security Policy (SP)]]. ==== Covered Personnel ==== As in SP. ==== Out of scope ==== As in SP. === Principles === As in SP. === Definitions === As in SP. * Event Log - This is the email list cacert-systemlog@lists.cacert.org who's archive is accessible at https://lists.cacert.org/wws/arc/cacert-systemlog === Documents and Version control === ==== 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 [[https://www.cacert.org/policy/SecurityPolicy.html|Security Policy]] is under [[https://www.cacert.org/policy/ConfigurationControlSpecification.html|CCS]] for audit purposes. SP is POLICY which is binding to the key personnel. ==== 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. ==== 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. ---- == PHYSICAL SECURITY == This section is managed by the Access Team Leader. ''Discuss'' '' Notes for reviewing this section Following comments are not part of SM:'' * ''Need secure-u to answer these questions.'' * [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p5.1|CPS5.1]] passes to here. * ''[[http://tools.ietf.org/html/rfc3647#section-4.5.1|Chokhani et al]] talks about:'' {{{ 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. }}} * ''however these above are suggestions, not requirements'' * ''these below are requirements from DRC:'' * A.5.a ''The CA maintains documentation of its procedures to ensure the electronic and physical security of its operations. '' * A.5.c ''The security manual describes how individuals are authorized to access computer equipment.'' * A.5.d ''The security manual describes how individuals are authorized to change...'' * A.5.e ''describes the security of physical equipment. The following shall be addressed:'' * personnel restrictions on access to cryptographic hardware * logging access to secure containers * frequency of changing combinations, cipher locks, etc. * A.5.g ''describes how computer systems and other hardware are protected against theft and unauthorized physical access.'' * http://audit.cacert.org/drc/browser.php === Facility === Hosting is provided by BIT under contract with secure-u. See §9.4. ==== Location and Construction ==== The facility is a modern, purpose-built secured hosting center in Ede, Netherlands. CPS5.1.1 refers here. ==== 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. ==== 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). ==== Catastrophic event mitigation ==== The facility is 9 meter above sea level (NAP). It has these event mitigation features: * fire detection system features very intelligent early warning. * a halon fire prevention system, * access control system to building and hosting room based on iris-scanning cameras and magnetic access card. * locked rack * crashfence, breezeblock walls, safe-style entrance door to hosting room * lightning protection according to NEN 1014 Class LP4 ''Is that it?'' CPS5.1.4 refers here. ==== Rating ==== The datacenter is structurally and electronically secured at the BORG Class 4 level. The BORG classification is controlled by the [[http://www.hetccv.net|Dutch Centre for Criminality Prevention and Security]], and is defined in [[http://www.hetccv.nl/binaries/ccv/dossiers/kwaliteitsregelingen-en-instrumenten/ccv-regelingen/borg/brl-borg-2005-versie-2-_mei-2007.pdf|Nationale Beoordelingsrichtlijn BORG 2005]] (only available in Dutch). === Physical assets === ==== Computers ==== Inventory list is to state vendor, model and serial number, maintenance contact, rack location, intended use, nickname. Working list of physical inventory: * [[SystemAdministration/CableIndex]] * [[SystemAdministration/EquipmentList]] * ''{changes should be controlled in some fashion.}'' 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) . * ''there is an open request to see this list.'' * ''there should be a routine for syncronising the working list with the legal list.'' ===== Acquisition ===== Acquisition of hardware opens particular security risks for well-funded attackers. * Acquisition of new equipment should be done from a long-term commercial business. Use a vendor with a high turnover of stock. * The nature of the purchase should not be revealed before taking delivery of the equipment (purpose, relevant names, time of purchase). * Units should be selected randomly. * Record in the log and in [[SystemAdministration/EquipmentList|inventory]]: vendor, method of the purchase, brand & type, performance/capacity statistics. * Units sent back for repair are considered compromised. 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. ==== Service ==== * ''This was Cables, but Cables are swallowed into "Computers" above.'' * ''this one does need to be filled in ...'' ==== Media ==== ===== Provisioning ===== Access Engineers maintain an inventory of storage media. The inventory shall include media type and capacity. ===== Storage ===== Change of status report should include: sysadmins present, steps taken, location of storage, etc. ===== Retirement ===== Secure destruction shall include one of the following, in order of preference: a. rendered unreadable via physical means that destroys the platters and electronics, or, a. disposed of via a licensed disposal facility, or a. 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]]. === Physical access === ''CPS5.1.2 refers here.'' ==== Access authorization ==== Authorization for physical access is provided as described in Appendix B of the CAcert-secure-u [[https://svn.cacert.org/CAcert/CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf|MoU]], as updated by the respective boards. ==== 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. * web+db server(s): one Access Engineer and one systems administrator. * signing server: For simple maintenance actions, at least one Access Engineer and at least one systems administrator will be present. The Access Engineer will overview commands given at the signing server system console by the systems administrator in order to check whether operations performed are indeed simple maintenance actions, and raise a flag (both locally and later on the mailing list) when this is not the case. Simple maintenance actions include things like: * hookup console access * hookup USB backup disk * perform encrypted backup to USB backup disk (brought in from safe storage and afterwards taken back to safe storage by secure-u) * reboot server, including file system checks * restart protocol software between signing server and webserver * adjust date/time of server * compress log files * signing server: For complex maintenance actions, at least three persons authorized for access must be on-site: one Access Engineer and two systems administrators. This is dual control over physical access and four eyes over logical access. The Access Engineer must enforce the presence of the two Systems Administrators. * for access to the physical networking or cabling, one Access Engineer and either another Access Engineer or a systems administrator. * non-critical servers: one Access Engineer and one systems administrator. Access Engineers do not access the data. ==== 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. ==== 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. ==== 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?'' ---- ---- ---- ---- == LOGICAL SECURITY == This section is managed by the Critical System Administration Team Leader. === Network === ==== Infrastructure ==== The diagrams are located ''where???'' ===== External connectivity ===== Services visible externally are: * http://www.cacert.org/ * https://www.cacert.org/ * https://secure.cacert.org/ * https://tverify.cacert.org/ ===== Internal connectivity ===== Services internally visible are: * SSHD Non-critical systems connect with critical systems only using externally visible services as follows: * [[SystemAdministration/Systems/Cats|Cats]] updates the web+db with CATS tests results using a HTTPS POST to the url https://secure.cacert.org/cats/cats_import.php ==== Operating configuration ==== ===== 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|| ===== 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|| ==== 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. === Operating system === The preferred OS for the webdb server is [[http://www.debian.org/releases/stable|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 [[http://www.debian.org/releases/Oldstable|Oldstable release]], but will continue to be maintained for one year with [[http://www.debian.org/security/|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 [[http://www.debian.org/releases/etch/|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]]. ==== Disk Encryption ==== See [[SystemAdministration/Procedures/DiskEncryption]]. ==== 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. ==== 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]] ===== “emergency” patching ===== === Application === * ''This section deals with applications written in-house.'' * ''CPS 6.6 refers to this section for all info.'' * ''Text below was ascribed to the Application Engineer, since deprecated. Needs to be reviewed.'' The primary tasks for managing the Application are: * Installing signed-off patches, * Verifying correct running, * Correcting immediate errors and copying fixes back to upstream repositories, * Running ad-hoc database scripts and other programs, * Repairing data errors, * Backing up at the database level, * Watching application-level logs. === Access control === * ''OK, these lists are a mess. Bugs:'' * ''See below for better names'' * ''The old MoU means that secure-u have a veto on the administrators who can remote '''and SSH''' access the data. Need to separate out the secure-u control over CAcert system administrators, as secure-u has no view over the data nor authority.'' * ''Need to separate console administrators from SSH administrators'' ==== 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. ==== Special Authorisation ==== The access control lists are: * '''Console Access List''', * is currently maintained directly by the Boards of CAcert and secure-u. * this should transition to Systems Administration Engineer. * This list is currently located in the MoU Appendix B, Access List, where it is known as the ''Remote and Virtual Access List''. * '''SSH Access List''', * maintained by the Systems Administration team leader. * Direct command-line access to critical systems shall only be granted to systems administrators and application engineers on this list. * Systems administrators who are on the Console Access List are implied to be on the SSH Access List. * ''Where is this list? need to create this list when things stabilise.'' * '''Application Engineer List''', * managed by the Systems Administration team leader and/or the Software Assessment team leader. * This is the "400 points" mechanism, and it gives only a few rarely-used features. * It is managed by means of direct access to the databas * ''Need the SQL command written in the practices manual or procedures document.'' * ''Support Engineers are managed inside the Application by the Support team leader (feature can be enabled by any existing SE).'' ==== 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. ==== Removing access ==== Upon any of these events: * resignation from systems administration team, * determination by two members of the SSH or Console access lists that access is no longer required, * direction from the Arbitrator, or * direction from the Board, 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. ---- ---- ---- ---- == OPERATIONAL SECURITY == This section is managed by the Critical System Administration Team Leader. === System administration === Four eyes principle is satisfied by a different systems administrator conducting regular log inspection over tasks. ==== 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.). ===== Authorized users ===== ===== 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. ===== 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 [[SystemAdministration/Procedures/PasswordManagement|Password Management Procedures]]. ==== Required staff response time ==== Availability to respond to system events is at ''best efforts''. ==== Change management procedures ==== All changes made to system configuration must be recorded through RCS. ==== Outsourcing ==== DNS and OCSP may be outsourced. See Section 9.4. ''This is a wip area.'' === Logging === ''CPS4.2 refers here.'' ==== 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. ==== 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.'' ==== Automated logs ==== Automated logs should be reviewed preferably daily. ==== 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. === Backup === ''tie this in with section 3.2.1'' ''CPS5.1.6 refers here.'' ==== Type ==== There are three types of backup: * online (operational) * offline, offsite (disaster recovery) * roots, offsite (disaster recovery) (see section 9.2) ==== Frequency ==== Backups shall be performed: * operational: automatically, for systems in production or test modes * disaster recovery: manually, of the entire system when put into production (see section 3.2.1) * roots: manually (see section 9.2) ==== 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. ==== Retention period and Re-use ==== '''PROCEDURE:''' ''A backup procedure needs to be written, including:'' * Multiple backups may be stored on a single medium (e.g. external USB disk). 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. ==== Encryption ==== Disaster recovery backups are dual-encrypted using encrypted file system and GPG public key. ==== 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!'' ==== Key Management ==== At least two must conduct the backup. Paper documentation must be stored with the backup: * of the machine configuration (operating system and any required applications) for a new system install backup * time and date * type of format. * Systems Administrators and secure-u representatives present. * Systems administrators with keys. 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:'' * ''probably meant as board member '''OR''' Public Officer.'' * '' history statement should be stored somewhere else? Event Log?'' * ''Add comment that recovery is by board decision.'' * ''need procedure for checking validity of keys.'' ==== 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. === Data retention === ==== User data ==== On termination of an account, user data will be retained according to the direction of the Arbitrator. ==== 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. ==== 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. ---- ---- ---- ---- == INCIDENT RESPONSE == This section is managed by ??? ''Discuss.'' ''CPS 5.7 refers to here.'' === Incidents === There are several levels: 1. Tunix firewall 24/7 port control & monitoring and unencrypted traffic analysis. 1. Webserver firewall port control & monitoring. 1. Application controls. 1. Signing server. All of these levels generate logs. === 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. === Immediate Action === ==== Severity and Priority ==== '''Severity.''' Anomalous events should be classified into one of these severity categories: 1. undirected failure (corruption by software) 1. probe a. automated probe (broad attempt to detect some common weakness) a. directed probe (specific attempt to exploit a particular service) 1. intrusion (successful perversion of controls) a. exploit, no loss a. compromise, possibility of losses of sensitive data or certificate issuance a. breach, positive evidence of data loss 1. 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). ==== Communications ==== '''Warning.''' As soon as an event is detected, an initial report of breach or compromise should be sent to: * systems administrators, * other teams and roles, * key persons list, and/or * board. 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. ==== 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. === 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: * incident requires Member log-in ''or'' no login required * effect on user data, issued certificate, root private keys === 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. ==== Intrusion ==== The service successfully probed should be investigated: * review the necessity of the service/software, * identify a defence against the probe, * implement the defence, and * review the area for similar weaknesses. ==== 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. ==== 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. ==== Root key compromise ==== If a root key is compromised: 1. It is taken off line, including any subroots. 1. It is revoked * via CRL (subroots) or, * via notification to vendors (root only). See Section 9.2.4. 1. New root key procedure is invoked. See Section 9.2.1. 1. New root key is installed. 1. Certificates are revoked and Members notified to issue new certificates. (in above, subroot applies if applicable.) ==== Application compromise ==== When an application is compromised: 1. developer is contacted. 1. relevant logs, code, files are escrowed, as advised by developer. 1. emergency patches are made, as advised. (in above, vendor applies as developer if applicable.) ==== Recovery from compromise or breach ==== Once the damage is assessed and compromise or breach is indicated, confer with the Arbitrator for recovery procedures. === Reporting === '''Report.''' A final report should be created on [[SecurityManual/IncidentReports/|the wiki]] and notified to all effected parties (sysadms, Board, software development, secure-u, user victims). It should include: * details (date, hardware, software) * severity and description of losses * responses and recovery * mitigation recommendations for the future. 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. ---- ---- ---- ---- == DISASTER RECOVERY == This section is managed by who ?? ''Discuss.'' || '''TBD.''' || '''''work-in-progress.''''' || The process described below follows the CISA view. ==== Notes ==== * ''CPS 5.7 refers to here.'' * ''See also [[Advisory/AMinutes20081222|meeting of 20081222]]. A first cut / wip.'' * ''DRC A.3.l:'' * ''The CPS describes the CA's procedures for recovering from disasters and other operating interruptions, including'' * ''the creation and securing of backup copies of root, intermediate, and subscriber certificates'' * ''the creation and securing of backup copies of information used to authenticate subscriber identities'' * ''the rehosting of CA servers'' * ''informing subscribers and the general public of interruptions'' * ''the replacement of authorized personnel and the hand-over of their knowledge of pass-phrases'' === Business Processes === The board maintains [[BusinessProcesses]]. ==== Core Processes ==== [[DisasterRecovery]] sets the core processes as: 1. critical systems 1. OCSP/CRL servers === Recovery Times === [[DisasterRecovery]] sets the recovery time for revocation services at 27 hours. === Plan === 1. Notification goes to the key persons list. 1. Board makes initial assessment of team needed and notifies team. 1. Disaster Recovery team converges. 1. Planning and response. === Key Persons List === The board designates a trusted team of core participants, including: * board * systems administration (all) * software development representatives * support representatives * arbitration 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 [[SystemAdministration/Procedures/KeyPeopleContacts|Key Persons List Procedure]]. == SOFTWARE DEVELOPMENT == This section is managed by the Software Assessment Team Leader. ''Refs to other documents:'' * ''[[PolicyDrafts/DevProcessPolicy]] is an old start for the software development team. This is now misnamed, should be something like a Procedures.'' === Authority === Software development team leader is responsible for the security of the code. === 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: * fix bugs * add features * propose architectural changes * assist in delivery of code to Systems administrators. === 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?'' === 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. === 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?'' === 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. == SUPPORT == This section is managed by the Support Team Leader. === Authority === The board appoints the [[Brain/Support/TeamLeader|Support team leader]] to lead the support team. [[https://community.cacert.org/board/motions.php?motion=m20100222.1|m20100222.1]] Software for storing Member information (aka the website) is generally under the control of [[https://www.cacert.org/policy/ConfigurationControlSpecification.html|CCS]], see [[http://audit.cacert.org/svn/DRC/browser.php|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: * request of the Member * instruction of the Arbitrator. The Arbitrator should provide a token for authority (by default, the ruling number). === Responsibilities === ==== Support Engineers ==== Support Engineers ("SEs") do the following: * responding to general requests for information or explanation by Members, * generally by request in email to support channels, * keep confidential any secrets that Members reveal in support mails * advise users of general technical difficulties * blog, maillists or other forums for announcements * "administrative" assignations of Experience Points * done directly to the mysql db (e.g., because of bugs in the software), * ''But, the SE has no access to mysql, these must be done by application engineer?'' * Assist the system of Arbitration, see section 8.5, * enable roles as authorised, see section 8.2.2, * change Name(s), DoB, under authorisation from Arbitrator * revoke an assurance * on request of the Assurer, ''suggested by Alejandro, now filed as dispute.'' either Assurer + Support, in a short time frame * ''Teus writes: The system will not allow reassurance of an assuree. Of course the system has a tooling to reassure for administrative reasons. If done so it is reported to Board in order to keep control. The last three years I did not see such only after a dispute resolution.'' * or, under authorisation from Arbitrator * account recovery, * a formal procedure is at [[https://svn.cacert.org/CAcert/Support/PasswordRecovery.pdf|Password Reset Procedure]] (following Section 1.4.3.) * ''can see Privacy Questions'' which triggers a mail of notification to Members * Delete the account of user * '''there is a way to remove an account but this is deliberately not documented due to bugs.''' * ''(this part needs training)'' * ''this part needs review because it is not aligned with Arbitration'' * handle Paypal emails (confirmations) so as to * Give our thanks to the donators (even 5 USD is worth a thank) * Check if the user has paid password recovery fees ==== Enabling Roles ==== The SE is responsible for enabling roles when given authority. * authority may come from Board, Arbitrator or potentially applicable team leaders? * should use a TOKEN, the decision or ruling number. There are these roles: 1. '''location role''' * allows the user to change the location database * provided by an extra menu entry 1. '''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 [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p4.2.6|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 1. '''Tverify role''' * allows the user to add more points???? not tested 1. "delete account" just flags the account as unaccessable * to really delete, must scramble the data 1. '''advertising role''' 1. '''TTP role''' * ''ask Robert how the TTP role works'' * need 200 "old points" 1. '''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. 1. '''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.'' ==== Triage ==== Support Team Leader appoints and manages a team of first responders, known as [[Support/Triage|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. ==== Support Team Leader ==== Support Team leader is responsible for: * review of support actions * especially for referral to Arbitration * report to board. * creation of guidelines for common issues * human resources for the support team * recruiting * training and testing * ongoing supervision * initiate background checks * maintain a dialogue with Software Development and System Administration teams * by means of bugs.c.o * provide feedback on features for improvement * communicating with the Members * as directed by Board in occasional notifications of changes to policies or agreements, etc * when certificate problems occur with a Member * when there are emergencies or disruptions * in the case of a dispute being filed against a Member * or as directed by Arbitrator === Channels === Incoming communication occurs over these methods: * sending a webpost via the website at [[http://www.cacert.org/index.php?id=11|Contact Us]]. This results in either, a. a forward to the open help forum, below, or a. a forward of email to support@ below. * email to support@ a. (historically) emails were archived in an IMAP mailbox, managed by [[Support/Triage|Triage]]. This tool is deprecated and is to be cleaned up pending the [[Technology/Support/DataRetentionPractice|Data Retention Practice]] definition. a. (new) emails are put into the OTRS tracking & ticketing system at issue.cacert.org. This is a new system that is currently being modified to suit Support needs. Arbitration may also expand into it. * IRC on cacert# (unlogged, public channel, informal help) * open help forum, currently the mail list at cacert-support (archived, public channel, informal help) [[Support/Triage|Triage]] may forward communications coming into support@ to these channels: * To the Support Engineer's channel (via OTRS). * To the Arbitration Forum (via OTRS and then sent by CMs to maillist cacert-disputes). * This interface (should be) jointly managed by Support and Arbitration. * To the open help forum. 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. === Records and Logs === Each instruction from the Arbitrator should come with a TOKEN. * by default, the token is the case number * this TOKEN is the authority to do the support action * the support engineer records the TOKEN into the support logging * ''in any convenient box... for now, the Subject: of mails.'' * (later on, the software will have this as a proper feature) * this is a suggested/emerging procedure and has not yet been tried * ''what to do about support people applying the ruling to similar instances later on???'' * ''other systems should strive to emulate the basic token method.'' All support channels should be logged. * Incoming mail to support@ is: * kept in the IMAP box in Archives folder, once dealt with by Triage. ''Must clean out archive according to [[Technology/Support/DataRetentionPractice|data retention]].'' * kept by OTRS. ''How? Document.'' * Support Engineer's traffic * was logged to support-se maillist period November-December 2009 as a temporary measure. ''Must clean out archive according to [[Technology/Support/DataRetentionPractice|data retention]].'' * Access was given to all Arbitration Forum members. * kept by OTRS. ''How? Document.'' === Arbitration === Arbitration is a major responsibility of the support team: * determine which support requests must be referred to Arbitration. These include issues which: * require Authority * require guidance or are complicated * cannot be easily fit into an existing ruling that gives blanket authority * are requested as filed disputes by the person * involve termination of the account or agreement. [[CCA4.2]] * where a Support Engineer acts without authority in an emergency situation * where any demand, request, order is made from an official or apparently official source. See [[https://www.cacert.org/policy/SecurityPolicy.html#9.3.2|SP9.3.2]]. * provide support * as described by the [[https://svn.cacert.org/CAcert/Support/SupportOfArbitration.html|Guidelines for Support of Arbitration]]. * as [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Case Manager]] if requested * as directed by Arbitrator Team leader is responsible for reviewing decisions to file, '''and decisions not to file.''' * ''history, review the actions so far? any pending? what rough time does it take for each step?'' * ''where documented?'' === References === * "practices" and guidelines are at * procedures in [[https://svn.cacert.org/CAcert/Support/|SVN]] * guidelines in [[Support/Team|wiki]]: for [[Support/SE|Support Engineers]], [[Support/Triage|Triage]] and for our Community's [[Support/OpenHelpForum|Open Help Forum]]. * support ''at'' c.o is the major obligatory support channel * issue.cacert.org is the OTRS tracking & ticketing system. * CPS 4.9, 5.2.1 * [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Case Manager's Guidelines / Handbook]] * mailing list at cacert-support ''at'' lists. ---- ---- ---- ---- == ADMINISTRATIVE == This section is managed by the Board. === Staffing === ==== Roles and responsibilities ==== Additional tasks include: * Access Engineer: Capacity planning, liaison with Hosting, observes correct procedures by Systems Administrators. * System administrator: system capacity planning, 3rd party software maintenance and patching, and log monitoring for intrusion detection purposes. * Software Assessor: See section 7.2. * Support. See section 8.2. * Team leaders: Coordinate and advise on patches, fixes and features. Recruiting. * All: liaise with other teams. * Board: Coordinate team leaders and teams. Prioritise the feature and bug fixes. ==== 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. ==== Process of new Team Members ==== The general process is: 1. team proposes someone to join 1. team does preparation and interview 1. background check is initiated by filing dispute to Arbitration 1. Arbitration Ruling plus recommendation presented to board for appointment 1. Board approves. 1. Team cycles new person in. ==== 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 [[https://svn.cacert.org/CAcert/Arbitration/BackgroundCheckProcedure.html|Background Check Procedure]] is managed by the Arbitrator. ===== Scope ===== An investigation should include examination of: * realm-specific knowledge: programming skills for developers; relevant OS skills for system administrators, etc * community status must be Assurer at least * conflicts of interest should be known before checks begin ===== Coverage ===== The interview should signal which policies are agreed to, and ask about any reservations the candidate may have. <> ===== 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. ===== Privacy for Critical Roles ===== ==== Authorisation ==== ==== 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. ==== Termination of staff ==== The following steps must be taken: 1. SSH public keys of that person are blocked. 1. major secrets are changed (e.g., root passwords, server SSH keys) 1. minor passwords are analysed for sensitivity (e.g., database passwords) 1. accounts, record of activities, etc, are escrowed. 1. 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. ==== 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.'' === Root Key Management === * ''from CPS 5.6. DRC-A.2.t-u '' * That which applies to roots also applies to Subroots, unless otherwise stated. * Although not explicitly stated, any other signing activity is also covered. E.g., re-signing a subroot. ==== Root Key generation ==== * ''from CPS 6.2.6; see [[Roots/NewRootsTaskForce]] for new roots project info.'' The Procedure for Key Generation is located at [[Roots/CreationCeremony]]. ==== 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.'' ==== Recovery ==== * ''A.3.l'' Procedure for Recovery of roots from Backup and Escrow (above) should be located at [[Roots/EscrowAndRecovery]]. ''but not as yet written.'' ==== 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: * There is no PKIX way to revoke a root. CRL/OCSP do not apply. * Each vendor has a vendor-specific method to revoke the root. * Above method follows [[http://wiki.mozilla.org/CA:Recommendations_for_Roots]] however note that those are not policy. * A mailing list is to be maintained for third party vendors. Subscription and posting is moderated. * ''align/review other section where revocation is discussed.'' * ''add note to 3pv-DaL to point to this list.'' === Legal === ==== Responsibility ==== The board is the ultimate responsible party for legal affairs. * See [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p9.15|CPS#9.15]]. * The laws of NSW Australia (home of CAcert Inc) are applicable. Our Arbitration Forum is the forum in which legal questions are disputed. * Board has adopted the model of the [[http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML|European Data Protection Directive]]. See [[http://www.cacert.org/index.php?id=10|Privacy Policy]]. * Australian Digital Signature law is "technology neutral" model. See [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p1.4.3|CPS#1.4.3]] on use of Digital Signatures. * See [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p5.8.1|CPS#5.8.1]] on transfer of CA. ==== 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.'' === 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: [[https://svn.cacert.org/CAcert/CAcert_Inc/hosting/|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. * ''How far does this SM/SP go? Do we include BIT, Ede?'' * ''MoU probably needs rewriting after the dust settles on SP/SM.'' === Confidentiality, Secrecy === CAcert critical roles give up some privacy so as to preserve the privacy of others. ---- ---- ---- ---- == RESOURCES == === Contacts === * Systems administrators and Access Engineers are located on the [[https://lists.cacert.org/wws/info/cacert-sysadm|cacert-sysadm mailing list]] which is an open list. * All manual change logging is done to the [[https://lists.cacert.org/wws/info/cacert-systemlog|cacert-systemlog mailing list (Event Log)]]. * Key persons list is ''work-in-progress''. * CAcert board is at [[https://lists.cacert.org/wws/info/cacert-board|cacert-baord mailing list]]. * secure-u People: * board is at vorstand ''at'' secure-u ''dot'' de. * (secure-u's) Access Engineers are at cacert-access ''at'' hobby ''dot'' nl (as well as on cacert-sysadm). ''Note:'' All mailing lists are currently run on "infrastructure" machines which are non-critical. ''Watch this.'' ==== Key Persons Contact List ==== The procedure for maintaining and distributing the key persons private contact list is documented in [[SystemAdministration/Procedures/KeyPeopleContacts]]. === Documents === 1. The [[https://www.cacert.org/policy/SecurityPolicy.html|Security Policy]] is under [[https://www.cacert.org/policy/ConfigurationControlSpecification.html|CCS]] for audit purposes. 1. MoU with secure-u is located in [[https://svn.cacert.org/CAcert/CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf|svn CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf]] '''List of Procedures:''' <> * [[https://svn.cacert.org/CAcert/Arbitration/BackgroundCheckProcedure.html|BackgroundCheckProcedure]] * [[https://svn.cacert.org/CAcert/Support/PasswordRecovery.pdf|Password Reset Procedure]] * [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Case Manager Handbook]] * [[https://svn.cacert.org/CAcert/Support/SupportOfArbitration.html|Guidelines for Support of Arbitration]] ==== To Provide / find ==== * ''location of infrastructure diagrams'' * ''location of inventory'' [[[[SystemAdministration/EquipmentList|inventory]] found. === Related Documents === * [[RiskAssessment|Risk assessment]] also find CISA manual reference for DR. * older [[https://svn.cacert.org/CAcert/SecurityManual/|security wips]] * CAcert-secure-u MOU (dated 24 June 2013) * Some parts of the Security Manual are referenced directly from the [[https://www.cacert.org/policy/CertificationPracticeStatement.php|CPS]] especially sections [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p5|5]] and [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p6|6]]. ---- . CategoryAudit . CategoryPolicy . CategorySystems . CategorySupport