Setting the Web Application Security Agenda for 2009: OWASP Invites You to Join Our Summit in Portugal

http://www.owasp.org/index.php/OWASP_EU_Summit_2008

With the theme ‘Setting the AppSec agenda for 2009′, the OWASP Summit will be a worldwide gathering of OWASP leaders and key industry players to present and discuss the latest OWASP tools, documentation projects, and web application security trends. Join us in Portugal in just a few short weeks! This venue hosts a diverse selection of training courses along with technical and business tracks, making it THE place to learn about web application security and the resources OWASP has available for use today.

OWASP is a not-for-profit organization with the purpose of supporting the Web Application Security community around the world, and has granted $250,000 USD for web application security research. In addition to over 40 presentations from the OWASP Leaders and grant recipients, the OWASP Summit will host multiple Working Sessions designed to improve collaboration, achieve specific objectives and identify roadmaps for OWASP projects, chapters, and the OWASP community itself.

To facilitate this event, OWASP is investing $150,000 USD which will be used to cover air travel and accommodation expenses for OWASP leaders, active contributors, and select key industry leaders. With their confirmed presence, the OWASP Summit will provide a relaxed but professional environment to meet, discuss, influence and contribute to OWASP projects.

There are still funds available! If you are interested in attending and you meet the profile of the current OWASP supported attendees (see list here: http://spreadsheets.google.com/pub?key=pAX6n7m2zaTVLrPtR07riBA) contact Paulo Coimbra (paulo.coimbra@owasp.org). Please note that you should do so only if you meet the paid attendance criteria (see herehttps://www.owasp.org/index.php/OWASP_EU_Summit_2008_paid_participation_rules) and are unable to get corporate support to attend this event (for other corporate sponsorship opportunities see http://www.owasp.org/index.php/OWASP_EU_Summit_2008_Sponsors).

The OWASP Summit will also host a large and diverse selection of training courses, covering multiple OWASP specific and Web Application Security Topics.

The remarkable impact of OWASP is made possible only by the collaboration of many dedicated people and organizations worldwide. In that spirit of cooperation, OWASP invites all its members (who have 20% discount + 1 VIP Ticket) and interested individuals and companies to attend this thrilling event. Please join us and help to set the Web Application Security Agenda for 2009!

Please see below for additional details about the OWASP Summit or visit the OWASP Summit website: http://www.owasp.org/index.php/OWASP_EU_Summit_2008.

Projects

OWASP projects selected for Summit presentation include new documentation and innovative tools to help developers, architects, and security specialists ensure that applications are secure:

• Application Security Verification Standard,
• Code review guide, V1.1,
• Ruby on Rails Security Guide v2,
• Securing WebGoat using ModSecurity,
• Testing Guide v3,
• GTK+ GUI for w3af project,
• Access Control Rules Tester,
• AntiSamy .NET,
• Live CD & DVD Project,
• OpenPGP Extensions for HTTP,
• Orizon Project,
• Python Static Analysis,
• WebScarab-NG,
• And many, many others.

Working Sessions

Expecting the presence of the application security industry key players, the Working Sessions will cover a wide range of issues such as:

• OWASP Top 10 2009,
• Browser Security,
• Web Application Framework Security,
• Enterprise Security API Project,
• Best Practices for OWASP Chapter Leaders,
• OWASP Documentation Projects,
• OWASP Tools Projects,
• OWASP Education Project,
• OWASP Strategic Planning for 2009,
• OWASP Certification,
• OWASP Winter of Code 2009
• Two-way Internationalization of OWASP Content
• And many more.

Training

These 2-day, 1-day or 1/2-day training courses cover a wide range of OWASP specific and Web Application Security Topics:

• OWASP Top 10 - What Developers Should Know on Web Application Security
• Uncovering WebScarab’s Secret Treasures
• Securing WebGoat with ModSecurity
• Secure Programming with Java
• Advanced Web Application Security Testing
• Building Secure Web 2.0 Applications
• Building Secure Web Services
• Building Secure Web Applications with OWASP’s Enterprise Security API (ESAPI)
• Classic ASP Security using OWASP tools
• Web Application Assessments
• Hacking Owasp Orizon Project v1.0
• Ajax Security
• Practical Penetration Testing: Think Like an Attacker to Stop Attacks
• Linux Software Exploitation
• Web server/services hardening using SELinux

Main Contact:

Kate Hartmann
OWASP Operations Director
9175 Guilford Road, Suite 300
Columbia, MD 21046, USA
Phone: +1-301-575-0189
Facsimile: +1-301-604-8033
Email: kate.hartmann@owasp.org

Wanted to drop a quick note to introduce the latest member of the SDL team - Katie Moussouris!

Many of you may already know Katie from her past work on the MSRC Ecosystem Strategy Team or her tenure at Symantec and @Stake.

Katie has joined the SDL team to help drive crucial elements of our SDL outreach effort; her primary responsibility will be managing our relationships with security consulting and training partners. She’ll additionally be tasked with ongoing analysis of the SDL – with a goal of assisting industry verticals that are looking to apply the SDL in critical computing scenarios. 

It goes without saying that she will be a regular contributor on the SDL Blog – but given her expertise, it’s likely she’ll continue to blog on an occasional basis over on Ecostrat...

Anyway – here’s Katie in her own words!

Katie Moussouris is a Senior Security Program Manager in the Security Development Lifecycle (SDL) Outreach Team, working to bring Microsoft’s SDL to partners, vendors and customers in order to improve the security of the Internet as a whole. Katie began her nerdy life programming her C64 in grade school, writing her own Zork-like text-based adventure – which was of limited use, since she had no friends and she knew all the puzzles in her own game.  Good thing she eventually left her room and found some like-minded people at a local 2600 meeting.

Katie’s professional background is application security, having come from Symantec by way of the @stake acquisition. Katie founded the Microsoft Vulnerability Research Program (MSVR), extending the focus of Microsoft’s security vulnerability research to third party software.  Katie also founded and ran the Symantec Vulnerability Research Program, the first program of its kind in Symantec's history to allow the publication through Responsible Disclosure of original vulnerability advisories discovered by Symantec researchers. In addition to performing security research, Katie has been an application penetration tester for Fortune 500 companies across numerous industries. She has uncovered serious vulnerabilities during the course of her work before they could be widely exploited by hooligans and criminals for either fun or profit, respectively.

This blog gives us a place to talk about our experiences from using the SDL here at Microsoft and hopefully provide useful information that will help you implement it more effectively at your company.  So, I would encourage you to use the Comments section at the bottom of each post to ask questions, give us feedback, or request other topics for us to cover.

Some quick definitions before we dive in. I’ve been using the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing the Security Development Lifecycle (SDL).  “Walking” is the point where your security development practices become a lifecycle – a repeatable, reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll continue to talk about walking – or adding the “L” in SDL.

Let’s jump into another component for adopting the Microsoft SDL to expand your own Security Development Lifecycle.

Expand Security Training

Once you have management approval, it is necessary to gain grassroots acceptance of the changes – at the developer, QA/test, and PM levels. If you have been “crawling”, you have probably already implemented some sort of discipline-specific training around things like threat modeling, using compiler defenses, and fuzz testing. Now that you are building a lifecycle, your goal for security training should expand. Security training should be about creating an environment where writing secure software is everyone’s mission. While security training should be undertaken with the goal of understanding security issues and how to address them, good training (and instructors) will also explain why solving security problems is in their best interests and create an environment where they know voicing security concerns is encouraged.

Training has been one of the earliest and most important elements of the SDL at Microsoft. From our experience, we learned that the most effective approach is to divide your training into two tracks: general security principles and role-specific security practices. Before I jump into the details, I want to encourage you to also read Shawn Hernan’s very good post about SDL training that highlights some of the ways to make security training effective.

The general security principles should explain why security is important, how you define security requirements, the process you will use for writing and validating secure code, and how security relates to each phase of the lifecycle or unique roles contributing to the development process. A key factor for building a development lifecycle is educating your individual contributors on the value of investing in security. Of course changing culture takes time, but using the opportunity of structured training to explain your principles will be one of your most effective platforms for influencing change.

At this point in your organizational maturity, you are also beginning to expand your security thinking by focusing on each role in the development process. Discipline-specific security training is where you dig into the details of implementing a Security Development Lifecycle.

·         The developer needs to understand the practical details of how to write code securely, how to set compiler flags, what a security code review means, how to avoid using banned APIs, and what tools are available for them to perform security analysis before checking in their code.

·         The QA/tester needs to know how to set security rules in test tools, how to perform penetration testing, and what the security quality criteria is for your product, or how to file a security bug.

·         The PM needs to understand how to define measurable goals or how security policies can be factored into feature design.

·         The business decision maker of your organization should understand how to track security metrics alongside other product measurements or how security policy plays a critical role in the overall quality and value of your product.

·         Finally, it is critical for the employees occupying all job roles to understand the value of threat modeling – both as a tool for understanding threats early in the design phase and throughout the development process as a key barometer to the security pulse of your product.

Discipline-specific training will be the place to address these issues for your organization. In case you were wondering, all job roles should be required to attend both types of security training before working on your product.

Our new SDL website [http://www.microsoft.com/sdl] will be a very good place to watch for future training materials. The SDL Training and Resources page has some useful material up now and more will be coming in the future.

That’s Part Two. In Part Three, I will discuss the important “walk” components of formalizing security requirements and reusing threat models and attack surface reviews. Then we will close with the discussions on conducting final security reviews, and managing post-release documentation.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        Do you provide security training to your employees today?

?        Do these additional training topics make sense in your organization?

?        What would you add to this that is unique to your application or company?

Collaboration in the Cloud

Forward thinking companies use collaboration technologies to melt away the physical distance between disparate offices, remote workers and suppliers.  Investments in R&D projects to create the next generation of business collaboration technologies and starting to bear early fruits and are worth paying attention to - especially if you get paid to “do security”.  One major focus area is Virtual Worlds.

Teleporting Virgins

The big news in the Second Life research community is that avatars (”virtual people”) have successfully teleported between distinct virtual worlds.  The virgin teleporters went from a Second Life Preview Grid - an experimental grid completely disconnected from the Main Grid - to a virtual world running IBM OpenSIM.

At this stage there is intentionally no asset transfer going on at all - in other words, you can’t take your “stuff” from one world to another - but that will come in time as the Open Grid Protocol is extended.  Today just login and teleport are supported.  No stealing those trade secret “assets” yet ;-).

Linden Labs speaks to this issue:

Q: How will Linden Lab prevent property from being copied into other virtual worlds?
We’re paying extremely close attention to that question. We will be designing this with the Second Life community to ensure their needs are met. We want to stress that when it does become possible to move avatars between worlds, we will take the utmost care to protect the rights of Second Life property owners and creators. Linden Lab will not design a system that lets people openly violate the permissions of SL goods and take them to other worlds. We recognize that intellectual property is the engine that drives Second Life, and we are completely committed to preserving the qualities that make Second Life the unique, innovative and dynamic place that it is today.

With my “hacker-vision” ™ enabled I see *all kinds* of opportunities for mischief here.  I’m betting we’ll see imaginative attacks as the usual cat and mouse game of vulnerability research and vendor response plays out.  “Sorry boss, someone hijacked my avatar and now I’m stuck on this desert island for who knows how long!”.

Threat Profiling Second Life

Getting back to reality, people are already exploring Virtual World security.  Michael Thumann of ERNW in Germany is a pen-tester and security researcher and in this 10 minute video, Michael shares the result of his security research on Second Life.

He covers:

• In-game cheating
• Identity theft
• Attacking 3rd party servers using Linden Scripting Language (think about the liability issues and the providers ability to track abusers)

For those interested in more detail, the full presentation he gave at BlackHat Europe 2008 in Amsterdam is here (pdf).

Of particular note, Michael applied a formal threat model approach to the research - STRIDE from Microsoft.

In a future post I’ll talk more about threat profiling in the context of Cloud Computing vulnerability research and specific API security vulnerability classes we can expect to see exploited.

For this contest, the goal is to create fear. Not just any fear, but a fear that you can alleviate through the sale of your new product idea. There are lots of risks out there, some of them serious, some of them so unlikely that we shouldn't worry about them, and some of them completely made up. And there are lots of products out there that provide security against those risks.

Your job is to invent one. First, find a risk or create one. It can be a terrorism risk, a criminal risk, a natural-disaster risk, a common household risk -- whatever. The weirder the better. Then, create a product that everyone simply has to buy to protect him- or herself from that risk. And finally, write a catalog ad for that product.

[...]

Entries are limited to 150 words ... because fear doesn't require a whole lot of explaining. Tell us why we should be afraid, and why we should buy your product.

On May 7, I posted five semi-finalists out of the 327 blog comments:

• DNA adulteratometer to detect waiters spitting in your soup.
• Toothpaste test strips.
• SOS device for people locked in car trunks.
• Anti-laser-pointer eyeglasses.
• "Alertness alert" heartbeat monitor.

Sadly, two of those five was above the 150-word limit. Out of the three remaining, I (with the help of my readers) have chosen a winner.

Presenting, the winner of the Third Annual Movie Plot Threat Contest, Aaron Massey:

Tommy Tester Toothpaste Strips:

Many Americans were shocked to hear the results of the research trials regarding heavy metals and toothpaste conducted by the New England Journal of Medicine, which FDA is only now attempting to confirm. This latest scare comes after hundreds of deaths were linked to toothpaste contaminated with diethylene glycol, a potentially dangerous chemical used in antifreeze.

In light of this continuing health risk, Hamilton Health Labs is proud to announce Tommy Tester Toothpaste Strips! Just apply a dab of toothpaste from a fresh tube onto the strip and let it rest for 3 minutes. It’s just that easy! If the strip turns blue, rest assured that your entire tube of toothpaste is safe. However, if the strip turns pink, dispose of the toothpaste immediately and call the FDA health emergency number at 301-443-1240.

Do not let your family become a statistic when the solution is only $2.95!

Aaron wins, well, nothing really, except the fame and glory afforded by this blog. So give him some fame and glory. Congratulations.

Below is a screenshot of some of the user-generated comics that can be viewed. I’ve magnified the last pane of one of the strips using Flash’s “Zoom In” feature. Notice anything interesting?

Yep, it’s our old friend URL encoding, commonly used by web browsers to include non-alphanumeric characters into an HTTP request. Just interpret the %XX as a hex number, so %20 is the space character (decimal 32), %21 is an exclamation point (decimal 33) and so on. But why is it showing up in a Dilbert mashups?

My first thought was that someone must be poking around the Dilbert site looking for security holes. But then I noticed that it wasn’t just the one strip; a lot of them had the same problem. And it seemed unlikely that there were that many security-minded people messing with the site relative to the rest of the cubicle dwellers trying to come up with funny things for Dilbert to say.

My next thought was just that some developer just forgot to call urlDecode() — or whatever the Flash equivalent is — on the user-supplied punch line. Except that’s an oversimplication because: 1) it doesn’t happen on every strip, 2) the web server usually strips off the first layer of URL encoding so the backend wouldn’t see it unless it was double encoded (e.g. %2520), and 3) if you click on one of the thumbnail comics with the URL encoding anomaly, the full-size rendered version of the comic looks fine:

So clearly the “preview” code and the “full-size render” code are doing slightly different things with the same data, which may or may not have been properly decoded prior to being inserted into the database.

Any thoughts, readers? The pen tester in me wants to get to the bottom of this, but unlike some of the web app security people out there, I tend to be more conservative about hacking stuff without a signed contract. Also, I don’t think I can stand to read any more un-funny punch lines. But my gut tells me there is something fairly interesting going on behind the scenes here.

Oh finally, here’s a tip from Scott Adams himself on avoiding the Flash navigation and viewing the daily comic as a plain ol’ GIF.

I digress. What inevitably happened once I started walking around with this button proudly displayed was that I would get one of two reactions. The first group — mostly current and former co-workers and acquaintances — understood the humor and got a good chuckle out of it. The second group would ponder for a bit and then ask, with some confusion, why I’d intentionally point out the fact that I’m not a CISSP. I’d give a brief answer and get back to talking about Veracode (we booth babes have responsibilities, you know).

So, why indeed? The long answer is that like many security certifications, it’s an ineffective measure of a security professional’s practical abilities. Employers and customers often assume the guy with the five magic letters on his resume is technically superior to the guy without. In my experience, it’s exactly the opposite, particularly in situations where you have to sit down at a keyboard and actually DO something as opposed to talking about it. Certainly, I’ve encountered some very notable exceptions to this observation, but we’re playing by the 80/20 rule here.

There’s a good reason for this. The trend in information security is toward specialization. Security has become such a broad umbrella of varying disciplines that it’s quite difficult to be a generalist. A security career is a balance between breadth and depth, and these days, the skilled pen tester, reverse engineer, or vulnerability researcher is more marketable than the guy who knows a little bit about dozens of different disciplines but can’t apply that knowledge in a practical situation. The CISSP subject matter illustrates this perfectly — you have cryptographic algorithms, site location principles, network security, and civil law on the same exam. I won’t even get into the complaints I’ve heard about the poorly-worded, overly simplistic exam questions or the ones that simply test one’s ability to memorize obscure facts.

I’m not claiming that there’s no value to holding the CISSP certification. It can’t hurt to have some exposure to business continuity planning, for example. The problem, as I stated in the beginning, is that the CISSP title is often interpreted as an indicator of practical abilities rather than a book-level understanding of security basics. These misaligned expectations can ultimately lead to bad hiring or staffing decisions.

Career advice, take it or leave it: If an employer or prospective employer demands that you get your CISSP in order to be hired or to progress in your career, run fast in the opposite direction and find a place where you will be valued for your cumulative experience rather than a piece of paper. Learn by doing, don’t “learn the test,” so to speak.

And that, in a nutshell, is why I love my “Not a CISSP” button.

By the way, here was my other favorite from RSA, thanks to WhiteHat. This one and “Samy is my hero” were the best out of a pretty clever selection… even though they forgot the semicolon after the single quote. <grin>

First, let me say what I knew about the SDL going in: no policy can anticipate every situation; you have to make tradeoffs; the details matter; the big picture matters; you need tools; you need human insight; you need management support; and we’re never going to be perfect. All of the things you’ve read in this blog are true, and they really shouldn’t be controversial. Since joining SQL, I’ve learned a lot about SQL Server too, and what it means to ship a product - but that’s outside the scope of this blog. So instead, I’ll try to describe three real experiences that illustrate things that shouldn’t be controversial either, but aren’t usually covered under the rubric of security.  They are crucial nonetheless.

Security is not the point, it’s the needs of the customer. It’s easy to believe that security is the point of producing a product. It’s not. We won’t produce an insecure product, but the primary driver for a product team is to produce a valuable, useful product. Yes, security is a big part of that, but security is not a goal in and of itself.  For example, one of the areas of fierce competition in enterprise database products is performance, and we have to balance security with  performance. One of the ways we do that is by verifying data we receive really well, but only when necessary. We define clear trust boundaries, and check the data thoroughly once on the way in, and then work very hard to enforce those trust boundaries.

I first encountered this in SQL when I helped review threat models for the database engine. The engine trusts that the data on the disk was written correctly by a trusted entity (with checksums to guard against random errors), and enforce that. Instead of a slavish adherence to the principle of total mediation or defense in depth, which, when taken to its extreme would say to “check everything, every time,” we are hard core about making the right checks, but only the right checks.

I will note that it is not an either/or choice between security and performance – it is possible to do both. Indeed, I would say that doing one without the other is pointless, but to get both 1) world class performance, and 2) world class security,  you have to understand your data flows really well, and make detailed decisions.

Be polite, but don’t be afraid: Job interviews at Microsoft can be challenging. When I interviewed for this job, my final interview was with a very senior architect. The subject of integer overflows came up, and he asked me to describe the problems and solutions. So I started writing some code on the whiteboard. After about 10 minutes of describing my approach to integer overflows, he said to me, “What if I were to tell you that’s a really bad solution, and the interview is over?”

My heart sank.

But instead of rolling over, I said, “well, that’s a bad outcome, tell me why.” He proceeded to attack my solution on several grounds, including being unreadable and unmaintainable, and he proceeded to describe his solution to the problem. Now, this was a very serious, very senior technical architect, and I was in a high pressure, asymmetric situation. So, not willing to be intimidated, but unable to attack back, I pointed out several shortcomings of his solution, politely, but firmly. And we spent the next 40 minutes talking about various aspects of the problem, and me defending my solution, which I think was credible. I don’t know if he agreed with my solution or not, really, but I suspect it might have been a test to see if I would cave. Or maybe he thought it really was a bad solution, I don’t know. But I got the job.

As a security professional, you’re always going to be at a technical disadvantage when you’re reviewing another team’s components. They designed and implemented the system. You are an outsider, and it is absolutely impossible to understand the system to the degree as the people who built it. Nonetheless, you’ve got to find a way to ask hard, probing, impolite and sometimes even uninformed questions without being threatening or insulting, or undermining your own credibility.  

Be polite, be firm, put your ego in a box, and ask questions until you understand.

“It should work” is not a good answer:  We take the giblets problem very seriously, and managing giblets can be quite difficult at times. And in SQL, we have lots of giblets. We consume things from Windows, and Office, and Visual Studio, and others, and we provide giblets to other teams as well. In fact, we provide components that other teams use to build the giblets they provide to us – we consume our own giblets!

And as it happens, one of the components we use was updated recently. Even though it would get serviced through Microsoft Update, we want to ensure we have the latest and greatest version of any component we ship. But to consume the latest and greatest version of this particular component would require some small updates to either our installer or theirs. So we met with the team that owns the giblet in question to try to divvy up the work, and to avoid schedule disruptions on either side.

There was a lot of back and forth about various things to try, and we continued to refine a solution until we had reduced the problem to a single issue. 

At this point, there was an air of hope in the room. If the idea actually worked, we had a solution at relatively low cost. But would it work? When the question of “will this work” comes up, all eyes turn towards test managers.

Our general manager was looking right at our test manager and she asked, “Will that work?” The test manager looked across the table at the development manager from the other group, and said, “I don’t know. That depends on their level of confidence in the behavior of their component under these conditions.”

Now, all eyes were starting at the dev manager, and the room got quiet. A somewhat sheepish look came over his face, because he knew the answer he was about to give would be unsatisfactory. He said, “Well, I’m not a tester, I’m just a developer, but it should work.”

At which point the room erupted into hysterical laughter.

“It should work” means “I think so, but we have to test it.” And that means the whole battery of tests for each of the affected components, across all of the supported platforms. And that has to be scheduled in test labs. To be clear, this wasn’t a lack of confidence in the developer, quite the contrary, he was laughing along with everyone else. We just know that writing software to satisfy all the scenarios in which our software is deployed requires far more testing than can reasonably be performed on a single desktop system.

So the tests were scheduled, the developer was proven correct, and we’re picking up the latest version. Even seemingly simple changes require a lot of testing.

So, that’s what I’ve learned: security isn’t the be-all-end-all,, things are really complex and hard to understand, and you don’t really know if anything works until you test it. None of which should be controversial, but none of the central ideas in the SDL are controversial either. The hard part is putting theory into practice, and recognizing that no venture is risk free, despite the natural inclination of security engineers to avoid any risk whatsoever. In this, I am reminded of one of my favorite books, “To Engineer is Human: The Role of Failure in Successful Design,” by Henry Petroski. He writes, “No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts [and are] constantly striving to do more with less. [] The engineer always believes he is trying something without error, but the truth of the matter is the each new structure can be a new trial. [] Such is the nature not only of science and engineering, but of all human endeavors.”