The “Security is Special” Problem: Cultural Challenge #2

This is the second entry in a series on cultural challenges of application security.

Steve the application security analyst sits down with Jennifer, an application architect at his company. Steve is armed with a series of PowerPoints and PDFs explaining a secure SDLC rollout.

Before Steve can begin, Jennifer starts:

“Steve, we all care about security here. But I’ve got a bone to pick.”

Steve, doesn’t like where this is headed.

“Your team’s penetration testers tested our web application. One of their findings was that our session cookie was missing the ‘HttpOnly’ cookie flag which they ranked as ‘medium’ risk. Now, most of us had never heard of this before the test. We thought it would be simple to fix, but it turns out that the version of application server we have doesn’t support this particular flag. If we wanted to add the flag to our session cookies, it would either entail jury-rigging some rewrite of the set cookie header using a webserver plugin or upgrading our application server. The former is dangerous and unpredictable; the latter is a massive effort. We spent some time researching this “HttpOnly” and found out that this wasn’t exactly an exploitable vulnerability. This was some measure of defense in depth for cross site scripting that some people seem to think is easy to bypass. We had such a massive backlog of features to build and defects to fix, that we decided it wasn’t worth immediately addressing the “HttpOnly” issue. Only, the information security team didn’t agree. You claimed it was a “known vulnerability” and we therefore had a mandate to fix it or have the business sign off on the risk before promoting code to production. We were already running behind on our project plan and the last thing we needed was another delay. Instead of working with my team to code, I spent time *trying* to explain to our counterparts in the business what the heck the “HttpOnly” flag was and why it made sense to accept it rather than hack together a fix or launch a new massive upgrade project.”

Jennifer paused briefly to collect her thoughts, “I’m going to explain to you what I told them. Yes, there is some risk that somebody will exploit another vulnerability because we made a mistake somewhere in code, and yes there is some remote chance that ‘remediating’ this ‘vulnerability’ may result in a slightly lower chance of an attacker taking advantage of a specific attack vector. Yet, the time and money that we spend on fixing this vulnerability represents an opportunity cost. What about the risk of not fixing a defect that affects peoples’ ability to use the system entirely? What about the real, and much more likely, loss of revenue due to a lack of performance enhancements? What about the internal reputation of the entire project team for delaying release of the application yet again? Is the “HttpOnly” flag something we should fix one day? Sure! Should it take priority away from other development simply because it has the ‘security’ keyword attached to it? I certainly don’t think so. I completely understand if you uncover some devastating vulnerability in our system that we should drop everything and fix it immediately. I don’t agree that *every* security issue needs to get special treatment. So, I see that you’re excited to rollout even more security processes for us, just please don’t try and give security an automatic trump card.”

— -

Strained relationships between development and security complicate further application security efforts. Although the sort of frank conversation between security and development above may not be commonplace, the situation Jennifer describes is far from rare. Developers have a mandate to support business goals. If the security team thinks that their issues automatically take precedence over other priorities then there is a good chance that developers will have a strained relationship with security.

Should Jennifer and her team adjust their attitudes towards security, should Steve and the security team change their approach to be more in line with the business, or is this sort of tension inherent between security and development teams? Would you do anything different if you were part of the information security team?

Previous Article
What does the DBIR show us?
What does the DBIR show us?

I just finished reading Verizon’s insightful 2012 Data Breach Investigations Report. As usual, well-known v...

Next Article
Dealing with the Incompetent Developer Problem
Dealing with the Incompetent Developer Problem

In the last entry on cultural challenges in application security series, we introduced the incompetent deve...