AppSec US 2018 (Please, make sure you register to attend)

As application security practitioners, we know that the attacks representing the most significant business risk for our organizations are often attacks targeting sensitive business functions of our applications. Those go far beyond the OWASP Top 10 and make generic (existing?) security tools inefficient. We require very tailor-made solutions to cover our security needs.

This talk will show how to create a security automation tool using dynamic instrumentation that helps to prevent business logic attacks. Sensors are added to the application source code, business events collected in an analysis engine and automated responses are pushed back to the application at runtime. The presented tool is based on open source libraries, and easily extensible and pluggable to analysis engines such as Kibana or Splunk.

Dynamic instrumentation is a game changer because it allows security teams to add sensors remotely, in real time, without asking development teams to trigger a new build and a new deploy of their applications.

The talk will include concrete business examples to help the audience apply this strategy. It will also give tips to navigate through the various teams (fraud, developers, product, …) that own a different piece of this security puzzle.

Continuous Delivery (CD) introduces a new set of challenges for application security testing, even compared with already fast Continuous Integration (CI) and DevOps methodologies. CD development organization can produce hundreds or even thousands of software updates per day, some of them taking no longer than a few hours from beginning to end. This puts pressure even on the best fast AppSec testing methodologies, such as fast incremental testing, restricted testing, etc.

True continuous testing calls for true, inline, continuous security testing, which does not rely on any dedicated testing slots. In this talk we will talk about some of these concepts - how to streamline security testing in the background, how to fit it into modern A/B testing cycles, and how to build an approval process that fits a modern CD workflow, rather than an old security go/no-go approach.

Join this talk if you would like to turn your application security testing methodology into one that can fit whatever development velocity your organization wants to go at!

In today’s DevSecOps world, “shift to the left” is not a new mantra for AppSec practitioners. It is imperative to notify developers about potential security issues as early as possible.

While heavy-weight static and dynamic analysis tools and fuzzers exist to find generic technical security flaws, finding custom security issues that are specific to an organization’s proprietary frameworks, APIs, libraries, etc. is often tricky, time-consuming and expensive to capture and maintain as “custom rules” in those tools. IDE plug-ins are often messy to deploy and maintain at scale in the real-world when you are dealing with highly diverse programming languages/frameworks and thus various versions of different IDE products.

Secure COde REview Bot (SCORE Bot) fills that gap and provides real-time, in-context security-oriented code review that focusses on org-specific security issues. It does that by automatically hooking into the GitHub Pull Request (PR) process and posts PR comments with not only the details about the identified security vulnerabilities but also remediation advice so that developers have actionable guidance to fix those security issues.

Driven by insights from behavioral science and experimentation (A/B testing), SCORE Bot became our reliable eyes-and-ears of the code being written at PayPal and a trusted security peer reviewer for our developers.

In this talk, we’ll share the lessons-learned from rolling out SCORE Bot at PayPal with details on what worked, what proved challenging with some real-world metrics from our deployment that scaled to cater to diverse programming languages, frameworks and CI/CD pipelines.

As enterprises are moving their iOS development towards Swift development from Objective C, it has become essential to adopt skills required to perform penetration testing/security audit of such applications. If you are working as Product Security Engineer or Bug Bounty hunter, it's important to know pentesting Swift application.

Considering such requirements, we're releasing brand new version of OWASP iGoat in Swift. Definitely, there are certain changes while pentesting Swift application over Objective C applications.

This talk is all about how you can find out security loopholes in Swift applications and as a developer how you can defend against them. This talk will help you learn iOS Swift App Pentesting from basics to advanced level using OWASP iGoat project.

This talk will discuss recent case studies of critical findings in iOS apps (Swift) and also help to address important issues as encryption key management, code obfuscation along with OWASP Top 10. We will release the major version of OWASP iGoat (Swift) at AppSec USA 2018.

Project code: https://github.com/OWASP/iGoat-Swift

Technology stack: Swift 4, Ruby

Security Development Lifecycle (SDL) methodologies have traditionally served consumer products and enterprise applications. These programs are usually well defined, with established architectures, target markets and product development cycles that span months or years.

Enter the Internet of Things, where there are no pre-defined form factors. An “IoT product” may be a smart fridge, a pacemaker, or a smart city. Makers of these classes of devices are often small/medium sized businesses, who are racing against the large corporates and other similar sized competitors to launch their products first. They look for standards in communication protocols, software stacks, libraries, and reuse them wherever possible. But standards are few and rarely one-size-fits-all. When it comes to securing IoT products, there are myriad of challenges on both process and technical fronts.

Our presentation introduces the audience to a cutting-edge version of Security Development Lifecycle, called the Security & Privacy Development Lifecycle (SPDL). Tailored specifically for IoT platforms, the SPDL is an agile framework that breaks-up a “generic” IoT architecture into its logical sub-components, accounts for the security assessment activities for each of them, as well as for the entire ecosystem. Privacy is woven into the process, and privacy-specific activities are planned at each step of the SPDL. Using standard waterfall-oriented SDL methodologies for IoT programs can be challenging and messy. We talk about the shortcomings of these existing models, and how our proposed SPDL framework addresses them.

As we write this, there’s extensive media coverage on companies collecting and sharing user data with third parties leading to global consequences. Compliance with privacy (for example, consent rules in GDPR) can be very challenging for IoT. We explore some of these topics, and also introduce a privacy vulnerability scoring framework (CPVSS) that can aid in measuring, prioritizing and addressing privacy breaches and data thefts.

Even though modern mobile operating systems like iOS and Android offer great APIs for secure data storage and communication, those APIs have to be used correctly in order to be effective. Data storage, inter-app communication, proper usage of cryptographic APIs and secure network communication are only some of the aspects that require careful consideration. The OWASP Mobile Security Testing Guide (MSTG) is a comprehensive manual for testing the security of mobile apps. It describes processes and techniques for verifying the requirements listed in the Mobile Application Security Verification Standard (MASVS) and provides a baseline for complete and consistent security tests.



In this talk, the final version of the MASVS and MSTG will be introduced and will discuss the many challenges we faced during development, from dealing with the diversity and fragmentation of the Android ecosystem to clarifying the role of software protections in mobile security.