Apr 12

Talking with Security Doubters

By terranceacrow | Techniques

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.

Mar 11

Security: Not Just for Banks Anymore!

By terranceacrow | Justification

Let’s say you’re a responsible corporate citizen. You want to retain customers and attract new customers. Maybe you architect applications, maybe you design them, or maybe you code them. If you’ve every brought some aspect of application security — say, you point out it’s a really good idea to disallow cross site scripting (XSS) — I bet you’ve run into opposition like:

  1. We’re not a bank! We don’t need all that security.
  2. We’re not a military installation. Why would we waste time and resources on security?
  3. We don’t have any sensitive information. Why are you trying to slow the development process down with useless security?
We're not a bank! Why do we need security? Answer: You don't -- if you don't care about customers!

We’re not a bank! Why do we need security? Answer: You don’t — if you don’t care about customers!

Those might have been legitimate questions sometime in the past. When, I don’t know, but I’m trying to be charitable here. The point is, those questions are invalid now. Why?

  1. Money isn’t the only thing malicious actors steal. Personal information, log-on information ( typically an e-mail address), or even just source IP addresses can be useful to them. In other words, if you have an application on the Internet, it’s of interest to malicious actors. How will your existing customers react if your site’s compromised? Will such an event help or hurt future potential customers?
  2. Sure, securing military installations is critical. But so is securing your installation! Ask doubters this question: if a malicious actor were loose on your servers, what havoc could they wreak? How would your customers react to receiving spam from your compromised servers? Would potential customers be more or less likely to consider you if they know your reputation through spamming?
  3. Your site may not store personally identifiable information. You might not store financial information. But you store something — or you wouldn’t have an application! How would an existing customer react if they find their data spewed all over the Internet — even if it’s just a record of which cat pictures they looked at? Would you join a website that allowed such shenanigans?
Would you use a site that you can't trust? Would your customers?

Would you use a site that you can’t trust? Would your customers?

It’s not even accurate to say security isn’t optional. It’s more accurate to say that security is a requirement, just as important as any other business or technical requirement. Not taking security into account means increasing the risk of losing existing customers and decreasing the chance of obtaining new customers.

People who ask questions like the ones above simply don’t understand what they’re asking. We’ll talk about how to deal with them in the next post.

Jan 07

Content Coming Soon

By terranceacrow | Uncategorized

In the coming weeks, please expect to see training modules to describe how to protect your application against real internet threats. I’ll focus on two environments: PHP and Java/Tomcat. However, the concepts will be universal.

Plus, instead of providing isolated chunks of code that might be hard to understand out of context, I’ll provide working demonstrations that you can download and work with.

I’ve developed more years than I care to count, and I’ve seen technology change a lot. But one idea has remained constant: as developers, we want to write code that delights the people who use it. I’m going to show you how to make your delightful code even more delightful by protecting your users’ data, keeping it safe, and keeping it available to them.