OWASP Global AppSec US 2021

How programming languages can bring an end to Injection Vulnerabilities, by "distinguishing strings from a trusted developer, from strings that may be attacker controlled".

This simple distinction will allow libraries to ensure Injection Vulnerabilities are not possible, because those sensitive values (e.g. SQL, HTML, CLI strings) cannot contain user values. Instead, it will be up to the well-tested libraries to handle user values; ideally via parameterised queries, but they can also use appropriate escaping.

Our security knowledge increases, our tools improve, but breaches still happen.

Studies show that 95% of security breaches are caused by human errors. One strategy to eliminate them might be to automate everything―to use smart technologies. But full automation remains an unrealized desideratum.

Another strategy is to build a security mindset. And here we have a challenge: how do we encourage people to do something that requires effort, that demands a change in behavior?

Recently, I participated in several activities through which I learned about the Maori way of educating people and managing change through storytelling and mutual teaching. It inspired in me the idea that this approach could be effective for educating people about security.

I lead cyber security work at a small company that is rapidly scaling and must significantly improve its security practices. Policies, guides, and traditional learning approaches haven’t changed behaviors by much, and awareness fades quickly after a course or a conversation.

I decided to test a new approach by using insights from the Maori culture of New Zealand to help to change the employees’ security mindset.

Here I share what I did and how it worked out. With these same practices, you may be able to achieve similar positive changes in your own workplace.

Serverless technology eliminates the need for development teams to provision servers, and it also results in some security threats being passed to the cloud provider. This frees up developers to concentrate on building logic and producing value quickly. But cloud functions still execute code. If the software is written poorly, it can lead to a cloud disaster.

How can developers ensure that their code is secure enough? They can scan for common vulnerabilities and exposures (CVEs) in open-source code. They can even scan their Infrastructure-as-Code (IaC) tool to identify insecure configurations. But what about custom code? At many organizations, the application security team struggles to keep up with the speed of development in a serverless environment. Traditional testing tools not only provide very limited coverage, but also slow development cycles unacceptably. Serverless code contains a mixture of cloud configurations and application programming interfaces (API) calls. As a result, legacy solutions lack the context that is necessary in a serverless environment, and the consequence is a lack of observability and slower response times.

Fortunately, it does not have to be this way. Organizations can leverage robust security during serverless development, automatically—if it is done properly. In this talk, we will discuss common risks in serverless environments. We will then cover existing testing methodologies and why they do not work well for serverless. Finally, we will present a new, completely frictionless way of testing serverless applications automatically—with no scripts, no tests, and no delays.

The goal of the OWASP Top Ten project is to raise awareness and create a baseline for application security by identifying some of the most critical risks facing organizations. The Top Ten project is referenced by many standards, books, tools, and organizations, including MITRE, PCI DSS, DISA, FTC, and many more.

Join me as we dive into what changed in the new OWASP Top Ten 2021. We'll briefly talk about each category and why it's part of the Top Ten. Hear about what we learned from collecting and analyzing widely varying industry data on over half-a-million applications, and building a dataset for comparison and analysis. We will discuss tips and common pitfalls for structuring vulnerability data and the subsequent analysis, and lastly, we will dive into what the data can tell us and what questions are still left unanswered.

With security teams being vastly outnumbered many organizations have responded to this challenge with different program scaling methods, including building security champions programs. Which leads us to questions; How does a security champions program work? How do you select your champions? And once you have them, what do you DO with them?

This session will teach you;
• How to attract the right people to your program
• What and how to train them
• How to engage them, and turn them into security advocates
• What do delegate and what NOT to delegate
• What to communicate, how often and to who
• How to motivate them
• How to build an AMAZING security champion program

Recipe for success; recruit, engage, teach, recognize, reward, don’t stop.

Data encryption has long been a major component of information security. Data in transit is well protected by the Transport Layer Security (TLS) open cryptographic standard and its predecessors, but unfortunately the same cannot be said for data at rest. The current, common approach for encryption of data at rest is to rely on low-level mechanisms that satisfy compliance requirements, but do not address modern security concerns. This session will discuss shortcomings of encryption at the disk, bucket, file, and database levels and provide alternatives that offer additional protection against ransomware, data theft, insider threat, and application layer attacks such as SQL injection. Technologies and techniques covered will include Application-Level Encryption (ALE), Transparent Data Encryption (TDE), Field-Level Encryption (FLE), client-side encryption, and custom implementations.

1. What's the need for automating architectural risk analysis, and why is IaC uniquely suited to helping us automate this activity?
2. Overview of the Open Threat Model format, and how to generate it using open source tools.
3. Operationalise OTM in a SecDevOps workflow.

Dating back to around 2007, OWASP ESAPI was one of the first comprehensive security libraries to attempt to provide security controls as defenses against common vulnerabilities in web applications. This presentation is a "lessons learned" from ESAPI about what was done right, what was done wrong, and some ugly hacks that many wish were done differently. The talk will focus on three perspectives: people, process, and technical details and will emphasize the unique challenges of supporting a security library.

AppSec champions program exist in virtually every organization that builds a ton of software and is security paranoid. These programs use informal influence and the art of persuasion to get software developers to write code with fewer security vulnerabilities. Many programs originate from the bottom up and lack strong organizational mandates – that’s where the Jedi Mind tricks come in.

AppSec champions may be widely implemented, but in general there is a lack of data on what organizations are actually doing in the field. The results of a 9-month research survey project attempt to change that, with first-ever data of common denominators of leading-edge appsec champions programs published. The structured research project involved 26 of the most innovative appsec programs, all of which had an appsec champion program. Many, if not most, were operating in isolation with no competitive data or widely understood best practices.

This session will identify the common denominators that we observed in the survey responses including emerging best practices around recruiting appsed champions, how security organizations trained champions, and how they communicated with champions in the field. Finally, return on investment responses are included to provide insight into how organizations are measuring success around their programs.

This data will certain recommendations about how security leaders should further build these programs to get upstream of the “vulnerability production engine” that creates additional attack surface. An emphasis will be focused on how attendees can take the survey results and use them for further justification for their own programs.

We’re not remotely close to solving the secure development problem. AppSec champions help win the hearts and minds of developers who are ultimately the ones who solve this problem. The hope is that armed with appsec champions numbers and best practices, attendees will be better equipped to help their development colleagues via AppSec champions programs.

This speech discusses observed Security Anti-Patterns as outcomes of Threat Modeling activities which require extensive rework if not accounted for in the design phase of the SDLC.
It also gives guidance on how to identify these Security Design Anti-Patterns in order to create awareness for Developers and Threat Modeling practitioners.

Mitigating Threats by implementing missing controls is part of fixing (acquired) Security Debt.
Threat Modeling activities aim at identifying missing controls very early on in the design phase of the SDLC.
However, not all Security Design flaws are created equal in terms of how easily they can be fixed. Apart from the impact that unmitigated threats have to a system’s security posture there is also the cost that development teams will have to bear associated with implementing missing controls.
Some design flaws or security threat mitigations can be fixed easier than others. Anti-Patterns described in the speech could result in a complete re-design of applications to fix security debt.
Worst case, the whole new system will not be allowed to be launched by compliance or the new system cannot be extended easily in a secure way.