Mississuance of EV Certificates

[corneli...@gmail.com]

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.

We became aware of the problem during an internal review of the configuration change from last week at Monday December 11 2 .30 p.m. UTC.

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.

•2017/12/04 2 p.m. UTC: Test Setup with wrong configuration has been set up.
•2017/12/06 12.10 p.m. UTC – 2017/12/08 3.40 p.m. UTC: 10 Certificates were issued using the wrong configuration. The configuration should have been using an internal not public trusted CA.
•2017/12/11 2.30 p.m. UTC: Wrong setup was detected during the internal setup review process.
•2017/12/11 3.00 p.m. UTC: The affected configuration has been suspended.
•2017/12/11 3.30 p.m. UTC: Affected Certificates were immediately revoked after a short internal review.
•2017/12/11 3.00 p.m. UTC: The affected configuration has been corrected.
•2017/12/12 10:00 p.m. UTC: Incident report was submitted to Mozilla


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.

The affected configuration has been corrected. Since then, no such certificates have been issued.

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.

The subject information in the affected certificates were not validated correctly due to the misconfiguration. 10 certificates were issued based on this misconfiguration between 2017/12/06 12.10 p.m. UTC and 2017/12/08 3.40 p.m. UTC.

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.

https://crt.sh/?id=273776520
https://crt.sh/?id=273776617
https://crt.sh/?id=272950014
https://crt.sh/?id=272950007
https://crt.sh/?id=272950012
https://crt.sh/?id=272950010
https://crt.sh/?id=272166103
https://crt.sh/?id=272166102
https://crt.sh/?id=272166107
https://crt.sh/?id=272166110



6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The employee wanted to set up a test set up for a partner and have made a mistake in choosing the wrong template for the issuing CA (productive EV CA instead of a untrusted internally used test CA).

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.

The implemented controls detected the misconfiguration within 24 hours. The incorrect configuration was nevertheless recorded as a security incident. The handling of the security incident by the information security management team is still underway. Further measures will be decided within this process.

[corneli...@gmail.com]

I have to correct one thing:
7)
The implemented controls detected the misconfiguration, when we detectetd the misconfiguration the report was given within 24 hours.

[Nick Lamb]

Hi,

I have a couple of follow-up questions if I may:

On Tue, 12 Dec 2017 02:09:47 -0800 (PST)
"cornelia.enke--- via dev-security-policy"

<dev-secur...@lists.mozilla.org> wrote:

> The subject information in the affected certificates were not
> validated correctly due to the misconfiguration. 10 certificates were
> issued based on this misconfiguration between 2017/12/06 12.10 p.m.
> UTC and 2017/12/08 3.40 p.m. UTC.

Can you say more about what validation if any was still in place? Would
it have been possible, with this misconfiguration, for your CA to issue
certificates without any of the validation steps required by the BRs?

Also, from the rest of the description it sounds as though the
misconfigured system was only used by an existing customer of
SwissSign, named Secardeo GmbH, is that correct? So in a similar
situation a hypothetical third party attacker would NOT be able to
obtain certificates without validation, only the (un)happy incident
customer?

> The implemented controls detected the misconfiguration within 24
> hours. The incorrect configuration was nevertheless recorded as a
> security incident. The handling of the security incident by the
> information security management team is still underway. Further
> measures will be decided within this process.

I suspect I speak for others on m.d.s.policy when I ask that you let us
know of any such measures that are decided. This sort of incident could
happen to many CAs, there's no need for everybody to learn the hard way.

[Ryan Sleevi]

Indeed, the purpose of incident reporting is not to shame CAs at all, but
rather, to help all of us working together, collectively, build a more
secure web.

Similarly, the goal is to understand not how people fail, but how systems
fail - not "who was responsible" but "how was this possible"

To that end, I think it would be beneficial if you could:
- Share a timeline as to when to expect the next update. It seems like 72
hours is a reasonable timeframe for the next progress update and
information sharing.
- Explore and explain how the following was possible:
- 2017/12/04 2 p.m. UTC: Test Setup with wrong configuration has been
set up.
That is, it was detected during the "2017/12/11 2.30 p.m. UTC" internal
review, which is good, but why wasn't it detected sooner - or even prior to
being put in production?

Again, the goal is not to find who to blame, but to understand how systems
fail, and how they can be made more robust. What privileges do personnel
have can lead to discussions about "How should a CA - any CA - structure
its access controls?" How was it possible to deploy the wrong configuration
can help inform "How should a CA - any CA - handle change management?".

Our focus is on systems failure, not personal failure, because it helps us
build better systems :)

[corneli...@gmail.com]

Am Dienstag, 12. Dezember 2017 16:19:22 UTC+1 schrieb Nick Lamb:
> Hi,
>
> I have a couple of follow-up questions if I may:
>
> On Tue, 12 Dec 2017 02:09:47 -0800 (PST)
> "cornelia.enke--- via dev-security-policy"
> <dev-secur...@lists.mozilla.org> wrote:
>
> > The subject information in the affected certificates were not
> > validated correctly due to the misconfiguration. 10 certificates were
> > issued based on this misconfiguration between 2017/12/06 12.10 p.m.
> > UTC and 2017/12/08 3.40 p.m. UTC.
>
> Can you say more about what validation if any was still in place? Would
> it have been possible, with this misconfiguration, for your CA to issue
> certificates without any of the validation steps required by the BRs?
>
> Also, from the rest of the description it sounds as though the
> misconfigured system was only used by an existing customer of
> SwissSign, named Secardeo GmbH, is that correct? So in a similar
> situation a hypothetical third party attacker would NOT be able to
> obtain certificates without validation, only the (un)happy incident
> customer?

You are completely right. The certificates were only issued to our partner Secardeo GmbH. SwissSign has set up a dedicated test account for this partner. The issued certificates were never installed on any system, either by Secardeo or by any other party.
No other partner or customer where affected by this misconfiguration.

As SwissSign only allows access to an account by certificates (clientAuth) and thus this account was only accessible by Secardeo no third party or any other customer was able to get such a EV certificate.

>
> > The implemented controls detected the misconfiguration within 24
> > hours. The incorrect configuration was nevertheless recorded as a
> > security incident. The handling of the security incident by the
> > information security management team is still underway. Further
> > measures will be decided within this process.
>
> I suspect I speak for others on m.d.s.policy when I ask that you let us
> know of any such measures that are decided. This sort of incident could
> happen to many CAs, there's no need for everybody to learn the hard way.

As an immediate measure we have decided not to setup any more test accounts on our productive environment until we have decided on long-term countermeasures. We will announce the decided countermeasures on Friday December 15th.

[corneli...@gmail.com]

Am Dienstag, 12. Dezember 2017 18:04:55 UTC+1 schrieb Ryan Sleevi:
> On Tue, Dec 12, 2017 at 10:18 AM, Nick Lamb via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > > The implemented controls detected the misconfiguration within 24
> > > hours. The incorrect configuration was nevertheless recorded as a
> > > security incident. The handling of the security incident by the
> > > information security management team is still underway. Further
> > > measures will be decided within this process.
> >
> > I suspect I speak for others on m.d.s.policy when I ask that you let us
> > know of any such measures that are decided. This sort of incident could
> > happen to many CAs, there's no need for everybody to learn the hard way.
> >
> >
> Indeed, the purpose of incident reporting is not to shame CAs at all, but
> rather, to help all of us working together, collectively, build a more
> secure web.
>
> Similarly, the goal is to understand not how people fail, but how systems
> fail - not "who was responsible" but "how was this possible"

This was a human error during the setup process. The problem could have been avoided if there had been restricting policies for the test setup. We are currently examining how we can define this as a long-term measure.

>
> To that end, I think it would be beneficial if you could:
> - Share a timeline as to when to expect the next update. It seems like 72
> hours is a reasonable timeframe for the next progress update and
> information sharing.

We will give an update on Friday December 15th.

> - Explore and explain how the following was possible:
> - 2017/12/04 2 p.m. UTC: Test Setup with wrong configuration has been
> set up.
> That is, it was detected during the "2017/12/11 2.30 p.m. UTC" internal
> review, which is good, but why wasn't it detected sooner - or even prior to
> being put in production?

Due to the fact that this was a test setup the regular review process was on a lower priority.
We will also reassess this review process within the long-term measures.

> Again, the goal is not to find who to blame, but to understand how systems
> fail, and how they can be made more robust. What privileges do personnel
> have can lead to discussions about "How should a CA - any CA - structure
> its access controls?" How was it possible to deploy the wrong configuration
> can help inform "How should a CA - any CA - handle change management?".
>
> Our focus is on systems failure, not personal failure, because it helps us
> build better systems :)

You are correct – this must be the main focus in our long-term countermeasures.

[corneli...@gmail.com]

Update on the long-term countermeasures:
At the first point - sorry for the delay. I missed to post my answer on Fryday.

We The occurred error caused by a human error we decided as a long-term protection measure to carry out the setup in the 4 AP and all possible restrictions in case of test accounts.
In this way, a repetition of the error is to be prevented.

[Ryan Sleevi]

On Mon, Dec 18, 2017 at 9:30 AM, cornelia.enke66--- via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> Update on the long-term countermeasures:
> At the first point - sorry for the delay. I missed to post my answer on
> Fryday.
>
> We The occurred error caused by a human error we decided as a long-term
> protection measure to carry out the setup in the 4 AP and all possible
> restrictions in case of test accounts.
> In this way, a repetition of the error is to be prevented.
>

I'm not sure I fully understand this response, but I do want to stress that
"human error" is not really a root cause. The root cause is what were the
systems and controls that allowed that human error to result in the
production incident, and what steps are taken to mitigate that in the
future.