1652827 - Microsoft: Incomplete Logical Access Review Audit Evidence

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Dustin Hollenback]

Background
This bug filing encompasses CAs managed by DSRE PKI at Microsoft, which includes the following Intermediate CAs:
Microsoft IT TLS CA 1
Microsoft IT TLS CA 2
Microsoft IT TLS CA 4
Microsoft IT TLS CA 5

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.
During the preliminary audit in January, a request for documentation to prove that we were performing human reviews of logical access was made. At that time, although we were collecting all other logical access logs, and were reviewing the evidence as it was collected; the creation of evidence proving that a review had been performed had not been completed.

At the conclusion of the audit period in June, we confirmed the need for a proof of review artifact. As such a public disclosure is required.

For reference: This is related to the WebTrust Baseline Audit Criteria for Network Security version 2.4.1 (4-2.10).

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.

• Note-1 : We only tracked dates and did not track time stamps as all actions involved humans, rather than computers.
• Note-2: The audit period is 1 July 2019 to 30 June 2020

15 May 2019 – Last logical access review document created in previous audit period
15 November 2019 – First logical access review document created in current audit period
15 January 2020 – BDO identified that our evidence had changed and there was a delay between expected review dates.
16 January 2020 – Documented process updated to add more clarity regarding the task cadence and underlying requirements
24 January 2020 – Logical access review documents created
25 June 2020 – Annual audit concluded with an evidence review and discussion confirming the need for a proof of review artifact

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.
There were no non-compliant certificates issued.

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.
There were no non-compliant certificates issued.

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.
There were no non-compliant certificates issued.

Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
This is a manual human process and resulted in human failure. Though we were collecting all other logical access logs, and were reviewing the evidence as it was collected; the creation of evidence proving that a review artifact was also required and was overlooked in the control documentation by the operator.

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.
We updated our documented process within one day of realizing the documentation gap to include more frequent reviews and clarified some of the language. This process change included increasing the frequency of reviews. We are also developing automation to monitor for a new evidence file and alert if review evidence was not created within a time window. This monitoring and alerting will be implemented by 30 September 2020.

Comment 1

[Ryan Sleevi]

Setting Next Update to a midpoint of the proposed monitoring and alerting, to make sure we're on track for that by 2020-09-30.

Comment 2

[Dustin Hollenback]

We are code-complete for the automated review logic and completed the deployment to our production systems. We are planning to complete the final monitoring and alerting changes by 15-September-2020 and are still on track for the 30-September-2020 completion date as our padded commitment date that includes time to address any issues that might be discovered along the way.

Comment 3

[Ben Wilson]

Setting next update to 15-Sept-2020

Comment 4

[Dustin Hollenback]

This monitoring and alerting is fully implemented and validated now.

Comment 5

[Ben Wilson]

I will schedule this bug to be closed on 21-Sept-2020 unless there are additional issues to be discussed.

Comment 6

[Ryan Sleevi]

Updating the description back to how we think about the organizations (one organization, Microsoft), rather than how it internally divides work.