Ok, First a quick apology for sending this request 18 days before the event (too busy, lack of sleep, charging kids nappies (or diapers for the US crowd), etc... :)

In the next OWASP conference in Seattle, which will happen on the 17th and 18th of October 2006 (see http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006/Agenda) I managed to convince the organizers (thx Dave) to add the following panel to the line up

Thursday 17th,  16:50-18:00 : "The role of frameworks (e.g., .Net, Java, Enterprise Library, Struts, JaCorb) in 'forcing' developers to create and deploy 'secure' applications. Moderator: TBD Panelists: Dinis Cruz, OWASP .Net Project Lead and others TBD "

The problem is in that last line: "Moderator: TBD Panelists: Dinis Cruz, OWASP .Net Project Lead and others TBD" since at the moment it is only me :)

So I am doing this public call for panelists in the hope that I will find the right ones.

Ideally I would like a strong representative from the following camps:
  • .Net CLR guru (with strong background on CAS (Code Access Security))
  • Java JVM  guru (with strong background on the Java Security Manager)
  • Struts guru (with a focus on Struts as a security layer), or other 'developer focused' frameworks
  • Web Application Security Consultant (somebody focused in 'breaking applications')
  • Business manager (somebody whose job is to create/deliver applications, and will bring to the table the 'business mind' point of view)
To finish off this email here is a quick abstract of what I want to discuss in this panel:

" The role of frameworks (e.g., .Net, Java, Enterprise Library, Struts, JaCorb) in 'forcing' developers to create and deploy 'secure' applications

From a security point of view, the current development paradigms are mainly based on the concept of 'making no errors'. I.e. if only the developers (and the Software development Livecycle that is supporting them) are able to program 'securely'  (what ever that might mean), the security vulnerabilities that we have today will cease to exit. Basically it is the concept of the 'Big Wall of china'. There are some efforts in 'defense in depth', which most of the time are either: a) not implemented, b) only designed to protect the server and not the assets (for example the idea of executing the code under a non-admin account) or c) too complex.

This creates an environment where the application asset's CIA (Confidentiality, Integrity and Confidentiality) can be compromised via one single mistake (created accidentally, by lack of knowledge or  'deliberately' ), such as: SQL Injection (the buffer overflows of Web Apps :) ), Authorization/Authentication blind spot, Application logic or malicious file upload/execution.

Part of the problem is that this requirement ('make no mistakes') applies to 100% of the code, since all code is executed under the same privileges (from the point of view of the assets). This means that we (the developers and security good guys) need to protect and worry about 100% of the code base (which given a large enough application is just impossible). Basically, we need to be able to "security and safely handle malicious code or benign code manipulated in a malicious way"

For me the solution is to create a development model where 85% or 95% of the code base is executed in an environment that doesn't have major security implications). In this world, the exploit vector would have to be in the remaining 15% or 5%, which would be the code base that would be audited, closely analysed and in some cases certified.

My view is that this world would deliver secure applications (and an environment where it would be commercially viable to do so), because most developers would be focused on what they are good at and are paid for ( i.e. features, performance and user experience) and only a small number of developers would be involved in security related activities.

And of course, the way to create this world is by using development frameworks that 'force' the developer(s) to program is such a way' (and having enough enough commercial preasure).

So what I what to talk about in this panel, is how to we get there (and 'are development frameworks a big part of the solution?').

Currently there are two main approaches to solve this problem: There is the 'Operating System' camp, and the 'Managed Environment' camp

Examples of the
'Operating System' camp are Microsoft's Vista, SELinux and AppArmour

Examples of the
'Managed Environment' camp are the .Net Framework (or mono) and Java

The only one that has any real momentum today is the
'Operating System' camp, and in the 'Managed Environment' camp most of the code (probably 99%) is executed in an 'unmanaged environment' (Full Trust in .Net or with the Security Manager/Verifier disabled in Java).

Unfortunately,
due to the enormous attack surface and the fact that most of the assets are located at the user/identity layer, the
'Operating System' camp is fighting a lost battle (look at Vista's UAC mess and reimplementation of CAS (Code Access Security) at the OS level (best example of this reimplementation is the new Vista Network permissions for processes (which will not work as expected, ironically mainly because of the problems that CAS has today: Policy, Complexity, Perceived value and ultimately Lack Effectiveness))

As you can see in my previous posts, I put more faith in the
'Managed Environment' camp, but at the moment there is no major focus in this direction. My view is that we will have to wait 1 or 2 more years until Vista, Mac Os and Linux show how their are not able to sustain 'unmanaged' malicious code.

So, if you have strong opinions on this and have an active role in either camp, join me on this panel at the next OWASP conference."


Best regards

Dinis Cruz
OWASP Autumn of Code 2006, http://www.owasp.org/index.php/OAC
OWASP .Net Project, http://www.owasp.org/index.php/.Net
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Reply via email to