On Mar 24, 2017, at 6:04 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
People don't talk about this enough. A CA is more than just a server or HSM, some scripts and a web UI. It's almost *all* about process and procedure, and as technical people we tend to ignore this.
At a high level, the processes and procedures are largely: - automate as much as possible - have as few people as possible interacting with the CA - track all changes in a revision control system - document all processes - follow all processes :) - keep all security sensitive information on one system - keep it simple Typical CA failures happen when people make mistakes. It is extremely rare that an automated process goes wrong.
I would be interested to hear an assessment of costs in term of staff/FTE equivalent for running a CA, cross-referenced to an independent evaluation of the security of said CA from a process PoV.
The costs largely depend on what the CA is doing. If it's just issuing client certs for EAP-TLS, most fields can be taken from LDAP, and client provisioning can be done via automated tools. A huge percentage of complexity I see in peoples systems is people trying to create custom systems due to custom business processes or requirements. Just... stop. Don't do that. Keeping it simple means it stays understandable, maintainable, and less goes wrong. Complex systems tend to end up as unknown black boxes that no one knows anything about. That way lies disaster. Another anti-rule is *don't out-smart the experts*. The number of amateurs who argue over security is amazing. Yes, PAP in RADIUS is OK. Don't force MS-CHAP because "it's more secure". It's not. It's *less* secure than PAP. Don't believe your local "expert" who's read an article on the subject. Believe the people who've been doing it for 20 years.
Slightly OT: can we have a quick headcount of which client deployment tools people are using to deploy their private CA, ideally annotated with any platforms it *doesn't* support?
This would be good to now, and to document on the wiki. Alan DeKok.