Why Less Emphasis On Software Security?

Thursday, February 23, 2012

Keith Mendoza


I have observed a disturbing trend when it comes to discussing IT security: that most of the conversation revolves around the securing the physical layer, securing the network, and making sure that the latest patches for the OS and application are installed.

Wait what, make sure the latest patches are installed? How about make sure that the software has been coded securely?

So why not? I think it's because of the mindset. Let's backpedal through the history of computers. Computers as we know it really boomed around the time of Windows 95.

Sure, computers have been around long before that; but, it was a geek toy; and not a visible part of society. Windows 95 was full of security holes, computer viruses were flying around as much as the first 10 elements of the periodic table do. This whole thing got so bad that it was a general rule never to buy the newest version of Windows (at least until Windows XP) until SP1 came out; basically people were expecting it to be broken.

Honestly, I think things just got worst with the proliferation of broadband internet services that even set-top devices have facilities for patching it. Who would have thought that you'll be able to stick a USB drive on the back of your TV to update the firmware?

So, how does the question of "why less emphasis on software security"? It's a mindset issue. The public in general have become desensitized to software patching that it's permeated to IT security.

Yes, I'm blaming the public for allowing software developers like me to write code that could lead to one-off errors, buffer overflow, and NULL pointer dereferencing; basically containing zero-day vulnerabilities. Now that I've pointed out what I feel is the root cause of all zero-day bugs in the world, I'm making a run for it.

The only real fix for this is a mindset shift. At the minimum, software developers need to code defensively regardless of the scope of the project; because, this needs to become a habit.

Coding standards should include requirements that all compiler warnings should be resolved--or document the reason why it's left unresolved. The standards should also require that static and dynamic analysis be done on software.

Considering that many of the open-source software that we use today to run enterprises started out as a curious itch; I believe that a mindset shift will do us a tremendous amount of good in the long term.

Cross-posted from Home+Power

Possibly Related Articles:
Information Security
Application Security Vulnerabilities Development Exploits Secure Coding Standards Software Security Assurance IT Security Programming Keith Mendoza
Post Rating I Like this!
Andy Willingham I think your perspective is schewed by the crowd you run with. Full disclosure - currently I run with a app sec crowd but even beyond that I don't hear much outside of securing code before it goes live. Granted the business most often wants security bolted on later but even so we continue to push our agenda and most that I talk with do the same. Unless I get with some of my old network/ systems security guys then they all talk about patches, av, acl, firewalls, etc... they sound more like the business than security guys. :)
Keith Mendoza That's exactly my point. The app sec crowd talks about it, but then how many of the app sec crowd really gets to make the big calls? Maybe if you're working on a mission-critical software then the app sec team gets to have better say; however, in general the app sec crowd don't get much say. Worst, what percentage of software organization actually have people that are proficient in application security?
Andy Willingham Very true, even the good coders usually stink at secure coding. Actually there is a push in OWASP right now to move away from the core and start focusing our efforts on Joe and Sally Developer. The message has to get beyond the few and out to the masses. As far as making the decisions I'm afraid that won't happen until we run the business.
Keith Mendoza Having that shift within OWASP is great; however, I don't think it will be enough. Unless you're using CGI, every web application is written using an interpreted language. Just think how PERL, Python, and Ruby--to name a few--started, and what language they are written in. We can protect the web app all we can; but, until the people that writes in C/C++ (admit it, all low-level systems are written in one of those languages anyway) starts coding defensively themselves we're building cars with all the bells and whistles and using an engine that seems to blow its gaskets the first instance that it over-revs.
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.