AppSecUSA 2015

There exists a lot of web security scanners and many are doing a descent good job. Yet there are times and genuine reasons when you wished you had your own scanning infrastructure. You perhaps wished how great it would be if you could build your own in 40 minutes. That you had more control. That you can add your custom requirements. Or may be using an existing one was not an option, from cost, scale, speed or code reuse perspective.

In this talk we will demonstrate:
1. how to build a robust web security scanner that answers many questions you might have.
2. how to scale it up as an infrastructure,
3. how to integrate it into your own continuous delivery pipeline.

We will also discuss the difference in the nature of this project as compared to related works such as Mozilla Minion and Netflix Monterey.

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.

In this presentation, we will provide the OWASP audience the necessary insights in this emerging Web technology, and discuss the various security aspects of WebRTC. This content is based on a recent study of the Web Security specifications the author has been conducting together with researcher from W3C, IETF and SAP.
Firstly, the overall WebRTC architecture will be presented, and the enabling technologies (such as STUN, TURN, ICE and DTLS-SRTP) will be introduced. This architecture will be illustrated in multiple deployment scenarios. As part of this description, the basic security characteristics of WebRTC will be identified.
Secondly, we will discuss how the new WebRTC technology impacts the security model of the current Web. They will highlight some of the weaknesses they have spot during their security assessment, as well as discuss the open security challenges with the WebRTC technology.

DevOps puts an intense focus on automation – taking humans out of the loop whenever possible to allow frequent, incremental updates to production systems. However, thorough application testing often has multiple components – much of this can be automated, but manual testing is also required. This is inconvenient and not “DevOps-y,” but is unfortunately an unavoidable requirement in the real world. In addition, managing these multiple sources of application vulnerability intelligence often requires manual interaction – to clear false positives, de-duplicate repeated results, and make decisions about triage and remediation.

Axway has rolled out an application security program that incorporates automated static and dynamic testing, attack surface analysis, component analysis, as well as inputs from 3rd parties including manual penetration testing, automated and manual dynamic testing, automated and manual static testing, and test results from vendors providing test data on their products. Automation has allowed Axway to increase the frequency of web application testing, thus reducing the cycle time in the application vulnerability “OODA loop.” Moving beyond the identification of vulnerabilities, Axway has deployed ThreadFix to automatically aggregate the results of the automated testing and de-duplicate findings. 3rd party penetration testers are also finding vulnerabilities and reporting them in reasonably structured CSV files requiring Axway to convert this manual test data and incorporate it into the aggregated vulnerability model in ThreadFix. Centralizing this pipeline allows for metric tracking – both for the application security program as a whole as well as on a per-vulnerability-source basis. This automation and consolidation now covers 50% of Axway’s application vulnerability review process - with plans to extend further.

This presentation walks through Axway’s construction of their application security-testing pipeline and the decisions they were forced to make along the way to best maximize the use of automation while accommodating the reality of manual testing requirements. It then looks at how this testing regimen and the associated automation have allowed them to impact deployment practices as well as collect metrics on their assurance program. Finally, it looks at lessons learned along the way – the good and the bad – and identifies targeted next steps Axway plans to take to increase the depth and frequency of application security testing while dealing with the deployment realities placed on them to remain agile and responsive to business requirements.

This presentation will provide an overview of developing extensions for the Burp Suite intercepting proxy. Using examples from extensions developed by the author we will discuss a number of key areas for anyone wishing to develop extensions for Burp Suite:

- Request modification
- Passive scanning
- Active scanning
- Identifying insertion points
- Integrated graphical user interface tab

Outline:
- Define multi-factor authentication
- Describe the current state of the technology
- Describe key problems
o 2D fingerprints, other already-hacked biometrics
o QR codes
o SMS OTP (subject to MITM)
o JavaScript requirements
o Weak account recovery methods
o Lack of mobile device risk analysis, not using OWASP Mobile Top 10 Risks for mobile
o Encryption with backdoors
- Recipe for what you can do

As German defense minister, Ursula von der Leyen can attest, fingerprints can be hacked, even from photographs. Facial and other biometrics can also be hacked. Why, then, is biometric-based authentication so fashionable?

It is easy to reset a password. It is hard to reset fingerprints.

Why are there over 200 multi-factor authentication vendors? Why is multi-factor authentication so expensive? Are there open source alternatives? What is the FIDO Alliance? Is it marketing hype or great standards?

Unfortunately, the current multi-factor technology offerings reflect evolutionary slip-slide, not quantum leaps forward. However, one or two technologies show promise.

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.

Timing attacks are usually undervalued by most web penetration testers. In this presentation, I’ll talk in details about timing attacks. I’ll focus specifically on the wrong use of the == operator and equals function which does byte by byte comparison in all modern programming language such as.NET, Java and Python. Using the == operator and equals functions in sensitive operations could lead to complete compromise of the system. The novelty of this talk is in the updated mathematical equation i used to increase the time difference response from the vulnerable server and hence improve the accuracy (the last equation in the the following section). The other important aspect is the real-world attacks examples that I'll present and finally I'll cover the challenges to timing attacks (like network delays) and how did I overcome it in my attacks.

Timing attacks are very tricky. The sources of noise are many. You can always fall in the trap that the data you gathered and analyzed mean something while actually it doesn't. Following the right approach (that I'll explain in this presentation), you can convert the non-feasible brute-force attack against a system to a feasible timing attack.

The main equation that drives this attack is as follows:
c := is the character set of the target string
n := is the total length of the target string

Brute Force:
c^n trials
(usually infeasible to perform. Sometimes you need the earth time to break the system)

Timing Attack in a perfect environment:
c * n
(usually infeasible also due to noise)

Realistic Timing attack:
c^t * n/t * l
where t << n and c^t can be generated in reasonable time
l is the number of trials needed to reduce the error of noise and distinguish between valid and invalid trial

By carefully selecting the t, a timing attack can be performed. t should be big enough to make statistical difference over the variance in network delay and small enough to execute the attack in reasonable time. Statistical approaches such as the null and alternative hypotheses are some of the means to analyze the timing attack results.

Organizations are increasingly incorporating open source software into their applications. Leveraging existing software to provide generic functionality results in reduced development costs as well as faster time to market.

However, along with these benefits, this freely available software also comes with an inherent problem – security vulnerabilities. While the advantages of using open source software are obvious, the negative impact on security brought on by their use is insidious.

While organizations spend enormous effort in securing their applications, most of this effort goes toward securing the part of the application that was developed in-house. A relatively small percentage of effort goes toward evaluating vulnerabilities in open source software, if they are considered at all. This makes open source libraries the weakest link in the security chain of an application.

We will present the current status of vulnerabilities in commonly used third party libraries and their impact on your application. We will then discuss an approach to holistically secure your application: a combination of securing in-house code and managing the security risk of third party libraries that are used.

Mom had a good reason for you to eat your vegetables; same thing goes with Application Security. It’s the good solid meat and potatoes (and broccoli) that help our programs grow up big and strong. The latest software development practices are out pacing traditional application security programs. Agile and DevOps are increasing the speed and frequency of development and deployments. Traditional application security is either slowing the process down or being bypassed; neither path is good for business. Security must be integrated into the process so that it is not an afterthought that inhibits the release of new features and fixes, but rather an expectation set up front.

Does your organization have unlimited resources? Of course not, you need to know where (and how) to spend the limited resources that are available to you. If you have an unknown number of applications with unknown levels of risk; how do you know which ones you should spend your limited time and resources on (and to what level of effort)? This critical understanding of the security stature of an application is not possible without a solid secure development program.

You hear the terms "proactive application security” or “earlier in the SDLC” often where someone is talking about how they managed to get pen testing or code review earlier in the testing cycle. This is an all too common pitfall in Secure Development and is often bypassed when seen as an impediment to delivery. There is a lot of time and money spent on the post-code activities: code review, functional testing, vulnerability assessments, and penetration testing. These are crucial activities for validating the current state of the application; but they are simply too late and too slow by themselves.

If you security team is only searching for vulnerabilities, they are not looking at the big picture; and they are doing your developers a disservice. Your developers are being held to security requirements that were not part of the original application design. Before you get to a security assessment, you need a line of sight from the potential threats to the application, through the resulting security requirements, the design/architecture, and how the design incorporated security controls at the right levels to help mitigate those identified threats.

Hear about what’s worked and not worked for different organizations in both the public and private sectors over several years of building secure development programs. There will be a focus on understanding the key components of a successful Secure Development Program, along with the critical differences when integrating with development life-cycles like Waterfall and Agile, and DevOps. See how secure development can feed your Risk Management Framework and other key initiatives and learn how a Secure Development Program may even justify its own existence.

Despite being known for more than a decade, Cross-Site Scripting (XSS) vulnerabilities are still very prevalent and frequently reported by security researchers. This partially explains why it is constantly ranked among Top 3 of the OWASP Web Application Security Risks since 2007. To defend against XSS, the most recommended approach is to apply output escaping based on the context (e.g., data, attribute, URL) that untrusted data will be placed into.

Nevertheless, realizing the context-sensitive escaping approach is a very complex process. For instance, the href attribute of an anchor tag is a compound context made up by a URI and attribute value context, for which secure escaping will involve using html entity encoding, percent-encoding, and a protocol validator to prohibit javascript: protocol.

Modern template engines only attempt to mitigate the vulnerabilities with a context-insensitive approach, therefore blindly escaping some special “XSS characters” (e.g., &, <, >, ', ") for all data that will replace the output expressions. Hence, malicious inputs known to be often injected through output expressions are encoded to their equivalent HTML entity representations that will not be rendered as executable scripts. Only a few large Internet corporations can afford to enhance the output expression escaping with a context-sensitive approach, but the solutions are specific to their own development and template frameworks (e.g., Closure). Other web applications, incapable of switching to those frameworks or lacking expert level of security supports, are remain vulnerable.

To address various needs of the majority, we propose a new set of solution, of which the components are loosely-coupled and readily available for extensions and standalone uses.

- Context Parser. Engineered from scratch, Context Parser is a heavily optimized HTML parser that is completely compliant to the latest HTML 5 standard. For instance, It eliminates unnecessary parsing rules and parsing tree construction. The processing speed is among the most efficient parsers of its type.

- Just Sufficient Escaping. We redesign a new set of context-sensitive XSS filters to escape only those characters that can possibly break out from the specific output contexts. Unlike other existing filters, the just sufficient escaping filters accurately avoid unnecessary escaping. Compared to the context insensitive filter, our filters are more secure, up to two times more efficient, and have also solved the age-old problem (such as those extra &lt;) of double/over-encoding.

- Template Compiler. Applying context-sensitive escaping manually is error-prone. Therefore, we need an automatic compiler capable of conducting contextual analysis. We build the first compiler for an open and popular template engine (i.e., the Handlebars JavaScript template engine) to facilitate immediate adoption.
a) Template Contextual Analysis. A standalone and handy tool is made available to perform automatic contextual analysis on the templates, and detect dangerous uses of output expressions and branching conditions.
b) Automatic Context-sensitive Escaping. The compiler analyzes a template and can automatically detect the contexts and insert the corresponding escaping filters. With the precompilation model, the analysis and filter insertion processes are completely offline, and thus require only the efficient escaping during runtime. All it requires from developers is only a few line of code changes to adopt the solution for both server or client-side rendering.

The solution is applied to one of the largest public-facing properties of Yahoo. The template compiler takes less than two and a half seconds to scan and process over 880 template files. Hence, it incurs insignificant performance overhead to incorporate the compiler into the regular build process. The template contextual analysis is able to flag output expressions that are placed in dangerous contexts such as script tag and attribute. We also verify that the context-sensitive filters are inserted in appropriate contexts. Most importantly, contexts such as unquoted attribute value and URI, that were unprotected by the context-insensitive approach, are now made invulnerable to XSS with the context-sensitive escaping.

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.

Bots, also commonly referred to as scrapers or spiders, are omnipresent on the Internet. Studies show that bot activity represents a great percentage of the overall traffic on the Internet. Bots are built for different purposes from simple health check to ensure the site is up to site spidering for the purpose of indexing the content or collecting specific information en mass. Not all bots are bad:
- The ones operated by search engines, audience analytics, SEO companies, web site performance monitoring services or partners drive users to the site, are vital to its success and the business it supports. But like with any automated activity, sometimes with the best of intentions, bot activity can have a negative load impact on the web site infrastructure.
- Other bot activity, sometimes more difficult to detect, can have more questionable benefits, hurt the image of company that owns the targeted site or even have some impact on the company's revenue in the case of content theft or competitive scraping.

The amount of bot activity seen on a given web site is generally proportional to the value of the content hosted on the site. The value of the content is defined by the dollar amount that can be gained by exploiting the data collected.

Bots are usually part of botnets and come in all shapes and sizes. Some are very simplistic scripts that run on a single machine and can only support a single task. Others are highly distributed and have the same abilities as a web browser and support a wide variety of tasks.

In order to efficiently detect as much bot activity as possible, it is essential to implement many different techniques to match the different types of bots. In this talk, we’ll discuss different detection methods including evaluating the HTTP header signature, testing the ability of a client and evaluating the client behavior.

Detecting bots is however half of the trouble. Because a bot has a certain header signature or behavior doesn’t mean it has bad intentions and would have a negative impact on the business. Clearly identifying and categorizing the bots is key, this talk will provide some guidelines on how to identify and categorize bots.

Once detected and categorized, bots that are considered good for the business should be allowed access to the content. However, the one that do not appear to bring any benefits should be handled appropriately. Denying the traffic has the immediate effect of sending a signal to the bot operator, telling him that the activity was detected. Although such action may provide immediate relief, the bot operator may adapt, redeploy and resume its activity undetected. To conclude the session, we’ll go over some guidelines on how best to respond to “bad bot” activity.

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.

We created a “Game of Hacks” – a viral Web app marketed as a tool to train developers on secure coding – with the intention of building a honeypot. During a 6-month timeframe, we witnessed each attack that came at this game, secured the app against it and studied how attackers adapted to the mitigation measures. The lessons learnt can be applied to any Web app introduced into the organization.

-----

How do hackers adjust, in real-time, to various strengthening measures of Web apps? We set to answer this question through an interactive Web app honeypot. For the honeypot, we created a viral Web-based gaming application. However, the lessons learnt could be applied to any Web application.

Aptly called “The Game of Hacks”, our gaming app was marketed as a tool to train developers to write secure code. The app presented users a piece of vulnerable code and a set of multiple choice questions from which the user had to choose the correct vulnerability – in the minimal amount of time. Storing a central database, the app kept a scoreboard of all players, displaying the top winners. Additionally, the app was built on crowd-sourcing capabilities where users could contribute their own piece of code and questions.

Our “Game of Hacks” quickly became a popular game, boasting more than 200K users within 2 weeks. Consequently, it also garnered the desired hackers’ attention. We were set to analyze, planning a continued 6-month analysis.

With the list of vulnerabilities in hand (and some that we added as we adapted to the threat landscape), we witnessed each attack that came at this game. Against each attack, we secured the app and studied the attackers’ next move. One by one, we crossed off the different attacks and had a live look at the way that attackers adapted to our mitigation measures.

We start this session with a brief introduction to “Game of Hacks” and the included vulnerabilities. We then proceed to simulate the actual honeypot activity in an interactive session similar to the actual cat-and-mouse game that we witnessed: for each vulnerability, we show how it was exploited, the corresponding security measure and how it was bypassed.

We examine vulnerabilities/ attacks such as: A) Business logic attacks. Here, hackers tweaked the timer so that their scores – based on parameters such as time and accuracy - became unsurpassable. B) DDoS attacks through site scraping where an external database was built to correctly respond to each question automatically. C) Comment spam enabled through the crowd-sourcing of questions.

We finalize the session with a summary of the methodologies we took to strengthen our gaming honeypot and share with attendees our insights. It is our hopes that attendees learn from these measures and apply them to any Web app being introduced in the enterprise.

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.

Human Machine Interfaces (HMIs) are the subsets of the Supervisory Control and Data Acquisition (SCADA) systems. HMIs are control panels that provide interfaces for humans to interact with machines and to manage operations of various types of SCADA systems. HMIs have direct access to SCADA databases including critical software programs. The majority of SCADA systems have web-based HMIs that allow the humans to control the SCADA operations remotely through Internet.
This talk discusses the insecure development practices followed by SCADA developers while designing web HMIs that lead to inherent application level vulnerabilities. This talk digs deeper into the design models of various SCADA systems to highlight security deficiencies in the existing SCADA HMI deployments from application security point of view. In this talk, several real time case studies will be discussed to highlight the state of application security in the field of SCADA. This talk unveils various flavors of vulnerabilities in web-based SCADA HMIs including but not limited to remote or local file inclusions, insecure authentication through clients, weak, insecure web-services, weak cryptographic design, cross-site request forgery, and many others. The research is driven with a motivation to secure SCADA devices and to build more intelligent solutions by hunting vulnerabilities in SCADA HMIs. A number of vulnerabilities will be demonstrated in SCADA web HMIs. In addition, this talk also discusses how OWASP standards can be used by SCADA developers as baselines to develop robust SCADA web HMIs to defend application layer attacks

In two years, over twenty thousand Cisco employees and contractors worldwide invested hours over and above their assigned duties to improve their knowledge of application security. Why would they take action voluntarily? What made them care about security? The answer is we made application security awareness personal, professionally valuable, and fun.

In today’s chaotic environment, every company desires a more secure product or solution, and their customers demand it. To achieve this, every person involved in the product life cycle must be security aware. The challenge is teaching people in a way that sticks. This is how Cisco did it: how employees and contractors learned to love and own Cisco’s security story; and built security into our organizational DNA and our products and solutions.

The Cisco Application Security Awareness Program raises technical security awareness at all levels of the organization through the creative, fun, and humorous use of video. The content ranges from introductory to advanced learning, using belts to measure student achievement and provide recognition. As students progress, they migrate from knowledge acquisition using video into doing things to improve the security of their products. A system of tracking and recognizing achievement-based activities gets people fired up to make security improvements in their products. Sprinkled throughout the talk are examples of the videos and interfaces that draw users into this world. The audience will experience the Cisco Security Awareness Program and visually understand the abstract concepts described.

Approaching crescendo, it is time to address the elephant in the room: “So What”. What is the true impact to Cisco? Through the metrics and feedback collected, a case will be made that this program has had a huge positive impact for Cisco.

The grand finale is the “top ten secrets of success”. This is a discussion of the actions taken to achieve success, broken down into four categories: content, recognition, system, and marketing.

Content is the lessons learned about video and how to master it for success. Recognition is how to reward participants and lead them to want to grow as security people. System is how to set up for success. Marketing is the intentional causes for the viral nature of the program.

This advice applies to real life; this is how we did it, now how can you learn from us and apply this in your own organization.

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.

One challenging aspect of achieving software security is the struggle to catch up with the speed of development and deployment. We built Providence with the goal of preventing obvious bugs from ever being deployed into production.

Providence is a lightweight and scalable tool which finds bugs and anti-patterns of varying complexity from code commits, and we’ve used it to prevent vulnerabilities ranging from XSS, to access control issues, to XXE. It works by continuously monitoring and pulling commits from version control systems and scanning them for bugs with rules defined in plugins. Additional plugins are easy to create and deploy, which has allowed for quick reaction to new bugs or problems as they are discovered.

Providence is easily integrated with SDLC workflows or bug-tracking tools, and we will discuss how we have integrated it in-house in an unobtrusive manner. This model of addressing issues also provides relative immediacy of resolution; on average, potential problems found by Providence are resolved more quickly than other vulnerabilities because developers are presented the issues right after they commit the code, instead of weeks to months later.

We are currently in the process of open-sourcing Providence in order to share the tool with the DevOps/security community (or any interested parties). This talk will cover the internals of Providence, its engine and plugin architecture (including examples of plugins and their ease of creation), as well as its integration with our SDLC and the faster and more efficient responses we’ve achieved as a result. We’re continuing to build new plugins and features, and we’re excited see what ideas others may have in mind!