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