m.d.s.p community, Google Trust Services (GTS) would like to provide an update on a potential risk related to the "Auditing of CA facilities in lockdown because of an environmental disaster/pandemic" thread.
Our annual audit period for all GTS CAs runs from October 1st of one year to September 30th of the following year, so we have just over 6 months to complete facility audits. While we believe it should be possible to fully audit all facilities, we have no way of knowing when the current travel restrictions will be lifted. For this reason, we want to flag this as a possible future risk Our facility audits normally involve site visits by auditors to 3 locations during July and August. The 3 sites are: 1 in Oklahoma, US, 1 in South Carolina, US and 1 in Zurich canton, Switzerland. At present, all sites are functional and secure but subject to some form of lockdown and most of our staff and auditor staff is subject to shelter in place requirements. We do not have any immediate concerns related to secure ongoing operation or compliance obligations, but if the Covid-19 restrictions extend into the late Summer, our ability to conduct facility audits for some locations may be imperilled. 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. Arvid Vermote started the "Auditing of CA facilities in lockdown because of an environmental disaster/pandemic" thread on m.d.s.p and we have been following it closely. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. GTS has expanded its business continuity plan to cover pandemics and travel restriction scenarios in more depth. We are maintaining regular communications with our auditors about potential impacts. If we needed to, under essential worker provisions, we could complete key ceremonies and facility audits, but as we have no pressing need to conduct either activity, we are delaying both indefinitely and continually assessing the impact and our risk position. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. Not applicable for this issue. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. Not applicable for this issue. 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. Not applicable for this issue. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The current Covid-19 pandemic is unprecedented. Our business continuity plans cover global disruptions but they assumed a higher likelihood of occurrence for disruptions due to local events. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. Like the rest of the industry, we're in a position of continuous re-evaluation. Should the situation change dramatically or not look likely to accommodate routine operations and activities by July 1, 2020, we will provide an update on our plans. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
