1636141 - SwissSign: failure to provide a preliminary report within 24 hours

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

On 2020-05-06 at 12:16 UTC, I submitted a certificate problem report to the address listed in SwissSign's CPS ([e-mail]) concerning the problem described in Bug 1636140. The report was accepted by SwissSign's mail server:

mail.log:May  6 12:16:53 thompson postfix/smtp[7758]: 34411A0057: to=<[e-mail]>, relay=swisssign-com.mail.protection.outlook.com[104.47.0.36]:25, delay=4.7, delays=0.21/0.02/2.6/1.9, dsn=2.6.0, status=sent (250 2.6.0 <[e-mail]> [InternalId=23003844842060, Hostname=GVAP278MB0134.CHEP278.PROD.OUTLOOK.COM] 18166 bytes in 0.139, 126.873 KB/sec Queued mail for delivery)

As of 24 hours later, I have yet to receive a preliminary report from SwissSign.

Comment 1

[Mike Guenther]

Please assign this bug to me

Comment 2

[Mike Guenther]

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.
SwissSign took notice of this issue as it was reported in Bugzilla

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.

• 20200506 14:16 CEST Email from @andrewayer.com is acknowledged by our mail gateway and is investigated by our Advanced Threat Protection
• 20200506 14:17 CEST The message is classified as potentially malicious and/or spam
• 20200507 07:55 PDT Opening of this bug
• 20200508 08:00 CEST SwissSign took notice of the this Bugzilla and validated the information
• 20200508 08:15 CEST The team responsible for [e-mail] is contacted
• 20200508 10:00 CEST The mentioned mail has not been found in the mailbox. A search order is given to the IT department
• 20200508 10:30 CEST The mail has been found in quarantine. (see entry from 20200506)
• 20200508 14:15 CEST Further investigations indicate that the attached pem-file has been identified as a potential threat. This is the standard configuration of the cloud-based ATP.
• 20200508 19:15 CEST Reply to the Andrew
• 20200508 19:15 CEST Posting in Bugzilla

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

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

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

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Our logs show that the added pem-file is most probably the reason why the mail has been classified as malicious. We did not have any knowledge of this mail therefore were not able to react accordingly.

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.
We are convinced that the configuration of our malware/spam protection is implemented according to current best-practices. We have no plans to change the current settings as it potentially lowers the safeguards for our company. However we are currently checking with the IT-department to delete pem-files and still send the rest of the mail to the info-inbox.

Comment 3

[mpalmer]

Given that sending a PEM or PEM-like data structure is, I understand, quite common in certificate problem reporting (the problematic cert itself, a compromised key, or a CSR attesting to compromise), it seems entirely plausible that one or more other valid certificate problem reports have been caught by this configuration.

I have the following questions:

1. When was the configuration change made to SwissSign's systems to block e-mails that contain a PEM or PEM-like data structure?
2. How far back does the logging on SwissSign's "threat protection" system extend?
3. Does the logging configuration of SwissSign's "threat protection" system contain sufficient detail for SwissSign to identify historical instances where potentially-valid certificate problem reports have been blocked?
4. If the answer to 3 is "no", does the possibility exist for such a configuration to be established?
5. If the answer to 3 is "no", or if the date in 1 preceded the date of 2, how does SwissSign intend to identify and process valid certificate problem reports which it previously rejected?
6. To the degree that information sufficient to identify potentially valid problem reports which were blocked what plans does SwissSign have in place to retrieve and process those reports?
7. What other forms of plausibly-valid certificate problem reports could be caught by SwissSign's "threat protection" system?
8. What procedures has SwissSign adopted in order to prevent potentially-valid problem reports that are sent in the future from being ignored?
9. What other potential solutions to this problem did SwissSign consider? Why were they rejected in favour of the solution that SwissSign has adopted?
10. What contingency plans has SwissSign considered, going forward, if SwissSign's IT department deems it impractical to delete PEM files from incoming e-mails?

Comment 4

[Mike Guenther]

We found no indication that another report was categorized as SPAM/Phishing in the past by checking all the quarantined mails (retention is 90 days).

I thank Andrew that he published this Bugzilla ticket. This way we were made aware of the unexpected issue.

For mitigation SwissSign decided to activate quarantine-notifications for the [e-mail] mailbox which triggers a manual check for a legit problem report by the responsible team.

Comment 5

[mpalmer]

I'd appreciate it if you could fully answer the questions I've asked.

Comment 6

[Ryan Sleevi]

Ben: I’m not sure that I think the answers to Question 3 will be all that helpful here, nor that will provide information that helps develop better mitigations. It also doesn’t seem like it would significantly alter our view of this incident. That is, the view and judgement is largely based on the CA’s initial/final report, and the details they decided to include or exclude.

Mozilla Policy is a bit ambiguous right now about who can ask questions and whether the CA “has” to answer them. Mozilla policy simply states:

Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered.

But that’s in a section “Keeping us informed”, and so it’s unclear if those are only applicable to questions from Mozilla.

I wanted to pass to you for your opinion here.

Comment 7

[Ben Wilson]

The questions in comment #3 are well-written, but in my opinion, it would be good just to know whether Swisssign has been able to reconfigure its mail filter in some way to ensure that various types of alerts (i.e. those with these types of attachments, etc.) will arrive and alert the appropriate personnel?

Comment 8

[Mike Guenther]

Ben: I can confirm that all mails which are quarantined by the malware protection now trigger a notification to the responsible team which is then looking into it manually to identify legit problem reports: see my comment 4.

Comment 9

[Ben Wilson]

I intend to close this bug as Fixed.