some security practice hypotheses

I’m not sure if I jotted these notes down here or not, but wanted to move these from a napkin to something more permanent.

What is the hardest part of security? My thought: Telling someone they’re doing it wrong when they don’t know how to do it right, and you can’t explain it properly. The more technical, the worse it is?

Two examples: First, someone makes a request that is just kinda dumb and gets denied. They come back with, “Why?” And you have to figure out why the value of saying no is higher than the value of just doing it, or what it would cost to accomplish the request while maintaining security and administrative efficiency. (i.e. You want *what* installed on the web server?!) This can be highly frustrating in a non-rigid environment. It’s also the source of quite a lot of security bullshitting.

Second, a codemonkey makes poor code and you point it out. Codemonkey asks how it should be done. If you’re going to point it out, I’d really kinda hope for some specific guidance appropriate to the tech level of your audience. This brings up the pseudo-rhetorical question: Should you be pointing out poor code if you don’t know how to give suggestions on fixing it? (Answer: depends. On one hand, don’t be a dick. On the other, anyone should be able to point our security issues, otherwise people wouldn’t point them out! It’s extremely nice when someone *can* help those with questions, though, with actionable answers beyond just “go read OWASP.”)

And here’s a hypothesis: You’re not doing security if you’re not breaking things, i.e. pushing boundaries. Follow-up: Security pursuit breaks things unless you have expert knowledge and experience.