AppSec USA 2017 has ended

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

DevOpsSec [clear filter]
Thursday, September 21

10:30am EDT

Test Driven Security in the DevOps pipeline

The myth of attackers breaking through layers of firewalls or decoding encryption with their smartphones makes for great movies, but poor real world examples. In the majority of cases, attackers go for easy targets: web frameworks with security vulnerabilities, out of date systems, administration pages open to the Internet with guessable passwords or security credentials mistakenly leaked in open source code are all popular candidates. The goal of Test Driven Security is to take care of the baseline: apply elementary sets of controls on applications and infrastructures, and test them continuously, directly inside the DevOps deployment pipeline.


A baseline of security controls defines the minimal requirements applications should match before being deployed to production. The controls are simple and specific, such as:

- All websites must implement a Content Security Policy

- Form submission must require CSRF tokens, unless explicitely whitelisted

- SSH Root login must require sudo on all systems

- The rules in firewalls and security groups must be tested at every deployment

- HTTP traffic is prohibited, HTTPS endpoints must use Mozilla's modern guidelines

- Outdated and vulnerable dependencies must be upgraded


The list of security best practices is established by the security team with the help of developers and operators to make sure everyone agrees on their value. A list of baseline requirements can be assembled quickly by collecting those best practices and adding some common sense. The controls themselves are simple and do not require particular expertise, the difficulty comes from testing and implementing them everywhere and all the time.


This is where Test Driven Security comes in. TDS is a similar approach to Test Driven Development (TDD) which recommends developers to write tests that represent the desired behavior first, then write the code that implements the tests. TDS proposes to write security tests first, thus representing the expected state, and then implement the controls that pass the tests.


The TDS approach brings several benefits:


1. Writing tests forces security engineer to clarify and document expectations. Engineers can build products with the full knowledge of the required controls rather than catching up post-implementation.


2. Controls must be small and very specific units which are easy to tests. Vague requirements such as “encrypt network communication” are avoided, instead we will prefer the explicit “enforce HTTPS with ciphers X, Y and Z or all traffic”, which clearly states what is expected.


3. Re-usability of the tests across products is high, as most products and services share the same base infrastructure. Once a set of baseline tests is written, the security team can focus on more complex tasks.


4. Security regressions are caught in real-time, prior to deployment, rather than periodically during manual reviews.


Let’s take an example. A good practice for web applications is to enforce the use of HTTPS on all traffic, which can be done using HTTP Strict Transport Security (HSTS). A website can set a HSTS header returned with HTTP responses to tell web browsers to always HTTPS when connecting to the site, never HTTP. It’s a simple control, trivial to configure at the web server or application level, that we can very easily test for by looking at the headers returned by a website.


The code sample below shows how a simple Bash script can check the value of HSTS on a local application (https://localhost:8080/). This test can easily be part of the integration pipeline, perhaps run automatically as part of a pull request. The test should be defined ahead of implementing HSTS itself. It will fail when the HSTS header is unset or when its value is lower than 90 days. As soon as the website returns an acceptable value, the test will succeed.


#!/usr/bin/env bash

hsts=$(curl -si https://localhost:8080 |

grep 'Strict-Transport-Security:' |

awk '{print $2}' |

cut -d '=' -f 2 | sed 's/\r//')

if [ "$hsts" != "" ] && [ "$hsts" -gt 7776000 ]; then

echo "HSTS test passes. value is $((hsts/86400))days"

exit 0


echo "Strict transport security is lower than the expected 90days value"

exit 1



Tests in the TDS approach will fail initially. This is expected to verify their correctness once they pass after the feature is implemented. Security teams should help developers and operators implement controls in their software and infrastructure at first, taking each test one by one and providing guidance on implementation, and eventually transfer ownership of the tests to the DevOps teams. When a test passes, the teams are confident the control is implemented correctly and the test should never fail ever again.


An important part of TDS is to treat security as a feature of the product. This is achieved by implementing controls directly into the code or the systems of the product. Security teams that do not collaborate with developers, and implement security outside of the applications and infrastructure, instigate a culture of distrust that eventually puts organizations at risk. You should shy away from this approach. Not only does it create tensions between teams, it also provides poor security as controls are not aware of the exact behavior of the application and miss things. A security strategy that isn’t owned by the engineering teams will not survive very long, and will slowly degrade over time. It is critical for the security team to define, implement and test, but it is equally critical to delegate ownership of key components to the right people.


TDS adopts the DevOps principles of automating the pipeline and working closely with dev and ops teams. It forces security folks to build and test security controls within the environments adopted by developers and operators, instead of building their own separate security infrastructure.


In the presentation, I will show how we implement TDS using a variety of open source tools:


- OWASP Zaproxy takes care of the baseline scan of web applications. We have worked closely with the core team of ZAP to implement Test Driven Security. We run baseline scan in two ways: 1) In the CI pipeline, like Travis-ci or CircleCI, to give feedback on pull requests and 2) in Jenkins as part of the deployment pipeline of each service, to test staging endpoint every time they are deployed.


- Static analysis tools, like jshint or gas, are used to inspect the source code of applications in CI.


- Dependency management tools, like NSP (Node Security Project) or goreport, are used to check for issues in third party of the applications. We also use closed source platforms like requires.io or greenkeeper.


- Infrastructure auditing is done via tools like Pineapple, which is used to verify the state of security groups in AWS.


Over the past 18 months, we have implemented TDS over a hundred of applications, websites and services and successfully improved our security posture. In this presentation, I will describe the techniques we developed to integrate TDS deep into the DevOps pipeline. The tooling we created will be presented to the audience, with links to resources they can use freely. I will also discuss the human aspect of integrating security processes into development and operations workflows, and how to succeed without disrupting slowing down organization’s SDLC.


avatar for Julien Vehent

Julien Vehent

Firefox Operations Security Lead, Mozilla
Julien leads the Firefox Operations Security team at Mozilla, tasked with defining, implementing and operating the security of Firefox's backend services and release engineering infrastructure. Julien's background is in web applications security, services architecture, cryptography... Read More →

Thursday September 21, 2017 10:30am - 11:15am EDT
Coronado H

11:30am EDT

Overcoming Mobile App Security Challenges with DevOps

As companies make the cultural shift towards DevOps, native mobile applications present a number of unique challenges. Results of a recent survey suggest that 81 percent of enterprises and 70 percent of small-to-medium businesses have adopted some form of DevOps. Yet another survey, though, reports that only 29 percent of mobile applications are undergoing security assessments. Why does this gap exist? I will examine the unique DevOps problems put forth by mobile app development, and discuss how implementing mobile DevSecOps practices can mitigate their effects.

The talk will focus on identifying and demonstrating the impact of mobile-specific DevSecOps challenges:


Broader mobile framework specialties: Examining a mobile app extends beyond the application code itself. A fully functional mobile security team must be able to forensically analyze data stored on the phone, examine APIs and communications protocols, perform server-side penetration testing, and reverse engineer an application to perform thorough assessments at scale.


Technology fragmentation: Not only are mobile apps deployed across a multitude of hardware devices, steps taken by Apple and Google to secure the iOS and Android platforms eliminate avenues security pros use to detect and respond to mobile security threats.


Mobile apps expose enterprise architecture: A mobile app is often an endpoint for a much deeper enterprise architecture, so a compromised app can have far reaching effects.


Faster time frames: Even in the fast paced DevOps world, mobile applications have even more accelerated timelines for release. In order to build - and maintain - a user base, mobile apps need to be deployed and updated more frequently. This shorter development cycle stresses systems that may already be in place.


Push vs. pull updating - the unique nature of app stores mean that users have to “pull” updates, rather than the developer “pushing” them to existing installations.


The talk will then focus on how to leverage the strengths of DevSecOps processes to mitigate each these challenges in mobile. I will discuss strategies connected to each of the problems above with a focus on leveraging automation, process, and culture. A particular focus will be making the case for early and automatic security testing and providing examples of practical solutions.

avatar for Brian Lawrence

Brian Lawrence

Solution Engineer, NowSecure
At NowSecure, Brian helps enterprises design and implement solutions to secure their mobile transformations and develop higher quality, more secure mobile apps. Prior to a stint in the restaurant and hospitality industries, Brian instituted a managed services provider's SaaS delivery... Read More →

Thursday September 21, 2017 11:30am - 12:15pm EDT
Coronado H

1:30pm EDT

Making Vulnerability Management Less Painful with OWASP DefectDojo
DefectDojo was created in 2013 when one security engineer at Rackspace stupidly opened his mouth in front of his leadership team. Vulnerability management is traditionally tedious, time consuming, and mentally draining. DefectDojo attempts to streamline vulnerability management with automation centered around templating, report generation, metrics, scanner consolidation, and baseline self-service tools. DefectDojo is currently used by multiple large enterprises and has core contributors from five different companies. It has made several engineers' lives much easier, and it can help you too. Got a ton of findings to consolidate and report on? DefectDojo has you covered. Need to have a dashboard of your team’s work? DefectDojo has you covered. Tired of boilerplate report generation? DefectDojo does that for you. Come check out how to make vulnerability management less painful and speed up your appsec program in this talk with demo.

avatar for Greg Anderson

Greg Anderson

Senior Security Engineer, Pearson
Greg Anderson is a security professional with diverse experience ranging from vulnerability assessments to intrusion detection and root cause analysis. Greg’s recent work has focused on advanced security automation to get the most out of application security programs. Greg’s... Read More →

Thursday September 21, 2017 1:30pm - 2:15pm EDT
Coronado H

2:30pm EDT

Juggling the Elephants – Making AppSec a Continuous Program

As security professionals charged with protecting large enterprise application portfolios, we continually find ourselves managing a wide array of disparate security initiatives, each of which demands to be treated as a top priority. Few of these initiatives ever achieve full coverage across the application portfolio. So we’re left to prioritize on the fly and try to keep everything we’re juggling in the air. Inevitably some will get dropped.


What if we could develop an AppSec program that ties those disparate initiatives together into a repeatable and continuous program that not only addresses coverage of the entire portfolio but acts as an enabler of high-paced development paradigms such as DevOps and CI/CD? In this presentation we’ll discuss a model for deploying AppSec programs that addresses these goals. A strategy for tying together various security activities including threat modeling, code reviews, and penetration tests, with business and risk processes in a way that actually makes development more efficient. We’ll discuss how an organization can tailor their own program based on the model but addressing the unique challenges and business goals of the individual firm.


You’ll see how the Continuous AppSec Model leverages the key principles of the latest OWASP SAMM to break down and unify your security activities. You’ll learn how an Application Security Program can be designed to enable continuous improvement within the program itself. You’ll discover how this continuous improvement allows for implementation of a program based on this model in an easily digestible and incremental fashion. You’ll understand how a truly continuous program allows you to better prioritize your security initiatives by providing you a clearer picture of the risks across your environment. You’ll leave with a better strategy for enabling your application teams to not only support but actually advocate for the security practices already employed within your enterprise as well as those perhaps thought too advanced for your organization.

avatar for Tony Miller

Tony Miller

Practice Leader, Aspect Security
Tony Miller is a highly experienced application security leader. Tony heads the Program Services practice at Aspect Security where he assists security and business leaders in global fortune 500 companies with strengthening their strategic approach to application security. Prior... Read More →

Thursday September 21, 2017 2:30pm - 3:15pm EDT
Coronado H

3:30pm EDT

WAFs FTW! A modern devops approach to security testing your WAF

Although Web Application Firewalls (WAFs) are recognized as an effective aspect of a defense in depth strategy, there are few tools that attempt to objectively review their effectiveness. Research companies like NSS or Gartner perform benchmarks of WAFs, but their methodologies are rarely disclosed. With the advent of site reliability and devops cultures, infrastructure as code has been a strategy to verify functionality of products. This talk brings that same mentality to WAFs; not only do we verify WAF functionality within deployments, but we also provide a method to verify WAF defenses against new exploits and attacks. We do this with our project FTW - Framework for Testing WAFs.


We achieved two outcomes from this project. The first was to design a framework that is extendable to test arbitrary WAF implementations. This would allow engineers to compare WAFs to help them make an informed purchase decision for their organization instead of relying on reports and literature that do not disclose their testing methodologies. Secondly, we want to have the ability to develop new tests without the need for development experience. This allows rapid prototyping of attack payloads without the need of a scripting language. These payloads are then executed against various WAF implementations to see how the WAF responds. Once tested, new rules can be deployed within the WAF and then the attack is added to a corpus of attacks for continuous testing.


We will first review the design of the tests. We use the OWASP Core Ruleset Version 3 (CRSv3) as our benchmark for web attacks and defenses, so the first task was to translate the CRS and write attacks to make sure the rules trigger. This resulted in a corpus of 1000s of attacks provided for end users at no cost. Tests are written in YAML format, and we will go into detail on how the format is developed to include both basic HTTP attacks as well as more advanced multi-stage attacks.


Next, we will review the architecture of the code. Py.test is used as the testing foundation due to the wide adoption within industry it enjoys, its ability to parametrize the YAML test files, as well as its ease of use in continuous integration environments. We show how an individual can set up an FTW testing environment and start writing or editing tests, as well as creating new ones. We will then show continuous integration strategies to test and deploy new WAF rules. We use Travis-CI as the continuous integration technology, but traditional CI or deployment tech can also be used.


We then will move into the crux of our presentation where we highlight the results. We plan to discuss how this project is being used throughout the community. The ModSecurity team used FTW extensively for regression testing in the CRS. We will show lessons learned and how regression testing in security is extremely important. We will also show a use case for how an origination uses FTW to ship WAF rules for their customers on the edge. Strategies to ship WAF rules include continuous integration and applying security to the SDLC of these deployments. Lastly, we highlight a journaling feature that allows security engineers and red teamers issue a battering ram of web attacks and log responses into a local database for pentest reports.


The Current Code

https://github.com/crs-support/ftw to check our code

https://github.com/fastly/waf_testbed for a VM that spawns the latest CRS w/ the latest FTW to start running tests

https://github.com/SpiderLabs/OWASP-CRS-regressions/tree/master/tests for CRS attacks

https://github.com/SpiderLabs/owasp-modsecurity-crs/ latest CRS

avatar for Zack Allen

Zack Allen

Manager, Threat Operations, ZeroFOX
Threat Intelligence, Data Science, Web Security, SecDevOps and if you want a job!

Thursday September 21, 2017 3:30pm - 4:15pm EDT
Coronado H
Friday, September 22

9:00am EDT

Building a Secure DevOps Pipeline
Is software development outpacing your ability to secure your company’s portfolio of apps?  You don’t have to buy into Agile, DevOps or CI/CD to realize the business wants to move faster.  And it's not like you didn’t already have more than enough to do. This talk will cover how to take the lessons learned from forward thinking software development and show you how they have been applied across several business.  This isn’t a theoretical talk.  It covers the results of  successfully applying these strategies to AppSec across multiple companies ranging from 4,000 to 40,000+ employees.  Yes, real stats on improvements seen will be provided. By changing focus from a point in time security testing and assessments to automation, continual health checks and event-based security, your AppSec program can start to keep pace with the increasing speed of delivery your business is trying to obtain.  By embracing the same methodologies, you can turn Docker from a problem to how you horizontally scale your security work.  Don't swim against the current of DevOps, Agile software development and Continuous Delivery.  Instead use those movements to speed your AppSec program to new levels.

avatar for Matt Tesauro

Matt Tesauro

Matt Tesauro is currently establishing a SDLC at a large healthcare software provider. Prior to his current role, he was a Senior AppSec Engineer building an AppSec Pipeline and continuous security program for Duo Security. Previously, he was a founder and CTO of 10Security, a Senior... Read More →
avatar for Aaron Weaver

Aaron Weaver

Application Security Manager, NA Bancard
Aaron Weaver is the Application Security Manager at NA Bancard. Prior to that he was at Cengage Learning and Protiviti where he built out their secure coding practice. Aaron has managed application security programs at large organizations and leads OWASP Philadelphia. Aaron speaks... Read More →

Friday September 22, 2017 9:00am - 9:45am EDT
Coronado H

10:30am EDT

Monitoring Application Attack Surface and Integrating Security into DevOps Pipelines
A web application’s attack surface is the combination of URLs it will respond to as well as the inputs to those URLs that can change the behavior of the application. Understanding an application’s attack surface is critical to being able to provide sufficient security test coverage, and by watching an application’s attack surface change over time security and development teams can help target and optimize testing activities. This presentation looks at methods of calculating web application attack surface and tracking the evolution of attack surface over time. In addition, it looks at metrics and thresholds that can be used to craft policies for integrating different testing activities into Continuous Integration / Continuous Delivery (CI/CD) pipelines for teams integrating security into their DevOps practices.

avatar for Dan Cornell

Dan Cornell

CTO, Denim Group
A globally recognized application security expert, Dan Cornell holds over 20 years of experience architecting, developing and securing web-based software systems. As Chief Technology Officer and Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies... Read More →

Friday September 22, 2017 10:30am - 11:15am EDT
Coronado H

11:30am EDT

Core Rule Set for the Masses

Everyone who has used, or attempted to use, OWASP ModSecurity Web Application Firewall knows something about fine-tuning rules. ModSecurity Core Rule Set (CRS) was designed to catch more, show more and let you decide what to do with security alerts. It is a time consuming -- and often frustrating -- exercise to analyze alerts, separating the wheat from the chaff, and determine which are candidates for blocking.


With thousands of servers at more than 100 locations, Verizon Edgecast CDN is one of the world’s largest deployment of OWASP Core Rule Set. We will share our experience in fine-tuning the CRS for a large number of customers, adjusting to their taste in risk and attitude toward false positives. We will discuss lesser used features of ModSecurity to cut down noise levels in alerts, sometimes as much as 90%. We will also discuss our experience in moving from CRS 2.2.9 to 3.0 which was released in late 2016.


We hope that the audience will walk away with understanding benefits of using the venerable web application firewall with the latest enhancements and issues to consider to get the most out of it. Ultimately, we hope that our experience will make your task of fine-tuning the CRS a little easier.

avatar for Robert Whitley

Robert Whitley

Security Solutions Architect, Verizon Digital Media Services
Robert Whitley started out his career as a customer facing SOC analyst that allowed him to explore the breadth of the information security field. After working closely on incident response and threat intel, Robert now spends his day to day on consulting users on WAF and rate limiting... Read More →
avatar for Tin Zaw

Tin Zaw

Director, Security Solutions, Verizon
The author resides in sunny southern California, where he seeks a Zen state of mind amid the chaotic mix of technology, society and cyber threats. Wanting to make the world safer online, he gave up his beloved programming job to focus on cyber security. He is a former president of... Read More →

Friday September 22, 2017 11:30am - 12:15pm EDT
Coronado H

1:30pm EDT

DevSecOps is real - What we learned by matching our appsec testing to our continuous release cycles

SaaS-first businesses like Salesforce, Box, Hubspot, Wix, ServiceNow, and Workday are taking over. It’s actually becoming risky for enterprise software companies NOT to adopt the SaaS technology and business model. There’s a real fear of being left behind. Over the next 10–20 years, every software company will be a SaaS company.


As a software-as-a-service company, Egnyte is innovating fast. It’s all about speed of innovation, design, and usability. The faster you can go, the less you spend on product development, and the fewer person hours are required to deliver a complete solution. Every iteration is an opportunity to deliver greater business value.


The problem with buying a SaaS solution from someone you don’t know is trust. When you don’t have a long-term, heavily invested relationship with your customers (as in the old-school IT-driven, on-premise local data center implementation model), how do you signal quality? Elements like security and regulatory compliance must be maintained, but the way they are implemented can’t slow the business down.


At Egnyte, we publish new software updates, features, and enhancements every two weeks. Secure software is business critical, and application security is what really matters. When it comes to software security, I am reasonably confident in our internal release criteria, which includes quality assurance and regression tests, automated security checks, as well as regular periodic software security assessment scans on our public-facing and production applications. But automated tools can’t find everything. Human powered security testing is necessary, and on-demand specialization wins.


Join Kris Lahiri, CISO of Egnyte, for an in depth discussion of the evolution of his software security program - what he tried, what worked, what didn’t, and how he’s planning to move forward. This session is a must-see for any security leader responsible for application security at a Saas company.

avatar for Kris Lahiri

Kris Lahiri

Chief Security Officer, Egnyte Inc
Kris is a co-founder of Egnyte. He is responsible for Egnyte's security and compliance, as well as the core infrastructure, including storage and data center operations. Prior to Egnyte, Kris spent many years in the design and deployment of large-scale infrastructures for Fortune... Read More →

Friday September 22, 2017 1:30pm - 2:15pm EDT
Coronado H

2:30pm EDT

How to stop worring about application Container security


Containers make it easier to deploy the applications that drive business value, but also profoundly challenge existing security models. Learn from our journey as a security team that went from not knowing what containers were to championing their adoption in our production sensitive information workloads over traditional DevOps application deployments.

• About Us

• Our Application & Security Challenges

• Our Container Journey

• Building an Container Ecosystem

• Learning Secure Application Containers

• Benefits for DevOps and Security

• Our Container Security Maturity Model

• What’s Next

avatar for Brian Andrzejewski

Brian Andrzejewski

Information Security Engineer, U.S. Citizenship and Immigration Services (USCIS)
Brian is the lead InfoSec Engineer in the CyberDefense Branch at the United States Immigration Services (USCIS), the world’s largest immigration agency. He leads, engineers, and architects several of USCIS’s security efforts, with his primary focus in application security and... Read More →

Friday September 22, 2017 2:30pm - 3:15pm EDT
Coronado H

3:30pm EDT

Practical Dynamic Application Security Testing within an Enterprise

The incorporation of DevOps within a large enterprise is generally accomplished through strategic planning on the organizational level. Having a common pipeline for Continuous Integration (CI) and Continuous Deployment (CD) can enhance the security posture of an application and enable organizations to rapidly release applications into production. However, the insertion of application security in the pipeline is only one step of a multidimensional application security approach.


In this presentation, we will describe our implementation of two complementary methods, which have allowed us to provide the scalability and coverage required in order to meet the needs of a large enterprise. The first method utilizes a tool written in Java to allow for easy integration with your build. We will demonstrate how to deploy and use a dynamic scanner within a Continuous Integration (CI) and Continuous Deployment (CD) pipeline. The second method leverages the data collected from analytic tools such as Splunk, LogStash, Tealeaf and SiteCatalyst. Through the utilization of containers, we will demonstrate how a RESTful API service can be implemented to perform a quick analysis of applications to ensure basic security requirements are met on a large scale. An example will be presented utilizing a RESTful API service to enhance our continuous scanning platform with multiple scanning technologies.


Implementing these solutions has transformed the way we assess our applications. Using the first method we were able to present a dynamic scanning solution to all of our applications that support automated regression testing. Our second method has enabled us to effortlessly scan over 2000 urls in less than 2 hours to provide a quick look at the security of all of our exposed urls. It is essential to put security on the forefront of organizational structure and to ensure that dynamic analysis is part of all build cycles

avatar for Nicholas Doell

Nicholas Doell

Senior Application Security Engineer, Verizon
Nicholas Doell is a senior application security engineer at Verizon. He received his M.Sc. degree in System Security Engineering from Stevens Institute of Technology in 2012 and has nine years of experience working in multiple security fields. He has a passion for web and mobile security... Read More →
avatar for Nicholas Kenney

Nicholas Kenney

Application Security Engineer, Verizon
Nicholas Kenney is an application security engineer at Verizon. He received his B.Sc. degree in Computer Science from East Stroudsburg University in 2012 and has worked in IT for 7 years. Nick started out working as a freelance web developer while in college, until being hired by... Read More →

Friday September 22, 2017 3:30pm - 4:15pm EDT
Coronado H