Talking with Security Doubters

Surrounded by Doubt…

In my last post, I talked about a scenario designers and developers know all too well: well-meaning management, project managers, architects, and business staff who don’t believe security is important — or don’t believe it’s important enough to warrant your time. Many of these doubters have direct input into the amount of effort you can spend on a project. If you’re a developer who knows what can happen when you ignore customer’s demands for reasonable security, what can you do?

Put Down the Stones!

nostonesFirst, let me address a tendency we have as developers. You are burdened with knowledge of how to get things done.* If you’re security conscious, you understand what insecure code or coding practices can do to customer trust. We tend to get frustrated or angry when people try to override our coding experience with their own priorities.

Becoming angry, though, won’t help. At best, they’ll just ignore you and label you a prima donna. At worst, they’ll just call you a prima donna and put you on work improvement because you’res not being a team player (in their eyes). But if (justifiable) anger’s not the answer, what is?

A Better Approach

Back in 1997, a modern philosopher named Don Miguel Ruiz came up with The Four Agreements to guide how we interact with others and ourselves. I’ve found them to be an effective way to advocate for security on behalf of the customer. Those rules are:

  1. Be impeccable with your word: Don’t be over the top or hyperbolic. Clearly and honestly state the requirements as you see them to your manager or team leader.
  2. Don’t take anything personally: Chances are, the folks arguing with you are just trying to meet their obligations and go home for the day. Unless you’ve knifed them (or one of their loved ones), it’s unlikely they’re attacking you personally.
  3. Don’t make assumptions: As developers, we tend to have a precise vocabulary. To my astonishment, I’ve learned not everyone’s like that (how do they even get to work without such precision?). Don’t assume they’re an idiot for not agreeing with you. Also, don’t assume you’re right! Even security requirements are subject to input from budget and risk. Management may have heard your pleas, considered them against the application’s risk posture and/or budget, and decided they could afford the risk.
  4. Always do your best: Represent your profession in the best way you know how. Don’t consciously exclude a security requirement without at least making your team leader or immediate supervisor aware. You could do worse than having the reputation as that “developer who’s always worried about security!” If you’re always striving for your best, you can still move your skills forward — even in a security-poor environment.

SometimesCantWin2Unfortunately, that last point is important: Sometimes, despite your best efforts, despite your eloquence and tenacity, despite your well-reasoned arguments and appeals to customer satisfaction, the team may decide not to incorporate the necessary security controls. They might elect to allow unfiltered input under the reasoning that the code uses stored procedures, so it’s safe. They might not understand that the input might include cross-site scripting (XSS) attacks that could ensnare a browser displaying the data. After all, security is only as strong as its weakest link. What can you do then?

As I see it, you have two choices:

  1. Accept the decision and keep working: If you enjoy working with this team, accept the decision and keep working. Certainly, keep a log of your concerns (e.g., keep the e-mails you sent warning of the security vulnerability) in case someone tries to blame you later. But otherwise, keep studying security on your own so your skills don’t stagnate. Also, hope the team will take your advice the next time!
  2. Find another job, give your two-weeks’ notice, and move on: If you find that no one’s listening, if you see customer data being compromised (especially if that data personally identifies a customer or reveals their health care data), it might be time to move on. You don’t want to lose your edge by working the architects, designers, or developers who don’t understand security. Again, keep a log of your efforts to make the team aware so they don’t try to frame you, but graciously move on. And don’t burn the bridges behind you! You never know when you might need to make a strategic retreat!

The real shame is that writing secure code is not materially different from writing insecure code. In fact, I’d argue that it’s actually less expensive, since the resulting code requires less operational support and is less likely to embroil the company in an inadvertent data disclosure. Those things take a lot of time to manage and correct! And that’s not even counting potential legal fees as the US Federal Trade Commission begins to get involved.

Always advocate for doing the right thing. It sometimes doesn’t seem worth it, but you have to live with you, so you might as well act in a way you can respect!

In the next post, we’ll take a look at giving your security concerns a sound foundation.



* After all, we’re the ones who tell the program exactly what to do and when to do it. The business team has more knowledge of why things are happening, but when it comes to exactly what’s happening, we’re at the epicenter.