| It might be fair to characterize my position as "vague but comprehensive"...if that's even possible? There are some standard-ish frameworks that could be adopted: - NIST has an existing framework that is currently going through some sort of update/revisory process. http://www.nist.gov/cyberframework/ - ISO has 27032:2012 which looks to have some good stuff in it. https://www.iso.org/standard/44375.html - Perhaps surprisingly enough, the American Institute of CPA's has a variety of information that looks to be a good starting point for anyone. http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/cyber-security-resource-center.aspx I would be interested in knowing if other people know of other frameworks and have experience using any of them. I'm certainly not advocating that any of the above be used here or that they are necessarily even good resources for folks in the CA space. Back to laughable security, my issue is that there are many ways an organization might experience a security breakdown in ways that cause severe face damage to security folks due to either excessive face palms or banging ones head against the wall or even laughing too hard. Examples include: allowing week passwords (by employees), poor password management, inadequate access controls, weak network intrusion detection, insufficient protection from well-known web application vulnerabilities (e.g. SQL injection), and the list goes on. If you'd like to keep the policy to a sentence or so, perhaps we could use some "including but not limited to" verbiage?
On 23/05/17 04:18, Peter Kurrasch wrote: > I think the term "industry best practices" is too nebulous. For > example, if I patch some of my systems but not all of them I could > still make a claim that I am following best practices even though my > network has plenty of other holes in it. I'm not sure that "patching half my systems" would be generally accepted as "industry best practice". But regardless, unless we are planning to write our own network security document, which we aren't, can you suggest more robust wording? > I assume the desire is to hold CA's to account for the security of > their networks and systems, is that correct? If so, I think we should > have something with more meat to it. If not, the proposal as written > is probably just fine (although, do you mean the CABF's "Network > Security Requirements" spec or is there another guidelines doc?). Yes, that's the doc I mean (for all its flaws). > For consideration: Mozilla can--and perhaps should--require that all > CA's adopt and document a cybersecurity risk management framework for > their networks and systems (perhaps this is already mandated > somewhere?). I would expect that the best run CA's will already have > something like this in place (or something better) but other CA's > might not. There are pros and cons to such frameworks but at a > minimum it can demonstrate that a particular CA has at least > considered the cybersecurity risks that are endemic to their > business. If we are playing "too nebulous", I would point out that to meet this requirement, I could just write my own (very lax) cybersecurity risk management framework and then adopt it. Any requirement which is only a few sentences is always going to be technically gameable. I just want to write something which is not easily gameable without failing the "laugh test". Gerv | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
