Security types are not known for being agreeable. This makes sense, because we are often asked to do stupid things like blow gaping holes in security just because some schmuck wants to do his/her job more easily. The nerve, what do these folks think- that we are running a business instead of running a secure infrastructure? Oh, crap...
So here's how my standard answers have evolved over the years;
First, (like almost everyone else) I simply said NO to any request. It is a safe answer, you know there is something wrong with every request- insecure, incompatible, can't afford it, etc. But then people start bypassing you, overruling you, or ignoring you- and then you are forced to deploy bad ideas, or worse yet, stabilize and/or secure things after they are deployed poorly.
Next I realized I needed to try to steer things without being an obstructionist, so my standard answer became "Yes, but..." and I listed issues and concerns with the idea in a constructive manner. The results were better, but some folks only heard the word "yes", and then we're back to the same mess as before.
My current approach isn't perfect, but it is another step forward. My answer to requests has evolved into "If you do...". The reactions can be entertaining, people are sometimes shocked to have responsibility for their requests placed neatly in their laps. If someone wants something, make them be involved and responsible for the outcome. Some still won't come around, but some will.
And recently, Allen Deryke suggested another, potentially better, approach: answer with "If we do...". Now you have (ideally) added an element of teamwork into the solution while putting some responsibility on whoever is making the request. You will just have to make sure that you aren't assumed to be using the royal we. There is also a danger that the end-users will think you actually like them, but that's a risk that may be worth taking.
Jack
