Bug-free and Secure Applications: New Tools and Approaches Required

Developers know less about the technology they are using these days than ever before.

Complex systems, third party black-box components, integrated development environments and code wizards all work to hide "unnecessary" details from the developer.

In an effort to make individuals more productive, we have reduced their knowledge of overall system architecture and how things work. We have hindered developers' abilities to handle many critical things in a sensible manner. And so, in consequence, the rate of production of applications with serious security flaws has actually increased.

Those that do know about issues like system architecture and secure coding are generally more focused on policies and corporate compliance programs and seem to have little impact on the actual code produced by developers in their organizations -- if any of the industry statistics on bugs in applications are valid.

We are looking at a strange paradox: There have never been more developers. There have never been more applications. There are more technologies and solutions available to developers for solving security problems than ever before. Yet, despite this, bugs are more prevalent than ever.

Which begs the question: what is wrong with the approaches that we as an industry are applying to solve this problem?

A simple classification of what has been done to this point breaks things down into two main approaches. The first approach I call "fix the developers" -- which is to turn all developers into security experts -- something which is rather impractical given the many other demands on these individuals and the amount of specialist knowledge needed to be an effective security expert.

The second approach I call "ignore the developers" -- namely to build security systems which operate entirely independently from the application developers. This fails for some fairly simple reasons -- there is no single approach to solving all security problems. Different contexts (or circumstances) require different solutions. The application developer has the details of the context which the security system needs, and so the approach of isolating the developer entirely from security related details precludes access to essential information.

Neither of these approaches is likely to impact the underlying problem of more bugs making it out in application code.

There is no reliable manner for a security system to guess the context of operation intended by an application developer without additional information. How can a security system guess what information is a sensitive financial transaction and what is not without being explicitly informed?

Basically stated, the application developer has the context necessary for the security system to be able to make the appropriate choices in terms of security technologies to use. However there is no clear way for the application developer to communicate that information to the security system in a manner which doesn't involve the developer becoming aware of security related information which they should not need to know. Where the application developer does not have that information they act as the agent of the end user for communicating that context.

If I'm sending details of what changes to make to where my salary is deposited each month, I want that information to be kept private and for there to be verification that it came from me before any action is taken. That's the level at which a developer should be thinking -- not down at the other end where it is S/MIME encrypted and sent over a TLS connection to head office using AES-256 as the cipher with RSA 2048 bit keys and mutual authentication chaining through the corporate trust hierarchy for identity confirmation using the appropriate corporate directory...

Why aren't there solutions which operate at that level -- allowing an application developer to continue to think in terms of classification of information, and the origin and destination of the information flow, in a manner which can then be used to map through to the appropriate security technologies to use? Developers should use their own (existing) vocabulary to describe information.

It is an interesting exercise to visit an organization and look through its security framework and policies, and then start looking at the applications being developed. Generally none of the corporate terminology or guidelines actually makes it down into the systems being produced. This gap is one that should be closed and may require development of new tools and approaches.

In summary:

Context-free application of security doesn't work.

Expecting application developers to understand security is unrealistic.

Defects in applications and development frameworks are here to stay.

Tim Hudson RSA Security, Inc

Post A Comment

Your Name
Your Email	Publish email?: Yes No
Your Blog
Subject
Comment
Verification Word