Let me start this post off by posing a question: What do you do when you discover a serious security defect in a piece of software, only to realize that the business has built a revenue stream around that 'feature'?
Many software security professionals are faced with this dilemma all the time. It typically starts out as an analysis done on an application or website being released (typically not a first-release...) where the security professional doing the security analysis discovers a (potentially) dangerous security issue.
This is brought to the attention of the business, at which point we find out that this is not only a 'desired result' but that this is actually a feature (security bug or not) that the business has come to depend on for revenue generation or critical functionality.
As security professionals, we tend to see things in black and white sometimes. When we find a bug in software that has the potential for causing security-related issues, we want to convince the business to fix the issue, remediate the problem that we find. Only thing is, while we see it as a security vulnerability the business sees it as a critical feature.
Juxtaposing the two against each other is not only difficult, but this can also be dangerous for the security professional. Given how difficult it is to walk the line between credibility and outlier in the business - picking a fight over whether a critical function should be 'fixed' or not because it is a security defect... can be detrimental to one's career.
So which is it - a security defect, or a business critical feature?
The answer to this question is often dependent on which side of the business/technology divide you come from. If you're an IT Security professional without too much business acumen, you're almost obligated to call it a defect. Of course anything that furthers revenue generation or adds to the functionality of an application is a feature. Is there a middle ground? And more importantly... how does one find that middle ground?
Even though we've all had the 'feature vs.. defect' discussion many times, it's still something that's relevant to our daily lives. This is, after all, one of the great sticking points in the discussion over whether the role of Information Security should have the ability to stop an application or project from being released. Let's analyze this to figure out just why this issue is so thorny.
The Business Perspective
If you've come from 'the business'... meaning that you generally don't have a technical background and don't understand the finer points of security bugs, you're likely to dismiss the criticality of the security analyst's finding. This puts you and your organization at a grave disadvantage, because technical understanding is key.
It's long been said that Information Security professionals, particularly those who have a techie background simply don't understand the finer points of business, and can't make decisions based on that missing understanding.
Sometimes it's OK to accept risks like a defect if the business depends on it for revenue, functionality, or competitive advantage. After all, technical analysts tend to miss the forest for the trees, so to speak, and often overlook the business value of a decision they're making. This is why the business likes to have managers from its own ranks making decisions that affect the company at a much higher level.
The IT Security Perspective
Fair enough point about technical analysts missing the 'bigger picture'... but if you don't understand details you are often grossly misinformed, and cannot possibly understand risk if you don't understand the basics.
Defects are defects, and if you're risking corporate reputation, client data, or creating an open avenue for attack because you don't quite understand the technical severity of a situation - I would argue you're not qualified to make that assessment. Sure, a business feature can make help the application do something spiffy, but there are likely other ways of accomplishing the same feature without creating security risks... and someone analyzing the situation from a business perspective won't get that little detail.
It's like the manager of a repair shop where you drop off your car for service making decisions about whether an issue the mechanic found is critical or not. Personally, I'd rather the mechanic make those decisions, especially if the manager has never turned a wrench or changed a spark plug in his or her life... I'm fairly certain you'd agree.
So now we have a problem... because both viewpoints appear to be valid. How do we overcome this?
There is hope for a solution, but it's not easy. The only way to overcome that great chasm of understanding between business goals and technical aptitude is a strong dialogue, mutual respect and an open mind. While it may be hard for the IT Security analyst to understand why a risk is good for the company, it's critical to understand that it's probably just as hard for the business analyst to understand why one little cross-site scripting issue is such a big deal. Dialogue is key.
There needs to be a middle language developed inside your organization that both sides can understand, and that comes from mutual trust, acknowledgement of your own deficiency (this means "drop the ego"), and willingness to do what's right for the company above all else.
Cross-posted from Following the White Rabbit
