The Fine Line Between Software Defects and Features

Wednesday, November 09, 2011

Rafal Los


Let me start this post off by posing a questionWhat 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

Possibly Related Articles:
Enterprise Security Software Application Security Development Software Security Assurance IT Security
Post Rating I Like this!
Chris Rich As always, excellent insight. There is a delicate balance between doing what's right versus doing what's right for the company. No two organizations are alike and thus, as a security professional, mechanic, doctor, attorney, or whatever
vocation you pursue you must have the confidence and courage to not only stand up for what you believe is right but also believe that within every problem or risk is an opportunity to benefit the organization.

I believe security professionals and other IT pros posess the potential to take many problems and upend them. I would also argue that technical professionals have a greater potential to leveraging their skills to benefit the business than business rofessionals
have potential to leverage technology. The challenge is deciding when and where to apply the influence, confidence, courage and wisdom within oneself to lead and when to compromise.

If chosen, security professionals may find the tough road of leadership to be lonely but it can also be very rewarding.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.