Posts Tagged ‘OWASP’

OWASP AppSec 2008 — Analyzing the WHID

Monday, September 29th, 2008

The first presentation I saw after the Keynote was Ofer Shezaf, presenting an analysis of recent results in the Web Hacking Incidents Database (WHID), a compilation of publicly disclosed Web Hacking Incidents hosted by the Web Application Security Consortium (WASC).

Ofer, who works for Breach Security, discussed the issues of trying to measure the effects and impact of security measures on web security. Documenting actual incidents covers definite risk factors from “real” bad guys, but even so, figuring out metrics for web applications is very difficult to assess.

Many web compromises other than defacements are stealthy in nature, and many organizations are either unaware of web compromises, or do not disclose them unless they run afoul of some regulatory requirement to do so (breach of PII, etc). So, as a result, most statistics on web compromises are skewed towards defacements and information leakage, as those are the only two that are regularly seen by the public.

Most assessments are biased, Ofer said, based on the role of who is doing the assessment. Most vendors are going to emphasis “FUD factors” or the results of automated tools, and many times developers reviewing their own code are going to be over-confident in their abilities and not give it the scrutiny it deserves. Lots of vulnerabilities are reported due to applications having a large attack surface, but the validity of the actual Risk and Threat are not considered in most listings of vulnerabilities.

As a case in point, most statistics from vendor tools and top ten lists are based on easily found and discovered vulnerabilities, and so the output of these is vulnerability only.

The OWASP Top Ten is vulnerable to this as well, Ofer claims. Having had some of the results tweaked by the OWASP board (such as the inclusion of CSRF) has helped, but he still feels that it is not an accurate depiction of what to worry about when actually calculating Threat and Risk. Analysis of the WHID shows that some “old” vulnerabilities are still alive and kicking — a large chunk of the last year’s WHID results show misconfiguration of servers as a main avenue of attack, and yet that was phased out of the last OWASP top ten (2007).

He acknowledged that WHID shows the same defacement and information leakage skew mentioned above due to sources, and also that most disclosed hacking incidents are against government and educational organizations. He doesn’t feel that this is necessarily accurate, but more because of requirements for disclosure and transparency in these organizations.

The next “targets” in priority in the WHID are retail institutions, followed closely by internet companies themselves — ISPs and others who influence the traffic of the internet themselves. He thinks that that niche may be the next big target, because of the use that their resources can be put to.

Having evaluated the 2007 data and what he’s seen for 2008, he points out the following trends from the past year:

There are finally large scale business models taking advantage of web application vulnerabilities. Web Hacking is replacing traditional spam methods as the most prolific way of propagating malware. In this process, the web site is the intermediary, not the end target, serving as a mechanism to infect clients. The “business” of malware has shifted its focus to this mass hacking as well, so targeted assaults on specific websites are less frequent (compared to overall incidents), but by no means have they gone away.

Sites are now valued by the loyal customer base that they have, rather than specific content — the larger the infection vector for the site, the more useful it is in the new model. However, small sites are hit constantly now by the mass SQL injection packages, which take over mom and pop sites by the millions.

And, as mentioned above, hacking service providers are increasing as well, with hacking of boxes that are network providers or ISPs.

So, in summary, trends indicated on the vulnerability front don’t always match what is happening in the real world, and investing protection dollars may be better done following the real world trends than trying to match vulnerability lists. Threat modeling should be done to include real risks and threats for your organization, not just the latest research discoveries.

OWASP AppSec 2008 Keynote

Sunday, September 28th, 2008

The keynote for this year was a tag team of various OWASP board members.

Tom Brennan played host to the panel, as he was not only on the board, but a local chapter lead and primary organizer of the conference.

Jeff Williams started the keynote out by discussing the promise of software, and how we are not fulfilling that promise. Currently, Jeff said, the security community is failing. The focus is on penetration testing and exploits, and not how code is written, and researchers are chasing obscure problems, and not looking at the “big questions” (which are also the hard questions) with research.

Repeating some of the mantras oft heard from myself and many others, Jeff pointed out that we can turn Application Security from a “black art” into a science, by organizing and exposing the knowledge required. He mentioned the OWASP is attempting an “OWASP in schools” program that will attempt to get lecturers to do free lectures on application security at different colleges and universities.

Jeff stated that the industry needs to promote secure coding — to the point that it becomes a primary requirement of building any software. “Breaking is easy, building is hard,” he said, but he felt that the collective we at the conference can fix the software market. OWASP is attempting to reach out to groups who build languages and standards and help them build new projects securely with “Intrinsic Security Working Groups” so that new software will be build properly.

Jeff closed by saying that making Application Security into a movement is the only way that it’s going to succeed.

Dave Wichers then discussed OWASP projects and where they are at in the evolution of OWASP. This was the first mention of the “more structure” that OWASP is moving towards — a stricter application of criteria for qualities of release, for all types of projects, and a desire to require that projects advance a level of quality every “season of code” that they are put through.

Dave said that most OWASP documents are available through LuLu as bound documents in addition to electronic format, and that OWASP has taken the steps of adding staff for various administrative purposes as the organization grows.

In the document arena, OWASP is looking to create an “Application Security Desk Reference,” designed to be a one stop shop for discussion of concepts of application security, which could then be referenced internally in other documents. This would allow a “one stop shop” for people seeking core knowledge, and allow other projects to reference back to it instead of having to duplicate boilerplate on basic concepts.

OWASP is also looking towards having more and more conferences and open events to attempt increase visibility and awareness.

Dinis Cruz then took the stand, and discussed another facet of OWASP’s growth — the formal adoption of a grants program for funding projects — things like “season of  codes” now have a formal review process with a review board, to attempt to be more evenhanded and fair in terms of what is handed out, and to attempt to focus and steer the growth of the organization by weighing if projects are pertinent to the mission.

Dinis also echoed the need for an increase in events and visibility, stating that often folks who did OWASP had it as a volunteer “second job” that was completely virtual, and that real world interaction helped promote better communication and interaction between people working towards a common goal.

He ended by discussing the upcoming OWASP summit in Portugal, which will be taking place in November, and how there will be a two-day set of working sessions for OWASP leadership and contributors to set goals and projects for the next year.

OWASP AppSec NYC 2008 summary

Sunday, September 28th, 2008

I attended the annual US OWASP conference in New York City this past week.

The conference was moved at the last minute to a different venue that allowed for a larger number of attendees, due a surge in registration, so instead of taking place at Pace University as planned, it was instead at the Park Plaza Hotel, a few blocks off of Central Park.

As with most security conferences, when you take a cross section of the industry with similar interests, you start to see themes echoing out across all the presentations to form a cohesive message that has more credence than if it just came from one presenter.

The first and foremost of this year from the “security” standpoint is that the cries of “SQL Injection is dead” are not only too early, they are about as wrong as you can get. We were told by a wide variety of presenters looking at different sets of data that SQL Injection is not only alive and well, but it’s probably the most dangerous and prolific attack vector out there today. That then carried the secondary message that the Web App Sec space suffers a bit from the same problems that have been seen at Black Hat and the growing market of city-specific hacker cons (ShmooCon, ToorCon, etc) — that the hype and what the attack-based researchers are working on may show new, large vulnerability surfaces that no one has defense against, but those vulnerabilities are not where the threat is being applied, and do not equate to a realistic amount of risk commensurate with their hype. Where the real world has to focus has a bit of a disconnect with what gets the hype and the press on the research side, and where professionals are working on defense day to day does not always involve what it looks like on paper.

This in turn reinforced an underlying message that has been entrenched in OWASP for a while — that glory of the ‘sploit aside, the real, ultimate, and very difficult work is find solutions, and solutions that can be easily deployed, taught, and replicated. This is an extremely difficult goal, but one that the organization is dedicated to working towards, and revelations such as the above help keep things on track, rather than devolving into the next big exploit of the week, and I think the presentation content at the conference reflected this.

An organizational take-away from the conference is that OWASP is not only growing rapidly, but is aware of this fact and taking steps to manage their growth, so that the increase in resources can be focused and put to work for the organization, rather than being unfocused and wasted, and possibly losing momentum. There is still a lot of work to go (as evidenced in some of the discussion behind the scenes), but I felt energized after attending, and that the growth of OWASP (which, like many other open-source and contributor based entities) which has felt very organic up to now, may be getting some structure. OWASP is trying to get a lot of its leadership and active/influential members to participate in the next big OWASP event, which is a summit in Portugal in November, and there set the tone and goals of the organization for the next year.

In the near future, I’ll try to make a few more posts and cover some of the presentations in detail — the organizers have promised to put recordings of many of them online in the next week or so.

OWASP DC Meeting 6/11/08 @ 1830

Sunday, June 8th, 2008

There will be an OWASP DC chapter meeting this wendsday 6/11/08 at Aspect Security’s office (9175 Guilford Rd, Ste 300, Columbia, MD 21046).  The meeting will start at 1830.  If you are late to the meeting and can not get in the door please call 301-604-4882, or hack the door. The meeting will focus on HTTP Verb Tampering and authentication bypass.

For those of you who do not know, Doug and I along with Rex Booth of Grant Thorton have taken on the OWASP DC chapter lead positions.  We have some new ideas about how to move the chapter forward and are looking forward to revitalizing the OWASP DC chapter.  If your interested please join the DC Chapter mailing list or visit the DC Chapter Wiki Page.

OWASP Enterprise Security API

Wednesday, March 26th, 2008

I was privileged to make it to the March OWASP DC meeting up in Columbia Maryland, to see Jeff Williams give a talk about the OWASP Enterprise Security API, or ESAPI. This is a project that Jeff has been working on for a while, with a variety of collaborators in the web application security field. The public last saw a preview of this at last years “Live O” conference, and it has shaped up nicely since then.

I often comment on how the real answer to most web app security questions is in prevention, and preventative measures are usually “non-sexy” in the InfoSec world. This presentation was probably a step towards making prevention accessible on a historic scale in that it starts to really answer a question that previously has been unanswerable in any concrete manner — “So how do I write secure code?” ESAPI may be the turning point for developers who are looking for an answer to this question that is concrete and accessible, as opposed to the general and unhelpful ones that security professionals (including myself) have had to give to them up this point (such as “learn to write secure code”). ESAPI should be looked at by almost any developer out there as an example of what is possible, even if it’s not something that they can adopt right away. Hopefully, if the project grows, it will become something they can use down the road. But listening to Jeff talk about it really feels like history in the making.

After a short round of general discussion common to all OWASP meetings, Jeff began his presentation. He described the current application development environment developers are in today, and the massive problem that most developers face when they are told to “write secure code,” especially when they are given already existing code to have to fix or include in their application. There are millions of choices in terms of what technologies can be used or combined, and each one is multi-faceted, giving the developer an impossible amount of information to learn in a finite amount of time — and the environment is ever evolving to further complicate this. And, usually, the developer is supposed to do this task on limited time and budget.

Many times, Jeff said, in this situation, in attempting to fix or write secure applications, developers who are not security experts, and may have no experience with security what so ever then attempt to build security controls. Often, between their lack of experience and the fact that some of the problems here are very hard to solve, they do it poorly.

Vulnerabilities stem from either missing, broken, or ignored security controls. Jeff put forth the idea that application security should follow the same model as cryptography — do NOT roll your own. Security controls are very hard to get right, and developers should “leave it to the experts.” Up until now, however, there has been nothing for developers to turn to — the answer is always “learn how to code securely,” which has the problems outlined above. Unless the developer is really savvy and really motivated, this is often going to be a losing proposition.

If an API is suddenly available that does a lot of the security controls for the developer, however, the situation changes. The developer is able to solve the issues of missing or broken code by simply using the APIs. The new API can not solve developers ignoring security controls, but having a standard, simple API allows for a variety of situations that make developers less likely to ignore (or be able to ignore) security controls. With a standard set of API calls to look for, static analysis tools suddenly become worth their weight in gold — every X type of call should use Y, and if you find an instance where it does not, you fix it. Training for developers on how to incorporate security becomes much shorter and sweeter, there is less to learn and it is easier to master — all things which will make developers much more likely to implement security in their applications.

(more…)