(circa 2006) Why Novell should take on the 'type-safe platform' challenge

Following a recent twitter thread with Miguel de Icaza, I (successfully) googled up a older post to the SC-L list written in 2006,where I tried to make the business case for Novell to invest in CAS (Code Access Security). After reading and realizing that (sadly) most of it is still relevant today, I'm reposting it here (to make it easier for later relinking)

(for more CAS and Sandboxing related ideas see this PPT 'Making the case for Sandbox v1.1 - Dinis Cruz - SD Conference.ppt ' and this blog post 'Past research of Sandboxing and Code Access Security (CAS)')

Here is the SC-L post that I wrote in 10 May 2006 (link to original which was a reply to Gary's Microsoft's Missed Opportunity Dark Reading post):

Dinis Cruz wrote:

> The ones that I wish were listening are Novell and the Mono project.
> The path to a type-safe platform could start there.

Following this comment made on the previous thread, here are the reasons why I wished Novell and the Mono project where listening to that conversation (note: an edited version of this post was sent directly to several Novell contacts who asked me 'What is it you wish we would listen to?' :

---------------------------------

Dear Novell

What I meant by my comment, is that there is an opportunity today (2006) for somebody (namely a company + community) to really grab the 'type-safe' + 'sandboxing' flag and run with it.

Here is a quick analysis of where we stand today:

    - Vista failed to deliver a OS based on a type-safe platform
    - 99% (or close) of the .Net Framework and Java code is executed in an environment with no sandbox (i.e. executed: a) in Full Trust, or b) with the Security manager disabled, or c) with no verification). Given the amount of code deployed out there, there is no chance that a real change will occur any time soon. Currently there is no interest from Microsoft or Sun to address this issue and invest the time, energy and resources required to solve it.
    - Microsoft failed to make the paradigm shift from Full Trust to Partial Trust when they released v2.0 of the .Net Framework (which would had been the perfect time to do it)
    - There is good grass roots support for type-safety
    - There is a growing need to create secure and trustworthy applications (with growing support from Governments, Large Corporations and ultimately the end users)
    - Sandboxing at the OS level, like the one in Vista's 'Integrity Level / Privilege Isolation' and in Suse's AppArmour (sorry Crispin for not replying to your posts on the previous SC discussion about Sandboxing (it is on my to-do-list)) will NOT prevent exploitation of the user's assets (like for example the user's email). These techniques are designed to 'control' and 'Sandbox' unmanaged code, which is something that I don't believe can be done today. A short term solution (before we get to type-safe OS) would be to have environments like these (which do add some security protection to the OS) supported by a managed/verifiable environment responsible for executing the managed/verifiable  (potentially malicious) code.
    - Apple has an amazing OS (which I am using at the moment) but doesn't seem to be focused on type-safe / sandboxing issues too. Apple also seems to (like most of the Open Source community) think that it is immune to security vulnerabilities (just look at the way they handle security patches at the moment)
    - Novell has gained a huge amount of respect for its support for the Mono-Project and for its support for Open Source
    - Basically, Microsoft has lost the plot on Security and (as Gary McGraw says) is too focused on bugs and not on architecture. They (Microsoft) will have tough times ahead when Vista proves to be as secure as XP SP2 was.
    - IBM has seen the future and is re-organizing itself around the concept of 'delivering enterprise solutions on top of Open Systems and Open Architectures'

So, like I said above, there is a big opportunity for an Open Source project, lead by a major company and based on a solid platform, to lead the way in the move from unmanaged/unsafe code (where I am including Full Trust .Net code in this category) to managed, verifiable and type-safe code (which can be safely executed in Sandboxes and malicious activity easily detected / mitigated)

Novell and Mono fits this bill perfectly.

And it would also give mono an unique point of sell, since at the moment it is still a 'pour cousin of the .Net Framework'.

Ultimately the goal would be to build an OS on of top of a type-safe platform. But before that the user-land world needs to be conquered.

A lot of research and effort must be placed on how to create powerful, feature-rich and fast GUI applications built on type-safe code. This is something that can only be done by a large community focused on a powerful goal: creating secure applications for execution on secure/sandboxed environments.

Imagine if this idea could be developed to such a state where (on Windows) it would be safer to execute C# applications on Mono than on the .Net Framework itself! (another area where mono could do really well is in Hosting of Asp.Net applications (for example based on a Linux distribution of a LAMM environment, hosted by a VirtualServer or VMware host))

I believe that we are watching today the limitations, of both Open Source world (with its 'many eyeballs') and Proprietary Code (with its Secure Development Lifecycle) to create code that doesn't contain critical security vulnerabilities (i.e. both can't do it (with maybe some notable exceptions)).

What is needed is a new paradigm (well not that new if you ask Gary McGraw) that creates a financial-model that rewards the companies that are able to create secure applications that can be executed on secure environments(the idea is not to prevent bugs/vulnerabilities from existing, but to prevent the damage caused by their exploitation).

Ultimately all source-code will have to be released and made public (not necessarily on an Open Source format, but at least available to peer review and external (i.e. independent) analysis) , and again here Novell and the other Open Source development companies have an advantage.

The other major asset which the Open Source distributions have (and one which will be crucial in the future) is the centralized distribution of Software (i.e. packages). In the future we will need entities that certify the security of Software applications, which in an unmanaged-code world (for example: C++ & Full Trust .Net ) is almost impossible to do (i.e. say for sure that Application XYZ does not contain a keyboard hook and direct access to the Internet), but quite possible in a managed, type-safe and verifiable world.

Of course that more CLRs (with custom GC, Security managers, Class loaders, verifiers, etc...) will need to be build, since the requirements of a powerful Windows Application, are very different from an Asp.Net Form, which are very different from a Device Driver.

Looking forward to your comments,

Best regards,

Dinis Cruz

OWASP for Charities: Haiti relief effort

There are days that I am really proud of being part of the OWASP community, today is one of those days :)

The email below was just sent to all subscribers of an OWASP mailing list or has an @owasp.org address (about 10,000)

OWASP Members and Supporters,

OWASP was founded, and is supported as a non-profit organization, by a group of dedicated volunteers who believe that all applications should be secure and trusted.  As our organization matures we have taken those beliefs broader, and have started setting up ways for our members to donate to the global community.  Among these initiatives are:

• OWASP has an active Kiva lending team who have donated $9,125.00 to date.  http://www.kiva.org/community/viewTeam?team_id=522
• OWASP in response to the need in Haiti has set up a secure and trusted way for those within the OWASP community to donate funds to help the people of Haiti. This allows our OWASP community to help another with a single global voice.  100% of the collected donations will be transferred directly to victims for disaster relief such as food and medical requirements.  Please visit www.owasp.org and click the link for G33k-4-HAITI.  In a time of crisis, OWASP can help those who are in great need. The OWASP community can help organize, support , and promote efforts outside of application security.

OWASP is well aware there is a movement for phishers to utilize this tragedy to get unsuspecting people to donate to a “cause” without having a legitimate business back end and ultimately funneling all the money directly into their own pockets.  The OWASP community is uniquely qualified to help protect from this type of attack and educate about attacks as well.

As the world becomes more dependent on technology and particularly web applications, there are many who need protection who simply have no options to protect themselves.  These include small companies, individuals, charities, and others.  The OWASP community can help by connecting qualified, trusted resources willing to volunteer their time to those organizations which qualify. OWASP is setting up an outreach program, which will be under the name project name of OWASP for Charities.

We hope you will support OWASPs efforts to make a difference  in any of the above ways. We are also open to suggestions in regards to where you feel the OWASP Community can be of service.

Regards,

Your OWASP Board

Kate Hartmann

OWASP Operations Director

9175 Guilford Road

Suite 300

Columbia, MD  21046

A couple more comments on ESAPI and ESTAPI

Following my recommending ESAPI? post, there has been some great answers and comments (on both SC-L and esapi-user list). Here is a great recent blog post on EASPI : What is the ESAPI?

To help to clarify why I asked those questions (and my chain of thought) here are two extra entries with my personal opinion. The first one is a post that that I started writing a couple days ago, and the 2nd one,  is a response I just posted on the SC-L and esapi-user mailing lists: 



1st one (note that some of the questions asked here are already answered in some of the comments to the original post)

My position is that ESAPI is a great example of what an enterprise security API should look like. But we have to be very careful when we say 'use ESAPI', because we risk that people actually use ESAPI on their applications (i.e. download the jar and copy it into their application, and use it)

I think we need to be careful to do this recommendation for several reasons.  The first one is that when we say 'use EASPI', we are basically positioning ESAPI in competition with all the other frameworks (including J2EE in this case, for the Java side of things).

The second one is we have to provide much more visibility to the bits of ESAPI that are ready to be used in production.  My understanding is that there are a lot of modules in ESAPI and not all of them have the same level or quality or readiness.

Some of our target audience is going to be developers without a lot of experience in application security, but who want to implement their security controls/features right, So we have to be very, very clear, whether we are providing them with the right advice on ESAPI, namely on which modules are actually enterprise-ready. (for ex: Is it just the encoding module or the logging module?  Or is the authentication module also ready for enterprise or application use?)


For me, part of the solution is to explicitly break ESAPI into three parts.  


The first one is the interfaces.  Basically, the security controls that an ESAPI API or ESAPI compliant framework should have.  

The second one should be a reference implementation(s), which is what we have today (and is the one that should be commercially supported by third parties).

The third one, are unit tests for the interfaces.  This is a bit where I'm actually quite interested, and I call these the ESTAPI, which is the Enterprise Security Testing API.  


I think that is a really valuable asset that we need to implement asap (staring by extracting what is already inside the ESAPI implementations). With ESTAPI , we will have a particular set of tests for a particular 'security sensitive behaviour', for example: "...If you are doing encoding for HTML, this is what you should do.  If you are doing encoding for Javascript, this is what you should do.  If you are doing encoding for HTML attributes, this is what you do.  If you are doing encoding for exec inside a Javascript block...., if your are doing authentication...., if you are doing authorization, ... if you are implementing a password reset... ,..etc., etc.  ..."

With the ESTAPI,  I'll be able to run these tests against all supported frameworks, whereby for each framework, all I need are little connecters between the ESAPI interface and the particular framework functionality/behaviour. Then we will be able to test the frameworks for their security capabilities.  I think this will actually provide a much more pragmatic and much more objective analysis of the framework,   allow the mapping of the supported security controls & behaviour, and allow the framework's clients to have much more visibility into what's happening on those frameworks.  

Again, I don't want to put ESAPI down.  I think ESAPI is a great project.  I think it's one of the most successful and powerful projects for OWASP and we just need to clarify it a little bit.  In fact, I think the more successful ESAPI is, the more this becomes a problem.  I don't think ESAPI  has blown up yet because ESAPI hasn't reached a wide level of adoption by software developers or commercial applications.  


Remember that one day we will have to deal with the problems of applications built on top of ESAPI that have security vulnerabilities or that are being successfully compromised by malicious hackers.

2nd one (posted on on mailing lists)

My view is that the key to make this work is to create the ESTAPI, which is the Enterprise Security Testing API

This way we would have (for every language):

• ESAPI Interfaces - which describe the functionality that each security control should have
• ESTAPI - Unit Tests that check the behaviour of the security controls
• ESAPI Reference Implementation(s) - Which are (wherever possible) 'production ready' versions of those security controls (and  in most cases a one-to-one mapping to the ESAPI Interfaces)
• Framework XYZ ESAPI 'connectors' - Which wrap (or expose) the security controls defined in the ESAPI Interfaces in Framework XYZ

What I really like about this world, is that we (Application Security Consultants) we start to create standards for how Security Controls should behave. and (as important) are able to work with the Framework developers without they felling that ESAPI is a 'competitor' to they Framework. After all, the way we will really change the market is when the Frameworks used by the majority of developers adopt ESAPI (or its principles)

Of course that the Framework developers are more than welcomed to grab large parts (or even all) of the code provided by the ESAPI reference implementation(s). But the key is that they (the framework developers) must: a) take ownership of the code and b) respect the ESAPI Interfaces.

And hey, if the Framework developers decide NOT to implement a particular security control, that is fine too. 

BUT! 

I would at least expect them to provide detailed information why they made that decision and why they chose NOT to implement or support it (which would allow us (Security community) to respectably agree or disagree with their choices (hey for some Frameworks, being insecure is a feature :) )

Finally, In addition to all the advantages that we will have when frameworks adopt these security controls, there is one that for me is probably the MOST important one: An 'ESAPI compliant app' (which btw is a term we still have to agree what exactly means),is an app that is providing explicit information about where they (the developers) think their (the app) security controls are located.

In another works, via the ESAPI Interfaces (and the ESTAPI tests) the developers are actually telling us (the security consultants): 

  a) what they think their application's attack surface is and  

  b) what is the security behaviour that they have already tested for

Of course that they can game the system, which is why we (Security Consultants) will still be needed (we will also need to make sure that they implemented the security controls properly). But compare that to today's (2009) world, were we are lucky to get an up-to-date application diagram and a reasonable accurate description of how the application was actually coded and behaves. 

This would also (finally) give the application security tools (white, black, glass, gray, pink, blue) a fighting change to automatically, or operator-driven, understand what is going on and report back: 

  - what it knows (security vulnerabilities) and (as important) 

  - what it doesn't know / understand
(ok there is a lot more that these tools will provide us (for example ESTAPI tests) but that is a topic for another post)

So, for me, the key added value of the ESAPI Interfaces, is that it will provide us (Security Consultants) a way to understand how the app works (from a security point of view) and to be able to finally be able to give the clients what they want: Visibility, Assurance and the ability to make 'knowledgeable Risk-based decisions'.

On Comments on Static Tools thread and Frameworks

Here are some comments on the comments made on the .. thread:



@Andrew: you touched on a very important point which is the importance of the 'operator' (i.e. the knowledgeable user). As per the points you make, I really think that we need to take into account its impact.


For example, we should measure the following:
A) can a tool find Issue XYZ using every trick in the book? (i.e. tool + operator + customization)
B) can the tool be customized so that It can find that issue XYZ without requiring an operator?
C) once customized can the tool find similar issues (to XYZ) automatically
D) can the tool find issue XYZ (and similar) automatically without any customization


You comment was not boring at all :)   Are you interested in helping on creating this test/evaluation environment?


@Romain: 1. Yes I am focusing on 'traditional' web frameworks (Java, .NET, PHP, Python, Ruby, etc..) so I  did not mention the C++ ones
2. we are going to have to agree to disagree on this one :)   . In fact in your answer you already provided a couple examples of why public and pear-reviewed test cases are so important :)
3.  Yes NIST (via SATE) has been trying to improve visibility into this space (and thx for the link to the report which I will read the report properly http://samate.nist.gov/docs/NIST_Special_Publication_500-279.pdf), as we move along this process I really want to make sure that all the great work done already by you (and others at NIST) are taken into account and used. My plan is to use the O2 Platform to address some of the issues you had (for example having pragmatic ways to compare the different tools results and allow the use of multiple sets of data (like results created using advanced customization and results created using NO customization))


----


Also,  I just found this comment from Neil MacDonald For Static Application Security Testing, Frameworks Matter which is absolutely spot on! Frameworks ARE the key issue on Static Analysis, because without it, the tools have no idea what is really going on: 


from Neil's post: "...Bottom line: if a static analysis tool doesn’t have an accurate understanding of the underlying framework, it can’t generate an accurate model and the analysis will be incomplete, resulting in at least false negatives. This is true for any of the languages a SAST tool may scan, not just Java and this is true of any SAST tool – whether analyzing source code, byte code or binaries.
When a SAST vendor says they support “Java” or any other language, dig deeper...." 

Update #4 on OunceLabs/IBM Relationship

Following the previous posts on this topic (see Update on O2 & Ounce & IBM, Update #2 on O2 & IBM - 02 Sep 09 , Update #3 on O2 & IBM ) here is an update of how the first chapter was concluded.


After some internal debate, IBM decided that the time was not right for them to provide commercial support for O2, so instead of waiting around in IBM land, I made the decision to not accept the contract that I was offered (see why I said NO to IBM for now), which had the practical consequence that my contract with IBM ended on December 31 2009.

This means that I am now (Jan 2009) not 100% booked, which has the positive side effect that gives me the opportunity to focus on the O2 adoption by the community  :)  (btw, feel free to ping me if you have O2 related projects)

In some ways, I don't think that IBM was ready for O2.  IBM is still digesting Ounce Labs, and in some ways, they need to go through that process before they can look at the next generation of what the products should do (which is basically what O2 represents).

From my limited exposure to IBM, Rational and AppScan teams, It looks like they currently don't have the internal structure to be able to fully support the work that has been done at O2, and I think this step (going outside IBM for a while) will probably be an easier way to get O2 used (as a core platform) by the multiple IBM AppScan, Rational, ISS or Jazz products and teams.

That said, a very positive development of the additional resources that IBM is putting into the ex-OunceLabs team (now AppScan Source edition), is that they are now looking seriously at the features in O2 that should be added to their roadmap and eventually into the product (which is what I always wanted to happen).  In some ways, if you are an Ounce/IBM customer,  now is a good time to put pressure on them for your favourite O2 features to be implemented ASAP.

Just to be clear, there are no hard feelings between me and IBM, and we still have a good working relationship (non-paid at the moment).

My understanding is that IBM is telling their customers using or evaluating Ounce (AppScan Source Edition), that if they want some O2 customizations or services, they should either contact me directly or go via the companies that are able to provide O2 customization, services, consulting.

This IBM position is very important to the market, because it clarifies the current situation and opens up the market for companies who want to provide commercially related O2 services  (ping me if you want your company to be part of this group).

In a way, IBM is choosing not to compete directly on this space, preferring to focus their energy on their core products and making sure that the best O2 features are implemented quickly on AppScan Source Edition (and others)

As you can tell, one of the areas I am going to be focussing next, is making sure that there are a number of commercial companies that provide consulting services around O2.

In an interesting twist of events. If one of these companies is really successful in integrating O2 into their services, and, more importantly are able to successfully use O2 to integrate multiple IBM technologies,  that company should become an IBM acquisition target (which could be a late 2010 or 2011 development)

The Need for Standards to evaluate Static Analysis tools

In Jan 2010, on the security static analysis space (also called SAST for Static Application Security Testing (you can download the Gartner's Magic Quadrant report from Fortify's website)) there are a number of security focused commercial products (and services) for analyzing an application's source code (or binaries):  Fortify SCA, IBM with Source Edition (was OunceLabs) and Developer Edition, Armorize CodeSecure, CodeScan, Vericode Security Review, Microsoft's CAT.NET, Coverity Static Analysis, Klocwork TruePath, Parasoft Application Security Solution and Art-of-Defence HyperSource (I didn't include any Open Source tool because I am not aware of any (actively used) that is able to perform security focused taint-flow analysis)

The problem is that we don't have any standards, methodology or test-cases for objectively and pragmatically, evaluate, compare and rate these different tools!

That creates a big problem for buyers, because they are not able to make knowledgeable decisions about which is the best tool for the target applications.

For example, one of the most fundamental issues that we have when looking at the results from this type of tool, is the lack of visibility into what they have (or not) done. Namely, we need to know what the tools know, and what the tools don't know. That's the only way we can actually be assured that the tool(s) actually worked and the results we have (or don't have) are actually meaningful.

Key Concept: When we review a tool's report, it's as important to know its blind spots as it is important to know what it found. If you have a scan report of an application with NO (i.e. zero) High or Critical issues, is it because there were NO vulnerabilities, or because the scanner had NO VISIBILITY of what's going on in the target application? (very common if that application used a framework like Struts or Spring MVC).

In order to know/predict how effective one of these tool can be, we need standard ways to list its capabilities and to compare/map them to what the target application(s) actually contains (namely the languages and frameworks used).

As an example, if a tool has problems following interfaces (i.e it doesn't follows the calls through interface implementations), even before we scan the code, we should be able to say, "Well...  XYZ tool is going to have a problem with this application"

This type of visibility will not only allow the buyers to make much more informed decisions,  but will also allow them to effectively use these tools in their organization (and get higher ROI).

Ultimately, I actually thinking that in the short-term solution (until the industry and technology matures)  is that most large companies will have to buy multiple tools and services! The reason is simple. Given the variety of technologies and programming practices that they have internally, only using multiple tools will they be able to get the coverage and quality of results that they need (note that these tools would have to be driven by knowledgeable security teams or 'security savvy developers')

Note 1: WASC has done a good job with WASSEC (Web Application Security Scanner Evaluation Criteria). The problem is that as far as I am aware, there has been no public & peer-reviewed test-cases and ratings (which means that anybody wanting to use WASSEC will have to pay somebody (internally or externally) to perform the tool comparison)

Note 2: NIST is also trying to map the tools performance via its SATE efforts, but my understanding is that the vendor participation is not as good as expected and the results are not fully published (they do seem to have good test cases which should be included in a 'static analysis test-cases')

Recommending ESAPI?

(I just posted this on the SC-L mailing list and ESAPI users list)

Following the recent thread on Java 6 security and ESAPI, I just would like to ask the following clarifications: 

1) For an existing web application currently using a MVC framework (like Spring or Struts) are we today (9th Jan 2009) officially recommending that this web application development team adds OWASP's ESAPI.jar to the list of 'external' APIs (i.e. libs) they use, support and maintain?

2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL they need to add? or are there other dependencies (i.e. jars) that also need to be added, supported and maintained? (for example on the 'Dependencies' section of the ESAPI Java EE page (i.e. Tab) it seems to imply that there are other *.jars needed)

3) Where can I find detailed information about each of the 9 Security Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography, 6) Error handling and logging, 7) Communication security, 8) HTTP security and 9) Security configuration? (I took this list of controls from the Introduction to ESAPI pdf)

4) When adopting EASPI.jar, are we recommending that the developers should adopt or retrofit their existing code on the areas affected by those 9 Security Controls? (i.e. code related to: Authentication, Access control, Input validation, Output encoding/escaping, Cryptography, Error handling and logging, Communication security, HTTP security and Security configuration) 

5) Should we recommend the adoption of ALL 9 Security Controls? or are there some controls that are not ready today (9 Jan 2009) for production environments and should not be recommended? (for example is the 'Authentication' control as mature as the 'Error handling and logging' control?)

6) Are there commercial (i.e. paid) support services available for the companies who want to add ESAPI.jar to they application?

7) What is the version of ESAPI.jar that we should recommend? the version 1.4 (which looks like a stable release) or the version 2.0 rc4 (which looks like it is a Release Candidate)

8) Where can I find the documentation of where and how ESAPI should be used? More importantly, where can I find the information of how it CAN NOT or SHOULD NOT be used (i.e. the cases where even when the EASPI.jar are used, the application is still vulnerable)

9) if there list of companies that have currently added ESAPI.jar to their applications and have deployed it? (i.e. real world usage of EASPI)

10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been through a security review? and if so where can I read its report?

11) when Jim says "... you can build a new secure app without an ESAPI. But libs like OWASP ESAPI will get you there faster and cheaper....",  do we have peer-reviewed data that suports this claim? 

12) Is there a roadmap or how-to for companies that wish to adopt ESAPI.jar on an a) new application or b) existing real-world application'?

13) What about the current implementations of ESAPI for the other languages. Are we also recommending their use?

14) If a development team decides to use (for example) Spring and ESAPI together in their (new or existing) application, what are the recommended 'parts' from each of those APIs (Spring and EASPI) that the developers should be using? (for example: a) use Encoding from ESAPI, b) use Authentication from Spring, c) use Authorization from ESAPI, d) use Error Handling from Spring, e) use Logging from ESAPI, etc...)

Thanks