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-security-policy@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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to