5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

5.1 Physical controls

5.1.1 Site location and construction

ISRG Secure PKI Facilities are located in the United States, as are all copies of CA root and intermediate private keys.

ISRG maintains at least two Secure PKI Facilities at all times for the sake of redundancy.

Secure PKI Facilities are constructed so as to prevent unauthorized entry or interference.

Secure PKI Facilities are monitored at all times (24x7x365) so as to prevent unauthorized entry or interference.

5.1.2 Physical access

Physical access to ISRG Secure PKI Facilities is restricted to authorized ISRG employees, vendors, and contractors, for whom access is required in order to execute their jobs. Access restrictions are strongly enforced via multi-factor authentication mechanisms.

5.1.3 Power and air conditioning

Redundant power sources are readily available at each Secure PKI Facility, and are designed to meet ISRG’s operating requirements.

Air conditioning systems at each Secure PKI Facility are designed to meet ISRG’s operating requirements.

5.1.4 Water exposures

ISRG Secure PKI Facilities are designed to protect ISRG infrastructure from water exposure/damage.

5.1.5 Fire prevention and protection

ISRG Secure PKI Facilities are designed to prevent fire and provide suppression if necessary.

5.1.6 Media storage

ISRG Secure PKI Facilities are designed to prevent accidental damage or unauthorized access to media.

5.1.7 Waste disposal

ISRG prohibits any media that contains or has contained sensitive data from leaving organizational control in such a state that it may still be operational, or contain recoverable data. Such media may include printed documents or digital storage devices. When media that has contained sensitive information reaches its end of life, the media is physically destroyed such that recovery is reasonably believed to be impossible.

5.1.8 Off-site backup

ISRG maintains multiple backups of private keys at multiple Secure PKI Facilities. All backups are stored on devices meeting FIPS 140 Level 3 criteria.

5.2 Procedural controls

5.2.1 Trusted roles

All persons, employees or otherwise, with the ability to materially impact the operation of ISRG PKI systems and services, or the ability to view CA confidential information, must do so while designated as serving in a Trusted Role.

Trusted Roles include, but are not limited to:

• Management
  • May view confidential information but may not directly impact CA operations. Strong decision-making authority.
• Security Officers
  • May view confidential information but may not directly impact CA operations. Strong decision-making authority.
• Systems Administrators
  • May view confidential information and directly impact CA operations. Decision-making authority is limited.
• Engineering Liaisons
  • May view confidential information but may not directly impact CA operations. No decision-making authority.

Each Trusted Role requires an appropriate level of training and legal obligation.

5.2.2 Number of persons required per task

A number of tasks, such as key generation and entering areas physically containing operating ISRG PKI systems, require at least two people in Trusted Roles to be present.

5.2.3 Identification and authentication for each role

Anyone performing work in a Trusted Role must identify and authenticate themselves before accessing ISRG PKI systems or confidential information.

5.2.4 Roles requiring separation of duties

Nobody with the ability to deploy software to ISRG PKI systems (e.g. Systems Administrators) may have the ability to commit code to core CA software. The reverse is also true.

5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements

ISRG management is responsible for making sure that Trusted Contributors are trustworthy and competent, which includes having proper qualifications and experience.

ISRG management ensures this with appropriate interviewing practices, training, background checks, and regular monitoring and review of Trusted Contributor job performance.

5.3.2 Background check procedures

Trusted Contributors must undergo a background check prior to performing in a trusted role. ISRG management will review the results of background checks for problematic issues prior to approving performance of a trusted role.

Background checks include, but are not limited to, criminal background and employment history.

5.3.3 Training requirements

Trusted Contributors must be trained on topics relevant to the role in which they will perform.

Training programs are developed for each role by ISRG management and Security Officers.

5.3.4 Retraining frequency and requirements

Training is repeated for each Trusted Contributor on an annual basis and re-covers all topics relevant to their trusted role.

Training is also offered whenever changes in the industry or operations require it in order for contributors to competently perform in their trusted roles.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

Action will be taken to safeguard ISRG and its subscribers whenever ISRG Trusted Contributors, whether through negligence or malicious intent, fail to comply with ISRG policies including this CPS.

Actions taken in response to non-compliance may include termination, removal from trusted roles, or reporting to legal authorities.

Once management becomes aware of non-compliance the Trusted Contributor(s) in question will be removed from trusted roles until a review of their actions is complete.

5.3.7 Independent contractor requirements

Independent contractors who are assigned to perform Trusted Roles are subject to the duties and requirements specified for such roles in this CPS and the accompanying CP. This includes those described in Section 5.3. Potential sanctions for unauthorized activities by independent contractors are described in Section 5.3.6.

5.3.8 Documentation supplied to personnel

Trusted Contributors are provided with all documentation necessary to perform their duties. This always includes, at a minimum, a copy of the ISRG CP, CPS, and Information Security Policy.

5.4 Audit logging procedures

5.4.1 Types of events recorded

Audit logs are generated for all events related to CA security (physical and logical) and certificate issuance. Logs are automatically generated whenever possible. When it is necessary to manually log information, logs are kept on paper with written confirmation from a witness and securely stored. All audit logs, electronic or otherwise, shall be retained and made available to compliance auditors upon request.

At a minimum, each audit record includes:

• Date and time of entry;
• Identity of the person (or machine) making the entry; and
• Description of the entry.

5.4.2 Frequency of processing log

No stipulation.

5.4.3 Retention period for audit log

Audit logs are retained for at least seven years and will be made available to compliance auditors upon request.

5.4.4 Protection of audit log

Audit logs, whether in production or archived, are protected using both physical and logical access controls.

5.4.5 Audit log backup procedures

ISRG makes regular backup copies of audit logs. Audit log backup copies are sent for secure offsite storage at least once per month.

5.4.6 Audit collection system (internal vs. external)

Audit data is automatically generated and reported/recorded by operating systems, CA software applications, and network devices. Systems are in place to ensure proper reporting and recording of audit data, and the failure of such systems may lead to suspension of CA services until proper audit log reporting is restored.

5.4.7 Notification to event-causing subject

No stipulation.

5.4.8 Vulnerability assessments

Audit logs are monitored by Trusted Contributors, including operations and engineering staff. Anomalies indicating attempted breaches of CA security are reported and investigated.

Automated internal and external vulnerability scans occur at least every two weeks, though more typically every week.

Extensive vulnerability assessments for ISRG infrastructure are conducted at least annually by qualified third parties.

ISRG Security Officers perform a risk assessment at least annually. This risk assessment:

1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;

2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and

3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

5.5 Records archival

5.5.1 Types of records archived

ISRG archives all audit logs, the contents of which are described in Section 5.4.1. ISRG may also archive any other information deemed critical to understanding the historical performance of the CA’s duties.

5.5.2 Retention period for archive

ISRG retains all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid.

5.5.3 Protection of archive

Archives are protected from unauthorized modification or destruction by strong security and environmental controls at primary and offsite storage facilities.

5.5.4 Archive backup procedures

Archives are backed up at primary CA facilities as well as at secure off-site facilities.

5.5.5 Requirements for time-stamping of records

Records are time-stamped as they are created.

Machine-created records use system time, which is synchronized automatically with third-party time sources. Machines without network access have the time set manually.

Manual records use a manually entered date and time, complete with time zone in use.

5.5.6 Archive collection system (internal or external)

No stipulation.

5.5.7 Procedures to obtain and verify archive information

No stipulation.

5.6 Key changeover

When a CA certificate is nearing expiration, a key changeover procedure is used to transition to a new CA certificate. The following steps constitute a key changeover procedure:

1. Some time prior to CA certificate expiration, the private key associated with the expiring certificate is no longer used to sign new certificates. It is only used to sign CRLs and OCSP responses.

2. A new key pair is generated and a new CA certificate is created containing the new key pair’s public key. This new key pair is used to sign new certificates.

3. If necessary or desired, the old private key associated with the expiring certificate may be used to cross-sign the new certificate.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

ISRG has created and maintains incident response procedures for a range of potential compromise and disaster situations. Such situations include, but are not limited to, natural disasters, security incidents, and equipment failure. Incident response plans are reviewed, potentially updated, and tested on at least an annual basis.

5.7.2 Computing resources, software, and/or data are corrupted

In the event that computing resources, software, and/or data are corrupted or otherwise damaged, ISRG will assess the situation, including its impact on CA integrity and security, and take appropriate action. CA operations may be suspended until mitigation is complete. Subscribers may be notified if corruption or damage has a material impact on the service provided to them.

5.7.3 Entity private key compromise procedures

In the event that a CA Private Key is compromised, or suspected to be compromised, ISRG will immediately launch a thorough investigation. Forensic evidence will be collected and secured as quickly as possible. If it cannot be determined with a high degree of certainty that the private key in question was not compromised, then the following steps may be taken in whatever order is deemed most appropriate by ISRG Security Officers:

• Certificates relying on the private key in question will be revoked.
• ISRG will notify root programs relying on the integrity of the key in question.
• ISRG will notify Subscribers relying on the integrity of the key in question.

5.7.4 Business continuity capabilities after a disaster

ISRG maintains multiple geographically diverse facilities, each of which is capable of operating ISRG CA systems independently. In the event that a disaster entirely disables one facility, ISRG CA operations will fail over to another facility.

5.8 CA or RA termination

In the event that ISRG CA services are to be terminated:

• All affected parties, including root programs and Subscribers, will be provided with notice as far in advance as reasonably possible.
• A termination plan will be created and review by the ISRG PMA.

If a suitable successor entity exists, the following steps will be taken:

• CA Private Keys, records, logs, and other critical documentation will be transferred to the successor organization in a secure and compliant manner.
• Arrangements will be made for compliant continuation of CA responsibilities.

If a suitable successor entity does not exist, the following steps will be taken:

• All certificates issued will be revoked and final CRLs will be published.
• CA Private Keys will be destroyed.
• CA records, logs, and other critical documentation will be transferred to a third party or government entity with appropriate legal controls in place to protect information while allowing its use in compliance with relevant policies and the law.