When Writing Software, Security Counts

When Writing Software, Security Counts
By Matthew Fisher

The life of your average IT Security engineer is becoming more difficult every day. The tools they employ are becoming more complicated and varied, as are the threats they face. On top of that, they must fight a growing tide of hacks against the one thing they can’t control; the application itself.

The majority of IT vulnerabilities in existence today stem from the initial stages of development from either the design, coding, or the implementation of software. In the case of Web application software, hacking the application can be extremely simple and effective for someone looking to steal sensitive information. Since the application is typically the only service exposed over the network, and the least secured, it becomes an easy target for hackers. While they can and certainly do employ attacks against the daemon itself, these often have a limited lifespan since disclosed vulnerabilities in the daemon are subject to patching. There are certainly plenty of undisclosed vulnerabilities against popular Web servers, but these are typically not widely circulated beyond the founding hacker groups. By exploiting flaws in the actual application itself, a whole new realm of possibilities exist, many with few defenses that can be employed aside from actually securing the code itself. Fortunately for the mischievous hacker, most software developers aren’t aware of the multitude of attack techniques deployed against their software. This is mostly due to the lack of education, process and appropriate tools required to secure their code. 

For people who understand application security, this is a bit of a shock as software vulnerabilities have existed for a long time. Take for instance the “buffer overflow” that was first popularized in the classic Morris Worm of 1988. Despite being well known and easily prevented, buffer overflows are still extremely common over 17 years later. Even SQL Injection, which is remarkably easy to fix, was documented in criminal hacks back in 1996; almost 10 years ago. Yet, SQL Injection still lives and thrives on Web sites all over the Internet. Despite firewalls, intrusion detection, and other technologies, Web vulnerabilities such as SQL Injection are exploited on a daily basis. Of course, there’s much more to secure coding than preventing SQL Injection and buffer overflows. Both of these types of attacks are input validation issues, and there are several other input validation attacks as well as many other complete categories of attacks that exist that are not so well known. Learning the complete threat model takes time, but is essential to be able to defend against these threats that show no sign of subsiding.

A common mistake that organizations make in regards to application security is fixating on the security portion and treating it as a matter to be dealt with purely by the security department. In fact, the security group is often times the one least able to do anything about these vulnerabilities since they aren’t likely to be modifying custom code. Typically by the time a security department finds these vulnerabilities, they are likely well beyond the point where the application could be quickly and easily remediated.

In reality, application vulnerabilities need to be treated like any other software defect; early and often. Of course the security department will always perform oversight assessments and will check for application vulnerabilities as part of any certification measures, but the most effective measures are those that take place throughout the entire lifecycle of an application. Years of metrics have proven that finding and fixing functional and performance bugs is easiest, cheapest and generally most effective the earlier they are found. The same is true with security bugs. A developer that has the awareness, education and tools to unit test for security is considerably more likely to produce more secure code than one that does not. Likewise, QA groups should be taught to test for security and given the appropriate tools to do so. Personally, I find QA a very efficient place for security testing for a variety of reasons, not the least of which is the fact that they have the hammer to bear. Development staff are quite aware that their work is not done until it passes QA testing. QA groups are also highly effective at finding bugs and getting them fixed. With the right security testing technology, they can easily begin checking for security related defects alongside functional and performance defects without changing their work process. 

Ultimately, though, it’s the awareness that begins the entire process. All too often developers believe that the security department handles all aspects of security, and that they don’t play a role. Until the full scope of the many ways of attacking software is presented, it’s easy for developers to be blissfully unaware of potential security issues in their code. Once someone shows them all the ways they can create vulnerabilities in their code – often times just by using what are generally accepted (yet poor) coding techniques - they tend to get impassioned about writing secure software, especially if their security is going to be tested by others. After all, no one wants their code to be the chunk that got hacked. But overall, writing secure code is about quality. In the book “Writing Secure Code” author Michael Howard explains that, “secure software is a subset of quality software and reliable software.” Nothing could be truer. As the paradigm of writing secure software spreads, everyone will benefit from the side effects of mature, secure code.

In the end, of course, it’s the decision of the organization. Shops can wait to get hacked or caught off guard by an unflattering security assessment, or can proactively implement a secure coding program throughout their development environment. As SQL Injection goes on it’s 10th year of popularity, I highly recommend the latter.

Comments

• Anonymous
  January 01, 2003
  Matt's written an interesting article sharing his experience "from the coal face" gained during years...
• Anonymous
  January 01, 2003
  Matthew Fisher has written written an interesting article for the Industry Insider's blog which...
• Anonymous
  September 13, 2005
  Err, aren't your chart axes' labels reversed? In other words shouldn't 'Design', 'Build', 'Deploy' be going along the time axis, with the exponentially increasing cost being in the upwards direction??
• Anonymous
  September 16, 2005
  Tony> Thank you for pointing that out - D'oh! What did you make of the article itself?