My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Saturday, March 6, 2004
« Another Application Security List | Main | I am a Lowly User of my Machine »

Randy has an article on Secure Software that is an interesting read.  The main point of his message can be found in the following paragraph:

"Maybe we are writing code as securely as we can. Maybe the flaw is so fundamental to the way that computer science and modern programming have evolved that it is essentially unsolvable using the current framework. Will making software companies liable make their code more secure if software programming as a science is inherently “brittle?” Will enforcing good coding habits ensure that software is more secure?"

I do not believe that we are writing code as securely as we can.  At its most basic level, the problem is one of education, or lack thereof. Developers simply are NOT taught the proper way to write Security to defend against possible attacks.  It is a very rare college curriculum that addresses the issues involved in defensive coding. Oh, they address the issues of software development processes such as Agile Development or RUP or things like OO and Debugging, but not Secure Coding. That mentality pervades the professional software development lifecycle as well, where getting the product out is more important than making a product secure.

As to the question of making software companies liable, my response would be that even if we do, it does not address the issue of custom applications and web sites that are developed and deployed by companies.  And that issue can only be addressed by educating the developers who create the software in Secure Coding practices and educating their management on the value of having robust, secure software products.

As to good coding habits.. What constitutes good coding habits? The book "Code Complete" by McConnell is considered a classic on what constitutes good coding habits.  It places no emphasis on security as part of the software development lifecycle.

There is also the gunslinger mentality of a lot of coders to deal with, that place a premium on fast code vs. Security. i.e. Emphasizing performance over security. You see, Secure Coding is not sexy. But talking about how you wring that last erg of speed out of an application? Now, that is sexy!  The basic premise of trade-offs is simply not something that is discussed all too often.

I saw this demonstrated very vividly in the Blogging world just recently. When the Microsoft Patterns and Practices group (PAG) released  "Improving Web Application Security: Threats and Countermeasures", which is an excellent book on building Secure Software on Microsoft's .NET platform, the response was at most, "Yawn, Ho Hum".

But when the PAG released the beta version of "Improving .NET Application Performance and Scalability", the amount of noise produced would have woken up a dead man!

I found that state of affairs... sad.

So what can be done?

  1. I will quote Michael Howard of "Writing Security" on this one:

    "We need more education regarding secure design, secure coding, and more thorough testing.  A good, well-rounded, three-semester course on systems security would cover general security concepts and threat analysis in the first semester, understanding and applying threat mitigation techniques in the second, and practicing designing and building a real system in the third. The student would learn that systems should be built not only to serve the business or customer but also to serve the business or customer securely. The course should prove the student with balanced doses of security theory and security technology"

  2. Techniques such as Threat Modeling need to be integrated directly into the software development lifecycle. I will quote Michael again - "You cannot build a secure system until you understand your threats"

    Security MUST NOT be an afterthought.  It must pervade every phase of the development lifecycle. The testing process must include security testing in addition to unit and functional testing.

  3. Sample code, feature demos, sample applications that are produced by software companies MUST be reviewed for security best practices before being made available to the public. It is an unfortunate but true fact that lot of the code that is provided in such a fashion is often "re-used" using cut and paste.

    In short WALK the TALK!  Talking about code security, then providing insecure samples simply propagates the "Do as I say, not do as I do" mindset which results in people eventually tuning you out.
We live in a world of connected systems. The age of "irrational exuberance" is over. Billions of dollars worth of business is conducted online on a daily basis. Software is at the heart of that process. At the same time, the day when we can expect a zero-day exploit draws closer and closer.  The process of software development cannot stay as is if software is to survive.
 
 
Tags:: Security
3/6/2004 7:07 PM Eastern Standard Time  |  Comments [6]  |  Disclaimer  |  Permalink   
Sunday, May 8, 2005 12:06:50 AM (Eastern Daylight Time, UTC-04:00)
Secure Coding ?? Blog
システム管理な雑記
Sunday, May 8, 2005 12:06:50 AM (Eastern Daylight Time, UTC-04:00)
Anil,
<br>
<br> Thanks for the throughtful response. I agree that we probably aren't coding as securely as we could be, but perhaps you missed the primary thrust of my argument.
<br>
<br> You are talking about secure coding as an educational issue. Education is great, but it may be exceptionally difficult to make sure that every coder is a &quot;good&quot; coder. In fact, even &quot;good&quot; coders may have to cut corners due to schedules and deadlines. On a small scale this means that it might be possible to write secure software, but as you scale it up it seems likely that inevitably serious security flaws will surface.
<br>
<br> I agree with your point regarding threat models, but again, this is another place where the problem may be the software. Threat models evolve. If you read Ross Anderson's excellent book Security Engineering you'll see that almost all security systems have broken over time largely due to changing environments and hence changed threat models.
<br>
<br> But software itself (in the current model) doesn't elvove to meet the changing threat model. Not automatically. Not without intervention.
<br>
<br> I know I'm out here on the edge of the thought space, but this really goes back to the Lanier article, which I strongly recommend as reading. He really lays out some of the reasons the current systems are so brittle. What it is about the foundations of computer science that cause that brittleness.
<br>
<br> It's not clear what the solution is or what the paradigm shift would actually look like, but what I'm essentially suggesting is that addressing software vulnerabilities head on via education, liability, or other mechanisms may not actually solve the problem. It may turn out that, other than spawning a serious industry built around security products, we can't solve the vulnerability issue without a fundamental paradigm shift in computer science.
<br>
<br> Again, this is all speculation on my part, but I think it's an interesting line of inquiry even if it were to ultimately turn out to be incorrect.
<br>
<br>
<br>--Randy
Randy Bias
Sunday, May 8, 2005 12:06:50 AM (Eastern Daylight Time, UTC-04:00)
Anil John had a nice reply to my prior article. I suggest reading it along with my response to the reply....
Insights into Information Security
Sunday, May 8, 2005 12:06:51 AM (Eastern Daylight Time, UTC-04:00)
SecureCoder by Anil John
Sunday, May 8, 2005 12:06:51 AM (Eastern Daylight Time, UTC-04:00)
SecureCoder by Anil John
Sunday, May 8, 2005 12:06:51 AM (Eastern Daylight Time, UTC-04:00)
Joe Stagner - Frustrated by Design !
Comments are closed.