TBH, the OWASP Top Ten is not really a metric, it's a set of general bins of threats. There's no such thing as "passing the OWASP Top Ten".
I think you're going to struggle to establish any sort of objective, general criteria. These protocol bugs are challenging to find and specific to different operational models. Honestly, I think the best thing for the industry is to align around one issuance API so that CAs don't have to keep reinventing the wheel. In addition to all the benefits that come from code reuse, it means that you can go ahead and nail down a bunch of security stuff, so that there are fewer ways for a CA deploying a new API to screw up. For example, several of the issues with the StartEncrypt API have already been raised on the ACME mailing list and addressed in the draft protocol. (And to be clear, though I obviously think ACME is the bee's knees, I would be just as happy to get alignment around *a* protocol.) --Richard On Thu, Jun 30, 2016 at 1:58 PM, Peter Kurrasch <fhw...@gmail.com> wrote: > All good points. I wonder if we need to start with something more basic: > setting expectations. > > Maybe we need to communicate to all participating CA's that we expect them > to perform a security scan of all Internet-facing interfaces. That we > expect each interface to be able to pass the OWASP Top Ten. That we expect > a scan to be performed at least once per year. > > To be sure, that's a pretty low bar but I don't know that all CA's could > pass even that minimal benchmark today. If so, that's a big problem. > > > Original Message > From: Tom Ritter > Sent: Thursday, June 30, 2016 11:57 AM > > On 30 June 2016 at 11:10, Peter Kurrasch <fhw...@gmail.com> wrote: > > Very interesting. This is exactly the sort of thing I'm concerned about > with respect to Let's Encrypt and ACME. > > > > I would think that all CA's should issue some sort of statement > regarding the security testing of any similar, Internet-facing API > interface they might be using. I would actually like to see a statement > regarding any interface, including browser-based, but one step at a time. > Let's at least know that all the other interfaces undergo regular security > scans--or when a CA might start doing them. > > > > Anyone proposing updates in CABF? > > In theory I would support this, in practice it has no teeth. There is > no (real) accreditation for security reviews, and the accreditations > that exist do not, in practice, ensure one with the accreditation is > skilled. You can say "APIs must have a security review" or an > "adversarial security scan" or a "vulnerability scan", or "manual > penetration test", or a "red team assessment" - but the definition of > the terms and the skillsets of people performing them vary so widely > that it would not guarantee very much in practice. > > I believe that the CAs who want to be a leader in this niche already > are, and the CAs who cannot afford to do so (because I assume every CA > wants to take security seriously, but is confined in practice) will > wind up meeting the requirement in a way that does not significantly > improve their security. (And various shades in between) > > But I'm biased, being a security consultant and all. > > -tom > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
