WebApp Sec mailing list archives

Call for panelists: "The role of frameworks (e.g., .Net, Java, Enterprise Library, Struts, JaCorb) in 'forcing' developers to create and deploy 'secure' applications" panel in the next OWASP Conference


From: "Dinis Cruz" <dinis.cruz () googlemail com>
Date: Tue, 3 Oct 2006 03:48:44 +0100

Ok, First a quick apology for sending this request 18 days before the
event (too busy, lack of sleep, changing 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

-------------------------------------------------------------------------
Sponsored by: Watchfire

Today's hackers exploit web applications to expose, embarrass and even steal. Firewalls and SSL may be commonplace but recent studies indicate 3 out of 4 websites remain vulnerable to attack. Watchfire's "Addressing Challenges in Application Security" whitepaper explains what to do and provides a guideline to improving your own application security. Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmw
--------------------------------------------------------------------------


Current thread: