AppSecUSA 2015

Companies are quickly racing towards DevOps and Agile to ensure they meet customer demands for automated solutions. And with this evolution, comes the need to further refine and innovate business processes that support product and service development. Along with other changes like migrations towards software defined environments and the Public Cloud, Security is fast becoming the new frontier for change because it plays a significant role in the deployment lifecycle for most applications, whether it be a gatekeeper or a partner in that process. New tools, products, and platform features are emerging within the security industry that requires a security professional to adapt their way of integrating with the software deployment process. Because of this, Security as Code is no longer just a dream of future nirvana, but a serious reality with a dramatic affect on how security professionals contribute value.

Security as Code is new and unchartered territory emerging from the integration of DevOps, Software Defined Environments, and Application Security practices. It is a foundational element for practicing DevSecOps and has inspired many within the security community to revisit the skills they have and the skills they will need for the future. We've been working with Ruby and developing APIs to support the security of a software defined stack and the domain applications deployed to the Public Cloud. This talk aims to bring the audience along on the experience of setting up for a Security as Code environment, the practices that have helped, the tools we use, and what we think is ahead of us.

A. Overview
We’ve been working in a mostly virtual environment for the past few years and have found that it has required a total shift in mindset, tooling, and operations to enable security within a software defined environment. With infrastructure and platforms rapidly being developed as APIs for developer and operator consumption, we’ve also realized that the job of security has grown in complexity, requires significant scale, and increased in speed. Meaning we haven’t been able to return to our checklists, manual controls, and assessments in a long time and now we can’t imagine going back. But mostly, we realized that the promise of getting better security by integrating with the Software Development Life Cycle and using automation to increase checks and tests as part of the deployment process is spot on.

B. Practicing Security as Code
Security as Code requires a program that supports organizing, mapping and testing policies, standards, and rules that secure infrastructure and applications within a software defined environment. Essentially, instead of developing perimeters, zones, and policies that get configured once to establish a data center driven by an applications purpose, software defined environments get created and assembled on an ongoing basis with security constantly changing and adapting to address new learnings, attack vectors, and remediation requirements. Security as Code is implemented by establishing a cross-between a Governance and Risk Management system and the Testing tools commonly deployed to support Application Security outcomes.

C. Tools of the Trade
We use a variety of tools to implement a resource based security controls program that helps with policy management, attack trees, and testing automation. We’ll talk about the tools we have developed in Ruby and some of the APIs we leverage from: Nessus, Burp, Maltego, Zap, Chef, and others to help reduce the time we spend automating for tests in our Security as Code pipeline. We’ll show how these tools come together to form the basis of our resource-oriented program and how we have developed a Grading system to provide for scaling remediation across our organization.

D. What’s Next?
We think we are at the forefront of change and that there are many new processes and tools to come. We’ve discovered many unsolved problems and few tools available to help with increasing the speed that security can be delivered when integrated with the Software Development Life Cycle. We’ll address the need for greater reconnaissance, some of the challenges of third parties, a lack of network controls, perimeter-less attack discovery, and auto-healing issues that arise from a shared responsibility model.

iSEC Partners routinely carry out Attacker Modeled Penetration Tests that use any and all means possible to gain entry to a company. The goal is to test organizations against true-to-life attack and penetration activities that real attackers use in the breaches that make headline News (and the breaches that don't).

Organizations that use Cloud Services to provision an operating environment to support a product, or use Cloud Service Providers to outsource elements of traditional enterprise IT into the Cloud, can find those very aspects used against them in an attack. While the potential attack surface for a breach changes, in many ways the use of Cloud infrastructure can make it easier for an attacker to gain access to critical systems and data. In this session the speaker will describe methods of penetration used during recent tests, illustrating how Cloud Services are viable entry points that lead to significant compromises. The following areas will be discussed:

- Common mistakes in deploying Internet-facing Cloud infrastructure
- Replication and communication paths between Cloud and on-premises infrastructure
- Effective ways for attackers to gain access to the Cloud Service administration console
- How the use of Cloud Services is weakening enterprise IT security
- Methods for securing Cloud Services, closing vulnerabilities and protecting the company

This session is a must-see for enterprise security professionals, software developers, system administrators and penetration testers.

Web applications are subjected to unwanted automated usage – day in, day out. Often these events relate to misuse of inherent valid functionality, rather than the attempted exploitation of unmitigated vulnerabilities. Also, excessive misuse is commonly mistakenly reported as application denial-of-service (DoS) like HTTP-flooding, when in fact the DoS is a side-effect instead of the primary intent. Some examples commonly referred to are:

* Account enumeration
* Click fraud
* Comment spam
* Content scraping
* Data aggregation
* Email address harvesting
* Fake account creation
* Password cracking
* Payment card testing
* Site crawling
* Transaction automation

Frequently these have sector-specific names. Most of these problems seen regularly by web application owners are not listed in any OWASP Top Ten or other top issue list. Furthermore, they are not enumerated or defined adequately in existing dictionaries. These factors have contributed to inadequate visibility, and an inconsistency in naming such threats, with a consequent lack of clarity in attempts to address the issues.

Without sharing a common language between devops, architects, business owners, security engineers, purchasers and suppliers/vendors, everyone has to make extra effort to communicate clearly. Misunderstandings can be costly. The adverse impacts affect the privacy and security of individuals as well as the security of the applications and related system components.

This presentation for the first time describes the work undertaken earlier this year and the concrete outputs completed including a new ontology of web application automation threats. Additionally the talk describes the primary and secondary symptoms, and current efforts to document and map relevant mitigations and protections. Attendees who own or operate production web sites, web APIs and other web applications will gain knowledge gathered from research and their peers about these threats, attack vectors, detection methods and protections against the unwanted automations.

To develop the ontology, research was undertaken to identify prior work and existing information about the types of automated threats to web applications using academic papers, breach reports, security incidents, and existing attack and vulnerability taxonomies. This has been refined using insider knowledge from application security experts and using interviews with web application owners. The initial objective was to assess and define a shared vocabulary about these sorts of "attacks", so that the problem can be defined and addressed further. The analysis focused on real-world external threats and attack vectors, although the impacts on individuals, intermediaries, partners and third party organisations are also being considered. Common Misuse Scoring System (CMSS) has been used in the analysis. The generated web application-specific ontology has also been mapped to other relevant sources including Security Content Automation Protocol (SCAP) components and the relevant parts of Mitre's Common Weakness Enumeration and Common Attack Pattern Enumeration and Classification (CAPEC).

The ontology has been published by the "OWASP Automation Threats to Web Applications Project" and is free to download and use. This OWASP project is intended to be an information hub for web application owners, providing practical resources to help them to protect their systems against these automated processes. The project is also seeking input in the form of event data that can be used to rank the threats for sectors such as financial services, ecommerce, hotel, travel, government, social media, gaming and gambling.

The recent major hacks at Sony, Target, Home Depot, Chase and Anthem all have something in common; they all gained access by stolen credentials. Hacking credit/debit cards is a growth industry, 66% CAGR. As more information and transactions are conducted online, the need for securing this information and these transactions is becoming paramount. There is increasing pressure to secure this information, customers wants it and shareholders are demanding it. Government regulations are good but they come slowly and the fraudsters seem to be gaining the upper hand.

There are a number of various biometric technologies being used with moderate success. Fingerprint, facial recognition, iris scan and voice recognition all provide a good level of security but are week in the area of usability.

Behavioral Biometrics is an area that offers ease of use, high level of security and does not require the need for passwords. An additional benefit is that there is nothing to remember, no special equipment and no personal identifiable information is used. Unlike the other biometric modes, the attributes are revocable which is useful in the corporate world.
How does it work? One scenario is authenticating login. It is a software-based second-factor biometric authentication solution. The technology compares, in real-time, users’ keying of known text against a previously-assembled cadence and habit library built using that known text. No keystroke character data is required for this comparison, only the keystroke timing data.

Some software algorithms function by comparing two chunks of independent typing samples (any text) and provides a statistical analysis of whether the same person typed it and how confident that is it the same person. Applications include, insider threat analysis, continuous monitoring, determining if it is still you after have successful login, and validating distance learning/certification.

These types of authentication are easliy configured and protect against MITM and MITB attacks.

Attackers typically have more compute resources and can spend much more time breaking components of applications than the engineers that write them in the first place. Since the pressure is on developers to release new code, even at the expense of security best practices, expecting all application vulnerabilities to be detected and remediated in advance of an application’s release is unrealistic to say the least.

One approach to combat this is to automatically build more security into the applications themselves. In this talk, the speakers will demonstrate some techniques to leverage the hooking of potentially vulnerable code paths in production applications and injecting code to introduce additional layers of security without requiring developers to write any code or recompile the applications. Specific examples will be given of hooking Java, .NET and Ruby frameworks.

Submit your questions here:
http://goo.gl/forms/jochnqYmBZ

The purpose of this presentation will be to introduce the audience to
new techniques attackers are using to target users of web applications
for exploitation.

The first part of this presentation will be an introduction to the
modern Malware landscape, with a breakdown of the top 5 types of
malware being actively used in campaigns to target end users of web
applications. Of interest, though perhaps unsurprising - the top three
are not what we traditionally think of as "malware" in the sense of
exploitative code or remote backdoors - but aimed at direct
monetization of the user.

The second part of this presentation will be a technical walkthrough a
real-world modern malvertising & malware campaign, and break down each
step of the attack, and each distribution & obfuscation layer. This
walkthrough will be the bulk of the presentation (30 minutes), leaving
time for Q & A at the end.

Time permitting, we may provide more examples of modern campaigns/malware.

Let’s be honest, PHP has had a rocky history with security. Over the years the language has been highly criticized for it’s lack of a focus on security and secure development practices. In more recent years, however, a resurgence has happened in the language and community, bringing secure development back into focus. With PHP 7 on the horizon, the language is making even more strides to improve some of its wayward ways of the past and reinvent itself. I’ll share practical code examples, tools, libraries and best practices that are making it easier than ever to keep PHP applications safe.

Come along with me as I guide you through both the language improvements and community encouragement making PHP a more secure place.

Test your wits and current AppSec news knowledge against our panel of distinguished guests. In the past, panelists have included Joshua Corman (Sonatype), Chris Eng (Veracode), Space Rogue (The Universe), Matt Tesauro (RackSpace), Ed Burns (Oracle), Justin Woo (PayPal), Jacob West (NetSuite) and Matthew McCullough (GitHub). "Wait Wait... Don't Pwn Me!" is patterned after the NPR news quiz show where we challenge the panel and the audience with "Bluff the Listener", "This Week's Security News", "The Security Limerick Challenge" and "Lightning Fill In the Blank".

Think you know your stuff? Get selected as an audience participant and prove it! Join us for a rollicking hour as we test the panel and the audience on recent security stories in the news. Who knows? Maybe you can pwn the panel.

AppSensor is a very active OWASP project that defines a conceptual framework, methodology, guidance and reference implementation to design and deploy malicious behavior detection and automated responses directly within software applications. The AppSensor idea was first conceived in 2008 and is the leading reference point in this area. More recently "application self-protection" has become a hot topic.

There are many security protections available to applications today. AppSensor builds on these by providing a mechanism that allows architects and developers to build into their applications a way to detect events and attacks, then automatically respond to them. Not only can this stop and/or reduce the impact of an attack, it gives you incredibly valuable visibility and security intelligence about the operational state of your applications.

The AppSensor project has released v2 this year. In this special presentation for AppSec USA, you will discover what AppSensor is and what it can offer you. The interesting features available in v2 will be covered along with upcoming features from the roadmap. In addition, you will learn how to cover different use cases with AppSensor by a walk-through of some sample applications. Lastly, you will receive information about the different components and integrations that make AppSensor enterprise-friendly.

Take-aways you will have from this presentation are:

* Knowledge about the benefits of proactive protection
* Information of the features in the new free-to-use reference implementation
* Guidance on implementing AppSensor in the real world
* Pointers to supporting materials specifically created for developers, architects, and senior management.
* Free copy of the 200-page v2 AppSensor Guide (also always available as a free PDF)

Additionally John and other members of the project team will be available after the presentation to continue discussion of the approach, and the AppSensor reference implementation.

For the past 15+ years all major automated XSS detection methods rely on payloads. Payloads are static exploit strings with previously known variations of exploits and exploit syntaxes. This presentation shows examples dynamic methods that do not rely on payloads to figure out if an XSS vulnerability exists. Furthermore these methods can be extended to provide, for the first time, accurate Stored XSS detection and generate dynamic custom XSS exploits. This presentation will show the current well-known automated XSS detection methods and the short comings of using a static payload methodology. It will then describe a number of methods and techniques that are used to provide dynamic XSS analysis. Finally, it will demonstrate how to create dynamic custom XSS exploits based on the dynamic detection XSS method described earlier in the presentation.