On Monday, December 9, 2019 at 2:03:20 PM UTC-8, Matt Palmer wrote:
> On Fri, Dec 06, 2019 at 07:08:46PM -0800, Apple CA via dev-security-policy
> > On Saturday, November 23, 2019 at 3:28:10 PM UTC-8, Matt Palmer wrote:
> > > [aside: this is how incident reports should be done, IMHO]
> > >
> > > On Fri, Nov 22, 2019 at 07:23:27PM -0800, Apple CA via
> > > dev-security-policy wrote:
> > > > We did not have an accurate understanding of how the vulnerability
> > > > scanner
> > > > worked. Our understanding of its capabilities lead us to believe it was
> > > > scanning and detecting vulnerabilities in EJBCA.
> > >
> > > There's a reasonable chance that other CAs may have a similar situation,
> > > so
> > > I think it's worth digging deeper into the root causes here. Can you
> > > expand
> > > on how this misunderstanding regarding the vulnerability scanner came to
> > > pass? What was the information on which you were relying when you came to
> > > the understanding of the vulnerability scanner's capabilities? Were you
> > > misled by the vendor marketing or technical documentation, or was it an
> > > Apple-internal assessment that came to an inaccurate conclution? Or
> > > "other"?
> > In order to identify vulnerabilities, the vulnerability scanner (1)
> > attempts to identify/profile software listening on ports and (2) compares
> > software versions against public CVEs and proprietary data sources. EJBCA
> > is not broadly used software, and the vulnerability scanner did not have
> > custom EJBCA detection logic. Upon our deeper investigation, we
> > discovered that it (1) only scans the HTTP service and not the EJBCA
> > software, which we would consider insufficient on its own and (2) is not
> > as effective at flagging vulnerabilities in EJBCA because CVEs are not
> > published by EJBCA. We don’t feel we were mislead by the vendor.
> Thanks for clarifying how the security scanning software worked; that's
> useful. I'm not confident that we've determined any root causes for the
> failure, though, especially things that other CAs in the ecosystem can learn
> from. I'll try a different phrasing, which will hopefully provide more
> clarity as to what I'm trying to achieve:
> What specific, actionable items would you recommend all CAs undertake to
> remove or mitigate the risk of this, or a substantially similar, problem
> occurring in their environment?
> > CVEs are not published by EJBCA.
> Does anyone else feel that this is a really, really, *really* bad idea? The
> CVE system, whilst far from perfect, seems to be the agreed upon medium for
> managing these types of issues, and it disappoints me that EJBCA would
> appear to be "opting out" of it. Should discussions with EJBCA, either from
> their customers or the wider community, be initiated?
> - Matt
The actions we took are as follows:
* We revisited the functionality of the vulnerability scanner, its ability to
identify vulnerabilities in the CA software, and questioned our previous
assumptions about how it functions.
* We revisited the support and patch management notification mechanisms
employed by the CA software vendor.
* We revisited the Network and Certificate System Security Requirements to
ensure appropriate coverage for the relevant requirements.
* We no longer rely on the vulnerability scanner as a key control to detect
security vulnerabilities with EJBCA.
* We made our review of software releases and decisions about upgrading a key
dev-security-policy mailing list