Security Certifications Are Causing More Harm Than Good

> The only time avoiding the certificate entirely is when the signal it provides is negative.

And further, I think all your examples are perfectly valid, real-world examples that I don't dispute exist and that lots of people find important. I also think perfectly good and reasonable people operate in the reality of their industries and play ball with these things when necessary. AND I think all the use cases you mentioned are bad for the system overall. As in, they are real, and in a practical sense we can't just ignore them, but ideally we wouldn't have them.

HR using negative signals for filtering is bad. Job requirements tailored to the actual job are good. Broad and mostly arbitrary requirements from a third party are bad. Applicants to a well specified job also know to address weaknesses in their cover letter. Specific and well-specified requirements are also useful in legal disputes. Using arbitrary requirements to provide legal for firing people is bad. Employers colluding to control the training pipeline using arbitrary requirements encoded in law is bad.

I agree with you that they useful in the real world, but I'm arguing that that usefulness is evidence that the system is worse than it could be.

Whilst there are people that, unfortunately, take the attitude in the article, I think that there's a load of others that take a more balanced approach and recognise some of the value of certifications.

The other thing I'd recommend, if you're not already doing it, is get along to some of the chapter meetings and conferences that there are increasing numbers of in security.

In particular I'd recommend BSides conferences (http://www.securitybsides.com/w/page/12194156/FrontPage) there's loads of them around and they're good places to meet people in the industry and also in many cases the sponsors are looking to hire.

A lot of companies treat these as some kind of mystical incantations that will protect them if sufficiently invoked. Case in point: being mandated to switch from one OTP generator app to another because the latter is "FIPS-Compliant" - regardless of the fact that both generate the exact same set of OTPs.

This cargo-culting is not inherently harmful, but it leads to magical thinking and a false senses of security, as well as diverting time and energy away from more productive avenues.

I suspect that the CISSP-genre of certifications suffers from a similar pathology: intrinsically they do function as at least a partial indicator of some type of competence. The problem is when actors with a financial incentive to game the system meet up with bureaucracies: the less defined but more accurate metrics are thrown under the bus in favour of something that is easy to quantify and sell.

Equally importantly: memory corruption exploit development and SQL injection are different skills, and most people who do SQL injection don't need proficiency in "buffer overflows". Why is superficial coverage of "buffer overflows" part of the rubric for that certificate? I don't know, and I don't know that anyone else does either.

Is there a single coherent security certificate anywhere in the industry? I'm interested in examples.