Application security has never been more important, yet traditional approaches are starting to fall apart as applications get larger, faster, and more complex while software development has accelerated to “ludicrous speed.” Unless something changes quickly, the world’s entire, limited pool of security experts will soon be completely absorbed seeking out Cross Site Scripting (XSS) vulnerabilities. A new, automated approach called IAST has the potential to achieve better vulnerability analysis results in a way that is much more compatible with the way in which software is developed.
Would it surprise you to know that although the threat has changed dramatically in the last 30 years, the techniques for building secure code have hardly advanced at all? We trust software with our lives, our safety, our healthcare, our communications and our businesses. Unfortunately, there are over 925 different ways that developers can introduce vulnerabilities. The result is widespread flaws that criminals who know how can exploit them and cause malicious harm to others. What does it take to create and deploy secure applications? How do you get a handle on your application portfolio? How do you create a positive, practical and responsible application security program? Join Jeff Williams to learn about the steps your organization can take immediately to Get Rugged and improve your organization’s security posture.
Many organizations have reacted to the onslaught of vulnerabilities in their code by searching harder – more dynamic scans, more static analysis, more code review, and more penetration testing. But the cost and complexity of these reactive programs will continue to increase until they are completely ineffective. The only way to get in front of the problem is to find a new path that leads to healthier software development lifestyle.
Java EE™ is the platform of choice for critical applications – exactly the ones targeted by groups like Anonymous and organized crime. However, discovery of software vulnerabilities has always been a costly and error prone process. We have discovered a way to use the Java™ Instrumentation API to perform “intrinsic analysis” – finding vulnerabilities from within a running application. Our approach is simple to install and powerful – enabling developers to find security flaws without headaches and false alarms. We’ve created a Java agent that runs in your app server and discovers vulnerabilities passively as you develop and test, without requiring anyone to attack your code!
Penetration testing is the most widespread assurance technique used today, but it is wildly inconsistent, reactive, and negative. Web applications have been enjoying a golden age of very easy “pentesting,” but that’s all about to change as technologies with faster transactions, more complex data structures, and custom protocols emerge.
For a variety of reasons, the assurance challenge is not one that can be overcome with more and more powerful automated vulnerability tools. In this webinar, Jeff shares his experience helping organizations get over their pentesting addictions and build positive application security programs, like Microsoft Security Development Lifecycle.
Automated tools for application security are either “static” (SAST) or “dynamic” (DAST). But recently, new classes of “interactive” or “intrinsic” (IAST) tools have emerged — some are calling them “hybrid” analysis tools. Is this finally application security automation that works? Or is it just another round of hype and false alarms?
More than half of the Global 500 use software built using components with vulnerable code. 80% of the code in today’s applications comes from libraries and frameworks. The risk of vulnerabilities in these components is widely ignored and underappreciated. Our researchers analyzed over 113 million downloads by more than 60,000 commercial, government and non-profit organizations. We studied the 31 most popular Java frameworks and security libraries downloaded from the Central (“Central”) Repository and discovered that 26% of these have known vulnerabilities. Every organization should be concerned about the security of the components that they use and trust to run their business.
Learn how to create a software ecosystem that produces security naturally. No matter how fast you are at playing vulnerability whack-a-mole, the moles always win eventually. If you truly want to get in front of application security, you have to start looking at changing your software development culture. Jeff shares his experiences with multiple approaches to changing security culture, going back to the late 1980’s. Not surprisingly, few of these approaches have made any difference. OWASP represents a new approach, and is an interesting experiment on how we change software culture worldwide. Jeff extracts and clarifies the lessons from OWASP that you can use in your own organization to bootstrap a software culture that generates security.
The applications we entrust with our healthcare, financials and national defense are just as vulnerable as other code. The problem is, that while our threat environment has changed dramatically over the last 20 years, the way in which we write code has not. Security doesn’t have to weigh down software development. A responsible application security program provides services that make software development more agile and efficient. Jeff shares success stories from large organizations that have standardized their application security controls, raised the awareness of their personnel, and transitioned away from punitive penetration testing programs to a positive verification approach.
There’s a math problem with application security. The costs associated with finding and fixing an organization’s software vulnerabilities are dramatically more than anyone has to spend. Attempts to automate our way out of this crisis have left us with inch-deep coverage and huge numbers of minor findings to address. Fortunately, there is another way. Jeff started the OWASP Enterprise Security API (ESAPI) Project to encourage organizations to standardize and externalize their security controls.