1865880 - Microsec: Findings in 2023 Audit

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[dr. Sándor SZŐKE]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Comment 1

[dr. Sándor SZŐKE]

Audit Incident Report

Finding #1

Findings with regard to ETSI EN 319 401:

7.9 Incident management

It was found that one vulnerability was not categorized correctly by the organization in JIRA and therefore the organization's fix times was not accountable. The organization has presented planned changes to the JIRA ticketing system to implement categorization so that vulnerability management can be implemented as per the controls. [REQ-7.9-10]

All non-conformities have been closed before the issuance of this attestation.

Root Cause Analysis

Microsec manages the discovered vulnerabilities in its JIRA system. Each vulnerability shall be classified as CRITICAL, HIGH, MEDIUM, LOW or INFORMATIVE.
The vulnerability shall be managed according to the marked classification with different deadlines.

There was no specific requirement on how to indicate the vulnerability classification, typically the classification was indicated in the TITLE field.

The identified ticket was rated HIGH and managed properly based on its rating, but this information was only in the comment text and not in the TITLE.

There was no regular follow-up for this type of issue, so the issue was uncovered until the audit.

As a result of the analysis, Microsec identified the following Root Causes:

• there was no clear requirement on how to mark vulnerability classification in JIRA
• there was no machine-processable marking
• regular monitoring focused on processing vulnerabilities and not marking classification

Action Items

• IMPROVE REQUIREMENTS

  Microsec introduced new rules for marking vulnerabilities.

  Each JIRA ticket containing a vulnerability shall have a LABEL "Sérülékenység" ("Vulnerability" in Hungarian) and another LABEL depending on the classification.

  The new rules were published on the internal wiki page

• CHECK EXISTING TICKETS

  Microsec shall check all existing tickets with vulnerability and shall add appropriate LABELS based on the vulnerability classification

• JIRA FILTER FOR VULNERABILITIES

  Microsec shall develop a specific filter in JIRA to list the identified vulnerabilities and their classification

• JIRA AUTOMATIC REPORT

  Microsec shall develop an automatic report running daily that lists vulnerabilities without classification labels and sends an email to the MSO

• MOZILLA INCIDENT REPORT

  Microsec shall open an Audit Incident Report in Mozilla and describe the issue and the actions taken to resolve the issue

• NON-CONFORMITY FULFILMENT REPORT

  Microsec shall send a report on the solution to the conformity assessment body and to the supervisory body within 3 months after the audit

Action Items Status

Action Item	Kind	Due Date	Status
IMPROVE REQUIREMENTS	Prevent	2023-10-20	DONE
CHECK EXISTING TICKETS	Detect	2023-11-10	DONE
JIRA FILTER FOR VULNERABILITIES	Detect	2023-11-10	DONE
MOZILLA INCIDENT REPORT	***	2023-11-21	OPEN
JIRA AUTOMATIC REPORT	Detect	2023-11-30	OPEN
NON-CONFORMITY FULFILMENT REPORT	***	2023-12-10	OPEN

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug is invalid.
If you think the bot is wrong, please reopen the bug and move it back to its prior component.
If your bug description is written in a non-English language, please use Google Translate or a similar service to translate it.

Please note that this is a production bug database used by the Mozilla community to develop Firefox, Thunderbird and other products.
Filing test bugs here will waste the time of our contributors, volunteers and employees.
Accounts that abuse bugzilla.mozilla.org will be disabled.

Comment 3

[dr. Sándor SZŐKE]

Audit Incident Status Report - 2023-11-29

Pending Action Items

• JIRA AUTOMATIC REPORT

  Microsec developed and introduced an automatic daily report in its jira ticketing system that lists vulnerabilities without classification labels and sends an email to the MSO every morning. In case of any listed ticket the MSO will contact the author of the ticket and require the classification of the vulnerability.

• MOZILLA INCIDENT REPORT

  Microsec opened an Audit Incident Report in Mozilla - present bug - and described the issue and the actions taken to resolve the issue.
  Microsec will inform the community about the status changes on weekly basis or in case of any questions received.

• NON-CONFORMITY FULFILMENT REPORT

  Microsec shall send a report on the solution to the conformity assessment body and to the supervisory body within 3 months after the audit

Action Items Status

Action Item	Kind	Due Date	Status
IMPROVE REQUIREMENTS	Prevent	2023-10-20	DONE
CHECK EXISTING TICKETS	Detect	2023-11-10	DONE
JIRA FILTER FOR VULNERABILITIES	Detect	2023-11-10	DONE
JIRA AUTOMATIC REPORT	Detect	2023-11-30	DONE
MOZILLA INCIDENT REPORT	***	2023-11-21	IN PROGRESS
NON-CONFORMITY FULFILMENT REPORT	***	2023-12-10	OPEN

Comment 4

[dr. Sándor SZŐKE]

Audit Incident Status Report - 2023-12-07

Action Items

• JIRA AUTOMATIC REPORT

  The daily report works fine, there were no new "vulnerability" jira tickets without labeling.

• NON-CONFORMITY FULFILMENT REPORT

  2023-11-06

  Microsec prepared the official report on the resolution and sent it to the conformity assessment body and the supervisory authority before the deadline.

• MOZILLA INCIDENT REPORT

  All planned tasks have already been completed.

  If there are no questions, Microsec recommends closing this ticket.

Action Items Status

Action Item	Kind	Due Date	Status
IMPROVE REQUIREMENTS	Prevent	2023-10-20	DONE
CHECK EXISTING TICKETS	Detect	2023-11-10	DONE
JIRA FILTER FOR VULNERABILITIES	Detect	2023-11-10	DONE
JIRA AUTOMATIC REPORT	Detect	2023-11-30	DONE
NON-CONFORMITY FULFILMENT REPORT	***	2023-12-10	DONE
MOZILLA INCIDENT REPORT	***	2023-11-21	IN PROGRESS

Comment 5

[Ben Wilson]

I will close this matter tomorrow, 9-Feb-2024, unless there are additional issues or comments to be addressed.

Comment 6

[dr. Sándor SZŐKE]

There is no new information, the solution works properly.

Comment 7

[amir]

I am confused about the timeline of this incident. When did you learn about these findings?

Comment 8

[Ben Wilson]

The AAL from Hunguard (https://www.hunguard.hu/wp-content/uploads/2023/12/Attestation_letter_007_v12_all_ds.pdf) appears to have been issued initially on 2023-10-16. The on-site audit dates were 2023-08-22 and 2023-09-11 to 2023-09-13.
(ETSI 319 401, REQ-7.9-10 states, "The TSP shall address any critical vulnerability not previously addressed by the TSP, within a period of 48 hours after its discovery.") The first action on the timeline of events was 2023-10-20, but it is unclear how soon the critical vulnerability was patched after its discovery. FWIW, section 4.f. of the CA/Browser Forum's Network and Certificate System Security Requirements allows 96 hours:

f. Do one of the following within ninety-six (96) hours of discovery of a Critical Vulnerability not previously addressed by the CA’s vulnerability correction process:

1. Remediate the Critical Vulnerability;

2. If remediation of the Critical Vulnerability within ninety-six (96) hours is not possible, create and implement a plan to mitigate the Critical Vulnerability, giving priority to
   i. vulnerabilities with high CVSS scores, starting with the vulnerabilities the CA determines are the most critical (such as those with a CVSS score of 10.0) and
   ii. systems that lack sufficient compensating controls that, if the vulnerability were left unmitigated, would allow external system control, code execution, privilege escalation, or system compromise; or

3. Document the factual basis for the CA’s determination that the vulnerability does not require remediation because
   i. the CA disagrees with the NVD rating,
   ii. the identification is a false positive,
   iii. the exploit of the vulnerability is prevented by compensating controls or an absence of threats; or
   iv. other similar reasons.

Comment 9

[dr. Sándor SZŐKE]

Answer for questions - 2024-02-10

2023-09-12

During our site visit, our auditor made a finding regarding the incomplete marking of a threat.

It is important to note that there was no any vulnerability in our IT system.
We constantly monitor published threats and examine the threat's potential impact on our systems within the time limit corresponding to the original classification defined in the publication. According to the results of the internal investigation, we may reclassify the threat and, if necessary, take appropriate protective or preventive measures.

The audit finding concerned only the documentation of the internal investigation of such a threat. In the textual description of the threat assessment, the classification of the trheat was described, but this classification was not marked "obviously" and easily managable way in the jira ticket, like a keyword.
The remedial activities carried out were specifically aimed at improving the marking method of the classification and the supervision of the marking.
The discrepancy found had a negligible impact on the safe operation of our services or the adequacy of the issued certificates.
Since no critical vulnerabilities were discovered, we did not create a public bugzilla report that time.

2023-10-16

This was reported in our AAL as the only finding during our audit.

2023-11-21

When Microsec uploaded the AAL into CCADB, it opened this "Audit Incident Report" to provide details on the management of the audit finding.

2023-12-10

Within 3 months of the onsite audit, Microsec had to submit a report to the auditor on the final solution to the finding, including preventive measures.

Comment 10

[Ben Wilson]

Unless there are any more questions, I will close this on Wed. 14-Feb-2024.