TALKS
September 22-23, 2011: Software security and software development professionals presented their ideas
Talks Format and Time
OWASP AppSec USA 2011 is a conference for information security and software development professionals up to the task of solving tough application security problems. The format was four tracks spread across two days, with each talk running 50 minutes in length. Track content covered new attacks & defenses, cloud security, mobile security, software & architecture patterns for security, secure SDLC, thought leadership, software assurance, and OWASP projects.
The morning keynote started around 8:30 AM Central Time on September 22 and September 23, 2011. The talks commenced around 9:30 AM each day. Lunch (one day was the OWASP Foundation Board, the other was Moxie Marlinspike) was held around 12:30 PM - 1:30 PM each day of talks. The final talk each day finished around 4:30 PM. On September 22 there was some happy hour fun afterward. On September 23, 2011 there was a wrap up session from about 5:00 PM - 5:15 PM. See the schedule.
Pricing and CPE Credits
Pricing and group registration discount information here.
One could earn up to 16 CPE credits by having attended the talks (attendees must self-submit CPEs).
Keynotes
Moxie Marlinspike
We were exhilarated to tell you that Moxie Marlinspike keynoted over lunch September 23 at OWASP AppSec USA 2011!
Ira Winkler
As OWASP celebrated ten years, OWASP AppSec USA 2011's September 23 keynote, famous real world spy author Ira Winkler, brought a dose of reality about today's threats.
Mark Curphey
It was a homecoming: OWASP AppSec USA 2011's September 22 morning keynote was OWASP founder Mark Curphey, who reflected on community.
OWASP Foundation Board Discussion
Additionally, an OWASP Foundation Board discussion was held during lunch September 22, 2011. We welcomed Jeff Williams (Chair), Tom Brennan, Eoin Keary, Matt Tesauro, Dave Wichers, and incoming board member Michael Coates. * Sebastien Deleersnyder was not able to attend due to a scheduling conflict.
The Talks
Slides are being posted here as they're received. We hope to have video of all of the talks posted by the end of November 2011 after it has been refined at OWASP's video editing partner. In the meantime, please check out the recorded live streamed and pre-conference videos or check out one of several thoughtful recaps about OWASP AppSec USA 2011.
Android Security, or This is not the Kind of "Open" I Meant... Mike Park
Android phones and applications are rapidly gaining market share and becoming more popular. While the availability of multiple Android Markets provides users with greater choice, it also provides attackers more opportunities.
Not only are Android applications plentiful, but the platform and security model means the apps are easy to abuse. This presentation will expose the security issues associated with Android Apps and how attackers take advantage of them. These include the ease with which Android Apps can be reversed, the ability to store sensitive data locally, and how these apps can be trojaned to access personal information on the device.
The presentation will demonstrate the use of various open source tools for reversing Android Apps, as well as the use of the Android SDK features for pen testing, again including techniques and fast demos. Solutions to app and marketplace security will be covered as well.
Application Security Advisory Board SDLC Panel Glenn Leifheit (moderator), Andreas Fuchsberger, Ajoy Kumar, Richard Tychansky, Alessandro Moretti
Companies are increasingly concerned about the risks to customer data and the potential damage to their reputation should a breach occur, but many are failing to recognize that software remains a significant weak spot in security defenses. Attackers are increasingly targeting the software and applications, rather than the infrastructure or operating system, as a way in to the organization.
The (ISC)²/Creative Intellect Survey on the State of Secure Application Lifecycle management, conducted late last year to understand the impact of security on the software development and delivery process, found that managers are jeopardizing secure software delivery, but they are not alone. This panel will identify who we need to influence in the SDLC process to ensure security is considered at the beginning of the process and discuss five tips for approaching them.
Application Security and User Experience Alex Smolen
You might think application security and usability are a zero-sum game. Strong password policies, tight access controls, and cycle-burning cryptography improve system security but hamper the user experience. From a security advocate's perspective, it's important to minimize risk, even if it makes a system hard to use. But what if introducing strict security mechanisms actually increases risk? When do security and usability complement, rather than detract from, each other?
No application is solely technical. Systems operate within a social context. People define, build, and use systems, and their needs and capabilities affect the security of a system. Ignoring the users' perspective when evaluating system security neglects an important attack surface - the human-machine interface.
Security mechanisms should be a barrier to attackers, but not for every user in the system. Draconian security measures can actually have the opposite effect of making systems less secure. Users demand more and more usable software, but security departments shouldn't have to compromise. Instead, security mechanisms should be designed with the user and the attacker in mind, so tradeoffs between security and usability can be minimized or avoided entirely.
Application Security Debt and Application Interest Rates Chris Wysopal
Architects and developers are well aware of the term technical debt but many in the security community have never heard of this concept. Ward Cunningham, a programmer who developed the first wiki program, describes it like this:
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."
The cost of technical debt is the time and money it will take to rewrite the poor code after you ship and bring it back to the quality required to maintain the software over the long haul. Using debt in the financial world costs more absolute dollars than not using debt but it allows financial flexibility to do things you couldn't do without using debt. It's this flexibility that makes debt a valuable business tool. Technical debt allows development teams to meet a ship deadline or get a particular feature out to customers quickly which ultimately serves the business.
Application Security Debt:
We can think of all the latent vulnerabilities in a piece of software as its application security debt. Security debt accumulates over time as more code is written without performing security processes during the development life cycle. A project takes on a lot of debt during the design phase if there is no threat modeling or architecture risk analysis performed. This will translate into costly redesign work at a later date. If code is written without using static analysis or following secure coding guidelines then security bugs are going to get into the final application that will eventually need to be eliminated at a higher cost. The more code that is written this way the more security debt accumulates.
There are obviously good business reasons for accumulating security debt because we see it everywhere in successful companies. However, there is a point in the lifetime of a lot of software projects where the debt gets too high and needs to be paid off by redesigning and rewriting a lot of code. If it isn't paid off, the security debt risks impacting the bottom line.
Application security debt has some similarities to technical debt but there are two big differences that we need to think about when deciding if our security debt load has gotten too high and needs to be paid off. Technical debt is all about maintainability and functional quality. Application security debt has breach cost and breach likelihood as factors. These factors are out of your control just like an adjustable interest rate is on financial debt. Breach cost can change over time due to changing compliance requirements and fines or increased brand damage. Breach likelihood changes as the threat space changes. If cost and likelihood go up, your debt goes up. I call these external factors the application's interest rate.
The Changing Application Security Interest Rate:
When your application was first written, the factors outside of your control, your application's adjustable interest rate, might be low. Attackers just aren't interested in your application. They might not have good tools to find vulnerabilities on the OS or platform you developed on. They may not have figured out how to monetize attacks where exploiting vulnerabilities in your application matters. Your application may not be popular, so it isn't worth the time to find vulnerabilities and write exploits. Your brand damage is low because you have no users. But if your application is successful, it is likely your application's interest rate will rise and your application security debt will increase to a point where you need to do something about your security flaws.
The changing threat space usually comes as a surprise to a business in the form of a breach or multiple breaches. For a software vendor the wake up call will be the public disclosure of vulnerabilities in their products. When these events occur the business typically makes the decision that some security debt needs to be paid down. The pay down can range from a full rewrite of the software to major design changes to just fixing a class of security bug. The amount of security debt repayment will depend on the size of the debt, the interest rate, and the risk tolerance of the organization.
Along with discussing application security debt and interest rates, Wysopal will provide examples of debt repayments, such as the famous Trustworthy Computing memo from Bill Gates and the successful online startup scenario, to show how security debt can build up and, in many cases, be managed. He will also provide attendees with steps to take in order to determine how much debt is too much and if there's a way to model application interest rate to see how your debt may be rising.
AppSec Inception - Exploiting Software Culture Jeff Williams
No matter how fast you are at playing vulnerability whack-a-mole, eventually the moles always win. If you truly want to get in front of application security, you have to start looking at changing your software development culture. In this talk, Jeff will share experiences with multiple approaches to changing security culture, going back to the late-80's. Not surprisingly, few of these approaches have made any difference. OWASP represents a new approach, and is an interesting experiment in how we change software culture worldwide. Jeff will extract and clarify the lessons from OWASP that you can use in your own organization to bootstrap a software culture that generates security.
Behavioral Security Modeling: Eliminating Vulnerabilities by Building Predictable Systems John Benninghoff
In addressing the human behavioral aspects of Information Security, we've largely failed as a profession. Historically, we've tried to force people to adapt to the technology we built, and then blame the user when they fail to use it properly – the talking point is, "people are stupid, and you can't fix stupid," or "People should know better," as discussed in a recent SANS ISC Diary posting on CVE-0. (http://isc.sans.org/diary.html?storyid=10933) Security Awareness training, one of the few tools we have to address people problems, has been and continues to be poorly executed. At best, Awareness explains security rules well enough so that we can fire people when they break them, and at worst is a series of posters asking people to "do good things," or tries to make them security experts, with no evidence that it is even effective. Although we have started to improve, our understanding of human/computer interaction (in the security context) is poor, and we do little, if any, to understand the motivation and behavior of both external attackers as well as internal personnel.
Behavioral Information Security, (BIS) A formal methodology to manage information risk, derived from knowledge of how humans behave and interact with information, is a new philosophy of information security that places people in the center of the model, and can be used to design and implement security architectures and controls based on our understanding of people. Borrowing from other professions, BIS seeks to develop practical tools for security practitioners, with the ultimate goal of reducing the cost and improving the effectiveness of information security. This talk will introduce Behavioral Information Security, and Behavioral Security Modeling; a tool developed using BIS principles.
Behavioral Security Modeling describes interactions between information and people in socially defined roles, as well as each role's desired and/or expected properties for the information exchanged. Differences between the desired/expected properties of information and the actual properties of the information systems that implement the interaction introduce security vulnerabilities. Behavioral Security Monitoring allows these vulnerabilities to be anticipated and managed by comparing expected properties to the actual properties of proposed information systems, allowing for more predictable systems, and better decisions about security design.
A practical example of Behavioral Security Modeling will be demonstrated by applying the approach to the tokenization of credit card numbers. The model presented will describe the key actors in an online purchase, the Customer, Merchant, and Processor, their desired properties for the information (the credit card number), the actual properties of the credit card number in most information systems, and show how different tokenization and encryption solutions can alter the properties of the information during capture, storage, and processing of payment, to help companies choose the solution that best meets their needs.
Brakeman and Jenkins: The Duo Detect Defects in Ruby on Rails Code Justin Collins, Tin Zaw
Ruby on Rails (RoR) is a popular web application development framework with support for Model-View-Controller architecture, "convention over configuration", "don't repeat yourself" or DRY principle, and test-driven development. The framework is designed to be resistant to web security exploits such as cross-site scripting, SQL injection and cross-site request forgery.
Even with built-in protections, it is possible, and often witnessed, that security flaws get introduced in Ruby on Rails code. Brakeman, a static code analyzer for Ruby on Rails code, is designed and developed at AT&T Interactive by Justin Collins to detect such flaws during early phases of development cycle. To further reduce the burden on the developer, Brakeman is integrated into a continuous build and integration server called Jenkins, formerly known as Hudson.
This talk will focus on basics of security features in Rails framework, advantages of using static analysis for discovering security issues, design and development of Brakeman, and how Brakeman and Jenkins are used together at AT&T Interactive to reduce security defects. The only static code analyzer for detecting security defects in Ruby on Rails code, Brakeman is available on GitHub under open source license.
CloudSec 12-Step Adrian Lane
Do you think cloud security is mainframe computing all over again? Is Azure security just like Windows security? If so, then join me for CloudSec Anonymous, a 12-step program for those of you who want to understand what's different about cloud security. This presentation if for those of you who talk about "The Cloud" and virtualization in the same breath, but have never actually built your own cloud - much less tried to secure it. For many, 'The Cloud' is just software running on someone else's machine, which you access from your browser. Still others only view the cloud as virtualized resources available to the public. Go ahead, admit it: You don't have a Rackspace account and you have never spun up an AMI. Admitting you don't understand the cloud or cloud security is the first step in figuring out how to secure services or securely deploy your applications. Cloud services are differentiated from traditional IT through elastic, self-service, pay as you go computing models. But these characteristics don't provide clues as to how 'The Cloud' changes data and application security. Rather it depends upon the service model, deployment model and platform provider that you choose. In this presentation I'll discuss 12 areas where cloud security differs from traditional models, focusing on platforms and services commonly used for custom web applications. Topics will include:
- Redeployment of data encryption and key management
- Testing and deployment of cloud applications
- Identity management for cloud applications
- PaaS today, gone tomorrow: reliance on API's
- Infrastructure stack management
- Tradeoffs between Platform as a Service and Infrastructure as a Service
- Fundamental security differences between public and private clouds.
ESAPI 2.0 - Defense Against the Dark Arts Beef (Chris Schmidt), Kevin Wall
In this presentation Chris, joined by Kevin Wall and other members of the ESAPI team will highlight the latest GA release of OWASP Enterprise Security API 2.0.
Key touchpoints of the talk will include:
- What is ESAPI
- Integrating Controls
- Crypto Enhancements (Kevin Wall)
- ESAPI Roadmap and Future (ESAPI Dev Team)
- ESAPI Community Launch
What is ESAPI will feature an updated overview of what an Enterprise Security API is, why it is important, and how it is intended to be used. This will be a high-level overview intended to raise questions from you about specifics that can be addressed in the breakout session or over a cold beer.
Integrating Controls will be a brief view into what it actually takes to build and integrate an ESAPI control into a web application. This demo will focus on solving a XSS issue on a small vulnerable web application.
One of the single largest enhancements to ESAPI 2.0 was a complete overhaul of the Crypto component. Kevin Wall drove this initiative from idea to completed project and will be highlighting the hows, whys, and whats of the enhancements.
ESAPI has come a long way since Jeff Williams originally started the project many years ago - and it has grown and evolved into something that is much bigger than any of us anticipated. The ESAPI Dev team will be outlining what you can expect to see over the next 12 months of ESAPI development and you will definitely not want to miss this.
The ESAPI Community is a new idea, focused on bringing in some of the awesome integration work that the user community has done and making it available as pluggable components that can be used to address common integration concerns such as using ESAPI with Struts or Spring.
Ghosts of XSS Past, Present and Future Jim Manico
This talk will discuss the past methods used for XSS defense that were only partially effective. Learning from these lessons, will will also discuss present day defensive methodologies that are effective, but place an undue burden on the developer. We will then finish with a discussion of future XSS defense mythologies that shift the burden of XSS defense from the developer to various frameworks. These include auto-escaping template technologies, browser-based defenses such as Content Security Policy, and Javascript sandboxes such as the Google CAJA project and JSReg.
The Good Hacker - Dismantling Web Malware Aditya K Sood, Richard Enbody
The talk sheds light on the new trends of web based malware. Technology and insecurity go hand in hand. With the advent of new attacks and techniques, the distribution of malware through the web has been increased tremendously. Browser Exploit Packs (BEP) (BlackHole, Phoenix, Bleeding Life, etc.) are increasing infections day by day. Most of these BEPs are used in conjunction with botnets such as Zeus and SpyEye to initiate infections across the web. The attackers spread malware elegantly by exploiting the vulnerabilities and drive by downloads. The infection strategies opted by attackers like malware distribution through IFRAME injections, SEO poisoning, URL trickery, social network manipulations, and web vulnerabilities act as a launchpad for web malware. Third generation banking malware such as SpyEye and Zeus has shown devastating artifacts. The question is, how we have to deal with them? Are our protection mechanisms sound enough? Do we need to hunt them back? All the answers will be provided in this talk covering the following points:
- Tracing the malware entry points in-network and hunting them
- Building up methodologies like a hacker to hit back at malware domains
- Analyzing trade and tactics of third generation banking malware
- Demonstrate the static, dynamic and behavioral analysis of web malware including PCAP analytics
- Understanding the design and relevance of Browser Exploit Packs
- Some hidden truths from the underground community
- Real time case studies will be discussed as part of our professional experience
Global Security Report Charles Henderson
Featuring analysis of more than 220 data breach investigations and more than 2,300 penetration tests conducted by Trustwave's SpiderLabs, the Global Security Report identifies the top vulnerabilities business encountered in the past year as well as a list of strategic initiatives to help your business improve its overall security.
The data gathered from these engagements is substantial and comprehensive. This presentation will be a summary of the results of the analysis of the data gathered during the past year. The results will be presented to cover both technical and business impact analysis.
Gray, the New Black: Gray-Box Web Penetration Testing Brian Chess, Ph.D.
Penetration testers who use only black-box tools are destined to lose to attackers who are willing to spend more time or effort looking for vulnerabilities. Defenders need to make use of one of the few natural advantages at their disposal: ready access to the system they're trying to protect.
In this talk I will build on previous research around defending running systems and discuss gray-box vulnerability testing techniques that expose web application internals so that testers understand what an application is doing and can spot vulnerabilities faster. The tool observes the program while it executes. It reveals attack surface, points out vulnerable program behavior, opens up a code-level view of the application, and allows a tester to understand information flow inside the program.
Hacking (and Defending) iPhone Applications Kevin Stadmeyer, Garrett Held
iPhone security is increasingly becoming a news-worthy event. As companies in all industries embrace mobile technology, mobile applications are the hot new technology. Writing iPhone applications presents unique challenges to application developers – and new opportunities to attackers looking to separate users and companies from their hard earned money. Many of the techniques and concerns discussed will also apply to other mobile platforms.
This talk will start with the basics - why do we care about mobile security, what the implications are for us as developers and assessors, and how to get your application into a testable state. We will discuss the benefits and negatives of testing on a device vs. testing on an emulator and how each to go down each path.
The implications of mobile security are far reaching and a breach through a mobile application can have financial, PR, and legal consequences for the organizations affected. We will discuss past cases, their root causes, and how future developers can avoid the same mistakes.
The presentation will provide detailed steps for setting up the test environment. We will cover the interception and modification of HTTP/S communications from iPhone applications to external web services. This will include installing a CA root SSL certificate in both the simulator and on a physical device.
After covering the basics this presentation will focus on the types of vulnerabilities normally encountered in the web application security world and how they may apply to the mobile application security world. We will cover which issues will apply as attacks against the client and which issues apply to the server.
Next we will speak about the types and locations of information that are stored by the device automatically. The talk will cover the areas of inadvertent local storage such as hidden screenshots and areas where text include credit card numbers, usernames and even passwords may be kept by the device well beyond any time frame imagined by the application developers.
Finally the issue of secure storage of information at rest on the device is examined. We will cover the current industry best practices regarding the secure local storage of information as well as propose new ways to securely access information from within the application.
At the conclusion of this talk audience members should have a solid working base of knowledge that they can then use to both build and test future iPhone based mobile applications. This talk will discuss new attacks and safety measures as well shine a light on some little understood aspects of secure local information storage.
Hacking .NET (C#) Applications: The Black Arts Jon McCoy (DigitalBodyGuard)
This talk will focus on attacking the .NET Runtime, Framework DLLs, Security of .NET applications and Security inside of a running .NET application.
Both white hat and black hat hacking will be shown on common security concerns such as intellectual property protection and licensing systems.
Last year I showed how to bend .NET applications and the Runtime. This year I will show how to break the rules of both the application and the Runtime. I will break rules like executing ASM shells and infecting the IL (byte code) of signed and protected EXE/DLLs. This breaking of the rules will make it easy to take out the most hardcore security systems such as USB dongles and network handshakes. I will show some of the Black Arts like making malware and Key-Gens/Cracks. This will take us to the point of also attacking malware and cracks.
I will show how to lock down a application to ensure it has no ability to attack the system it runs on. This will cover what security systems can be used and how to check if they are. Evaluations of what security systems are good/strong and others that are bad/weak, this will also talk about security systems that open vulnerabilities.
I will adapt this presentation from what I give at Black Hat and DEF CON it will be 80% the same with less focuses on attacking and more focus on penetration testing and security evaluations.
How NOT to Implement Cryptography for the OWASP Top 10 (Reloaded) Anthony J. Stieber
This talk is an update of a talk in 2008 at the OWASP Minneapolis-St.Paul Chapter which was about encryption as it applies to parts of the OWASP Top Ten. The new talk uses fresh examples of application cryptography successes and failures, and also incorporates the new OWASP ESAPI. Audience questions, participation, and contributions are encouraged.
Improve your SDLC with CAPEC and CWE Ryan Stinson
IT security needs to move from fighting fires to preventing fires. Unfortunately, developer incentives are all about meeting functional requirements and ship dates for their applications. The requirements and methods for developing rugged software have been challenging to articulate and implement; hence they are largely omitted from the development process. Mr. Stinson will show how to avoid making the "Top 25 Most Dangerous Software Errors" with the lessons he has learned from working with various application development teams throughout the SDLC. He will share how organizations can use the Common Attack Pattern Enumeration and Classification (CAPEC) and Common Weakness Enumeration (CWE) to reduce code vulnerabilities and improve their SDLC approaches. He will also provide real-world examples of how organizations can use these tools to set priorities and make practical risk-based decisions. The audience will see real exploitation scenarios that were made possible by the smallest of errors that were a result of translation issues early in the lifecycle but manifested themselves during in-depth application penetration testing.
Introducing the OWASP Zed Attack Proxy Simon Bennetts
The OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing as well as experienced pentesters.
A fork of the well regarded Paros Proxy, it was released in September 2010, has been downloaded over 10,000 times and has now been identified by the OWASP Global Projects Committee as a flagship OWASP project.
It has comprehensive help pages, is fully internationalized and has been translated into 10 languages.
ZAP's functionality includes:
- Intercepting Proxy
- Active scanner
- Passive scanner
- Spider
- Brute Force scanner (using DirBuster code)
- Fuzzer (using JBroFuzz code)
- Port Scanner
- Dynamic SSL certificates
- REST API
- Beanshell integration
This talk will cover:
- What ZAP is
- Why it was created
- What you can do with it
- Where its going
Keeping up with the Web-Application Security Ganesh Devarajan, Todd Redfoot
You read everyday in the news that so and so company got popped using xyz methodology. Go Daddy is the world's largest hosting provider, with data centers across the world, and more than one third of the Internet goes through our servers. We see over 120 million brute force attempts per day, a few thousand DDoS attempts per day and a couple of million web application attacks per day, which we do our best to block straight out of the gate. Most often people enumerate their top 10 or top 20 based on what they have seen or heard about... In this talk I will show you the true numbers behind the various attack types and show which part of the world favors what attack type. I will show graphs and maps of all the common attack types and from where they are originating. I will follow that up with an overview of what we are currently doing to defend against these attacks. Based on all this we have developed our own Internet threat level gauge. Also, we have developed our own Internet Blacklist, which we use in various part of our network to better protect our devices and our network.
In the second part of the talk I will cover how these vulnerabilities are exploited and what are the most common obfuscation techniques used by the attacker. I will also go over what the attacker's end objective was and what we are doing in order to detect and clean up those compromises. I will also go over various options and tools that the domain owners have at their disposal that can help them better secure their sites.
Lessons Learned Building Secure ASP.NET Applications Tom Fischer
Building more secure web applications with requires realistic goals and practical tools. In the real world of delivering web sites and services capable of passing security audits that often translates into meeting OWASP defined goals with vendor provided tools. After designing, building and enhancing several Microsoft-based applications over the years as consultant I learned a few lessons about delivering more secure web sites and services with OWASP and .NET. This presentation discusses a few of these lessons that will help most Microsoft developers today.
Out of the Box - The ASP.NET API provides several valuable tools which will immediately enhance security. Whether or not they're employed also involves trade-offs. This section discusses some of the more well known tools and their costs.
FxCop - While intended as a tool for enforcing the .NET Framework Design Guidelines, it can help your organization apply both community and custom secure coding guidelines. For example, the latest set rules for Visual Studio supports ASP.NET and its incantation of MVC.
New Technologies, New Opportunities - The recent explosion of tantalizing technologies from Microsoft comes with some new security unknowns. Successfully dealing with them may determine whether or not some of these new technologies, such as, AJAX, Azure, MVC, and LINQ, become the next hot area in security.
Making it in Information Security and Application Security Rafal Los, Mike McCormick, Christophe Veltsos, Jeff Williams
Information security, and especially application security, is a growing career field. Learn what works, what to avoid, and where to place your bets for the future - from people working in different capacities: a CEO at a consulting firm, a VP of security architecture at a company in a major industry vertical, a strategist at a major IT and solutions provider, and a professor.
Messaging Security using GlassFish 3.1 and Open Message Queue Srini Penchikala
In this session, I will cover the security aspects of Open Message Queue container. We will look at how to enable and configure security for various components in the messaging architecture. The discussion includes Authentication and Authorization for controlling access to the message broker components as well as how to implement message level security using encryption techniques.
I will also discuss the monitoring aspect and how we can use JMX API to monitor and manage various messaging resources such as the Broker, Services, Connections, Destinations, Producers, Consumers and Messages. I will demonstrate all the security features using a sample Java EE application running on GlassFish 3.1 and Open MQ.
Value:
Open Message Queue provides excellent support for securing messaging based Java EE applications. Attendees will be introduced to various security features offered by Open Message Queue. They can use the sample application to learn more about the message security services provided by the container and use it in their own applications right away. I will also demonstrate how to run the embedded broker from within a Java client, which can be used for unit testing in Agile Software Development.
Summary:
Open Message Queue is an open source message oriented middleware (MOM) and business integration system that can be used to design and implement reliable and scalable messaging based Java enterprise applications. OpenMQ container also provides an excellent support for securing the messaging applications. The security can be enabled at various levels of the application tier (like broker, destination, message, etc.) which gives the Architects, Developers, and Operations a complete solution to enforce and monitor security throughout the lifecycle of a message without having to install several different software components or services.
This session will cover the security aspects of Open Message Queue container. We will look at how to enable and configure security for various components in the messaging architecture. The discussion includes application security features (Authentication and Authorization) for controlling access to the message broker components as well as how to implement security at a message level using the encryption techniques.
I will explain how to connect to an LDAP data store (OpenDS Directory Server) to perform the user authentication. I will also cover the Message Queue support for the clients to communicate with the broker using secure protocol (HTTPS).
We will briefly look at how to integrate SOAP and Message Queue to process a JMS message containing a SOAP payload, to take advantage of the reliable messaging service offered by Message Queue.
In the presentation, I will also discuss the monitoring aspect and how we can use JMX API to monitor and manage various messaging resources such as the Broker, Services, Connections, Destinations, Producers, Consumers and Messages. Open MQ Administration Console as well as the VisualVM plugin for Open Message Queue will be used to demonstrate the monitoring of messaging components.
I will demonstrate all the security features of OpenMQ server provides out of the box, with the help of a sample Java EE application running on GlassFish 3.1 and Open MQ servers. The sample application uses various tools like GlassFish 3.1, Open Message Queue, Open DS Directory Server and Visual VM.
I will conclude the presentation with architectural patterns and best practices that architects and developers should consider when developing messaging based solutions using the Open MQ server.
Outline:
- Introduction
- Messaging and Security
- Security Aspects
- Authentication
- JAAS-Based Authentication
- Authorization
- Message Encryption
- Messaging Security
- Broker Level
- Destination Level
- Message Level
- Integrating SOAP and MessageQueue
- Sample Application
- Monitoring the Messaging Components
- Best Practices
- Conclusions
Key Takeaways
- Attendees will be introduced to various security features offered by Open Message Queue.
- Attendees can use the sample application to learn more about the message security services provided by the container and use it in their own applications right away.
- I will also demonstrate how to run the embedded broker from within a Java client, which can be used for unit testing purposes in Agile Software Development processes.
Mobile Applications Software Assurance Adam Meyers
Mobile computing has opened a new arena for consumer and enterprise usage. Originally for consumer use, mobile devices are now moving into the enterprise, making security an issue. Driven by consumer demand for features, these devices have few if any security controls, such as security updates, encryption, and perimeter control. Nor does the life cycle of a mobile device include secure removal of malware and control of applications downloaded. Mr. Meyers outlines the steps organizations and their developers need to take to protect their mobile applications from the bad guys. Some of these steps should be quite familiar but many have new wrinkles thanks to the unique characteristics of these small yet powerful devices.
Mobile Web Services Gunnar Peterson
They're not mobile applications, they're mobile web applications. This distinction is important because some of the most important vulnerabilities of mobile apps are found in the web service layer. This talk explores the weird but crucial area of server side plumbing and shows how to defend your servers.
Next Generation Web Attacks – HTML 5, DOM(L3) and XHR(L2) Shreeraj Shah
Browsers are escalating their feature set to accommodate new specifications like HTML 5, XHR Level 2 and DOM Level 3. It is forming the backbone of next generation applications running on mobile, PDA devices or desktops. The blend of DOM (Remote Execution stack) , XHR L2 (Sockets for injections) and HTML5 (Exploit delivery platform) is becoming an easy victim for attackers and worms. We have already witnessed these types of attacks on popular sites like Twitter, Facebook and Yahoo. It is of the essence to understand attack surface and vectors to protect next generation applications. We have an enormous expansion of attack surface after inclusion of features like audio/video tags, drag/drop APIs, CSS-Opacity, localstorage, web workers, DOM selectors, Mouse gesturing, native JSON, Cross Site access controls, offline browsing, etc. This extension of attack surface and exposure of server side APIs allow attacker to perform following lethal attacks and abuses.
- XHR abuse with attacking Cross Site access controls using level 2 calls
- JSON manipulations and poisoning
- DOM API injections and script executions
- Abusing HTML5 tag structure and attributes
- Localstorage manipulation and foreign site access
- Attacking client side sandbox architectures
- DOM scrubbing and logical abuse
- Browser hijacking and exploitation through advanced DOM features
- One-way CSRF and abusing vulnerable sites
- DOM event injections and controlling (Clickjacking)
- Hacking widgets, mashups and social networking sites
- Abusing client side Web 2.0 and RIA libraries
We will be covering the above attacks and their variants in detail along with some real life cases and demonstrations. It is also important to understand methods of discovering these types of vulnerabilities across the application base. We will see some new scanning tools and approaches to identify some of these key issues.
OWASP Codes of Conduct Colin Watson
The new OWASP Codes of Conduct are a collection of documents defining a set of minimal requirements for other types organizations specifying what OWASP believes to be the most effective ways they could support OWASP's mission. The Codes were largely developed at working sessions during the OWASP Summit in Portugal earlier this year and their scope includes government bodies, educational institutions, standards groups, trade organizations and certifying bodies. The Codes have now become a formal OWASP project and this presentation will outline the objectives, requirements and future plans for the Codes.
OWASP CRS and AppSensor Project Ryan Barnett
This talk will build on the OWASP AppSensor project workgroup at OWASP AppSec USA 2011 and additional insight from the OWASP AppSec USA 2011 Open Source Showcase and provide a hands on view of the OWASP Core Rule Set.
OWASP Mobile Top 10 Risks Jack Mannino, Zach Lanier, Mike Zusman
This presentation will feature the first public unveiling of the official OWASP Mobile Top 10 Risks. As many agree that mobile application security is in its infancy, this list is intended to help developers and organizations prioritize their security efforts throughout the development life cycle. Many of the same mistakes made over the past decade in other areas of application security have managed to resurface in the mobile world. There have also been many new security challenges introduced by mobile applications and platforms. Through the OWASP Mobile Security Project, the primary goal is to enhance the visibility of mobile security risks just as OWASP has successfully done for the web.
As the attack surface and threat landscape for mobile applications continues to rapidly evolve, arming developers with the tools they need to succeed is essential. Each environment presents very unique and different risks to consider. Our research and findings will be presented from a platform agnostic perspective.
OWASP Projects Portal Launch! (5-10 Minutes) Jason Li
The OWASP Global Projects Committee (GPC) is launching the new OWASP Projects Portal to manage and promote OWASP projects. The days of searching for project source code, project pages being clobbering by other project pages, and desperately reading pages of project listings to find the relevant project are coming to an end! The GPC has partnered with SourceForge to create individualized project pages, each with their own supporting infrastructure, all under the OWASP banner!
The project infrastructure perfectly complements the new OWASP Project Lifecycle, developed in conjunction with the community to simplify the project workflow and make project management more community driven. The new centralized infrastructure will help OWASP consumers more easily navigate the OWASP project landscape and help OWASP contributors receive the recognition and promotion they deserve for their projects! Come learn about the new features of the OWASP Projects Portal, see some of the projects already migrated to the new infrastructure, and help drive the future of projects at OWASP!
Principles of Patrolling: Applying Ranger School to Information Security Patrick Tatro
Army Ranger School is a leading school on developing leader's ability to make decisions, adapt to situations, and accomplish the mission. Information Security professionals face situations that don't fall under a framework or a standard. Few have the opportunity to experience the lessons learned in Ranger School by exceeding their mental and physical limits. Having experienced being a leader in these situations, I offer a different perspective on how to plan and design controls to improve your ability to make decisions.
The Army trains its soldiers to follow doctrinal maneuvers and tactics outlined in field manuals. Ranger School forces leaders to take responsibility for all their team does and fails to do regardless if the situations they face can be met with a tactic or maneuver. Information Security Professionals must address the ever changing business requirements. Applications, mobile apps, tablets, virtualization, and other platforms are moving into our organizations regardless of security concerns. Security frameworks, regulations, and standards allow us to implement security programs, design controls, or to become “compliant”. They don't provide the means for making decisions on “grey area” issues or trail behind technology.
Ranger students are provided with the 5 Principles of Patrolling to make decisions and adapt to situations. The tactics or controls may fall out of a specific tactic but may never violate a Principle of Patrolling. This empowers leaders to make decisions. These principles are applied similarly to the different variations of the C-I-A triad.
The 5 Principles of Patrolling are Planning, Reconnaissance, Security, Control, and Common Sense. Each of these can be applied to Information Security and will be elaborated upon in the presentation.
Planning can range from strategic planning down to tentative plans verbally discussed. Things never go as planned and having some type of plans in place provide a foundation for leaders make changes from when adapting to a situation. Often times, contingency plans or redundancy is overlooked or down played.
Reconnaissance defines Information Security Professionals. Staying current of the threat environment, technologies, laws, standards, and controls allow us to make decisions that will be successful today and into the future. Without that information, decisions are made to implement outdated or incorrect systems or security products.
Security is what we do. We cannot get tunnel vision on edge devices or on the technologies we are familiar with. Security is a state of mind and a posture of constant vigilance. Applying controls across our organizations need to cover all areas and not just what we are comfortable with as techies.
Control is often misunderstood. Managers believe they have control because they are in charge. Pushing information down and delegating tasks to all members of the team within the confines of a known plan provides real control. An IDS/IPS can be installed but is it doing what you expect it to do. Properly configuring that device to report or take action on what you want is the control leaders need to focus on.
Common sense is not common. If something doesn't seem right, it likely isn't. Employee requests need to be considered in terms of common sense for the business. If a tablet makes an employee more efficient and can save money then that makes sense. That doesn't mean security is ignored but it has to meet common sense to ensure employees and management buy into our controls.
As a Penetration Tester and Security Consultant, I need to be able to evaluate organizations based on limited exposures to their controls and networks. One framework or standard cannot be applied to every organization. I have expanded on the 5 Principles of Patrolling and have adapted that decision making structure to make me successful as an Information Security Professional. I would like to present this topic in more detail to other professionals.
Pure AppSec, No Fillers or Preservatives - OWASP Cheat Sheet Series Michael Coates
There is a small window of opportunity when someone is looking for the best advice to tackle a security concern. In those 15 seconds OWASP can provide an answer to the proposed question or be left behind for some other site that provides faulty or incomplete security guidance. Enter the OWASP Cheat Sheet series. These documents provide concise and complete security guidance on the most pressing application security topics. From cross site scripting, to SQL injection, to correct TLS usage and design, the cheat sheet series provides actionable information that can be quickly absorbed by the reader. Join us as we discuss the currently available cheat sheet topics, how you can get this information to your developers, and the future of the OWASP cheat sheet series.
Pwning intranets with HTML5 Javier Marcos de Prado, Juan Galiana Lara
A huge proportion of modern software are deployed as Web Applications. Following from this it has not taken attackers very long to migrate their effort into targeting these applications through their common means of access: the web browser. Taking advantage of modern web browsers features can be an important attack vector to break into a secured intranet.
This research is based on how to perform targeted attacks by enumerating internal resources and services belonging to a company's intranet using a client connected to the secure network, even behind a firewall. The attack is initiated by simply visiting a malicious website or exploiting well known web application vulnerabilities like Phishing or Cross-Site Scripting. It relies on web browser features such as HTML5, Websockets, Cross-Origin Resource Sharing and JavaScript, therefore, it will work in the latest version of a full-patched browser.
The presentation shows how far an attacker can get using a maliciously crafted website. For this purpose, several modules were designed and implemented to run on the open source Browser Exploitation Framework (BeEF). They allow an attacker to gather information about the victim's computer, network, and machines or devices in adjacent networks. Using this tool-set an attacker could discover hosts and draw a topology diagram of the network, perform a port scan of a specific host, internal DNS enumeration, basic OS fingerprinting and the ability to locate and exploit targets inside the victim's domain, including services that are not using the HTTP protocol using a technique called inter-protocol exploitation.
These tasks can be performed automatically with the set of modules we will be presenting and shows a clear example of how the tools can be weaponized and used by real targeted attacks, also known as Advanced Persistent Threats (APT), like Operation Aurora or the Apache.org attack.
Secure Programming Support in IDE Dr. Bill Chu, Jing Xie
Many of today's application security vulnerabilities are introduced by software developers writing insecure code. The OWASP community has already reached a consensus that developers do not write secure code for all kinds of reasons. We believe a lack of understanding of secure programming practices and developers' lapses of attention on security account for the top ones.
Much work, from both academia and industry including OWASP, on software/application security has focused on detecting software vulnerabilities through automated analysis techniques. While they are effective, we believe they are not sufficient. Tools that embody this approach tend to be used to find vulnerabilities at the end of the development lifecycle; thus, other business priorities may take precedence. Moreover, using such tools often requires some security expertise and can be costly. Additionally, if programmers are removed from this analysis process, these tools will also not help prevent them from continuing to write insecure code.
Expecting the majority of developers to proactively adopt secure coding practices is risky. Developers prioritize security at level six among all other software development focuses according to John Wilander's recent survey on more than 200 developers (). Swamped with all activities involved by the other development focuses and constrained by human inertia characteristics such as bounded rationality, developers rarely have the spare time and energy to attend to the activities required by producing high security quality applications. What is worse, without comprehensive understanding of how, where and when to use the given security technology, developers may introduce unwanted and unintended errors that may eventually turn to be security vulnerabilities when incorporating it to their development.
Thus, in this talk, we propose to increase developer awareness and promote practice of secure programming by interactively reminding programmers of secure programming practices inside Integrated Development Environments (IDEs). We introduce our proof-of-concept implementation for Eclipse and Java, which we refer to as Application Security IDE plugin (ASIDE). We use a case study to illustrate the practical benefits of integrating ESAPI with ASIDE to push secure coding knowledge and concrete best practices into developers' minds instead of relying on developers pulling them out from the application security sphere. More specifically, we use the IDE as a medium to direct developers when to use ESAPI, where to use ESAPI, which ESAPI API to use, how to use ESAPI, and how to use ESAPI in a correct way.
The ASIDE plugin is a prototype implementation of our interactive approach to reminding and helping programmers to perform good secure programming practices. It uses two key techniques to help programmers prevent errors: interactive code refactoring and interactive code annotation.
Interactive code refactoring works in a manner similar to a word processor corrects spelling and grammatical errors. In this case, ASIDE automatically inserts necessary code, with the help of the programmer. We believe code refactoring can be appropriately applied to input validation and/or filtering types of vulnerabilities. In this section, we discuss an example concerning input validation to illustrate the key concepts.
A developer is alerted by a marker and highlighted text in the edit window when input validation is needed. ASIDE has a rule-based specification language, which is also XML-based, to specify sources of untrusted inputs which we formally named as trust boundaries. Currently two types of rules are supported: Method (API) invocations, for example, method getParameter(String parameter) in class HttpServletRequest introduces user inputs from clients into the system; and Parameter input, for instance, arguments of the Java program entrance method main(String[] args).
With a mouse click, the developer has access to a list of possible validation options, such as a file path, URL, date, or safe text. Upon the selection of an option, appropriate input validation code will be inserted and the red marker will be dismissed. The library of input validation options can be easily reconfigured by an individual developer or an organization.
Interactive code annotation is a mechanism that helps developers to avoid more subtle security vulnerabilities where code refactoring is not feasible, such as broken access control and CSRF. Instead, programmers are asked to indicate where practices were performed, which is added as an annotation to the code. This serves as both a reminder to perform good practices, and enables further analysis and auditing.
We envision that this approach can detect and address common web application vulnerabilities and can serve as an effective aid for programmers, and it can also effectively complement existing software security best practices and significantly increase developer productivity. We do not think that we can take all security away from developers. If they are not educated about the right ways of doing things, they will keep committing the same errors over and over again. If one means of education is not effective, we just have to seek for another one that is effective.
Security Evolution - Bug Bounty Programs for Web Applications Michael Coates
It's all about scale; how can an organization possibly keep up with a growing number of web applications, features, and supported capabilities with a limited security team? One option that has provided successful results for several companies is a bug bounty program. These programs successfully engage the world community and bring many eyes towards the common good.
This talk will discuss the benefits and risks of a bounty program for web applications. What types of organizations consider starting a bounty? How would an organization start such a program and what should they expect? Is the return worth the effort? How does such a program compete with the black market?
In addition to these topics, we will also discuss the progress, metrics and lessons learned from the Mozilla web application bounty that was launched in December 2010.
The Self Healing Cloud: Protecting Applications and Infrastructure with Automated Virtual Patching Dan Cornell
Organizations often have to deploy arbitrary applications on their infrastructure without thorough security testing. These applications can contain serious security vulnerabilities that can be detected and exploited remotely and in an automated manner. The applications themselves and the infrastructure they are deployed on are then at risk of exploitation. Configuration changes or vendor-provided software updates and patches are typically used to address infrastructure vulnerabilities. However, application-level vulnerabilities often require coding changes to be fully addressed.
Virtual patching is a technique where targeted rules are created for web application firewalls (WAFs) or other IDS/IPS technologies to help mitigate specific known application vulnerabilities. This allows applications to be &virtually& patched prior to actual code-level patches being applied. These virtual patches are most often applicable to vulnerabilities that have a strong detection signature such as SQL injection and cross-site scripting (XSS) because the detection rules can be targeted to detect these signatures, but limited only to specific parts of the application attack surface where the application is known to be vulnerable.
This presentation examines the automatic creation of virtual patches from automated web application security scanner results and explores scenarios where this approach might be successfully employed. It discusses theoretical approaches to the problem and provides specific demonstrations using Open Source tools such as the skipfish and w3af scanners and Snort and mod_security protection technologies. Finally, it looks at opportunities to apply these techniques to protect arbitrary applications deployed into arbitrary infrastructures so that short-term protection against common web application attacks can be consistently applied while minimizing false blocking of legitimate traffic.
Simplifying Threat Modeling Mike Ware
Is threat modeling too tough to produce actionable results? Is it too overbearing on resources? Does it demand too much documentation?
Architects and developers often perceive threat modeling as being too difficult, heavy on documentation, and costly to both produce an initial threat model from a clean slate and to maintain it as the system evolves. During this talk, we'll attempt to bust these myths and show how organizations can incrementally obtain better results over time while making threat modeling "seem easy."
How does one simplify threat modeling? By removing the fluff and following 5-10 steps designed to produce 3 simple "security views" which architects, developers, and testers can act on: misuse/abuse view, asset flow view, and attack surface view. We'll explain how organizations just getting started with threat modeling can leverage or enhance SDLC artifacts they already produce to illuminate these security views. We'll also explain where these security views should be produced within a typical SDLC and who should create them. Finally, we'll describe how these security views are used to develop a threat matrix which describes who your threats are, where they might attack, what they will go after, and how they will do it.
Six Key Metrics: A look at the future of appsec Arian Evans
This presentation covers real-world key performance indicators (KPIs) necessary to create and sustain a successful, trustworthy, and scalable application security program in the enterprise. This presentation will overview
- The 2011 threat landscape from public forensic data
- The 2011 vulnerability landscape and stats
- The 2011 attacker profiles (from supporting stats)
- The challenges surrounding existing standards, programs, and metrics
- Keep it simple approach to quantitative and qualitative metrics
- Six Appsec KPIs broken down into two categories:
- Risk Analysis metrics – how to Qualify quantitative vulnerability data
- Appsec Program metrics – how to Quantify appsec program success
- Scaling: Initial results from "How to scale web application security" survey, OWASP Summit Portugal, and feedback from OWASP Europe
- Additional KPIs and program metrics suggested from OWASP summit scaling roundtable
- Danger: Anecdotal feedback from CISOs: Appsec Scaling Pitfalls from the Enterprise
- Review of OWASP project focus over the last decade, and where OWASP needs to go to grow
You should walk away from this with a solid idea of how you can enhance your Application Security efforts including using these KPIs in:
- Program initiatives, tracking and progress
- Application assessment reports
- Application security product findings & reporting
This presentation won't have any sexy zero-days or product demos, but it will include sexy pictures, charts, ideas, and a sexy speaker.
Software Assurance Automation throughout the Lifecycle Richard Struse
Over the past decade, software developers have been regularly prodded to write more secure code. While lists of common software weaknesses such as the OWASP Top Ten and the CWE/SANS Top Twenty Five are a good start, there is a clear need for tools, languages and repositories to help stem the tide of vulnerable code. Given the extraordinarily diverse landscape of software development languages, methodologies and tool sets, it is critical to have standards-based solutions that everyone can leverage. This presentation will provide an overview of the languages, enumerations and repositories that support and enable the automation of software assurance, with specific emphasis on practical applications that can improve software security today.
Sticking to the Facts: Scientific Study of Static Analysis Tools Chuck Willis, Kris Britton
The National Security Agency's Center for Assured Software (CAS) researches tools and techniques that can be used throughout the development lifecycle to evaluate and improve the assurance of software and to avoid and eliminate exploitable vulnerabilities. Over the past two years, the CAS has extensively and scientifically studied commercial and open source static analysis tools for C, C++, and Java. The purpose of this research is to determine the strengths and limitations of modern static analysis tools with respect to the flaws they identify, the flaws they miss, and the false positives they report. This presentation will describe the CAS's most recent study of commonly used static analysis tools and include details on the test cases, methodology, and analysis techniques used. It will cover the study's conclusions, aggregate results, and trending information from previous studies, and also provide guidance for those using or considering static analysis tools.
SwA and the Cloud - Counting the Risks Andy Murren
As organizations move to Cloud Computing the types and management of business risks changes. Measuring and assessing these risks presents a unique set of challenges. This presentation will cover the basic Cloud Computing service models and examine some business risks the resulting measurement and assessment methods organizations need to address.
- What is the impact on the organization's risk exposure and responsibilities?
- Are some of the risks associated with insecure design, code, and system configuration actually decreased or just transferred to other organizations?
- What steps should the organization take to reasonably manage those risks?
- Understand features of different Cloud Computing environments
- Integrate Cloud specific considerations into their SDLC and software management governance model
- How QA and Test professionals should consider extending their roles to better address "reliability, resilience, robustness, and security."
Threat Modeling in the Cloud: What You Don't Know Will Hurt You! Scott Matsumoto
When you deploy your application in the Cloud, how do you know whether you've introduced vulnerabilities that do not exist in your current deployment model? If you wait until you are about to deploy, that's too late.
Threat Modeling is a critical activity for identifying such vulnerabilities early in the development process. Proper threat modeling requires the identification of application's assets, security controls and attackers. For applications based on Amazon Web Services (AWS), there are subtle differences in the security controls provided by AWS when compared to more traditional data center hosted applications. These differences manifest themselves beyond the definitions of the security controls themselves; they also affect the application's overall structure and the design patterns required to create a secure application.
This talk first discusses the security controls in the AWS components: EC2, S3, EBS and SQS. It then describes how to build a threat model for an application built using these components. This talk does assume some familiarity with the AWS components, common web application design patterns and web application vulnerabilities; although in depth knowledge of these topics is not required.
Software Security: Is OK Good Enough? John B. Dickson, CISSP
Widely publicized breaches regularly occur involving insecure software. This is due to the fact that the vast majority of software in use today was not designed to withstand attacks encountered when deployed on hostile networks such as the Internet. What limited vulnerability statistics that exist confirm that most modern software includes coding flaws and design errors that put sensitive customer data at risk. Unfortunately, security officers and software project owners still struggle to justify investment to build secure software. Initial efforts to build justification models have not been embraced beyond the most security conscious organizations. Concepts like the "Rugged Software" are gaining traction, but have yet to make a deep impact. How does an organization – short of a breach – justify expending critical resources to build more secure software? Is it realistic to believe that an industry-driven solution such as the Payment Card Industry's Data Security Standard (PCI-DSS) can drive secure software investment before headlines prompt government to demand top-down regulation to "fix" the security of software?
This presentation will attempt to characterize the current landscape of software security from the perspective of a practitioner who regularly works with Fortune 500 chief security officers to build business cases for software security initiatives. Given the current status of software security efforts, and the struggles for business justification, industry would be well-served to look further afield to other competing models to identify future justification efforts. There is still much that can be learned from models outside the security and information technology fields. For example, the history of food safety provides lessons that the software security industry can draw from when developing justification models. We can also learn from building code adoption by earthquake-prone communities and draw comparisons to communities that have less rigorous building codes. Finally, we can learn much from certain financial regulations that have or have not improved confidence in our financial system.
Speeding Up Security Testing Panel Wendy Nather (moderator), Dinis Cruz, Chris Eng, Jerry Hoff, Darren Meyer, John Steven, Sean Fay
Dynamic and static analysis practices are converging quickly. Now how will organizations speed up security testing to make a compelling case for security/quality investment? Wendy Nather, who provides analysis on the current state of security in her position at The 451 Group, will moderate what is sure to be an entertaining panel with some of the sharpest researchers in this area.
STAAF: An Efficient Distributed Framework for Performing Large-Scale Android Application Analysis Ryan W Smith
There has been no shortage of Android malware analysis reports recently, but thus far that trend has not been accompanied with an equivalent scale of released public Android application tools or frameworks. To address this issue, we are presenting the Scalable Tailored Application Analysis Framework (STAAF), released as a new OWASP project for public use under Apache License 2.0. The goal of this framework is to allow a team of one or more analysts to efficiently analyze a large number of Android applications. In addition to large scale analysis, the framework aims to promote collaborative analysis through shared processing and results.
Our framework is designed using a modular and distributed approach, which allows each processing node to be highly tailored for a particular task. At the heart of the framework is the Resource Manager (RM) module, which is responsible for tracking samples, managing analysis modules, and storing results. The RM also serves to reduce processing time and data management through the deduplication of data and work, and it also aids with the scheduling of tasks so that they can be completed as a pipeline or as a single unit. When processing begins, the RM uses several default “primitive” modules that carry out the fundamental operations, such as extracting the manifest, transforming the Dalvik bytecode, and extracting application resources. The analysis modules then use the raw results to extract specific attributes such as permissions, receivers, invoked methods, external resources accessed, control flow graphs, etc., and these results are then stored in a distributed data store, after which the information can be queried for high level trends or targeted searches.
The modular nature of our framework allows independent analyses to happen on a per module basis, and the results of this data processing can be merged with other results at a later time. This design promotes an agile approach to large scale analysis, because it permits a wide array of analysis to happen distributively and in parallel. This means that teams with different needs or schedules can complete time-sensitive tasks separately with minimized data processing pipelines, while allowing more complex or time intensive tasks to be added later. Additionally, if analysis needs to be branched at some point in the pipeline, intermediate results can be retained and additional modules can be added leveraging the results from the past analysis steps. The results are also stored in a distributed database and designed to be queried using a map-reduce style query, which offers performance efficiencies as well as allowing the transparent inclusion of remote third party analysis databases. By using this plug-in style analysis framework, we are able to attain more efficient processing schedules and tailor the analysis for a specific need.
This framework is designed to be scalable and extensible, and the initial offering of this framework includes several modules that focus key aspects of the application analysis process. Our hope is that by releasing the framework, we will not only provide an efficient tool for automating and scaling analysis tasks, but we hope the work will encourage the sharing of research in the field. We will present a detailed overview of the architecture of the STAAF framework and the process for creating a customized implementation. We'll also demonstrate multiple use-case walk-throughs, and present results from our own analysis of a private collection of applications from the official Android market as well as several third party marketplaces.
Stealing Intellectual Property in 5 Easy Steps Tom Brennan
A Red Team Exercise
Shall we play a game? This talk will focus on full scope security assessments and stealing intellectual property in five easy steps. It will take the form of a game that divides the audience into attack and defend teams for a builder vs. breaker educational workshop. Included in the discussion will be physical, electronic (network, application, wireless, telecom, and cellular), and intelligence gathering techniques used for offensive projects.
Testing from the Cloud: Is the Sky Falling? Matt Tesauro
More and more IT is being moved to the cloud, why shouldn't your testing move there too? This talk will cover what it takes to take your testing tools from your laptop to the cloud using new features of the OWASP Web Testing Environment (WTE). WTE allows you to create custom installations of application security tools in the cloud on demand. Has your IP been shunned? No problem, kill that cloud instance and startup another. Is your life as mobile as your phone? No problem, a laptop + Internet = access to all your favorite tools from anywhere. Multiple clients? No problem, start an an instance for each one. By the end of this talk, you'll know all you need to fire up an cloud instance with all of your favorite tools and start having fun.
Top Ten Risks with Cloud that will keep you Awake at Night Shankar Babu Chebrolu, PhD, CISSP
Against the backdrop of new economic realities, one of the larger forces that is affecting businesses worldwide is cloud computing, whose benefits include agility, time to market, time to capability and reduced cost. Cloud computing is already transforming majority of the IT industry into services oriented IT organizations or simply IT as a Service (ITaaS), changing the way how solutions and services are designed and purchased. IT spending related to cloud adoption is projected to reach $42.2 B in 2012. Recently, US Federal CIO, Vivek Kundra, announced a major push towards Cloud to lower the cost of IT operations and drive innovations for US government.
However, there are many challenges that come along with cloud concept, biggest of them being security including trust, privacy, data ownership and control, availability, compliance and legal challenges. As borderless enterprises grow more reliant on cloud based solutions and services, data no longer resides within the physical premises of the enterprise creating ineffective network boundary controls. This shift demonstrates the need for data centric security models and extends trust boundaries with the cloud providers. Security is the top concern for cloud adoption and expectations from the security staff are all time high to apply a defense-in-depth strategy to protect enterprises, thus giving them sleepless nights.
In this presentation, Cisco infosec professional Shankar Babu Chebrolu will share the security challenges faced with cloud adoption at Cisco and other large enterprises. Shankar Babu Chebrolu has evaluated multiple cloud vendors for security and privacy risks and has also worked on the OWASP Cloud Top Ten Security Risks initiative describing risks faced with Cloud computing and XaaS models.
Web Application Security Payloads Andrés Riancho
Web Application Payloads are the evolution of old school system call payloads which are used in memory corruption exploits since the 70's. The basic problem solved by any payload is pretty simple: "I have access, what now?". In memory corruption exploits it's pretty easy to perform any specific task because after successful exploitation the attacker is able to control the CPU / memory and execute arbitrary system calls in order to create a new user or run an arbitrary command; but in the Web Application field, the attacker is restricted to the "system calls" that the vulnerable Web Application exposes:
- Local File Read - read()
- OS Commanding - exec()
- SQL Injection - read(), write() and possibly exec()
Web Application Payloads are small pieces of code that are run in the attackers box, and then translated by the Web application exploit to a combination of GET and POST requests to be sent to the remote web-server.
This talk will introduce attendees to the subject and show a working implementation of Web Application Payloads that uses the "system calls" exposed by vulnerable Web Applications to collect information from, and gain access to the remote Web server.
Our greatest achievement regarding web application payloads is the possibility of automatically downloading the remote application's source code, statically analyzing it to identify more vulnerabilities, and exploit those new vulnerabiliies to keep escalating privileges in the remote system.
The Web application payloads implementation was developed as a part of the w3af framework, an open source Web application attack and audit framework developed by contributors around the world since 2007 and lead by Andrés Riancho (the speaker) since its conception.
When Zombies Attack - a Tracking Love Story Ashkan Soltani, Gerrit Padgham
Online privacy and behavioral profiling are of growing concern among both consumers and government regulators. Consumers use the web for a variety of business and personal activities, including things that they would prefer to keep private. Mobile devices introduce additional concerns as typically, they are carried with us nearly everywhere we go. The "always on" nature of these systems closely mirror the activity of their owners, thereby revealing a historical trail of online and offline activities to multiple unknown third parties.
In this talk, we will present the current state of online tracking and highlight current practices such as "cookie respawning" and non-cookie based tracking that popular websites and mobile applications engage in. We will discuss theories on why the platforms we use do not adequately protect users from these threats and highlight the proposed solutions, such as additional transparency tools and Do-Not-Track that are intended to help mitigate these issues. We will also demonstrate MobileScope, a technical solution we have been developing to give the end user ultimate visibility into the traffic their device is sending. Finally, we will discuss open questions surrounding the ability to adequately assess risk drawing from behavioral economics and risk management theories for cues as to potential outcomes in this space.
Why do developers make these dangerous software errors? Michelle Moss, Nadya Bartol
According to the US Computer Emergency Readiness Team (US-CERT), most successful cyber-attacks result from targeting and exploiting software vulnerabilities, a significant number of which are introduced during software design, development, and sustainment phases of the lifecycle. Today's software modules and hardware components are created and assembled globally, and delivered physically and/or virtually. Unfortunately, many organizations do not understand the likelihood of a software vulnerability being exploited and the impact it could have on the organization's critical functions or business relationships. As a result, it is more challenging for security professionals to ensure the integrity, confidentiality, and availability of high-value data crucial to mission and business functions. It is understandable that IT security organizations struggle to justify funding, assign responsibly, and measure progress for application security. This presentation will provide insight to engaged appropriate stakeholders to address the technical, management, and operational aspects of incorporating software assurance into the IT lifecycle.
You're Not Done (Yet) – Turning Securable Apps into Secure Installations using SCAP Charles Schmidt
Secure software engineering practices get a great deal of attention today and deservedly so – they form a foundation without which effective security becomes impossible. However, this is not the end of a developer's part in supporting application security. Even the best software development methodology will only be able to make application security a possibility. To have a truly secure application, the end user or sysadmin must install and configure it and its dependencies correctly. Doing this requires that good security configuration practices be conveyed from the application developer to the end user in a format the user can utilize. While often neglected, this aspect of application security is what turns security theater into practical security that has a real benefit for enterprises and end users. This presentation gives the developer a roadmap on how to use the Security Content Automation Protocol (SCAP) suite of standards to ensure that their applications are correctly installed and configured.